
見積もりの精度 Accuracy of Estimation
2008/3/6
昇進や解雇の対象になる可能性が最も高いのはいつか? 最も手に汗握るのはいつか? それは要件を把握できないときだろうか? それとも、ソリューションを設計するときだろうか? あるいは、コードを生成するときだろうか? いずれも違う。心臓が最もドキドキするのは、担当者が予測した予算、人員配備、納期に基づいてプロジェクトが最終承認されたときだ。
本記事は、IBM developerWorksからアットマーク・アイティが許諾を得て翻訳、転載したものです。 |
90%の精度でソフトウェアプロジェクトの実際のコストと納期を判断できるソリューションがあったらどうだろう。整合性のある「ソフトウェア開発ライフサイクルプロセス」に従い、プロセスを合理化および自動化するようデザインされたツールを用いることで、より多くのソフトウェアプロジェクトの時間内/予算内/期限内の納品が約束される。本当だ。
Galorath Incorporatedは「IBM Rational」パートナーであり、複雑なプロジェクトの計画や管理で政府や民間企業を支援するためのソリューションを20年以上前から開発してきた。同社の「SEERsolutions」は、直感的なインターフェイス、プロジェクトに応用可能な大規模知識ベース、非常に洗練されたプロジェクトモデリング技術、そして豊富なレポート作成機能を組み合わせてプランニングプロセスを素早く処理し、プロジェクトをスケジュール通りに走らせる。現在、政府各機関や経済誌の各種ランキング常連企業では、金融システム、航空機の運航、GPS、そして国際宇宙ステーションといったミッションクリティカルなプロジェクトをGalorathのSEERに依存している。
本稿は、ソフトウェア開発ライフサイクルのプランニングと管理のためのプロセスと技術を紹介する。
10段階の見積もりプロセス
- - PR -
確立され、実績もあり、開発プロセスとうまく統合された見積もりプロセスを適用することは、正確かつタイムリーなプランニング情報を提供することで、プロジェクトプランが信頼できるものであり、実現可能であり、顧客の期待に沿う、またはそれを上回り、ほかの管理活動を支援することを保証するのに役立つ。以下の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:パフォーマンスのトラッキング(測定値とフィードバック)
作業中の情報は継続的に収集し、当初の計画や基準と比較する。パフォーマンスが常時、もしくは大幅に変動する場合は、修正手段を評価およびインプリメントしてプロジェクトを軌道に戻す。パフォーマンスフィードバックも見直し、プロジェクトのデータを維持して見積もりプロセス自体を洗練させる。
見積もりの精度 Accuracy of Estimation
| Page1 10段階の見積もりプロセス |
|
| Page2 パラメトリック/予測モデリングツール |
|
| Page3 実際のプロジェクトモデリング:米社会保障局の10年 |
|
| Page4 Rational-SEER-Rational:ソフトウェア開発ライフサイクルの統合 |
The Rational Edge バックナンバー 連載インデックスへ»
- 第1回 要件仕様の決定に時間を割かない結末は?
- 第2回 先駆者に学ぶ「開発プロセス改善の原則」
- 第3回 あるプロジェクトリーダーの成功ストーリー
- 第4回 ソフト開発の変革というWebサービスの可能性
- 第5回 プロダクト・マネジメントを成功に導くには
- 第6回 分散コンピューティング時代のテスト手法
- 第7回 プロジェクトの特性に合わせた要件定義手法の選択
- 第8回 優秀なテスターの育成と訓練方法
- 第9回 「アジャイル」「RUP」「Rational XDE」の融合
- 第10回 Dr.ユースケースの “ユースケース人生相談”
- 第11回 Webサービスのテスト技法進化論
- 第12回 要件定義の考古学
- 第13回 チェスとソフト開発、その相関関係を探る
- 第14回 開発計画が破たんするには理由がある
- 第15回 要件定義の管理技術(Lv0〜Lv5)
- 第16回 オン・デマンドの波をキャッチしろ
- 第17回 オープンソース時代のテスト手法、そのノウハウ
- 第18回 オープンソース時代のテスト手法、テストのロードマップ
- 第19回 オープンソース時代のテスト手法、テストのまとめ
- 第20回 『オープン』の正体 (前編)
- 第21回 『オープン』の正体 (後編)
- 第22回 サブシステムの「なに?」「なぜ?」「どうやって?」
- 第23回 サブシステムとはモデリング概念である
- 第24回 アスペクト指向プログラミング オーバービュー
- 第25回 「プロジェクト管理」を管理するために
- 第26回 レッスン1:何もせずに取り残されるな
- 第27回 レッスン3:相違に注意を払え
- 第28回 大規模プロジェクトにアジャイルを適用する方法(前編)
- 第29回 大規模プロジェクトにアジャイルを適用する方法(後編)
- 第30回 アジャイル開発:成熟期の到来、その道のり
- 第31回 UML 2.0のキホン:コンポーネント図の詳細解説
- 第32回 コーディングの知恵を要件定義で利用する
- 第33回 隣のテストチームが優秀ないくつかの理由(前編)
- 第34回 隣のテストチームが優秀ないくつかの理由(後編)
- 第35回 中国のソフトウェア開発現場はこんなにスゴイ
- 第36回 ソフトウェア開発の「いま」と「近未来」の話
- 第37回 ルネサンスの巨匠たちに学ぶエンジニアリングの技
- 第38回 オブジェクト指向を超えて
- 第39回 ユーザー要件を引出すテクニック
- 第40回 ITプロジェクトを見える化する
- 第41回 ソフトウェアアーキテクチャって何なの?(前編)
- 第42回 ソフトウェアアーキテクチャって何なの?(後編)
- 第43回 ソフトウェアアーキテクトの役割
- 第44回 ソフトウェアアーキテクティングのプロセス
- 第45回 ソフトウェアアーキテクティングのメリット
- 第46回 ウォーターフォールから反復型への移行手順
- 第47回 トランザクション管理の複雑性を克服する パート1
- 第48回 トランザクション管理の複雑性を克服する パート2
- 第49回 汎用グラフィカルモデリング言語「SysML」 パート1
- 第50回 グラフィカルなモデル言語で製品構造を記述
- 第51回 キミのコードが汚い理由
- 第52回 「設計」や「構築」よりも重宝されるスキル
- 第53回 専門家に聞くモデル駆動開発のメカニズム
- 第54回 プロジェクトのはじめに計画を立てるのは無謀
- 第55回 「この開発プロジェクトは中止!」の基準
- 第56回 なるほど! ビジネスユースケース
- 第57回 そうだったのか! システムユースケース
- 第58回 不完全なコードは推敲フェイズで潰しておきたい
- 第59回 ビルドが全滅する原因
- 第60回 初歩の「Perl」「Python」「Ruby」
- 第61回 開発プロジェクトを「統治」するベストプラクティス
- 第62回 開発プロジェクト「統治」のピンポイント解説
- 第63回 反復開発の「ここはぜひカバーしたいポイント」
- 第64回 開発プロセス導入のアンチパターン
- 第65回 プロセスはチャンスが訪れるたびに改善する
- 第66回 自己管理型チームの利点と弱点
- 第67回 人事評価と開発者のモチベーション
- 第68回 鈍重な開発チームは鈍重なシステムを作る?
- 第69回 ソフトウェアが複雑なのは仕方がない?
- 第70回 ソフトウェアの複雑性を手なずける
- 第71回 見積もりの精度 Accuracy of Estimation
- 第72回 アジャイル開発の広範な普及を目指して
- 第73回 アジャイルとシステムテストの新たな関係(前編)
- 第74回 アジャイルとシステムテストの新たな関係(後編)
ホワイトペーパー(TechTargetジャパン)
|
|

