このフェーズの座組み
詳細設計フェーズ — 座組み
フル稼働アプリ（FE）アプリ（BE）インフラDBA共通チーム
部分参加PL/TLPMOQAセキュリティ
⚠️ 共通チームの遅延が全チームのボトルネックになる
共通コンポーネント仕様書とAPIゲートウェイ詳細設計は、FEとBEチームの設計開始前に提供される必要がある。共通チームの遅延は全アプリチームの詳細設計開始を遅らせる。共通チームの成果物は最優先で完成させる。
成果物マトリクス
| 役割 | 成果物 | ポイント |
|---|---|---|
| 技術統括PL/TL | 詳細設計レビュー基準、コーディング規約、ブランチ戦略・マージポリシー | 品質基準を明文化しないとレビューの合否判断がブレる。レビュー観点のチェックリスト形式が効果的。 |
| アプリFE | 詳細画面設計書、コンポーネント仕様書（Storybook等）、API呼び出し仕様、状態管理設計 | BEのAPI仕様書との整合確認が必須。モック実装のタイミングも合わせて計画する。 |
| アプリBE | 詳細API仕様書（OpenAPI 3.x）、クラス設計・シーケンス図、エラーコード定義、ログ設計 | 実装の直接インプット。曖昧さを残さない。エラーコードはFEと共有する。 |
| インフラインフラ | インフラ構成図（物理）、IaCテンプレート設計（Terraform等）、監視設計書（アラート定義含む） | IaCテンプレートの設計もここで開始。構築手順書（初版）も並行して作成。 |
| データDBA | 物理データモデル、DDL（CREATE TABLE文）、インデックス設計書、バックアップ・リストア方針 | インデックス設計はクエリパターン（BEの詳細設計）と合わせて行う。後付けは性能問題を引き起こす。 |
| 横断共通チーム | 共通コンポーネント仕様書、APIゲートウェイ詳細設計、共通ライブラリ利用ガイド、サンプルコード | 各チームへの共有タイミングが遅れるとボトルネックになる。最優先で完成させる。 |
| 横断QA | 単体・結合テストケース設計（初版） | 仕様書ベースで先行作成。テストケースを書く過程で仕様の矛盾が発覚するケースがある。 |
| 横断セキュリティ | セキュリティ詳細設計チェックリスト確認結果（SQLインジェクション・XSS・CSRF・認証バイパス等） | OWASPトップ10の対策状況をAPI設計・画面設計に照らし合わせて確認する。 |
設計品質基準の明文化
PL/TLが作成する詳細設計レビュー基準には、以下の観点を最低限含める。
| 観点 | 確認内容 |
|---|---|
| 整合性 | API仕様書とBEの詳細設計、FEの呼び出し仕様が一致しているか |
| 完全性 | 正常系・異常系・境界値がすべて記述されているか。エラー時のレスポンスも定義されているか |
| DBA連携 | クエリパターンとインデックス設計が対応しているか |
| セキュリティ | 入力値バリデーション・認証チェックが実装位置として明記されているか |
| 非機能要件との整合 | 性能要件（レスポンスタイム・スループット）を達成できる設計か |
✅ 次のPARTへ