〜Planning Pokerで合意を形成し、リスクも考慮した精度の高い見積りを行う〜
はじめに
アジャイル開発では、短いイテレーションの中で頻繁に変更や調整が発生します。
そのため、「どの作業にどれくらいのテスト工数が必要か」を正確に見積もることが、プロジェクト成功の鍵になります。
この記事では、ISTQB Agile Tester Extension（Chapter 3.2.2）のテーマである
**「内容とリスクに基づくテスト工数の見積り」**について詳しく解説します。
1. テスト工数の見積りとは？
テスト工数（Testing Effort Estimation）とは、テスト活動に必要な
-
時間（Time）
-
コスト（Cost）
-
作業量（Effort）
を見積もることです。
たとえば、新しいユーザーストーリーをテストする場合、
テスト設計・実行・不具合修正確認などにかかる時間を事前に算出します。
見積りが正確であれば、
-
チームのスケジュールが安定し、
-
バックログ管理がスムーズになり、
-
遅延リスクの早期発見にもつながります。
2. アジャイルで使われる代表的な見積り手法「Planning Poker」
アジャイルでは、チーム全体で合意形成する見積り方法が重視されます。
その代表例が「プランニング・ポーカー（Planning Poker）」です。
● Planning Pokerの概要
Planning Pokerは合意形成型の見積り手法で、以下の流れで進められます。
-
**プロダクトオーナー（PO）**がユーザーストーリーを説明する
-
**各メンバー（テスター、開発者など）**がタスクの難易度を考え、
手元のカードで見積り値を出す
-
値は一般的に「フィボナッチ数列（1, 2, 3, 5, 8, 13, 21…）」を使用
-
各自が一斉にカードを出す（例：テスターA＝5、開発者B＝8など）
-
数値の違いが大きい場合は理由を話し合い、共通理解を得る
-
最終的に合意された値（ストーリーポイントや時間）を記録する
● 例：テストケース作成タスクの見積り
|
参加者 |
見積り値（ストーリーポイント） |
理由 |
|---|---|---|
|
テスターA |
5 |
既存機能に近く、テスト設計も再利用できる |
|
テスターB |
13 |
新しいAPIを含むため、未知の部分が多い |
|
開発者C |
8 |
開発側から見ると中程度の複雑さ |
話し合いの結果、**共通理解をもとに「8ポイント」**で合意する、という流れです。
3. 内容（Content）に基づく見積りのポイント
タスク内容に基づいて見積る場合、以下の要素を考慮します。
-
機能の複雑さ（Complexity）
-
テストデータ準備の難易度（Data Setup Effort）
-
自動化可能かどうか（Automation Feasibility）
-
関連モジュールとの依存関係（Dependencies）
例えば、単体テストレベルの作業よりも、
システム統合テストやユーザー受け入れテストでは、より多くの時間がかかります。
4. リスク（Risk）を考慮した見積りの重要性
単に内容だけでなく、「リスクの高い領域」は特に慎重に見積る必要があります。
● リスクを考慮する理由
リスクが高いタスクほど、
-
不具合が発生しやすい
-
検証範囲が広がる
-
想定外の手戻りが発生しやすい
そのため、テスト工数にも安全マージンを加味することが求められます。
● 例：リスクを考慮した見積り比較
|
タスク |
内容 |
リスクレベル |
見積り時間 |
|---|---|---|---|
|
ログイン機能のテスト |
既存コード修正 |
低 |
4時間 |
|
支払い機能のテスト |
外部APIとの連携あり |
高 |
12時間 |
同じサイズのタスクでも、リスクが高ければ見積り値も上がります。
5. チーム全体でのディスカッションの流れ
Planning Pokerや他の見積り手法では、
チーム全員が質問・議論できる場を持つことが重要です。
特にテスターは、
-
「このストーリーの期待結果は何か？」
-
「異常系テストも含まれるか？」
-
「自動テストは適用できるか？」
などを確認し、理解のずれを防ぎます。
見積りの過程で出た疑問や意見交換自体が、
チーム全体の知識向上や品質改善につながります。
6. 見積りの最終合意と記録
全員の見積りが一致すればその値を採用します。
もしバラつきがある場合は、話し合いを経て平均値や妥当な値を決定します。
最終的な見積りは、
-
プロダクトバックログに反映し、
-
イテレーション計画やバーンダウンチャートに活用されます。
7. まとめ
-
テスト工数見積りは「時間＋リスク」の両面で考える
-
Planning Pokerでチーム全体の合意を形成する
-
リスクを含めた議論を行うことで精度が向上する
-
見積りは単なる数字ではなく、チームの学習プロセスでもある
アジャイル開発では、
「正確な見積り」よりも「チーム全体で理解を深めるプロセス」が大切です。
🧩補足：他の見積り手法の例
-
T-Shirt Size法（S, M, L, XLで相対的に見積り）
-
バケットシステム（範囲ごとにグルーピング）
-
三点見積り（楽観値・悲観値・最確値の平均をとる）
✅ まとめの一言
アジャイルの見積りは「数字合わせ」ではなく、チームの理解と共通認識を作るための対話です。
コメント