どうも、大曲です。

赤ちゃんが生まれ、沐浴やおむつ替えをマスターしました！
赤ちゃんを抱っこしながら、読書をするための足技も習得出来ました！
しかし、赤ちゃんが「魔の3週目」に入り泣き止まないため対応に日々困っております。

書く内容

開発のロードマップ決めや優先度付けを効率良くするために工夫している図があるのでそれを紹介します。

紹介する図は以下の二つ。

ロジックモデル（大学や行政で利用されることが多い図）
- 事業のビジョンと現場の仮説検証との関係性を表す
優先度MAP（いくつかの要素を組み合わせて自作した図）
- 仮説検証の状態と事業の優位性への影響を表す

前提

自分はプロダクトマネージャー（以下PMとする）として活動しております。

チームでは四半期毎にリリーストレインを策定しています。これがある種のロードマップとしての役割を果たしています。今回はそのリリーストレインを決めるために利用している二つの図を紹介します。リリーストレインの話はこちらにあります。

blog.engineer.adways.net

プロダクト開発サイクルの図は以下の通りです。対象となる図は黄色背景の部分です。
今回は、スクラム部分ではなくチーム構成・優先度で利用するため事業戦略やチーム編成に近しい位置にあることがわかると思います。
（いつか、このプロダクト開発サイクルの変化もブログに書ければいいなと思っています）

ロジックモデル

事業のビジョンと現場の仮説検証との関係性を表すために利用しています。

ロジックモデルの紹介

対事業責任者に対しては、PMがビジョン達成に向けた重視するアウトカムの優先度や中長期のフェーズの認識合わせを行う
対現場のメンバー（営業・開発）に対して、PMが作業しているプロジェクトや仮説検証の機能が事業にとってどんな価値を求められているのかを説明する

ロジックモデル自体の解説はこちらのページが参考になりますので読んでみてください。

大学や行政などで頻繁に使われていることが多いイメージがあります。最近、「ロジックモデル」でググってみたら、経済産業省が令和３年度ロジックモデルを公表しており、DX投資や5G事業に対してロジックモデルを活用しているようです。

自社で変更・工夫した部分

ロジックモデルをそのまま利用せずに使いやすようにいくつか工夫をしています。

その前にロジックモデルを構成する要素となる用語を載せておきます。

ロジックモデルの用語について

インプット　 ：事業活動（諸活動）等を行うために使う資源（ヒト・モノ・カネ）
アウトプット ：事業活動によって変化・効果を生み出すために提供するモノ・サービス
活動　　　　 ：モノ・サービスを提供するために行う諸活動
アウトカム　 ：事業や組織が生み出すことを目的としている変化・効果

出典元：ロジックモデル解説

インプットは利用しない

ヒト・モノ・カネを明確にする部分であり、最初は決めていこうとしていたのですが仮説検証の範囲（どのプロジェクトを対象にするか？開発メンバーはどんなロールが必要か？）では粒度が細かくなりがちになりました。そのため、あまり費用対効果を感じられなかったので止めました。ただし、事業として大きな挑戦となる内容だったり、新しい領域の開拓などマッチしそうなケースはありそうですが、全てのケースで明確にする必要はないなと感じました。（あくまで、事業責任者やPdMが意識すべき部分ではないということであり現場メンバーは仮説検証に必要なヒト・モノ・カネは考えてもらってます）

アウトプットはPJ名だったり、指標を明記する

アウトプットはプロダクト開発においては機能などの成果物がメインと捉えていました。しかし、決めていくうちに課題や達成したい指標などを書くスタイルに落ち着きました。

結果的に現在は2パターンあります。運用していくうちにうまい形が見つかればいいなと思っています。

OKR形式
- KRに行動指標などが含まれるパターンもある
「プロジェクト名 + 指標」形式
- 指標はグロースサイクルなど事業戦略上で重視している指標

結果的にアウトプットがアウトカムに近しい形になったのは、ロードマップに機能を書くべからずでも言及されているようにHOWとなる機能が前面にあるのは違うなということになりました。

アウトカムは事業それぞれで重視するもの

アウトカムは短期、中期、長期とありますが、それぞれは事業とで形式が違います。

長期になるにつれて抽象度が上がること以外はアウトカムの形は以下のようにそれぞれで違ったりしています。これは事業というより事業戦略の成果物次第でもあるため、ある程度自由でいいのかなと思います。

事業の課題一覧（優先度順）
事業の強みとなるKSF
事業がありたい価値・状態

実際の図

ある事業で利用している図です。

実際の内容は明記できないので全部「XXXX」と書いてありますが、イメージはしやすいと思います。
アウトカムは工夫した点にも書いた通り、この図はKSF(Key Success Factor)ですが、他の事業では違ったりしています。

使ってみてどうだったか

良い点

繋がりが見えるのは非常に良い
- アウトカムの短中長期を要素ごとにどれが関係するかを繋げると何がどれに影響を及ぼすのかを明確にできるためPMとしてどこにリソースを投入すべきかはっきりしやすくなった
アウトカムで競合分析や課題分析した結果を活用できる
- 競合分析などを通した成果物は事業戦略を考え直すときに更新して、そのままが多かった
  別にこれが悪いわけではないと思うので問題ないのが、実際のプロジェクトとの関係性を上手く表せなかったことがロジックモデルに組み込めるので活用できている感じがもの凄くする（笑）
事業だけでなく、組織のミッションとしても使えそう
- 事業貢献を目的としている開発組織であるため、自社事業全体や開発組織という観点でもロジックモデルが活用できそう
- 新しい組織のビジョンを満たすために必要なインプットは何であるべきか短期のアウトカムは何を重視すべきか腕の見せ所な気がしてきた

改善したい点

インプットをもう一度挑戦したい
- 細かな粒度（開発メンバー..etc）は無視して、事業としての必要な投資は整理したいので上手く活用したい
アウトカムが変わるタイミングがまだ無い
- 策定して半年以上経つ（アウトプットは変化している）が、まだアウトカムは更新されていないため、変化をうまく反映できるかはこれからの状態

参考資料

優先度MAP

仮説検証の状態と事業の優位性への影響を表すために利用しています。

優先度MAPの紹介

バブルチャートみたいな図を自作しました。
これを利用することで価値を見極めるフェーズなのか？規模を拡大させるフェーズなのか？で状況が異なるため、それらを明記することが出来ました。

Y軸
- 事業の優位性にあたるものに該当するのかを表す優位性の判断はPMの感覚に頼りっきりである
- 優位性が低い＝悪いというわけではない
  業務効率化などは優位性は高くはないが、重要なプロジェクトである
  あくまで事業としてバランス（新規価値と業務効率）が取れているかどうかが大事
X軸
- プロジェクトのフェーズを表す
  MVPに止まらず、どう成長させていきたいか
- 事業計画「シード・スプラウト・フラワー」をベースに分類分けをしている
  デュアルトラックアジャイルって結局何なの？での記事内のディスカバーとデリバリーを細かく分けているようなイメージと近しい
- どの段階にいるのかを明確化することで、不確実性の高さを表す
丸の大きさ
- 大きさは規模を表す
- 現時点での成長幅(必ず獲得できる顧客、営業活動での見込みが高い or 自分たちの裁量で展開できる..etc)
矢印の長さ
- 四半期の間でどこまでの状態を目指すかを表す
- 矢印が長いほど、不確実性が高く失敗するリスクが高いことを表すプロジェクトによっては一気にデフォルト機能化をゴールにするものもあるが、仮説検証を通した機能などは見込みが立ちづらいのが現実（機能の規模感で可能な場合ももちろんある）

実際の図

ロジックモデルで全体を整理して、優先度MAPでプロダクト開発での優先度付けをしています。調査や模索メイン（薄い色の丸）と開発メイン（濃い色の丸）で分けて優先度をつけており、これをベースにチーム編成（開発メンバーはどうするか？UI/UXメンバーとエンジニアを同じチームにすべきか）や進捗状況に合わせたアサインの変更などはこの優先度に沿って動いています。

使ってみてどうだったか

良い点

事業ごとで仮説検証の状況が把握しやすい
- X軸が右にずれ込まなければ事業全体に影響するような成果にはならない
  そのため、仮説検証を通して事業貢献する規模に成長しているのか？似た仮説ばかりに手をつけて価値を向上できていないのではないか？などが更新するたびに把握できる
- 新規価値かつデフォルト機能化（右上部分）の状態の仮説検証を多く増やさなければ成果が小さいところでずっと仮説検証を行なっており事業にインパクトを与えられていないと意識するようになった
新規価値と効率化・技術改善などのバランスを意識しやすい
- Y軸で事業にとっての優位性と置いているため、上が新規価値で下が効率化や技術改善になりがちでプロダクト開発としてどちらも大事であり最終的にバランスが重要になるのでそれを可視化出来るのは良い

改善したい点

プロジェクト粒度の扱い（丸の部分）がまだ適当な状態
- デフォルト機能化のフェーズでありながら、実際は仮説模索や新ロジックのMVP検証だったりする
  立ち位置として規模拡大のためのロジック模索でもあるため破綻はしてないがスッキリはしていない

まとめ

ロジックモデルで事業とのつながりを示し、優先度MAPで仮説検証の状態を表すことで
チーム構成や優先度判断での議論が楽になりました。PMとしては事業貢献のためのバランス調整（新規価値と効率化など）で利用できたり、事業ごとの価値模索の状況（全然、デフォルト機能化まで成長する仮説検証が出来ていない...etc）などの整理がしやすくなりました。

事業戦略と現場開発との間にはまだまだ改善の余地がたくさんあるので色々な工夫をこれからも実施できればいいなと思います。次はPRDを上手く絡められたらいいなと考えています。