要件がなかなか収束しないことがある。ステークホルダーが多いほど,その傾向が強くなる。しっかりとした要求仕様書が無い場合も同様である。システムに対する要求が打ち合わせを重ねるたびに増加したり変化したりすることはもはや当たり前であるかのようである。ところが,そのような要求を実装してはみたものの,システムが完成した後でほとんどど使われることのない機能だったということも少なくない。プロジェクト・マネージャ(PM)たるもの,実装すべき要求とそうでない要求とを見極めた上で,要件定義を行う必要がある。

 Aさんは入社以来,プログラマからSEまで経験を積み,今回初めてPMとして抜擢された中堅技術者である。Aさんが担当することになったプロジェクトは,ある旅行会社の予約管理システムの構築であった。

 顧客から提出された要求仕様書はA4サイズで3~4枚程度しかなかった。しかも,かなり抽象的な要求事項が多かった。そこで,Aさんは要件定義フェーズを長めに取り,じっくりと顧客からの要求事項を引き出そうと考えた。

 要件定義フェーズには,全体開発の20%に当たる2カ月を割り当てた。何度かの打ち合わせを重ね,最初のレビューを迎えることになった。このレビューで顧客からは要件についての修正依頼と,新たな要求事項が出てきたのだった。Aさんとしては,それらの要求について精査を行い,次のレビューまでに要件定義書を修正した。しかし,次のレビューでは,前回レビューで指摘された部分以外の個所について修正依頼とさらに追加の要求事項が出てきた。

 その後,レビューを重ねるたびに新たな修正依頼と追加事項が出てくるようになった。それに対して,Aさんはその都度,内容の精査は行うものの,基本的にはそれらの要件を出来る限り取り込もうと調整したのだった。このシステムのステークホルダーが多岐にわたっており,それらのステークホルダー間の意見調整に時間を割くよりは,それぞれから出てきた要件を取り込んだ方が早いと考えたからである。

 しかし,その後もこの追加修正依頼と要件は一向に減ることはなかった。Aさんが精査した結果,なぜそんな画面が必要なのか?と思うような機能も多々含まれていた。それについて問い合わせても「素人には分からないだけ。必要なものは必要」といった具合で,次から次へと新規要件は増え続けたのであった。

 その結果,要件定義フェーズは,当初予定していた2カ月を超え,3カ月経過しても最終要件定義レビューが通過しないという事態に陥った。この事態を憂慮したAさんの会社は,要件定義フェーズをいったん打ち切り,顧客に対してはAさんを交代させるという提案をしたのだった。

ユーザーは自分の要求を正しく表現できない

 基本的に,ユーザーは自分が本当に必要とする要件について常に正しく表現できるとは限らない。つまり,ユーザーからの要求事項は絶対ではないということである。これについては,「オレゴン大学の実験」(C.アレグザンダ―・他著,B6判,203p,鹿島出版会,1977年12月)が有名である()。

図●オレゴン大学の実験
[画像のクリックで拡大表示]

 顧客が本当に必要だったもの,すなわち真の要求事項は右下の絵にある「木にぶらさがったタイヤ」である。それに対して,顧客が説明した要件は左上の絵にある「木にぶら下がった3段ブランコ」だった。つまり,顧客は自分が本当に必要であるものをそのまま伝えることができないないという例なのだ。その後,それを聞いたプロジェクト・リーダーは左上の2番目の絵ととらえ,以下,アナリスト,プログラマへと続き,結果としてプロジェクトは悲惨な状態になってしまう。

 これは,要求を伝えられない顧客が悪いのではない。人間は誰しも頭の中にあるものを正しく相手に伝えることが苦手なのである。このことをPMは常に意識しておく必要がある。そして,顧客の要望を100%信用するのではなく,真の顧客の要求とは何かを常に考える必要があるのだ。

要求は時間の関数

 次に注意すべきは「要求は時間の関数である」ということだ。Aさんの失敗例からも分かるとおり,時間をたくさんかけたからといって要求が集約するとは限らない。それよりは,むしろ発散する方向になりがちである。

 そもそも,要求とは時間の関数なのだ。つまり,要求は時間とともに変化してゆくのが普通なのである。これは,要求が顧客(要求を出す人間)の思いや考えをベースにしているためである。顧客(要求を出す人間)のそのときの考え方や立場,それを取り巻く環境が時間的に変化すれば,自然と要求も変化する。時間的な変化には,時間の推移とともに当初の要求そのものが変化するものと,当初の要求に追加して新たに要求が発生するものがある。

 Aさんの例は特別なのではない。何の管理もせずに要求を抽出しようとすると,どうしても修正要求や追加要求が出てくるものなのだ。PMたるもの,要件定義を行う場合には,時間管理を厳密に行い,その時間の中で何が出来るのかを考えた上で,要求を精査する必要がある。

すべての機能には理由がある

 最後に気を付ける点は,すべての機能には,なぜその機能が必要かという理由があるということである。システムに実現すべき顧客の要求事項には,必ず理由がなければならない。しかし,この要求に対する理由が要件定義書に記載されることはあまりない。

 要件定義書に規定した機能に対して理由を明記していないと,後になって「この機能はなぜ必要なんだろう?」となるのである。システム完成後ほとんど利用されることのない機能の多くは,要件定義フェーズでなぜ必要なのかという理由をあいまいにしたり,理由そのものが無かったりする場合である。

 この「理由」についてステークホルダー間できちんと協議・合意した上で,顧客からの要件を機能として取り扱い,かつその理由については明記すべきである。そうすることによって,本当に必要な機能を抽出する精度が格段に上がる。顧客からの際限無き要求を抑制する効果もある。

 PMたるもの,要求の持つ三つの性質を理解したうえで要件定義に臨むべきである。

要求の三つの性質
(1)ユーザーは自分の真の要求を正しく伝えられない
(2)要求は時間の関数である
(3)すべての機能(要求)には理由がある


上田 志雄
ティージー情報ネットワーク 技術部 共通基盤グループ マネージャ
日本国際通信,日本テレコムを経て,2003年からティージー情報ネットワークに勤務。88年入社以来一貫してプロジェクトの現場を歩む。国際衛星通信アンテナ建設からシステム開発まで幅広い分野のプロジェクトを経験。2007年よりJUAS主催「ソフトウェア文章化作法指導法」の講師補佐。ソフトウェア技術者の日本語文章力向上を目指し,社内外にて活動中。