目標設定・実行管理フレームワーク

目標設定・実行管理フレームワーク

ユーザーの $ARGUMENTS に基づき、以下のフレームワークから適切なものを適用してください。

---

01. OKR（Objectives and Key Results）

目的: 野心的な目標と定量的な成果指標を紐づけて、組織の方向性を揃える

いつ使うか: 組織やチームが「何を目指すか」を明確にし、全員の方向性を合わせたいとき。特に、成長フェーズの企業や新規事業立ち上げ時に有効。

テンプレート:

レベル	Objective（目標）	Key Result 1	Key Result 2	Key Result 3
全社
チーム
個人

ルール:

• Objectiveは定性的・挑戦的（ワクワクするもの）
• Key Resultは定量的・測定可能（達成度60-70%が理想的な難易度）
• 四半期ごとに設定・振り返り
• Key Resultは各Objectiveに対し2〜5個が適切（多すぎると焦点がぼやける）
• OKRは評価制度と直結させない（挑戦を萎縮させるため）

記入例（SaaS企業の例）:

レベル	Objective（目標）	Key Result 1	Key Result 2	Key Result 3
全社	プロダクト主導の成長エンジンを確立し、国内No.1のHRテックになる	ARR 5億円→8億円	NPS 40→60	チャーンレート 3%→1.5%
チーム（プロダクト）	ユーザーが毎日使いたくなるプロダクト体験を実現する	DAU/MAU比率 30%→50%	オンボーディング完了率 40%→75%	機能リクエスト対応率 60%→80%
個人（エンジニア）	プロダクトの信頼性と開発速度を両立する	デプロイ頻度 週1→日1	本番障害 月3件→月0件	PR レビュー待ち時間 24h→4h

よくある失敗:

• Key Resultがタスクになっている: 「ブログ記事を10本書く」はKey Resultではなくタスク。Key Resultは「オーガニック流入 月5,000→15,000」のように成果で定義する
• Objectiveが平凡すぎる: 「売上を伸ばす」では方向性が見えない。「〇〇業界のデファクトスタンダードになる」のように、チームが奮起する表現にする
• 全社OKRとチームOKRが無関係: 各レベルのOKRは上位目標と論理的につながっている必要がある。完全なカスケードではなく、60%程度の整合性を意識する

活用のヒント:

• 最初は全社で1〜3個のObjectiveに絞る。多すぎるOKRは「何も優先していない」のと同じ
• Key Resultの進捗は毎週チェックイン（15分）で確認する。四半期末の振り返りだけでは手遅れ
• 「Committed OKR（必達）」と「Aspirational OKR（挑戦的）」を区別すると運用しやすい
• OKR導入初期は、まず1チームでパイロット運用してから全社展開する

次のステップ:

• Key Resultを因数分解したい → 02. KPIツリー
• 個々のKey Resultを具体的なアクションに落としたい → 03. SMART
• OKRの達成状況を多角的に評価したい → 07. バランスト・スコアカード（BSC）
• 戦略の方向性を先に整理したい → strategyスキル（SWOT分析、ポーターの基本戦略）
• チームの役割分担を明確にしたい → organizationスキル（RACI）

---

02. KPIツリー

目的: 最終目標（KGI）を因数分解し、各レイヤーのKPIと担当を明確にする

いつ使うか: 「売上を上げたい」「コストを下げたい」等の大きな目標を、具体的な打ち手に分解したいとき。数字で管理できるビジネスに特に有効。

テンプレート:

KGI: 売上 ○○円
├── KPI: 顧客数 × 客単価
│   ├── KPI: 新規顧客数
│   │   ├── KPI: リード数 × CVR
│   │   └── 担当: マーケティング
│   └── KPI: 既存顧客LTV
│       └── 担当: カスタマーサクセス
└── ...

使い方: KGIから逆算してツリーを作る。各KPIに担当者とアクションを紐づける。分解は「足し算（A = B + C）」か「掛け算（A = B × C）」の関係になるようにする。

記入例（ECサイトの例）:

KGI: 月間売上 5,000万円
├── 新規顧客売上 = 新規購入者数 × 初回購入単価
│   ├── 新規購入者数 = サイト訪問数 × 購入CVR
│   │   ├── サイト訪問数 = 50万/月 → 目標: 70万/月
│   │   │   ├── 広告流入: 20万 → 目標: 30万（担当: 広告運用チーム）
│   │   │   ├── SEO流入: 15万 → 目標: 20万（担当: コンテンツチーム）
│   │   │   └── SNS流入: 15万 → 目標: 20万（担当: SNSチーム）
│   │   └── 購入CVR = 2.0% → 目標: 2.8%（担当: UI/UXチーム）
│   └── 初回購入単価 = 4,500円 → 目標: 5,000円（担当: MD）
├── 既存顧客売上 = リピーター数 × リピート単価 × 購入頻度
│   ├── リピーター数 = 前月購入者 × リピート率
│   │   └── リピート率 = 25% → 目標: 35%（担当: CRM）
│   ├── リピート単価 = 6,000円 → 目標: 7,000円（担当: MD）
│   └── 購入頻度 = 1.2回/月 → 目標: 1.5回/月（担当: CRM）

よくある失敗:

• 分解のロジックが崩れている: 「売上 = 顧客数 × 客単価」は正しいが、途中で「ブランド認知度」など直接計算できない指標を混ぜると、ツリーの整合性が壊れる
• 末端KPIが多すぎて管理不能: 4階層以上に分解すると、現場は何を追えばいいかわからなくなる。各チームが追うKPIは2〜3個に絞る
• KPIだけ設定してアクションがない: KPIツリーは「何を測るか」の地図であり、「どうやって改善するか」のアクションプランとセットで初めて機能する

活用のヒント:

• まず「四則演算で分解できるか」を確認する。できない場合はKPIツリー以外の手法（BSCなど）を検討する
• 各KPIに「現状値」「目標値」「ギャップ」を記入し、ギャップが最も大きいKPIから優先的に改善する
• 週次ダッシュボードでKPIを自動追跡する仕組みを作ると運用が定着する
• KPIツリーは「仮説」であり、定期的に構造自体を見直す

次のステップ:

• 各KPIの改善施策を洗い出したい → ideaスキル（ブレインストーミング）
• ボトルネックのKPIを深掘りしたい → problemスキル（ロジックツリー、なぜなぜ分析）
• SaaS/アプリのKPIを設計したい → 04. AARRR（海賊指標）
• KGI自体を見直したい → 01. OKR
• 業務プロセスの改善でKPIを上げたい → improvementスキル（バリューストリームマッピング）

---

03. SMART

目的: 目標を5つの基準で具体化し、実行可能な形にする

いつ使うか: 「なんとなく」の目標を「実行に移せるレベル」まで具体化したいとき。個人の目標設定、プロジェクトのマイルストーン定義、チームの行動計画に有効。

テンプレート:

基準	チェック	内容
Specific（具体的）	□	何を達成するのか？
Measurable（測定可能）	□	どう測るのか？数値は？
Achievable（達成可能）	□	現実的に達成できるか？
Relevant（関連性）	□	上位目標と整合しているか？
Time-bound（期限付き）	□	いつまでに？

SMARTな目標文: 「[期限]までに、[具体的な対象]の[測定指標]を[現状値]から[目標値]に改善する。」

記入例（マーケティングチームの例）:

曖昧な目標: 「SNSのフォロワーを増やしたい」

基準	チェック	内容
Specific（具体的）	✅	公式Xアカウントのフォロワー数を増やし、リード獲得チャネルとして確立する
Measurable（測定可能）	✅	フォロワー数 5,000→15,000、X経由のリード獲得 月20件→月80件
Achievable（達成可能）	✅	競合B社は同期間で同規模の成長を達成済み。コンテンツチーム2名を増員済み
Relevant（関連性）	✅	全社OKR「インバウンドマーケティング比率を50%に引き上げ」に直結
Time-bound（期限付き）	✅	2026年9月末まで（6ヶ月間）

SMARTな目標文: 「2026年9月末までに、公式Xアカウントのフォロワー数を5,000から15,000に増やし、X経由のリード獲得を月20件から月80件に引き上げる。」

よくある失敗:

• Achievableを甘く見積もる: 「やればできる」と精神論で判断せず、過去データ・リソース・競合事例から実現可能性を客観的に検証する
• MeasurableとSpecificを混同する: Specificは「何をやるか」の範囲定義、Measurableは「成功を何で測るか」の指標定義。両方必要
• Relevantを省略する: 上位目標との整合性を確認しないと、「目標は達成したが事業に貢献しなかった」という事態に陥る

活用のヒント:

• SMARTは「目標の品質チェックリスト」として使う。まず自由に目標を書き、その後SMARTの5項目で磨き上げる
• チームで使う場合は、各メンバーが書いた目標をペアで相互レビューすると精度が上がる
• 「SMARTER」として、Evaluated（評価）とRecognized（承認）を追加する拡張版もある
• 1つの目標文に5要素すべてが含まれている状態を目指す

次のステップ:

• SMART目標を実行計画に落としたい → 06. ガントチャート
• 複数のSMART目標を時系列で並べたい → 05. ロードマップ
• 目標の上位戦略を確認したい → 01. OKR
• 目標達成の障害を洗い出したい → problemスキル（イシューツリー）
• 目標を関係者に伝えたい → communicationスキル（ピラミッドストラクチャー）

---

04. AARRR（海賊指標）

目的: サービスのグロースを5段階のファネルで管理する

いつ使うか: Webサービス、アプリ、SaaSなどのデジタルプロダクトでグロースを体系的に管理したいとき。スタートアップのPMF検証やグロースハック施策の優先度判断に最適。

テンプレート:

段階	定義	現状値	目標値	主要施策
Acquisition（獲得）	ユーザーがサービスを知る
Activation（活性化）	初回の価値体験
Retention（継続）	繰り返し利用
Referral（紹介）	他者に薦める
Revenue（収益）	課金・収益化

鉄則: まずRetention（継続率）を改善してからAcquisition（獲得）に投資する。穴の空いたバケツに水を注いでも意味がない。

記入例（タスク管理SaaSの例）:

段階	定義	指標	現状値	目標値	主要施策
Acquisition	新規訪問	月間ユニークビジター	50,000	80,000	SEO強化、比較記事LP、Product Hunt掲載
Activation	初回価値体験	サインアップ後7日以内にタスク5件以上作成	25%	45%	オンボーディングフロー改善、テンプレート提供、チュートリアル動画
Retention	継続利用	月次リテンション率（M2）	35%	55%	プッシュ通知最適化、チーム招待促進、習慣化ナッジ
Referral	紹介	招待機能利用率	5%	15%	招待インセンティブ、シェア機能強化、チームプラン割引
Revenue	課金	フリー→有料転換率	3%	7%	価値の壁設計見直し、年額プラン訴求、企業向けプラン拡充

よくある失敗:

• Acquisition偏重: 獲得数だけ追い、活性化・継続が壊れている状態で広告費を投入し続ける。結果、CAC（顧客獲得コスト）が高騰しLTV < CACに陥る
• Activationの定義が曖昧: 「サインアップ」をActivationとしてしまうケース。Activationは「ユーザーがAha!モーメント（価値を実感する瞬間）を体験した」時点で定義すべき
• ファネルを一度作って放置: 各段階の指標は、プロダクトの成熟度に応じて再定義が必要。シリーズAとシリーズCでは追うべき指標が変わる

活用のヒント:

• 各段階のAha!モーメントを定義する。例: Activation = 「チームメンバーを1人招待し、共同でタスクを完了した瞬間」
• コホート分析と組み合わせて、時系列での改善傾向を追う
• 各段階のボトルネック（最も数値が悪い段階）を1つだけ選び、集中的に改善する
• North Star Metric（最重要指標）を1つ決め、AARRRの中で最もそれに影響する段階にフォーカスする

次のステップ:

• 各段階のKPIを詳細に分解したい → 02. KPIツリー
• 顧客が離脱する理由を深掘りしたい → customerスキル（カスタマージャーニーマップ）
• 競合のグロース戦略を分析したい → marketスキル（競合分析）
• 施策のアイデアを発想したい → ideaスキル（ブレインストーミング、SCAMPER）
• プロダクト戦略を整理したい → strategyスキル（リーンキャンバス）

---

05. ロードマップ

目的: 中長期の計画をタイムラインで可視化し、マイルストーンを管理する

いつ使うか: 四半期〜年単位の計画を関係者と共有するとき。プロダクト開発、事業計画、組織変革などで「いつ・何を・どの順番で」を合意するために使う。

テンプレート:

期間	Q1	Q2	Q3	Q4
テーマ
マイルストーン
主要タスク
リソース
リスク

使い方: 詳細すぎるロードマップは陳腐化する。大きなマイルストーンと方向性を示すことに注力する。

記入例（BtoB SaaSプロダクトの例）:

期間	Q1（基盤強化）	Q2（成長加速）	Q3（市場拡大）	Q4（収益最大化）
テーマ	PMF検証と基盤固め	セルフサーブ成長	エンタープライズ展開	収益性改善
マイルストーン	NPS 50達成、コア機能完成	MRR 1,000万円突破	大手企業3社導入	ARR 2億円達成
主要タスク	API基盤刷新、UXリデザイン	料金プラン改定、招待機能	SSO/SAML対応、監査ログ	年額プラン推進、アップセル機能
リソース	エンジニア5名、デザイナー1名	+マーケ2名	+エンタープライズ営業2名	+CS2名
リスク	技術負債による開発遅延	競合の価格攻勢	エンタープライズ要件の膨張	チャーン率の悪化

よくある失敗:

• ロードマップを「約束」として扱う: ロードマップは「方向性の合意」であり、詳細なスケジュールの約束ではない。状況変化に応じて四半期ごとに更新する前提で作る
• すべてを盛り込みすぎる: 各四半期のテーマは1〜2個に絞る。「あれもこれも」は結局何も完成しない
• リスク欄を空欄にする: リスクを事前に想定しておくことで、計画変更時の判断が速くなる

活用のヒント:

• ロードマップは3種類作り分ける: (1)経営向け（年単位、戦略テーマ中心）、(2)チーム向け（四半期、マイルストーン中心）、(3)顧客向け（直近四半期、機能中心）
• 「Now / Next / Later」形式のシンプルなロードマップも有効。時期を厳密に決めず優先度だけ示す
• マイルストーンには必ず「成功基準（Definition of Done）」を定義する
• ロードマップのレビューは月1回、大幅改定は四半期に1回が目安

次のステップ:

• 各マイルストーンを詳細なタスクに分解したい → 06. ガントチャート
• マイルストーンの成功基準を具体化したい → 03. SMART
• ロードマップの戦略的根拠を整理したい → strategyスキル（SWOT分析、アンゾフの成長マトリクス）
• リスクを詳細に分析したい → problemスキル（リスクマトリクス）
• ステークホルダーにロードマップを説明したい → communicationスキル（PREP法）

---

06. ガントチャート

目的: プロジェクトのタスク・担当・期間・依存関係を一覧で管理する

いつ使うか: 具体的なプロジェクト（製品リリース、イベント準備、システム移行など）で、タスクの順序と並行作業を管理したいとき。2週間〜3ヶ月程度のプロジェクトに最適。

テンプレート:

タスク	担当	開始日	終了日	W1	W2	W3	W4	依存
				██
					██	██		タスク1
						██	██	タスク2

使い方: クリティカルパス（最長経路）を意識して遅延リスクを管理する。クリティカルパス上のタスクが1日遅れると、プロジェクト全体が1日遅れる。

記入例（新機能リリースプロジェクトの例）:

タスク	担当	開始日	終了日	W1	W2	W3	W4	W5	W6	依存
要件定義	PM田中	7/1	7/11	██	██					-
UIデザイン	デザイナー鈴木	7/7	7/18		██	██				要件定義(50%)
API設計	エンジニア佐藤	7/14	7/18			██				要件定義
フロントエンド実装	エンジニア山田	7/21	8/1				██	██		UIデザイン
バックエンド実装	エンジニア佐藤	7/21	8/1				██	██		API設計
結合テスト	QA高橋	8/4	8/8						██	FE実装, BE実装
リリース準備	PM田中	8/4	8/8						██	結合テスト(並行)
クリティカルパス: 要件定義 → UIデザイン → FE実装 → 結合テスト（計30営業日）

よくある失敗:

• バッファを入れない: すべてのタスクを最短見積もりで組むと、1つの遅延でドミノ倒しになる。クリティカルパスには全体の10〜20%のバッファを確保する
• 依存関係を曖昧にする: 「なんとなく並行で進める」ではなく、明示的に「タスクAが完了しないとタスクBが開始できない」を定義する
• 更新を怠る: ガントチャートは生き物。週1回は実績を反映し、遅延があれば即座にリスケジュールする

活用のヒント:

• タスクの粒度は「1人が1〜5日で完了できるサイズ」が管理しやすい
• 依存関係は4種類ある: FS（終了-開始）、SS（開始-開始）、FF（終了-終了）、SF（開始-終了）。最も一般的なのはFS
• マイルストーン（期間0のイベント）を要所に置き、進捗チェックポイントにする
• 並行作業が多い場合はリソースの競合（同一人物に複数タスクが集中）に注意する

次のステップ:

• プロジェクト全体の位置づけを確認したい → 05. ロードマップ
• タスクの優先度を判断したい → ideaスキル（ペイオフマトリクス）
• プロジェクトの進行を阻む問題を分析したい → problemスキル（なぜなぜ分析）
• チームの役割分担を整理したい → organizationスキル（RACI）
• プロセスのムダを削減したい → improvementスキル（バリューストリームマッピング）

---

07. バランスト・スコアカード（BSC）

目的: 財務だけでなく4つの視点で経営をバランスよく評価・管理する

いつ使うか: 財務指標だけでは経営の全体像が見えないとき。中期経営計画の策定、部門横断の目標設定、経営ダッシュボード設計に有効。特に「売上は上がっているが組織が疲弊している」等のバランス問題に効く。

テンプレート:

視点	戦略目標	KPI	目標値	アクション
財務
顧客
業務プロセス
学習と成長

因果関係: 学習と成長 → 業務プロセス改善 → 顧客満足度向上 → 財務成果 （下から上へ因果関係が連鎖する。すべての視点が最終的に財務成果につながるストーリーを描く。）

記入例（中堅製造業の例）:

視点	戦略目標	KPI	現状値	目標値	アクション
財務	収益性の向上	営業利益率	5%	8%	高付加価値製品の比率拡大
財務	新規事業の育成	新規事業売上比率	5%	15%	3つの新規事業に各1億円投資
顧客	顧客ロイヤルティ向上	NPS	30	50	カスタマーサクセス体制の構築
顧客	ソリューション提案力	提案型案件比率	20%	40%	コンサルティング営業への転換
業務プロセス	開発リードタイム短縮	企画→量産 期間	18ヶ月	12ヶ月	アジャイル開発プロセス導入
業務プロセス	品質向上	不良率	0.5%	0.1%	AI検査システム導入
学習と成長	デジタル人材の育成	DX研修修了者数	50名	200名	全社DX研修プログラム
学習と成長	エンゲージメント向上	従業員エンゲージメントスコア	3.2	4.0	1on1制度導入、キャリアパス明確化

因果関係ストーリー: DX人材を育成し（学習と成長）→ 開発プロセスを効率化し（業務プロセス）→ ソリューション提案力を高め（顧客）→ 収益性を向上させる（財務）

よくある失敗:

• 4視点が独立している: 各視点のKPIがバラバラで因果関係のストーリーがない。「なぜこの学習が、この業務プロセスの改善につながるのか」を明確にする
• 財務視点に偏る: BSCの本質は「財務以外の先行指標」を管理すること。財務KPIだけ10個あって他が1個ずつでは意味がない
• 学習と成長を軽視する: 「研修回数」など形式的なKPIを置きがち。「実際にスキルが向上し、業務に適用されたか」を測る指標を設定する

活用のヒント:

• BSCは「戦略マップ」とセットで使う。戦略マップは4視点の因果関係を矢印で可視化した図
• 各視点のKPIは2〜4個に厳選する。合計で12〜16個が上限
• 「遅行指標（結果）」と「先行指標（ドライバー）」を区別する。例: 売上（遅行）← 商談数（先行）
• 四半期ごとにスコアカードをレビューし、因果関係の仮説が正しかったか検証する

次のステップ:

• 財務視点のKPIを詳細に分解したい → 02. KPIツリー
• 各視点の戦略目標を具体化したい → 03. SMART
• 業務プロセス視点を深掘りしたい → improvementスキル（バリューストリームマッピング、シックスシグマ）
• 学習と成長の組織施策を設計したい → organizationスキル（マッキンゼー7S）
• 全社戦略の方向性を整理したい → strategyスキル（SWOT分析、ポーターの基本戦略）

---

08. OODAループ

目的: 変化の速い環境で素早く意思決定・行動するための思考サイクル

いつ使うか: 計画を立てる余裕がない緊急事態、競合の動きへの対応、市場の急変時、新規事業の仮説検証など、スピードが求められる局面。PDCAが「計画→実行→検証」の順序で回すのに対し、OODAは「観察→判断→即行動」で圧倒的に速い。

テンプレート:

フェーズ	問い	内容
Observe（観察）	何が起きているか？	生データを偏りなく収集する
Orient（状況判断）	それは何を意味するか？	経験・知識・文脈で解釈する
Decide（意思決定）	何をするか？	複数の選択肢から行動方針を決定する
Act（実行）	すぐ動く	実行し、結果を次のObserveにフィードバック

PDCAとの違い:

	PDCA	OODA
起点	計画（Plan）	観察（Observe）
速度	中〜遅（計画に時間をかける）	速い（観察から即行動）
適する場面	安定環境、品質管理	不確実環境、競争局面
サイクル	週〜月単位	時間〜日単位

記入例（競合の価格攻勢への対応）:

フェーズ	問い	内容
Observe	何が起きているか？	競合A社が主力製品を30%値下げ。SNSで話題になり、自社への問い合わせが先週比40%減。既存顧客3社から「乗り換え検討中」の連絡。営業チームから「商談が止まった」との報告
Orient	何を意味するか？	A社は資金調達直後でシェア拡大フェーズ。価格競争に付き合うと消耗戦になる。ただし、短期的な顧客流出を防がないとチャーンが急増する。自社の強みは「カスタマーサポート品質」と「API連携の豊富さ」
Decide	何をするか？	(1)既存顧客向け: 即座にCSチームが全顧客に「ロイヤルティ割引（年額15%OFF）」を個別提案。(2)新規向け: 価格ではなくROI比較資料を作成し「総所有コスト」で勝負。(3)プロダクト: API連携の優位性を訴求するLP新設
Act	実行	本日中にCSチームにスクリプト配布。今週中にROI比較資料完成。来週LP公開。→ 結果を1週間後に再Observe

よくある失敗:

• ObserveとOrientを混同する: Observeは「事実の収集」、Orientは「事実の解釈」。「競合が値下げした」はObserve、「これは消耗戦を仕掛けている」はOrient。分けて考えることで判断の質が上がる
• Orientのバイアス: 過去の成功体験や思い込みでデータを解釈してしまう。意識的に「別の解釈はないか？」と問う
• Actの後にObserveに戻らない: 1回で終わらせるとただの場当たり対応。結果を観察し、ループを高速で回し続けることが本質

活用のヒント:

• OODAの最大の武器は「Orientの速さと深さ」。日頃から業界知識・顧客理解・競合動向を蓄積しておくと、Orientの精度が格段に上がる
• 1回のループは最長でも1週間以内に回す。「もっとデータが欲しい」は分析麻痺の罠
• チームで使う場合は、Observe担当（情報収集）とOrient担当（分析）を分けると並行作業できる
• 緊急度が高いほどOODA、じっくり取り組むべきテーマはPDCAと使い分ける

次のステップ:

• Observeフェーズの情報収集を体系化したい → marketスキル（PEST分析、ファイブフォース）
• Orientの精度を上げるために顧客を深く理解したい → customerスキル（ペルソナ、エンパシーマップ）
• Decideの選択肢を増やしたい → ideaスキル（ブレインストーミング、SCAMPER）
• Actの結果を構造的に振り返りたい → improvementスキル（PDCA、KPT）
• 意思決定を関係者に説明したい → communicationスキル（PREP法、ピラミッドストラクチャー）

---

09. 組織図

目的: 組織の構造・指揮命令系統・責任範囲を可視化する

いつ使うか: 組織設計、組織改編、新規チーム立ち上げ、M&A後の統合、新入社員へのオリエンテーションなど。「誰が何に責任を持ち、誰にレポートするか」を明確にしたいとき。

テンプレート:

            [CEO]
        ┌────┼────┐
      [事業A] [事業B] [管理]
      ┌─┴─┐        ┌─┴─┐
    [開発] [営業]  [人事] [経理]

組織形態の種類と特徴:

形態	特徴	メリット	デメリット	適する場面
機能別組織	営業・開発・管理等の機能で分ける	専門性が高まる、規模の経済	サイロ化しやすい	単一事業の中小企業
事業部制組織	製品・地域・顧客別に分ける	事業判断が速い、P/L責任が明確	機能の重複、全社最適が難しい	多角化企業
マトリクス組織	機能軸×事業軸の2軸で管理	柔軟なリソース配分	指揮命令が複雑、コンフリクト	グローバル企業
プロジェクト型	プロジェクト単位でチーム編成	目的特化、スピード	帰属意識の低下	IT・コンサル

記入例（50名規模のSaaS企業の例）:

                    [CEO / 代表取締役]
            ┌───────────┼───────────┐
        [CTO]        [COO]        [CFO]
     技術統括      事業統括      管理統括
    ┌───┴───┐    ┌───┴───┐    ┌───┴───┐
[プロダクト] [SRE] [セールス] [CS]  [人事] [経理]
  開発チーム  基盤   営業チーム  CS    HR   Finance
   (15名)   (3名)   (8名)  (6名) (2名)  (2名)
     │               │       │
  ┌──┴──┐        ┌──┴──┐   │
[FE] [BE] [QA]  [法人] [SMB] [オンボーディング]
(5名)(7名)(3名)  (5名) (3名)    (3名)

※ デザインチーム(3名)はCTO直轄、横断的に各チームを支援
※ マーケティング(4名)はCOO直轄、セールスとCSに跨って活動

よくある失敗:

• 組織図を描いて満足する: 組織図は「箱」を並べただけ。各箱の「ミッション・権限・責任範囲」を明文化しないと機能しない
• 組織図が実態と乖離している: 公式の組織図と実際の意思決定フローが異なるケースが多い。非公式なパワーラインも把握する
• 規模に合わない組織形態を選ぶ: 10名の会社にマトリクス組織は過剰。まず機能別組織で始め、30名を超えたら事業部制を検討するのが定石

活用のヒント:

• 組織図と一緒に「責任分担表（RACI）」を作成すると、曖昧な役割が明確になる
• 「スパン・オブ・コントロール（1人の管理者が直接管理できる人数）」は5〜8名が理想
• 組織変更は半年に1回以上行わない。頻繁な変更は現場を混乱させる
• 組織図の「空白地帯」（誰も担当していない領域）を意識的に探す。そこにリスクが潜んでいる
• リモートワーク時代は、公式組織図に加えて「コミュニケーションマップ（誰が誰と日常的にやり取りしているか）」も可視化すると有効

次のステップ:

• 各ポジションの役割分担を明確にしたい → organizationスキル（RACI）
• 組織の強み・弱みを診断したい → organizationスキル（マッキンゼー7S）
• 組織変革の計画を立てたい → 05. ロードマップ
• チームのモチベーション設計をしたい → organizationスキル（ハーズバーグの二要因理論）
• 経営幹部への組織改編提案をしたい → communicationスキル（ピラミッドストラクチャー、PREP法）

---

対話の進め方

ステップ1: ヒアリング

AskUserQuestionで以下を確認する:

1. 目標・課題: 「何を達成したいですか？」「今一番困っていることは何ですか？」
2. 時間軸: 「いつまでに達成したいですか？」（短期: 1〜3ヶ月 / 中期: 3〜12ヶ月 / 長期: 1年以上）
3. 対象範囲: 「個人/チーム/部門/全社、どのレベルの話ですか？」
4. 現状把握: 「現在の状況を教えてください（数値があれば具体的に）」
5. 制約条件: 「予算・人員・技術的な制約はありますか？」

ステップ2: フレームワーク選定

ヒアリング結果に基づき、最適なフレームワークを提案する。以下の判断基準を使う:

ニーズ	推奨フレームワーク
組織全体の方向性を揃えたい	01. OKR
数値目標を因数分解したい	02. KPIツリー
曖昧な目標を具体化したい	03. SMART
Webサービス/アプリの成長指標を管理したい	04. AARRR
中長期の計画を可視化したい	05. ロードマップ
プロジェクトのタスクを管理したい	06. ガントチャート
経営を多角的に評価したい	07. BSC
素早く意思決定したい	08. OODAループ
組織構造を設計/可視化したい	09. 組織図

複数のフレームワークが該当する場合は、組み合わせを提案する。例: 「まずOKRで方向性を定め、KPIツリーで指標を分解し、ガントチャートで実行計画を作りましょう。」

ステップ3: 対話的にテンプレートを埋める

• 一度にすべてを聞かず、セクションごとに対話で進める
• ユーザーの回答が曖昧な場合は、具体例を示して選択肢を提示する
• 業界・ビジネスモデルに応じて、記入例をカスタマイズして提示する
• 途中で「ここまでの内容を確認させてください」と中間確認を挟む

ステップ4: 完成・レビュー

• 完成したワークシートをMarkdownで出力する
• 「改善ポイント」や「見落としがちな観点」をコメントとして付加する
• 「次のステップ」として、他のフレームワークやスキルへの接続を提案する

複数フレームワークの組み合わせパターン

パターンA: 戦略→実行の一気通貫 strategy（SWOT等）→ 01. OKR → 02. KPIツリー → 06. ガントチャート

パターンB: グロースハック customer（ペルソナ）→ 04. AARRR → 02. KPIツリー → idea（施策発想）

パターンC: 中期経営計画 07. BSC → 01. OKR → 05. ロードマップ → 09. 組織図

パターンD: 危機対応 08. OODAループ → problem（根本原因分析）→ 03. SMART（対策の具体化）