システムは出来上がったのに役立たず？――「上流設計」を考える（2/2 ページ）

ITが経営に対する貢献を求められている昨今、「要求」を決めるプロセスの重要性が増している。「システムは出来上がったが役に立たない」という結果を招かないためには、どうすればよいか？

[増田克善，アイティセレクト編集部]

業務要件を要素分解するところから始める

　要件定義品質に問題がある背景には、第一に概念的な戦略や構想が上流工程において、具体的なシステム機能や要件にブレークダウンされないまま開発作業を進めてしまうケースがあることだ。そうした場合、詳細要件を詰める段階になって要件に矛盾が起きたり、大幅な変更が必要になるなど、プロジェクトの遅れにつながるトラブルが発生しやすい。

　また、ユーザー部門の要求の本質をシステム部門が正しく理解できていないという問題もある。ユーザーの要件を十分に把握しないままシステム開発を行うと、受け入れテストの段階で問題が発生する危険性がある。

　では、要件定義の品質を上げるためには、どのような方法論を用いるべきか。業務要件は、会社の組織構造や業務形態に深く関係する部分が多いため、その定義プロセスに単一の方法論を適用できるほど容易ではないだろう。そこで業務要件を要件構成要素に分解して、それぞれの関係を体系化するところから始めるとよいとされる。

　業務要件の構成要素は、「目的」「手段」「リソース」「プロセス」の四つに分類できる。目的はあるべき姿であり、手段はその達成に必要な施策だ。手段を実行するためには、社内外のリソースを利用する必要があり、それをどう組み合わせて実行するかを定義するのがプロセスである。また、こうした要素に影響を与えるものとして、外部環境要因・内部環境要因がある。

　それらの環境要因を反映させながら、四つの要件要素に分解していく作業こそが要件定義といえる。

（「月刊アイティセレクト」2007年4月号のトレンドフォーカス「事業戦略とシステム構築を融合させる『上流開発』の新発想」より）