前回までのあらすじ
この連載記事では、アイデアからの仮説生成を支援するAIサービス「Value Discovery」の開発経緯を踏まえて、プロダクトマネジメントにおける0→1でのプロダクト開発について紹介しています。
著者は当初、プロダクトマネジメントにおける実践的な学習リソースの必要性を仮説として立てましたが、これについて2年間と3回の反復にわたる仮説検証プロセスを通じて調査してきました。その結果、ユーザーが「仮説を言語化するのに苦労している」ことを発見し、経験に関わらず人間の入力には限界があることがわかってきました。その時、ChatGPTのリリースにより入力支援が劇的に改善することがわかり、この技術的な変革を利用したMVPを開発することに至りました（詳細は第2回を参照）。この記事では、Minimum Viable Product（MVP）を使用した仮説検証プロセスについて説明します。
要約
- MVPの目的は、作るべき製品の要件を明確にし、チームと協力して解像度を向上させて、製品のテストと改善を繰り返すこと。
- ジョブ理論などのフレームワークによって、ユーザーの行動をより深く理解し、製品の価値を定義することの重要性について。その結果、顧客のニーズに焦点を当てたプロダクトを作ることができるようになる。
- 製品の価値を視覚的に認識できるモックアップを共有することで、チームと協力してMVPの解像度を上げることができる。
MVPによる仮説検証プロセス（1）
さて「Generative AIを使って革新的なサービスを作るぞ！」とすぐに考える前に、まずは最小限の機能で価値を持つプロダクト「MVP（Minimum Viable Product）」はどういうものかを定義しましょう。プロトタイプと異なりMVPの目的（※1）は、最小限のリソースでプロダクトのアイデアを具現化し、市場での反応を検証することです。
（※1）プロトタイプとMVPの主な違いは、プロトタイプはアイデアを検証するためにユーザーのニーズを満たしているかを確認するために役立ちます。一方で、MVPは製品やサービスがユーザーにとって価値があるかどうか、ビジネスに利益をもたらすかどうかを確認するのに役立ちます（厳密な定義は文脈や状況によって異なります）。
MVPによる仮説検証プロセスでは、プロダクトマネージャーは以下のタスクを行います。本記事では1と2について紹介します。
1. MVPの要件を明確にし、モックアップを作る
2. チームと連携し解像度を高める
3. テストと改善を繰り返す
1．MVPの要件を明確にし、モックアップを作る
プロトタイプを通した3回の反復作業の中で、MVPの方向性として下記のWhy-Howは定義できていました。
- Why：プロダクトマネジメントを実践的に学びたい
- How：仮説検証を型に沿って実践する
- What：？？？
しかし、反復3でリリースした仮説検証管理ツールでは、「仮説をうまく言語化できない」という課題がありました。
そこで、改めてユーザーの行動をより分析するためにプロダクトの価値を定義するのに使ったのが「ジョブ理論」です。ジョブ理論では、ユーザーの状況、達成したい成果、障壁、代替手段を定義します。
さらに、それを図解したのが以下です。
この図解はのちに、Value Discovery内でも利用される図なのですが、もともとはCustomer Forces Canvas（※2）と呼ばれるもので、ユーザーが望んでいる状態（＝達成したい成果）に向かって、ユーザーがどのように行動するかを図で表したものです。
（※2）Customer Forces Canvas：顧客の動機、行動、意思決定プロセスを深く理解するために使用される図解。顧客が現在のソリューションから新しいソリューションに切り替える際に影響を与える要因を、プロダクトマネージャーやチームが発見し、分析するのに役立ちます。
このような図解はMVPを考えるにあたって、PRD（プロダクト要件定義書）と呼ばれるドキュメントやスライドの中に記載することで、自身の考えを整理したり、チームに共有し共通言語を作るのに役立ちます。
そして、PRDと合わせて作成するのが、プロダクトモックアップ（※3）です。
（※3）プロダクトモックアップとは、ウェブサイトやアプリケーションの見た目や機能を表現した詳細なデザインのことです。モックアップは、ワイヤーフレームよりも完成度が高く、実際のプロダクトに近い状態を示します。
プロダクトモックアップは、プロダクトの要件を視覚化された最小限の要素やデザインで表したもので、プロダクトマネージャーがデザイナーやエンジニアと共通理解を構築するのに利用されます。
あまりこだわったデザインをしてしまうと、デザイン面に意識が入ったりするので、多くはワイヤーフレーム（※4）と呼ばれる線図による設計図を作ったりします。
（※4）ワイヤーフレームとは、ウェブサイトやアプリケーションのデザインプロセスで使用される、画面の構造やレイアウトを示す簡易的な図面のことです。デザイン要素（色、フォント、画像など）をできるだけ含まず、主にコンテンツの配置、ナビゲーション、インタラクションを明確にすることを目的とします。
これらを踏まえて、これまでの仮説検証プロセスで明らかになってきた点から、MVPを定義する際に作成したPRDがこちらです（詳細をNotion上で確認）。
PRDには以下の要素が含まれています。
- 解決すべき課題（Jobs-to-be-done）
- Customer Quote（顧客の声）
- 現状の課題
- 考えうる解決策
- ユーザーストーリー
- 本MVPを通して明らかにしたいこと
- モックアップ
PRDの書き方は、プロダクトのフェーズ、業種業態、企業規模、目的に応じて異なります。しかし、ある程度、自分が得意なテンプレートがあると良いと思いますので、以下の記事を参考にしていただければと思います。
今回は、PM DAOというコミュニティの3～5名のチームで、プロダクトの初期のMVPとして、少人数で作るべきものを明確にすることを目的としたので、比較的簡潔かつビジネス要件を除いた内容を記載しました。皆さんが抱えているプロダクトによっては、より明確なビジネスや市場の分析、資金やスケジュールなどの計画も含まれる場合があります。
そして、このPRDで定義された内容を踏まえて、視覚的に作るべきものを示したのが、以下のモックアップです（Figma上で体験できます）。
Figmaで、デザイナー経験のない著者が30分ほどで作成したものになります。本来モックアップは、ワイヤーフレームのようなデザイン要素を極力排除したものを作成するのですが、今回はデザイナーがいないチームでしたので、ある程度のデザインを入れた上で、チームに共有し、フィードバックを求めました。
