@k2works/claude-code-booster 4.4.0 → 4.4.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/bin/claude-code-booster +2 -2
- package/lib/assets/.claude/agents/xp-architect.md +250 -250
- package/lib/assets/.claude/agents/xp-executive.md +207 -207
- package/lib/assets/.claude/agents/xp-interaction-designer.md +239 -239
- package/lib/assets/.claude/agents/xp-product-manager.md +245 -245
- package/lib/assets/.claude/agents/xp-programmer.md +268 -268
- package/lib/assets/.claude/agents/xp-project-manager.md +229 -229
- package/lib/assets/.claude/agents/xp-technical-writer.md +224 -224
- package/lib/assets/.claude/agents/xp-tester.md +265 -265
- package/lib/assets/.claude/agents/xp-user-representative.md +204 -204
- package/lib/assets/.claude/skills/analyzing-business-case/SKILL.md +148 -148
- package/lib/assets/.claude/skills/analyzing-business-strategy/SKILL.md +277 -277
- package/lib/assets/.claude/skills/analyzing-review/SKILL.md +174 -174
- package/lib/assets/.claude/skills/creating-iteration-report/SKILL.md +210 -210
- package/lib/assets/.claude/skills/creating-release-report/SKILL.md +161 -161
- package/lib/assets/.claude/skills/developing-review/SKILL.md +175 -175
- package/lib/assets/.claude/skills/developing-uiux-review/SKILL.md +207 -207
- package/lib/assets/.claude/skills/generating-bmc/SKILL.md +123 -123
- package/lib/assets/.claude/skills/operating-qt/SKILL.md +147 -147
- package/lib/assets/.claude/skills/operating-review/SKILL.md +171 -171
- package/lib/assets/.claude/skills/operating-script/SKILL.md +145 -145
- package/lib/assets/.claude/skills/orchestrating-development/SKILL.md +168 -168
- package/lib/assets/.claude/skills/practicing-getting-start-tdd/SKILL.md +266 -266
- package/lib/assets/.claude/skills/validating-iteration-plan/SKILL.md +54 -54
- package/lib/assets/.devcontainer/devcontainer.json +1 -1
- package/lib/assets/.gitattributes +0 -2
- package/lib/assets/CLAUDE.md +193 -193
- package/lib/assets/Dockerfile +1 -6
- package/lib/assets/README.md +0 -16
- package/lib/assets/docs/article/functional-desgin-ppp/clojure/01-immutability-and-data-transformation.md +1 -1
- package/lib/assets/docs/article/functional-desgin-ppp/clojure/15-gossiping-bus-drivers.md +1 -1
- package/lib/assets/docs/article/functional-desgin-ppp/clojure/20-pattern-interactions.md +1 -1
- package/lib/assets/docs/article/functional-desgin-ppp/clojure/21-best-practices.md +6 -6
- package/lib/assets/docs/article/functional-desgin-ppp/clojure/22-oo-to-fp-migration.md +3 -3
- package/lib/assets/docs/article/functional-desgin-ppp/clojure/index.md +22 -22
- package/lib/assets/docs/article/functional-desgin-ppp/elixir/01-immutability-and-data-transformation.md +1 -1
- package/lib/assets/docs/article/functional-desgin-ppp/elixir/index.md +22 -22
- package/lib/assets/docs/article/functional-desgin-ppp/fsharp/01-immutability-and-data-transformation.md +1 -1
- package/lib/assets/docs/article/functional-desgin-ppp/fsharp/15-gossiping-bus-drivers.md +1 -1
- package/lib/assets/docs/article/functional-desgin-ppp/fsharp/17-video-rental-system.md +1 -1
- package/lib/assets/docs/article/functional-desgin-ppp/fsharp/19-wator-simulation.md +1 -1
- package/lib/assets/docs/article/functional-desgin-ppp/fsharp/21-best-practices.md +2 -2
- package/lib/assets/docs/article/functional-desgin-ppp/fsharp/22-oo-to-fp-migration.md +5 -5
- package/lib/assets/docs/article/functional-desgin-ppp/fsharp/index.md +22 -22
- package/lib/assets/docs/article/functional-desgin-ppp/haskell/15-gossiping-bus-drivers.md +1 -1
- package/lib/assets/docs/article/functional-desgin-ppp/haskell/20-pattern-interactions.md +1 -1
- package/lib/assets/docs/article/functional-desgin-ppp/rust/01-immutability-and-data-transformation.md +1 -1
- package/lib/assets/docs/article/functional-desgin-ppp/rust/index.md +22 -22
- package/lib/assets/docs/article/functional-desgin-ppp/scala/01-immutability-and-data-transformation.md +1 -1
- package/lib/assets/docs/article/functional-desgin-ppp/scala/15-gossiping-bus-drivers.md +1 -1
- package/lib/assets/docs/article/functional-desgin-ppp/scala/21-best-practices.md +3 -3
- package/lib/assets/docs/article/functional-desgin-ppp/scala/22-oo-to-fp-migration.md +3 -3
- package/lib/assets/docs/article/functional-desgin-ppp/scala/index.md +22 -22
- package/lib/assets/docs/article/getting-start-tdd/integration/04-type-system-comparison.md +2 -2
- package/lib/assets/docs/article/getting-start-tdd/integration/06-learning-roadmap.md +8 -8
- package/lib/assets/docs/article/getting-start-tdd/ruby/11-immutable-data-and-pipeline.md +2 -2
- package/lib/assets/docs/article/grokkingfp/all/part-2-ch03-immutable-data.md +3 -3
- package/lib/assets/docs/article/grokkingfp/all/part-3-ch06-option.md +4 -4
- package/lib/assets/docs/article/grokkingfp/all/writing-plan.md +8 -8
- package/lib/assets/docs/article/grokkingfp/elixir/part-1.md +1 -1
- package/lib/assets/docs/article/grokkingfp/elixir/part-5.md +1 -1
- package/lib/assets/docs/article/grokkingfp/elixir/part-6.md +1 -1
- package/lib/assets/docs/article/grokkingfp/fsharp/part-6.md +1 -1
- package/lib/assets/docs/article/grokkingfp/haskell/part-4.md +1 -1
- package/lib/assets/docs/article/grokkingfp/haskell/part-6.md +1 -1
- package/lib/assets/docs/article/grokkingfp/java/part-1.md +1 -1
- package/lib/assets/docs/article/grokkingfp/java/part-2.md +4 -4
- package/lib/assets/docs/article/grokkingfp/java/part-6.md +2 -2
- package/lib/assets/docs/article/grokkingfp/python/part-1.md +3 -3
- package/lib/assets/docs/article/grokkingfp/ruby/part-1.md +1 -1
- package/lib/assets/docs/article/grokkingfp/ruby/part-6.md +1 -1
- package/lib/assets/docs/article/grokkingfp/rust/part-4.md +1 -1
- package/lib/assets/docs/article/grokkingfp/scala/part-1.md +1 -1
- package/lib/assets/docs/article/grokkingfp/scala/part-3.md +1 -1
- package/lib/assets/docs/article/grokkingfp/scala/part-6.md +1 -1
- package/lib/assets/docs/article/grokkingfp/typescript/part-1.md +1 -1
- package/lib/assets/docs/article/grokkingfp/typescript/part-4.md +1 -1
- package/lib/assets/docs/article/grokkingfp/typescript/part-6.md +1 -1
- package/lib/assets/docs/article/index.md +39 -39
- package/lib/assets/docs/design/index.md +44 -44
- package/lib/assets/docs/index.md +33 -33
- package/lib/assets/docs/operation/index.md +16 -16
- package/lib/assets/docs/reference/CodexCLIMCP/343/202/242/343/203/227/343/203/252/343/202/261/343/203/274/343/202/267/343/203/247/343/203/263/351/226/213/347/231/272/343/203/225/343/203/255/343/203/274.md +546 -546
- package/lib/assets/docs/reference/SonarQube/343/203/255/343/203/274/343/202/253/343/203/253/347/222/260/345/242/203/343/202/273/343/203/203/343/203/210/343/202/242/343/203/203/343/203/227/346/211/213/351/240/206/346/233/270.md +1 -1
- package/lib/assets/docs/reference/UI/350/250/255/350/250/210/343/202/254/343/202/244/343/203/211.md +1 -1
- package/lib/assets/docs/reference/images/BMC.drawio.svg +3 -3
- package/lib/assets/docs/reference//347/265/214/345/226/266/346/210/246/347/225/245/345/210/206/346/236/220/343/202/254/343/202/244/343/203/211.md +566 -566
- package/lib/assets/docs/requirements/index.md +17 -17
- package/lib/assets/docs/strategy/index.md +17 -17
- package/lib/assets/docs/template//343/202/244/343/203/206/343/203/254/343/203/274/343/202/267/343/203/247/343/203/263/350/250/210/347/224/273.md +327 -327
- package/lib/assets/docs/template//343/203/252/343/203/252/343/203/274/343/202/271/345/256/214/344/272/206/345/240/261/345/221/212/346/233/270.md +275 -275
- package/lib/assets/docs/template//344/272/213/344/276/213/345/210/206/346/236/220.md +513 -513
- package/lib/assets/ops/docker/sonarqube-local/docker-compose.yml +57 -57
- package/lib/assets/ops/nix/shells/.tmux.conf +2 -2
- package/package.json +1 -1
- package/lib/assets/.envrc +0 -1
|
@@ -1,277 +1,277 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: analyzing-business-strategy
|
|
3
|
-
description: 企業事例(与件文)を基に企業戦略・事業戦略・機能戦略の 3 階層を体系的に立案。環境分析(SWOT・VRIO・BMC)から始めて、ドメイン定義・成長戦略・競争戦略・価値連鎖・ケイパビリティマップまで、PlantUML を活用した可視化ドキュメントを作成する。「戦略を立案したい」「企業戦略を作りたい」「事業戦略を策定したい」「SWOT 分析をしたい」「VRIO 分析をしたい」「成長戦略を考えたい」「競争戦略を立てたい」「価値連鎖を分析したい」「ケイパビリティマップを作りたい」「診断士試験の戦略分析をしたい」「企業事例から戦略を導出したい」といった場面で発動する。事例と戦略をセットで扱うことで、経営コンサルティングの提案書や中小企業診断士の答案に相当する体系的な戦略ドキュメントを作成できる。
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# 企業戦略分析
|
|
7
|
-
|
|
8
|
-
企業事例(与件文)を出発点として、企業戦略・事業戦略・機能戦略の 3 階層を論理的に導出し、可視化ドキュメントとして整理する。
|
|
9
|
-
|
|
10
|
-
戦略立案は「なぜその戦略なのか」の根拠が命であり、与件文から SWOT・VRIO・BMC を経由して戦略を導くことで、論理的整合性を担保できる。場当たり的に「差別化戦略がよい」と決めるのではなく、「与件の強み × 機会の組み合わせから差別化の方向性が導かれる」という筋道を示すことが重要。
|
|
11
|
-
|
|
12
|
-
## 参照ドキュメントと成果物
|
|
13
|
-
|
|
14
|
-
| 種類 | パス | 備考 |
|
|
15
|
-
|------|------|------|
|
|
16
|
-
| テンプレート | @docs/template/企業分析.md | 編集禁止。コピーして使用する |
|
|
17
|
-
| 入力 | @docs/strategy/business_case.md | `analyzing-business-case` スキルの出力 |
|
|
18
|
-
| ガイド | @docs/reference/経営戦略分析ガイド.md | 3 階層戦略の理論的背景・フレームワーク詳細 |
|
|
19
|
-
| 参考 | @docs/reference/ロジカルシンキング.md | 論理展開の基本(演繹・帰納) |
|
|
20
|
-
| 成果物 | `docs/strategy/business_strategy.md` | テンプレートを基に作成 |
|
|
21
|
-
| 後続成果物 | `docs/strategy/BMC.svg` | `generating-bmc` スキルで生成 |
|
|
22
|
-
|
|
23
|
-
## 3 階層の戦略構造
|
|
24
|
-
|
|
25
|
-
戦略は階層的に連鎖する。上位の戦略が下位の戦略の前提条件を決定するため、この順序で立案することが重要。
|
|
26
|
-
|
|
27
|
-
| 階層 | 問い | 主なフレームワーク |
|
|
28
|
-
|------|------|------------------|
|
|
29
|
-
| **企業戦略** | どの事業領域で戦うか? | ドメイン定義、Ansoff 成長戦略 |
|
|
30
|
-
| **事業戦略** | 各事業でどう競争するか? | Porter 基本戦略、競争地位別戦略、価値連鎖 |
|
|
31
|
-
| **機能戦略** | どう実行するか? | バリューストリーム、ケイパビリティマップ、組織マップ |
|
|
32
|
-
|
|
33
|
-
上位階層を飛ばして機能戦略だけを論じても、「なぜその機能が必要か」が答えられない。逆に企業戦略だけでは「絵に描いた餅」になる。3 階層を貫く論理のラインを作ることが、使える戦略ドキュメントの条件である。
|
|
34
|
-
|
|
35
|
-
## 立案の進め方
|
|
36
|
-
|
|
37
|
-
### ステップ 1:入力の確認
|
|
38
|
-
|
|
39
|
-
`docs/strategy/business_case.md` が存在することを確認する。存在しない場合は `analyzing-business-case` スキルを先に実行するか、ユーザーに事例情報をヒアリングする。
|
|
40
|
-
|
|
41
|
-
与件文から以下を抽出してメモしておく(各ステップで参照する):
|
|
42
|
-
|
|
43
|
-
- 企業基本情報(業種・規模・沿革・主力製品・主要取引先)
|
|
44
|
-
- 経営環境の変化(外部ショック・競争激化・技術変化)
|
|
45
|
-
- 内部リソース(技術・人材・設備・ノウハウ・ブランド)
|
|
46
|
-
- 現在の課題(事業承継・組織・人事・生産・財務)
|
|
47
|
-
- 相談内容(どの方向で助言を求めているか)
|
|
48
|
-
|
|
49
|
-
### ステップ 2:環境分析(事実ベースの整理)
|
|
50
|
-
|
|
51
|
-
戦略を考える前に、事実を整理する。ここで飛ばしやすいが、環境分析なしの戦略は主観の羅列になる。
|
|
52
|
-
|
|
53
|
-
#### 2-1. 組織図
|
|
54
|
-
|
|
55
|
-
与件から読み取れる組織構造を `@startwbs` で可視化する。不明な階層は「推定」と注記する。
|
|
56
|
-
|
|
57
|
-
#### 2-2. ビジネスモデル(BMC)
|
|
58
|
-
|
|
59
|
-
9 要素のマインドマップとして整理する。与件に明示されていない要素は、業種の一般論から推定してよい(ただし「推定」と明記)。
|
|
60
|
-
|
|
61
|
-
- 外部環境:競争・政治社会技術・マクロ経済・市場
|
|
62
|
-
- 内部環境(顧客):顧客セグメント
|
|
63
|
-
- 内部環境(価値):価値提案・チャネル・顧客関係
|
|
64
|
-
- 内部環境(インフラ):主要活動・主要リソース・主要パートナー
|
|
65
|
-
- 内部環境(資金):収益源・コスト構造
|
|
66
|
-
|
|
67
|
-
**`generating-bmc` との連携**:この BMC セクションは `generating-bmc` スキルが読み取る入力となる。見出しは `### ビジネスモデルキャンバス`(推奨)または `### ビジネスモデル`(テンプレート準拠)を使用し、PlantUML の `@startmindmap` ブロックで 9 要素を記述する。`generating-bmc` は両方の見出しを認識する。ルートノード名は `* ビジネスモデル` でも `* A 社ビジネスモデル` でもよい(事例名プレフィックス可)。重要なのは「顧客 / 価値 / インフラ / 資金」の 4 分類 → 9 要素の階層構造を維持することで、これにより `generating-bmc` がマインドマップを解析して SVG 図を生成できる。
|
|
68
|
-
|
|
69
|
-
```plantuml
|
|
70
|
-
@startmindmap
|
|
71
|
-
* ビジネスモデル
|
|
72
|
-
-- 外部環境
|
|
73
|
-
--- 競争
|
|
74
|
-
--- 政治・社会・技術
|
|
75
|
-
--- マクロ経済
|
|
76
|
-
--- 市場
|
|
77
|
-
** 内部環境
|
|
78
|
-
*** 顧客
|
|
79
|
-
**** 顧客セグメント(具体的なセグメント名)
|
|
80
|
-
*** 価値
|
|
81
|
-
**** 価値提案(独自の価値)
|
|
82
|
-
**** チャネル(販売経路)
|
|
83
|
-
**** 顧客関係(関係性)
|
|
84
|
-
*** インフラ
|
|
85
|
-
**** 主要活動(コア活動)
|
|
86
|
-
**** 主要リソース(重要資源)
|
|
87
|
-
**** 主要パートナー(協業先)
|
|
88
|
-
*** 資金
|
|
89
|
-
**** 収益源(収益モデル)
|
|
90
|
-
**** コスト構造(主要コスト)
|
|
91
|
-
@endmindmap
|
|
92
|
-
```
|
|
93
|
-
|
|
94
|
-
#### 2-3. SWOT 分析
|
|
95
|
-
|
|
96
|
-
SWOT は「強み × 機会」「弱み × 脅威」の交差から戦略の種が出てくるため、単に 4 象限を埋めるだけでなく、クロス SWOT を念頭に置いて整理する。
|
|
97
|
-
|
|
98
|
-
- 強み(Strength):与件から抽出できる固有の能力
|
|
99
|
-
- 弱み(Weakness):与件から読み取れる制約
|
|
100
|
-
- 機会(Opportunity):外部環境の追い風
|
|
101
|
-
- 脅威(Threat):外部環境の逆風
|
|
102
|
-
|
|
103
|
-
#### 2-4. VRIO 分析
|
|
104
|
-
|
|
105
|
-
SWOT で抽出した強みを、持続的競争優位性の観点で評価する。強みすべてが競争優位の源泉ではない。
|
|
106
|
-
|
|
107
|
-
- 経済的価値(Value):顧客にとって価値があるか
|
|
108
|
-
- 希少性(Rarity):競合が持っていないか
|
|
109
|
-
- 模倣困難性(Imitability):簡単に真似されないか
|
|
110
|
-
- 組織能力(Organization):強みを活用する組織体制があるか
|
|
111
|
-
|
|
112
|
-
### ステップ 3:企業戦略の立案
|
|
113
|
-
|
|
114
|
-
環境分析を踏まえて、「どの事業領域で戦うか」を定義する。
|
|
115
|
-
|
|
116
|
-
#### 3-1. ドメイン
|
|
117
|
-
|
|
118
|
-
- 企業ドメイン:理念・ビジョン・ミッション(与件から読み取れない場合は相談内容から推定)
|
|
119
|
-
- 事業ドメイン:誰に(ターゲット顧客)・何を(価値提案)・どのように(提供方法)
|
|
120
|
-
|
|
121
|
-
#### 3-2. 成長戦略(Ansoff)
|
|
122
|
-
|
|
123
|
-
既存市場 / 新規市場 × 既存製品 / 新規製品の 4 象限でどこを狙うかを決める。与件の「相談内容」が重要なヒントになる。
|
|
124
|
-
|
|
125
|
-
- 市場浸透:既存市場 × 既存製品
|
|
126
|
-
- 市場開発:新規市場 × 既存製品
|
|
127
|
-
- 商品開発:既存市場 × 新規製品
|
|
128
|
-
- 多角化:新規市場 × 新規製品(水平・垂直・集中・集成)
|
|
129
|
-
|
|
130
|
-
#### 3-3. 企業戦略のイシューツリー
|
|
131
|
-
|
|
132
|
-
ドメインと成長戦略を論点として、論理ツリーで整理する。
|
|
133
|
-
|
|
134
|
-
### ステップ 4:事業戦略の立案
|
|
135
|
-
|
|
136
|
-
企業戦略で定めた事業ドメインに対して、「どう競争するか」を決める。
|
|
137
|
-
|
|
138
|
-
#### 4-1. 基本戦略(Porter)
|
|
139
|
-
|
|
140
|
-
- コストリーダーシップ:低コスト実現
|
|
141
|
-
- 差別化:独自価値の提供
|
|
142
|
-
- 集中:特定セグメントへの集中
|
|
143
|
-
|
|
144
|
-
中小企業は経営資源が限られるため、基本は「差別化」または「集中」が現実的。与件の強み(VRIO で評価済み)が選択の根拠になる。
|
|
145
|
-
|
|
146
|
-
#### 4-2. 競争戦略(競争地位別)
|
|
147
|
-
|
|
148
|
-
- リーダー:市場拡大・同質化
|
|
149
|
-
- チャレンジャー:差別化
|
|
150
|
-
- ニッチャー:集中
|
|
151
|
-
- フォロワー:追随
|
|
152
|
-
|
|
153
|
-
与件の企業の市場シェア・規模から競争地位を判断する。中小企業はニッチャーかフォロワーが多い。
|
|
154
|
-
|
|
155
|
-
#### 4-3. 価値連鎖(Porter Value Chain)
|
|
156
|
-
|
|
157
|
-
- 主活動:購買物流・製造・出荷物流・マーケティング販売・サービス
|
|
158
|
-
- 支援活動:インフラ・人事労務・技術開発・調達
|
|
159
|
-
|
|
160
|
-
各活動のうち、強み(競争優位の源泉)となる活動と弱み(改善対象)となる活動を明示する。
|
|
161
|
-
|
|
162
|
-
#### 4-4. 事業戦略のイシューツリー
|
|
163
|
-
|
|
164
|
-
基本戦略・競争戦略・価値連鎖を論点として整理する。
|
|
165
|
-
|
|
166
|
-
### ステップ 5:機能戦略の立案
|
|
167
|
-
|
|
168
|
-
事業戦略を実行するための具体的な機能レベルの戦略を策定する。
|
|
169
|
-
|
|
170
|
-
#### 5-1. バリューストリーム
|
|
171
|
-
|
|
172
|
-
価値の流れを「主活動 → 支援活動 → 個別業務機能」の順で可視化する。テンプレートの `バリューストリーム` セクションをベースに、事例の業種特性に合わせて調整する。
|
|
173
|
-
|
|
174
|
-
#### 5-2. ケイパビリティマッピング
|
|
175
|
-
|
|
176
|
-
組織が持つ能力を「コア / 汎用 / サポート」に分類する。コアは競争優位の源泉、汎用はどの企業にも必要、サポートは業務支援機能。
|
|
177
|
-
|
|
178
|
-
- コア:競争優位に直結する能力(例:独自の製造技術、顧客対応力)
|
|
179
|
-
- 汎用:業界標準の業務能力(例:販売管理、在庫管理)
|
|
180
|
-
- サポート:間接業務(例:会計、給与計算)
|
|
181
|
-
|
|
182
|
-
#### 5-3. 組織マップ
|
|
183
|
-
|
|
184
|
-
ケイパビリティを組織構造にマッピングする。「どの部門がどのケイパビリティを担っているか」を可視化することで、組織の歪み(重複・欠落)が見える。
|
|
185
|
-
|
|
186
|
-
#### 5-4. 情報マップ
|
|
187
|
-
|
|
188
|
-
事業遂行に必要な主要情報エンティティと、情報の流れを整理する(後続のデータモデル設計の入力となる)。
|
|
189
|
-
|
|
190
|
-
#### 5-5. ビジネスシナリオ
|
|
191
|
-
|
|
192
|
-
事業戦略を実現するためのシナリオを物語形式で記述する。アクター・ゴール・期待する結果を明示する。
|
|
193
|
-
|
|
194
|
-
#### 5-6. 機能戦略のイシューツリー
|
|
195
|
-
|
|
196
|
-
機能戦略の論点を組織・ケイパビリティの観点で整理する。
|
|
197
|
-
|
|
198
|
-
### ステップ 6:業務分析(任意、詳細設計に進む場合)
|
|
199
|
-
|
|
200
|
-
機能戦略をさらに業務レベルに落とし込む。後続の要件定義・ドメインモデル設計の入力となる。
|
|
201
|
-
|
|
202
|
-
- **業務領域(サブドメイン)**:コア / 汎用 / サポートに分類
|
|
203
|
-
- **ビジネスコンテキスト**:システムと外部アクターの関係
|
|
204
|
-
- **ビジネスユースケース**:ユースケース図・シーケンス図・業務フロー図
|
|
205
|
-
|
|
206
|
-
この段階は任意であり、戦略ドキュメントとしてはステップ 5 までで完結する。後続の開発フェーズに進む場合に着手する。
|
|
207
|
-
|
|
208
|
-
### ステップ 7:論理整合性チェック
|
|
209
|
-
|
|
210
|
-
出力前に以下を確認する。3 階層の戦略が縦に貫かれているかが最重要。
|
|
211
|
-
|
|
212
|
-
- **縦の論理**:環境分析 → 企業戦略 → 事業戦略 → 機能戦略 の論理ラインは成立しているか
|
|
213
|
-
- **SWOT × 戦略**:強み・機会が採用した戦略の根拠になっているか
|
|
214
|
-
- **VRIO × 競争優位**:VRIO で高評価の強みが基本戦略・競争戦略の軸になっているか
|
|
215
|
-
- **与件との整合**:与件に記載された事実と矛盾していないか
|
|
216
|
-
- **相談内容への回答**:与件の「外部専門家への相談内容」に対する答えになっているか
|
|
217
|
-
|
|
218
|
-
矛盾や飛躍があれば、環境分析に立ち戻って再整理する。戦略の結論を変えるのではなく、論拠を足す方向で調整する。
|
|
219
|
-
|
|
220
|
-
### ステップ 8:成果物の出力
|
|
221
|
-
|
|
222
|
-
`docs/strategy/business_strategy.md` として出力する。テンプレートの見出し構成を維持し、各セクションに事例固有の内容を記述する。
|
|
223
|
-
|
|
224
|
-
- PlantUML の図は、テンプレートの構造をベースに事例の内容を反映
|
|
225
|
-
- 図の後に「考察」「根拠」を文章で補足(図だけでは戦略の意図が伝わらない)
|
|
226
|
-
- 与件の引用は最小限にとどめ、戦略の論拠として使う
|
|
227
|
-
|
|
228
|
-
### ステップ 9:BMC SVG の生成(後続タスク)
|
|
229
|
-
|
|
230
|
-
`business_strategy.md` 出力後、BMC を視覚的なキャンバス図として残したい場合は `generating-bmc` スキルを実行する。環境分析セクションの `### ビジネスモデルキャンバス` にある mindmap データが自動的に入力として使われる。
|
|
231
|
-
|
|
232
|
-
- 出力先:`docs/strategy/BMC.svg`
|
|
233
|
-
- 生成タイミング:`business_strategy.md` の初回作成時と BMC セクションを更新したとき
|
|
234
|
-
- 生成を推奨する理由:戦略ドキュメントは長文になるため、9 要素の全体像を一枚絵で示せる BMC 図はステークホルダーへの説明時に極めて有効
|
|
235
|
-
|
|
236
|
-
`generating-bmc` は `business_architecture.md` を既定の入力として想定しているが、本スキルの `business_strategy.md` も同等の mindmap フォーマットで BMC を持つため、入力パスを `docs/strategy/business_strategy.md` に切り替えれば利用できる。
|
|
237
|
-
|
|
238
|
-
## 戦略を導くコツ
|
|
239
|
-
|
|
240
|
-
**事実と解釈を分ける**:「従業員数 45 名」は事実、「人員不足である」は解釈。解釈には必ず根拠(他社比較・業務量など)を示す。
|
|
241
|
-
|
|
242
|
-
**フレームワークに縛られない**:テンプレートのフレームワーク(SWOT・VRIO・Ansoff 等)は道具であり目的ではない。無理に全項目を埋めるより、事例に本当に関係する項目に集中する。
|
|
243
|
-
|
|
244
|
-
**与件にない情報は「仮定」と明記**:推定が必要な場合、「業界平均から推定すると …」「同業他社の一般的な傾向から …」と明示する。
|
|
245
|
-
|
|
246
|
-
**イシューツリーは戦略の地図**:各階層のイシューツリーは、その階層で答えるべき論点のリスト。埋まらないイシューがあれば、その戦略は不完全。
|
|
247
|
-
|
|
248
|
-
## 途中から再開する場合
|
|
249
|
-
|
|
250
|
-
既存の `docs/strategy/business_strategy.md` がある場合は、まずその内容を確認する。どのセクションまで埋まっているかを確認し、未記入のセクションから再開する。
|
|
251
|
-
|
|
252
|
-
**Example:**
|
|
253
|
-
|
|
254
|
-
```
|
|
255
|
-
ユーザー: 「環境分析は終わった。企業戦略から進めたい」
|
|
256
|
-
回答: 既存の business_strategy.md を読み込み、SWOT・VRIO の内容を確認した上で、
|
|
257
|
-
ステップ 3(企業戦略の立案)からドメイン定義・成長戦略・イシューツリーの順で進める。
|
|
258
|
-
```
|
|
259
|
-
|
|
260
|
-
## 注意事項
|
|
261
|
-
|
|
262
|
-
- テンプレート(`docs/template/企業分析.md`)は編集禁止。読み取り専用として使用する
|
|
263
|
-
- 入力となる `business_case.md` が存在しない場合は、`analyzing-business-case` スキルを先に実行することを推奨
|
|
264
|
-
- PlantUML の図は事例固有の内容にカスタマイズする。テンプレートの例をそのままコピーしない
|
|
265
|
-
- 論拠のない戦略は書かない。「強みを活かして差別化」では不十分で、どの強みをどう活かすかを具体的に
|
|
266
|
-
- タスク項目(リスト)の前には空行を入れる(Markdown Lint 準拠)
|
|
267
|
-
- 出力先ディレクトリ `docs/strategy/` が存在しない場合は作成する
|
|
268
|
-
|
|
269
|
-
## 関連スキル
|
|
270
|
-
|
|
271
|
-
- `analyzing-business-case` — 前提となる事例(与件文)作成(本スキルの入力を生成)
|
|
272
|
-
- `analyzing-business-architecture` — ビジネスアーキテクチャ分析(実プロジェクトの事業構造整理)
|
|
273
|
-
- `generating-bmc` — 本スキルの BMC セクションから SVG 図を生成(後続の可視化タスク)
|
|
274
|
-
- `analyzing-inception-deck` — 後続のプロジェクト方向性整理
|
|
275
|
-
- `analyzing-requirements` — 後続の要件定義(機能戦略・業務分析を入力)
|
|
276
|
-
- `analyzing-domain-model` — 後続のドメインモデル設計(サブドメインを入力)
|
|
277
|
-
- `creating-adr` — 戦略選択の意思決定を記録
|
|
1
|
+
---
|
|
2
|
+
name: analyzing-business-strategy
|
|
3
|
+
description: 企業事例(与件文)を基に企業戦略・事業戦略・機能戦略の 3 階層を体系的に立案。環境分析(SWOT・VRIO・BMC)から始めて、ドメイン定義・成長戦略・競争戦略・価値連鎖・ケイパビリティマップまで、PlantUML を活用した可視化ドキュメントを作成する。「戦略を立案したい」「企業戦略を作りたい」「事業戦略を策定したい」「SWOT 分析をしたい」「VRIO 分析をしたい」「成長戦略を考えたい」「競争戦略を立てたい」「価値連鎖を分析したい」「ケイパビリティマップを作りたい」「診断士試験の戦略分析をしたい」「企業事例から戦略を導出したい」といった場面で発動する。事例と戦略をセットで扱うことで、経営コンサルティングの提案書や中小企業診断士の答案に相当する体系的な戦略ドキュメントを作成できる。
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# 企業戦略分析
|
|
7
|
+
|
|
8
|
+
企業事例(与件文)を出発点として、企業戦略・事業戦略・機能戦略の 3 階層を論理的に導出し、可視化ドキュメントとして整理する。
|
|
9
|
+
|
|
10
|
+
戦略立案は「なぜその戦略なのか」の根拠が命であり、与件文から SWOT・VRIO・BMC を経由して戦略を導くことで、論理的整合性を担保できる。場当たり的に「差別化戦略がよい」と決めるのではなく、「与件の強み × 機会の組み合わせから差別化の方向性が導かれる」という筋道を示すことが重要。
|
|
11
|
+
|
|
12
|
+
## 参照ドキュメントと成果物
|
|
13
|
+
|
|
14
|
+
| 種類 | パス | 備考 |
|
|
15
|
+
|------|------|------|
|
|
16
|
+
| テンプレート | @docs/template/企業分析.md | 編集禁止。コピーして使用する |
|
|
17
|
+
| 入力 | @docs/strategy/business_case.md | `analyzing-business-case` スキルの出力 |
|
|
18
|
+
| ガイド | @docs/reference/経営戦略分析ガイド.md | 3 階層戦略の理論的背景・フレームワーク詳細 |
|
|
19
|
+
| 参考 | @docs/reference/ロジカルシンキング.md | 論理展開の基本(演繹・帰納) |
|
|
20
|
+
| 成果物 | `docs/strategy/business_strategy.md` | テンプレートを基に作成 |
|
|
21
|
+
| 後続成果物 | `docs/strategy/BMC.svg` | `generating-bmc` スキルで生成 |
|
|
22
|
+
|
|
23
|
+
## 3 階層の戦略構造
|
|
24
|
+
|
|
25
|
+
戦略は階層的に連鎖する。上位の戦略が下位の戦略の前提条件を決定するため、この順序で立案することが重要。
|
|
26
|
+
|
|
27
|
+
| 階層 | 問い | 主なフレームワーク |
|
|
28
|
+
|------|------|------------------|
|
|
29
|
+
| **企業戦略** | どの事業領域で戦うか? | ドメイン定義、Ansoff 成長戦略 |
|
|
30
|
+
| **事業戦略** | 各事業でどう競争するか? | Porter 基本戦略、競争地位別戦略、価値連鎖 |
|
|
31
|
+
| **機能戦略** | どう実行するか? | バリューストリーム、ケイパビリティマップ、組織マップ |
|
|
32
|
+
|
|
33
|
+
上位階層を飛ばして機能戦略だけを論じても、「なぜその機能が必要か」が答えられない。逆に企業戦略だけでは「絵に描いた餅」になる。3 階層を貫く論理のラインを作ることが、使える戦略ドキュメントの条件である。
|
|
34
|
+
|
|
35
|
+
## 立案の進め方
|
|
36
|
+
|
|
37
|
+
### ステップ 1:入力の確認
|
|
38
|
+
|
|
39
|
+
`docs/strategy/business_case.md` が存在することを確認する。存在しない場合は `analyzing-business-case` スキルを先に実行するか、ユーザーに事例情報をヒアリングする。
|
|
40
|
+
|
|
41
|
+
与件文から以下を抽出してメモしておく(各ステップで参照する):
|
|
42
|
+
|
|
43
|
+
- 企業基本情報(業種・規模・沿革・主力製品・主要取引先)
|
|
44
|
+
- 経営環境の変化(外部ショック・競争激化・技術変化)
|
|
45
|
+
- 内部リソース(技術・人材・設備・ノウハウ・ブランド)
|
|
46
|
+
- 現在の課題(事業承継・組織・人事・生産・財務)
|
|
47
|
+
- 相談内容(どの方向で助言を求めているか)
|
|
48
|
+
|
|
49
|
+
### ステップ 2:環境分析(事実ベースの整理)
|
|
50
|
+
|
|
51
|
+
戦略を考える前に、事実を整理する。ここで飛ばしやすいが、環境分析なしの戦略は主観の羅列になる。
|
|
52
|
+
|
|
53
|
+
#### 2-1. 組織図
|
|
54
|
+
|
|
55
|
+
与件から読み取れる組織構造を `@startwbs` で可視化する。不明な階層は「推定」と注記する。
|
|
56
|
+
|
|
57
|
+
#### 2-2. ビジネスモデル(BMC)
|
|
58
|
+
|
|
59
|
+
9 要素のマインドマップとして整理する。与件に明示されていない要素は、業種の一般論から推定してよい(ただし「推定」と明記)。
|
|
60
|
+
|
|
61
|
+
- 外部環境:競争・政治社会技術・マクロ経済・市場
|
|
62
|
+
- 内部環境(顧客):顧客セグメント
|
|
63
|
+
- 内部環境(価値):価値提案・チャネル・顧客関係
|
|
64
|
+
- 内部環境(インフラ):主要活動・主要リソース・主要パートナー
|
|
65
|
+
- 内部環境(資金):収益源・コスト構造
|
|
66
|
+
|
|
67
|
+
**`generating-bmc` との連携**:この BMC セクションは `generating-bmc` スキルが読み取る入力となる。見出しは `### ビジネスモデルキャンバス`(推奨)または `### ビジネスモデル`(テンプレート準拠)を使用し、PlantUML の `@startmindmap` ブロックで 9 要素を記述する。`generating-bmc` は両方の見出しを認識する。ルートノード名は `* ビジネスモデル` でも `* A 社ビジネスモデル` でもよい(事例名プレフィックス可)。重要なのは「顧客 / 価値 / インフラ / 資金」の 4 分類 → 9 要素の階層構造を維持することで、これにより `generating-bmc` がマインドマップを解析して SVG 図を生成できる。
|
|
68
|
+
|
|
69
|
+
```plantuml
|
|
70
|
+
@startmindmap
|
|
71
|
+
* ビジネスモデル
|
|
72
|
+
-- 外部環境
|
|
73
|
+
--- 競争
|
|
74
|
+
--- 政治・社会・技術
|
|
75
|
+
--- マクロ経済
|
|
76
|
+
--- 市場
|
|
77
|
+
** 内部環境
|
|
78
|
+
*** 顧客
|
|
79
|
+
**** 顧客セグメント(具体的なセグメント名)
|
|
80
|
+
*** 価値
|
|
81
|
+
**** 価値提案(独自の価値)
|
|
82
|
+
**** チャネル(販売経路)
|
|
83
|
+
**** 顧客関係(関係性)
|
|
84
|
+
*** インフラ
|
|
85
|
+
**** 主要活動(コア活動)
|
|
86
|
+
**** 主要リソース(重要資源)
|
|
87
|
+
**** 主要パートナー(協業先)
|
|
88
|
+
*** 資金
|
|
89
|
+
**** 収益源(収益モデル)
|
|
90
|
+
**** コスト構造(主要コスト)
|
|
91
|
+
@endmindmap
|
|
92
|
+
```
|
|
93
|
+
|
|
94
|
+
#### 2-3. SWOT 分析
|
|
95
|
+
|
|
96
|
+
SWOT は「強み × 機会」「弱み × 脅威」の交差から戦略の種が出てくるため、単に 4 象限を埋めるだけでなく、クロス SWOT を念頭に置いて整理する。
|
|
97
|
+
|
|
98
|
+
- 強み(Strength):与件から抽出できる固有の能力
|
|
99
|
+
- 弱み(Weakness):与件から読み取れる制約
|
|
100
|
+
- 機会(Opportunity):外部環境の追い風
|
|
101
|
+
- 脅威(Threat):外部環境の逆風
|
|
102
|
+
|
|
103
|
+
#### 2-4. VRIO 分析
|
|
104
|
+
|
|
105
|
+
SWOT で抽出した強みを、持続的競争優位性の観点で評価する。強みすべてが競争優位の源泉ではない。
|
|
106
|
+
|
|
107
|
+
- 経済的価値(Value):顧客にとって価値があるか
|
|
108
|
+
- 希少性(Rarity):競合が持っていないか
|
|
109
|
+
- 模倣困難性(Imitability):簡単に真似されないか
|
|
110
|
+
- 組織能力(Organization):強みを活用する組織体制があるか
|
|
111
|
+
|
|
112
|
+
### ステップ 3:企業戦略の立案
|
|
113
|
+
|
|
114
|
+
環境分析を踏まえて、「どの事業領域で戦うか」を定義する。
|
|
115
|
+
|
|
116
|
+
#### 3-1. ドメイン
|
|
117
|
+
|
|
118
|
+
- 企業ドメイン:理念・ビジョン・ミッション(与件から読み取れない場合は相談内容から推定)
|
|
119
|
+
- 事業ドメイン:誰に(ターゲット顧客)・何を(価値提案)・どのように(提供方法)
|
|
120
|
+
|
|
121
|
+
#### 3-2. 成長戦略(Ansoff)
|
|
122
|
+
|
|
123
|
+
既存市場 / 新規市場 × 既存製品 / 新規製品の 4 象限でどこを狙うかを決める。与件の「相談内容」が重要なヒントになる。
|
|
124
|
+
|
|
125
|
+
- 市場浸透:既存市場 × 既存製品
|
|
126
|
+
- 市場開発:新規市場 × 既存製品
|
|
127
|
+
- 商品開発:既存市場 × 新規製品
|
|
128
|
+
- 多角化:新規市場 × 新規製品(水平・垂直・集中・集成)
|
|
129
|
+
|
|
130
|
+
#### 3-3. 企業戦略のイシューツリー
|
|
131
|
+
|
|
132
|
+
ドメインと成長戦略を論点として、論理ツリーで整理する。
|
|
133
|
+
|
|
134
|
+
### ステップ 4:事業戦略の立案
|
|
135
|
+
|
|
136
|
+
企業戦略で定めた事業ドメインに対して、「どう競争するか」を決める。
|
|
137
|
+
|
|
138
|
+
#### 4-1. 基本戦略(Porter)
|
|
139
|
+
|
|
140
|
+
- コストリーダーシップ:低コスト実現
|
|
141
|
+
- 差別化:独自価値の提供
|
|
142
|
+
- 集中:特定セグメントへの集中
|
|
143
|
+
|
|
144
|
+
中小企業は経営資源が限られるため、基本は「差別化」または「集中」が現実的。与件の強み(VRIO で評価済み)が選択の根拠になる。
|
|
145
|
+
|
|
146
|
+
#### 4-2. 競争戦略(競争地位別)
|
|
147
|
+
|
|
148
|
+
- リーダー:市場拡大・同質化
|
|
149
|
+
- チャレンジャー:差別化
|
|
150
|
+
- ニッチャー:集中
|
|
151
|
+
- フォロワー:追随
|
|
152
|
+
|
|
153
|
+
与件の企業の市場シェア・規模から競争地位を判断する。中小企業はニッチャーかフォロワーが多い。
|
|
154
|
+
|
|
155
|
+
#### 4-3. 価値連鎖(Porter Value Chain)
|
|
156
|
+
|
|
157
|
+
- 主活動:購買物流・製造・出荷物流・マーケティング販売・サービス
|
|
158
|
+
- 支援活動:インフラ・人事労務・技術開発・調達
|
|
159
|
+
|
|
160
|
+
各活動のうち、強み(競争優位の源泉)となる活動と弱み(改善対象)となる活動を明示する。
|
|
161
|
+
|
|
162
|
+
#### 4-4. 事業戦略のイシューツリー
|
|
163
|
+
|
|
164
|
+
基本戦略・競争戦略・価値連鎖を論点として整理する。
|
|
165
|
+
|
|
166
|
+
### ステップ 5:機能戦略の立案
|
|
167
|
+
|
|
168
|
+
事業戦略を実行するための具体的な機能レベルの戦略を策定する。
|
|
169
|
+
|
|
170
|
+
#### 5-1. バリューストリーム
|
|
171
|
+
|
|
172
|
+
価値の流れを「主活動 → 支援活動 → 個別業務機能」の順で可視化する。テンプレートの `バリューストリーム` セクションをベースに、事例の業種特性に合わせて調整する。
|
|
173
|
+
|
|
174
|
+
#### 5-2. ケイパビリティマッピング
|
|
175
|
+
|
|
176
|
+
組織が持つ能力を「コア / 汎用 / サポート」に分類する。コアは競争優位の源泉、汎用はどの企業にも必要、サポートは業務支援機能。
|
|
177
|
+
|
|
178
|
+
- コア:競争優位に直結する能力(例:独自の製造技術、顧客対応力)
|
|
179
|
+
- 汎用:業界標準の業務能力(例:販売管理、在庫管理)
|
|
180
|
+
- サポート:間接業務(例:会計、給与計算)
|
|
181
|
+
|
|
182
|
+
#### 5-3. 組織マップ
|
|
183
|
+
|
|
184
|
+
ケイパビリティを組織構造にマッピングする。「どの部門がどのケイパビリティを担っているか」を可視化することで、組織の歪み(重複・欠落)が見える。
|
|
185
|
+
|
|
186
|
+
#### 5-4. 情報マップ
|
|
187
|
+
|
|
188
|
+
事業遂行に必要な主要情報エンティティと、情報の流れを整理する(後続のデータモデル設計の入力となる)。
|
|
189
|
+
|
|
190
|
+
#### 5-5. ビジネスシナリオ
|
|
191
|
+
|
|
192
|
+
事業戦略を実現するためのシナリオを物語形式で記述する。アクター・ゴール・期待する結果を明示する。
|
|
193
|
+
|
|
194
|
+
#### 5-6. 機能戦略のイシューツリー
|
|
195
|
+
|
|
196
|
+
機能戦略の論点を組織・ケイパビリティの観点で整理する。
|
|
197
|
+
|
|
198
|
+
### ステップ 6:業務分析(任意、詳細設計に進む場合)
|
|
199
|
+
|
|
200
|
+
機能戦略をさらに業務レベルに落とし込む。後続の要件定義・ドメインモデル設計の入力となる。
|
|
201
|
+
|
|
202
|
+
- **業務領域(サブドメイン)**:コア / 汎用 / サポートに分類
|
|
203
|
+
- **ビジネスコンテキスト**:システムと外部アクターの関係
|
|
204
|
+
- **ビジネスユースケース**:ユースケース図・シーケンス図・業務フロー図
|
|
205
|
+
|
|
206
|
+
この段階は任意であり、戦略ドキュメントとしてはステップ 5 までで完結する。後続の開発フェーズに進む場合に着手する。
|
|
207
|
+
|
|
208
|
+
### ステップ 7:論理整合性チェック
|
|
209
|
+
|
|
210
|
+
出力前に以下を確認する。3 階層の戦略が縦に貫かれているかが最重要。
|
|
211
|
+
|
|
212
|
+
- **縦の論理**:環境分析 → 企業戦略 → 事業戦略 → 機能戦略 の論理ラインは成立しているか
|
|
213
|
+
- **SWOT × 戦略**:強み・機会が採用した戦略の根拠になっているか
|
|
214
|
+
- **VRIO × 競争優位**:VRIO で高評価の強みが基本戦略・競争戦略の軸になっているか
|
|
215
|
+
- **与件との整合**:与件に記載された事実と矛盾していないか
|
|
216
|
+
- **相談内容への回答**:与件の「外部専門家への相談内容」に対する答えになっているか
|
|
217
|
+
|
|
218
|
+
矛盾や飛躍があれば、環境分析に立ち戻って再整理する。戦略の結論を変えるのではなく、論拠を足す方向で調整する。
|
|
219
|
+
|
|
220
|
+
### ステップ 8:成果物の出力
|
|
221
|
+
|
|
222
|
+
`docs/strategy/business_strategy.md` として出力する。テンプレートの見出し構成を維持し、各セクションに事例固有の内容を記述する。
|
|
223
|
+
|
|
224
|
+
- PlantUML の図は、テンプレートの構造をベースに事例の内容を反映
|
|
225
|
+
- 図の後に「考察」「根拠」を文章で補足(図だけでは戦略の意図が伝わらない)
|
|
226
|
+
- 与件の引用は最小限にとどめ、戦略の論拠として使う
|
|
227
|
+
|
|
228
|
+
### ステップ 9:BMC SVG の生成(後続タスク)
|
|
229
|
+
|
|
230
|
+
`business_strategy.md` 出力後、BMC を視覚的なキャンバス図として残したい場合は `generating-bmc` スキルを実行する。環境分析セクションの `### ビジネスモデルキャンバス` にある mindmap データが自動的に入力として使われる。
|
|
231
|
+
|
|
232
|
+
- 出力先:`docs/strategy/BMC.svg`
|
|
233
|
+
- 生成タイミング:`business_strategy.md` の初回作成時と BMC セクションを更新したとき
|
|
234
|
+
- 生成を推奨する理由:戦略ドキュメントは長文になるため、9 要素の全体像を一枚絵で示せる BMC 図はステークホルダーへの説明時に極めて有効
|
|
235
|
+
|
|
236
|
+
`generating-bmc` は `business_architecture.md` を既定の入力として想定しているが、本スキルの `business_strategy.md` も同等の mindmap フォーマットで BMC を持つため、入力パスを `docs/strategy/business_strategy.md` に切り替えれば利用できる。
|
|
237
|
+
|
|
238
|
+
## 戦略を導くコツ
|
|
239
|
+
|
|
240
|
+
**事実と解釈を分ける**:「従業員数 45 名」は事実、「人員不足である」は解釈。解釈には必ず根拠(他社比較・業務量など)を示す。
|
|
241
|
+
|
|
242
|
+
**フレームワークに縛られない**:テンプレートのフレームワーク(SWOT・VRIO・Ansoff 等)は道具であり目的ではない。無理に全項目を埋めるより、事例に本当に関係する項目に集中する。
|
|
243
|
+
|
|
244
|
+
**与件にない情報は「仮定」と明記**:推定が必要な場合、「業界平均から推定すると …」「同業他社の一般的な傾向から …」と明示する。
|
|
245
|
+
|
|
246
|
+
**イシューツリーは戦略の地図**:各階層のイシューツリーは、その階層で答えるべき論点のリスト。埋まらないイシューがあれば、その戦略は不完全。
|
|
247
|
+
|
|
248
|
+
## 途中から再開する場合
|
|
249
|
+
|
|
250
|
+
既存の `docs/strategy/business_strategy.md` がある場合は、まずその内容を確認する。どのセクションまで埋まっているかを確認し、未記入のセクションから再開する。
|
|
251
|
+
|
|
252
|
+
**Example:**
|
|
253
|
+
|
|
254
|
+
```
|
|
255
|
+
ユーザー: 「環境分析は終わった。企業戦略から進めたい」
|
|
256
|
+
回答: 既存の business_strategy.md を読み込み、SWOT・VRIO の内容を確認した上で、
|
|
257
|
+
ステップ 3(企業戦略の立案)からドメイン定義・成長戦略・イシューツリーの順で進める。
|
|
258
|
+
```
|
|
259
|
+
|
|
260
|
+
## 注意事項
|
|
261
|
+
|
|
262
|
+
- テンプレート(`docs/template/企業分析.md`)は編集禁止。読み取り専用として使用する
|
|
263
|
+
- 入力となる `business_case.md` が存在しない場合は、`analyzing-business-case` スキルを先に実行することを推奨
|
|
264
|
+
- PlantUML の図は事例固有の内容にカスタマイズする。テンプレートの例をそのままコピーしない
|
|
265
|
+
- 論拠のない戦略は書かない。「強みを活かして差別化」では不十分で、どの強みをどう活かすかを具体的に
|
|
266
|
+
- タスク項目(リスト)の前には空行を入れる(Markdown Lint 準拠)
|
|
267
|
+
- 出力先ディレクトリ `docs/strategy/` が存在しない場合は作成する
|
|
268
|
+
|
|
269
|
+
## 関連スキル
|
|
270
|
+
|
|
271
|
+
- `analyzing-business-case` — 前提となる事例(与件文)作成(本スキルの入力を生成)
|
|
272
|
+
- `analyzing-business-architecture` — ビジネスアーキテクチャ分析(実プロジェクトの事業構造整理)
|
|
273
|
+
- `generating-bmc` — 本スキルの BMC セクションから SVG 図を生成(後続の可視化タスク)
|
|
274
|
+
- `analyzing-inception-deck` — 後続のプロジェクト方向性整理
|
|
275
|
+
- `analyzing-requirements` — 後続の要件定義(機能戦略・業務分析を入力)
|
|
276
|
+
- `analyzing-domain-model` — 後続のドメインモデル設計(サブドメインを入力)
|
|
277
|
+
- `creating-adr` — 戦略選択の意思決定を記録
|