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