organizational-design

組織設計

2 人のプロダクトリーダーのフレームワークを活用して、効果的な組織構造を設計できるようユーザーを支援します。

支援の進め方

ユーザーから組織設計について相談された場合：

1. 状況を理解する - 現在の組織構造、会社の成長段階、解決したい課題、許容できるトレードオフについて質問します
2. 中核となるトレードオフを特定する - 集権的な（Apple 型）モデルと分権的な（Amazon 型）モデルの間にある選択肢を把握できるよう支援します
3. 選択肢を評価する - さまざまな組織構造がスピード、一貫性、チーム間の依存関係に与える影響を検討します
4. 導入を支援する - 新しい組織構造へ移行する方法を検討できるよう支援します

基本原則

根本的なトレードオフ：スピードと一貫性

Gustav Soderström：「一方の極には Amazon があります。依存関係を最小限に抑え、並行して進められるようにします。もう一方には Apple があります。1 人の人物のもとに近い形で中央集権的に組織されています。」Amazon は、依存関係を最小限にした自律的なチームによってスピードを最適化します。Apple は、中央で調整することで一貫性のあるユーザー体験を最適化します。どちらかが常に優れているわけではありません。自社のプロダクトにとって何が最も重要かに応じて選択します。

機能別組織はスタートアップのスピードを取り戻せる

Brian Chesky：「機能別組織に移行しました。スタートアップに戻ったのです。」Airbnb は、リーダーと実務の間を隔てていた事業部制の組織構造や管理階層を廃止しました。機能別組織は専門性を集約し、経営幹部と IC の間で情報が伝言ゲームのように伝わる状況を減らします。

実務を理解していないマネージャーをなくす

Brian Chesky の組織再編では、自分で実務を遂行できない「ピープルマネージャー」をなくしました。リーダーは、単に部下を管理するだけでなく、意思決定に必要な状況を十分に把握しているべきです。マネージャーが実際の成果物をレビューできないなら、組織構造に問題があります。

戦略に合わせて組織を設計する

適切な組織構造は、何を最適化するかによって異なります。独立した取り組みを迅速かつ並行して実行する必要があるなら、分権化します。緊密に統合されたプロダクト体験が必要なら、集権化します。

ユーザーを支援するための質問

• 「この組織再編で解決しようとしている問題は何ですか？」
• 「個々のチームのスピードと、プロダクト全体の一貫性のどちらをより重視しますか？」
• 「経営幹部と実務を担う人々の間には、何階層ありますか？」
• 「マネージャーは、チームの成果物を実際にレビューし、理解できますか？」
• 「現在、最も大きな調整上の失敗は何ですか？」

よくある間違いとして指摘すべきこと

• 明確な課題がないまま組織再編を行う - 組織構造の変更は混乱を招きます。解決しようとしている具体的な課題を明確にします
• 他社の組織構造をそのまま模倣する - Amazon の組織構造は Amazon の戦略に適しています。名声ではなく、自社のニーズに基づいて選んでいることを確認します
• 管理階層が多すぎる - 階層が増えるたびに遅延と情報の損失が生じます。意思決定者と実務の距離を最小限に抑えます
• 実務を遂行できないマネージャー - リーダーが成果物を理解していなければ、それについて適切な意思決定はできません

詳細

2 人のゲストから得られた 2 つの知見については、references/guest-insights.md を参照してください。

関連スキル

• チーム文化の構築
• 組織変革
• 上司との関係構築
• 業務の委任