顧客の要望から、プロジェクトはスタートするといっても間違いではないだろう。とはいえ、どこまで顧客の追加要求を受け入れるべきなのだろうか。そうした点を解説する。
プロジェクトマネジメントで最も重要な課題は、
の2点であると解説しました。これらの内容については、前回の「プロジェクトマナージャは、説得術を磨くべし」をお読みください。
さらに1つ目の課題の対応策として、大別して下の5通りの方法が存在することをお伝えしました。
今回は、5の追加要求の影響を最小化、かみ砕いていえば「お客さまから無茶なことをいわれたときの対応」について、実務上のポイントをお伝えいたします。
顧客からのシステム要件の追加要求は、プロジェクトへさまざまな影響を与えます。代表的な例として、以下が挙げられます。
いずれもありがちな話です。だからといって放置するわけにもいきません。何らかの対応が必要なのは明らかですが、対応を間違えればプロジェクトの崩壊を招くほどのインパクトがあるものです。
それでは、上記の追加要求はどのようなインパクトがあるでしょうか。
例えば、スケジュールへの影響が出た場合、1日や2日程度であれば取り戻すことはさほど難しくありません。ところが、それが1週間、2週間となった場合、それを取り戻すことは難しくなります。プロジェクトは通常、人員に空きが生じないようにぎりぎりの人数で組まれているからです。
あるいは、仕様変更や作業範囲の変更があった場合などの影響を想像してみてください。十分な期間もなくそのような変更を要求されれば、せっかく現在までテスト済みであったコードまで、新しい仕様に合わせてテストをやり直す必要が出るかもしれません。
それどころか、「いままで固めてきた仕様が、まったく役に立たなくなった」などということが起きてしまえば、プロジェクトそのものがなくなることすらあり得るのです。
よって、追加要求に対してプロジェクトマネージャは慎重に対応する必要があります。
とはいえ、きちんと追加の要求をさばけなかったためにプロジェクトで大赤字が出てしまったといった話はあまりあるほど存在します。プロジェクトマネージャにとって、追加要求にいかにうまく対応するかは死活問題なのです。
それでは、プロジェクトマネージャはどうすればよいのでしょうか。ここでは1つ、本質にさかのぼって考えてみましょう。すなわち、「要件定義とは何か」を知ることで、追加要求をうまくさばく術を見いだそう、というわけです。
要件定義という言葉を調査したところ、各種の文献により多少の表現の相違がありますが、大まかには、次の表のようになります。
情報システムの信頼性向上に関する評価指標の定義
PMBOKの用語集のプロジェクト・スコープの定義
ISO 10006(品質マネジメントシステム−プロジェクトにおける品質マネジメントの指針)の定義
その他の理解関係者を特定し、それらのニーズを確立するとよい。それらのニーズは、文書化された要求事項に変換し、関連ある場合には、顧客の同意を得るとよい
いかがでしょうか。「要件定義」という言葉も、「プロジェクト管理」という言葉と同じくらい、さまざまに解釈されていることが分かります。
よって、当然何が正しく、何が間違っているという議論はできないのですが、トーマツイノベーションにおいては、次のような意味で「要件定義」という言葉を用いています。
要件定義とは以下を実行することである。
端的にいえば、要件定義とは「絞り込むこと」です。ここまでくると、勘のよい方は追加要求の正体に気付くかもしれません。なぜ、追加要求が発生するかです。ひと言でいえば、次のようになります。
「追加要求は、顧客の要求の絞り込みを十分に行っていないために発生する」
顧客が、「われわれがやりたいことを実現するには、ほかにも機能が必要なのでは」、と思うからこそ追加の要求が出てくるのです。
もう少し、詳しく見ていきましょう。要件定義は通常、次のようなプロセスを通って行われます。
要件定義の根幹に位置するのは、顧客のやりたいことです。当たり前のことですが、顧客は何かやりたいことがあるのでシステム開発の依頼を出すのです。
よって追加要求をできるだけ減らすには、要件定義プロセスの最初の段階において「やる」「やらない」「後でやる」をしっかりと決めなければならないのです。
Copyright © ITmedia, Inc. All Rights Reserved.