こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。
会の概要
以下、イベントページから引用です。
プロダクトロードマップは、プロダクトの重要な指針を示すものです。そのため、プロダクトマネージャー、エンジニア、ビジネス、デザイナーがチームとなって、向き合わなければなりません。
しかし、実際にはプロダクトマネージャーが考えるものとして捉えられているケースも多く、目の前の業務が優先となり、自分ごととして捉えられていないエンジニアも多いのではないでしょうか。
そこで今回は、「プロダクトマネジメントのすべて」の共同著者の小城さん（@ozyozyo）をお招きし、プロダクトマネジメントの考え方から紐解くエンジニアのプロダクトロードマップとの向き合い方についてお話しいただきます。
会の様子
小城さんの講演
プロダクトマネジメントとエンジニア
今回の講演はエンジニアを対象にしたお話だったということもあり、プロダクトに関わる以上はプロダクトマネジメントに関わっていると言えるんだという前提から話がありました。*1
プロダクトマネジメントの体系化
また、プロダクトマネジメントの領域は徐々に体系化されているということで、過去にされてきた失敗の回避もやりやすくなってきたという話がありました。
プロダクトマネジメントが失敗するとどうなるか？
プロダクトマネジメントが失敗した際に起きることが、魚を例にして説明されていきました。
魚をプロダクトとして進化させようとした結果、ある人は陸上でも動けることが重要だと考えて足をつけてみたり、ある人はもっと可愛くしようとして顔を変えたりしたしてしまい、何もいいところがない化け物のような存在になってしまったというのが、プロダクトマネジメントの失敗例として挙げられていました。
仮説のミルフィーユ
プロダクトは局所的に捉えられがちなので、
- Core(プロダクトの世界観、企業への貢献)
- Why(誰をどんな状態にしたいか、なぜ自社がするのか)
- What(ユーザー体験、ビジネスモデル、ロードマップ)
- How(誰をどんな状態にしたいか？)
の観点を持つことで複数観点からプロダクトを捉えられるようになるというお話がありました。
プロダクトロードマップとは？
プロダクトロードマップは生きたドキュメントであるため、"WBS"のように絶対に守らないといけないスケジュールでもないという話がありました。
また、前述したように、プロダクトは機能がどんどん増えればいいわけではないため、BackLogを中長期的に見るような役割をプロダクトロードマップが担うイメージを持つとわかりやすいということです。
ロードマップの三本線
プロダクトロードマップに必要な三本線として、
- できるだけずれることがない「事業数字」
- 仮説検証を繰り返す中で随時アップデートする「目指す状態」*2
- こまめに仮説検証して変更をする「作る機能」
が挙げられていました。
パネルディスカッション
講演のあとは、小城さん大西さんのお二人でパネルディスカッションがありました。
ロードマップ作成にどこまでのメンバーを巻き込むべきか？
まず、ロードマップだけを作成するということはありえないという話がありました。(仮説のミルフィーユの観点で考えた場合、ロードマップはWhatの部分)
そのため、普段からWhyの認識が揃えられているようなチームなのかどうか？という部分でロードマップ作成に巻き込むメンバーは変わってくるだろうということです。
ロードマップの活用頻度は？
ロードマップをいつ更新するか決めるというよりも、更新頻度を見て仮説検証の進みが遅いことに気がついて行動変容を起こすという使い方に近いということでした。
ロードマップの修正頻度は？
まず、事業数字は基本的には変えないものだということでした。
目指す状態を変える間隔は、リリースサイクルや新規事業かどうかによるものの、ローンチしているプロダクトであれば月一位の頻度が多いというお話がありました。
目指す状態は売上指標になる？
小城さんは、売上指標というよりも顧客が挙げている成果や顧客が価値を享受できているか？という部分に注目をするということでした。
機能だけが書かれたロードマップが挙がってきた場合、エンジニアからどういうコミュニケーションをするべきか？
全部状態ベースにしましょう、という話をしだすと頭がパニックになってしまうことが多いのではないか？というのを小城さんは懸念されているそうで、まずは「直近解決したい課題ってなんでしたっけ？」といった具合に、目先の部分から始めていくのがよいいのではないか？ということでした。
また、ユーザーの解像度がめちゃくちゃ高いメンバーが育っていくと、コミュニケーションが取りやすくなるのではないかというお話もありました。
小城さんが経験したエンジニアのよかったコミュニケーションは？
まず、こういう質問が出てくるのは良いコミュニケーションだと思うという話がありました。
小城さんは色々なカルチャーの会社を見ているそうですが、「どんな機能を作ろうと今思っているんですか？」という質問をしてくれたり、「XXという課題を解決したいならこんな機能も作ってみました」というコミュニケーションを取ってもらえたとき(=プロダクトマネジメントに興味を持ってくれたとき)はすごく嬉しいという話がありました。
エンジニアとプロダクトマネージャーが大事にしている軸が違う場合、どう折り合いをつけるべきか？
エンジニアとプロダクトマネージャーはそれぞれ見ているものや大切にしている軸が違うことが多いですが、ユーザー視点や仮説ミルフィーユのWhyで見てみると、自ずと歩み寄れるのではないか？ということでした。
また、ふりかえりの場をエンジニアとプロダクトマネージャーで持つことも重要だというお話もありました。
Q&A
PdM/UXデザイナ/エンジニアのチームの場合、みんなでプロダクトを作る前提ですが、PdMとUXデザイナの最終意思決定の境界はどのあたりになるか？
こちらのnoteの紹介がありました。PdMは、Whyだけは譲らないようにすることが重要だということです。
させたい状態を定義するのは難しいのだが、どのような思考でそのような状態を定義しているか？
ビジョンレベル100があるときビジョンレベル20ならその差分はどうか？というような思考をすると「プロダクトアウト的にこういう世界観を作りたいな」というのが出てくるため、そのあとはユーザーインタビューなどでユーザーの行動を観察しながら状態を具体化しているようにしているそうです。
技術的負債の解消やセキュリティ対応などTech的には対応mustなものはどうロードマップと折り合いをつけるとよいか？
セキュリティ周りに関しては、常に他の品質特性などとのトレードオフが働いているため、ロードマップに載せた上でどんな状態を目指すのか？というのを考えるようにしているということでした。
一方で、技術的負債は常に解消するもので、一定スプリント計画などで対応のバッファを持っておくことが多いそうです。
会全体を通した感想
小城さんのお話を聞くのは今回が初めてだったのですが、非常に優しく落ち着いた語り口で話をしてくれたので、話が聞き取りやすかったです。
会の内容としては、小城さんが現場で実際にどのような動きをしているのか？という部分が知れたのが特によかったです。
*1:小城さんがプロダクトマネジメントですごく大切だと思っているし好きな考え方として、プロダクトマネジメントは専業性の掛け合わせが重要でプロダクトマネージャーが専業性をつなぎ合わせる訳では無いという話がありました
*2:行動が変わったことに対してお金を払っているため、「作業が2分で終わる」といった状態が大切になってくる
