Requirements Validation

要件検証スキル

目的

開発を始める前に、要件が正確で、網羅的かつ一貫性があり、ビジネス上の課題を実際に解決することを確認します。「正しいものを作る」ことと「ものを正しく作る」ことの違いです。

検証と妥当性確認

• Verification（検証）：「製品を正しく作っていますか？」（要件は品質基準を満たしていますか？）
• Validation（妥当性確認）：「正しい製品を作っていますか？」（要件はユーザーのニーズを解決していますか？）

主な妥当性確認の手法

1. ピアレビュー／ウォークスルー

• プロセス：同僚（開発者、他のビジネスアナリスト）による非公式または準公式のレビューです。
• 目標：ロジックの誤り、曖昧さ、考慮漏れのあるエッジケースを見つけます。
• チェックリスト：
  • 明確ですか？
  • テスト可能ですか？
  • 実現可能ですか？

2. ステークホルダーによるインスペクション／承認

• プロセス：ビジネスオーナーによる正式なレビューです。
• 目標：次の段階に進むための承認を得ます。
• 方法：ドキュメントを読むだけではなく、シナリオや例を使って確認します。

3. プロトタイピング

• 方法：言葉で説明するのではなく、実物を見せます。ワイヤーフレームやモックアップを使用します。
• 目標：UI／UX 要件を妥当性確認します。「思い描いていたものと同じですか？」

4. 受け入れ基準のレビュー

• 方法：「Given-When-Then」シナリオをレビューします。
• 目標：要件がテスト可能なほど具体的であることを確認します。

要件トレーサビリティマトリックス（RTM）

目的

要件をその起点と下流の成果物に関連付けます。

• 前方トレーサビリティ：要件 → 設計 → コード → テスト。（必要なものがすべて構築されていることを確認します）。
• 後方トレーサビリティ：テスト → 要件 → ビジネス目標。（「過剰な作り込み」や不要な機能がないことを確認します）。

RTM テンプレート

要件 ID	説明	ソース（ステークホルダー）	ビジネス目標	設計書	テストケース ID	ステータス
FR-01	ゲストチェックアウト	マーケティング担当副社長	コンバージョン増加	DD-Checkout	TC-001, 002	実装済み
FR-02	Apple Pay	CEO	モバイル戦略	DD-Payment	TC-005	承認済み
FR-03	3D Secure	コンプライアンス	法的要件	DD-Security	TC-010	テスト済み

品質チェックリスト（INVEST）

ユーザーストーリーの場合：

• Independent（独立している）
• Negotiable（交渉可能である）
• Valuable（価値がある）
• Estimable（見積もり可能である）
• Small（小さい）
• Testable（テスト可能である）

妥当性確認で見つかった問題への対処

1. 曖昧さ：「システムは高速でなければならない。」
   • 修正：「システムは 2 秒未満で読み込まなければならない。」
2. 意見の相違：ステークホルダー A は青を、B は赤を希望しています。
   • 修正：交渉を調整するか、スポンサーにエスカレーションします。
3. 不完全さ：エラー状態が欠落しています。
   • 修正：「これが失敗した場合、どうなりますか？」と尋ねます。

成果物

• 妥当性確認済み要件パッケージ：整理され、承認されたドキュメント。
• 承認記録：スコープを承認したメールまたは電子署名。
• 更新済みトレーサビリティマトリックス。

ツール

• Jira（ストーリーをエピック／テストに関連付けます）。
• Excel／Lark Base（RTM）。
• Confluence／Lark Docs（承認）。