TOPプロジェクト管理> ソフトウェアの要求の見える化
見える化
見える化とは何か〜改めて問うその真価

第1回:「見える化」はなぜ必要か?
著者:チェンジビジョン  平鍋 健児   2006/10/26
前のページ  1  2   3  次のページ
ソフトウェアの要求の見える化

   次に、ソフトウェアの要求に話を移そう。ソフトウェアの要求を獲得するという活動は非常に難しい。標準の図解法が存在しないし、インタビュー技術のような人間系のテクニックも必要だ。そこで私が着目したのは、Mind Map(マインドマップ)だ(図2)。
アイデアの見える化(JUDEによるMind Mapの例)
図2:アイデアの見える化(JUDEによるMind Mapの例)
(画像をクリックすると別ウィンドウに拡大図を表示します)

   Mind Mapは英国のトニーブザンが開発した、発想図解法である。放射上に周囲に伸びる枝が印象的な、アイデアノート術といえる。JUDEでは、このMind Mapで「発想」を、そしてUMLで「アーキテクチャ」を見える化し、両者を行ったり来たり相互変換できる。この融合は世界でも初めてのアイデアだ。

   UMLは比較的厳密な描き方の作法があり、システム開発の知識がない人には読み書きが難しい。しかし、Mind Mapは言葉と連想線だけのフリースタイルな図解法であるため、どんな人でもある程度読み書きができる。

   図2は、市立図書館のシステム開発を例題として、実際にユーザに要望の聞き取りを行った例である。「誰が使いますか?」「どんな場面で使いますか?」「何を管理したいですか?」という質問をあらかじめ用意しておき、その場で枝を伸ばしながら Mind Map にユーザの答えを書きとめている。

   このように、システム開発の前段階、すなわちユーザの要望聞き取りから要求の仕様化といった、ぼんやりしたアイデアを集めている場面(要求のギャザリング)ではMind Mapを用いる

   そしてその後のシステム開発への準備段階、すなわちソフトウェアに変換するためのモデルを構築する場面(要求のモデリング)では、UMLを使ってより厳密に仕様化する、という2段階の手法を提案する(図3)。

Mind MapとUMLの融合
図3:Mind MapとUMLの融合
(画像をクリックすると別ウィンドウに拡大図を表示します)

   システムの企画やアイデアをMind Mapで収集・整理し、そしてUMLでモデル化して分析・構築する。こうして作られた要求モデルは、以降の設計、実装において、スムーズに元々のアイデアの理解とつなげていくことができる、という利点がある。

   JUDEを使うと、作ったMind MapからターゲットとなるUMLへドラッグ&ドロップで簡便に変換が行える。図4は図2で作った市立図書館のMind Mapを、「ユースケース図」と呼ばれるUMLに変換したものである。

ユースケース図
図4:ユースケース図
(画像をクリックすると別ウィンドウに拡大図を表示します)


システム開発の進捗状況の見える化

   さて最後の見える化対象は、「システム開発の進捗状況」だ。プロジェクト管理において、管理者がトップダウン的に作業指示を出し進捗状況を開発者から聞くというスタイルは、ソフトウェア開発をはじめとする「知的生産活動」には向いていない、というのが筆者の持論である。

   多くのシステム開発の現場で、問題の報告が遅れたり、遅れているのに順調に進んでいるような報告がされたりするのは、このコントロール型のマネジメントスタイルに問題がある。

   元来、ソフトウェアエンジニアという職種の人々は、「自分の技術を使って人に喜ばれるシステムを作り上げたい」という強い欲求を持っている。いいかげんな仕事をして、品質の悪いものでも納品できればよしなどと考えているプロフェッショナルなエンジニアは1人もいない。本来、エンジニアであれば誰しも、誇りを持って、良い品質のシステムを納めたいと思っているのだ。

   このモチベーションが出るように、現場をどのようにエンパワーするかが重要だ。管理者からの進捗の「プル」は、しばしば悪いニュースが現場から出てくる妨げとなる。往々にして悪いニュースは取り返しが付かなくなるまで、現場に隠れている。そうならないように、開発者からの進捗の「プッシュ」が必要だと考える。「私たちは現在、このような状況です」と責任を持って開発者が発信する、というスタイルに移行すべきなのだ。

   進捗状況について開発者から管理者へと自らプッシュされる状況を作るためには、様々な試みがある。ここでは当社の製品「TRICHORD(トライコード)」を用いた場合の例とそれらの具体的な試みを紹介する。

   TRICHORDは、システム開発の状況を「見える化」するツールである。単なる管理者のためのプロジェクト管理ツールではなく、開発者のための「見える化」ツールを目指したものである。管理者が「これを使え」というのではなく、開発者が「これを使いたい」と思えるようにデザインした。具体的には、現在3つのユニークなビューで見える化ができる。

前のページ  1  2   3  次のページ


株式会社チェンジビジョン 平鍋 健児
著者プロフィール
株式会社チェンジビジョン   平鍋 健児
代表取締役社長
1989年東京大学工学部卒業後、3次元CAD、リアルタイムシステム、UMLエディタJUDEなどの開発を経て、現在コンサルタントとしてオブジェクト指向とアジャイル開発を研究、実践中。アジャイルプロセス協議会副会長、要求開発アライアンス理事。翻訳書多数。


INDEX
第1回:「見える化」はなぜ必要か?
  「見える化」の目的
ソフトウェアの要求の見える化
  「かんばん」によるタスクの見える化