CodeZine(コードジン)

特集ページ一覧

プロダクトマネージャーは、仮説検証とアジャイル開発を使いこなす「両利き」になろう

ProductZineオンラインイベント「プロダクト開発を学ぶ夏」レポート

  • ブックマーク
  • LINEで送る
  • このエントリーをはてなブックマークに追加
2020/09/18 11:00

 プロダクトの構想を検討するところから、立ち上げ、それを世の中に問いかけ、育てていくことまでの全般を担うことが求められるのがプロダクトマネージャー(PM)である。PMの役割で重要になるのが、開発者や運用者仮説検証を行う人などの専門家をうまく連動させて良い結果を出せるようにすることだが、その中でも重要になるのが、「ターンアラウンド」を短縮することである。そのためにはどんな観点で捉え、何を学ぶ必要があるのか。プロダクト開発のターンアラウンド戦略について、ProductZine チーフキュレーター 市谷聡啓氏が解説した。

目次

プロダクトマネージャー(PM)の役割とは?

 ProductZine チーフキュレーターを務めている市谷氏は、政府CIO補佐官を務めつつ、株式会社レッドジャーニーを立ち上げ、DX伴走支援を行っている。専門領域は仮説検証とアジャイル開発だ。

ProductZine チーフキュレーター 市谷聡啓氏
ProductZine チーフキュレーター 市谷聡啓氏

 市谷氏はまずプロダクトマネージャーの役割について解説を行った。プロダクトマネージャーは「プロダクトの構想を検討するところから、立ち上げ、それを世の中に問いかけ、育てていくことを全般的に担うため、守備範囲は広い」と説明する。

 だが仮説検証、開発、運用などの活動はすべてチームで進めていくことになる。そのため、プロダクトマネージャーの役割として非常に重要になるのが、各タスクを専門に行う人たちを「うまく連動して結果が出せるようにリンクを押さえていくこと」だと言うのである。

 開発と仮説検証がうまく連動していなかったり、チームと運用がうまくかみ合っていなかったりというところを見て、リンクが弱いところを適宜補強していくことが、プロダクトマネージャーが特に重視すべきところだと言うのである。だからといって各領域の知識が不要というわけではない。各領域のより深いところは専門家に委ねることになるが、各専門性を結集させ、連動をなめらかにするためには、それぞれの領域の知見が必要である。

 ではどんな状況でプロダクトマネージャーが必要とされるのか。「事業=企業」のプロダクト事業会社では、組織責任をCEO、事業責任をプロダクトマネージャーが担うことになる。小規模な企業の場合だと、CEOとプロダクトマネージャーのポジションに同じ人が就き、組織と事業のどちらの責任も担うことがあるという。

 昨今話題のDXの文脈においてもプロダクトマネージャーは必要だ。市谷氏は「DXは外部環境からの破壊的な変化に対応していくこと。具体的にはデジタルテクノロジーを利用して、新しいプロダクトやサービス、ビジネスモデルを構築し、顧客体験の変革し価値を創出する活動である。だからプロダクトマネージャーが必要だ」と言い切る。

ターンアラウンドを短くするために

 このようにプロダクトマネージャーの役割を挙げると、やるべきことが多すぎて、「プロダクトマネージャーなんてできる人がいるのか」という疑問が生じる。そこで市谷氏はフォーカスすべき点を一つ提示した。それが「ターンアラウンド」である。

 ターンアラウンドとは、「働きかける」→「反応を得る」→「理解を正す(学ぶ)」という3つの活動で構成される。この活動をプロダクト開発に置き換えると、「プロダクトを世の中に提供する」→「ユーザーからフィードバックを得る」→「ユーザーの欲求を理解し機能を見直す」という活動になる。この一連の動きがターンアラウンドであり、プロダクトマネージャーの主眼は「その時間をいかに短くできるか」だと市谷氏は言うのである。

 ターンアラウンドは、「何を学ぶためなのか」と「何をどのくらい働きかけるのか」の二軸で捉える必要がある。

 前者の「何を学ぶ」のか。それは「プロダクトの担い手たちが知りたいこと」で、三点あるという。第一は「有用性、有意性」。「われわれが提供するものに価値があるのかということ」と市谷氏。第二は「継続性」。継続的に価値を感じてもらうためにはどんな体験を提供すべきなのか、また今の体験のどこに問題があるのかなどについて学ぶのである。第三は「可能性」。これはこの先より価値を感じてもらい、より多くの人に届けるためには何を揃えていくべきなのかを把握することである。つまりプロダクトマネージャーはこの3つのポイントを学ぶために、何をどのくらい働きかけるのかという設計をしていくのである。

 だが、ここで注意すべきなのは、そのターンアラウンドが長いほど、「その期間中、そのプロダクトに関する価値を読み間違えているなど、無駄を積み上げている恐れがある」ことだ。作っている間も、使い始めてもらっている間も、そのプロダクトに関する正しい判断はできない。だから「ターンアラウンドを短くする必要がある」と市谷氏は強調する。ターンアラウンドを短くすることは、「失敗を早くせよ」という言葉で表すこともできるが、その本質は学びを得るまでの距離を短くすること、つまり間違えている期間を最短化することであり、そのための工夫をチームで行っていくことである。

 例えばソフトウェア開発は、プロダクトを出してユーザーからフィードバックを得るまでの時間、ターンアラウンドがものによっては長くなる。つまり分からないままの時間が長く続いてしまうということだ。ではその期間を短くするためにどういった作戦があるのか。

 有用性、有意性を知るためには、ソフトウェア自体を作らないとつかめないわけではないという。「ノーコードツールを使って、ユーザーインタビューやプロトタイプ検証をしていくという作戦がある」と市谷氏は言う。

 第二の継続性については、プロダクト体験が必要になるため、MVP(Minimum Viable Product:実用最小限の製品)による検証を行う。そして第三の可能性については、ノーコード検証とMVPによる検証を織り交ぜることだという。

 そしてもう一つ、ターンアラウンドを短縮するために欠かせないのが、段階的に行うことだ。例えば1段階目ではユーザーインタビューでProblem-Solution-fitの度合いを確かめ、2段目では体験をしてもらえるようプロトタイプを提供してその反応を得る。そして3段階目では、MVPを作って検証する。このように段階的にすることによって、「機動的な判断ができるようになる」と市谷氏は言う。プロトタイプの段階で、その方向性がないと分かればそこで損切りし、次の行動に移ることができる。


  • ブックマーク
  • LINEで送る
  • このエントリーをはてなブックマークに追加

著者プロフィール

  • 中村 仁美(ナカムラ ヒトミ)

     大阪府出身。教育大学卒。大学時代は臨床心理学を専攻。大手化学メーカー、日経BP社、ITに特化したコンテンツサービス&プロモーション会社を経て、2002年、フリーランス編集&ライターとして独立。現在はIT、キャリアというテーマを中心に活動中。IT記者会所属。趣味は読書、ドライブ、城探訪(日本の城)。...

バックナンバー

連載:ProductZineウェビナーレポート
All contents copyright © 2005-2020 Shoeisha Co., Ltd. All rights reserved. ver.1.5