このフェーズの座組み
基本設計フェーズ — 座組み
フル稼働アーキテクト/PLインフラDBA共通チームPMO
部分参加PMアプリ（FE）アプリ（BE）QAセキュリティ
⚠️ このフェーズの成果物は後続全チームの「設計の前提」になる
特に共通チームの認証・認可設計と、DBAの論理データモデルは、アプリ担当の詳細設計に先行して確定させる必要がある。これらが固まる前に詳細設計を開始すると、確定後に大規模な修正が必要になる。
成果物マトリクス
| 役割 | 成果物 | ポイント |
|---|---|---|
| 管理PM | スコープ確定書、リソース計画（詳細化） | このフェーズでスコープを凍結する。以降の変更は変更管理プロセスを経る。 |
| 管理PMO | WBS（詳細化）、リスク管理表（定量評価開始） | リスクの定量評価（発生確率×影響度）をここで開始する。 |
| 技術統括アーキテクト/PL | システム方式設計書、技術選定ドキュメント（ADR）、アーキテクチャ図（C4モデル等） | 全チームの設計の前提。変更コストが最も高い決定。全員が参照できる場所に置く。 |
| アプリFE | 画面一覧・画面遷移図、コンポーネント設計方針、UIライブラリ選定 | デザインシステム・UIライブラリの選定もここ。後からの変更は全画面に影響する。 |
| アプリBE | API一覧・API設計方針、サービス/モジュール分割設計 | FEとの「契約書」として機能する。早期のFEとの合意が重要。 |
| インフラインフラ | インフラ構成図（論理）、冗長化・DR方針、クラウドリージョン・AZ設計 | 可用性要件と照合しながら設計する。マルチAZ構成の方針はここで確定。 |
| データDBA | 論理データモデル（ER図）、テーブル設計方針、DB選定根拠（RDB/NoSQL） | RDB/NoSQLの判断はこのフェーズで行う。後から変えると全体影響が出る。 |
| 横断共通チーム | 認証・認可設計、共通ライブラリ選定、APIゲートウェイ設計方針 | 全アプリ担当の詳細設計に影響する。先行して確定が必須。 |
| 横断QA | テスト計画書（詳細化）、テスト環境要件定義 | テストデータ設計の開始タイミング。テスト環境の構築はインフラと連携。 |
| 横断セキュリティ | セキュリティアーキテクチャレビュー結果 | 設計への指摘はここが事実上の最終機会。詳細設計以降は修正コストが高い。 |
変更コストが最も高い決定
基本設計フェーズでは以下の決定が「後から変えられない」または「変更コストが極めて高い」決定として位置付けられる。
| 決定事項 | 変更した場合の影響範囲 |
|---|---|
| DB選定（RDB/NoSQL） | スキーマ設計・クエリ実装・マイグレーション計画のすべてに影響 |
| 認証方式（OAuth2/SAML/独自） | FE・BE・インフラのすべてに影響。セッション管理の再設計が必要 |
| マイクロサービス vs モノリス | 開発体制・デプロイ戦略・インフラ構成のすべてに影響 |
| フロントエンドフレームワーク | 全画面の再実装が必要。コンポーネント資産の移行コストも発生 |
| クラウドリージョン・AZ構成 | ネットワーク設計・DR計画・コスト構造のすべてに影響 |
共通チームの成果物が先行する理由
💡 共通チームの遅延はすべてのアプリチームのボトルネックになる
認証・認可設計とAPIゲートウェイ設計は、FEとBEの詳細設計の前提条件だ。これらが固まる前に詳細設計を開始すると、確定後に「認証フローが変わったので全API仕様を修正する」という状況になる。共通チームの成果物は他のすべてのチームのアンブロッカーとして優先的に完成させる必要がある。
✅ 次のPARTへ