ロードマップでは方向と状態変化のストーリーを表現しよう！「粒度が粗く抽象的になったガントチャート」状態からの卒業を目指して
本記事は 地味PM Advent Calendar2022の31日目の記事です。
嘘です。永嶋さん・さとじゅんさんに黙って勝手に言ってるだけです。
好きな言葉は「許可を求めるな謝罪せよ」です。
良いロードマップはストーリーがある。
— 坂上 真大（マダイ）@VALT JAPANのなんでも屋 (@madai0517) September 21, 2022
悪いロードマップは機能しかない。
良いロードマップはプロダクトの在りたい姿と、そこにどういう順番で到達するのかが明確に示されている。
悪いロードマップは機能とローンチ時期のみで実質WBSになってしまっている。 https://t.co/GlxDpjSuh8
今回のnoteは私の過去一反響のあったこのTweetについて自分のロードマップの作り方・考え方に対しての言語化を試みたものになります。
また、前回のnoteでも少し触れた以下の内容についての解説記事にもなっている、つもり、です。
記載する内容は短期・中期・長期の時間軸において、対象とするものがどういう状態になっていくかを記載するようにしています。
5W1Hで言うWhenとWhereでマトリクス表を作るようなイメージです。
上手く書けた部分も、そうでない部分もあるので疑問・質問・反論・感想など様々なフィードバックいただけると嬉しいです。
よく見かける【開発項目が並べられたロードマップ】の問題点
おそらくほぼ全ての人はロードマップと呼ばれるものを目にしたり作成したことがあると思います。
が、その目にしたロードマップの大半は
横軸に時間
縦軸にチームや人
内容に開発する機能
を置いたものではないでしょうか。
少なくとも自分は多くの場面でこの形式のロードマップを見てきましたし、自分自身もよくこの形式で作っていました。
ですがこの形式には様々な問題点があります。
1. 粒度が粗く情報量が減っている
この構成で作られたロードマップ（と呼ばれるもの）から分かることは
どのチームが（あるいは誰が）
何の開発を（あるいは何の作業を）
いつ頃までやっているか（いつ出すことを目標としているのか）
のみです。
この情報構成はWBSやガントチャートと全く同じもの、つまりWBSやガントチャートの粒度が粗くなり情報量が減っただけなのです。
そして大抵の場合において、この内容が選択された背景となる事業戦略や具合的な情報もわからないはずです。だって書いてないんだから。
これを作った人の頭の中にはあるのかもしれませんが、これを見る人には一切伝わらないわけです。
※もし知っているとしたら、それは別の資料や口頭での説明によるものでしょう。
2. アウトカムと今やる理由がわからない
アウトプットは機能名などから想像がつきますが、それによって提供する価値と得られるもの・アウトカムまではわかりません。
例えば「お気に入り機能」「決済手段の追加」「キーワード検索の精度向上」などが並んでいたとします。
それぞれどんな機能なのか・どういう改善を求めているのかは大枠ではわかりますし、大枠ではみんな同じことを考えられますが完全には一致しない状態になります。
具体的な話として「決済手段の追加」を取り上げてみます。
支払い方法を増やして利便性を上げるのか、決済手数料を下げるために追加するのか、あるいは多通貨決済に対応するために実施するのか…etc
決済手段の追加1つ取っても様々な目的があり得るわけですが、そういった情報はこのロードマップだけではわかりません。
それ故になぜ今やるのか？を理解することは困難です。だって書いてないんだから。
3. リリースしたら終わるわけではない
このロードマップの問題点はもう1つあります。
それはリリースまでしか描かれないこと＝リリースしたら終わりになっていることです。
リリースしたサービスや機能が想定通りに使われたり効果を発揮することばかりではなく、むしろ効果が十分ではなくて改善することもあるでしょう。
しかしこの機能を並べたロードマップでは改善までは表現されません。
仮に改善の部分までロードマップに記載したとしましょう。
しかしリリースするまでは何をどのくらい改善し続ける必要があるのかはわかりません。
よって予め計画に入れ込むことは難しく、このロードマップ的なものからは運用にかかるリソースのことは抜け落ちてしまいます。
プロダクト開発はリリースしてからが始まりです。
我々は点ではなく線で仕事をしています。
機能をリリースしたら終わるのではなく、その瞬間から運用と改善が始まります。そこに繋ぎ目などなく一連の流れなのです。
しかしこの機能ベースのロードマップではその点が表現されていません。
ロードマップで示すべきは目標到達へのストーリー
これらの問題点を解決するためにはロードマップの在るべき姿を考え直し、そこからどういう形でアウトプットすることが良いのかを考え直してみます。
何故ロードマップが必要となるのか？
その答えは事業の時間軸と開発の時間軸を揃えることにあると思っています。
ほぼ全ての事業会社にとって事業計画があるはずで、その達成のために様々な施策を実施していくわけです。
事業の時間軸と開発の時間軸を揃えるとはどういうことなのか？
地味PM Advent Calendar2022で永嶋さんが初日に素晴らしい言葉で書かれています。（流石です）
“経営判断に足りる、シンプルなメッセージと、事業計画にきちんとミートできるのか、できないなら、打ち手をどうするのか（たとえば、人を増やしたら達成できるのか、作る以外の選択肢も考えるのか、なんなら撤退も視野にいれるのか）を考えられる材料を揃える”
つまりロードマップは事業数字の達成に向けた実行計画書であり、経営と現場が同じ方向を向いて実行に向かうための架け橋となるものでなくてはいけないと思うわけです。
組織を導くロードマップに必要な要素
では具体的に何が示されていればいいのか？私は以下の3つの要素が必要だと考えます。
何のためにやるのか？Vision実現に向けた繋がりはあるのか？（Why）
利害関係者は誰なのか？それによって誰に影響があるのか？（Who）
その結果、何が (得られる | 解決する) のか？（Value）
組織全体で同じ方向を向いて活動するためにはこの3つの要素をストーリーとして表現することが重要だと考えます。
ストーリーとして表現するということは
どういう優先順位で
どういうステップを踏んで
どの方向に向かって
が可視化され組織としての共通認識を持てるようにすることが事業と開発の時間軸を揃えるために必要な最初の一歩だと思います。
これは前回のnoteでも紹介しましたが「ストーリーとしての競争戦略」のこの表現がとても好きです。
戦略を構成する要素がかみあって、全体としてゴールに向かって動いていくイメージが動画のように見えてくる。全体の動きと流れが生き生きと浮かび上がってくる。これが「ストーリーがある」ということです。
ロードマップの縦軸には「プロダクトが影響を与えるもの」を置く
横軸は時間のままでOKです。
問題は縦軸で、ここに何を置くかが重要だと考えます。
私は「プロダクトによって影響を受けるもの→プロダクトが影響を与えるもの」としました。
※当初は「影響を受けるもの」としていましたが主体的・能動的な表現に変えました
ちょっと曖昧な表現で申し訳ないですが、to B SaaSの場合は実際の利用者だけでなく、利用者が所属するチームや組織まで影響する場合がありますし、to C エンタメ系の場合はKGIがそれに当たると思います。
例えば従業員の育成のために教育・研修系のサービスにおいて利用者は従業員個人ですが、従業員がきちんと学習しているのか？それによってチームがどのように変化していくのか？など管理職目線でも考えていく必要があると思います。
一方でゲームアプリの場合は課金率・課金額をいかに高めていくか？そのために可処分時間の獲得やLTVなどの指標をどのように上げていくかにフォーカスしていくことになるはずです。
というわけで当初「利害関係者」でまとめようと思っていましたが、上記の理由からこのような表現になりました。
このあとの具体例でも少し触れますが、正直自分でもまだ上手に言語化できていないなと思っている部分なので、いろんな方からご意見もらえると嬉しいです。
内容にはOKRと紐付けたものを設定する
私自身はOKRを評価制度にすることに関しては否定派ですが、OKRの考え方そのものはとても好きです。
OKRが好きな理由がObjective＝ムーンショットという高い目標を掲げることにあり、より野心的でより向上心を高めるようなものを掲げるという考え方が自己やプロダクト・事業の成長にとても好ましいと思うからです。
が、それ故に評価制度に導入すると評価期間の半年に縛られてムーンショットではなくなってしまいがちになることが相性悪いなと思っています。
まぁ、それは今回あまり関係ないのでこの辺にして…
OKRはObjectiveの高い目標を中長期的に設定し、それに対してのKR（計測可能な指標）を目標として設定します。
Objectiveは会社やプロダクトのVisionを分解した形で、KRは事業計画上必要な数字から割り戻した値をそれぞれ設定していきます。
できれば半年などの短期間ではなく2〜3年後までOKRを考えておくと良いと思います。
前述の通り、ムーンショットを考えるにあたっては短期間だと現実に打ちのめされてしまうので程よく先の期間が良いと思います。
この工程が最も重要で、ここが定まればロードマップは完成したも同然だと思います。
あとはActionを考えてみたり、すでに考えていたものをマッピングしていたりすれば完成です。Actionについては直近のみ埋まっていればOKですし、ここはみんなでアイディアを出しあえば良いと思います。
このようにOKRと紐付けることで中長期からの逆算で考えた一連のストーリーが見えてきますし事業計画と紐付いた目標値であるKRがあり、そのKR達成のための施策（Action）は何なのか、全てが繋がって可視化されるようになります。
ロードマップの具体例
(1) SaaSプロダクトの場合
こちらはある会社のワークサンプルで作成したものをベースにしています。
内容は全く変えているので多分大丈夫でしょう。
好きな言葉は「許可を求めるな謝罪せよ」です。（二回目）
見ていただければわかるかと思いますが、まずA領域にフォーカスし、段々とC領域へフォーカスする領域を変化させていきます。
序盤注力していたA領域は後半では注力しないことになっています。
そしてD領域については2年間フォーカスせず、その後に取り組んでいくことがわかると思います。
またOKRと組み合わせて半年毎にどの領域でどの状態（KR）の達成を目指していくのか？を明記しています。
このような選択を行っている理由を示す内容もあったのですが、加工しても情報がバレそうなのでここでは割愛します。
簡単に紹介すると、まずVision実現に必要な要素とステップを洗い出し、それぞれが利害関係者にどのような影響があるか？を整理しました。
(2) to C向けECサイトの場合
こちらはECサイトのロードマップを作成したときのものです。
このサイトはまだ立ち上げ初期で売上も微々たるものでした。
先程のSaaSと同じように領域が細かく分かれているわけでもなく、利害関係者を縦軸に並べても
売り手は「いっぱい売れて欲しい」
買い手は「安く良いものを買いたい」
という話に収束してしまうので、ECサイトの基本である 流入数 x 購入率(CVR) x 購入単価 なのでその3つの指標を縦に並べています。
また、赤枠でどの指標から順に改善していくか？を明示しています。
これは現状の数字から課題となっている領域を特定し、解決する順番を明示しているのですが、これによってクライアントとも共通認識ができ、今やっていることが何に繋がるか？の理解が進んだり、次は何をやるか？のアイディア出しがスムーズになりました。
まとめ
というわけでロードマップの作成についての私の現時点での考えは以上になります。
まとめると
ロードマップは事業と開発の時間軸を揃えるためのもの
ロードマップは組織全体をどの方向にどういう流れで進むか導く
ロードマップにOKRを紐付けるとストーリーと事業計画が可視化される
機能を並べたロードマップは情報が欠損しているので卒業しましょう
という感じでしょうか。
今回も長文になってしまいましたが、最後までお読みいただきありがとうございました。
感想・疑問・意見などなどお待ちしています。
この記事が気に入ったらサポートをしてみませんか？