- 当日のスライド：プロダクトマネージャーは両利きを目指そう
プロダクトマネージャー（PM）の役割とは？
ProductZine チーフキュレーターを務めている市谷氏は、政府CIO補佐官を務めつつ、株式会社レッドジャーニーを立ち上げ、DX伴走支援を行っている。専門領域は仮説検証とアジャイル開発だ。
市谷氏はまずプロダクトマネージャーの役割について解説を行った。プロダクトマネージャーは「プロダクトの構想を検討するところから、立ち上げ、それを世の中に問いかけ、育てていくことを全般的に担うため、守備範囲は広い」と説明する。
だが仮説検証、開発、運用などの活動はすべてチームで進めていくことになる。そのため、プロダクトマネージャーの役割として非常に重要になるのが、各タスクを専門に行う人たちを「うまく連動して結果が出せるようにリンクを押さえていくこと」だと言うのである。
開発と仮説検証がうまく連動していなかったり、チームと運用がうまくかみ合っていなかったりというところを見て、リンクが弱いところを適宜補強していくことが、プロダクトマネージャーが特に重視すべきところだと言うのである。だからといって各領域の知識が不要というわけではない。各領域のより深いところは専門家に委ねることになるが、各専門性を結集させ、連動をなめらかにするためには、それぞれの領域の知見が必要である。
ではどんな状況でプロダクトマネージャーが必要とされるのか。「事業＝企業」のプロダクト事業会社では、組織責任をCEO、事業責任をプロダクトマネージャーが担うことになる。小規模な企業の場合だと、CEOとプロダクトマネージャーのポジションに同じ人が就き、組織と事業のどちらの責任も担うことがあるという。
昨今話題のDXの文脈においてもプロダクトマネージャーは必要だ。市谷氏は「DXは外部環境からの破壊的な変化に対応していくこと。具体的にはデジタルテクノロジーを利用して、新しいプロダクトやサービス、ビジネスモデルを構築し、顧客体験の変革し価値を創出する活動である。だからプロダクトマネージャーが必要だ」と言い切る。
ターンアラウンドを短くするために
このようにプロダクトマネージャーの役割を挙げると、やるべきことが多すぎて、「プロダクトマネージャーなんてできる人がいるのか」という疑問が生じる。そこで市谷氏はフォーカスすべき点を一つ提示した。それが「ターンアラウンド」である。
ターンアラウンドとは、「働きかける」→「反応を得る」→「理解を正す（学ぶ）」という3つの活動で構成される。この活動をプロダクト開発に置き換えると、「プロダクトを世の中に提供する」→「ユーザーからフィードバックを得る」→「ユーザーの欲求を理解し機能を見直す」という活動になる。この一連の動きがターンアラウンドであり、プロダクトマネージャーの主眼は「その時間をいかに短くできるか」だと市谷氏は言うのである。
ターンアラウンドは、「何を学ぶためなのか」と「何をどのくらい働きかけるのか」の二軸で捉える必要がある。
前者の「何を学ぶ」のか。それは「プロダクトの担い手たちが知りたいこと」で、三点あるという。第一は「有用性、有意性」。「われわれが提供するものに価値があるのかということ」と市谷氏。第二は「継続性」。継続的に価値を感じてもらうためにはどんな体験を提供すべきなのか、また今の体験のどこに問題があるのかなどについて学ぶのである。第三は「可能性」。これはこの先より価値を感じてもらい、より多くの人に届けるためには何を揃えていくべきなのかを把握することである。つまりプロダクトマネージャーはこの3つのポイントを学ぶために、何をどのくらい働きかけるのかという設計をしていくのである。
だが、ここで注意すべきなのは、そのターンアラウンドが長いほど、「その期間中、そのプロダクトに関する価値を読み間違えているなど、無駄を積み上げている恐れがある」ことだ。作っている間も、使い始めてもらっている間も、そのプロダクトに関する正しい判断はできない。だから「ターンアラウンドを短くする必要がある」と市谷氏は強調する。ターンアラウンドを短くすることは、「失敗を早くせよ」という言葉で表すこともできるが、その本質は学びを得るまでの距離を短くすること、つまり間違えている期間を最短化することであり、そのための工夫をチームで行っていくことである。
例えばソフトウェア開発は、プロダクトを出してユーザーからフィードバックを得るまでの時間、ターンアラウンドがものによっては長くなる。つまり分からないままの時間が長く続いてしまうということだ。ではその期間を短くするためにどういった作戦があるのか。
有用性、有意性を知るためには、ソフトウェア自体を作らないとつかめないわけではないという。「ノーコードツールを使って、ユーザーインタビューやプロトタイプ検証をしていくという作戦がある」と市谷氏は言う。
第二の継続性については、プロダクト体験が必要になるため、MVP（Minimum Viable Product：実用最小限の製品）による検証を行う。そして第三の可能性については、ノーコード検証とMVPによる検証を織り交ぜることだという。
そしてもう一つ、ターンアラウンドを短縮するために欠かせないのが、段階的に行うことだ。例えば1段階目ではユーザーインタビューでProblem-Solution-fitの度合いを確かめ、2段目では体験をしてもらえるようプロトタイプを提供してその反応を得る。そして3段階目では、MVPを作って検証する。このように段階的にすることによって、「機動的な判断ができるようになる」と市谷氏は言う。プロトタイプの段階で、その方向性がないと分かればそこで損切りし、次の行動に移ることができる。
