さて、ここまでで要求定義技法についての解説は一通り終わりました。本連載「隠れた要求を見極める!」も、今回で最終回となります。ここで、これまでの連載の内容を振り返ってみましょう。
第1回ではまず、要求を定義するプロセスには以下の4つの段階があることを説明しました。
第5回の後半で3番目の「要求の仕様化」や、その後のシステム構築への連携などに少しだけ触れました。また今回は4番目の「要求の確認」について触れました。しかし、本連載のほとんどの部分は、要求定義の前半部分である「要求の抽出」「要求の分析・合意の形成」を中心に話を進めました。
それだけ、要求定義においてこれらのフェイズが重要だということなのです。この「要求の抽出」「要求の分析・合意の形成」をしっかり行うことの最大の意義は、
という状態を作り出すことです。
本連載の第2回〜第5回で、そのために役立つプロセスやツールを数多く紹介してきました。NTTデータが開発した要求定義方法論MOYAも、この部分にかなり重点を置いています。
特定の人だけがハッピーになるように要求抽出を行ってもプロジェクトメンバー間の合意は得られないでしょうし、多くのステークホルダーからばらばらの要求を抽出しただけでは収拾がつかないでしょう。このような状態ではステークホルダー間の合意は望むべくもなく、当然そのままシステム化したとしてもプロジェクトの成功はおぼつかないでしょう。
しっかりと共有化された目的はステークホルダー間での共通の価値基準となり、この目的はプロジェクトの軸となるのです。「新しい要求を出す」「今の要求を変更する」というアクションがあったとしても、そこで皆が立ち戻れる場所があるのです。細かな点で新しい要求は出てくるでしょうが、大きな意味での手戻りはないはずです。
「隠れた要求を見極める」ことの重要性を少しでもお伝えできればと連載を進めてきましたが、いかがだったでしょうか?
第1回で「ユーザーが欲しいのはシステムではない」と銘打って話をしましたが、一方でシステムをまったく使わずにビジネスを遂行することも現実的には考えられません。「ユーザーが欲しいのはシステムではない」の真意は、「システムは不要である」ということではなく、「ビジネスに寄与しない」システムは不要であるという意味です。もっと簡単な言葉で言い換えると、「役に立たない」システムはいらないということなのです。
つまり、「ユーザーが欲しいのは『役立つ』システムである」と言い換えることができます。
本連載のタイトルである「隠れた要求を見極める」ことによって、ステークホルダー間で目的を共有し、その目的に沿ったシステムを作ることこそが「ビジネスに寄与する」「役立つ」システムを作るということなのです。
実際のシステムを作るためには要求定義以外にも、システムアーキテクチャの選定、プロジェクトマネジメント、移行要件の検討など、さまざまな要素を勘案しなくてはなりません。本連載の内容だけでは良いシステムは作れません。
しかし、たとえ優れた人材を多く集め、多額の予算を確保したとしても、ステークホルダー間で「プロジェクトが達成する目的」が共有されておらず、「システムが目指すゴール」が明確でないプロジェクトが成功することはありません。
読者の皆さんが、本連載で紹介したプロセスやツールを用いることで「隠れた要求を見極め」、顧客に本当に満足してもらえる「役立つシステム」を提供されることを願ってやみません。
平岡 正寿(ひらおか まさとし)
株式会社NTTデータ 技術開発本部 ソフトウェア工学推進センタ 課長
筑波大学大学院教育研究科修了。
SIerやコンサルティング会社を経て、2004年NTTデータに入社。
当初、アーキテクト部隊に所属していたが、SIerにおける上流工程の重要性を強く意識し、MOYAのチームに参加。以降、MOYA自体をブラッシュアップするとともに、多くの現場で実践を続けている。
MOYAポータルサイト: http://www.nttdata-moya.jp/
Copyright © ITmedia, Inc. All Rights Reserved.