見積もりの精度 Accuracy of Estimation：The Rational Edge（1/4 ページ）

ソフトウェアプロジェクト開発ライフサイクルの見積もりで、パートナーがソフトウェア開発組織をどのように支援するのか紹介する。

[Denton Tarbet（プロジェクト管理／プランニングコンサルタント），Galorath Incorporated]

　昇進や解雇の対象になる可能性が最も高いのはいつか？ 最も手に汗握るのはいつか？ それは要件を把握できないときだろうか？ それとも、ソリューションを設計するときだろうか？ あるいは、コードを生成するときだろうか？ いずれも違う。心臓が最もドキドキするのは、担当者が予測した予算、人員配備、納期に基づいてプロジェクトが最終承認されたときだ。

本記事は、IBM developerWorksからアットマーク・アイティが許諾を得て翻訳、転載したものです。

　90％の精度でソフトウェアプロジェクトの実際のコストと納期を判断できるソリューションがあったらどうだろう。整合性のある「ソフトウェア開発ライフサイクルプロセス」に従い、プロセスを合理化および自動化するようデザインされたツールを用いることで、より多くのソフトウェアプロジェクトの時間内／予算内／期限内の納品が約束される。本当だ。

　Galorath Incorporatedは「IBM Rational」パートナーであり、複雑なプロジェクトの計画や管理で政府や民間企業を支援するためのソリューションを20年以上前から開発してきた。同社の「SEERsolutions」は、直感的なインターフェイス、プロジェクトに応用可能な大規模知識ベース、非常に洗練されたプロジェクトモデリング技術、そして豊富なレポート作成機能を組み合わせてプランニングプロセスを素早く処理し、プロジェクトをスケジュール通りに走らせる。現在、政府各機関や経済誌の各種ランキング常連企業では、金融システム、航空機の運航、GPS、そして国際宇宙ステーションといったミッションクリティカルなプロジェクトをGalorathのSEERに依存している。

　本稿は、ソフトウェア開発ライフサイクルのプランニングと管理のためのプロセスと技術を紹介する。

10段階の見積もりプロセス

　 今日の大半のソフトウェア組織は、1）概算の／適当な見積もり、2）トップダウンの／制約主体の見積もり、3）ボトムアップの／設計主体の見積もりの中から最低1つをソフトウェアプロジェクトの見積もりに取り入れている。プランニングの手法に違いはあるが、これらのアプローチには、希少で非常に献身的な担当者と、手作業、あるいはスプレッドシートや各種自社開発ツールなどの最小限に自動化されたプロセスの有無に依存した1回限りの手法として実行される共通点がある。このような1回限りの手法は、当然矛盾しており、予測が不可能で、人為的ミスの影響を強く受けやすい。個々のプランニング担当者は多彩な才能とプロジェクトの経験を持っている。過度に楽観的であったり、悲観的であったりする。プロジェクトとは関連のない社内の政治的問題など、各種要因の影響を受けることもある。あるいは、プロジェクトの目立たない要素を単に見落とすこともある。

　確立され、実績もあり、開発プロセスとうまく統合された見積もりプロセスを適用することは、正確かつタイムリーなプランニング情報を提供することで、プロジェクトプランが信頼できるものであり、実現可能であり、顧客の期待に沿う、またはそれを上回り、ほかの管理活動を支援することを保証するのに役立つ。以下の10段階の見積もりプロセスは、20年以上にわたるソフトウェアの見積もりに関するベストプラクティスの研究に基づき、Daniel GalorathとMichael Evans（「Software Sizing, Estimation, and Risk Management」、2006年Auerbach Publishing刊）が開発したものだ。

ステップ1：見積もりの範囲と目的を確立する

　期待されるものを定義および文書化する。参加者全員が見積もりの範囲と目的を理解したら、矛盾のある仮定を明らかにし、将来変更があった場合の影響の測定基準を確立し、誤解が生じる可能性を阻止する。

ステップ2：技術基準、基本原則、および仮定を確立する

　見積もりに組み入れる機能を特定する。詳細な機能が分からない場合は、基本原則と仮定、そして見積もりに組み入れるものと入れないものを文書化する。民生利用（COTS）や再利用などの各種仮定も文書化しておく。

ステップ3：データ収集

　必要なデータとその情報の持ち主を特定する。質問と明確な定義をあらかじめ参加者に提供しておく。インタビュー中は、データが現実的で妥当かを確認する。プロジェクトの履歴レポジトリを構築して参照し、不確実なものを確実に把握する。

ステップ4：規模と範囲の決定

　状況によって見積もり手法の妥協を余儀なくされる場合は、許される時間の大半をプロジェクト規模の判断に費やす（このプロセスは規模判断用データベースやツールを利用すると円滑に進む）。これは、プロジェクトの最終的な成功を決める恐らく最も重要なステップだ。規模や範囲を決定すると、プロジェクトの各部分が決まってくるが、製品の開発やアップグレードのための作業が制約を受け、選択肢が限られてくる。

ステップ5：見積もり基準の用意

　プロジェクトの見積もりは一度限りの作業だと考えてはならない。プロジェクトが進行すると、分からないものが分かり、新しい想定外の問題やチャンスが出てくる。何が起こるかは分からない。開発プロセスを通じて見積もりを見直し、誤差を文書化することで、1）徐々に信頼性を高めたデータに基づくトレードオフの評価、2）その時点で「最も正確な」見積もり、そして3）時間の経過に伴う見積もり精度の向上が保証される。

ステップ6：品質リスクとリスク分析

　リスクは、時間、品質、お金、コントロール、あるいは理解の喪失で表すことができる。リスクに関連した喪失はリスク影響と呼ばれる。リスクを排除することはできないが、それを考慮に入れておくことはできる。タイミングよく認識し、取り組んでおけば、リスク自体がプロジェクトの成功を脅かすことはない。

ステップ7：確認とレビュー

　見積もりの確認とレビューを行うことで、見積もりの整合性を系統的に確認できる。この手順では、組織が先を見越してプロジェクトの可変要素を調整し、プロジェクトのデータが妥当で、手法が効率的で、予想される結果が正確で、焦点が適切に定まっているとの確信を証明できるようになる。

ステップ8：プロジェクトプランの作成

　プロジェクトプランの作成では、詳細な機能・タスク指向の作業分解構造で、特定のコスト、リソース、適時性の割り当てと伝達を行うためにプロジェクトの見積もりをたたき台にする。

ステップ9：見積もりと教訓の文書化

　見積もりの完成時、更新時、そしてプロジェクトの完成時には、適切であることが分かった情報と、プロジェクトから得られた教訓を必ず文書化する。そうすることにより、「最善努力」プロセスを文書化し、見積もりモデルの調整に利用できる実結果が獲得できる。

ステップ10：パフォーマンスのトラッキング（測定値とフィードバック）

　作業中の情報は継続的に収集し、当初の計画や基準と比較する。パフォーマンスが常時、もしくは大幅に変動する場合は、修正手段を評価およびインプリメントしてプロジェクトを軌道に戻す。パフォーマンスフィードバックも見直し、プロジェクトのデータを維持して見積もりプロセス自体を洗練させる。