プロジェクト見積の進め方を理解しよう❷ | 精査の視点
itpjstudy
6回シリーズの第6回目です。以前の回でお話したように、4回を使って、プロジェクトのコスト構造を説明し、見積前提を決めるうえでの重要な要素について、理解いただきました。第5回目では、基本的な見積の流れを説明しました。今回は、最終回として、出てきた見積結果を精査する視点について、お話します。
見積は、実際にタスクが始まる前に実施しますので、仮説でしかありません。その仮説の精度を高めるために、色々な視点で精査することがとても大事です。
比較する
ボトムアップ見積との比較
前回説明した見積の流れは、ITパートナ持つ見積ツールを利用するものでした。
工数を大きく左右する要素を、重要な見積前提として定めて、大きく工数を見積するというやり方です。少ないインプットで効率よく工数を出すもので、「トップダウン見積」とも呼ばれます。
ただ、少ないインプットで見積を行うため、当たらずとも遠からずということが起きることも多いです。そのため、別の方法で、見積を精査することが必要になります。
そこで、実際のプロジェクトの場面を想像して、ひとつひとつ具体的な作業レベルで見積を行っていきます。トップダウン見積に対して、「ボトムアップ見積」と言われます。
例として、要件定義の工数精査の仕方を見てみましょう。
トップダウン見積では、対象業務や打合せすべき関係者数などの少ないインプットで、工数を計算します。一方で、ボトムアップ見積では、もう少し前提を細かく置いて見積もります。
この例では、1回あたりの検討会の工数を想定で置いたうえで、何人くらいが何回くらい参加する必要があるのかの想定を掛け合わせて、工数を積み上げます。
そうして出したボトムアップ見積の工数と、トップダウン見積の工数を比較します。差異が無ければ、算出された工数は妥当である可能性が高いです。差異が大きい場合は、その差異の原因を深掘りしていき、差異が小さくなるように、見積前提を変えていきます。
そうやって、見積の精度を高めていきます。
類似事例との比較
他の精査の仕方としては、類似事例の工数と比較するのも有効です。
完全に一致するような事例はなかなか無いと思いますが、近そうな事例を幾つか集めて、比較するだけでも、見えてくることがあります。
まずは、大きく、全体の工数を見比べた後、フェーズごとの工数や期間などの内訳を見て行きます。
差異があれば、それは見積前提の考え方の違いに起因するものです。そこを深掘りしていくことで、見積精査の視点を得ることができます。
このように見積の精査によって、プロジェクトに必要な金額の精度を上げていきます。ただ、精査以外の理由で、金額を調整したいときがあります。
例えば、ユーザ企業への提案で、競合他社に勝つために、金額を小さくしたい時などです。
金額調整は、見積前提の変更によって行う
提案に勝つために金額を下げる必要があるが、必要な工数を変えたくない場合は、ITパートナにとっての利益率を下げるというのが、よくある方法のひとつです。
しかし、ITパートナの事情として、利益率を下げられないときもあります。その場合は、工数を落とすしかありません。
ただ、その際に、絶対にやってはいけないのは、見積前提を変えずに、提案金額（＝工数）だけ落とすことです。やるべき作業内容は減っていませんから、必ず工数が足りなくなります。その結果、品質問題や遅延が発生してしまいます。
では、どういう調整を行うか。
作業対象を小さくすることを、ユーザ企業と調整する
まずは、金額を小さくするために、ユーザ企業と合意できそうな見積前提の変更を検討します。そのうえで、ユーザ企業に相談して、それが受け入れ可能かを確認して、金額を落とすようにします。
そうすることで、リスクを抱えずに、金額の削減をすることができます。
提案金額が大きくなり過ぎていので、何か打ち手を考えたいです。
例えば、業務の標準化を進めることで、開発プログラムの本数を減らすことはできないでしょうか。
プロジェクト費用が大きくなり過ぎるのは、ユーザ企業としても困ります。
業務の標準化は、簡単ではありませんが、実現効果も大きいと思います。是非その方向で考えてください。
役割分担の変更を、ユーザ企業と調整する
他の方法としてよくあるのは、役割分担の変更です。
こちらは、全体の工数は減らさないので、作業対象は変わりません。一方で、一部の役割が、ユーザ企業に移りますので、ユーザ企業で工数の確保が必要であることに納得して貰わなくてはいけません。
実は、更に金額を減らさないといけないと思っています。
現時点では、作業対象として、減らせるところは無そうです。そこで、システムテストのテスト実行について、一部、ユーザ企業側から工数を出して貰うことは可能でしょうか。
なるほど。システムテストのテスト実行で入ることは、ITメンバの新システム理解向上にも役に立ちそうなので、問題無いと思います。
ただ、大規模なシステムテストのテスト実行はやったことがないメンバなので、実行手順などは、しっかり準備して貰えますか。
このように、最後は、IT企業とユーザ企業との間で、見積前提や役割分担の調整を行って、最終的な提案金額（＝プロジェクト費用）を決定していきます。
6回シリーズの最終回でした。プロジェクト費用を見積もるためのポイントについて、大きな骨格はご理解頂けたでしょうか。
今回は、主にITパートナの目線でお話を進めてきましたが、ユーザ目線では、複数のITパートナに声をかけて、相見積を行うなどの打ち手が必要になってきます。また、プロジェクトが始まった後に、当初見積との乖離が発生することも多々あります。この辺りは、また別の機会にお話しできればと思います。
最後まで読んで頂き、ありがとうございました。ご意見・ご感想を頂けますと幸いです。
ITプロジェクト研究会
