【米SVPG社 翻訳記事】成功するプロダクト組織を作り上げる要素

作者：マーティ・ケーガン

翻訳者：インターンスタッフ（アーテリジェンス）

‍

スタートアップのアーリーステージを乗り超えた組織のほとんどが対峙する、最も一般的であり難解な問題は、「プロダクトに関する業務をどのように役割分担するか」、ということです。複数のプロダクトマネージャーかインタラクションデザイナーが社内にいるようになるとこの問題が浮き彫りになります。また、特に大きな組織ではこれは重大で、長い間苦しむ問題です。

この問題はとても重要で、様々な要素が考慮されなければならないため、いつもできるだけ慎重に答えるようにしています。

この記事では、私が提案をする際に重視する要素を挙げたいと思います。また、もうひと手間かけて、最も重要な要素から順位順に紹介するようにしました。ただし、実際には企業のカルチャーに合わせてこの順位が変動することがあります。

優先順位1.明らかなオーナーシップ

エンパワーされている、かつアカウンタビリティを持つチームは、多くの責任が降りかかります。だからこそ、プロダクトチームに重要で、かつ真に所有でき、自由に手を加えられるものを与えるオーナーシップ（役者補則：主体者意識やプロダクトへのコミットメントを指していると考えられます）が、常に私が考えるプロダクトチームにおける最優先事項です。これは、すべてのチームがある一定の水準で相互に関連していることを認識して常に調整する必要があります。なので、リソースとプロダクト領域において完全なるコントロールを与えることはできませんが、オーナーシップの感覚を最大限に引き出すようにしなければなりません。

優先順位2.ユーザー/顧客との連携

これは社内のユーザーやステークホルダーに関してではありません（それはビジネスユニットとの整合に入ります）。ここで話しているのは、サイトまたはサービスの実際の顧客およびユーザーとの連携についてです。ユーザーや顧客との連携のプライオリティがかなり低い企業は多くありますが、（以下の要素の影響力が大きいため）これを行うことはプロダクトとチームに非常に有益なものとなるでしょう。

優先順位3.開発チームとの整合

プロダクトマネージャーやデザイナーは基本的に、デベロッパーと毎日協力してプロダクトを開発します。そして、プロダクト組織とテクノロジー組織が上手く連携していない場合は、なかなか結果が出ません。スクラムチームが複数のプロダクトオーナーと対処しなければならず不満を募らせているとき、プロダクトマネージャーがとにかく消え続けるリソースのために奮闘しなければならないとき、この問題が浮き彫りになります。重要なのは、多少のギブアンドテイクは必要になりますが、エンジニアリングチームを中心にプロダクトストラクチャーを作るのではなく、エンジニアリングと協力して連携を取れるようにすることです。

優先順位4.アーキテクチャとの整合

デベロッパーチームとの連携に関連してはいますが、実際にはソフトウェアアーキテクチャと整合性を図る方がはるかに困難です。基本的に、すべてのアーキテクチャはいくつかの目的を中心に設計されており、その結果、他の業務よりはるかに簡単な業務というのが出てきます。世には多くのチーム、特に非常に古いコードベースを用いているチームで、小さな作業にとても長い時間を要したり、様々な側面で変更が必要なチームがあります。大抵これはチームがアーキテクチャにおいて苦労しているからです。最新のアーキテクチャはこの特性を改善しますが、それでもアーキテクチャによる影響がプロダクトチームにあります。繰り返しますが、重要なのはバランスです。アーキテクチャがプロダクトを推進することは望ましくありません。一方、アーキテクチャを進化させてチームの働き方を改善することは、非常に重要な仕事になる可能性があることを認識してください。

優先順位5.ビジネスユニットとの整合

普段これは最も重要視される要素であるため、リストの最後にあることに不満を感じるビジネスユニットリーダーもいるかもしれませんが、これを最優先させるのは大抵大きな間違いです。よく言われるのが、「会社の統括について知りたいのであれば、ウェブサイトを見ればわかる」ということです。これが当てはまる理由は、プロダクト組織が（ユーザーや顧客ではなく）ビジネスユニットを中心に構成されていることが非常に多いためです。ビジネスユニットがユーザーまたは顧客を中心に編成されている場合、これはさほど問題にはなりませんが、多くの場合、機能や収益の流れなど他の要素を中心に編成されます。ユーザー、テクノロジー、ビジネスユニットがすべて連携していると便利ですが、そうならないしっかりとした理由があります。もしそのような状況にあなたがいるのであれば、まずはプロダクトと顧客の間の整合性をとり、その後テクノロジーとの整合性をとり、最後にビジネスユニットとの整合性を取るようにしましょう。

メモ：

–この議論の全ては、特定のチームモデル（https://svpg.com/dedicated-product-teams/を参照）およびチームが使用している開発プロセス（特にスクラムに当てはまります）に強く関連しています。特定のチームに移動し、スクラムなどの最新のプロセスを使用すると、これらの問題のいくつかが強制され、ほとんどの場合、上記の整合性を図る目標にかなり役立ちます。

–プロダクト組織の最適な構造は定まらないものであることを認識してください。組織のニーズは時とともに変化するはずであり、変化するでしょう。数か月ごとに再編成する必要があるわけではありませんが、一年ごとくらいで構造を再検討することは理にかなっています。

–特に大規模なチームの場合、同じようなサービスを提供するプロダクトチームが複数いることは多々あります。多くの場合、これらのチームを「コモンサービス」、「コアサービス」または「プラットフォーム」チームと呼びます。これは非常にレバレッジが高いですが、テクノロジー、依存関係、および幅広いユーザーのために、最も困難なタイプのプロダクトチームの1つでもあります。これらのコモンサービスチームには、強力で技術的なプロダクトリーダーを配置することを、忘れないでください。

最後に、チームを構成する完璧な方法は決してないことを理解しましょう。プロダクト組織の構成のすべての試みは、何かを犠牲にして何かを改善させます。したがって、プロダクトのほとんどの業務と同様に、トレードオフと優先順位付けが必要となります。うまくいけば、これらの要素が組織を前進させるのに役立つでしょう。