---
name: orchestrating-analysis
description: 分析フェーズ全体のワークフローをオーケストレーション。戦略→要件定義→機能要件→非機能要件の順序で各 analyzing-* スキルの実行を案内。分析フェーズの開始、全体像の把握、次に何を分析すべきかの判断、分析の進め方の相談時に使用。「分析を始めたい」「要件定義の次は何？」「設計ドキュメントを一通り作りたい」といった場面で発動する。
---

# 分析フェーズオーケストレーション

分析フェーズ全体の作業順序を案内する。各工程には専門の analyzing-* スキルがあるため、このスキルの役割は「何を・どの順序で・なぜその順序で」進めるかを示すことにある。

開発ガイド（@docs/reference/開発ガイド.md）の分析セクションに定義されたフローに準拠する。

## 分析フェーズの構成

分析は **戦略 → 要件定義 → 機能要件 → 非機能要件** の 4 段階で進める。各段階の出力が次の段階の入力になるため、この順序を守ることが品質を確保する上で重要になる。

### 段階 1: 戦略

プロジェクトの「なぜ・何を・どうやって」を明確にする。ここが曖昧だと後工程すべてがブレるため、最初に固める。

| 工程 | スキル | 成果物 |
|------|--------|--------|
| ビジネスアーキテクチャ分析 | `analyzing-business-architecture` | ビジネスモデルキャンバス、バリューストリーム、ケイパビリティマップ |
| インセプションデッキ作成 | `analyzing-inception-deck` | 10 の問いへの回答、概念アーキテクチャ、マイルストーン |

### 段階 2: 要件定義

システムが解決すべき問題と境界を定義する。RDRA 2.0 の体系に従い、システム価値→外部環境→境界の順で分析を進める。

| 工程 | スキル | 成果物 |
|------|--------|--------|
| 要件定義 | `analyzing-requirements` | システムコンテキスト、要求モデル、業務フロー |
| ユースケース・ユーザーストーリー | `analyzing-usecases` | ビジネスユースケース、システムユースケース、ユーザーストーリー |

### 段階 3: 機能要件

要件をどう実現するかの設計を行う。アーキテクチャが決まらないとデータモデルやドメインモデルの粒度が定まらないため、アーキテクチャ設計を先に行う。

| 工程 | スキル | 成果物 |
|------|--------|--------|
| アーキテクチャ設計 | `analyzing-architecture` | バックエンド・フロントエンド・インフラ設計 |
| データモデル設計 | `analyzing-data-model` | ER 図、テーブル定義 |
| ドメインモデル設計 | `analyzing-domain-model` | エンティティ、値オブジェクト、集約 |
| UI 設計 | `analyzing-ui-design` | 画面遷移図、画面イメージ |

### 段階 4: 非機能要件

システムの品質特性と運用方針を定義する。機能要件が見えた段階で策定することで、現実的な要件を設定できる。

| 工程 | スキル | 成果物 |
|------|--------|--------|
| テスト戦略 | `analyzing-test-strategy` | テストピラミッド、テスト種別、カバレッジ目標 |
| 非機能要件 | `analyzing-non-functional` | 性能・セキュリティ・可用性・保守性要件 |
| 運用要件 | `analyzing-operation` | 運用フロー、監視設計、障害対応手順 |

### 横断: 技術スタック・ADR

技術スタック選定とアーキテクチャ決定記録は、分析の進行に応じて随時実施する。

| 工程 | スキル | 成果物 |
|------|--------|--------|
| 技術スタック選定 | `analyzing-tech-stack` | 技術選定・評価結果 |
| ADR 作成 | `creating-adr` | Architecture Decision Record |
| 構成適用 | `apply-docs-structure` | 各工程の成果物の配置先判断（戦略は `strategy/` 単一、要件以降はプロジェクト別 `<category>/<project>/`） |
| OKF 適用 | `apply-okf` | 各工程の成果物へのフロントマター付与・`index.md`/`log.md` 更新 |

`docs/` がドキュメント構成ガイド（単一企業・統合戦略・複数プロジェクト）を採用しているなら、各工程で成果物を書く**直前**に `apply-docs-structure` で配置先を判断する。戦略工程（企業分析・経営戦略・ビジネスアーキテクチャ・インセプションデッキ）の成果物は `docs/strategy/` に単一管理、要件定義以降の成果物はプロジェクト別カテゴリの `<category>/<project>/` 配下に置く。配置を書いた後に直すと索引・リンク・OKF の来歴すべての修正が必要になるため、判断は必ず書く前に行う。

`docs/` が OKF 知識バンドル（ルート `index.md` に `okf_version` がある）なら、各工程で設計ドキュメントを作成・更新するたびに `apply-okf` を実行する。分析の成果物はエージェントが書き、人がレビューして確定する流れなので、作成時は `status: draft`、レビュー後に `verify --by human:<id>` で `stable` に昇格させる。工程ごとにこれを行えば、分析フェーズの終わりには「どの文書が誰に確認済みか」がフロントマターから読める状態になる。

## 進め方

### 現状を確認してから始める

分析を開始する前に、プロジェクトの現状を把握する。既存のドキュメントやコードがある場合、ゼロから始める必要はない。

1. `docs/` 配下の既存ドキュメントを確認
2. `docs/design/` 配下の設計ドキュメントの有無を確認
3. 未着手の工程を特定し、次のアクションを提案

### 途中から再開する場合

すべての工程を最初から実施する必要はない。既に完了している工程はスキップし、未着手または更新が必要な工程から再開する。

**Example:**

```
ユーザー: 「要件定義は終わった。次は何をすればいい？」
回答: 段階 3（機能要件）のアーキテクチャ設計から開始。
      analyzing-architecture スキルを使ってアーキテクチャ設計を進める。
```

### 工程間のフィードバック

分析は一方通行ではない。後工程の検討で前工程の見直しが必要になることがある。たとえば、データモデル設計中に要件の不足に気づいた場合は、要件定義に戻って補完する。

## コンテキスト管理

分析フェーズは多くの工程を含むため、長時間セッションになりやすい。以下のタイミングで `/compact` を実施し、コンテキストを圧縮する。

- 分析工程 1 件が完了したとき
- 設計ドキュメント 1 件の作成・更新が完了したとき
- コミット完了後、次の工程に着手する前

`/compact` 実施前に、現在の作業状態と次の工程をメモとして出力する。これにより、圧縮後も作業の連続性を保てる。

## 注意事項

- 分析結果は開発フェーズで継続的に見直す。完璧を目指して分析を長引かせるより、十分な品質で開発に進み、フィードバックで改善する方が効果的
- 各工程の成果物は `docs/` 配下に Markdown + PlantUML で文書化する。配置先は書く前に `apply-docs-structure` で判断し、OKF バンドルなら作成・更新のたびに `apply-okf` で規約を適用し、`gulp okf:check` が ERROR 0 の状態でコミットする
- リリース計画（`planning-releases`）は分析フェーズの最後に、技術スタック選定後に実施する