連載
» 2005年07月12日 12時00分 公開

マインド・マップとUMLを使った要求分析支援(後編):マインド・マップとUMLの連携術 (2/2)

[安井力,株式会社 永和システムマネジメント]
前のページへ 1|2       

ユースケース図を作成しよう

 開さんは話を聞きながら書いた議事録を基に、設計作業を進めようとしています。まずはシステム化範囲を明確にしつつ、ユースケース図を描きます。

 ユースケース図を描くために、まずは議事録の中からユースケースになりそうなものを探しました。だいたいが、受け付け業務の中に含まれています。一部、業務内容の説明の中から取り出したものもあります。それぞれのトピックを右クリックして「UMLモデルに変換する」→「ユースケース」を選択すると、画面左上の構造ツリーの中にユースケースができていきます(図5)。

ALT 図5 マインド・マップからユースケースを作成する(クリックすると拡大)

 この時点では、まだユースケース図は空っぽの状態です。ここに、構造ツリーからユースケース図をドラッグしてくると、図上にユースケースが乗ります(図6)。

ALT 図6 ユースケース図(初期状態)(クリックすると拡大)

 これを並べ替えたり、名前を変えたり、《include》などで関係付けたりしていきます。またアクターも付け加えましょう。

 議事録上では「加工を聞く」などとなっているトピックが、ユースケース上では「加工を登録する」などとなっている点に気を付けてください。「加工を聞く」のは受け付け担当(おじさん)のやることですが、ユースケース図ではシステムとアクターのやりとりを表現します。お客さんから加工を聞いた受け付け担当は、システムに対しては「加工を登録する」という操作をすることになるのです。

 議事録からは、取りあえずユースケースになるかもしれないものを片っ端からユースケースにしてしまいます。図上に配置して検討しながら、不要なものは削除していきます。ものによってはノートになったり、組み合わせて別のユースケースになったりもします

 例えば、議事録上の「料金を決める」というトピックはユースケースになりそうですが、ユースケース図上では「料金をもらう」に含まれるものとして消してしまいました。「受け付け」「お客さん」となっていたものは、「お客さん情報を入力する」というユースケースになりました。

 図上には適宜、ノート(コメント)も入れていきます。マインド・マップのトピックから直接ノートを作ることはできませんが、トピックをCtrl+Cでクリップボードにコピーして、ユースケース上でノートを作り、そこでCtrl+Vを押すとトピックのテキストを張り付けられます。ここではノートに色を付けています。水色はUMLだけでは表現できない仕様の記述、ピンク色は後で確認する必要がある内容です。この色分けは平澤章さんのやり方を真似ています。

 こうして作成したのが、図7です。

ALT 図7 ひとまず完成したユースケース図

クラス図を作成しよう

 続いてクラス図も作成します。ユースケースと同じく、トピックを右クリックして「UMLモデルに変換する」→「クラス」を選択すると、構造ツリー中にクラスができます。これをクラス図に配置して、操作や属性を加えていくのです(図8)。

ALT 図8 クラス図(初期状態)(クリックすると拡大)

 第1段階として、マインド・マップから作成したクラスを並べて、思い付くままに配置して関連を引いてみました(図9)。ここではクラス名はまだ変えていません。関連は「なんとなく関連してそう」というレベルです。関連のないクラスもあります。お客さんの電話番号や住所など属性になりそうなものも、関連でつなぐのにとどめています。また分類やカテゴリであるものは、継承にしています。(「大カテゴリ―小カテゴリ」の関係と、「カテゴリ―具体的な物」の関係は、見分けにくいことが多いので、いまの段階では区別していません)。

ALT 図9 取りあえず並べてみたクラス図

 クラス図だけではうまくつかめないところは、オブジェクト図を描いてみるのが1つの手です。ここでは、ヒアリングで聞いた具体例の部分をそのままオブジェクト図にしてみました。防虫と防水がオプションのサービスであることが分かります。一方クリーニングは必須なのか? クリーニングなしで防水加工だけということもあるのか? 情報が足らないことが分かりました。次回のヒアリングで使う議事録マインド・マップに、あらかじめ確認事項として書いておくとよいでしょう。

ALT 図10 オブジェクト図

 マインド・マップからオブジェクトを作成するには、構造ツリー上でマインド・マップを広げて([+]をクリック)、各トピックをクラス図にドラッグします。UMLモデル変換ダイアログが開くので、種類を「オブジェクト」にしてOKを押します。

 このクラス図はまだまだ完成とはいえません。ここを出発地点にして、洗練させていく必要があります。洗練させていくにはいろいろな方法がありますが、本稿の趣旨を外れてしまうのでここでは割愛します。

マインド・マップとUMLの連携

 今回は、要求分析のヒアリングでマインド・マップを利用し、そこからUMLモデリングを行うという流れを見てきました。このような作業をするうえでのポイントをいくつか紹介します。

  1. マインド・マップはルール無用。つながりの意味はあまり意識せず、書きたいことや思い付いたことをどんどん書いていきましょう
  2. マインド・マップのトピックはキーワード。説明を避けて一言で書きましょう。「トピック」「キーワード」「一言で」のように、分割して書くのも手です
  3. UMLモデリングは段階を踏んで。いきなり完成系を目指さず、試行錯誤しながら徐々に洗練させていきましょう
  4. 清書は最後に。ついつい図をきれいに配置したくなりますが、きれい過ぎるとかえって修正しにくくなってしまいます。並びは適当なままで、いろいろといじってみましょう

 マインド・マップは思考の「発散」、UMLは「収束」です。キーワードを使ってどんどん範囲を広げながら情報を集めていくのにはマインド・マップが、そうして集めた情報の取捨選択と整理分類はUMLが向いています。それぞれの特徴をつかんでうまく組み合わせることによって、新たな「思考ツール」になるかもしれません。自分に合うように工夫して、自分ならではのやり方を編み出してみてください。


[議事録マインド・マップで営業とコミュニケーション]

 マインド・マップのちょっと違った使い方を紹介しましょう。マインド・マップの別の使い方として、会議の内容を人に教えるために議事録マインド・マップを活用する、というものがあります。

 一般的な議事録は、記録としての使い方が主な目的になっています。要点だけ、結論だけがまとめてあり、話の流れや雰囲気といったものは伝わりません。また多くの場合、紙やファイルになった議事録を人に渡すだけで、議事録を見せながら会議の内容を人に説明することは少ないのではないでしょうか。

 議事録マインド・マップは、その想起力を生かして、議事内容を説明するのに有効です。単に見せるだけでは内容はあまり伝わりません。むしろ普通の議事録の方が分かりやすいくらいです。しかし、自分が書いたマインド・マップを眺めると、ああこんな話もあったな、ここは盛り上がったんだよな、という印象や感想を思い出しやすくなります。

 会議の内容を人に伝えるときにも、より臨場感のある説明をできますし、聞く側も細かいニュアンスや会議参加者の姿勢といった感覚的なものをつかみやすくなります。さらに、議事録を説明する側とそれを聞く側が、マインド・マップという図=イメージを共有することができます。深いレベルでの認識の一致が図れるようになるのです。

 この記事を読んでいるのはほとんどが技術者の方だと思いますが、非論理的・感覚的な話をする人と話が通じないという経験がある方も、多いのではないでしょうか。筆者の体験ですが、プロジェクトの担当営業がお客さんとの打ち合わせから意気揚々と帰ってきて、「今度こそお客さんやる気なんだよ! うちの誠意と努力が通じてきたみたいで!! これから正念場だから、頑張っていこうな!!!」などといわれて、だからつまりどういうこと? 何をどう頑張るとお客さんが喜ぶの? と突っ込みたくなることがよくありました。

 いまにして思えば、そんなときに営業の人が議事録マインド・マップを出してきて、会議の展開や流れを説明してくれていたら、もっとお客さんの要望や営業の狙いが分かり、プロジェクトのビジョンを共有できていたかもしれません。マインド・マップをもらってそこにコメントを追加して、技術側のヒアリングの材料にも使えたでしょう。技術と営業が、より良くコミュニケーションできるようにさえ、なったかもしれないという気がします。

 マインド・マップを書いていると、いったいなに書いてるの? と関心を示す人が少なくありません。そうしたチャンスをとらえて、簡単に書き方を説明して「試しに書いてみたら?」と勧めると、その人とのコミュニケーションがうまくいくようになるかもしれません。ぜひ、やってみてください。


前のページへ 1|2       

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ