このフェーズの座組み
図1: 基本設計フェーズの役割・成果物・タスク
基本設計フェーズ — 座組み
フル稼働アーキテクト/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仕様を修正する」という状況になる。共通チームの成果物は他のすべてのチームのアンブロッカーとして優先的に完成させる必要がある。
技術選定は「なぜそう選んだか」を記録する
技術選定の理由を記録したドキュメントをADR（Architecture Decision Record）と呼ぶ。ADRは単に「何を選んだか」ではなく「なぜ選んだか・何を捨てたか」を記録することが目的だ。
| ADRに含める要素 | 内容例 |
|---|---|
| Status | Proposed / Accepted / Deprecated / Superseded |
| Context | この決定が必要になった背景・制約・要件 |
| Decision | 採用した選択肢とその理由 |
| Alternatives considered | 検討したが採用しなかった選択肢と、採用しなかった理由 |
| Consequences | この決定によって生じるトレードオフ・将来のリスク |
ADRを残す最大のメリットは「なぜ今の設計になっているのか」を後から参加したメンバーが確認できることだ。特に「なぜPostgreSQLをRDSで使っているのに別の場所でDynamoDBも使っているのか」「なぜモノリスをあえて選んだのか」といった一見矛盾に見える決定に、必ず理由がある。
基本設計フェーズでよくある失敗パターン
基本設計は「アーキテクチャを確定する」フェーズだが、この段階での手抜きが後の全フェーズに影響する。
| 失敗パターン | 何が起きるか | 防止策 |
|---|---|---|
| アーキテクチャ選択理由を残さない | 半年後に「なぜこの構成なのか」を誰も説明できなくなる。メンバー交代後は設計変更も怖くなる | ADRで決定・代替案・理由を記録。最低限でもConfluenceの1ページに書き残す |
| 非機能要件（性能・可用性）が未決定のまま進む | RDSのマルチAZ要否・Redisのレプリカ有無が詳細設計で判明し、アーキテクチャを再検討する羽目になる | 基本設計開始前にインフラと合意した非機能要件マトリクスを作る |
| 共通基盤の設計を後回しにする | 認証・共通エラーハンドリング・ロギングをFE/BEが独自実装して実装が乱立する | 共通チームを基本設計フェーズから参加させ、共通コンポーネント設計を先行完了させる |
✅ 次のPARTへ