@k2works/claude-code-booster 4.13.0 → 4.15.0

package/lib/assets/.claude/skills/analyzing-business-architecture/SKILL.md

@@ -1,122 +1,122 @@
----
-name: analyzing-business-architecture
-description: ビジネスアーキテクチャ分析を支援。要件定義の前段階として、ビジネスモデルキャンバス、バリューストリーム、ケイパビリティマップ、組織マップ、情報マップ、ビジネスシナリオを作成。「ビジネスモデルを整理したい」「バリューストリームを描きたい」「ケイパビリティマップを作りたい」「事業構造を分析したい」「ビジネスアーキテクチャを分析したい」「BA 分析をしたい」といった場面で発動する。ビジネスの全体像を理解してからシステム要件に落とし込むことで、本当に必要な機能を見極められる。
----
-
-# ビジネスアーキテクチャ分析
-
-エンタープライズがどのように価値を生み出し、顧客に提供するかの構造を体系的に整理する。この分析は要件定義の前段階として行い、成果物は後続の `analyzing-requirements`（要件定義）や `analyzing-usecases`（ユースケース分析）の入力になる。
-
-ビジネスの構造を先に理解することで、「何を作るか」ではなく「なぜ作るか」からシステムを設計でき、本当に価値のある機能に集中できる。
-
-## 参照ドキュメント
-
-- @docs/reference/ビジネスアーキテクチャ分析ガイド.md — 分析手法とフレームワークの詳細。各成果物の作成方法はこのガイドに従う。
-
-## テンプレート・入力・成果物
-
-| 種類 | パス | 備考 |
-|------|------|------|
-| テンプレート | @docs/template/ビジネスアーキテクチャ.md | 編集禁止。コピーして使用する |
-| 入力（任意） | @docs/strategy/business_strategy.md | `analyzing-business-strategy` の成果物があれば流用 |
-| 成果物 | `docs/strategy/business_architecture.md` | テンプレートを基に作成 |
-
-### 入力の扱い
-
-本スキルは実プロジェクトのビジネスアーキテクチャを文書化するもので、単独実行も可能である。ただし、`analyzing-business-strategy` スキルで戦略分析（SWOT・VRIO・BMC・価値連鎖・ケイパビリティマップなど）を先に済ませている場合は、その成果物 `business_strategy.md` を入力として活用することで分析の重複を避けられる。
-
-`business_strategy.md` から流用できる主な要素：
-
-| 戦略分析の成果物 | 本スキルでの活用先 |
-|----------------|------------------|
-| 環境分析（SWOT・VRIO） | ビジネスプリンシプル策定の根拠 |
-| ビジネスモデル（BMC） | ビジネスモデルキャンバスセクションへ直接転記 |
-| バリューストリーム | バリューストリーム設計の叩き台 |
-| ケイパビリティマップ | ケイパビリティモデル構築の出発点 |
-| 組織マップ | 組織マップセクションへ直接転記 |
-| 情報マップ | 情報マップ作成の入力 |
-| ビジネスシナリオ | ビジネスシナリオ策定の雛形 |
-
-戦略分析の視点（why）と、アーキテクチャ分析の視点（how／what の構造）は異なるため、単純なコピーではなく「戦略で決まった方向性を、アーキテクチャの構造として再整理する」姿勢で取り込むこと。
-
-`business_strategy.md` が存在しない場合は、プロジェクトの基本情報（ビジョン、ミッション、ビジネス概要）をヒアリングして直接作成する。
-
-## 分析の進め方
-
-以下の順序で進める。各ステップの出力が次のステップの入力になるため、この順序を守ることで整合性の高い分析ができる。
-
-### 0. 入力の確認（任意）
-
-`docs/strategy/business_strategy.md` が存在するかを確認する。存在する場合は該当セクション（BMC、バリューストリーム、ケイパビリティマップ、組織マップ、ビジネスシナリオなど）を読み取り、各ステップで活用する。存在しない場合は次のステップから開始する。
-
-### 1. プリンシプルの定義
-
-ビジョン・ミッション・価値観に基づく方針を最初に固める。プリンシプルが曖昧だと、後続の分析で判断軸がブレる。
-
-- **ガイディングプリンシプル**: ビジネス・アプリケーション・データ・テクノロジーの各アーキテクチャに対する方針
-- **ビジネスプリンシプル**: ビジネスにおける原則原理
-
-### 2. ビジネスモデルの整理
-
-ビジネスモデルキャンバスを作成し、ビジネスの全体構造を 9 つの要素で可視化する。
-
-- 顧客セグメント、価値提案、チャネル、顧客関係
-- 主要活動、主要リソース、主要パートナー
-- 収益源、コスト構造
-
-### 3. バリューストリームの設計
-
-価値がどのように流れるかを可視化する。バリューストリームはケイパビリティモデルの土台になるため、ケイパビリティより先に作成する。
-
-- バリュー（価値）の分析
-- バリューストリームマップの作成
-- 各ステージでの価値増加の可視化
-
-### 4. ケイパビリティモデルの構築
-
-組織が持つ能力を体系的に整理する。バリューストリームの各ステージに必要なケイパビリティを紐付けることで、どの能力に投資すべきかが見える。
-
-- ケイパビリティの特定（戦略・コア・サポート）
-- 階層化とレベリング
-- ヒートマッピングによる成熟度評価
-- バリューストリームとのマッピング
-
-### 5. 組織マップの作成
-
-部門・組織構造を整理し、ケイパビリティとの対応付けを行う。
-
-### 6. 情報マップの作成
-
-ビジネスエンティティを特定し、エンティティ間のリレーションを整理する。後続のデータモデル設計の基礎になる。
-
-### 7. ビジネスシナリオの策定
-
-問題を特定・文書化し、ゴールと期待する結果を定義する。ヒューマンアクター・コンピュータアクターを特定し、後続のユースケース分析の入力とする。
-
-## 途中から再開する場合
-
-既存の `docs/strategy/business_architecture.md` がある場合は、まずその内容を確認する。完了済みのセクションはスキップし、未着手または更新が必要なセクションから再開する。
-
-**Example:**
-
-```
-ユーザー: 「ビジネスモデルキャンバスは作った。次は？」
-回答: バリューストリームの設計に進む。ビジネスモデルキャンバスで特定した
-      主要活動を基に、価値の流れを可視化する。
-```
-
-## 注意事項
-
-- プロジェクトの基本情報（ビジョン、ミッション、ビジネス概要）が提供されていることを確認してから分析を開始する
-- ビジネスアーキテクチャの重要な決定は ADR（`creating-adr`）で記録する
-- 成果物は PlantUML を活用して視覚的に文書化する
-- タスク項目（リスト）の前には空行を入れる（Markdown Lint 準拠）
-
-## 関連スキル
-
-- `analyzing-business-strategy` — 前段の戦略分析（成果物 `business_strategy.md` を本スキルの入力として活用可能）
-- `generating-bmc` — 本スキルの BMC セクションから SVG 図を生成
-- `analyzing-requirements` — 後続の要件定義（本スキルの成果物が入力）
-- `analyzing-usecases` — 後続のビジネスユースケース詳細化
-- `analyzing-architecture` — 後続のシステムアーキテクチャ設計への橋渡し
-- `orchestrating-analysis` — 分析フェーズ全体のワークフロー案内
+---
+name: analyzing-business-architecture
+description: ビジネスアーキテクチャ分析を支援。要件定義の前段階として、ビジネスモデルキャンバス、バリューストリーム、ケイパビリティマップ、組織マップ、情報マップ、ビジネスシナリオを作成。「ビジネスモデルを整理したい」「バリューストリームを描きたい」「ケイパビリティマップを作りたい」「事業構造を分析したい」「ビジネスアーキテクチャを分析したい」「BA 分析をしたい」といった場面で発動する。ビジネスの全体像を理解してからシステム要件に落とし込むことで、本当に必要な機能を見極められる。
+---
+
+# ビジネスアーキテクチャ分析
+
+エンタープライズがどのように価値を生み出し、顧客に提供するかの構造を体系的に整理する。この分析は要件定義の前段階として行い、成果物は後続の `analyzing-requirements`（要件定義）や `analyzing-usecases`（ユースケース分析）の入力になる。
+
+ビジネスの構造を先に理解することで、「何を作るか」ではなく「なぜ作るか」からシステムを設計でき、本当に価値のある機能に集中できる。
+
+## 参照ドキュメント
+
+- @docs/reference/ビジネスアーキテクチャ分析ガイド.md — 分析手法とフレームワークの詳細。各成果物の作成方法はこのガイドに従う。
+
+## テンプレート・入力・成果物
+
+| 種類 | パス | 備考 |
+|------|------|------|
+| テンプレート | @docs/template/ビジネスアーキテクチャ.md | 編集禁止。コピーして使用する |
+| 入力（任意） | @docs/strategy/business_strategy.md | `analyzing-business-strategy` の成果物があれば流用 |
+| 成果物 | `docs/strategy/business_architecture.md` | テンプレートを基に作成 |
+
+### 入力の扱い
+
+本スキルは実プロジェクトのビジネスアーキテクチャを文書化するもので、単独実行も可能である。ただし、`analyzing-business-strategy` スキルで戦略分析（SWOT・VRIO・BMC・価値連鎖・ケイパビリティマップなど）を先に済ませている場合は、その成果物 `business_strategy.md` を入力として活用することで分析の重複を避けられる。
+
+`business_strategy.md` から流用できる主な要素：
+
+| 戦略分析の成果物 | 本スキルでの活用先 |
+|----------------|------------------|
+| 環境分析（SWOT・VRIO） | ビジネスプリンシプル策定の根拠 |
+| ビジネスモデル（BMC） | ビジネスモデルキャンバスセクションへ直接転記 |
+| バリューストリーム | バリューストリーム設計の叩き台 |
+| ケイパビリティマップ | ケイパビリティモデル構築の出発点 |
+| 組織マップ | 組織マップセクションへ直接転記 |
+| 情報マップ | 情報マップ作成の入力 |
+| ビジネスシナリオ | ビジネスシナリオ策定の雛形 |
+
+戦略分析の視点（why）と、アーキテクチャ分析の視点（how／what の構造）は異なるため、単純なコピーではなく「戦略で決まった方向性を、アーキテクチャの構造として再整理する」姿勢で取り込むこと。
+
+`business_strategy.md` が存在しない場合は、プロジェクトの基本情報（ビジョン、ミッション、ビジネス概要）をヒアリングして直接作成する。
+
+## 分析の進め方
+
+以下の順序で進める。各ステップの出力が次のステップの入力になるため、この順序を守ることで整合性の高い分析ができる。
+
+### 0. 入力の確認（任意）
+
+`docs/strategy/business_strategy.md` が存在するかを確認する。存在する場合は該当セクション（BMC、バリューストリーム、ケイパビリティマップ、組織マップ、ビジネスシナリオなど）を読み取り、各ステップで活用する。存在しない場合は次のステップから開始する。
+
+### 1. プリンシプルの定義
+
+ビジョン・ミッション・価値観に基づく方針を最初に固める。プリンシプルが曖昧だと、後続の分析で判断軸がブレる。
+
+- **ガイディングプリンシプル**: ビジネス・アプリケーション・データ・テクノロジーの各アーキテクチャに対する方針
+- **ビジネスプリンシプル**: ビジネスにおける原則原理
+
+### 2. ビジネスモデルの整理
+
+ビジネスモデルキャンバスを作成し、ビジネスの全体構造を 9 つの要素で可視化する。
+
+- 顧客セグメント、価値提案、チャネル、顧客関係
+- 主要活動、主要リソース、主要パートナー
+- 収益源、コスト構造
+
+### 3. バリューストリームの設計
+
+価値がどのように流れるかを可視化する。バリューストリームはケイパビリティモデルの土台になるため、ケイパビリティより先に作成する。
+
+- バリュー（価値）の分析
+- バリューストリームマップの作成
+- 各ステージでの価値増加の可視化
+
+### 4. ケイパビリティモデルの構築
+
+組織が持つ能力を体系的に整理する。バリューストリームの各ステージに必要なケイパビリティを紐付けることで、どの能力に投資すべきかが見える。
+
+- ケイパビリティの特定（戦略・コア・サポート）
+- 階層化とレベリング
+- ヒートマッピングによる成熟度評価
+- バリューストリームとのマッピング
+
+### 5. 組織マップの作成
+
+部門・組織構造を整理し、ケイパビリティとの対応付けを行う。
+
+### 6. 情報マップの作成
+
+ビジネスエンティティを特定し、エンティティ間のリレーションを整理する。後続のデータモデル設計の基礎になる。
+
+### 7. ビジネスシナリオの策定
+
+問題を特定・文書化し、ゴールと期待する結果を定義する。ヒューマンアクター・コンピュータアクターを特定し、後続のユースケース分析の入力とする。
+
+## 途中から再開する場合
+
+既存の `docs/strategy/business_architecture.md` がある場合は、まずその内容を確認する。完了済みのセクションはスキップし、未着手または更新が必要なセクションから再開する。
+
+**Example:**
+
+```
+ユーザー: 「ビジネスモデルキャンバスは作った。次は？」
+回答: バリューストリームの設計に進む。ビジネスモデルキャンバスで特定した
+      主要活動を基に、価値の流れを可視化する。
+```
+
+## 注意事項
+
+- プロジェクトの基本情報（ビジョン、ミッション、ビジネス概要）が提供されていることを確認してから分析を開始する
+- ビジネスアーキテクチャの重要な決定は ADR（`creating-adr`）で記録する
+- 成果物は PlantUML を活用して視覚的に文書化する
+- タスク項目（リスト）の前には空行を入れる（Markdown Lint 準拠）
+
+## 関連スキル
+
+- `analyzing-business-strategy` — 前段の戦略分析（成果物 `business_strategy.md` を本スキルの入力として活用可能）
+- `generating-bmc` — 本スキルの BMC セクションから SVG 図を生成
+- `analyzing-requirements` — 後続の要件定義（本スキルの成果物が入力）
+- `analyzing-usecases` — 後続のビジネスユースケース詳細化
+- `analyzing-architecture` — 後続のシステムアーキテクチャ設計への橋渡し
+- `orchestrating-analysis` — 分析フェーズ全体のワークフロー案内

package/lib/assets/.claude/skills/analyzing-business-case/SKILL.md

@@ -1,148 +1,148 @@
----
-name: analyzing-business-case
-description: 企業事例（ケーススタディ）の与件文作成を支援。経営戦略・マーケティング・生産管理・財務会計の 4 パターンから選択し、テンプレートのプレースホルダに対応する質問に回答することで与件文を生成する。「企業事例を作りたい」「ケーススタディを書きたい」「与件文を作成したい」「診断士試験の事例問題を作りたい」「仮想企業の事例を整理したい」といった場面で発動する。事例テンプレートに沿って体系的にヒアリングすることで、論理的整合性のある与件文を効率的に作成できる。
----
-
-# 企業事例作成
-
-企業事例（ケーススタディ）の与件文を、テンプレートに沿ったプレースホルダ置換方式で作成する。ユーザーへの体系的なヒアリングを通じてプレースホルダを埋め、自然な日本語の事例文として出力する。
-
-事例の型（テンプレート）を先に固定することで、論理の抜け漏れを防ぎ、診断・分析の前提となる「よい与件文」を短時間で作成できる。
-
-## 参照ドキュメントと成果物
-
-| 種類 | パス | 備考 |
-|------|------|------|
-| テンプレート | @docs/template/事例分析.md | 編集禁止。コピーして使用する |
-| 参考 | @docs/template/企業分析.md | 分析フレームワーク |
-| ガイド | @docs/reference/経営戦略分析ガイド.md | 事例作成の理論的背景と 4 パターンの詳細 |
-| 成果物 | `docs/strategy/business_case.md` | テンプレートを基に作成 |
-
-## 4 つのパターン
-
-事例のテーマによって以下から 1 つを選択する。複数テーマを含む場合は主テーマのパターンを採用し、副次的要素は他パターンから補完する。
-
-| パターン | テーマ | 代表的な論点 |
-|---------|-------|-------------|
-| 1 | 経営戦略（組織・人事） | 事業承継・組織設計・人材定着・役割分担 |
-| 2 | マーケティング戦略 | ターゲット顧客・商品戦略・チャネル・競争環境 |
-| 3 | 生産管理（生産・技術） | 工程管理・ボトルネック・技術継承・新規受注対応 |
-| 4 | 財務会計 | 財務分析・投資意思決定・資金調達・リスク |
-
-## 作成の進め方
-
-### ステップ 1：パターンの選択
-
-ユーザーに事例のテーマを確認し、4 つのパターンから 1 つを選択する。ユーザーがテーマを明示しない場合は「どのような論点を中心に据えるか？」と聞き、テーマを特定する。
-
-### ステップ 2：共通プレースホルダのヒアリング
-
-どのパターンでも必要になる基礎情報を最初にまとめてヒアリングする。既に会話やファイルで判明している情報は質問を省略する。
-
-ヒアリングする項目：
-
-- 企業略称（A社/B社 など、匿名化必須）
-- 業種
-- 資本金
-- 従業員数（正社員・パート内訳）
-- 売上高
-- 所在地・立地特性（地名は記号化：X 県 など）
-- 創業年
-- 現経営者の代・属性
-- 後継者の有無
-- 主力製品・サービス
-- 主要取引先・顧客層
-- 外部専門家への相談内容
-
-### ステップ 3：パターン固有プレースホルダのヒアリング
-
-選択したパターンの本文テンプレートを読み込み、プレースホルダを段落ごとに分割してヒアリングする。一度にすべてを聞くと回答者の負担が大きいため、段落単位で区切って進める。
-
-**ヒアリングの単位（パターン別の段落構成）**：
-
-- **パターン 1（経営戦略）**：企業概要 → 創業と沿革 → 事業変遷 → 組織構造・人事制度 → 現在の経営課題 → 相談
-- **パターン 2（マーケティング）**：企業概要 → 立地・商圏 → 創業沿革 → 商品特性・強み → 取引先・チャネル → 事業見直し → 外部環境変化 → 相談
-- **パターン 3（生産管理）**：企業概要 → 生産部門構成 → 主要プロセス → 生産計画・工程管理 → 各工程詳細 → 新規製品事業 → 相談
-- **パターン 4（財務会計）**：企業概要 → セグメント構成 → 貸借対照表・損益計算書の特徴 → 経営指標趨勢 → 投資計画 → 資金調達 → リスク要因 → 相談（加えて財務諸表の数値）
-
-段落ごとに質問を投げ、回答を受けてから次の段落に進む。これにより、話の流れが自然になり、論理的整合性も保たれる。
-
-### ステップ 4：パターン横断要素の統合
-
-テンプレートのパターンは万能ではなく、ユーザーが提供した情報の中には選択パターンに専用段落がないものが混じる。代表例は以下：
-
-| 要素 | パターン 1 | パターン 2 | パターン 3 | パターン 4 |
-|------|----------|----------|----------|----------|
-| 後継者情報 | 専用段落あり | 相談段落に統合 | **相談段落に統合** | 相談段落に統合 |
-| 財務数値 | 概要のみ | 概要のみ | 概要のみ | 専用段落あり |
-| 立地・商圏 | 概要のみ | **専用段落あり** | 概要のみ | 概要のみ |
-| 工程詳細 | 概要のみ | 概要のみ | **専用段落あり** | 概要のみ |
-
-**統合ルール**：選択パターンに専用段落がない要素は、最も近い段落（多くは「企業概要」または「外部専門家への相談」）に自然に織り込む。専用段落を新設したり、テンプレートにない見出しを追加してはいけない。
-
-### ステップ 5：整合性チェック
-
-プレースホルダの値を埋め終えたら、出力前に以下を確認する：
-
-- 時系列の前後関係は矛盾していないか（創業年 → 転機 → 現在）
-- 因果関係は自然か（外部ショック → 売上減少 → 事業転換）
-- 人物（現経営者・後継者）の年齢・経歴が矛盾していないか
-- パターン 4 の場合、財務数値の合計は一致しているか（資産 = 負債 + 純資産 など）
-- **文体の統一**：与件文は原則として常体（だ・である調）で統一する。敬体（です・ます調）との混在は避ける。テンプレート本文の文末表現に揃える
-
-矛盾があればユーザーに確認して修正する。
-
-### ステップ 6：与件文の生成
-
-テンプレートの本文部分に値を代入し、`docs/strategy/business_case.md` として出力する。構成は以下のとおり：
-
-```markdown
-# {{company_name}}の事例
-
-## 与件
-
-### （選択パターンの見出し構成）
-
-（本文テンプレートをプレースホルダ置換した文章）
-```
-
-以下のルールに従う：
-
-- 未使用プレースホルダを含む段落は削除する（テンプレート使用方法に準拠）
-- 段落順序はテンプレートを維持するが、自然さを損なう場合は因果関係・時系列を優先
-- 固有名詞は必ず匿名化（「X 県」「A 社」のような記号的表現）
-- パターン 4 の場合、財務諸表（BS・PL）の表も併せて出力する
-
-## ヒアリングのコツ
-
-**ユーザーが情報を持っていない場合**：仮の値を提案して確認を取る。「仮に資本金を 3,000 万円としておきますが、よろしいですか？」のように、決めないと先に進めない項目は提案して前に進める。
-
-**段落ごとに一旦確認**：各段落の本文ドラフトができたら、その段落だけを先にユーザーに見せてフィードバックを受ける。最後にまとめて見せると修正コストが大きい。
-
-**情報源がある場合**：実在企業の公開情報を参考にする場合は、必ず匿名化し、実在が特定できないよう数値や時期をぼかす。
-
-## 途中から再開する場合
-
-既存の `docs/strategy/business_case.md` がある場合は、まずその内容を確認する。どの段落まで埋まっているかを確認し、未記入のプレースホルダから再開する。
-
-**Example:**
-
-```
-ユーザー: 「企業概要と沿革は書いた。次は組織の話」
-回答: 既存の business_case.md を読み込み、パターンを特定した上で
-      組織構造・人事制度段落のヒアリングに進む。
-```
-
-## 注意事項
-
-- テンプレート（`docs/template/事例分析.md`）は編集禁止。読み取り専用として使用する
-- プレースホルダ名は snake_case（テンプレート定義に準拠）
-- 地名・企業名は必ず匿名化し、「X 県」「A 社」のような記号的表現で抽象度を保つ
-- タスク項目（リスト）の前には空行を入れる（Markdown Lint 準拠）
-- 出力先ディレクトリ `docs/strategy/` が存在しない場合は作成する
-
-## 関連スキル
-
-- `analyzing-business-architecture` — ビジネスアーキテクチャ分析（実プロジェクト向けの事業構造整理）
-- `analyzing-requirements` — 事例を入力として要件定義に進む場合
-- `creating-adr` — 事例作成で生じた設計判断の記録
+---
+name: analyzing-business-case
+description: 企業事例（ケーススタディ）の与件文作成を支援。経営戦略・マーケティング・生産管理・財務会計の 4 パターンから選択し、テンプレートのプレースホルダに対応する質問に回答することで与件文を生成する。「企業事例を作りたい」「ケーススタディを書きたい」「与件文を作成したい」「診断士試験の事例問題を作りたい」「仮想企業の事例を整理したい」といった場面で発動する。事例テンプレートに沿って体系的にヒアリングすることで、論理的整合性のある与件文を効率的に作成できる。
+---
+
+# 企業事例作成
+
+企業事例（ケーススタディ）の与件文を、テンプレートに沿ったプレースホルダ置換方式で作成する。ユーザーへの体系的なヒアリングを通じてプレースホルダを埋め、自然な日本語の事例文として出力する。
+
+事例の型（テンプレート）を先に固定することで、論理の抜け漏れを防ぎ、診断・分析の前提となる「よい与件文」を短時間で作成できる。
+
+## 参照ドキュメントと成果物
+
+| 種類 | パス | 備考 |
+|------|------|------|
+| テンプレート | @docs/template/事例分析.md | 編集禁止。コピーして使用する |
+| 参考 | @docs/template/企業分析.md | 分析フレームワーク |
+| ガイド | @docs/reference/経営戦略分析ガイド.md | 事例作成の理論的背景と 4 パターンの詳細 |
+| 成果物 | `docs/strategy/business_case.md` | テンプレートを基に作成 |
+
+## 4 つのパターン
+
+事例のテーマによって以下から 1 つを選択する。複数テーマを含む場合は主テーマのパターンを採用し、副次的要素は他パターンから補完する。
+
+| パターン | テーマ | 代表的な論点 |
+|---------|-------|-------------|
+| 1 | 経営戦略（組織・人事） | 事業承継・組織設計・人材定着・役割分担 |
+| 2 | マーケティング戦略 | ターゲット顧客・商品戦略・チャネル・競争環境 |
+| 3 | 生産管理（生産・技術） | 工程管理・ボトルネック・技術継承・新規受注対応 |
+| 4 | 財務会計 | 財務分析・投資意思決定・資金調達・リスク |
+
+## 作成の進め方
+
+### ステップ 1：パターンの選択
+
+ユーザーに事例のテーマを確認し、4 つのパターンから 1 つを選択する。ユーザーがテーマを明示しない場合は「どのような論点を中心に据えるか？」と聞き、テーマを特定する。
+
+### ステップ 2：共通プレースホルダのヒアリング
+
+どのパターンでも必要になる基礎情報を最初にまとめてヒアリングする。既に会話やファイルで判明している情報は質問を省略する。
+
+ヒアリングする項目：
+
+- 企業略称（A社/B社 など、匿名化必須）
+- 業種
+- 資本金
+- 従業員数（正社員・パート内訳）
+- 売上高
+- 所在地・立地特性（地名は記号化：X 県 など）
+- 創業年
+- 現経営者の代・属性
+- 後継者の有無
+- 主力製品・サービス
+- 主要取引先・顧客層
+- 外部専門家への相談内容
+
+### ステップ 3：パターン固有プレースホルダのヒアリング
+
+選択したパターンの本文テンプレートを読み込み、プレースホルダを段落ごとに分割してヒアリングする。一度にすべてを聞くと回答者の負担が大きいため、段落単位で区切って進める。
+
+**ヒアリングの単位（パターン別の段落構成）**：
+
+- **パターン 1（経営戦略）**：企業概要 → 創業と沿革 → 事業変遷 → 組織構造・人事制度 → 現在の経営課題 → 相談
+- **パターン 2（マーケティング）**：企業概要 → 立地・商圏 → 創業沿革 → 商品特性・強み → 取引先・チャネル → 事業見直し → 外部環境変化 → 相談
+- **パターン 3（生産管理）**：企業概要 → 生産部門構成 → 主要プロセス → 生産計画・工程管理 → 各工程詳細 → 新規製品事業 → 相談
+- **パターン 4（財務会計）**：企業概要 → セグメント構成 → 貸借対照表・損益計算書の特徴 → 経営指標趨勢 → 投資計画 → 資金調達 → リスク要因 → 相談（加えて財務諸表の数値）
+
+段落ごとに質問を投げ、回答を受けてから次の段落に進む。これにより、話の流れが自然になり、論理的整合性も保たれる。
+
+### ステップ 4：パターン横断要素の統合
+
+テンプレートのパターンは万能ではなく、ユーザーが提供した情報の中には選択パターンに専用段落がないものが混じる。代表例は以下：
+
+| 要素 | パターン 1 | パターン 2 | パターン 3 | パターン 4 |
+|------|----------|----------|----------|----------|
+| 後継者情報 | 専用段落あり | 相談段落に統合 | **相談段落に統合** | 相談段落に統合 |
+| 財務数値 | 概要のみ | 概要のみ | 概要のみ | 専用段落あり |
+| 立地・商圏 | 概要のみ | **専用段落あり** | 概要のみ | 概要のみ |
+| 工程詳細 | 概要のみ | 概要のみ | **専用段落あり** | 概要のみ |
+
+**統合ルール**：選択パターンに専用段落がない要素は、最も近い段落（多くは「企業概要」または「外部専門家への相談」）に自然に織り込む。専用段落を新設したり、テンプレートにない見出しを追加してはいけない。
+
+### ステップ 5：整合性チェック
+
+プレースホルダの値を埋め終えたら、出力前に以下を確認する：
+
+- 時系列の前後関係は矛盾していないか（創業年 → 転機 → 現在）
+- 因果関係は自然か（外部ショック → 売上減少 → 事業転換）
+- 人物（現経営者・後継者）の年齢・経歴が矛盾していないか
+- パターン 4 の場合、財務数値の合計は一致しているか（資産 = 負債 + 純資産 など）
+- **文体の統一**：与件文は原則として常体（だ・である調）で統一する。敬体（です・ます調）との混在は避ける。テンプレート本文の文末表現に揃える
+
+矛盾があればユーザーに確認して修正する。
+
+### ステップ 6：与件文の生成
+
+テンプレートの本文部分に値を代入し、`docs/strategy/business_case.md` として出力する。構成は以下のとおり：
+
+```markdown
+# {{company_name}}の事例
+
+## 与件
+
+### （選択パターンの見出し構成）
+
+（本文テンプレートをプレースホルダ置換した文章）
+```
+
+以下のルールに従う：
+
+- 未使用プレースホルダを含む段落は削除する（テンプレート使用方法に準拠）
+- 段落順序はテンプレートを維持するが、自然さを損なう場合は因果関係・時系列を優先
+- 固有名詞は必ず匿名化（「X 県」「A 社」のような記号的表現）
+- パターン 4 の場合、財務諸表（BS・PL）の表も併せて出力する
+
+## ヒアリングのコツ
+
+**ユーザーが情報を持っていない場合**：仮の値を提案して確認を取る。「仮に資本金を 3,000 万円としておきますが、よろしいですか？」のように、決めないと先に進めない項目は提案して前に進める。
+
+**段落ごとに一旦確認**：各段落の本文ドラフトができたら、その段落だけを先にユーザーに見せてフィードバックを受ける。最後にまとめて見せると修正コストが大きい。
+
+**情報源がある場合**：実在企業の公開情報を参考にする場合は、必ず匿名化し、実在が特定できないよう数値や時期をぼかす。
+
+## 途中から再開する場合
+
+既存の `docs/strategy/business_case.md` がある場合は、まずその内容を確認する。どの段落まで埋まっているかを確認し、未記入のプレースホルダから再開する。
+
+**Example:**
+
+```
+ユーザー: 「企業概要と沿革は書いた。次は組織の話」
+回答: 既存の business_case.md を読み込み、パターンを特定した上で
+      組織構造・人事制度段落のヒアリングに進む。
+```
+
+## 注意事項
+
+- テンプレート（`docs/template/事例分析.md`）は編集禁止。読み取り専用として使用する
+- プレースホルダ名は snake_case（テンプレート定義に準拠）
+- 地名・企業名は必ず匿名化し、「X 県」「A 社」のような記号的表現で抽象度を保つ
+- タスク項目（リスト）の前には空行を入れる（Markdown Lint 準拠）
+- 出力先ディレクトリ `docs/strategy/` が存在しない場合は作成する
+
+## 関連スキル
+
+- `analyzing-business-architecture` — ビジネスアーキテクチャ分析（実プロジェクト向けの事業構造整理）
+- `analyzing-requirements` — 事例を入力として要件定義に進む場合
+- `creating-adr` — 事例作成で生じた設計判断の記録