プロダクトチームの構造化方法

システム（広義に定義される）を設計する組織は、その組織のコミュニケーション構造のコピーである設計を生み出すだろう。

• メルビン・E・コンウェイ¹

スタートアップ、スケールアップ、または大規模な組織で働いているかどうかにかかわらず、プロダクトチームの成功は通常、そのチームの成長を意味します。まず、より多くの人を雇う必要があり、次にチームを分割し、今度は組織するチームのグループがあり、しばらくするとループは最終的に再び始まります。これらの変化は組織に課題と機会をもたらします。ここでは、プロダクトチームを組織するためのいくつかの戦略、それらが最適化するもの、およびどのような状況で使用するかについて説明します。

何を解決するか？

#

プロダクトチームを組織する際には、完全性、独立性、明確性、バランスの4つの要素を考慮することが重要です。_ネタバレ：_これらすべてを最適化する方法は見つかっていません。しかし、組織とそのチームがどの段階にあるかに応じて、これらの要素のどれが最も重要かについて明確なパターンがあります。

完全性

#

チームとグループがドメインをエンドツーエンドで所有していることを確認します。完全なドメインでは、チーム/グループは明確な価値ベースのビジョンとロードマップを構築できるはずです。ドメインは、機能を提供するのではなく、時間をかけて完全な価値を提供するために、十分にタイト（穴がない）で十分に広い必要があります。

独立性

#

速く動くことは、チームの成功の最も重要な側面の1つです。各チームがドメインに対して独立していることを確認することは、速く動き、全体的に価値を創造する能力に大きく貢献します。独立性は、チームが作業している開発チームでミッションを推進し、目標を達成でき、他のチームへの依存が最小限である場合に達成されます。プロダクトの依存関係は、開発チームと技術的な依存関係に限定されません。追加の依存関係には、他のPM、データ、UX、デザイン、マーケティングなどの他のデリバリーチーム、また法務、コンプライアンス、財務などのステークホルダーが含まれます。

明確性

#

ドメインは内部チームと外部のステークホルダーにとって明確である必要があります。これにより、a) チームがコア機能と目標が何であるかを知り、b) 外部のステークホルダーを同じビジョンに合わせることが容易になります。チームのすべての成果物とドキュメントは、その明確さを伝えることを目指す必要があります（例：チーム名）。

バランス

#

プロダクトチームのドメインを作成または分割する場合、またはプロダクトグループ内で、トピックの関連性と負荷の観点からバランスの取れた分配があることを確認することが重要です。そうでなければ、単一のチームが利用可能な総リソースの限られた量だけで会社の最も重要な問題のすべてに取り組むシナリオにチームが陥る可能性があります。バランスはまた、ある程度、すべてのグループとチームが一定のレベルの関連性と影響力を持っていることを確認する必要があります。そうでなければ、チームメンバーを採用し、モチベーションを維持することが難しくなる可能性があります。

戦略

#

チームを組織する方法と、各戦略が上記の4つの要素とどのように比較されるかについてのオプションを以下に示します。

機能別

#

別名：製品別、機能別、技術コンポーネント別

graph LR

O([プロダクト & エンジニアリング組織])

subgraph フロントエンド
FPM(プロダクトマネージャー)
FEM(エンジニアリングマネージャー)
FPD(プロダクトデザイナー)
FFD(フロントエンド開発者)
end


subgraph バックエンド
BPM(プロダクトマネージャー)
BEM(エンジニアリングマネージャー)
BBD(バックエンド開発者)
end

subgraph プラットフォーム
PPM(プロダクトマネージャー)
PEM(エンジニアリングマネージャー)
PBD(バックエンド開発者)
end

O --> フロントエンド
O --> バックエンド
O --> プラットフォーム

この構造は、製品、機能、コンポーネント、またはレイヤー（FE対BE）などの機能モジュールによってグループとチームを分割します。このオプションは、最初のリリースを提供するためにも重い作業が必要な初期段階の企業に最も適しています。この時点でのビジョンとロードマップは通常、全体的な製品のものであり、すでに定義されたスコープに向けて異なる部分がうまく連携する必要があります。組織がスケールすると、チームが成長し、その分割がますます細かくなるため、これは悪いオプションになります。これにより、チーム間の依存関係のレベルが劇的に増加し、各チーム/グループのビジョンとロードマップが制約され、顧客中心性が低くなります。

カスタマージャーニー

#

graph LR

O([プロダクト & エンジニアリング組織])

subgraph ディスカバリー
DPM(プロダクトマネージャー)
DEM(エンジニアリングマネージャー)
DPD(プロダクトデザイナー)
DFD(フロントエンド開発者)
DBD(バックエンド開発者)
end

subgraph 購入
PPM(プロダクトマネージャー)
PEM(エンジニアリングマネージャー)
PPD(プロダクトデザイナー)
PFD(フロントエンド開発者)
PBD(バックエンド開発者)
end

subgraph 認証
APM(プロダクトマネージャー)
AEM(エンジニアリングマネージャー)
APD(プロダクトデザイナー)
AFD(フロントエンド開発者)
ABD(バックエンド開発者)
end

O --> ディスカバリー
O --> 購入
O --> 認証

この構造では、各チーム/グループは全体的なカスタマージャーニー、またはそのジャーニーの特定のフェーズを担当します。例えば、顧客購入フローでは、プロダクトチームがユーザー獲得を所有し、別のチームがオンボーディング、別のチームがディスカバリー、別のチームがチェックアウトプロセスを所有できます。この方法では、カスタマージャーニーの各フェーズに十分な実体があることが必要です。多くの場合、これらの接点で顧客がジャーニーを続けるか失敗するかを密接に反映する重要なビジネスメトリクスがあり、説明責任の委任を可能にします。ただし、全体的なフローの一部の特定のメトリクスを最適化しても、全体的なメトリクスに役立たない場合があります。この組織構造は、製品全体で一貫した顧客体験を確保するために多くのデザイン調整が必要です。

問題定義

#

別名：目標、メトリクス、ジョブ・トゥ・ビー・ダン

graph LR

O([プロダクト & エンジニアリング組織])

subgraph 獲得
ACPM(プロダクトマネージャー)
ACEM(エンジニアリングマネージャー)
ACPD(プロダクトデザイナー)
ACFD(フロントエンド開発者)
ACBD(バックエンド開発者)
end


subgraph アクティベーション
ACTPM(プロダクトマネージャー)
ACTEM(エンジニアリングマネージャー)
ACTPD(プロダクトデザイナー)
ACTFD(フロントエンド開発者)
ACTBD(バックエンド開発者)
end

subgraph エンゲージメント
EPM(プロダクトマネージャー)
EEM(エンジニアリングマネージャー)
EPD(プロダクトデザイナー)
EFD(フロントエンド開発者)
EBD(バックエンド開発者)
end

subgraph コンバージョン
CPM(プロダクトマネージャー)
CEM(エンジニアリングマネージャー)
CPD(プロダクトデザイナー)
CFD(フロントエンド開発者)
CBD(バックエンド開発者)
end

O --> 獲得
O --> アクティベーション
O --> エンゲージメント
O --> コンバージョン

この方法では、各チームとグループは問題定義を担当し、それは目標、メトリクス、ジョブ・トゥ・ビー・ダンに翻訳できます。チームは、その問題を解決すると信じる機能に触れることができます。このアプローチの主な利点は、個々のプロダクトマネージャーに説明責任を押し付けることです。複数のチームが同時に同じ製品コンポーネントで作業したい（または必要とする）可能性があり、したがってそれらのものに対して誰も所有権を感じないことになる可能性があります。これは、顧客とビジネスの成果を捉える確立された製品KPIを持つ企業にとって良い選択です。前の方法との違いは、異なるチーム間の全体的な懸念が必ずしも単一のユーザーフローの一部ではないことです。

ユーザーペルソナ

#

graph LR

O([プロダクト & エンジニアリング組織])

subgraph 買い手
BPM(プロダクトマネージャー)
BEM(エンジニアリングマネージャー)
BPD(プロダクトデザイナー)
BFD(フロントエンド開発者)
BBD(バックエンド開発者)
end


subgraph 売り手
SPM(プロダクトマネージャー)
SEM(エンジニアリングマネージャー)
SPD(プロダクトデザイナー)
SFD(フロントエンド開発者)
SBD(バックエンド開発者)
end

subgraph 広告主
APM(プロダクトマネージャー)
AEM(エンジニアリングマネージャー)
APD(プロダクトデザイナー)
AFD(フロントエンド開発者)
ABD(バックエンド開発者)
end

O --> 買い手
O --> 売り手
O --> 広告主

各チームとグループにはペルソナが割り当てられ、そのペルソナのニーズをエンドツーエンドで担当します。通常、複数のペルソナを持つ製品で使用され、さまざまなペルソナのニーズが独立しており、互いに矛盾しない場合に使用されます（例：買い手と売り手がいるマーケットプレイス）。この組織はチームをユーザーのニーズに集中させますが、努力の重複、確立されたデザイン原則からの逸脱、または同時に製品を異なる方向に導くことを避けるために、チームとグループ間での重い調整が必要です。

まとめ

#

企業、業界などすべての組織的問題に対する単一の解決策はありません。ただし、上記の戦略は、大きな落とし穴を避けるためのいくつかの興味深い方法を提供します。

例として、初期段階の会社で働いている場合、機能別の分割を採用するのが理にかなっているかもしれません。チームとスコープは非常に明確になり、製品検証の最初の初期段階をより速く通過するのに役立ちます。同様に、製品にすでに明確に定義されたユーザーフローがある場合（例：獲得、アクティベーション、コンバージョンなどのeコマース）、各チームをカスタマーフローのステージの1つに焦点を当てることがオプションかもしれません。これにより、各チームに明確なKPIとスコープを提供しやすくなり、簡単にスケールできます。複数の異なるペルソナがいる場合（買い手-売り手タイプを考えてください）、それら2つの体験を明確に最適化できます。

これらすべての戦略により、コンテキストに適応し、そのコンテキストが変化するにつれてチームの構造を進化させることができます（変化するでしょうから）。明確な答えはなく、上記の提案は、ここで提示されたいくつかの戦略をどのように活用できるかの例にすぎません。

やってはいけない唯一のことは、これらのフレームワークのいくつかを同じ構造内で混在させようとすることです。これにより、混乱、不明確な依存関係、および組織全体でのノイズが発生します。

最終的に、どのオプションを選択しても、スケールするにつれて、目標は常にチームが顧客中心を失わないようにすることです。そうしないと、a) 不幸な顧客と b) 失敗につながります。

システム（広義に定義される）を設計する組織は、その組織のコミュニケーション構造のコピーである設計を生み出すだろう。

• メルビン・E・コンウェイ¹