5 ソフトウェアテスト見積り精度の向上
93
情報量 部分的な情報 情報量
部分的な情報
／高いリスク
／高いリスク 最終的な規模 最終的な規模
データ項目数
ﾌｧﾝｸｼｮﾝ･ﾎﾟｲﾝﾄ数（ｺｰﾄﾞ･ﾗｲﾝ数）
情報の充実／
情報の充実／
低いリスク 低いリスク
誤差 誤差
類似ｼｽﾃﾑ
規模規模
要求機能 複雑さ
情報量 部分的な情報 情報量
部分的な情報
／高いリスク
／高いリスク 最終的な規模 最終的な規模
データ項目数
ﾌｧﾝｸｼｮﾝ･ﾎﾟｲﾝﾄ数（ｺｰﾄﾞ･ﾗｲﾝ数）
情報の充実／
情報の充実／
低いリスク 低いリスク
誤差 誤差
類似ｼｽﾃﾑ
規模規模
要求機能 複雑さ
図 5.2 前提があいまいな状況
5.2 見積り手法と継続的な改善
こちらもソフトウェアテストに限ったものではありませんが、見積り精度の向上のためには、
見積り手法・モデルを確立した後で、見積り予測値と実績値の違いの差異分析を通して、見積り 手法・モデルの改善を行う必要があります。また、このとき重要なのは、手法またはモデルの改 善だけでなく、プロジェクトマネジメントについても十分なチェックを行うことです。見積り値 が妥当であっても、プロジェクトマネジメントに失敗した場合は、改善すべき対象はプロジェク トマネジメントの方になります。
また、リスクの排除も重要な見積りと実績を一致させるために重要なポイントとなります。ソ フトウェアテストでは、採用するテスト技法、目標値、利用するツール、設計・実装工程段階に おける作り込み品質などが大きな変動要因となります。これらの変動要因が、「悪い」方向に変化 した場合、見積りでは予測していない事態が起こることは経験的に明らかです。変動要因の影響 を評価できない（状況がわからない）場合は言うまでもありませんが、リスクがわかった場合で も、そのぶれ幅を正確に予測することは難しく、逆にそのリスクを排除してぶれを除く努力をす る方が効率的と考えられます。
以下に見積り精度向上の手順について記載します。また、図 5.3 に見積り手法の構築からフィ ードバックまでのサイクルを示します。
（１）見積り手順の確立
組織で一貫した手順として見積り手順を確立する。
（２）見積りの実践
確立した見積り手順を実践する。また、見積り活動そのものではないが、見積りにあたっ て可能な限りリスクを明らかにするとともに、排除しておく。
（３）見積り結果（計画）と実績の差異分析
計画時の見積り結果とプロジェクト完了時の実績値との間の差異分析を通して、差異の根 本原因を特定する。
（４）差異分析結果のフィードバック
差異分析結果に基づいて改善対策を検討し、対策を展開する。差異分析の結果反映される 対象として、次の二つがある。
・プロジェクトマネジメントへのフィードバック
・見積り手順（見積り手法を含む）へのフィードバック
（５）共通要因に基づくプロセス改善
複数のプロジェクトで共通な課題を見積り、実績評価の繰り返しに基づき分析し、対策を 検討して、プロセス改善を展開する。
モデル改善 追加データ収集・改善
(1)(1)見積り手順見積り手順 の確立 の確立 組織としての確立 組織としての確立
・プロジェクトの課題の分析
・改善方針の提示
(4(4--1)1)ﾌﾟﾛｼﾞｪｸﾄﾏﾈｼﾞﾒﾝﾌﾟﾛｼﾞｪｸﾄﾏﾈｼﾞﾒﾝ ﾄへのﾌｨｰﾄﾞﾊﾞｯｸ ﾄへのﾌｨｰﾄﾞﾊﾞｯｸ (3)
(3)見積り結果（計画）と見積り結果（計画）と 実績の差異分析 実績の差異分析 (2)
(2)見積りの見積りの 実践 実践
個別プロジェクトでの実践 個別プロジェクトでの実践
(4
(4--2)2)見積り手順への見積り手順への ﾌｨｰﾄﾞﾊﾞｯｸ ﾌｨｰﾄﾞﾊﾞｯｸ
(5)
(5)共通要因に基づ共通要因に基づ くプロセス改善 くプロセス改善
組織へのﾌｨｰﾄﾞﾊﾞｯｸ 組織へのﾌｨｰﾄﾞﾊﾞｯｸ モデル改善
追加データ収集・改善
(1)(1)見積り手順見積り手順 の確立 の確立 組織としての確立 組織としての確立
・プロジェクトの課題の分析
・改善方針の提示
(4(4--1)1)ﾌﾟﾛｼﾞｪｸﾄﾏﾈｼﾞﾒﾝﾌﾟﾛｼﾞｪｸﾄﾏﾈｼﾞﾒﾝ ﾄへのﾌｨｰﾄﾞﾊﾞｯｸ ﾄへのﾌｨｰﾄﾞﾊﾞｯｸ (3)
(3)見積り結果（計画）と見積り結果（計画）と 実績の差異分析 実績の差異分析 (2)
(2)見積りの見積りの 実践 実践
個別プロジェクトでの実践 個別プロジェクトでの実践
(4
(4--2)2)見積り手順への見積り手順への ﾌｨｰﾄﾞﾊﾞｯｸ ﾌｨｰﾄﾞﾊﾞｯｸ
(5)
(5)共通要因に基づ共通要因に基づ くプロセス改善 くプロセス改善
組織へのﾌｨｰﾄﾞﾊﾞｯｸ 組織へのﾌｨｰﾄﾞﾊﾞｯｸ
•リスクの洗い出し•リスクの洗い出し
•リスクの排除•リスクの排除
（過去プロジェクトでの対策）
（過去プロジェクトでの対策）
•リスクの排除•リスクの排除
（将来プロジェクトへの対策）
（将来プロジェクトへの対策）
図 5.3 見積り精度向上の PDCA
5.3 契約によるリスク解消の糸口
5.3.1 見積りにおけるユーザ企業とベンダ企業の役割
見積りにおいて、ユーザおよびベンダのそれぞれの役割は以下のとおりです。
まず、ユーザはシステム開発におけるすべての意思決定の主体であり、機能要件や非機能要件 の内容は、ユーザが決定します。機能要件の内容や品質要件・技術要件などは、システムの規模 や開発の生産性を決定します。従って、システムの規模や開発の生産性は、ユーザ企業がコント ロールできます。
逆に、ベンダ企業側は、そのような要件をユーザ企業が判断・確認することをシステム開発の プロフェッショナルとしてサポートする必要があります。これは、ユーザ企業すべてがシステム 開発に慣れているわけでないことが背景にあります。例えば、非機能要件のうちシステムの技術 的難易度など、ユーザから見てシステム構築の知識がないと判断できないものは、ベンダのサポ ートが不可欠です。
ソフトウェアテストでは、システムテストや受入れテストなどの高位レベルのテストは主にユ ーザ企業が主体でベンダ企業と協力して行い、単体テストや統合テストなどの低位レベルのテス トをベンダ企業が主体でユーザ企業と協力して行うことが多いのが一般的です。3.4 節で記載し
95
ましたが、低位レベルテストのプロセスは高位レベルテストのプロセスと密接に関連しているの で、高位レベルテストの視点から低位レベルテストの目標を定めて、低位レベルテストのテスト プロセスを設計し、実施し、評価することが重要です。また、設計・実装工程段階で品質を作り こむ主たる責任はベンダ企業にあり、これは低位レベルのテストのみならず、高位レベルのテス トの量および生産性に大きく影響します。従って、ソフトウェアテストの見積りでは、ユーザ企 業とベンダ企業とが密接に協力して、テスト戦略を検討して、ユーザ企業およびベンダ企業相互 に合意することから始めます。テスト戦略で、ソフトウェアテストにおけるユーザ企業とベンダ 企業との役割および目標を明確にし、ソフトウェアテストの量や生産性に関してユーザがコント ロールする事項と、ベンダがコントロールする事項とを区分して、ユーザ企業とベンダ企業とが 相互に協力して、最終的なソフトウェアテストの工数またはコスト（ひいては価格）の低減や工 期の短縮を図ることができます。
5.3.2 変動要因に関するユーザ企業とベンダ企業の調整プロセス
要求される品質のレベルと同様に、ユーザ企業とベンダ企業との間で、個別のソフトウェア開 発プロジェクトでの変動要因のレベルをチェックして、今回のソフトウェアのテストは、個々の 変動要因の基準から、どの程度高いのか、低いのかを確認しあい、そのレベルに応じて生産性の 高低を評価し、見積りに反映することで、見積りの妥当性を確保する必要があります。これは新 規開発、改良開発にかかわらず、同じような取り組みが必要です (12)。
5.3.3 ソフトウェアテストの段階的な見積りと多段階契約の採用
多段階契約では、契約作業にかかわる手間は増大しますが、開発途中で発生しがちなソフトウ ェアテストの前提条件の変化を確認しつつ、その時点で明確になった部分の反映が可能であるた め、特に改造の影響範囲が不明確なシステムや高い信頼性を要求されるシステムを開発するプロ ジェクトに適しています。
図 5.4 に多段階契約と契約・再見積りのタイミング例を示します。
(12)SEC BOOKS「ソフトウェア開発見積りガイドブック」の「1.3.4 項(4) 変動要因に関するユー ザとベンダとの調整プロセス」を参照ください。
支援型契約 支援型契約 支援型契約 一括請負契約 支援型契約
再見積りのタイミング システム
化の方向 性
システム 化計画
要件定義 設計 実装 テスト
テスト戦 略立案
テスト戦 略見直し 詳細テス ト計画
テスト準 備および 仕様化
図 5.4 ソフトウェアテストに関する契約・再見積りのタイミング例
97