小城久美子（@ozyozyo）

ソフトウェアエンジニア出身のプロダクトマネジャー。ミクシィ、LINEでソフトウェアエンジニア、スクラムマスターとして従事したのち、『LINE CLOVA』や『LUUP』などにプロダクトマネージャーとして携わる。そこでの学びを活かし、Tably社にてプロダクトマネジメント研修の講師、登壇などを実施。書籍『プロダクトマネジメントのすべて』（翔泳社）共著者

「ロードマップがない」もしくは「ロードマップは存在するが形骸化している」という状況を驚くほど多く見聞きします。

しかしながら、私はロードマップなしにプロダクトマネジメントはできないと言い切れるほどに、ロードマップが重要だと考えています。

この記事では、プロダクトロードマップをどのように定義し、扱うことでプロダクトづくりが良くなるのかを、提案します。

なぜ、プロダクトロードマップが必要なのか。それは、虫の目と鳥の目を切り替えるため

ソフトウェアをつくるとき、ユーザーの要望を叶えてすべての機能を作りきる日は来ません。また、機能を提供することでユーザーに提供できる嬉しさを図に表すと、残念ながら下図のように機能の数が増えれば増えるほどユーザーの嬉しさは鈍化してしまいます。

できるものなら、鈍化するポイントを見極めてそこで開発を止め、別の開発を進めることができたら、ユーザーの嬉しさの総量をより増やすことが可能になります。このように、普段は虫の目で近距離から見ているプロダクトを一度鳥の目で俯瞰して見ることで本質的な時間の使い方を考えることができるのがロードマップです。

プロダクトの連続的な成長と、非連続的な成長

未来のプロダクトの成長戦略を考えるとき、今のプロダクトの価値を深ぼる成長（連続的）と、今のプロダクトにはない価値を生み出していく成長（非連続的）の2軸に分かれます。

Kindleのような電子書籍アプリを例に取ると今後の成長方針は以下のようなマトリックスに配置されます。

そして、先程述べたようにただ機能が増えてもユーザーの嬉しさの総量は増えないので、すべての連続的な成長を諦めて、適宜新しい価値の成長に時間を使うと、効率よくプロダクトを成長させることができます。

打ち止める指標を定める

では、どこで連続的な成長を打ち止めて、次の非連続な成長に移ればいいのでしょうか？ この認識を合わせるためには、「この数字を達成したら次に行く」という指標を設定しておくとよいでしょう。

例えば、「スムーズに書籍が読める」ためには多くの機能開発が必要です。では、「スムーズに書籍が読めている」状態とはどんな状態だといえるでしょうか。例えば、早く集中できることであるとして「アプリを開いてから500文字読み終えるまでにかかる時間」のように定義をして、機能をリリースするたびにこの時間短縮に貢献したかを測るとよいでしょう。

このように定義をしておくと、目標としていた時間短縮ができたなら、例えば予定していたダークモード対応はスキップして次に進む意思決定もできるようになります。

売上を達成するために、機能を考える

さて、プロダクトを鳥の目で俯瞰したときには、ユーザーの幸せの総量だけではなく、会社として存続していくための売上についても目を向けなくてはいけません。先程の指標をすべて達成できたら、必要な売上に届くでしょうか？

売上などのKPIは「売上=単価×ユーザー数」のように方程式に分解できます。各機能が貢献する指標が検討されていれば、方程式に当てはめてどれくらい売上に貢献できるかも推定できるはずです。

売上目標に届かないときには、マトリクスに変更を加えましょう。KPIツリーを再考してどの指標にテコ入れすると良いかを考えます。（※ KPIについては第4回もご確認ください）

例えば、売上を上げるためには解約率を改善した方が良さそうであるという仮説が立つなら、解約理由を解決するための価値提案をロードマップに入れて、アイディエーションするとよいでしょう。

プロダクトロードマップはコミュニケーションツール

プロダクトロードマップのよくある誤解として、ロードマップのとおりに進行しなければならないというガントチャートとの誤用があります。プロダクトをつくることは仮説を検証していくことなので、スケジュールどおりに進行することはありません。そのような状態で、なぜAではなくBを今するのかを全体を俯瞰して検討し、可視化するのがプロダクトロードマップです。

プロダクトチームがロードマップを使ってコミュニケーションする相手は3つあります。

これらの会話はプロダクトを成功させるために必要不可欠です。会話を通して、ロードマップを常にアップデートして、現状と現状の仮説から推定する未来を可視化しておくとこれらの重要なコミュニケーションがうまくいきます。

プロダクトロードマップを3本に分ける

機能が書かれたロードマップもプロジェクトマネジメントにおいては必要になることがあると思いますが、今回お話ししているプロダクトロードマップにおいて機能は主役ではありません。

プロダクトロードマップには機能だけでなく、下図のように事業数値と目指す状態を書くことでなぜ機能が必要なのかの見通しが良くなり、プロダクトの未来を俯瞰して機能と紐付けて考えることができるようになります。

エンジニア出身の方にとっては事業数字を考えるのはハードルが高いと感じるかもしれませんが、一人で書く必要はありません。プロダクトロードマップはビジネスを担うチームと開発を担うチームの溝を埋めるものになるはずです。ぜひ、プロダクトに関わる方みなさんでロードマップについて向き合う時間をとってみてください。

各状態はNorth Star Metricに貢献するか？

ロードマップで可視化したときには、事業数字←→状態←→機能のつながりを確認すると同時に、状態同士の関係性も確認してください。目指す状態がちぐはぐになっていて、プロダクトに不要な足が生えていませんか？

不要な足であるかの確認方法の1つに第4回でプロダクトチームが北極星として目指すべき指標として紹介したNorth Star Metricが役に立ちます。各状態の指標がNorth Star MetricのInput Metricになっているか、North Star Metricに強く貢献しているものが優先度が高く配置されているかを確認してください。

仮説検証の結果をロードマップに反映させる

ロードマップを3本で書くと「機能をリリースしっぱなし」になることも防げます。機能をリリースしたあと目指した「状態」になっているかどうかの確認をしなければ次に何をするかが決められません。ロードマップに書いたスケジュールどおりに機能開発を進めるのではなく、ロードマップに書いた状態になっていなければ、急いで別の機能を考えて差し込まなければいけません。

常に「何のためにその機能が必要なのか」「なぜ今それを開発するのか」に向き合わせてくれるのがプロダクトロードマップの効果です。開発して終わりではなく、ユーザーに価値を提案し、その価値の対価として売上を上げる好循環を作りましょう。

「機能」思考から「状態」思考への転換

これまで「機能」でプロダクトを捉えてきた方にとって「状態」で考えることは訓練が必要です。機能は開発をしてリリースをすればアウトプットとして完了しますが、その機能を出したとしてもユーザーが思うように使ってくれなければ「状態」は完了しません。

このロードマップを3本で書くフレームワークも状態を考える上で有効ですが、この連載では各回で状態で考えるための思考法を紹介しています。「状態」で考えることが難しい方には、他の回や特に第二回で解説した仮説のミルフィーユが役に立つはずです。