【ISTQB /JSTQB ALTM 3.0解説】テスト見積もり技法の選定方法|ISTQB Test Manager v3.0解説

JSTQB Advanced Level Test Management 3.0

ソフトウェアテストにおける「見積もり(Estimation)」は、プロジェクトの成功を左右する重要な要素です。

特にテストマネージャにとって、「どの見積もり技法を選ぶか」は、スケジュールや品質、コストに直結する判断です。

本記事では、ISTQB Test Manager v3.0(Chapter 2.2.3)の内容に基づき、

「テスト見積もり技法の選定方法」をわかりやすく解説します。


🧩 テスト見積もり技法とは?

ISTQB Foundationレベルでも紹介されているように、テスト見積もりには大きく2種類のアプローチがあります。

1️⃣ メトリクスベース技法(Metrics-based Estimation)

過去のデータや統計情報を基に見積もる方法です。

例えば、以前のプロジェクトで「100件のテストケースに20時間かかった」という履歴データがあれば、

新しいプロジェクトのテスト件数からおおよその工数を予測できます。

代表的な例:

  • 比率ベース見積もり(Ratio-based Estimation)

  • 外挿法(Extrapolation)

2️⃣ エキスパートベース技法(Expert-based Estimation)

経験豊富な専門家の知見を活用して見積もる方法です。

過去の似たプロジェクト経験や製品知識を基に、チームで話し合いながら予測します。

代表的な例:

  • ワイドバンド・デルファイ法(Wideband Delphi)

  • プランニングポーカー(Planning Poker)

  • 三点見積もり(Three-point Estimation)


🧠 技法選定の前に考慮すべきポイント

テストマネージャが技法を選ぶ際には、以下の点をしっかり検討する必要があります。

1. 十分な情報・データがあるか?

メトリクスベース技法は、過去の履歴データが存在して初めて活用できます。

新しい組織や新規プロジェクトではデータが不足しているため、エキスパートベース技法の方が現実的です。

💡 例:

  • 組織に過去3年分のバグ件数・テストケース数が蓄積されている → メトリクスベースが有効

  • 新しい製品で履歴データがない → エキスパートベースが適切


2. 専門家(エキスパート)が社内にいるか?

エキスパートベース技法では、製品ドメインに詳しい人の意見が欠かせません。

もし経験豊富なテストリーダーや開発者がいない場合、この方法は難しいでしょう。

💡 例:

  • ベテランQAチームがいる → ワイドバンド・デルファイやプランニングポーカーが効果的

  • 経験者が少ない新規チーム → 定量データを活用するメトリクス型が向いている


3. プロジェクトの複雑さ(Complexity)

  • 低い複雑さ → データ分析中心のメトリクスベースが効率的

  • 高い複雑さ → チームで議論するエキスパートベースの方が柔軟に対応できる

💡 例:

  • 単純なアプリ修正 → 外挿法

  • 新機能を多数含むアジャイル開発 → プランニングポーカー


4. SDLC(開発ライフサイクル)の種類

  • ウォーターフォール型 → 計画段階で固定見積もりを出すため、メトリクスベースが適している

  • アジャイル型 → スプリントごとに変化するため、エキスパートベースで柔軟な再見積もりが必要

💡 例:

  • ウォーターフォール:過去データ+比率計算で全体見積もり

  • アジャイル:スプリント開始時にチームでポーカー見積もりを実施


5. 利用できる時間とリソース

一部の技法は、実施に時間とコストがかかります。

技法

所要時間

特徴

プランニングポーカー

チームで即時決定できる(アジャイル向き)

外挿法

正確だがデータ分析が必要

ワイドバンド・デルファイ

専門家間の意見調整が必要

プロジェクトの納期や予算を考慮し、「現実的に使える」技法を選ぶことが重要です。


🔁 見積もりは「一度きり」ではない

テスト見積もりは、プロジェクトの進行とともに更新されるべきものです。

新しい要件や変更が発生した場合、再見積もりを行うのは自然なことです。

💬 「見積もりを修正する=無能」ではありません。

むしろ、変化に対応して見積もりを再調整できるのが優秀なテストマネージャです。

ただし、頻繁な変更は混乱を招くため、情報が更新されたタイミングで計画的に行うのが理想です。


⚖️ テスト見積もりとプロジェクト全体のバランス

テストはプロジェクト全体の一部に過ぎません。

したがって、テスト見積もりも開発スケジュールや予算との整合性を取る必要があります。

テストマネージャは、作成した見積もりをプロジェクトマネージャへ提示し、根拠を説明します。

その上で承認を得ることが重要です。

💡 例:

「この範囲のテストを行うには200時間が必要です。もし100時間に削減する場合、カバレッジは70%に低下します。」

このように、見積もりは交渉と説明のツールでもあります。


🧮 具体的な技法の選定例

状況

推奨技法

理由

新規製品でデータなし

ワイドバンド・デルファイ

経験者の意見に基づく推定が有効

小規模・繰り返し案件

比率ベース見積もり

過去データの活用で効率的

アジャイル開発

プランニングポーカー

チーム全体の共通理解が得られる

精度を重視

三点見積もり

不確実性を平均化して精度向上

✅ まとめ

テスト見積もり技法の選定は、**「データ」「人材」「プロジェクトの性質」**に大きく依存します。

重要なのは、状況に応じて最適な方法を柔軟に選ぶことです。

🔹 データがあるならメトリクスベース

🔹 データがないならエキスパートベース

🔹 変化が多いなら柔軟な再見積もり

テストマネージャは、常に「なぜこの方法を選んだのか」を説明できる状態を保ちましょう。

コメント

タイトルとURLをコピーしました