Outcome Oriented Roadmapのススメ

Wataru Kitamura
Product Run
Published in
Feb 8, 2023

“プロダクト”ではなく、”プロダクトによって生み出す成果”に着目しよう!

こんにちは、Tanzu Labs のプロダクトマネージャーのWataruです。今回はLabsのプロダクトマネージャーが使っている「ロードマップ」について紹介しようと思います!

みなさんプロダクトの「ロードマップ」と聞いてどんなものを思い浮かべますか?

<よくあるロードマップ>
・機能または機能群の羅列
・フェーズゲートやリリースなどの「日付」が強調されている
・プロダクト外の事情や声が採用されている(例:このリリース日は必達!etc)
・年単位の長い期間で書かれている

こんな感じでしょうか?見た目で言うと、ウォーターフォール開発でよくあるWBSが簡略化されたような見た目かなと思います。

要件定義→基本設計→詳細設計→・・的なやつですね

僕も以前SIerで働いていた時代の開発プロジェクトで、名前こそ「ロードマップ」ではないものの、機能や時間を中心にした線をよく引いていましたが、今日ご紹介したいロードマップは、これらとは異なるものです。

※何が良い、という話ではなくTanzu Labsでは何に着目してロードマップをどう使っているか(使えると良いと思っているか)というお話になります。

前提

大前提として、我々Tanzu LabsはLean StartupとExtreme Programmingを掛け合わせたLean XPという手法を用いて、学びながら変化に対応していくアジャイルな状態でプロダクトを作っていくことを信条としています。

アジャイルな状態ってこういうことだと考えてます

従って、未来を正確に予想することはできないし、完璧な計画なんて立てられない!と思っています。更に言うと、新たなプロダクトを0から作る場合、そもそも顧客が何を望みに、何にお金や時間を使うかも正確に理解できていない。という前提に立っています。

自信もないし、何も分かっていないじゃん!という風に聞こえるかもしれませんが、その通りです。(笑)

でもロードマップって「作るもの」や「日程」といった未来の話のエッセンスを感じますよね??

何も分かっていない我々は何のためにどんなロードマップを作るんでしょうか?

Tanzu Labsのロードマップ 〜考え方編〜

ここから、我々Labsのロードマップについて紹介していきます。
そもそもLabsのロードマップはどういう目的でどう作られるのか?
大事なポイントは以下の3つです。

  1. ビジョンに向かうための方向性を示す
  2. 不確実性と変化を想定し、学習と対応を最適化する
  3. OutputよりOutcomeを大事にする

ちょっと抽象的だと思うので、1つずつ説明していきます。

1. ビジョンに向かうための方向性を示す

プロダクトはビジョン実現の手段

プロダクトを作る際は、必ずそのプロダクトのビジョンを立てます。ビジョンとは、「プロダクトがあることによって実現したい未来/世界観」です。

それに対してロードマップはビジョンをどう実現するかの戦略といった位置付けです。各ステップでどんな成果(Outcome)を達成すればビジョンに近づいていくのか?そういったことをチーム全員で共通理解を作っていくためのツールと位置付けています。

2. 不確実性と変化を想定し、学習と対応を最適化する

Build-Measure-LearnはLabsのメンバーの合言葉

先ほどLabsの考え方を少し紹介したところでも触れましたが、我々は新しいことを学習し、その学びを元に構築するものを適応させていく、ということを開発手法のベースにしています。つまり、新しいことを学ぶことによってロードマップも頻繁に変化し得るということになります。

ロードマップというと「この計画でいきます!コミットします!」という雰囲気があるかもしれませんが、我々の文脈だと「今のところ知っていることをベースにすると、こういうステップでこういう成果を出していくと良いと思ってます」くらいの表現になるかと思います。

3. OutputよりOutcomeを大事にする

Output vs Outcome

個人的にはここが一番ポイントなんですが(この記事のタイトルもここからきてます)、LabsのロードマップはOutput(成果物)よりOutcome(成果)を大事にします。分かりにくいと思うので、それぞれのワードについて解説します。

【Output】≒成果物
プロダクト自体や機能、ドキュメントなど何かしら活動によって生み出される物のこと。

【Outcome】≒成果
何かしらの活動によってもたらされる結果のこと。プロダクトを作ることでユーザやビジネスに起きる変化のこと。

OutputよりOutcomeを大事にするということは、極論を言うと、作る機能はそこまで重要ではないということです。それよりも、その機能やプロダクトがあることでユーザやビジネスにどういった変化があるのか?変化をもたらしたいのか?ということを重要視しているということです。

Tanzu Labsのロードマップ 〜実践編〜

上記で説明した考え方に則ったロードマップってどういうもの?
ここから少しサンプルを紹介していこうと思います。

例えばこんな感じ

形は非常にシンプルです。

  • 横軸:時間
    最初に紹介したようなよくあるロードマップと同じく、横軸は「時間軸」になりますが、厳密な日付は特に記載しません。Labsではよく、「現在」「その次」「未来」の3つのフェーズくらいで用意します。
  • 縦軸:Business Outcome
    ビジネス上達成したい成果を書きます。このプロダクトがあることによって、収益が上がる、評判が良くなる、などビジネス上どんないいことがあるかを記載します。
  • 縦軸②:Metrics (for business outcome)
    Outcomeの達成/未達成を示す指標としてSuccess Metrics(成功指標)を設定します。なるべく定量的にしたいですが、定性的なことでも達成を図る術があれば良いと思います。
  • 縦軸③:User Outcome
    このプロダクトを手にしたユーザがどうなっていて欲しいかを書きます。より簡単にxx作業できる、より早く◯◯を予約できる、などユーザーが嬉しくなるポイントです。
  • 縦軸④:Metrics (for user outcome)
    縦軸②と同じく、指標を設定します。1つのOutcomeの達成を測るために複数の指標を設けても問題ないです。
  • オプション
    上記に書いたこと以外でも、Outcomeを達成するための機能(上のSampleには入れています)や、課題、仮説、それらに至った学びなど、究極的には何を書いても間違いということはありません。ただ、何を目指すのかの共通理解を進めるためにも、人が読む気になる量にとどめておきたい、と個人的には思います。

余談になりますが、社内で使う業務システムなどの場合、Business OutcomeとUser Outcomeが近づいてきてしまう(or言い換えただけ)事象が起きるかもしれません。

例)
Business Outcome:業務Aにかかるコストを小さくする。
User Outcome:業務Aを今までより簡単に実施できる。

このような場合、無理に頭を悩ませなくてもいいかなと思います。
望むべき成果とそれをどう測って評価するか、の共通理解ができることが大事です。

Sample

簡単ですが、架空の「オンラインバンキングアプリ」の例を書いてみます。

サンプルはMiro上で作ってみましたが、きれいなドキュメントでなくてもこんな感じで十分ですし、メンバーなどからもらったFeedbackやStakeholderなどからの意見を貼っておいて、リサーチなどで新たなことを学んだら適宜updateしていければOKです。

また、未来の部分は一部空欄になっていますが、先の話になってくると色々と不確実性が増してきたり分からないことも多いので、未来のことは書けることだけ(例えばMetricsは一旦空欄、とか)書いておく、ということも1つの手かなと思います。

ロードマップによるOutcome

さて、もしみなさんが作っているプロダクトのロードマップを我々のロードマップのような考えに則って作ってみたとして、それを上役の方や関係者に共有した場合、どんなことが起こりそうですか?

もしかしたら、

「いや、実現したいことはこういうことじゃない」
「僕は/私はこう思ってました」
「こういう数字もチェックしないと効果が分からないのでは?」
・・・

みたいな様々な反応が上からも横からもあるかもしれません。
(なんならロードマップの内容がめちゃめちゃ叩かれてしまうかもしれません・・。実際によくあります。)

もしそうなったら・・心の中で「うまくいってるぞ」と思ってください。

「実は、この状態でうまくいってるのよ!」「えーそうなのー!」

何を言ってるんだと思うかもしれませんが、この状態こそ、ロードマップを作ることで達成したいOutcomeです。

我々がロードマップを作ることで達成したいOutcome/成果は、

プロダクトを作ることで何が/誰がどういう状態になるのか、という視座で関係者が議論できる状態にする

ということです。その状態になったのならば、議論がなされて中身が変わっていっても全く問題なく、むしろその視点で、まず達成したいことや優先順位、それをどう測るかの話がしていければ非常に良い状態だと思います。そういった活動を通して、関係者全員でどんなビジョンをどう実現していくのかという共通理解を持てることがとても重要です。

まとめ

さて、Labs式ロードマップ、いかがでしたか?必ずしも、こういうロードマップを作ればOK、という話ではなかったと思います。そこが面白いところであり難しいところです。

みなさんが作っているプロダクトはどんな成果、価値をビジネスやユーザにもたらしていますか/もたらそうとしていますか?

きっとこういう価値だと思うけど、チームのみんなや関係者の人たちはどう思っているのかなぁ?と思った方、ぜひOutcome oriented なロードマップを作ってみんなと対話する機会を作ってみてください!

--

--