このフェーズの座組み
開発フェーズ — 座組み
フル稼働アプリ（FE）アプリ（BE）インフラ共通チームPMO
部分参加PMDBA
レビュー参加PL/TLQA
⚠️ 開発フェーズのPMOの主な仕事はスコープクリープの防止
「ちょっとした仕様追加」が積み重なって納期が崩れるパターンは非常に多い。すべての変更要求を記録し、承認なしの実装を防ぐことがPMOの最重要ミッションとなる。
成果物マトリクス
| 役割 | 成果物 | ポイント |
|---|---|---|
| 管理PM | 進捗報告書（定期）、課題エスカレーション記録 | バッファ管理と課題の早期浮上が主な仕事。「赤信号を早く出す文化」を作る。 |
| 管理PMO | 課題管理台帳（更新）、変更管理記録（変更要求ログ） | 変更要求は全件記録し、承認なしの実装を防ぐ。変更の影響評価も記録する。 |
| アプリFE | 実装コード、単体テスト（Jest等）、Storybookコンポーネント集 | CI/CDパイプラインへの組み込みも含む。コードレビューの観点はPL/TLが定義した基準に従う。 |
| アプリBE | 実装コード、単体テスト（JUnit等）、API実装（OpenAPI準拠確認）、ログ設計実装 | ログ設計はここで実装しないと後の障害対応で詰む。ログレベル・フォーマット・出力先を統一する。 |
| インフラインフラ | IaCコード（Terraform/CloudFormation等）、CI/CDパイプライン構築、開発・ステージング環境 | 環境の整備遅れが開発全体のボトルネックになる。IaCコードはGitで管理し、環境差異をコード化する。 |
| データDBA | マイグレーションスクリプト（Flyway/Liquibase等）、初期データ投入スクリプト、スロークエリ対応記録 | 開発中の性能劣化を早期に検知する。スロークエリが出たらインデックス設計を見直す。 |
| 横断共通チーム | 共通ライブラリ（リリース版）、利用ガイド更新、サンプルコード | 各チームのブロッカーにならないことが最優先。問い合わせ対応の窓口を明確にする。 |
スコープクリープの防止
💡 変更要求の記録フォーマット
PMOが管理する変更管理記録には、最低限①変更要求の内容、②申請者・日付、③影響評価（工数・スコープ・スケジュール）、④承認者・承認日の4項目を含める。これがないと「誰がいつ何を変更したか」の追跡ができなくなる。
ログ設計は開発フェーズで実装する
⚠️ 「ログは後で入れる」は禁句
ログ設計を後回しにしたシステムは、本番障害発生時に「ログが全く役に立たない」状況になる。BEの実装と同時にログを入れる習慣を徹底する。最低限、リクエストID・ユーザーID・処理時間・エラーコードがトレースできる設計にすること。
✅ 次のPARTへ