組織設計

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

サポート方法

ユーザーが組織設計に関するサポートを求める場合:

1. コンテキストを理解する - 現在の構造、企業段階、解決しようとしている問題、進んで引き受ける権利放棄について質問する
2. 中核となるトレードオフを特定する - 集中化モデル(Apple方式)と分散化モデル(Amazon方式)のスペクトラムを理解するのを支援する
3. 選択肢を評価する - 異なる構造がスピード、一貫性、チーム間の依存関係に与える影響を検討する
4. 実装をガイドする - 新しい構造への移行方法を検討するのを支援する

中核となる原則

基本的なトレードオフ: スピード対 一貫性

Gustav Soderström: 「スペクトラムの一方にはAmazonがあります。依存関係を最小化して並行実行できるようにします。もう一方にはAppleがあります。1人の個人に密接に組織化されています。」Amazonは依存関係が最小限の自律的なチームによってスピードを最適化します。Appleは中央調整を通じて一貫したユーザー体験を最適化します。どちらも普遍的に優れているわけではありません。プロダクトにとって最も重要なことに基づいて選択してください。

機能別モデルはスタートアップのスピードを回復できる

Brian Chesky: 「機能別モデルに移行しました。スタートアップに戻りました。」Airbnbはリーダーを作業から分離した事業部門構造と管理層を廃止しました。機能別モデルは専門知識を集中させ、経営幹部とICの間の「電話ゲーム」を減らします。

仕事を知らないマネージャーを排除する

Brian Cheskeyの再編成は、自分たちで仕事ができない「ピープルマネージャー」を削除しました。リーダーは報告書を管理するだけでなく、決定を下すのに十分なコンテキストを持つべきです。マネージャーが実際のアウトプットを確認できない場合、構造は壊れています。

構造は戦略に従う

適切な組織構造は、何を最適化するかに依存します。独立したイニシアチブの迅速で並行した実行が必要な場合: 分散化してください。密接に統合されたプロダクト体験が必要な場合: 集中化してください。

ユーザーをサポートするための質問

• 「この再編成で解決しようとしている問題は何ですか?」
• 「独立したチームのスピード、それともプロダクト全体の一貫性をより重視していますか?」
• 「経営幹部と実際の作業を行っている人の間に何層ありますか?」
• 「マネージャーは本当にチームのアウトプットをレビュー・理解できますか?」
• 「現在、最大の調整の失敗は何ですか?」

注意すべき一般的な間違い

• 明確な問題のない再編成 - 構造の変更は破壊的です。解決しようとしている具体的な問題を明確にしてください
• 他社の構造をコピーする - Amazonの構造はAmazonの戦略に適しています。名声ではなく、自社のニーズに基づいて選択していることを確認してください
• 管理層が多すぎる - すべての層はレイテンシと情報損失を追加します。意思決定者と作業の距離を最小化してください
• 仕事ができないマネージャー - リーダーがアウトプットを理解していない場合、それについて良い決定を下すことはできません

深掘り

2人のゲストからの2つのすべてのインサイトについては、references/guest-insights.md を参照してください

関連スキル

• Building Team Culture
• Organizational Transformation
• Managing Up
• Delegating Work