なぜ見積りが重要なのか

システム開発には見積りがつきもので、これは慎重に取り組むべき業務とされています。なぜ見積りが重要なのでしょうか。細川氏は、「⁠トラブルの2大原因は、見積りの間違いと要求仕様未凍結にある」というRobert Glassの言葉を紹介しました。この2つは“⁠動き回る標的問題⁠”といわれ、互いに深く関連しあっています。

見積り作業には困難が伴います。その原因の1つとして、顧客企業とベンダーの思惑が大きく異なるという点があります。顧客企業としては、戦略的ビジネスに対応するシステムを構築したい思いがあり、仕様は段階的にしか決定できないが全体の予算だけは最初に決めたいと考えます。そうした中、ベンダーは先行事例がなく顧客企業との相互理解が不足した状態で見積りを提示しなければなりません。

また、見積り作業が、プロジェクトの現場ではなく会社経営層・マーケティング部門、顧客といったユーザー部門が担う、Political Estimationによって進行することが多いということもこの業務を難しくしている一因です。

見積りに“銀の弾丸”はない

実際に見積りを行う際、よく用いられるのが西洋的パラメトリックモデルです。

「アーロン法、COCOMO法、ファンクションポイント法など、さまざまなパラメトリック手法が存在しますが、いずれのパラメトリックモデルも“⁠数学的⁠”に計算式で算出されるだけで銀の弾丸ではありません。つまり、必要ではあるけれども、パラメトリック手法のみに頼るべきではありません⁠」⁠ と細川氏は訴えました。なぜなら、計算式で算出される数値には、不可能領域や非現実的領域が存在するからです。日本的に合意できる見積りとするためには、顧客に見積り額を算出するまでに至った経緯を“⁠感情面⁠”も考慮しながら筋道立てて説明できることが重要だといいます。

現実性の高い見積りを行うポイント

細川氏は、現実性の高い見積りを行うためのポイントとして以下の10項目を挙げました。

1. 見積りを実施する前に、前提条件と制約事項を明確にする
2. 複数の見積り手法を使用して見積りを行う
3. 過去のプロジェクトの実績データを使用する
4. 間接工数の見積りを行う
5. 実施した見積りを文書化する
6. 見積り後の検証を必ず実施する
7. 見積りとリスク／コンティンジェンシーを混同しない
8. 見積りと価格を混同しない
9. 開発中に繰り返し再見積りを実施する
10. 見積り値と実績値の分析を行う

この中でも特に強調したのは、2と4でした。複数の手法を使って見積ることで、その結果を比較して差異が生じた理由を分析・確認でき、見積りの抜けや漏れを発見できる効果があります。そして、出てきた見積りの結果に自信が持てるようになるといいます。また、直接工数しか見積り対象としていないケースも多いため、意識的に間接工数を洗い出す作業が必要だとのことでした。

見積り結果の検証も重要で、プロジェクト側で算出した金額を、品質保証部門がさかのぼって工数や規模を割り出す、あるいは“⁠技術要因とその他の要因の分離したか⁠”“⁠リスクファクターを明確化し、リスク算入ロジックを組み入れたか⁠”などの観点から振り返るプロセスを設けることを勧めました。 「⁠ぜひ若いテストエンジニアも積極的にプロジェクト計画段階から参画し、品質面からの見積りサポートに一役買ってください。見積りの歴史・既存知識を、これは本当に正しいのかと懐疑心を持ちながら学んでいくと、それがキャリアアップにもつながります⁠」⁠ と、細川氏は受講者の皆さんを鼓舞して講演を締めくくりました。