@k2works/claude-code-booster 4.4.1 → 4.5.0

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` — 事例作成で生じた設計判断の記録