organizational-design

組織設計

対象範囲

対象となる内容

• スピード、説明責任、顧客の成果を向上させるために、組織の構造とオペレーティングモデルを設計または再設計する
• 中央集権型か分散型か（Apple ↔ Amazon のスペクトラム）、また機能別か事業部制／バリューストリーム別かを選択する
• 依存関係を最小限に抑え、意思決定権限を明確にして、調整コストを削減する
• リーダーが業務を理解し、単にプロセスを管理するのではなく、専門性を高められるよう、管理職の役割と階層を設定する

利用する場面

• 「プロダクトとエンジニアリングの組織再編／組織設計を提案してください。」
• 「依存関係が多くて動きが遅くなっています。並行して進められるよう、チームを再設計してください。」
• 「UX に一貫性がありません。意思決定を中央集権化すべきでしょうか。それとも機能別のリーダーシップを強化すべきでしょうか。」
• 「急成長して階層が増えました。組織を簡素化し、スタートアップのようなスピードを取り戻すのを手伝ってください。」

利用しない場面

• まずプロダクト戦略／ビジョンが必要な場合（defining-product-vision または working-backwards を使用してください）。
• 主に個人のパフォーマンスの問題である場合（組織再編ではなく、コーチング／フィードバックのワークフローを使用してください）。
• 報酬レンジ、職位レベル、採用計画、法務／人事の助言が必要な場合（人事／法務部門に相談してください）。
• 重要度の高い単一の意思決定プロセスが必要な場合（running-decision-processes を使用してください）。

入力情報

最低限必要な情報

• 組織の状況：企業の段階、事業領域、規模、および対象範囲に含める機能（例：プロダクト／エンジニアリング／デザイン／データ）
• 現在の組織構造：チーム、レポートライン（概略で構いません）、現在の業務の進め方
• 主な目標：何を改善する必要があるか（例：スピード、品質、統合された UX、オーナーシップ、コスト）
• 主な症状と具体例（例：意思決定の遅さ、手戻り、オーナーシップの不明確さ、UX の断片化）
• 制約／譲れない条件（人員数、スケジュール、重要なローンチ、規制／コンプライアンス、リーダーシップの意向）

情報が不足している場合の方針

• references/INTAKE.md から最大 5 つの質問をしてください。
• 回答が得られない場合は、前提を明示して進め、不明な点にはその旨を記載してください。

成果物

以下の順序で組織設計パックを作成します（チャット内の Markdown 形式、または依頼があればファイル形式）。

1. 組織設計ブリーフ（目標、制約、設計原則、成功指標）
2. 現状マップ（チーム／チャーター、依存関係の集中箇所、意思決定権限、階層）
3. オペレーティングモデルの決定（中央集権型 ↔ 分散型 ＋ 機能別 ↔ 事業部制とその根拠）
4. 目標組織の設計図（チームのトポロジー ＋ チャーター ＋ リーダーシップの役割 ＋ インターフェース）
5. 運営メカニズム（意思決定権限、計画の頻度、チーム間インターフェース）
6. 移行計画（段取り、コミュニケーション、人員配置の変更、リスク軽減策、測定方法）
7. リスク／未解決の質問／次のステップ（必ず含める）

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

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

1) 最適化する対象（および制約）を定義する

• 入力情報： 目標、症状、制約、スケジュール。
• アクション： 「組織再編が必要」という要望を、設計上の課題に置き換えます。どの成果を、いつまでに改善する必要があるかを明確にします。設計原則を 3～5 個選びます（例：「依存関係を最小限に抑える」「重要な顧客体験に対して UX のオーナーを 1 人置く」「階層を減らす」）。
• 成果物： 組織設計ブリーフ（ドラフト）＋成功指標。
• 確認事項： 関係者が主要なトレードオフ（例：スピードと UX の一貫性）について合意でき、何をもって成功とするかが明確になっていること。

2) 現在の組織をシステムとして可視化する（業務、依存関係、意思決定）

• 入力情報： 現在のチーム、ロードマップ／作業ストリーム、既知の摩擦の具体例。
• アクション： チームのチャーター、依存関係、意思決定権限を記録します。依存関係が集中する箇所、オーナーシップの重複、想定外の承認者を特定します。管理職の階層と、管理職が業務を理解していない箇所を把握します。
• 成果物： 現状マップ＋「摩擦を生む主なループ 5 件」のリスト。
• 確認事項： 具体的な依存関係や意思決定のボトルネックを示すことで、確認されている遅延や手戻りの大部分をマップで説明できること。

3) 運営モデルの方針を選ぶ（中央集権型か分権型か、機能別か事業部制か）

• 入力： 製品アーキテクチャと結合度、UX の統合ニーズ、人材の成熟度、リスク許容度。
• アクション： 組織を次の2つの軸で位置付けます。（1）中央集権型（Apple のようなモデル）↔ 分権型（Amazon のようなモデル）、（2）機能別 ↔ 事業部制／バリューストリーム型。根拠とガードレール（標準化すべきことと、異なる形を認めること）を記述します。
• 出力： 運営モデルの決定とガードレール。
• 確認項目： 選択したモデルが製品の結合度に合致していること。統合された体験には明確な責任者を置き、独立した領域は明確なインターフェースのもとで並行して運営できます。

4) 実行可能な組織案を2～3案作成する（1案だけにしない）

• 入力： 現状のマップ、運営モデルの方針、制約。
• アクション： チーム一覧、チーム憲章、リーダーの役割、インターフェース、依存関係の変更見込みを盛り込んだ案を2～3案（A／B／（C：ハイブリッド））作成します。マネジメント層を明確にし、領域や専門分野の知見がない「ピープルマネージャー」は避けます。
• 出力： 案の比較表と各案の説明。
• 確認項目： 各案について、何が速くなり、何が悪化し、どの依存関係が解消され、どれが単に移動するだけなのかが示されていること。

5) 案を評価し、代替案も含めて推奨案を選ぶ

• 入力： 各案、ステークホルダーの優先事項、リスク上の制約。
• アクション： references/RUBRIC.md に基づいて採点します。推奨案と代替案を選びます。「初日からの変更」と「後続のリファクタリング」を特定し、必要な運営メカニズムの変更（意思決定権、開催頻度、標準）を明確にします。
• 出力： 推奨案、評価表、合意が必要な重要事項。
• 確認項目： チーム憲章、レポートライン／リーダーの役割、意思決定権が明確で、推奨案を実行できること。

6) 移行を設計する（変更計画、コミュニケーション、安全策）

• 入力： 推奨案、人員に関する制約、ローンチカレンダー。
• アクション： 段階的な移行計画（パイロット／フェーズごとの展開）、コミュニケーション計画、リスク軽減策を作成します。成功指標とチェックインの時点（30／60／90日目）を定義します。リスクの高い変更については、ロールバックの発動条件を追加します。
• 出力： 移行計画とコミュニケーションの概要。
• 確認項目： 人への影響に関するリスクが明らかになっており、重要な業務の継続性が確保され、「初日から意思決定をどのように進めるか」が明確であること。

7) 品質ゲートを通過させ、最終化する

• 入力： ドラフト一式。
• アクション： references/CHECKLISTS.md を実行し、references/RUBRIC.md に基づいて採点します。資料一式を最終化し、リスク／未解決の質問／次のステップを含めます。
• 出力： 最終版の組織設計資料一式とルーブリックのスコア。
• 確認項目： ルーブリックのスコアが低い場合は、もう一度ヒアリングを行い（質問は最大5つ）、内容を修正します。

品質ゲート（必須）

• 最終化する前に、references/CHECKLISTS.md を実行し、references/RUBRIC.md に基づいて採点します。
• 必ず リスク、未解決の質問、次のステップ を含めます。

例

例 1：「従業員約200人の会社でプロダクト担当の VP をしています。チーム間の依存関係のせいで進みが遅いため、並行して進められるように組織の再設計を提案してください。」
期待される内容：現状の依存関係マップ、分権化の案、依存関係を最小限にした目標組織の設計図、移行計画。

例 2：「創業者／CEO：組織に階層を増やした結果、スピードが落ちました。より機能別のモデルに移行し、マネージャーが業務を把握できるようにしてください。」
期待される内容：運営モデルの決定（機能別の方針）、階層削減計画、リーダーの役割定義、コミュニケーションとリスクを含む移行計画。

適用範囲の境界となる例：「人員削減を正当化するための組織再編を作成してください。」
回答：このスキルは成果を向上させるための組織設計を目的としています。人員削減が動機である場合は、まず HR／法務に相談し、戦略と制約を明確にしてください。