顧客の膨らむ要望にいかに対処すべきか：やる気を引き出すプロジェクト管理（6）（1/2 ページ）

顧客の要望から、プロジェクトはスタートするといっても間違いではないだろう。とはいえ、どこまで顧客の追加要求を受け入れるべきなのだろうか。そうした点を解説する。

[安達裕哉，トーマツ イノベーション]

プロジェクト管理で最も重要な課題

　プロジェクトマネジメントで最も重要な課題は、

1. 「『成果の設定（仕様の確定）』と『仕事の設計（作業の洗い出しとスケジュール化）』は不確実である」というリスクへの対応
2. プロジェクトが「うまくいっている」「うまくいっていない」の判断

の2点であると解説しました。これらの内容については、前回の「プロジェクトマナージャは、説得術を磨くべし」をお読みください。

　さらに1つ目の課題の対応策として、大別して下の5通りの方法が存在することをお伝えしました。

1. 客に要件定義を依頼
2. 契約の見直し
3. 「成果の設定」「仕事の設計」の精度向上
4. 関係者への説得・承諾
5. 追加要求の影響を最小化

　今回は、5の追加要求の影響を最小化、かみ砕いていえば「お客さまから無茶なことをいわれたときの対応」について、実務上のポイントをお伝えいたします。

お客さまからの追加要求の影響

　顧客からのシステム要件の追加要求は、プロジェクトへさまざまな影響を与えます。代表的な例として、以下が挙げられます。

1. スケジュールの変更
2. 設計・仕様変更
3. 作業範囲変更
4. 見積もり変更
5. 運用変更
6. プロジェクト目標の変更

　いずれもありがちな話です。だからといって放置するわけにもいきません。何らかの対応が必要なのは明らかですが、対応を間違えればプロジェクトの崩壊を招くほどのインパクトがあるものです。

追加要件の影響が大きい場合のリスク

　それでは、上記の追加要求はどのようなインパクトがあるでしょうか。

　例えば、スケジュールへの影響が出た場合、1日や2日程度であれば取り戻すことはさほど難しくありません。ところが、それが1週間、2週間となった場合、それを取り戻すことは難しくなります。プロジェクトは通常、人員に空きが生じないようにぎりぎりの人数で組まれているからです。

　あるいは、仕様変更や作業範囲の変更があった場合などの影響を想像してみてください。十分な期間もなくそのような変更を要求されれば、せっかく現在までテスト済みであったコードまで、新しい仕様に合わせてテストをやり直す必要が出るかもしれません。

　それどころか、「いままで固めてきた仕様が、まったく役に立たなくなった」などということが起きてしまえば、プロジェクトそのものがなくなることすらあり得るのです。

無茶な追加要求はプロジェクトマネージャの悩みの種

　よって、追加要求に対してプロジェクトマネージャは慎重に対応する必要があります。

　とはいえ、きちんと追加の要求をさばけなかったためにプロジェクトで大赤字が出てしまったといった話はあまりあるほど存在します。プロジェクトマネージャにとって、追加要求にいかにうまく対応するかは死活問題なのです。

要件定義とは何かを知る

　それでは、プロジェクトマネージャはどうすればよいのでしょうか。ここでは1つ、本質にさかのぼって考えてみましょう。すなわち、「要件定義とは何か」を知ることで、追加要求をうまくさばく術を見いだそう、というわけです。

　要件定義という言葉を調査したところ、各種の文献により多少の表現の相違がありますが、大まかには、次の表のようになります。

情報システムの信頼性向上に関する評価指標の定義

• 具体的な要求事項（機能要件、非機能要件）を文書化し、双方で承認すること

PMBOKの用語集のプロジェクト・スコープの定義

• 規定された特性や機能をもつプロダクト、サービス・財産等を生み出すために実行しなけれならない作業

ISO 10006（品質マネジメントシステム−プロジェクトにおける品質マネジメントの指針）の定義

• 製品並びにプロセスに対する顧客のニーズ及び期待は、明示されたもの及び通常暗黙のうちに了解されているもののいずれも、法令・規制の側面を含めて、文書化された要求事項に変換し、顧客の要求があるときには、相互に合意するとよい。

その他の理解関係者を特定し、それらのニーズを確立するとよい。それらのニーズは、文書化された要求事項に変換し、関連ある場合には、顧客の同意を得るとよい

表1　いくつかの要件定義にまつわる定義

　いかがでしょうか。「要件定義」という言葉も、「プロジェクト管理」という言葉と同じくらい、さまざまに解釈されていることが分かります。

　よって、当然何が正しく、何が間違っているという議論はできないのですが、トーマツイノベーションにおいては、次のような意味で「要件定義」という言葉を用いています。

　要件定義とは以下を実行することである。

1. 顧客のあいまいな要求を把握
2. 本プロジェクトでやれることを決定
3. システムの機能要件・比機能要件への落とし込み
4. 要件定義書（仕様書）の作成と合意

　端的にいえば、要件定義とは「絞り込むこと」です。ここまでくると、勘のよい方は追加要求の正体に気付くかもしれません。なぜ、追加要求が発生するかです。ひと言でいえば、次のようになります。

　「追加要求は、顧客の要求の絞り込みを十分に行っていないために発生する」

　顧客が、「われわれがやりたいことを実現するには、ほかにも機能が必要なのでは」、と思うからこそ追加の要求が出てくるのです。

　もう少し、詳しく見ていきましょう。要件定義は通常、次のようなプロセスを通って行われます。

お客さまのやりたいことを分類することが大事

　要件定義の根幹に位置するのは、顧客のやりたいことです。当たり前のことですが、顧客は何かやりたいことがあるのでシステム開発の依頼を出すのです。

　よって追加要求をできるだけ減らすには、要件定義プロセスの最初の段階において「やる」「やらない」「後でやる」をしっかりと決めなければならないのです。