テスト計画のロールプレイング

a.md

以下のロールプレイ形式で、実際のプロジェクトを想定し、テスト計画のスタートからゴールまで具体的な見積もり方法を解説します。

⸻

【ロールプレイ設定】 • あなた：テストマネージャー • 私：経験豊富な品質保証コンサルタント

システムの概要： • ECサイトの決済機能の新規開発。 • 納期は1ヶ月後。 • 開発チームは5名（フロント2名、バックエンド3名）。

⸻

Step1. テスト計画の立ち上げ

【あなた】

「ECサイトの決済機能のテスト計画を立てることになりました。見積もり方法を教えてください。」

【私（品質保証コンサルタント）】

「まず、テスト計画を立てるには次の順序で進めましょう。」 1. テスト対象範囲の決定 2. テストの種類とレベルの明確化 3. テストケース数の見積もり 4. 工数算出 5. 人員配置の決定 6. テスト計画の文書化

⸻

Step2. テスト対象範囲の決定

【あなた】

「まず何から始めればいいでしょうか？」

【私】

「新規に開発される決済機能の中でも、特にリスクが高い箇所や重要度が高い機能をリストアップします。 例えば、『クレジットカード決済』『PayPayなどQR決済』『エラー処理』などです。 ここで対象範囲を明確にします。」

⸻

Step3. テストの種類とレベルの明確化

【あなた】

「次は何をすればよいでしょう？」

【私】

「テストレベルとタイプを明確にしましょう。例えば以下のように決定します。」 • 単体テスト：開発者が担当。 • 結合テスト：バックエンドとフロントエンドの接続を確認。 • システムテスト：ユーザー目線で全体的な動作を確認（機能テスト、負荷テスト、セキュリティテストを含む）。

「これにより、テストタイプごとの人員や工数を見積もりやすくなります。」

⸻

Step4. テストケース数の見積もり

【あなた】

「実際のテストケース数はどのように算出しますか？」

【私】

「大まかな目安を考えます。 例えば： • クレジットカード決済機能：正常系5件＋異常系10件 • QRコード決済機能：正常系5件＋異常系5件 • エラー処理：異常系10件

合計で約35件と見積もります。」

⸻

Step5. 工数算出

【あなた】

「次に工数の算出はどうやりますか？」

【私】

「まず、テストケースごとに必要な平均時間を見積もります。 例えば、1テストケースあたり： • テスト準備：10分 • 実施と結果記録：20分 • 結果確認・報告：10分

合計で1テストケース40分とします。

35件×40分＝1400分（約24時間）と算出できます。」

⸻

Step6. 人員配置の決定

【あなた】

「実際に何人ぐらい必要になるでしょう？」

【私】

「ここでスケジュールが関わります。 納期は1ヶ月（約20営業日）ですが、テスト期間は一般的に納期の後半1週間～2週間程度です。 仮にテスト期間を1週間（5営業日）とすると、1人が1日にテストに費やせる時間を5時間とします。

1人の1日あたりのテスト可能時間 = 5時間（300分） 全工数 = 1400分 ÷ 300分 ≒ 4.6日（約5日間で1人で完了可能）

これにバッファ（予備日）20％を追加すると、約6日必要と考えられます。

結論として、1名がフルタイムで対応できれば間に合いますが、レビューや予備日を考慮すると、1〜2名が適切でしょう。」

⸻

Step7. テスト計画の文書化

【あなた】

「最後に文書化するポイントを教えてください。」

【私】

「次の内容をテスト計画書に記載します。」

テスト計画書

テスト対象範囲

• クレジットカード決済
• QRコード決済（PayPay等）
• エラー処理

テストの種類とレベル

• 単体テスト（開発者が実施）
• 結合テスト
• システムテスト（機能テスト・負荷テスト・セキュリティテスト含む）

テストケースと工数見積もり

機能	テストケース数	1ケースあたりの工数	合計工数
クレジットカード決済	15件	40分	600分
QRコード決済	10件	40分	400分
エラー処理	10件	40分	400分
合計	35件	-	1400分（約24時間）

リソース計画

• 期間：5営業日
• 必要人員：1〜2名

リスクと対策

• テスト環境トラブル → 予備日設定
• 人員不足 → サブ要員の事前確保

⸻

まとめ（ゴール）

【あなた】

「具体的でわかりやすかったです。この流れでテスト計画を進めます！」

【私】

「よかったです。このように順序立てて進めると、根拠のあるテスト計画が立案できます。」

⸻

以上が、テスト計画の具体的なスタートからゴールまでのプロセスおよび見積もり方法です。

b.md

以下に、テスト計画を進める際の実際のプロジェクト進行の続きを示します。

⸻

Step8. テスト計画の承認・共有

【あなた】

「作成したテスト計画書は、次にどのようなステップを踏めばよいでしょう？」

【私】

「作成したテスト計画は、プロジェクト関係者（PMや開発メンバー、顧客など）と共有し、承認を得る必要があります。」

具体的なステップ： • 関係者向けレビュー会の実施 • テスト対象範囲、工数見積もり、人員配置について理解してもらう。 • 指摘・修正の反映 • 意見があれば、適宜修正し、最終版を確定させる。 • 承認 • 計画書の正式承認を得ることで、その後のテスト実施フェーズに進む根拠とします。

⸻

Step9. テスト準備・環境構築

【あなた】

「承認が得られた後、どのようにテスト準備を進めますか？」

【私】

「次の準備作業を進めます。」 • テストケースを詳細に作成（入力データ、テスト手順、期待値など） • テスト環境の準備（テスト用データベース、サーバ、端末など） • テストツールのセットアップ（バグ管理ツール、テスト実行ツール） • テスト担当者への説明会・キックオフ

⸻

Step10. テスト実施フェーズの管理

【あなた】

「テスト実施の際に気をつけるポイントは何ですか？」

【私】

「実施フェーズでは、以下を管理します。」 • 進捗管理 • 日次でテスト進捗を把握（完了件数、未完了件数） • 障害管理 • 発見されたバグのトラッキング・報告・修正確認 • リソース調整 • 進捗遅れが生じれば、迅速に人員追加やスケジュール調整を検討する

⸻

Step11. テスト結果の評価と報告

【あなた】

「テストが終わったら、どうやって評価すればよいでしょう？」

【私】

「テスト結果を評価し、レポートを作成します。」 • 終了基準と照らしてテスト完了可否を判断 • 終了基準（例：重大バグがゼロ、テストケース完了率95%以上など）に達しているかを確認 • 残存バグ・リスクの明確化 • 残存するバグがある場合、運用上のリスクとその影響度を明記する • 最終テスト結果報告書の作成 • 実施テストの範囲、ケース数、障害発生状況、残存リスクを報告書にまとめます。

例：

テスト結果報告書

テスト実施結果概要

項目	内容
テストケース総数	35件
完了ケース数	35件
実施期間	2025/03/01〜03/05

障害発生状況

バグレベル	発生数	未修正
重大	0件	0件
中程度	3件	0件
軽微	5件	2件（運用許容）

残存リスク

• 軽微なUI表示のバグ2件が運用許容されましたが、決済処理自体への影響はありません。

テスト完了判断

終了基準を満たし、テスト完了と判断します。

⸻

Step12. テストプロセスの振り返り（Post-Mortem）

【あなた】

「最後に、このプロジェクトから次回以降に役立つような振り返りはどのようにしますか？」

【私】

「テスト終了後には振り返りを必ず実施しましょう。」

振り返りの視点： • テスト計画の精度（工数・スケジュール予測の妥当性） • 発生した問題と対応策の効果 • プロセスの改善点（テストケース設計・環境準備・進捗管理など） • 次回への推奨アクション

例：

プロジェクト振り返り報告書

良かった点

• テスト計画の見積もりが正確であり、計画通り完了した。
• 障害管理の徹底により、バグ修正の効率が良かった。

改善すべき点

• 軽微バグの確認が後半に集中したため、早期にテストを実施し確認する必要があった。

次回推奨アクション

• 軽微な障害の早期発見のため、前倒しで一部の機能をプレテストとして検証する。

⸻

ゴール（完了）

【あなた】

「一連の流れが理解できました。ありがとうございます。」

【私】

「お疲れさまでした。今回の一連のプロセスを繰り返し、徐々に精度を高めていくことで、効率的で質の高いテストプロセスが定着していきます。」

⸻

以上が、テスト計画のスタートからゴール、見積もり方法の具体的な実践ロールプレイの一連の流れです。

c.md

以下に、「明らかな見積もりの誤りがあった事例」と「その具体的なリカバリー方法」を紹介します。

⸻

事例①：テスト工数の見積もりが甘かったケース

状況： • 当初35件として見積もったテストケースが、仕様変更や詳細設計後の分析により、実際には70件に増加。 • 見積もりでは1週間で完了できると見込んでいたが、テスト期間途中で倍以上の工数が必要と判明。

問題： • 納期内の完了が困難。 • 人員不足、品質低下のリスク。

リカバリー方法： 1. 即時状況把握と報告 • まずはプロジェクト関係者に状況を迅速に共有する。 • 遅延のリスクと影響を明確に伝える。 2. 優先度に基づくテストケースの再評価 • テストケースの優先順位（必須・推奨・任意）を再設定し、クリティカルなケースから実施。 3. 追加リソースの確保 • 一時的に他プロジェクトのテスターを応援要員として調整。 • または外部委託を検討し、迅速に対応。 4. テスト期間の再調整（交渉） • 顧客またはプロジェクトマネージャーと交渉し、テスト期間を延長することで品質を担保。 5. 再発防止策 • 次回以降の見積もりでは、バッファを増やし、見積もり時点で仕様変更の可能性をより考慮する。

⸻

事例②：テスト環境の構築時間を見積もり漏れしたケース

状況： • テスト環境準備の工数を見積もりから漏らし、テスト開始時に環境構築で遅延。 • テスト開始が1週間遅れることが判明。

問題： • 開始遅延に伴うスケジュール全体の遅延リスク。

リカバリー方法： 1. 緊急のスケジュール調整 • 他の開発工程との同時並行を検討（部分的にテスト環境を優先的に構築し、順次テストを進める）。 2. 部分的なテスト環境の活用 • フル環境を待たず、優先度が高いテストから段階的に実施可能な環境を作り、効率よく進める。 3. リソース再調整 • 環境構築を専門的に行うエンジニアを一時的に投入。 4. 報告と透明性の確保 • 顧客に遅延の状況を即時報告し、信頼関係を維持。 5. 再発防止策 • 次回以降、テスト環境構築の作業工数を明確に計画書に記載。

⸻

事例③：テスターのスキルレベルを過大評価したケース

状況： • テスターのスキルレベルを高めに想定していたが、実際は経験が少なくテスト進行が予定より大幅に遅れた。

問題： • 品質低下および納期遅延のリスク。

リカバリー方法： 1. 経験者によるフォロー体制構築 • 経験豊富なテストリーダーがサポート役として即座に介入し、作業効率化を図る。 2. 作業再配分 • 難易度の高いケースは経験者へ、単純なケースは経験の浅いテスターへと再分配。 3. OJT形式の導入 • 作業をしながらトレーニングを兼ねることで、即時的なスキルアップを図る。 4. 再発防止策 • 今後のプロジェクトではテスターの実績・スキルレベルに基づく慎重な見積もりを行う。 • 必要に応じて事前トレーニング期間を設ける。

⸻

【リカバリー手順（まとめ）】

どの事例においても、リカバリー時の共通した考え方は以下です： 1. 問題の即時共有・透明性の確保 • 迅速な報告で遅延を最小化し、信頼関係を維持。 2. 優先順位の再評価と柔軟なリソース配置 • 工数を柔軟に再配分し、優先度の高いタスクにリソースを集中させる。 3. 代替案・バックアッププランの迅速な導入 • 部分的なテスト実施、他プロジェクトからの人員応援、外部委託を検討。 4. 顧客やプロジェクト関係者との協力体制の維持 • 課題解決をチーム全体の課題としてとらえ、協力を仰ぐ。 5. 再発防止の明確化 • 失敗から学び、次回の見積もり方法を改善（過去実績を活用、工数バッファを設けるなど）。

⸻

上記の方法で迅速にリカバリーし、また、次回以降の計画に反映させることで、安定したプロジェクト運営を実現できます。

d.md

以下のロールプレイを通じて、「見積もりミスによりテスト工数が大きく超過したが、リソース追加は見込めない」という現実的なシナリオで、具体的なテスト計画の修正からゴールまでの流れを紹介します。

⸻

【ロールプレイ設定】 • あなた：テストマネージャー • 私：品質保証コンサルタント

シナリオ： • ECサイトの新機能テスト。 • テスト期間はあと1週間。 • 見積もりは35ケースで完了と見込んでいたが、途中で仕様追加により合計70ケースに増加。 • リソース（人員）の追加は見込めない。

⸻

【あなた】

「テスト計画時の見積もりが明らかに誤っていました。テストケースが倍に増えていますが、リソースは追加できません。どのように対処すればよいでしょうか？」

【私（コンサルタント）】

「まず慌てず、現状を整理しましょう。リソースが限られている状況では、テスト計画を『再評価』して、『再計画』することが重要です。」

⸻

Step1. 現状の再評価（状況の可視化）

【あなた】

「具体的には、どう再評価しますか？」

【私】

「次のことを明確にします。」 • 残りのテストケース数（例：残り45件未完了） • 1ケースあたりの平均テスト時間（例：40分） • 残された稼働時間（1週間5日間、1日約5時間で25時間＝1500分）

「現状を計算すると、45件×40分＝1800分。利用可能な時間は1500分なので、明らかに時間が不足しています。」

⸻

Step2. テストケースの優先順位付け

【あなた】

「時間不足は理解しました。次の行動は？」

【私】

「現状をプロジェクト責任者（PM）に即座に伝えた上で、テストケースに優先順位をつけ、限られた時間内で何をやるべきか、改めて明確化します。」 • 優先度（高）：決済・注文確定などのクリティカルな処理（20件） • 優先度（中）：ユーザー体験に影響する範囲（15件） • 優先度（低）：管理画面・軽微な表示関連（10件）

⸻

Step3. 優先度の低いテストケースを調整（削減or簡略化）

【あなた】

「優先度をつけましたが、それでも間に合いません。どうしますか？」

【私】

「優先度『低』の10件は、リスクを関係者に説明し、以下のような対応を提案します。」 • テストケースを簡略化（代表的な2～3ケースのみ実施） • 場合によってはリリース後のモニタリングで対応（運用許容）

「優先度『中』の一部も、シナリオを統合し、効率化を図ります。」

⸻

Step4. テスト方法の見直し・効率化

【あなた】

「他に効率化できるポイントはありますか？」

【私】

「実施方法自体を効率化しましょう。」

例えば： • 類似テストケースをまとめて実施する（セットアップを共通化） • 探索的テストの導入（時間の許す限り複数ケースを柔軟に実施） • 詳細なドキュメント化を最低限に留め、結果はシンプルに記録する

「これらで1ケースあたりの工数を5〜10分ほど削減し、さらにテスト可能なケース数を増やします。」

⸻

Step5. 残存リスクの透明化と合意形成

【あなた】

「テストケースを削ると、品質への影響が気になりますが。」

【私】

「正確な情報をプロジェクト関係者・顧客に提供し、残存リスクを明確に伝え合意を得ます。」 • テスト未実施箇所が持つリスクと具体的影響を明示（例：『管理画面の軽微バグが残存する可能性あり』） • 顧客・PMとリリース条件を再調整し、透明性を確保する

⸻

Step6. 再計画書の提示（合意後）

【あなた】

「合意が取れたら、計画書はどう修正しますか？」

【私】

「再計画として、以下のように修正します。」

再調整版テスト計画書（修正版）

テストケース調整結果

優先度	当初件数	調整後
高	20件	20件（全件実施）
中	15件	10件（統合・簡略化）
低	10件	3件（代表ケースのみ）
合計	45件	33件

残存リスク

• 中優先度の5件は簡略化による若干の漏れリスクあり
• 低優先度7件はリリース後のモニタリングでカバーする方針

対策

• 効率化テスト手法（探索的テスト）を導入し、柔軟性を高める。

⸻

Step7. テストの実施（再調整計画）

【あなた】

「計画を再調整した後のテスト実施のポイントは？」

【私】 • 進捗をこまめに管理（朝夕で進捗確認） • 探索的テストを活用し、柔軟に品質リスクを抑える • 問題発見時、迅速に優先順位を再調整する

⸻

Step8. テスト結果の評価と完了報告

【あなた】

「テスト実施後の報告は？」

【私】 • 完了したテストケースと未実施ケースを整理 • 残存するリスク・バグの明示 • リリース許可判断のため関係者に最終報告を実施

⸻

Step9. 振り返りと再発防止策

【あなた】

「この失敗を繰り返さないための教訓は？」

【私】 • 見積もり時のバッファ増加（初期見積もりの20〜30％の余裕） • 仕様変更が発生した際のテストケース再評価を迅速に実施 • 優先順位を最初から厳密に設定しておくこと

⸻

ゴール（完了）

【あなた】

「リソース追加なしで、最も合理的な方法で品質リスクを抑えられました。」

【私】

「よく対応できました。この教訓を次回に活かしましょう。」

⸻

以上が、リソース追加が見込めない中で、見積もりの誤りをリカバリーする現実的なテスト計画プロセスです。