ISTQB Test Manager（テストマネージャ）認定試験の「Chapter 2：Managing the Product」では、テスト見積もり（Test Estimation）に関する重要なテーマが扱われています。
この記事では、その中でも特に重要な 「2.2.2 テスト工数に影響を与える要因（Factors Influencing Test Effort）」 について、具体例を交えてわかりやすく解説します。
🔍 テスト見積もりとは？
まず前提として、テスト見積もり（Test Estimation） とは、
「あるプロジェクトやリリース、またはイテレーションで、テストを完了するために必要な作業量（工数）を予測すること」です。
たとえば、テストマネージャは次のような判断を行います：
-
どのくらいのテストケースを準備すべきか
-
どのくらいの人員・期間が必要か
-
自動化やツール導入によるコスト削減は見込めるか
これらを正確に見積もるためには、複数の要因（Factors） を考慮する必要があります。
🧩 テスト工数に影響を与える5つの主要要因
テスト工数に影響する要因は大きく以下の5つに分けられます。
-
プロダクト要因（Product Factors）
-
開発プロセス要因（Development Process Factors）
-
人的要因（People Factors）
-
テスト結果要因（Test Result Factors）
-
コンテキスト要因（Test Context Factors）
それぞれ詳しく見ていきましょう。
① プロダクト要因（Product Factors）
テスト対象のプロダクト自体が、見積もりに直接影響を与えます。
たとえば次のような要素です：
-
テストベースの品質（要求仕様書の明確さ・完全さ）
-
プロダクトの規模（画面数、機能数、データ量など）
-
ドメインの複雑さ（医療、金融、自動車など）
-
非機能要件（性能・セキュリティ・信頼性などの品質特性）
💡 具体例：
-
Eコマースサイトの場合：
主な機能は「商品検索」「カート」「決済」「配送」。
機能は多いが、ドメインリスクは比較的低い。
→ テスト工数は“中程度”。
-
**自動車の安全制御システム（Automotive Safety System）**の場合：
命に関わるため、ISO 26262などの安全規格に厳密に準拠が必要。
→ ドキュメント量・レビュー回数・テストレベルが増え、工数は“数倍”に。
結論：
「何をテストするか」が変われば、必要な労力もまったく違うのです。
② 開発プロセス要因（Development Process Factors）
次に重要なのが、どのように開発しているかです。
つまり、採用している SDLC（ソフトウェア開発ライフサイクル） やツール環境などが影響します。
-
開発モデルの種類（ウォーターフォール、アジャイルなど）
-
組織の成熟度（プロセスの安定性・標準化）
-
ツール・自動化環境の有無（CI/CD、テスト自動化、テスト管理ツールなど）
💡 具体例：
-
ウォーターフォール開発：
テストは開発後に一括実施されるため、期間が短く集中する。
→ バッファが少なく、再テスト対応も含める必要あり。
-
アジャイル開発：
テスターはスプリントごとに参加し、自動化と継続的テストが前提。
→ 準備段階では工数が増えるが、長期的には効率化。
③ 人的要因（People Factors）
チームのスキル・経験・モチベーションも大きな影響を与えます。
-
チームメンバーのスキルレベル
-
過去の類似プロジェクト経験
-
休暇・祝日などの人的リソースの変動
-
メンバーの定着率やモチベーション
💡 具体例：
-
経験豊富なQAエンジニアが多ければ、作業は早く正確。
-
しかし新人が多い場合、教育コストが増加し、見積もりは増加。
-
また、長期プロジェクトではメンバーの有給・体調不良も想定すべき。
結論：
「人はリソースではなく、変動する要素」。
テストマネージャは、チーム構成の変化を織り込んで見積もりを行う必要があります。
④ テスト結果要因（Test Result Factors）
意外に見落とされがちなのが、テスト結果そのものが工数に影響するという点です。
-
発見される不具合（Defects）の数と重大度
-
不具合修正後の再テスト（Retesting）・リグレッションテストの有無
-
バグトラッキング・報告作業の量
💡 具体例：
1つのテストケースが失敗した場合、次の作業が発生します：
-
不具合報告（Defect Logging）
-
修正確認（Retesting）
-
影響範囲の再確認（Regression Testing）
結果として、1つの失敗テスト＝約4倍の工数がかかることもあります。
つまり、不具合の多いプロジェクトほど見積もりは膨らむのです。
⑤ コンテキスト要因（Test Context Factors）
最後に重要なのが「コンテキスト（Context）」、つまりプロジェクトや組織の状況です。
-
チームの分散（オンサイト／オフショア）
-
開発拠点数や時差の有無
-
業界特有の規格やガイドライン
💡 具体例：
-
自動車業界（Automotive）：ISO 26262（安全性）準拠が必要
-
金融業界：PCI DSS（セキュリティ基準）対応が必要
-
医療分野：FDA認証やトレーサビリティ文書の維持が必須
このような規制・文化・チーム構造などの違いが、コミュニケーションコストやレビュー回数を増やし、結果的に工数を押し上げます。
🧮 テスト見積もりの精度を高めるポイント
-
過去プロジェクトの**履歴データ（Historical Data）**を活用する
-
チームのスキル分布と休暇計画を考慮する
-
失敗テスト時の再作業も見積もりに含める
-
プロダクトと開発モデルに応じて見積もりモデルを変える
✅ まとめ
|
要因カテゴリ |
主な内容 |
工数への影響例 |
|---|---|---|
|
Product |
規模・品質・ドメイン |
大規模・安全性重視の製品ほど工数増 |
|
Process |
SDLCモデル・ツール環境 |
自動化導入で初期工数増・長期削減 |
|
People |
スキル・休暇・経験 |
経験不足・離脱リスクで工数増 |
|
Test Result |
不具合数・再テスト |
失敗テストは最大4倍の工数 |
|
Context |
業界特性・拠点分散 |
法規制・時差で工数増加 |
💬 まとめのひとこと
テストマネージャが正確な見積もりを行うには、
「単なる数字合わせ」ではなく、全体の背景と影響要因を理解することが欠かせません。
プロジェクトの性質、チームの状態、そして品質目標。
これらを総合的に考慮して初めて、現実的で信頼できる見積もりができます。
コメント