検証
リリース前に「何を」「どう」「どこまで」検証するかを定義します。
成功基準を明確にすることで、品質を担保します。
なぜ検証計画が必要か
よくある失敗パターン
- • 「テストしました」の基準が曖昧で、重大なバグが見逃される
- • 発注者が期待していた動作と、実装された動作が違う
- • リリース直前に「これもテストしないと」が発覚
- • 誰がOKを出せばリリースできるのか不明確
検証計画を事前に定義することで、「何がOKならリリースできるか」が明確になります。 スコープに入った各ユーザーニーズに対して、検証方法と成功基準を設定します。
入力する項目
検証対象
スコープに入ったユーザーニーズが自動で検証対象になります。
例
- • 商品を素早く検索して見つけたい（月間45,000回）
- • カートを途中保存して後で購入したい（月間12,000回）
- • お気に入り商品の在庫復活を知りたい（月間2,000回）
検証方法
どのように検証するかを記述します。
検証方法の種類
- 自動テスト: ユニットテスト、E2Eテスト
例: Playwright で検索→商品詳細→カートの一連の操作を自動テスト
- 手動テスト: QAチームによるシナリオテスト
例: テストケース50件を2人で実施、所要時間8時間
- ユーザーテスト: 実ユーザーによる検証
例: ペルソナに近いユーザー5名で60分のユーザビリティテスト
- パフォーマンステスト: 負荷テスト、速度測定
例: 同時1,000ユーザーで応答時間1秒以内を確認
成功基準 ⭐ 重要
「何がOKならこの検証は合格か」を具体的に定義します。
良い成功基準の例
- ✓ 検索結果が1秒以内に表示される（P95）
- ✓ 検索→購入完了のE2Eテストが100%パス
- ✓ ユーザーテストで「商品が見つけやすい」評価が4.0以上（5点満点）
- ✓ 重大度「高」のバグが0件
悪い成功基準の例
- ✗ 「問題なく動くこと」← 何が「問題なく」か不明
- ✗ 「使いやすいこと」← 誰がどう判断するか不明
- ✗ 「バグがないこと」← 全てのバグは検出不可能
結果チェック担当
誰が最終確認してOKを出すかを明記します。
例
- • 自動テスト: CI/CD で自動判定
- • 手動テスト: QAリーダー 田中さん
- • ユーザーテスト: PDM 山田さん
- • 最終承認: 発注者 佐藤部長
Claude Code での操作例
あなた
「toishiに検証計画を追加して。 商品検索機能のE2Eテスト、成功基準は検索結果1秒以内と100%パス」
AI
検証計画を追加しました。
【検証対象】商品検索機能
【検証方法】E2Eテスト（Playwright）
【成功基準】
- 検索結果表示: 1秒以内（P95）
- テストパス率: 100%
結果チェック担当を設定しますか？例えば「QAリーダー」など。
承認のポイント
承認者はここをチェック
- ✓ スコープに入った全てのニーズに検証計画があるか
- ✓ 成功基準が具体的で測定可能か
- ✓ 検証に必要な工数・期間が見積もられているか
- ✓ 結果チェック担当が明確か
- ✓ ユーザーテストが必要な場合、ユーザー手配の計画があるか
ベストプラクティス
開発前に検証計画を立てる
開発後に「どうテストしよう」では遅い。 要件定義の段階で検証方法を決めておくと、実装の方針も明確になります。
自動化できるものは自動化する
E2Eテスト、パフォーマンステストは自動化して CI/CD に組み込む。 手動テストはユーザビリティなど、人間の判断が必要な部分に集中させます。
「NG時のアクション」も決めておく
成功基準を満たさなかった場合どうするか？リリース延期？部分リリース？ 事前に決めておくと、判断がスムーズになります。
発注者も検証に参加してもらう
最終的に「これでOK」を出すのは発注者。 ユーザーテストや受け入れテストに参加してもらい、期待と実装のギャップを早期に発見します。
なぜこの設計なのか
受入基準から自動導出 — テスト計画を後から考えると漏れる
開発後に「どうテストしよう」では、重要なテストケースが漏れます。 ユーザーニーズの受入基準（「検索結果が1秒以内」）から検証項目を自動生成することで、 「このニーズは、この基準で、このテストで検証する」が契約時に確定します。
「このニーズは、この基準で、このテストで検証する」のトレーサビリティ
テスト項目が「検索機能のテスト」だけでは、どのニーズを検証しているか分かりません。 各検証項目にユーザーニーズIDを紐付けることで、 「このニーズは検証済み」「このニーズは未検証」が一目で分かり、リリース判断ができます。
検証不能な要件 = 曖昧な要件 → 要件の書き直しを促す
「使いやすいこと」のような曖昧な要件は、検証方法が定義できません。 検証計画を立てる段階で「この要件は検証できない」と気づくことで、 「ユーザーテストで評価4.0以上」のように測定可能な要件に書き直せます。