予算のあり方は？ チームが抱える問題にどう働きかければいい？ Q＆A
この後、質疑応答が行われた。当日答えきれなかった質問についても、吉羽氏に回答いただいたので紹介する。
プロダクトマネージャーのキャリア
Q BtoBのプロダクトマネージャーと、BtoCのプロダクトマネージャーの違いは？ それぞれキャリアチェンジすることはできるでしょうか。
吉羽氏：BtoBとBtoCで最も異なるのは顧客（お金を払ってくれる人）の獲得モデルでしょう。これはロードマップに影響を与える可能性があります。またリリースサイクル、要求品質、機能の廃止や変更にも影響がある可能性があります。キャリアチェンジするのであれば、これらの違いを押さえておく必要はあると思います。ただ基本的に素早く学習する習慣があれば、業界やターゲットの違いも乗り越えられるはずです。
Q プロダクト思考はどのくらい必要でしょうか？ 正直、受託開発なのであまり必要性を感じていません。
吉羽氏：これからは受託開発的なものの中にも、新規事業やR&Dのような答えがわからないものも増えていくと考えられます。今後受託開発でもプロダクト思考は必要になると思います。
アウトカムに集中する指標の考え方
Q 収益はNorth Star Metricに向いていないと伺いましたが、最も適切なものは？ また、North Star Metricはフェーズで変動しますか？
吉羽氏：North Star Metricは「プロダクトが顧客にもたらしている価値の量」を示すものにするのが定石。例えば音楽サイトなら総再生時間（顧客が満足していれば増える）、ECサイトなら月間購入点数、SNSであれば月間アクティブユーザー数などがプロダクトの価値が受け入れられていることを示します。これは長期的な支えとなるものなので、頻繁に変わるものではありませんが、仮説検証の過程でプロダクトをピボットすれば変わる可能性はあります。
Q 開発組織の生産性を測るために、リリース数やコード行数を使うと、アウトプット思考で部分最適に陥る可能性があるのではと思う。開発によって生み出された売上や収益を見る方が適切かと思いますがどうでしょうか？
吉羽氏：その通りだと思います。いくら生産性が高くてもプロダクトが価値（一般的には会社の収益につながる何か）を生み出していなければ意味がないわけなので。
Q 検証フェーズもプロダクトバックログに入れるとのことですが、仮説検証フェーズでは完了の定義（Definition of Done）は不要と考えるのでしょうか？
吉羽氏：その仮説検証によって生み出したものを誰に向けてリリースするつもりなのかによって、満たさなければいけない品質基準（完成の定義）は変わってきます。例えばインタビューのために持っていくプロトタイプレベルのものであれば、完成の定義はハッピーパス（UXデザイナーがユーザーにたどってほしいと考える道筋）が動作することになります（自分のPCに入れて見せるだけなら、セキュリティも関係なければ、テスト自動化も不要です。プロトタイプは使い捨てなので）。とはいえミニマムで一般向けにリリースすると決めているのであれば、それに必要な基準は満たさなければいけないでしょう。
予算について
Q 実験して効果を見ながら進めていく場合、予算やロードマップ作成をどのタイミングで行えばよいでしょうか？
吉羽氏：予算のあり方とプロダクトマネジメントは若干、相反します。スタートアップの資金調達モデルのような形が理想です。まず実験するための資金を用意して、その範囲内でユーザーインタービューや仮説検証を行い、そのソリューションにニーズがありそうと評価できた時点で、追加で投資をします。その資金でMVP（Minimum Viable Product）を作り、評価し、行けそうという評価になったところで予算を作ります。年度の予算は大きなプールとしてとっておき、そこから資金をいろんな案件に払い出していきます。
本当にプロダクトとして育つということがわかれば、さらに予算を追加で持ってくるというやり方が良いと思います。ロードマップも引くのは良いですが、あくまでも現時点での方向性であることをちゃんとうたっておくことです。
Q 仮説検証するための具体的な予算感は？ 絞りすぎてもあるはずの鉱脈に達せないこともあるのではと思います。
吉羽氏：会社の規模や検証の規模によりだいぶ変わりそうですが、検証ではすべてを明らかにする必要はなく、重要だと思われること、リスクが高いと思われることを検証すればよいので、事前に詳細に計画して大人数・大規模でやる類いのものではありません。数人×数カ月くらいが初期のプロダクトのアイデアの検証段階の規模感かなと思います。大きすぎるチームはムダな仕事を生み出してしまうので。
組織の改革
Q「事業責任者は数字を出せ！」と言いますが、プロダクトマネージャーの責任である「なぜ」をまず議論するにはどうすべきでしょうか？
吉羽氏：これはプロダクトの始め方が良くないかもしれないです。絵に描いたビジネスモデルやプロダクトアイデアにいきなり目標売上を設定しようとしてもわからず、何ら根拠のない数字になりかねません。数字を出すには仮説検証を素早く回して、ダメなアイデアを素早く捨て、可能性がありそうなものを早めに見つけ、見つかったら素早く投資していく考え方が必要。これは企業の年間予算主義の考え方とは大きく異なります。AmazonやGoogleでさえもプロダクトをたくさん廃止しているので、そういった事例を示しても良いかと思います。
Q プロダクト主導のマインドセットを組織に広めるために、チームはどのように外部に働きかけるべきでしょうか？
吉羽氏：マインドセットを含めた組織改革はボトムアップとトップダウンの組み合わせが定石です。ボトムアップだけだと時間がかかるのと、周りへの浸透に多大な労力がかかるためです。一方でトップダウンだけだと、現場は「また上が何か言い出した」くらいの温度感になってしまい自分ごととして捉えられません。
これらを踏まえると、まずは自分たちのチームで目に見える成果を出し、それに関心を持ってもらい、その上でトップ層になぜうまくいったのかを説明したり、必要な教育を受けてもらい納得してもらったりするのが良いのでは。トップに話をする際、外部の第三者（コンサルタントなど）を使って説得力を持たせるのも一つの手です。
Q 上長などから「動くものがないと判断できない」と指摘され、何も作らないことに対する理解が得られない。どう説得していくべきでしょうか？
吉羽氏：動くものとは必ずしも本番リリースレベルの品質を持つものである必要はありません。プロトタイプレベルでも十分評価可能なのでなるべく工数をかけずに評価可能なものを作ると良いと思います。Dropboxの場合はそれが動画でした。ティザーサイトを作って登録者数を見てみるといった方法もあります。
Q 大規模なECサイトを開発しているが、チームがファンクションごとに存在し、リソースのないチームがボトルネックになってスピード感が出ない。どのような開発体制が望ましいでしょうか？
吉羽氏：バリューストリームを通過する時間が短くなるようにするのが王道です。ボトルネックを解決する方法としては、ボトルネックになっている箇所を増強する（そのファンクションに人を増やす）か、ボトルネックのチームがやっていることを自分たちで引き取る（つまり自分のチームをクロスファンクショナルにする）のいずれかになると思います。改善によってボトルネックは変化するのと、通常受け渡しが多いとリードタイムが長くなるので後者の形がおすすめ。若干古い事例だが、Spotifyのチーム構成が参考になると思います。
Q 現在のプロダクトマネージャーがプロジェクトマネジメントの成功体験を引きずっていて仕事の進め方が変えられずにいる。結果としてそのプロダクトは成功していない。周囲はどのように考え方や働き方のシフトをサポートできるでしょうか？
吉羽氏：結果的にプロダクトがうまくいっていないのであれば（アジャイルで開発しているなら）ふりかえりで扱うべき重要なテーマはそれになります。みんなで事実を把握し、なぜそうなっているのか、今後同じことが起こらないようにするにはどうするべきかを考えて、プロダクトチーム全体として行動を変えていく必要があります。
例えばプロダクトマネージャーやプロダクトオーナーの判断が良くなくても、その一方で開発チームがその判断を丸のみしているのであれば、それも問題です。同じゴールを目指すチームとして打ち返していく必要がある。まずは事実をみんなで認めてみると良いと思います。またマネージャーの立場であれば、1on1などでコーチングしても良いと思います。
Q 既存プロダクトのフルリニューアル案件のプロダクトマネージャーです。KPIや評価がロードマップに集中してしまう。どのようにチーム、ステークホルダーと会話をしていけばよいでしょうか？
吉羽氏：この構図は「Noと言わない（言えない）」ことによって起きます。プロダクトマネージャーやプロダクトオーナーがステークホルダーの言いなりになっている、開発チームがプロダクトマネージャーやプロダクトオーナーの言いなりになっているといった感じです。
組織としての成果達成を目指すので、成果達成の阻害となるものについては全員が意見を言えるようにする必要があります。そのために必要なのがチームビルディングなど。またありふれているが心理的安全性の醸成も必要です。この手の話はリーダーが積極的に良いチームを作る活動に時間を使っていかないとなかなか変わらないので、手を替え品を替えやっていくしかないと思います。あとは1on1やレトロスペクティブを活用するのが良いと思います。
ProductZine読者向けウェビナーのお知らせ（第7回：2021年2月24日開催）
毎月開催しているProductZineの読者向けウェビナーですが、2月開催分は本対談でお話しいただいたエムスリー山崎聡さんにご登壇いただきます。
テーマは「プロダクトマネージャー育成」と「チーム作り」。事前登録制で参加無料です。ぜひ併せてご参考ください！
- 詳細・参加申し込み⇒ https://codezine.jp/application/15/
