さて、いよいよ本題です。マインド・マップをソフトウェア開発でどのように使えるか、というテーマを扱います。特に、オブジェクト指向開発においてなくてはならない標準記法である、UMLとうまく融合して使えないか、という挑戦です。
まずは、少しマインド・マップの特徴を分析してみます。再度先頭のマインド・マップの例を、ツール(JUDE)を使って書いてみました(図7)。
マインド・マップは、視覚的には放射状の構造をしていますが、論理的にはツリー構造になります(図8)。
また、文章の構造(章、節、パラグラフ)を表現しているということもできます(表)。
価値
原則
実践
このように、マインド・マップは非常に単純な論理構造です。しかし、その分、柔らかく、応用が利く構造だといえます。ツリーの枝から葉へとつながるキーワードの関係性の意味は、特に規定されていません。マインド・マップはただ単に「連想」ということだけで、非常に単純で決め事が少ない記法だということができます。
では、UMLをマインド・マップと比べてみます。図9にレンタルビデオ店の概念モデルの一部をUMLの例として示します。四角で描かれている1つ1つの名詞がクラスを示し、クラス間の関係が線によって書かれています。線には種類があります。図には、関連(−)、汎化(白抜き矢印)、コンポジット(黒いひし形)などが登場しています。例えば、汎化はいくつかの概念の上位汎用概念を示し、コンポジットでは、全体−部分の関係を示します。さらに、「1」や「*」のように関連の両端に多重度が書かれ、クラス間の要素の数との関係を示しています。
このように、UMLは文法(シンタクス)と意味(セマンティクス)が定義されており、概念間の関係を雄弁に定義しています。また、「正しいモデル」と「正しくないモデル」の分け目が比較的きっちりしています。しかし、UMLでクラス図を描いているとき、文法や意味で悩んでしまい、手が止まってしまうことはありませんか? これはどう描くのだろう、これで正しいのだろうか、この矢印はどちら向きだっけ? などと描き方のレベルで悩んでいては、素早くアイデアを書き留めることができません。アイデアがどんどんわいている過程や、顧客へのインタビューの過程では、とにかく手を止めずに言葉を書き留めて収集することが重要です。それは人によっては一般的なメモ書きだったり、付せんを使ってみたり、きれいに整理されたノートなのかもしれません。
マインド・マップは、発想法ですから、思い付きを逃さず書くこと、文法や意味よりも、語彙を自由に発散させることができるのが特徴です。文法や意味がない分、フリーな感覚で思考を止めることなく、どんどん書くことができます。また、マインド・マップはキーワード指向です。そのため、一般的な文章とは異なり、より簡潔にキーワードでまとめられた「単語地図」となります。文章に比べて個々の言葉がより際立ち、意味を見る者に訴えかけます。さらにマインド・マップを書く速度は、日本語の「文章」を作るよりも高速です。さらに、マインド・マップは一覧性に優れています。全体をぱっと見て分かる1つの絵に押し込めます。細かく見ようと思えば枝を拡大して見られますし、一歩さがれば、全体を「ふかん」することができます。
ここでもう1つ、マインド・マップが持つ、最も重要な特徴があります。この記事の最初で述べたマインド・マップの「想起力」(思い出す力)です。マインド・マップは、一度見たら忘れられないインパクトを脳に与えます。後で自分が書いたマインド・マップを見て、その場面(アイデアがわいた瞬間や、顧客との会話、誰とどういうムードで話をしたか)がよみがえります。「対話」や「ムード」というドキュメントにはうまく載らないコンテクスト情報を、マインド・マップの持つ「想起力」によってつなぎ留めることができるのです。
この特徴を生かして、アイデアを広げる場面、アイデアを収集する場面においてマインド・マップをうまく使えるのではないか、と筆者たちは考えています。『実践UML』の著者として有名なクレーグ・ラーマンも、アイデアや要求の収集の場面で使える 「ブレインライティング」(頭の中の書き出し)と「アフィニティクラスタリング」 (グルーピング)手法の1つとしてマインド・マップを紹介しています[6]。
「アジャイルソフトウェア開発宣言」[7]において、ソフトウェア開発では、顧客との対話が重要であることがうたわれて再認識されています。特に、ユーザーが語るストーリーが重視されており、「ドキュメント」が顧客との対話の代替にはならないことが改めて認識されています。ストーリーカードは、「情報カード」という媒体に書かれて壁に貼り付けられます。この「ストーリーカード」という媒体は、物理的でたくさん書き込めないアナログなものをわざと使うことで、ユーザーとの関わりの重点を「ドキュメント」から「対話」へと移すことが狙いです。つまり、ストーリーカード自体は「仕様」ではなくその対話を思い出すことができる「きっかけ」「シンボル」、過去のリアルな場面への「ポインタ」、対話の「イコン」[8]となるのです 。
同じように、マインド・マップはその想起性によって、実際の場面を思い出すことができる、という特性を持っています。これを利用して、コンテクスト情報を埋め込んだ形でアイデアをキーワードと連想によって収集しよう、というわけです。顧客とのインタビューで収集した情報は、「キーワード」によってマインド・マップに素早く記録されます。キーワードには、顧客自身の使った言葉がたくさん使われているでしょう。マインド・マップを後で見ると、顧客との対話の場面を思い出すことができます。描き終わったマインド・マップをその場で積極的に顧客に見せて、対話の場面を印象付けることができます。マインド・マップも、ストーリーカード同様、対話の「イコン」として機能します。
さて、マインド・マップの特徴をまとめます。
「要求」という魔物をとらえようとする難しさは、 例えば「要求開発」の分野[9] でも大きなテーマとなっています。
この記事の最後に、「要求分析」という活動のなかで、マインド・マップと UMLとの役割分担を考えたいと思います。前述のように、マインド・マップは、素早く書ける、全体が見える、キーワードで書ける、その場面を思い出すことができる、という特徴があります。
図10に、マインド・マップとUMLが得意な分野を分けてみました。要求分析の前段階の発散・収集過程を、「要求ギャザリング」活動、後段階の収束・モデル化過程を、「要求モデリング」活動と呼びます。
要求ギャザリング活動では、ソフトウェアの仕様や要求分析を行う「基」になる、「アイデア出し」や「情報収集」を行います。マインド・マップをうまく使うことで、思考のスピードを落とすことなく、キーワードを収集することができます。また、後で対話や発想の場面を思い出すことが容易になります。
そして、その後の「要求モデリング」活動において、収集したキーワードから、より関係の意味をしっかり表現できるUMLモデルへと落としていきます。ここでは、UMLの持つしっかりしたセマンティクスとシンタクスが生き、後の設計フェイズへとつながるアウトプットを出すことができます。
こういった役割分担を行うことができる、というのが、マインド・マップとUMLの融合の骨子です。
“出して、つなげて、広げる”のがマインド・マップ、“並べて、つなげて、まとめる”のがUMLといってもよいでしょう。 これによって、双方の利点が生きる形での融合が可能です。
ここで注目していただきたいのはいままで「要求ギャザリング」の過程が、要求分析という文脈においてあまり注目されてこなかった点です。マインド・マップのような思考ツールは汎用的なテクニックのため、要求分析と同じ文脈で語られることがありませんでした。しかし実際に業務に携わっているプロフェッショナルの中には、以前からマインド・マップを使用していたり、付せんにキーワードを書いて整理したり、アウトラインエディタにメモを取り整理する、という現場の職人芸で要求の収集や発散過程を処理してきた方が多くいます。今回のマインド・マップとUMLの連携という挑戦は、この「要求ギャザリング」という発散過程の暗黙知の表出化ともとらえることができます。
最後に、本記事(前編)を書くに当たって作ったマインド・マップを紹介します。
さて、後編は、現実の要求収集から分析・モデリングという場面において、実際にどのようにマインド・マップとUMLが連携するのか、という実例をお見せしましょう。
Copyright © ITmedia, Inc. All Rights Reserved.