抜け漏れパターン6選
図1: よくある失敗事例と対策
❶ DBAが詳細設計フェーズから参入
インデックス設計が後付けになり、アプリチームが書いたクエリと整合が取れなくなる。開発フェーズで性能問題が頻発し、テーブル構造の見直しを余儀なくされるケースも。
→ DBAは基本設計フェーズからフル稼働させる
❷ 共通チームが不在
認証処理をFE・BEチームがそれぞれ独自実装する。実装がバラバラになり、仕様変更時に全チームへの影響が出る。セキュリティホールが生まれやすい領域でもある。
→ 共通チームを基本設計フェーズから設置し、認証設計を先行して確定させる
❸ インフラが要件定義に不在
非機能要件（可用性・スケール・DR）が後から覆る。「マルチAZ必須」が基本設計完了後に判明し、アーキテクチャを再設計するケースが典型例だ。
→ インフラは要件定義フェーズから非機能要件定義に参加させる
❹ QAがテストフェーズ直前まで不参加
テストケース設計が間に合わない。仕様書の矛盾がテストフェーズまで発覚せず、発覚時点で修正コストが高くなる。UATの受入基準も曖昧なまま進む。
→ QAは基本設計フェーズからテスト計画に参加させる
❺ Runbookなしで運用移行
「作った人しか直せない」状態で運用チームに引き継ぐ。障害発生時に開発チームへの逆エスカレーションが頻発し、運用チームが疲弊する。
→ Runbookをリリースフェーズまでに作成し、運用移管完了報告に含める
❻ データ移行リハーサルなし
本番移行時に想定外のデータ不整合・処理時間超過が発生。ロールバック手順も未整備のまま本番に臨み、システム停止が長期化する。
→ DBAが主導して本番同等データでのリハーサルを最低1回実施する
なぜ繰り返されるのか
これらのパターンには共通する構造的な原因がある。
| 原因 | 具体的な状況 |
|---|---|
| コスト意識による早期参加の回避 | 「まだ設計段階だからDBAを呼ぶのは早い」という判断で参加を遅らせる。結果的に後工程の手戻りコストの方が高くつく。 |
| 役割の境界の曖昧さ | 「それは誰の仕事か」が明文化されていないため、誰も作らない成果物が発生する。特に共通基盤（認証・ライブラリ）が典型。 |
| フェーズの形骸化 | 「フェーズは区切りだけ」という認識で、各フェーズの成果物や参加者の合意がないまま次のフェーズに進む。 |
| プロジェクト後半の圧縮 | 開発フェーズの遅延がテスト・リリースフェーズを圧縮する。テスト準備・Runbook作成・移行リハーサルが省略される。 |
防止のためのチェックポイント
⚠️ フェーズ移行時のチェックリスト
各フェーズから次のフェーズに移行する前に、「このフェーズで全員が作るべき成果物は揃っているか」を確認する。特に①基本設計→詳細設計（DBA・共通チームの成果物）と②テスト→リリース（UAT合意書・Runbook・移行リハーサル結果）の2つの移行ポイントは念入りに確認する。
フェーズ別：抜け漏れが起きやすいタイミング
抜け漏れはどのフェーズでも起きうるが、「発覚したフェーズ」が「発生したフェーズ」より後になるほど手戻りコストが膨らむ。下表は各フェーズで特に注意すべき抜け漏れをまとめたものだ。
| フェーズ | よく抜けるもの | 発覚するタイミング | 手戻りの深刻度 |
|---|---|---|---|
| 企画 | スコープ外の未定義、RACI表の未作成 | 要件定義〜開発 | 高（全工程に影響） |
| 要件定義 | 非機能要件（可用性・性能）の未定義、セキュリティ要件の遅延 | 基本設計〜テスト | 高（アーキテクチャを覆す場合あり） |
| 基本設計 | DBA・共通チームの不参加、インデックス方針の未確定 | 詳細設計〜開発 | 中〜高（テーブル再設計が発生） |
| 詳細設計 | エラーケース・境界値の設計漏れ、API仕様のFE/BEズレ | 開発〜テスト | 中（修正は局所的だが多発する） |
| 開発 | ログ出力の抜け、セキュリティチェックの省略 | テスト〜運用 | 中（後から追加は工数大） |
| テスト | UAT受入基準の未合意、性能テストの省略 | リリース後 | 高（本番障害に直結） |
| リリース | Runbook未作成、データ移行リハーサルなし | 本番移行直後 | 高（システム停止の長期化） |