事業開発者・プロダクトマネージャーが知っておくべきフレームワーク7選
プロダクトマネージャーという仕事はビジネス・デザイン・エンジニアすべてのスキルが求められる総合格闘技のような仕事です。その分、やることも多く忙しくなりがち。
しかし、再現性の高いプロセスというのは仕事が変わってもそのまま活用できます。その代表例がフレームワークです。
今回は世の中に数あるフレームワークのうち、プロダクトマネージャー・事業開発者が絶対知っておいた方が良いと判断したものを厳選してみました。
プロダクトマネージャー向けフレームワーク4選
1. Product Prioritization Framework
こちらはもうプロダクトマネージャーであれば無意識に考えていてほしいくらいシンプル、かつ大事なフレームワークです。
expected：期待値の大きさ（起こりやすさ）
high impact：影響の大きさ
この2つで4象限に機能を分けることでやる・やらないを判断します。
期待値大 × 影響大 ＝ なければならない機能
期待値小 × 影響大 ＝ やってみたら良い影響があるかもしれない機能
期待値小 × 影響小 ＝ あったら良いけど必須ではない機能
期待値大 × 影響小 ＝やらなくて良い機能
このようにそれが起きる可能性（期待値）と影響の大きさの掛け算で決めるというものです。特にプロダクトが未成熟なタイミングで取捨選択をする時に役立つでしょう。
2.THE PRODUCT VISION BOARD
プロダクトを何のために作るのか？という根本的な問は、事業が進むにつれてしばしば忘れられがちです。また、スタートアップがこれからプロダクトを作るときに「誰のニーズなのか？」が不明確なまま進んでしまうこともあるあるです。
そういうプロダクト開発のよくある失敗を防ぐために、チーム間でこれを作っておくととでプロダクトのビジョンと具体的なアクションにずれが起きにくくなります。
ターゲットグループ：どのマーケットのどのユーザーが使うのか？
ニーズ：そのプロダクトが解決する課題は何ですか？
プロダクト：そのプロダクトの特徴的な部分は？実現可能か？
ビジネスゴール：そのプロダクトはどのように会社に利益を生むのか？
この4つだけでも言語化し整理しておくことで、メンバーが増えていったとしても認識を揃えやすくなります。プロダクトマネージャーにとっては最も基本的で、最もシンプルで、かつ効果があるものなので1枚印刷して手元に置いておくと良いでしょう。
3. RICE
RICEはアメリカのプロダクトマネージャー間で有名なプロダクト開発の優先順位付けフレームワークです。こちらもインターコムが提唱しています。1で紹介したProduct Prioritization Frameworkに「工数」が要素として追加されたものです。
Reach：何人のユーザーに影響するか？
Impact：どれくらいの影響があるか？
Confidence：どれくらい確信があるか？（仮説が正しいと思っているか）
Effort：開発工数はどれくらいかかるか？
図にもありますが、要するにこういう風に優先順位を付けるべきということです。
良い影響（影響度×インパクト×確信） ÷ 工数 ＝ RICEスコア
同じ影響度であれば工数が小さいものを優先するべきですし、影響度は高くても工数が高いものは他の機能を先にやるべき、という判断もできるようになります。
特にプロダクトマネージャーが不在、もしくはジュニアクラスの企業だと、上司に言われるがままに機能開発をしてしまうのはあるあるなので、自分なりの優先順位ロジックを考えておくことでグッと仕事がしやすくなります。
4. 666ロードマップ
カスタマーサポートSaaSのZendeskでVP of Productを務めているポール・アダムス氏の提唱するフレームワークです。これは、プロダクトの開発サイクルを6で区切ることで効果的なプロダクト開発ができるようになると言っています。
次の6週間：直近の改善案をやる
次の6ヶ月：将来から逆算して重要なことをやる
次の6年 ：将来の大きな展望を描く
このフレームワークの良いところは「6」という数字で区切ることが絶妙な塩梅である点です。プロダクト開発でよくあるのが目の前のタスクばっかりやってしまう、またはニーズがないのに大きな機能開発をしてしまうことです。
しかし、6週間であれば、目先すぎることばかりやっていると駄目だと気付くことができますし、6ヶ月であればある程度大きな機能開発もやれるので何をするべきかもう少し俯瞰した目線でプロダクトを考えられます。
目先すぎず先のことすぎないちょうどいいバランスを取るために役立つフレームワークです。
事業開発者向けフレームワーク3選
1. リーンキャンバス
スタートアップ界隈でのバイブルである「リーン・スタートアップ」で紹介されているフレームワークです。プロダクトを作るとき、考えておくべき要素を一覧にして整理したものです。
課題：ターゲットが感じている解決すべき課題
顧客セグメント：どんな人がターゲットなのか
独自の価値提案(UVP)：どうなれば独自の価値を感じてもらえるか
ソリューション：どうやって課題を解決するのか
チャネル：どうターゲットにアプローチするのか
収益の流れ：どのように収益化されるのか
コスト構造：コスト（顧客獲得コストや流通、人件費など）はどれくらいかかるのか
主要指標：どの数値を達成すれば成功と言えるのか
圧倒的な優位性：他者にない優位性とは何か
これらの項目が具体的であればあるほどプロダクトの成功確率が上がるので、事業を作る人であれば1回は作っておきたいフレームワークです。
6. Spotify MVP
こちらは6でも書いたMVP（Minimum Viable Product）を作る時によくある誤解がよく分かります。フレームワークというよりは図解ですが、事業開発でMVPを作るときによくある誤解なので知っておいて損はありません。
MVPとは要するに
◯ スケボー → 自転車 →車と進化する
✕ 車をタイヤから作る
ではないということです。MVPは「必要最低限の価値があると検証できるプロダクト」のことですが、この「必要最低限」という言葉が誤解されやすいのでしょう。
例えば乗り物でいえば、歩きより早く移動したいというニーズを解決するとき、まず最もお手軽なのはスケボーです。しかし、スケボーは乗るのが難しく怪我もしやすい。そこで次に来るのが自転車です。スケボーより早く安全ですが、遠くまで行くのは疲れます。そこから次に来るのが車で、ガソリンは必須ですがより遠くに安全に、早く移動することができます。
このように、MVPとは価値が進化していくための最初の一歩がMVPであり、最初から車を作ることではないと理解しやすくなるでしょう。
7. Lean Product Playbook
こちらはプロダクトを新しく作るとき、MVP（Minimum Valuable Product）をどう作るか、またPMF（Product Market Fit）をするタイミングがどこか？について分かりやすくなるフレームワークです。
ターゲットユーザーの選定
解決されてない課題・ニーズ
独自の価値
MVPの機能
MVPを作る
ユーザーにMVPを使ってもらう
この6つに分けて考えます。いわゆるビジネスとして上手くいくPMFをしたという状態は、ここで言う2を満たせると判断した時だと言えます。そこから、自分たちだけが提供できる独自の価値を考え、それをMVPとして提供することがリーン・スタートアップのベーシックかつ重要な動き方です。
おわりに：プロダクトマネージャーは総合格闘技である
自分がプロダクトマネージャーの仕事をしていると、いったいどこまでスキルを上げるべきなのだろう？と思うことがあります。しかしどこまでいってもITの世界には知らないことがありますし、知っていることもすぐに形骸化します。
そういう意味では、最も求められる資質は地頭よりも「知的好奇心」なのかもしれませんね。まさに総合格闘技、パンチもキックも寝技もありです。だからこそプロダクトマネージャーという仕事は楽しい、そう思います。みなさんも良い仕事ができるよう頑張ってください！
記事がよかったらTwitterリプライ・ツイートしていただけると嬉しいです。