概要
本記事は『ソフトウェア見積もりガイドブック 品質要件に応じた見積もりとは』
の5章の要約です
テーマ
ソフトウェア見積もりの精度を向上させるには？
1.見積もりの前提条件のモニタリングとコントロール
2. 見積もり方法の継続的改善
3. 契約によるリスク解消
1.見積もりの前提条件のモニタリングとコントロールを行おう
なぜ前提条件のモニタリングが必要か。突然変わる場合があるからです。
見積もりの前提条件が後から変わるという問題
-
見積もりの前提条件が見積もりの後になって変わることがあります。前提条件が変わる状況は2種類に大別されます。
- 1.当初想定していた前提が状況の変化に伴い変わってしまう
- 2.そもそも前提が曖昧だった&実際のテストの段階で想定外の事象が顕在化する。(その結果、混乱)
-
前提条件の変化の具体例は以下の通りです。
- 後続テスト工程になって、先行テストでのテスト漏れが判明
- 設計および実装の遅延によりテスト期間が短くなる
- リグレッションテストが想定より不十分
- テストを実施しても欠陥が検出されない
- テストをしても想定の期間内に欠陥の量が収束しない。そのため、テストの期間とコストが増加
- このように見積もりの当初は情報量が少ないため、見積もりの誤差が大きくなりがちです。そのイメージは不確実性コーン(上述の資料より引用)で表現されます。
対処法
- まず、見積もりの前提条件が変わることによる見積もり結果の変動を、見積もりの計算方法で帳消しにすることは無理。
- それゆえ、できることは、以下の3つです。
- 見積もりの前提条件を明確にする
- それを関係者と共有する
- その上でモニタリングとコントロールを行う
2.見積もり手法の継続的改善
- 見積もり精度の向上のためには、実際の結果をもとにフィードバックループ(あるいはPDCAサイクル)をまわしていくことが必要である。
フィードバックループの手順
1.見積もりの計算方法の確立と計算
- ここでは、リスクの洗い出しとその排除を含む。リスクとはテストの工数に影響する変動要因が、当初の想定よりも悪い方向に変化するリスクである。
2.見積もりの予測値と実績の差異分析
3-1.見積もり手順へのフィードバック(モデル改善、追加データ収集)
3-2. プロジェクトマネジメントの方法へのフィードバック
(見積もりは正確だったが、プロジェクトマネジメントに失敗して遅延した場合)
3.契約によるリスクを解消
ここでの契約とは、ユーザーとベンダーの間のプロジェクトに関する契約。
テストをめぐるユーザーとベンダーの役割分担
-
要件の面での役割分担
- ユーザーは要件(機能と非機能)を決定する。
- その要件はテストの量と生産性に大きく影響する。そのため、ユーザーがテスト工数の大半を決める。
- 一方、その要件の決定のサポートをするのがベンダーである。ベンダーはシステム開発の知見があるため、実現可能性などの情報を提供する。
役割分担のイメージは以下の図
-
次に、テストレベルの面から役割分担を見てみる。
- 受け入れテストやシステムテストを主体となって進めるのはユーザーである。これらのテストは先行する単体テストの進め方などから影響を受ける。それゆえ、ユーザーが先行するテストの目標やプロセス設計を行い、ベンダーと合意をとるのが良い。
-
設計と実装の品質に責任を持つのがベンダーである。しかし、これはテストの量と生産性に影響する。それゆえ、ユーザーはベンダーとテスト戦略を検討し、相互に合意をとることが重要である。そのテスト戦略では、ユーザとベンダーの役割と目標を明確にし、テスト量と生産性についてユーザーがコントロールする部分とベンダーがコントロールする部分を明確に定義する。そうすることで、最終的にテストのコストの低減やスケジュールの短縮を図れる。
テストレベルの観点での役割分担と品質に関する責任のイメージは以下の図
-
変動要因に関するユーザーとベンダーの合意も重要。目標とする品質レベルだけでなく、テストの量と生産性への変動要因の中身を確認する。例えば、リグレッションテストの範囲が広いことをベンダーが確認したら、それをテスト見積もりに反映する。
イメージは以下の図
多段階契約によりテストの段階的な見積もりが可能
- たしかに多段階契約のデメリットとしては、契約作業の工数が増加することが挙げられる。しかし、メリットもある。開発を通して見積もりの前提条件が変わることを契約内容に織り込める。以下のような多段階契約は信頼性の高いシステムや、改修の影響範囲が見通せないシステムに向いている。
多段階契約と再見積もりのタイミングの一例は以下の図を参照
さいごに
豆腐メンタル系しくじりエンジニアは適切な見積もり方法を武装して心の平穏を保とう!!