ロードマップは決めきるべきじゃない。「売れない」から脱出するために、PdMがやるべきこと【エムスリー山崎聡】

人はつい「楽なほう」に流れがち。プロダクト開発も同様で、気を抜くとすぐに「楽だけど売れない」状態に陥ってしまいます。そうした事態を防ぐために、エムスリーのCTO兼VPoPを務める山崎さんは、自身がPdMを務める際には「楽じゃないが売れる」道を徹底的に追求しているそう。

山崎さんによると、「楽じゃないが売れる」プロダクト開発に必要不可欠なのは「プロダクトのロードマップを、あえて決めきらないこと」だそう。とはいえ世の中には、すでに確定したロードマップがあり、それに向かって走っている最中のプロダクト開発現場のほうが多いはず。それにプロダクト開発に関わる人々も、ロードマップが確定しているからこそ、日々の仕事を着実にこなしていける、という側面もあるでしょう。

なぜ山崎さんは、ロードマップを決めきらないことにこだわるのでしょうか？　「このままじゃ売れないのでは」と危機感を感じたら、何から始めればいいのか？　詳しく聞きました。

• keyboard_arrow_down 決まりきったロードマップに沿っているうちは、プロダクトは売れない
• keyboard_arrow_down 「売れないプロダクト開発」からの脱出は、プロダクトビジョンの見直しから
• keyboard_arrow_down コツは「10人未満で小さく始める」「議事録をとらない」
• keyboard_arrow_down これは「プロダクトマネジメントを、アジャイルにやる」ための方法論である

――山崎さんはPdMとして、エムスリー社で数々のプロダクトを成功に導いてきましたが、プロダクトマネジメントにおいて最も大切にしていることは何ですか？

山崎：プロダクトのビジョン、方向性や長期の目標を含むロードマップの内容を、決めきらないことです。

新しいビジネスを始めるときは往々にして、確実に売れる仮説など立てられません。運よく正しい仮説を立てられたとしても、世の中や顧客、また組織が変化して状況が変わることもある。だから、「これに沿っていれば売れる」と断言できるロードマップを決めきり、その通りに成功する確率は、極めて低いと言えるでしょう。

そして、一度仮説として定めたロードマップに沿って開発を進める中で、仮説検証して学んだ結果を、ロードマップに反映することなく進んでしまえば、重要な課題を見落とし、途中で現れた新たな勝ち筋を見逃してしまいます。これがつまり「楽だけど売れない」という状況なのです。

――改めて考えると、確かにその通りです。ではなぜ「ロードマップに仮説検証の結果が反映されない」といった状況に陥ってしまうのでしょうか。

山崎：職種や立場の異なる多くの関係者が協働する場合、その方が仕事をしやすいからです。

ロードマップの内容がしっかり決まっていると、安心できるんですよね。異なる職種で、異なる景色を見ている関係者がたくさんいるからこそ、同じ将来像を共有して「我々は立場は違うが、同じ方向に向かっている」という前提をつくっておくと、それが互いの信頼につながる。つまり、楽なんです。

でも「安心できる・楽である」と「売れる・儲かる」は違います。私は楽かそうでないか、儲かるか儲からないかは、この4象限で表現できると考えています。

山崎：ロードマップを決めきると「楽」です。そのロードマップに沿って計算通り売れれば「①楽だし儲かる」に分類されるでしょう。けれど、プロダクト開発においてこれはかなりレアケースです。となると、ロードマップを決めきって「楽」な道を行く多くのプロダクト開発は、「③楽だが儲からない」の罠に陥ってしまっているんです。

ではどうするか。一足飛びに「①楽だし儲かる」に移行できるのが理想的ですが、これは先述の通り難易度が高すぎる。最も現実的なのは「②楽ではないが儲かる」を目指すことでしょう。

もし「すでにプロジェクトが進んでいて、今さら見直しは無理」だと思うなら、それこそ、決まりきったロードマップに引きずられ「③楽だが儲からない」の道に進んでしまっているのではないでしょうか。

――複数の関係者と一緒にプロダクト開発を進めていくうえでは、ロードマップで進む方向を決めないと、誰が何を目指しているのか曖昧になり、チームがばらばらになってしまいそうです。

山崎：そうならないために「プロダクトビジョン」が必要です。昨今のプロダクト開発では、まずプロダクトビジョンで、顧客の課題を解決した先の世界を形作り、そこから逆算する形でロードマップを引き、課題解決の流れを具体化していく、という方法が一般的です。プロダクトビジョンがハッキリしていれば、それより具体的な未来を描くロードマップもつくっていけますね。

私がプロダクトビジョンを定めるときに大切にしているのは、「拡張可能な世界観」を描くことです。

――「拡張的な世界観」とは、どんなものですか？

山崎：比較的自由度の高い地図のようなイメージですね。『ドラゴンクエスト3』でいえば、アリアハンくらいの地図です。……って、逆にわかりにくいですか（笑）。

言い換えると、ゲームの面白さがわかる最小範囲。プロダクトでいうなら、ユーザーに動かぬ価値を感じてもらえる最小の範囲、ともいえます。

プロダクトで価値を届ける範囲を「世界観」として、それを最初から狭めておくことで、プロダクトの拡張性を確保するのです。

――具体的に教えてください。

山崎：たとえば、私が好きなSNSであるX（旧Twitter）。もし私が、何か新しいSNSをつくるとしたら、まずは日本語でつくり、日本で広く使われることだけを決めておくでしょう。その後の海外展開の方法や順序は、日本語版が成功してから考えればいい。日本語版のあとは英語版、中国語版……などと事前に計画するより、最新の市場状況を観察して、動き出す直前に決めるのです。もちろん、英語が得意であれば英語版からのスタートでも良いでしょう。重要なのは、ユーザーに刺さってから次の手を考える、ということです。

先に広範囲すぎるビジョンをつくってしまうと、目指す最終形態と現在との距離が遠すぎて、具体的な計画を立てたくなり、結果的にロードマップもガチガチに固定されてしまいます。

「拡張可能な世界観」は、マルチプロダクト戦略にも通じると思います。マルチプロダクト戦略では、価値を届けるユーザー群の中で、解決すべき課題に応じてプロダクトを増やしたり、1つのプロダクトを機能別に別プロダクトに分けることで拡張していけます。また、機能は増やさず、特定の機能を磨いて世界観を広げることも、もちろんあるでしょう。

――プロダクトビジョン、すなわち拡張可能な世界観の設定と、それをもとにした開発は、どのように進めていけばよいでしょうか？

山崎：プロダクトビジョンは、PdMに力があればその人の考えをベースに、他のメンバーの意見を聞きながらブラッシュアップしていくのが早道。PdMのレベルがまだそこまで達していなければ、メンバーと対話しながら描いていくのがよいでしょう。このディスカッションに経営者を入れる場合は、トップダウンで的外れな方向にいかないよう注意が必要ですね。

経験則ですが、こうしてできあがったプロダクトビジョンに、もし8割くらいの人が「待ってました」と共感してくれるのなら、PMF（プロダクトマーケットフィット）はしやすいと思います。

次に、「拡張可能な世界観＝プロダクトビジョン」に則ってその時々で何をするか、たとえば既存機能を深く磨き込むのか、新しい機能を加えていくのか、それらをどのようにやるのかなどを決め、開発を進めていく。その最中にもっと重要なことが見つかったら、思い切ってロードマップを変更します。リソースに余裕があれば、プロダクトを追加してマルチプロダクトに展開することもできる。

これが、「ロードマップを決めきらないプロダクト開発」です。何も考えずに最初のロードマップを突き進むより、ずっとうまくいくはずです。

もっとも、こうして定まったプロダクトビジョンさえも、ロードマップと同じように、「今後一切更新しません！」と決めきってしまってはいけません。プロダクトビジョンも、ロードマップと同じで常に考え直すこと。8割は自信を持って進めつつ、2割くらいは「本当にこれが現時点でのベストな方法なのか」と疑い続けることも必要ですね。

――すでに動き始めている開発現場で、プロダクトビジョンを“拡張可能な世界観”にして、それに基づいたプロダクト開発を進められるようになるには、どのように初めの1歩を踏み出したらよいですか。

山崎：一番最初は、自分ひとりで「拡張可能な世界観」を考えてみるところから始めてみるのが良さそうです。とはいえ、考える取っ掛かりが見つからなかったり、今までの考え方に無意識に縛られてしまっていたりもするかもしれません。

そんな時は、「もしも○○だったら」と考えてみるといいですよ。もし自分がCPOだったら？　あるいは、いま所属しているこの会社の社長になったら？　こうして、普段の自分の立場に囚われず、プロダクトをどう変更していけばよいだろうかと考える。すると、新しい視点から、戦略がいくつも思い浮かぶはずです。

あとは、同じプロダクト開発チームの中で仲間を集めて、みんなで大いに語り合いましょう。その際は、口頭伝播が可能な範囲の小さなチームで進めた方がよいと思います。目安としては、10人未満でしょうか。大人数だと、合意形成する方向に話が進みがちで、革新的なアイディアが出にくいように思います。

ちなみに、「拡張可能な世界観」について話し合う場合、議事録は取らない方がいいかもしれません。議事録を取ると、一貫性バイアスがかかって、「一度こう発言したから」と別のことを言い出しにくくなる可能性があります。

――少人数で進めたほうがいいのですね。では、すでに10人以上の大人数でプロダクト開発が進んでいる場合は、どうしたらよいでしょう？

山崎：その場合、無理にプロダクト開発チーム全体をスコープに入れようとせず、チームやプロジェクトを切り出し、実験的に小さく進めてみるのがいいでしょう。既存の機能を一部切り出してもいいし、新しい機能を追加する部分でやってみてもいい。あるいは、1つの開発チームや、1つの機能あたりなどで試してみるのもよいと思います。

小さなスコープでやってみた結果「そもそもプロダクト全体の、決まりきったロードマップって必要なんだっけ？」という話になったり、「この動きを全体に適用したほうが成功しそうだ」と気づいたりすることもあるはずです。

――改めてまとめると、拡張可能な世界観としてのプロダクトビジョンを軸としながら、ロードマップに仮説検証の結果を反映し続けることが、「売れるプロダクト」へとつながるわけですね。

山崎：その通りです。実は、今回説明した方法は、アジャイル開発の考え方をプロダクトマネジメントに応用したものです。

まずはプロダクトビジョン、すなわち拡張可能な世界観を定め、ロードマップに沿って試行錯誤しながら、そこで得た知見を、プロダクトビジョンやロードマップに反映し、また試行錯誤をする……という繰り返し。アジャイルに試行錯誤し、変化に適応するのです。

プロダクトビジョンとロードマップは、どちらから先に着手しても大丈夫。とにかく、売れるプロダクトをつくりたいのなら、決まりきったロードマップに安心するのだけは、やめたほうがいいかなと思います。

――プロダクト開発がアジャイルにできているかどうかは、どうやって判断しますか？

山崎：あらかじめ決められたことを毎回のスプリントでやっていく分割ウォーターフォールや、とにかく機能を順番に実装していくフィーチャーチーム化が見られたときは、戦略が凝り固まっている、危険なサインだと思います。

それから最後にお伝えしたいのが、今回紹介した内容は組織によって合う合わないがあるし、必ずしもこのやり方でなければダメだ、と言っているわけではありません。ただ、このやり方にはメリットはあるし、うまくいくケースが多いというだけ。もし少しでも参考にしてもらえる部分があれば嬉しいなと思います。

取材・執筆：古屋江美子
編集：光松瞳
撮影：赤松洋太