【米SVPG社 翻訳記事】プロダクトチームとフィーチャーチームの違い

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

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

‍

理想とするプロダクトチーム実現のために

‍

この記事は確実に多くの人を動揺させることになるでしょう。

悲しいことに、テクノロジー企業でのプロダクトの役割を取り巻く継続的な混乱は悪化の一途をたどっています。さらに、会議の講演、トレーニングプログラム、およびプロダクト担当者向けのいわゆる認定プログラムで、問題や問題のある行動が制度として取り入れられているのを目にします。

私は過去にこの問題について何度か話しており、エンパワードプロダクトチームに関する記事と基調講演の中では特に詳細に話しました。しかし、多くの人は自分に都合がいいことのみをピックアップしてしまっていることから、より明確に語る必要があることに気づきました。

したがって、この記事を読むのは苦痛かもしれませんが、プロダクトの世界の人々の矛盾した混乱を招くようなメッセージに不満を感じている場合は、ここで耐えてくれれば、非常に必要としていた明確な見解を得られることでしょう。

テクノロジーの世界の「プロダクトチーム」には大まかに分けて3つの異なるタイプがあります。

３つの種類のプロダクトチーム

デリバリーチーム

単純な数で一番実際に多いのは、実はプロダクトチームではなく、デリバリーチームと呼ばれるものです。「開発チーム」、「スクラムチーム」または「エンジニアリングチーム」とも呼ばれ、会社がSAFeのようなものを実行している場合、残念ながらこれはあなたのチームです。このチームには、何人かのデベロッパーとプロダクトオーナーがいます。このモデルのプロダクトオーナーは、私が「バックログ管理者」と呼んでいるものです。確かに、誰かがこのバックログ管理作業を行う必要があります。しかし、このバックログ管理作業はアウトプットを捻出するためだけのものであり、私が重要視している顧客のための一貫した真のイノベーションにはほとんど繋がりません。このモデルが実際には再パッケージ化されたウォーターフォールであり、真のハイテクプロダクト企業で使用されていない理由については、他の場所で書いています。なので、これは横に置いておきましょう。

この記事の主題はデリバリーチーム以外の二つのチームの違いです。

ここからの文章では、まだ定着しておらずかつ合意が得られていない名称を使います。しかし、これは昨今業界として他の二つのタイプのチームの両方を「プロダクトチーム」または「プロダクトスクアッド」と呼んでいるため、行わなければならないことなのです。この先を見るとわかりますが、この二つのチームは表面的には似ていますが、特にプロダクトマネージャーの役割について話すと、大きく異なります。

プロダクトチーム

‍エンパワーされたプロダクトチームの長所について書いたとき、私はこの記事でいう「プロダクトチーム」について書いています。より詳しく言うと、プロダクトチームは部門という枠を超えているチームです（プロダクト、デザイン、エンジニアリング）。彼らは（アウトプットではなく）結果に焦点を置いて成果が図られます。そして、彼らは与えられた課題の最良の解法を見つけるためにエンパワーされています。

この文脈の中でのプロダクトチームの目的は、顧客が喜ぶ方法で問題を解決し、かつビジネスにもなるようにする、ということです。

そうであることを願う限りですが、この文脈のプロダクトチームであることは、全体の割合の中ではごく少数であることが事実です。

残念ながら、多くの場合、チームはまったくエンパワーされていません。逆に、彼らはビジネスに奉仕するためにそこにいます。

フィーチャーチーム

この記事では、この３つ目のチームを「フィーチャーチーム」と呼びます。ここでは、フィーチャーチームのより確立された定義を少し曲げていますが、これらのチームがアウトプットに焦点を全て当てていることを強調できるため、この用語を使用しています。フィーチャー（機能）、そして時々プロジェクトは、通常ロードマップと呼ばれる優先リストの形式でチームに提供されます。

しかし、ここがさらに深く掘り下げる必要がある部分です。

プロダクトには常に4つのリスクがあることを思い出しましょう。

・バリューリスク（人々はそれを購入または使用したいと思うのか？）

・ユーザビリティリスク（ユーザーはそれを使用する方法を理解できるのか？）

・実現可能性のリスク（私たちが持っている時間、スキル、テクノロジーでそれは構築できるのか？）

・ビジネスの実行可能性リスク（このソリューションは、ビジネスのさまざまな側面で機能するのか？）

エンパワーされたプロダクトチームでは、プロダクトマネージャーは価値と実行可能性を保証する責任があり、デザイナーは、使いやすさを保証する責任があり、そしてテクノロジーリーダーは実現可能性を保証する責任があります。チームは、積極的なギブアンドテイクを行い真の協力を実現させ、全員に通用するソリューションを見つけます。

エンパワーされたプロダクトチームの真のプロダクトマネージャーになることがどれほど難しいかについて話したり書いたりするのは、まさに価値と実行可能性を確保することが非常に難しいからです。これらが簡単だと思われる場合は、こちらをお読みください。

フィーチャーチームにも、使いやすさを保証するためのデザイナーと実現可能性を保証するためのエンジニアがいます。ただし、そこでは価値とビジネスの実行可能性は機能をロードマップで要求したステークホールダーまたは上司の責任になります。この点を理解することが重要です。

彼らがあなたに（例えば）機能Xを構築する必要があると言った場合、彼らは機能Xがある程度の価値をもたらすと信じており、機能Xはビジネスにとって実行可能なものであると信じています。

ただし、ステークホールダーが明記はされておらずとも価値と実現可能性に置いて責任を負うはずなのに、彼らはもし期待通りの結果が出なかった時、そのチームを非難することは指摘しておいた方がいいでしょう。時間がかかり過ぎてしまったから、デザインが悪かったから、期日を守ために重要な機能がカットされたから、などと。もちろん、チームはこれがそもそも作る価値があると決して確信していませんでした。これは以前から起こっていることで、より詳しくここで書いています。

‍

フィーチャーチームとプロダクトチームの違い

‍

表面的には、フィーチャーチームとエンパワーされたプロダクトチームはどちらもチームです。したがって、それらの見た目は似ていますが、違いは深くまであります。

価値提供と実行可能性の確保

‍

まず、プロダクトマネージャーの役割から始めましょう。エンパワーされたプロダクトチームでは、プロダクトマネージャーが価値と実行可能性を確保する必要があり、顧客、データ、業界、特にビジネス（販売、マーケティング、財務、サポート、法務など）に関する深い知識は絶対的に不可欠です。

対して、フィーチャーチームでは、その知識は（せいぜい）ステークホールダーの間で分散されるようなものです。

いずれにせよ、このモデルでのプロダクトマネージャーの責任が、プロダクトチームによって大きく異なることは明らかです。

フィーチャーチームでのプロダクトマネージャーの仕事は、最も一般的には、機能を設計して提供するための監視役を行うファシリテーターとして、または実際には何も特定の責任を負わない、曖昧で弱いクロスファンクショナルリーダーとして説明されます。これらのフィーチャーチームは、プロダクトディスカバリーを行っていると勘違いすることがよくありますが、実際には、それは単なるデザインとおそらく少しのユーザビリティテストです。

ただし、フィーチャーチームがプロダクトマネージャーの役割に与える影響は他にもあります。

魅力的な人材を引き付けることができるかどうか

‍

チームがエンパワーされていないため（つまり、提供するアウトプットが決められた場合、実用可能な権限が与えられていないため）、真のプロダクトデザイナー（サービスデザイン、インタラクションデザイン、ビジュアルデザインそしてユーザーリサーチに熟練した人）を引き付けて維持することは非常に困難です。

フィーチャーチームはほとんどの場合、デザイナー（いる場合）がグラフィックデザイナーです。グラフィックやビジュアルデザインが重要ではないというわけではありませんが、重要なのは、現在語られるデザイナーとは大きなギャップがあるということです。誰かが少なくともインタラクションデザインを理解し、できればユーザーリサーチを行う必要があります。したがって、このモデルのプロダクトマネージャーに、これらのギャップを埋めるよう圧力がかかることはよくあることです。

デザイナーが使用するツール自体を学習することは困難でないが、良いデザインやユーザーリサーチがどのようなものかを学ぶのは困難であることから、この状況の更なる悪影響が考えられます。多くのプロダクトマネージャーは、真のプロのプロダクトデザイナーと仕事をする機会がなかったため、悲しいことに何が欠けているのかさえを知り得ないのです。

幸運にもチームに真のプロダクトデザイナーがいる場合（少なくとも、スキルを十分に活用できる会社に移動するまで）、彼らはほとんどの場合（そして当然のことながら）プロダクトマネージャーがいる理由を疑問視します。何故なら、彼らはすでにその仕事の大部分を行っているため、プロダクトマネージャーのフィーチャーチームであるがために加わった責任を認知するのが簡単だからです。

‍

フィーチャーチームにおけるプロダクトマネージャーは「肩書きだけ」で実際にはプロジェクトマネージャーでしかない

結果的に、フィーチャーチームでは、プロダクトマネージャーの役割は主にプロジェクトマネージャーであり、一部（熟練していない）デザイナーです。

多くの場合、エンジニアにも同様のフラストレーションがあります。実際にはプロジェクトマネージャーであるプロダクトマネージャーは、エンジニアが考える働き方と対立した考え方をすることが多いです。言うまでもなく、このモデルでは、エンジニアは納品業務に追いやられています。何度も言ったように、その場合はエンジニアの実際の価値の約半分しか得られません（つまり、優れたエンジニアは離れて、実際に自分の技術が使えるエンパワーされたプロダクトチームに参加します）。

したがって、この重要なポイントを締めくくると、プロダクトマネージャーは「会社で最も強力な才能の一人でなければならない」し、「CEOはプロダクトマネージャーを会社の将来のリーダーになる可能性がある存在だと見なす」必要があり、「強いプロダクトマネージャーはプロダクトのCEOである」ことが不可欠です。これは決してフィーチャーチームのプロダクトマネージャーのことを指しているのではありません。

この時点で、自分はフィーチャーチームモデルで仕事をしているのか、エンパワーされたプロダクトチームモデルで仕事をしているのかがわかるといいのですが、人々はフィーチャーチームモデルに参加していると認めたがらないことが多々あることを私は学びました。

なので、自分のチームをチェックするためのテストがあります。

‍

自分のチームがフィーチャーチームかプロダクトチームかを判定する方法

判定チェックリスト

・優先順位が付けられた要求する機能と期日を含むロードマップが提供されていますか、それともビジネスの成果で解決するための課題が割り当てられていますか？

・あなたとあなたのデザイナーの間に役割の混乱はありますか？

・あなたとあなたのデリバリーマネージャーの間に役割の混乱はありますか？

・あなたは一日のほとんどをプロジェクト管理に費やしていますか？

・OKRを使用しようしたら、混乱してしまい、最終的に拒否されたか、それとも結果と機能の不自然なマッシュアップができてしまったことはありますか？

・エバンジェリストや傭兵のチームはありますか？

・説明責任のレベルはどれくらいですか？

‍

エンパワーされていないチームは全てフィーチャーチームである

フィーチャーチームとプロダクトチームは一見非常に似ていますが、運用方法、権限付与と説明責任のレベル、特にプロダクトマネージャーの責任が大きく異なります。

いくつかの例外を除いて、最高の企業の最高のプロダクトチームはすべて、エンパワーされたプロダクトチームモデルに基づいたものです。しかし、私が最高のプロダクト企業と考えている企業でも、すべてのプロダクトチームがエンパワーされてはいません。実際、一部はフィーチャーチームです。通常、それはリーダーがその特定のチームをまだ信頼していないためです。時には、その信頼をまず獲得する必要があります。そしてまた時には、問題点はリーダーが与えられた問題の解決策を自分の意思で決めたがっているところにあります。

私は、エンパワーされたプロダクトチームに対する強いこだわりを隠そうとしたことはありません。しかし、私は今、エンパワーされたチームを広めようとするだけでなく、さらに先に進む必要があると考えています。フィーチャーチーム、それらが引き起こす問題、およびそれらがもたらす好ましくない結果を指摘する必要があるのです。

今日、無数の企業がデリバリーチームモデルの無益さに気づき、真にテクノロジーを活用したプロダクト企業へと変革を起こす必要があることを認識しています。しかし、フィーチャーチームに移行する表面的な変化を加えることで「目的を達成した」ことにできると考えています。

ここで締めくくりとして、フィーチャーチームのプロダクトマネージャーになることと、エンパワーされたプロダクトチームになることの違いを強調したいと思います。この二つは完全に異なる仕事であり、大きく異なるスキルセットを必要とします。おそらく同じ役職であってはなりません。

非常に多くのデザイナーやエンジニアが真のプロダクトマネージャーに接したことがなく、エンパワーされたチームで仕事することができていないことは、悲しいことです。だからこそ、十分に活用されていない才能がたくさんあると私は主張し、最高の企業が働き方と同じような働き方をするように、人々を説得しようとしているのです。

一つ、すぐにできることは、次にプロダクト関連の記事やツイートを読んだり、会議の講演に参加したり、プロダクトトレーニングに参加したりするときに、作成者、スピーカー、またはトレーナーはエンパワーされたプロダクトチームについて語っているのか？それとも、フィーチャーチームについて語っているのか？と問うことです。

‍