このシリーズを書いた動機
図1: 計画から運用までのWebシステム開発の全フェーズ
Webシステムの開発プロジェクトが失敗に終わるとき、その原因の多くは技術的な問題ではなく、「誰がいつ何を作るべきか」の認識ズレにある。
「DBAは開発フェーズから呼べばいい」「セキュリティはリリース直前に診断すればいい」「共通認証はアプリチームが作る」——こうした認識のまま進んだプロジェクトは、後半に必ず大きな手戻りを起こす。
本シリーズは企画から運用まで全8フェーズを横断し、PM・PMO・アーキテクト・アプリ（FE/BE）・インフラ・DBA・共通チーム・QA・セキュリティ担当が「いつ・何を作るべきか」を整理したものだ。 プロジェクト立ち上げ時のアサイン計画や、フェーズ移行時のチェックリストとして活用してほしい。
典型的な失敗パターン2選
実際のプロジェクトで繰り返し見てきた失敗パターンを2つ挙げる。 どちらも「技術的には解決できた問題」だったが、「誰がいつ関与するか」が明確でなかったために手遅れになった。
⚠️ 「後から呼べばいい」は成立しない
DBA・セキュリティ・共通チームに共通するのは「後から入っても変えられない設計を扱う」という点だ。 アーキテクチャ・認証方式・DB構造は、後から変更するコストが指数関数的に増大する。 これらの専門家を早期に巻き込むことが、手戻りゼロプロジェクトの最短経路だ。
シリーズの構成と読み方
本シリーズは以下の構成で展開する。
| PART | タイトル | 内容 |
|---|---|---|
| 01 | はじめに（本記事） | シリーズの目的と失敗パターン |
| 02 | 前提整理 | フェーズ定義・役割定義・「成果物」の定義 |
| 03 | 人員マップ | 全フェーズ×全役割の稼働レベル俯瞰表 |
| 04〜11 | 各フェーズ | フェーズごとの座組みと成果物マトリクス |
| 12 | 抜け漏れパターン | よくある失敗事例と構造的な原因 |
| 13 | まとめ | 成果物を活かすプロジェクト運営 |
全体像を把握したい場合はPART 03（人員マップ）を先に読むことを勧める。 フェーズの詳細に入る前に「誰が何フェーズで必要か」を掴んでおくと、各フェーズ記事の成果物表が頭に入りやすい。
対象読者
以下のような立場の方に特に役立つ内容だ。
- プロジェクト立ち上げ時のアサイン計画を作成するPM・PMO
- 「このフェーズで自分は何を作ればいいか」を確認したいSE・エンジニア
- 新規参画プロジェクトのキャッチアップをしたいPL・TL
- 発注側・ユーザー企業でITプロジェクトを管理する担当者
このシリーズの活用方法
本シリーズには2通りの読み方がある。
| 読み方 | おすすめの状況 | 推奨する読み順 |
|---|---|---|
| シリーズ通読 | プロジェクト立ち上げ前・参画前のキャッチアップ | PART 01 → PART 02 → PART 03 → PART 04〜11 → PART 12 → PART 13 |
| フェーズ別参照 | 特定のフェーズの準備・レビュー時 | PART 03（人員マップ）を確認後、該当フェーズの記事を直接参照 |
プロジェクト途中から参画したエンジニアには、まずPART 03（人員マップ）と自分が参加しているフェーズの記事（PART 04〜11）を読むことを勧める。全体の流れを知りたい場合はPART 12（よくある抜け漏れパターン）も合わせて参照すると、どこに注意すべきかが把握できる。