プロジェクト・マネジャーが知るべき97のこと/「見積り＝不幸の始まり」にしないために

　「マネジメントしやすいプロジェクト」とは、どういうプロジェクトでしょうか。私は、スコープやスケジュール、コストのベースラインがしっかり設定されていて、プロジェクト進行中にベースラインからの乖離が発生すれば、それが把握できてコントロールできるプロジェクトだと思います。鍵はベースラインです。ベースラインは、プロジェクトの計画段階で設定されます。ところが、設定するにあたっての制約事項や大枠は、プロジェクトが始まる前に決まっているのです。つまり、見積り段階です。プロジェクト・マネジャーは、どんなことを考えて見積りを行えばよいのでしょうか。

　まず、「何のために見積るか」を考えてみます。見積りの目的は 3 つです。1 つ目は、「注文を取る」、組織内なら「稟議を通す」ことです。見積りの結果、プロジェクトの開始に結びつけることが、第一の目的です。では、単に注文を取りやすい条件で見積ってよいでしょうか？　もちろん、これでよいはずがありません。目的の 2 つ目は、「適切な利益やコストを確保する」ことです。そのためには、見積りで提示する金額や期間が説明できて、納得してもらわなくてはなりません。統計や提唱されている見積りモデルなどのエンジニアリング的なアプローチを駆使して、論理的、合理的に説明できることが求められます。3 つ目は、「プロジェクトを成功に導く基盤を作る」ことです。これがプロジェクト・マネジャーにとって最も重要なことです。ソフトウェアの開発に仕様変更はつきものです。これをコントロールしやすい仕掛け、つまり、ベースラインをしっかり設定できているかどうかがプロジェクトの成否に大きく影響します。例えば、権威のある見積りモデルを使って算出した見積値により、2 つ目の目的である適正なコストが確保できていても、モデルに与えるパラメータが複雑で、プロジェクトの状況変化に応じて算出値の変化を説明できなければベースラインとして機能しているとは言えません。3 つの目的をすべて満たしている見積りが、よい見積りです。

　では、どう見積ればよいでしょうか。まず思い留めて欲しいのが、スコープとコストやスケジュールのベースラインの設定や変更に順序性があることです。スコープのベースラインが変更されたときに、コストやスケジュールのベースラインが変わります。したがって、見積りのときにも、以下のプロセスで作業を行えば、変更に強い見積りができます。

最終成果物で実現する機能を洗い出し、「何を作るか」を明確にする。
最終成果物に備える非機能要件のレベルを検討し、「どれぐらいのパフォーマンス」にするか明確にする。
最終成果物を作るための作業を定義し、「どう作るか」を明確にする。
「どう作るか」をもとに、「いくらかかるか」を明確にする。

　仕様変更があって 1 の作るものが追加されたり、2 の信頼性や性能などパフォーマンスの要件が変わると、3 の作業が追加されて工数が増え、4 の費用も増えます。実際の見積りの手順としては、概算見積りの段階では、1 の「何を作るか」は、あいまいな状態で機能やフィーチャーをブレークダウンしても定義し切れませんので、「どれぐらいの大きさのものを作るか」に置き換え、規模を見積ります。2 の非機能要件は、本来、成果物スコープに含まれるものですが、見積りでは 3 の「どう作るか」と合わせて、工数見積りに反映します。この段階では、WBS でのスコープ定義にも限界がありますので、こういう開発パターン、非機能要件のレベルなら生産性がどれぐらいになるかを想定して工数を算出します。4 では、算出した工数をもとに単価を設定して、売価やコストを見積ります。まとめると、見積りは、規模見積り→工数見積り→コスト見積りという順で整合性が取れていると変更管理もしやすくなります。とりわけ大事なのが、規模見積りです。これが成果物スコープのベースラインとして機能しないと、プロジェクトが混乱する要因となります。もともとの見積りからどう変わったかがわかるように、できる限り定量化して約束します。このときにポイントとなるのが、どういうメトリクスを使って定量化するかです。

非機能要件や実装形態など「どれぐらいのパフォーマンス」や「どう作るか」に左右されないメトリクスを使う。
計測ルールが明確で、ステークホルダー間で見積り結果を共有できるメトリクスを使う。
見積りからプロジェクト完了まで測定値に一貫性があるメトリクスを使う。

　ファンクションポイント法を使えば、上記の 3 つの条件を満たしますが、LOC（Lines of Code）を利用する場合も、機能要件を実現するために数ステップ、今回のプロジェクトは性能の要件が厳しいので数 % 増し、というように細かく約束した方が、要件が変わったときに対応しやすくなります。

　見積りでプロジェクトの命運が決まります。変更要求に対して、変更箇所と責任分担を明確にできる見積りがよい見積りです。