ロードマップに機能を書くべからず

機能を書くならバックログに

まず機能だけが書かれたロードマップから見ていきましょう。時系列に沿って、どんな機能を追加するのか並んでいます。

残念ながら、多くの場合、機能開発が遅延したり、差し込み案件が発生したりして、以下のようになってしまいます。

こうなると、もうこのロードマップは信頼できません。過去の実装がここまで遅延していると、次に取り掛かる機能がいつリリースされるのか分からず、どれの優先度がもっとも高いのかも判断するのが難しくなってしまいます。

こういった「機能」に近いものは、縦長のプロダクトバックログの形式で並べ、ユーザーストーリーに分解して見積もったものを上から順番に実施していくほうがスッキリします。

では、ロードマップがなぜ必要なのか

プロダクトバックログはとても良いものですが、プロダクトの中期的・長期的な未来を構想するには少し見づらくなります。特に、会社の中で中期的・長期的な方針を考える役割の人（経営層）にとっては使いづらいツールです。このコミュニケーションをスムーズにすることがロードマップの役割の1つです。

これは、決してロードマップを開発チームに見せないというわけではありません。ロードマップを共有した上で、ロードマップから分解したプロダクトバックログを用いて日々の優先順位付けを行います。

経営層と開発チームをつなぐために、考えなければならないのは数字です。経営層からは、プロダクトで実現する「インパクト」として、いくらの売上を立てるのかが求められます。そのため、経営層とコミュニケーションを取るロードマップには、数字をいれておきましょう。

ロードマップに、数字を書く

数字といっても「売上」など事業全体の目標だけを書くのではなく、どのチームがどの数字に責任を持ち、最終的な全社目標とする数字を作っていくのかに分解できると尚良いです。例えばフードデリバリープロダクトであれば、事業全体の売上を達成するために、営業チームはレストランを獲得すること、プロダクトは注文頻度を増やすことなど、役割を分けて目標とします。プロダクトが目標とする指標については、こちらのnoteもご確認ください。

肉厚なプロダクト指標をつくる - North Star Metricを起点にしたKPIツリー
https://note.com/ozyozyo/n/n66d22511f9e4

ロードマップに、期待されるアウトカムを書く

数字だけではなく「どうやってその数字を達成するのか」も書きましょう。どのタイミングに、どんな状態ができるから、その数字を上げることができるのか、を埋めていきます。例えば、「注文回数を3Qまでに500回増やすために、今対応できている自宅だけではなく、会社での利用ユースケースを拡充する」といった形です。

なぜ、機能を書かないのか？

ロードマップに機能を書いてはいけないわけではありません。「決済機能を追加する」など、数字に影響がある機能は書いても良いと思います。ただ、すべての機能をロードマップに書くことを、私は推奨しません。

「いくら売上を上げるのか」はプロダクト側の都合です。その売上をあげるために、どんなユーザー体験が良いのかは仮説検証を繰り返しながら解を模索していくものです。機能の構想を練っても、ユーザーインタビューをするとボロボロで、誰もそんな機能など欲していなかったということは日常茶飯事です。ロードマップでは、「数字」と「どの時期にどんな状態をつくるのか（アウトカム）」を示し、そのためのHowとなる機能については仮説検証を繰り返して作っていくのがよいというのが、今回のnoteの主張です。そして、目の前にいるユーザー目線だけではなくて、プロダクトが何をすべきか？という中期的な目線から機能を発想することも大事にしていきたい💪

まとめ

1. ロードマップには数字を書きましょう（売上と、プロダクトが持つべき指標）
2. どんな状態をつくることで、その数字を達成するのかを書きましょう（アウトカム）
3. 「機能」は仮説検証を繰り返して最も良い形を探すこととし、長期的なロードマップに決め打ちでは書かない（数字に影響があるような物は除く）
4. すべてのタスクがロードマップにあるわけではありません。日々の業務をこなしながら、ロードマップを実現できるように頑張っていきましょう。

ロードマップ、まだまだ模索しておりますので、みなさんの知見もぜひお聞かせください。ありがとうございました。