org-design

プロダクトとエンジニアリングの組織設計

自律性、スピード、戦略との整合性を最大化できるよう、チームを編成します。

Lenny's Podcast と Newsletter に登場した27人のゲストや投稿者の知見をもとに、プロダクトとエンジニアリングの組織設計を支援します。

支援の方法

1. ライフサイクルと目標を分析する - GMモデルによるスピードと俊敏性、または機能別モデルによるプロダクトの一貫性のどちらが必要かを判断します。
2. チームの境界を定める - 一時的な機能ではなく、長期にわたって維持される顧客セグメントや成果を軸に、自律的なポッドを編成します。
3. リーダーのペアを割り当てる - あらゆるレベルでプロダクトとエンジニアリングのリードをペアにし、ビジネス戦略と技術面の実行のバランスを保ちます。
4. スケーリングのためのガードレールを設ける - 組織の成長に合わせて、プロダクトオペレーションなどの専門職や明確なキャリアラダーを導入し、勢いを維持します。

基本原則

プロジェクトからプログラムへ移行する

Bill Carr：「単独で機能できるチームを作りましょう。各チームには単独のリーダーがおり、必要な部門横断的なリソースはすべて、そのリーダーに直接レポートするか、チーム専属にします。必ずしも直属の部下である必要はありません。Amazonでは、ほとんどの場合、直属の部下でした。点線でつながる関係もありましたが、すべて直属でも、すべて点線でも、その組み合わせでも構いません。」

タスク間でリソースを移動させるやり方から、特定の顧客領域を無期限に担当するプログラム志向へと移行します。これにより、単一の責任を担うリーダーが長期的な成果に全面的な責任を持てるようになります。

単一のCPTOの下に統合する

Claire Vo：「CPTOというのは、プロダクト、エンジニアリング、デザインの機能を一体で運営することを短く表したものです。プロダクトにとって何が最善か、エンジニアリングにとって何が最善か、デザインをどれだけ速く進めるべきか、といった議論をするべきではありません。組織全体にとって何が最善でしょうか？」

プロダクト、エンジニアリング、デザインを1人のリーダーの下に統合すると、部門間のサイロをなくせます。各部門の目標よりも組織全体のスピードを優先することで、社内の対立を解消できます。

機能別の集約によって標準化する

Dhanji R. Prasanna：「今では、すべてのエンジニアが1つのチームに、すべてのデザイナーが1つのチームに所属し、エンジニアリングの責任者も、デザインの責任者もそれぞれ1人になりました。これが私たちが行った大きな変革です。その結果、AIやプラットフォーム、そして全般的な技術的な深さを本当に前進させることができました。」

機能別の組織構造に移行すると、技術戦略を全社で統一しやすくなります。また、エンジニアリング部門全体の卓越性を高めるため、標準化されたエンジニアリングのレベルや方針を導入できます。

オープンに設計する

Heidi Helfand：「組織再編では透明性が保たれているのがとても良いと思います。私の本には、SpotifyのChristian Limaが大規模なインフラチームを再編した事例があります。ホワイトボードに新しい組織図を描き、リーダーたちが目指すチーム構成をメンバーに見てもらい、設計について意見を出してもらったのです。」

組織再編の際には、提案する組織構造を人目に触れるホワイトボードに可視化し、透明性を保ちます。早い段階から従業員を巻き込むことで、構造上の誤りを見つけやすくなり、新たなミッションへの参加意識も高まります。

PMの責任を分散する

Karri Saarinen：「実際、私たちの会社にはPMがあまりいません。1人だけです。この点については、もっと詳しく話せます。チームを作り、あらゆることに対して非常に細分化された役割を設定し始めると、PMが物事を明らかにし、意思決定を行い、チームを導く一方で、機能を作る当人ではなくなってしまうことがよくあると思います。」

すべてのチームに専任のPMを置かないことで、プロダクトを実際に作る人たちのオーナーシップを高められます。管理業務をエンジニアやデザイナーに分散すると、細部への注意も高まります。

喉が渇いたときだけ採用する

Varun Mohan：「会社は、ほとんど脱水状態の存在のようであってほしいと思っています。採用するたびに少しだけ水を得るようなものです。再び脱水状態になるまで、次の採用はしません。」

新しい採用者は誰もが希少なリソースだと考え、チームが本当に手いっぱいになるまで人員を増やさないでください。これにより、組織の肥大化を防ぎ、すべての役割がプロジェクトの存続に不可欠であることを確実にできます。

顧客セグメントごとに組織する

Sachin Monga：「チームはプロダクトの表層を中心に編成されているわけではありません。アプリチームやダッシュボードチーム、ポッドキャストチームのようなチームはありません。顧客を中心に編成し、長く続く顧客課題の解決に取り組むチームがあります。」

一時的な機能の表層ではなく、各チームが担当する具体的な顧客グループに基づいてチームを編成してください。これにより、各チームが専任の部門横断型リソースを持つ、より持続性の高い組織構造を実現できます。

テンプレートとフレームワーク

• GM・機能別・ハイブリッド組織モデルの意思決定フレームワーク（General management, functional, and hybrid models: Which org design works best for top companies?） - （A）北極星指標と収益の近さ、および（B）holの重要性に基づき、会社に最適な組織モデルを判断するための2要素フレームワーク
• 指標ベースと機能ベースのチーム分類（How Duolingo builds product） - プロダクトチームを定量的な指標中心に編成するか、プロダクトのミッションや課題中心に編成するかを判断するためのフレームワーク
• AMPEDチーム構造（How Miro builds product） - 分析、（プロダクト）マーケティング、プロダクト、エンジニアリング、デザインを統合し、ストリームごとに編成された統一的なプロダクトチームに組み込む部門横断型のチーム構造
• Notionの4層プロダクトチーム構造（How Notion builds product） - 機能を完全に分離できない、相互に密接に結びついたプロダクト向けの比喩的な階層型チーム構造
• LinearのPMを置かないプロジェクトチームモデル（How Linear builds product） - 従来型のPMを置かずにプロダクトチームを運営するためのフレームワーク。プロジェクトチーム自体がPMの役割を担います。
• 責任領域（AOR）のスプレッドシートテンプレート（How to get your marketing team to drive more impact） - Asanaの社内システムから得た知見をもとに、マーケティングチームと部門横断型チーム間で責任領域の共有リストを作成するためのスプレッドシートテンプレート
• プロダクトの開発速度を高める組織設計の原則（How Ramp builds product） - スピードとコラボレーションを最大化するために、プロダクト組織を構成する3つの原則
• 責任の所在が曖昧な場合に対処する3つの方法（This Week #9: Breaking into growth, leading with influence, and (not) stepping on toes 🦶） - PMチームの拡大に伴い、プロダクト領域の責任の所在が不明確な場合に対処する、最も簡単な方法から最も複雑な方法まで段階的にまとめた戦略
• 会社の成長段階 → 組織モデルの変遷（General management, functional, and hybrid models: Which org design works best for top companies?） - 企業が初期段階から成熟したマルチプロダクト企業へ成長するにつれて、組織構造がどのように変化するかを示す、ライフサイクルベースのフレームワーク
• PMのキャリアラダー設計に関する意思決定チェックリスト（Product management career ladders） - 20社以上の事例から導き出された、PMのキャリアラダーを構築する際の重要な構造上の意思決定事項

詳細を含む全リストについては、references/artifacts.mdを参照してください。

ユーザーへの質問

• 「今の主な目標は、事業のスピードと俊敏性ですか、それともプロダクトの一貫性と統一性ですか？」
• 「現在、リリースの速度を低下させている、チーム間の依存関係の上位3つは何ですか？」
• 「現在のチームは、機能（アウトプット）を担当していますか、それとも事業成果（指標）を担当していますか？」
• 「現在、プロダクト、エンジニアリング、デザインの各部門には何人いますか？」
• 「組織の拡大に伴う役割の曖昧さを減らすため、明確なキャリアラダーを定めていますか？」
• 「チームは技術レイヤーごと、あるいは顧客セグメントごとに編成されていますか？」

注意すべきよくある間違い

• プロジェクトに人員を配置しすぎる - 人を増やしすぎると、コミュニケーションの負担や組織の硬直化が生じ、実行のスピードが落ちます。
• 業界標準をそのままコピーする - 他社のモデルを独自の企業文化やプロダクトの特性に合わせずに導入すると、摩擦が生じやすくなります。
• プロダクト部門とエンジニアリング部門を分断する - PM とエンジニアリングのリーダーを連携させないと、戦略のずれや実行上のボトルネックにつながります。
• 組織設計を固定的なものとして扱う - 組織はプロダクトであり、事業の変化に応じてチームが最大限の自律性を発揮できるよう、継続的に見直す必要があります。
• 秘密裏に組織再編を設計する - 設計プロセスを隠すと従業員の不安を招き、現場に最も近い人々から得られる貴重なフィードバックを逃してしまいます。

詳細

27 人のゲストから得た、出典付きの 50 件すべての知見については、references/guest-insights.md をご覧ください。

関連スキル

• プロダクト人材の採用
• 候補者の面接と評価
• グロースチームの構築
• 創業幹部チーム