このフェーズの座組み
図1: 開発フェーズの役割・成果物・タスク
開発フェーズ — 座組み
フル稼働アプリ（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・処理時間・エラーコードがトレースできる設計にすること。
ログ設計で最低限含めるべき項目と理由を整理しておく。
| ログ項目 | なぜ必要か |
|---|---|
| リクエストID（トレースID） | 複数サービスにまたがるリクエストを追跡するために必須。マイクロサービスでは特に重要。 |
| ユーザーID / セッションID | 「どのユーザーで発生したか」を特定し、再現手順を復元できる。 |
| 処理時間（ms） | 性能問題の検知・分析に使う。閾値を超えたらアラートも出せる。 |
| エラーコード / スタックトレース | エラーの原因特定に必須。ログにスタックトレースがないと調査に何倍もの時間がかかる。 |
| タイムスタンプ（ISO 8601形式・UTC） | 複数システムのログを時系列で突き合わせる際に形式が統一されていないと比較できない。 |
✅ 次のPARTへ