organizational-transformation

組織変革

対象範囲

対象

• 企業を現代的なプロダクト運営モデルへ移行させるための、実践的な変革計画の設計と主導
• 旧来型の組織を「少しずつ後押し」すること。変革が拒絶されず、受け入れられるよう順序立てて進めます
• フレームワークの導入（Spotify、SAFe など）自体を最終目標とする落とし穴を避けること
• 組織構造＋プロセス＋文化の変革を調整すること（チーム、意思決定権、ディスカバリー／デリバリー、インセンティブ、儀式）

利用するタイミング

• 「機能別チームから自律性の高いプロダクトチームに移行するのを手伝ってください。」
• 「フレームワークを導入し続けていますが、何も変わりません。本当の変革計画を作ってください。」
• 「90日間のパイロット計画と、プロダクト運営モデルを展開するためのロードマップを作成してください。」
• 「経営陣は変革を望んでいますが、チームは懐疑的です。反発を抑える変革＋コミュニケーション計画を作成してください。」

利用しないタイミング

• まず戦略／ビジョンが必要な場合（defining-product-vision または working-backwards を使用してください）。
• 組織図／チーム構成の変更だけが必要な場合（organizational-design を使用してください）。
• 既知の計画に対するプロジェクト管理が必要な場合（managing-timelines を使用してください）。
• 報酬、レイオフ、労働法、または慎重な対応が必要な人事施策について、人事／法務の助言が必要な場合（人事／法務部門に相談してください）。

入力

最低限必要

• 組織の状況：業界、規模／成長段階、地域、規制上の制約（ある場合）
• エグゼクティブスポンサー＋意思決定者、および変革を行う「今」の理由
• 現在の運営モデルの症状（具体例を含む）：意思決定のボトルネック、アウトプットとアウトカムの不一致、ディスカバリーの不足、依存関係の連鎖
• 現在のチームモデル（機能別チームかプロダクトチームか）、およびプロダクトに関する意思決定が現在どこで行われているか
• 制約：スケジュール、予算／人員、維持必須のプロセス、重要なローンチ

情報が不足している場合の対応

• references/INTAKE.mdから最大5つの質問をします。
• 回答が得られない場合は、明示的な前提を置いて進め、不明点を明記します。

出力（成果物）

次の順序で組織変革パックを作成します（チャット内の Markdown、または依頼があればファイルで提供）：

1. 変革憲章（今変革する理由、目標／対象外、原則、成功指標、制約）
2. 現状診断（現在の業務の流れ、能力の不足、抵抗勢力マップ、失敗パターン）
3. 目指すプロダクト運営モデルの設計図（チームの種類、役割、意思決定権、定例、主要な成果物）
4. パイロット／小規模な後押し計画（90日間）（試行しやすいパイロットを2～4件、トレーニング／コーチング、学習ループ、導入戦略）
5. 変革ロードマップ（6～12か月）（フェーズ、主要施策、依存関係、順序付け、リソース配分）
6. 変革＋コミュニケーション計画（ステークホルダー、メッセージ、定例、導入支援、抵抗への対応）
7. ガバナンス＋指標（先行指標、レビューの頻度、エスカレーション、「フレームワークの適切な運用」を守るためのガードレール）
8. リスク／未解決の質問／次のステップ（必ず含める）

テンプレート：references/TEMPLATES.md

ワークフロー（8ステップ）

1) フレームワークではなく成果をすり合わせる

• 入力： 今変革する理由、目標、症状、制約、過去の取り組み。
• アクション： 「Xフレームワークを導入する」を、成果＋行動に置き換えます。対象外（まだ変更しないこと）を定義します。変革の原則を3～5つ設定します。
• 出力： 変革憲章（ドラフト）＋前提。
• 確認事項： スポンサーが、成功を「Xを導入した」ではなく、成果／行動で説明できます。

2) 現在の運営モデルをシステムとして診断する

• 入力： チームの種類、計画の頻度、意思決定権、デリバリーの流れ、遅延／手戻りの例。
• アクション： アイデアからリリースまでの業務の流れを可視化します。ボトルネック（依存関係、承認、インセンティブ、ディスカバリーの不足）を特定します。機能別チームのモデルが強化されている箇所を記録します。
• 出力： 現状診断（システムマップ＋主要な問題）。
• 確認事項： 診断では、具体的なメカニズムに基づいて症状を説明します（印象論ではありません）。

3) 変革の方針とガードレールを定める（フレームワークの適切な運用）

• 入力： 診断結果、制約、変革の実行能力、リーダーシップの合意。
• アクション： 効果を生み出すために必要な、最小限のオペレーティングモデルの変更を定義します（例：権限を与えられたチーム、ディスカバリーとデリバリーの並行実施、成果重視の計画策定）。「フレームワークの適切な運用」ルールを追加し、取り入れるもの、取り入れないもの、その理由を明確にします。
• 成果物： Charterの「変革の方針とガードレール」セクション。
• 確認事項： 計画が状況に合わせて調整され、モデルの丸ごとの模倣を避けていること。

4) 目指すプロダクト・オペレーティングモデルを設計する（具体的かつ観察可能に）

• 入力： 変革の方針、プロダクトの形態（統合型かモジュール型か）、人材の成熟度。
• アクション： チームの種類（プロダクト／プラットフォーム／イネーブリング）、役割、意思決定権、受け入れ方法、ディスカバリーに求めること、計画の頻度、必要な成果物を明確にします。
• 成果物： 目標プロダクト・オペレーティングモデルのブループリント。
• 確認事項： リーダーが初日から「誰が何を決めるのか」と「『良い状態』とは何か」に答えられること。

5) ナッジ優先のパイロット計画を作成する（90日間）

• 入力： ブループリント、候補となるチーム／領域、リスク上の制約。
• アクション： 明確な仮説、支援策（コーチング／トレーニング）、導入を促す施策（ナッジ、定例活動、テンプレート）を含む2～4件のパイロットを設計します。何を学び、どのように適応するかを定義します。
• 成果物： パイロット／ナッジ計画とパイロット評価表。
• 確認事項： パイロットが安全に試行でき、測定可能で、組織全体の完全な合意を必要としないこと。

6) 変革ロードマップを作成する（6～12か月）

• 入力： パイロット計画、リソース、カレンダー上の制約。
• アクション： 主要施策（組織構造の変更、能力開発、ツール／プロセスの変更）の順序を決めます。意思決定ポイント、依存関係、ロールバックのトリガーを盛り込みます。
• 成果物： 変革ロードマップ（フェーズとマイルストーン）。
• 確認事項： ロードマップが実行可能で、事業継続性と進行中のコミットメントを守ること。

7) 変革とコミュニケーションを計画する（拒絶を減らす）

• 入力： ステークホルダー、抵抗の状況、インセンティブ。
• アクション： コミュニケーションのストーリー、ステークホルダーごとのメッセージ、支援計画、反対意見に対応する仕組みを作成します。変革をインセンティブやリーダーシップの行動と結び付けます。
• 成果物： 変革・コミュニケーション計画。
• 確認事項： 計画に、単なる告知だけでなく、定着を促す仕組み（定例活動、指標、リーダーの行動）が含まれていること。

8) 品質ゲートを通過し、仕上げる

• 入力： ドラフト一式。
• アクション： references/CHECKLISTS.mdを実行し、references/RUBRIC.mdで評価します。「リスク」「未解決の質問」「次のステップ」が含まれていることを確認します。
• 成果物： 最終版の組織変革パックと評価スコア。
• 確認事項： 評価スコアが低い場合は、追加で1回インテークを行い（質問は最大5つ）、内容を修正します。

品質ゲート（必須）

• 最終化する前にreferences/CHECKLISTS.mdを実行し、references/RUBRIC.mdで評価します。
• 必ず含める項目：リスク、未解決の質問、次のステップ。

例

例1：「従来型企業のプロダクト担当VPです。チームは機能をリリースしていますが、成果が向上しません。権限を与えられたプロダクトチームへの変革計画を作成してください。」
期待される内容：診断、目標オペレーティングモデルのブループリント、90日間のパイロット、6～12か月のロードマップ、ガバナンス指標。

例2：「CEOです。SAFe／Spotify型の変更を試しましたが、反発を招きました。拒絶を減らす、ナッジ優先の計画とコミュニケーションを作成してください。」
期待される内容：フレームワークの適切な運用に関するガードレール、小規模なパイロット、ステークホルダー向けメッセージ、定着を促す仕組み。

境界の例：「『Spotifyモデルを』そのまま導入する計画を書いてください。」
回答：このスキルではフレームワークをツールとして扱います。そのため、状況に適したオペレーティングモデルを作成し、何を（もしあれば）取り入れるか、またパイロットを通じてどのように検証するかを明確にします。