Appendix A: チェックリスト

本書で扱う「要求→要件→仕様→設計→テスト」を、作業漏れなく進めるための最小チェックリストです。プロセスの厳密さではなく、意思決定の一貫性を優先します。

A-1. 要求/要件/仕様（設計入力）のチェック

• 要求（Needs/Goals）が、要件（Shall）と仕様（Behavior）に変換されている
• To-Be（あるべき姿）と As-Is（現状）の差分が説明できる
• スコープ内/外（やらないこと）が明記されている
• 仕様（受け入れ条件）が検証可能な形式で定義されている
• 非機能の最小合意（性能/可用性/セキュリティ/運用）が定義されている
• 重要な例外系（権限、競合、失敗時、監査）が列挙されている

A-2. 設計（境界・結合）のチェック

• 依存関係トップ 10 を列挙できる（複雑性の焦点がある）
• 結合を S/D/V で説明できる（感想ではなく指標）
• 境界（責務の分離点）が言語化されている（なぜそこか）
• コア（純粋ロジック）が I/O に依存していない
• 境界を跨ぐ契約（型/DTO/インターフェース）が明確
• shared に相当する領域が肥大化していない（責務が曖昧になっていない）
• 公開 API（外部に漏れる契約）がどこか説明できる（UI/API/DB スキーマ等）

A-3. テスト（配分・導線）のチェック

• 価値導線（ユーザー価値）に E2E が割り当てられている（少数精鋭）
• 境界（API/DB/認可/外部連携）の契約が統合テストで検証されている
• コアの重要ロジックが単体テストで守られている
• テストが実装詳細に過度依存していない（変更耐性がある）
• 不安定要因（時刻、乱数、外部I/O）が制御可能になっている
• テストの目的が 4 本柱（価値/保守性/壊れにくさ/速度）に接続している
• E2E の増やし過ぎが発生していない（実行時間・フレークで破綻しない）

A-4. 進化（変更容易性）のチェック

• 境界強化のトリガーが明確（S/D/V 悪化、運用要件、変更頻度）
• 重要な意思決定が ADR として最小記録されている
• 設計変更がテスト戦略（配分・対象）に反映されている
• 「やらないこと（非ゴール）」が継続的に守られている

A-5. セキュリティ/観測性/運用（最小チェック）

• セキュリティ:
  • 認証/認可がサーバ側で強制されている（UI の表示制御に依存しない）
  • 入力検証（形式/長さ/必須）が境界（HTTP）で一貫している
  • 機微情報（トークン、個人情報、パスワード相当）をログに出さない
  • 権限逸脱や認可失敗が追跡できる（監査ログ/相関ID）
• 観測性（運用）:
  • 主要導線の成功/失敗が観測できる（エラー率、失敗理由コード）
  • 外部I/F（通知等）の失敗が検知できる（ログ/メトリクス/アラートのいずれか）
  • 主要イベントが検索できる（誰が/いつ/何をしたか。最低限の監査ログ）
• 運用:
  • 失敗時の期待（業務継続/停止、再送、手動復旧）が仕様として固定されている
  • バックアップ/復旧の前提が合意されている（復旧の責任者と手順の所在）
  • リリース/ロールバックの手順が明文化されている（属人化していない）

A-6. PR / AI / 形式手法との接続チェック

• PR body に、確認範囲、変更判断、検証結果、残リスクが記録されている
• GitHub Copilot などの AI review コメントを全件確認し、必要な修正または不要理由を返信している
• AI に投入した情報に、秘密情報、個人情報、未公開顧客データ、認証情報が含まれていない
• AI が生成した要件・仕様・テスト観点は、事実と仮説を分けて人間がレビューしている
• 不変条件、状態遷移、認可ルール、競合制御など、形式仕様化した方がよい箇所を検討している
• 形式手法を採用しない場合も、対象外とした理由（規模、コスト、リスク、代替テスト）を記録している
• CI の実行 URL、失敗時ログ、再実行結果、Pages 確認結果を PR に残している
• merge 後に main checks と公開ページ反映を確認している