はじめに — シリーズの目的と失敗パターン

このシリーズを書いた動機

Webシステムの開発プロジェクトが失敗に終わるとき、その原因の多くは技術的な問題ではなく、「誰がいつ何を作るべきか」の認識ズレにある。

「DBAは開発フェーズから呼べばいい」「セキュリティはリリース直前に診断すればいい」「共通認証はアプリチームが作る」——こうした認識のまま進んだプロジェクトは、後半に必ず大きな手戻りを起こす。

本シリーズは企画から運用まで全8フェーズを横断し、PM・PMO・アーキテクト・アプリ（FE/BE）・インフラ・DBA・共通チーム・QA・セキュリティ担当が「いつ・何を作るべきか」を整理したものだ。プロジェクト立ち上げ時のアサイン計画や、フェーズ移行時のチェックリストとして活用してほしい。

実際のプロジェクトで繰り返し見てきた失敗パターンを2つ挙げる。どちらも「技術的には解決できた問題」だったが、「誰がいつ関与するか」が明確でなかったために手遅れになった。

❶ DBAが詳細設計フェーズから参入

DB設計は基本設計フェーズで骨格が決まる。しかしDBAが不在のまま進んだ結果、詳細設計でインデックス設計が後付けに。開発フェーズでアプリチームが書いたクエリと整合が取れず、全面修正を余儀なくされた。

❷ セキュリティ担当がテストフェーズ直前に登場

「セキュリティ診断はリリース前にやればいい」という認識で進めた結果、認証設計の根本的な欠陥が発覚。設計の見直しが必要になり、リリースを2ヶ月延期。要件定義での関与があれば防げた問題だった。

⚠️ 「後から呼べばいい」は成立しない

DBA・セキュリティ・共通チームに共通するのは「後から入っても変えられない設計を扱う」という点だ。アーキテクチャ・認証方式・DB構造は、後から変更するコストが指数関数的に増大する。これらの専門家を早期に巻き込むことが、手戻りゼロプロジェクトの最短経路だ。

本シリーズは以下の構成で展開する。

全体像を把握したい場合はPART 03（人員マップ）を先に読むことを勧める。フェーズの詳細に入る前に「誰が何フェーズで必要か」を掴んでおくと、各フェーズ記事の成果物表が頭に入りやすい。

以下のような立場の方に特に役立つ内容だ。

✅ 次のPARTへ

PART 02では、本シリーズが対象とするフェーズと役割の定義、そして「成果物」という言葉の範囲を整理する。