作者:マーティ・ケーガン
翻訳者:インターンスタッフ(アーテリジェンス)
記事に入る前に一つ用語の説明をさせて下さい:普段私が「デザイン」という言葉を使うときは、「UXデザイン」のことを指すようにしています。しかし、この記事のみにおいて、「デザイン」という言葉は「UXデザイン」と「ソフトウェア・アーキテクチャデザイン」のどちらも指します。ご了承ください。
1、プロダクトチームとディスカバリー
最近、フィーチャーチームとエンパワーされたプロダクトチームの違いがわかり始めた人が増えてきて、嬉しい限りです。
つい最近、ジェフ・パットン氏がこの違いについて、またフィーチャーチームのマインドセットについて考察した素晴らしい記事を公開していました。
本記事では、残念ながらフィーチャーチームで働いている状況に置かれている方々からよく来る、「プロダクトディスカバリーという概念はそもそもフィーチャーチームに当てはまるのか?」という質問について、考えていきたいと思います。
ただ、私はプロダクトディスカバリーという概念の正当性を主張する人ではないです。また、この記事を読んでいる誰もが自分の会社の改革を促すことができるわけでもないし、強いプロダクト企業に移動できるわけでもないことは理解しています。
ある意味、これは簡単な質問です。プロダクトディスカバリーとは、解決しろと言われた質問に対して、有効なソリューションを提供することですから。
ご存知のとおり、エンパワーされたプロダクトチームには、解決すべき問題が与えられ、ソリューションを見つける権限が与えられます。
対照的に、フィーチャーチームの大きな特徴は、解決すべき問題が与えられるのではなく、作るべき機能やプロジェクトを、大抵ロードマップの形で渡される、ということです。
多分、何かしらの問題のソリューションとしてその機能をステークホルダーは要求しているのでしょうが、それはただ自分が一番効果的だと考えるソリューションを説明しているだけに過ぎません。
このように説明すると、フィーチャチームにディスカバリーは当てはまらない、という結論になるでしょう。
ただし、このような回答は流石に物事を単純化し過ぎています。もう少し深掘りしてみましょう。
2、ディスカバリーとフィーチャーチームの関係性
プロダクトディスカバリーには、常に4つのリスクが存在することを思い出しましょう:
・バリューリスク(人々はそれを購入または使用したいと思うのか?)
・ユーザビリティリスク(ユーザーはそれを使用する方法を理解で切るのか?)
・実現可能性のリスク(私たちが持っている時間、スキル、テクノロジーでそれは構築できるのか?)
・ビジネスの実行可能性リスク(このソリューションは、ビジネスのさまざまな側面で機能するのか?)
エンパワーされたプロダクトチームでは、プロダクトマネジメント、プロダクトデザイン、そしてエンジニアリングという重要な3部門が効率的に動くことがリスクを処理するために必要です。
ただし、フィーチャーチームでは、バリューリスクと実行可能性のリスクに暗黙的に責任を負うのはステークホルダーです(そのため、フィーチャーチームのプロダクトマネージャーはどちらかというとプロジェクトマネージャーのような仕事をするのですが、これは二次的な現象です)。
フィーチャーチームでは、ステークホルダーがユーザビリティリスクと実現可能性のリスクに関してはチームに頼ります。ですから、プロダクトデザイナーともちろんエンジニアが必要になってくるのです。
なので、少なくとも多少のディスカバリーはまだフィーチャーチームに関係すると言えるでしょう。そして、フィーチャーチームで学んだスキルが多少はエンパワーされたプロダクトチームでも活きるものだということも、言えるでしょう。
3、フィーチャーチームとプロダクトチームのディスカバリーの違い
ただし、「効果的なソリューションを発見すること」と、「特定の機能に対してUXデザインをすること(デザイナー)、実現可能なものを作ること(エンジニア)」は、大きく難易度が異なることも、理解しておくべきです。
より高度なスキルが求められるのに加えて、フィーチャーチームではステークホルダーが望んだソリューションが通用しなかった際、究極的な責任はステークホルダーにあったのが、エンパワーされたプロダクトチームでは、自分たちに責任が降りかかってきます。結果に対して責任を負うことはとても難しいことです。
別の言い方をすると、ディスカバリーとは様々なアプローチを試して有効打を見つけるということです。フィーチャーチームでは、基本的に決められたアプローチが与えられていて、それをいかに良いものにするかが試されています。
いずれにせよ、フィーチャーチームのプロダクトマネージャーが企業のリーダーたちに、自分がビジネスの様々な側面を理解しており(ビジネスの実現可能性)、実際の顧客のことを深く理解していることを証明することができれば(特にバリューリスクについて)、リーダーたちはフィーチャーチームにも難解な課題を解決する、自分たちの実力を見せるチャンスを与えてくれるでしょう。
注記:この記事は、SVPG社 (Silicon Valley Product Group、https://svpg.com/) の制作記 事を、同社の許可を得て、アーテリジェンスのスタッフが無償で翻訳しています。本翻訳 記事の無断での複製・転載を禁じます。