Product Managerに必要な3つの視点について

Nakamura Hiroki / 中村 浩樹

Product Manager(以下PdM)の役割とは何か、言葉で表現すると
"会社や事業全体の方向性を理解し、プロダクト(もしくはサービス)を成功に導くこと"です。プロダクトのフェーズはまちまちで、ゼロから新規プロダクトを企画して立ち上げることもありますし、すでにあるプロダクトをグロースすることから関わることもあります。

いかなるフェーズであれ、PdMが持つべき視点を端的に表しているのがこの図です。

画像1

© 2011 Martin Eriksson. Re-use with appropriate attribution.

この図は私のオリジナルではなく、Martin Eriksson氏の図です。UXとビジネスとテクノロジー、まさにこの3つがPdMが持つべき視点です。1つずつ私の解釈を加えながら説明してみます。

UX 

言い換えるとユーザーから見た価値の質です。良いUXとは、ユーザー価値の質が高い状態を指しますが、この質を分解すると定量的な質と定性的な質の2つがあります。

(1) 定量的な質

定量的な質は、プロダクトとしての本質的な価値に紐つく指標です。例えば、音声認識をコアとした自動議事録アプリを仮定すると、音声認識率がUXのKPIになります。KPIが決まれば、それをどう測定するのか、どの精度まであげればユーザーに満足いただけるか、それを上げるために足りていないものは何か、と分解していきます。このKPIは、測定可能であることと、その指標の目標値に対して具体的なアクションがひもつけられる必要があります。

定量的な質に対して、PdMが実施するべきことは一言で言うと、定義することと、改善のサイクルを作ることです。改善のサイクルを作るためのプロセスに分解すると以下の通りです。

a. プロダクトとしての本質的な価値に紐つく指標を定義する(UX KPI)
b. UX KPIのゴールとタイムラインを定義する
c. UX KPIが測定できる仕組みを作る
d. UX KPIを上げるための課題を設定し、高速に解決する
e. UX KPIの向上が、プロダクトのKGI(売り上げやDAUなど)と関連付いているかを定期的にチェックする

特に重要なのは(c)の測定できる仕組みを作ることです。早く目に見える価値を生み出したい誘惑を抑え、定量的なUXを測定する仕組みを作り、コストをかけずに改善のサイクルが回るようにする。これができているかどうかで、その後のUXの品質向上の活動がスムーズに回るかどうかが決まる、と言っても過言ではないと思います。

(2) 定性的な質

一方の定性的な質ですが、これを数字で表現することはとても難しいです。あえて言語化すると、使い心地であったり気持ちよさでしょうか。理想的には、目的がなくてもつい続けたくなる気持ちよさです。それは反応速度であったり、ちょっとしたアニメーションであったり、そのプロダクトのキャラクターによって"気持ちよさ"を大事にするポイントは変わってきます。

定性的な質で大事にするには、定性的な質の重要性を理解することです。言い換えると、定量的な質に依存しすぎないこと、です。1ユーザーとして、直感的に使い続けたいか、気持ちが良いUXになっているか、という感性にも頼る。定量的に測定することが重要なのは大前提ですが、感性を判断に加味することは、プロダクトに対する決定権を持つPdMだからできることであり、重要な観点です。

テクノロジー

テクノロジーの観点で重要なのは、実現する難易度とコストへの理解と低レイヤーな技術への理解です。

(1) 実現する難易度とコストへの理解

当たり前のことですが、難易度とコストがわかっていれば、サービスのスペックを突拍子もないものにすることもありませんし、目指すべき状態とチームの能力に乖離があれば早い段階からチームを強化することができます。(後者のギャップまで正確に理解している人は案外少ない印象です)

難易度とコストを理解するのに一番良い方法は、実際に開発した経験を持っていることですが、全てのレイヤでその経験を積むのは難しいことがあると思います。（とはいえ、努力はすべきですが

開発経験がない場合、少なくとも開発のプロセスは深く理解すべきです。例えば、音声認識エンジンの精度を上げる時、どういう学習データがどれぐらい必要で、それを学習データとして使うための前処理にはどういう作業が必要で、学習にかかるコスト、そして精度評価まで一連のプロセスを理解していれば、コストは読めるようになります（プロセスがわかれば、難易度も半分ぐらいは理解できるようになるはずです）

難易度が理解できていると、不確定要素、つまりプロジェクト上のリスクもわかるようになるので、先んじてバックアッププランを立てやすくなるという副次効果もあります。

(2) 低レイヤーな技術への理解

マーケティング的なバズワードに惑わされないために重要なのは、低レイヤーな技術への理解です。例えば、TCP/IPヘの正しい理解があれば、これに関連するソフトウェアの動きは理解できますし、何がどこまでできるのかも想像できます。逆に、最終製品だけを見ていると、実は同じ技術を使っているのに違うバズワードで表現されたものを同じと認識できません。また、本質的な技術の高度さを測ることもできません。

低レイヤーな技術を理解するのは、道のりが長いため、技術そのものが好きな人でないと苦痛が伴います。しかし、一度理解しておくとプロダクトのスペックを決める時もそうですし、何か技術的な課題が発生した時、それが解ける問題なのかどうなのか、勘所が掴めるようになります。

実際にコードを書くエンジニアであれば、技術のトレンドを追いかけて、Howの知識を更新し続ける必要があります。一方のPdMの観点では、Howのトレンドを追いかけるよりも、根底にある技術を理解した方が、本質的なユーザー価値として実現できる境界を理解することができるため、PdMの役割としてはより良いかと思います。

ビジネス

ビジネスについては、一言で言うと、そのプロダクトに関わる全てのステークホルダーの動機付けを理解することがとても重要です。このステークホルダーは、社内外の全ての人たちです。

(1) ユーザーの動機付けへの理解

そのプロダクトが対象とするユーザーの動機付けとは、なぜそのプロダクトを使うのか、そのプロダクトがない状態ではどういう手段でそのニーズを満たしているのか、または課題を解決しているのか、などです。ユーザーがそのプロダクトを（他の現状の手段から乗り換えてでも）使う動機付けがわかれば、それに対してどれぐらいの対価を払ってもらえるかを想定することができます。

ビジネス = ビジネスモデルとなりがちですが、ビジネスモデル自体は、それを得意とする専門家にお任せした方が良いケースがあるでしょうし、実際にお任せすることも可能だと思います。一方で、PdMは、UXとテクノロジーを理解した上で、なぜユーザーがそれに価値を感じるか(価値の質)、どれぐらいのユーザーがその価値を感じてくれるか(価値の量)、というより根本的な問いに対する答えを思考するべきだと思います。

(2) パートナーの動機付けへの理解

当然ですが、そのプロダクトを共に作るパートナー企業の動機付けも重要です。なぜ、自分の会社と協業するのか、その協業の狙いは何か、逆にあまり気にしていないことは何か、そしてその動機付けは、パートナーの組織内でどう作られるのか。会社という形自体は、一つの意思をして存在しないため、意思決定者やキーパーソンは誰か、どういうプロセスで意思決定がなされるか、まで解像度を上げて理解する必要があります。

パートナーの動機付けが深く理解できていれば、ユーザー価値を作るためにどうお互いのwantを結びつけるかを想定しやすくなりますし、何かパートナーの状況に変化があったときでも、それがどうプロダクトに影響するのか予想しやすくなります。

(3) 社内ステークホルダーの動機付けの理解

最後は、社内です。自社がなぜそのプロダクトを開発して、推進するのかです。主に、経営層の視点での全社方針の理解と、その方針の元でプロダクトの方針をどうすり合わせるか、が大事になってきます。このすり合わせは、一度で終わるものではなく、特にダイナミックな経営がされている会社では常に動くので、細かくアップデートし、短いサイクルで期待値を確認し続ける必要があります。

すでに社内でそのプロダクトの存在意義が確立されている場合は、期待値のコントロールの"型"ができているケースも多いです。一方で特に新規事業の場合は目に見えるプロダクトや実績がない分、難易度が高く、PdMの数あるタスクの中でも最も重要な(そして難しい)タスクになることが多いと思います。

最後に

色々と書きましたが、私自身も全てできてませんw すべてを完璧にこなせる人はとてもとても稀だと思います。では、一番重要なことは何か、それはこの3つに集約されます。

1. PdMに必要な視点を理解する
2. 自分に足りてない視点やスキルを理解する
3. 2を埋めるために必要な人を巻き込む

この3つができればチームとして、必要な能力を満たすことができますので、必要な視点を網羅して推進することができます。PdMは、必要なことを理解する能力と、足りないこと埋められる能力、この2つが最も大事なスキルだと考えています。そして、足りないことを埋められる能力があると、一緒に仕事をしたチームから多くを学ぶことができ、結果、PdM個人としての知識や能力も上げられるのではないかと思います。

PdMとして必要な視点を、UX、テクノロジー、ビジネスの3つで分解してみました。少しでも参考になればと思います。

この記事が気に入ったらサポートをしてみませんか？