「作るべきプロダクト」の探求プロセス概略

Transcript

1. プロダクト企画 「作るべきもの」を見つける探求のプロセス by takosuke
2. ＊この資料は、新規プロダクト立ち上げの取り組みの中でも、特にデジタルベースのライトなプロダクト（ディープテックではないデジタルプロ ダクト）を企画する部分に焦点をあて、その位置づけ、全体像、すべきことの説明を試みたものです。 ＊プロダクトビジネスの新規事業立ち上げや、既存プロダクトのメジャーアップデートなどに携わってきた経験を踏まえ、どのような順番で何 をすべきか、ごく一般的かつ最低限の手順を整理して、次に同様のことをする際に自分のガイドとすることを第一に意図して作成しています。 ＊スタートアップなど、自身の会社を起業するという経験はしていないため、そのような動きをとる際に必要になると思われるもの（たとえば資 金調達や創業者菅の株式の配分、資本政策、会社設立手続き、採用など）については記載していません。 ＊以上の前提がありますので、この資料に説明されていないことは数多くありますし、記載しているものの中にも間違いが多くあるはずです。 ここに記載している通りのことを実行するだけでは、事業立ち上げを成功に導くうえではまったく十分ではないということをお含みおきくださ い。 ＊自分自身のためにも、この資料は改善しつづけていきたいので、もし間違いや足りないこと、改善の必要があること、質問などがあればこ ちらからご連絡ください。 2 この資料について
3. 1. プロダクト企画の位置づけ 2. プロダクト企画の流れ 3. 課題仮説検証 4. ソリューション仮説検証 5. MVP検証 6. 参考資料 3 Agenda
4. 1. 「企画」の位置づけ 4
5. 新規事業のうち成功するのは10%と言われていますが、失敗する理由の多くは、「プロダクトが悪いから」で はなく「マーケットのニーズがないものを作ったから」であると言われています。 よくある失敗 出典：「人間と話す : Lean Customer Development (Lean Startup Update 2015)」 by Takaaki Umada https://www.slideshare.net/takaumada/lean-customer-development-lean-startup-update-2015 5
6. ニーズ有無を検証せずに、「まず MVPを作って、反応を見ながら修正しよう」とアイディアをプロダクト化して しまうと、学習速度が遅くなり失敗の確率が高まります。 「まずMVPを作る」 ≠ “Start Small, Fail Fast” 要件定義＆見積 開発＆リリース 要件修正＆再見積 追加開発＆リリース 要件修正＆再見積 数か月 数か月 数か月 数か月 数か月 数百～数千万円 数百～数千万円 ユーザーの反応 ユーザーの反応 ✔ 打った施策が正しかったかどうかを検証するためのサイクルが半年～1年に一度になってしまう。 ✔ うまくいっていないのはニーズがないからなのか、プロダクトが悪いからなのか、販売・マーケ戦略が悪いからなのか？分 析すべきポイントが複雑になり、十分なデータを集めるにも時間を要する。 ✔ 一度リリースすると、技術的負債や販売・マーケ・オペレーション等の費用や手間も増え、プロジェクトリーダーが考慮・管理 すべき事項が多くなるので、迅速な軌道修正がしづらくなる。 時間切れ、予算の枯渇、士気・モラル低下で停滞などの理由により、投資回収前に撤退 6
7. 「マーケットのニーズがないプロダクトを作る」という失敗を避けるため 、実際にモノを作るための大きな投 資をする前に、正しい問いと正しい答えのセットを見つけ出しておく必要があります。 プロダクト開発の考え方 Business Viability 販売、マーケやオペレー ションまで含めて利益が 出せる事業か？ Usability ユーザーにとってわかり やすく使いやすいものに なっているか？ Feasibility リソース、技術、スケ ジュールの観点から実現 可能か？ Value 誰の、どんな課題を解決するのか？ それはすぐに解決したいクリティカルな課題か？ なぜ他ならぬこのソリューションを選ぶのか？ 正しい問いを設定し、 正しい答えを見出す 正しい解を 正しく実現する 7
8. プロダクト企画とは、仮説検証サイクルを通じて得られるエビデンスに基づいて、価値、事業性、有用性、実 現可能性を実現できるサービス／プロダクトを定義・設計することであり、プロダクト開発の着手前に実施さ れる必要があります。 「問い」と「答え」を探索する 「正しい問い」を見つける 誰のどんな課題を解決するのか？ 「正しい答え」を見つける どんな解決方法が有効か？ 正しくつくる・届ける どんな仕様のものをどうつくるか？ 出典：https://nortal.com/us/insights-news/ux-showcase/eesti-ee/ プロダクト企画 8
9. 2. プロダクト企画の流れ 9
10. 企画段階では、「正しい問いと答えを見つける」ために、各フェーズごとに検証の目標と基準を設定し、仮説 検証サイクルを素早く繰り返します。 プロダクト企画の流れ PJ立ち上げ 顧客・課題検証 ソリューション検証 MVP検証 目標 事業化を検討するプロダクト仮説と 検証計画ができている状態。 ターゲット顧客と、彼らの「尻に火が ついている課題」を特定できている 状態。 顧客にとって価値のあるソリュー ションを特定できている状態。 事業性のあるプロダクトと事業計画 が定義できている状態。 アクティ ビティ例 ✔ チーム組成 ✔ 企画立案 ✔ 情報収集 ✔ データ分析 ✔ 企画書 ✔ 初期資金／予算調達 ✔ ペルソナ ✔ ジャーニーマップ ✔ インタビュー ✔ 参与観察 ✔ 定量調査 ✔ アイディエーション ✔ リーンキャンバス ✔ 低忠実度プロトタイプ ✔ インタビュー ✔ 市場・競合調査 ✔ 収益性分析 ✔ サービスブループリント ✔ MVPプロトタイプ作成・提供 （UI/UX検証、技術検証） ✔ プロダクトロードマップ ✔ GTM戦略 ✔ オペレーション計画 ✔ プロダクト要件定義 ✔ 事業計画 ✔ 開発資金／予算調達 ヒット率が低い。従って、学習の速度と試行回数が重要。 10
11. 以下のような項目の達成状況を確認することで、プロジェクトがいまどのような状況にあり、次に何をすべき かを判断することができます。 ステータス判断 ✔ ターゲット顧客の業務フローを詳細に記述できる。 ✔ 何が課題で、それがなぜ発生していて、なぜ未解決なのか明確である。 ✔ お金や労力を費やしてその課題を解決しようとしている初期顧客が特定できている。 課題仮説 検証 ✔ 想定している価格での購入に前向きな関心を示す顧客が複数名いる。 ✔ ソリューションの価値にクリティカルな機能、サービスが特定されている。 ✔ 想定している価格とサービス内容で、利益が上げられる目途が立っている。 すべてYES いずれかが NO ソリューション仮説 検証 いずれかが NO ✔ サービスを今すぐに利用したいという顧客が複数名いる。 ✔ プロダクトのデザイン面、技術面の有効性、実現性が検証できている。 ✔ GTM計画、オペレーション計画ができている。 すべてYES MVP 検証 いずれかが NO すべてYES 本番プロダクト開発 & 立ち上げ準備 11
12. 3. 課題仮説検証 12
13. このフェーズでは、プロダクトが誰にどのような価値を届けるのかを明確にするため、顧客がどのような人 か、またその人にとってお金を払ってでも解決したい喫緊かつ重要な課題とは何かを明らかにします。 課題仮説検証フェーズ 目標 ターゲット顧客と、彼らの「尻に火がついている課題」を特定できている状態。 基準 ✔ ターゲット顧客の業務フローを詳細に記述できる。 ✔ 何が課題で、それがなぜ発生していて、なぜ未解決なのか明確である。 ✔ お金や労力を費やしてその課題を解決しようとしている初期顧客が特定できている。 ✔ ペルソナ（仮説） ✔ ジャーニーマップ（仮説） ✔ インタビュー ✔ 参与観察 ✔ 定量調査 ✔ 検証済ジャーニーマップ ✔ 検証済ペルソナ ✔ 潜在顧客リスト 13 Input Process Output
14. 考慮する項目例： プロダクトがどのような人の課題を解決するか、プロジェクト内での認識を共有するために、ペルソナを作成 します。（toBビジネスの場合は企業と個人の 2種類） ペルソナ 留意点： • サービスの拡大後に顧客になる人ではなく、リリース直後に、 最初の顧客になり そうな人（企業）について考えます。理想のイメージを当てはめないように気を付 けましょう。 • 想定する課題の保有状況に影響する「軸」を定めてセグメントを切り分け、左記 にあげたような項目を セグメントごとに整理していきます。 • toBビジネスの個人ペルソナに関しては、プロジェクトで解決しようとする課題に ついて該当企業の中で 最も強く課題意識を持っていて、ソリューションを必死に 探していると思われる人 が最重要です。しかし、実際にサービスを使用する人が 異なる場合がよくあるため、その場合はそれぞれのペルソナを作成するのが望 ましいです。 • Miroなどを使ってプロジェクトメンバーで議論しながら作ることで、 誰のため、何 のためのプロジェクトなのか共通認識を作る ことが重要です。 企業ペルソナ ✔ 企業名 ✔ 業種 ✔ 商材の特徴 ✔ 売上規模 ✔ 従業員数 ✔ 社風 ✔ 業界における立ち位置 ✔ 将来の展望、戦略 個人ペルソナ ✔ 氏名 ✔ 年齢 ✔ 担当部署 ✔ 役職 ✔ 経歴 ✔ 決裁権の有無、決裁枠 ✔ 担当業務 ✔ 仕事上の目標 ✔ 自身や部署が抱える課題 参照：https://fintan.jp/page/6871/ 14
15. ジャーニーマップの例： 解決する課題についてチーム内の理解を合わせて深掘りするため、顧客がどのような活動・業務を行って いて、課題がどこでどのようにして発生しているかを整理します。 ジャーニーマップ 参照：https://drm.ricoh.jp/lab/glossary/g00053.html 留意点： • 初めに、どのペルソナのジャーニーマップなのか を明示します。 • 次に、顧客が実現したい目標を設定した上で、目標を実現するために行ってい る活動や業務を思いつく限りリストアップします。 • リストアップした業務・活動を時系列に並べなおし、 同じフェーズに入るものをま とめます。フェーズ分けができたら、フェーズの中で時系列が先になる業務・活 動から順番に、上から下へ並べます。 • 業務・活動とフェーズが整理できたら、それぞれのフェーズで 顧客がどのような ことを考えているか、どのような気持ちになっているか を整理します。 • 可能なら、それぞれのフェーズで どのようなサービスやツールを使用しているか も挙げていきます。 • 顧客が最も解決したいと考えている課題を特定します。 • ジャーニーマップには様々な形態が存在しますが、どの形がよいのか以上に、 その中身の方が重要です。できる限り早く、中身を作ることに集中しましょう！ 15
16. インタビュイー（インタビュー相手）のリクルーティングは時に手間と時間がかかりますが、インタビューの有 効性を大きく左右するため、慎重かつ迅速に行いましょう。 インタビュイーのリクルーティング 主なリクルーティング方法： 既存の つながり ✔ 既存顧客、自社主催の関連イベント参加者、メルマガ登録者など。 ✔ 知り合い、知り合いの知り合いなど。 クラウド ソーシング ✔ 1件当たり数千円～数万円 / Hr.費用が発生します。 ✔ ビザスクLite、ランサーズ、クラウドワークス、 Uniiリサーチなど ✔ 自分で募集要項を作成・掲載して日程調整や検収・決済も行います。ア カウント作成＆クレジットカード登録で利用可能です。 ✔ ビザスクはtoB向け、その他はどちらかというと toC向け。Uniiリサーチ はユーザーリサーチインタビューに特化。 ✔ ビザスクInterview ✔ ビザスクの担当者に条件を伝えると、インタビュイーをピックアップして 日程調整までしてもらえます。法人契約が必要です。 オンライン サーベイ ✔ 1件当たり数十万円～百万円程度の費用が発生します。 ✔ クロスマーケティング、マクロミル、楽天リサーチなど ✔ 指定した条件に当てはまるモニターに対してアンケートを配信し、回答 内容を見て直接アンケートを打診します。 留意点： • まずは5人程度を目標にインタビュイーをリクルーティングし ましょう。 • インタビューをお願いする前に、相手が 想定したセグメントに 当てはまるかどうか厳密に評価する必要があります 。対象 者の条件が変わることで、検証の前提が変わってしまいま す。 • ペルソナやジャーニーマップを基に、想定する課題仮説を 持っている人の条件を洗い出しておき、必要に応じて質問票 に回答いただくなどして、インタビュー相手として適切かどう かを評価するための情報を集めましょう。 • インタビュー時だけでなく、募集時にもインタビューの趣旨・ 目的やデータの利用・保管方法については十分に説明しま しょう。 16
17. 基本のインタビュー項目の例： 想定した課題仮説が、顧客にとって「お金を払ってでも解決したい課題」かどうか、顧客の声を通じて検証 し、取り組む意義や構築すべき解決策の解像度を高めます。 課題仮説検証（インタビュー） ペルソナを検証するための質問 ✔ あなたの会社やあなたの業務内容について教えてください。 ✔ あなたの業務で、中長期的に実現・達成を期待されている目標は何で すか？ ✔ あなたが　　[目標]　　するときの一連の流れを、一番はじめから時系列 で説明してください。 課題仮説を検証するための質問 ✔ あなたが＿＿＿＿＿＿するときの、一番の難題は何ですか？ ✔ その難題には、どれぐらいの頻度で直面しますか？ ✔ その難題に最後に直面したのはいつで、どのような順番でどのようなこ とが起きたか教えてください。 ✔ それが困難だった理由は何ですか？ ✔ その難題を解決するために工夫したことや使ったソリューションがあれ ば、どのようなものか教えてください。 ✔ これまで試したソリューションの中で気に入らなかった点は何ですか？ 留意点： • このインタビューは、顧客にとって今すぐに解決したい課題が何なのかを理解す るための場です。また、アイディアの話を聞かされると、多くの人はそれに影響さ れて、本当に考えていることとは別の話をしてしまいます。自分のアイディアにつ いて話すのではなく、徹底的に聞く側に回り、顧客の生活や仕事、世界の見え 方についての理解を深めましょう。 • NG例：「～～～～なプロダクトを作ろうと思っています。どう思います か？」 • 仮定の話、未来の話にはあまり意味がありません。具体的な事実や行動と、そ の理由や経緯を聞くようにしましょう。 • NG例：「XXXXな状況になったらどうしますか？」 • 顧客に必要な機能を聞いても、その答えは仮定に過ぎないのでやめましょう。多 くの場合、顧客は自分が本当に必要とするものが何なのかを知りません。それ を考えるのはあなたの仕事です。 • NG例：「この問題を解決するプロダクトには、どのような機能が必要だ と思いますか？」 17
18. インタビュー結果をもとに、セグメントにおける課題の広さ、深さ、発生頻度、発生構造を評価し、次のフェー ズへ移るか引き続き課題の検証を行うか検討します。 課題仮説検証の評価 広さ 発生頻度 深さ 発生構造 対応パターン 1. 評価が十分にできない場合 →改めて課題を深堀りして取り扱う課題を特定し、再度 評価します。 2. 課題の広さ・頻度・深さが不十分な場合、もしくは一過 性な課題の場合 →同じ顧客の別の課題に目を向けます 3. 1, 2を実行しても、どの課題も広さ・頻度・深さが不十分 な場合、もしくは一過性な課題の場合 →別の顧客に目を向けます どれぐらいのコスト（お金、労力、時間など）を払って 解決しているか？ ✔ インタビューで確認 ✔ 行動観察や行動ログで確認 同様の課題を抱える顧客がどの程度いるか？ ✔ アンケートで定量調査 ✔ インタビューのうえ、セグメントのサイズを推定 どれぐらいの頻度で発生するのか？ ✔ インタビューで確認 ✔ アンケートで調査 ✔ 行動観察や行動ログで確認 構造的に存在・拡大を続ける課題か？ ✔ 顧客を取り巻く環境や社会情勢をウェブや本など で情報収集 参照：https://fintan.jp/page/6871/ 18
19. 4. ソリューション仮説検証 19
20. このフェーズでは、特定したターゲット顧客が抱えている喫緊の課題について、それを実際に解決するソ リューションを設計し、プロトタイプの提示・提供を通じて、顧客がお金を払うに値すると考えるようなサービ スを探索し、同時に見込み顧客を見つけます。 ソリューション検証フェーズ 目標 顧客にとって価値のあるソリューションを特定できている状態。 基準 ✔ ソリューションの購入意思を示す顧客が複数名いる ✔ 継続して利用している / 他の人にも紹介しようとしてくれている顧客が複数名いる ✔ ソリューションの価値にクリティカルなタスクが特定されている ✔ 検証済みのペルソナ ✔ 検証済みのジャーニーマップ ✔ 潜在顧客リスト ✔ 低忠実度プロトタイプ設計・作成 ✔ リーンキャンバス作成 ✔ プロトタイプ検証 ✔ 検証済みのプロトタイプ ✔ 見込顧客リスト Input Process Output 20
21. 考慮する項目例： 解決する課題の整理 課題仮説検証フェーズで集めた情報に基づいて、ペルソナとジャーニーマップの情報を更新し、これから自 分たちは誰のどのような課題の解決に取り組むかについて、チーム内で認識を合わせます。 企業ペルソナ ✔ 企業名 ✔ 業種 ✔ 商材の特徴 ✔ 売上規模 ✔ 従業員数 ✔ 社風 ✔ 業界における立ち位置 ✔ 将来の展望、戦略 個人ペルソナ ✔ 氏名 ✔ 年齢 ✔ 担当部署 ✔ 役職 ✔ 経歴 ✔ 決裁権の有無、決裁枠 ✔ 担当業務 ✔ 仕事上の目標 ✔ 自身や部署が抱える課題 参照：https://fintan.jp/page/6871/ ジャーニーマップの例： 参照：https://drm.ricoh.jp/lab/glossary/g00053.html 21
22. ソリューション設計プロセス例： ターゲット顧客の喫緊の課題について整理できたら、チームでの議論を通じてその課題を解決するサービ スのアウトラインを設計します。 ソリューション設計 情報収集 （30分） アイディアを考えるためのヒントとして、情報収集を行います。 ✔ 課題解決のために顧客が今使っているもの ✔ 同じ課題を解決するものとしていま存在するもの ✔ 別の領域で、似たような課題を解決するために使われているもの アイディエーション① （30分～60分） ✔ 10分ほどの時間をとって、個々に思いつく限りのアイディアをポストイットに書き／描きます。時間が来たら、それぞれの アイディアをプレゼンします。 ✔ それぞれ面白いと思ったアイディアを最低 1つ挙げ、その理由を説明します。 ✔ 誰でも参加できるようにするために、「紙に」「手で」書く／描くということが重要です。この時点では絵のうまさなど関係あ りませんし、表現方法は絵でなくても構いません。 アイディエーション② （30分～60分） ✔ 個々に、ベストだと思うアイディアを考え抜き、紙に書きます。 ✔ それぞれのアイディアをプレゼンします。 方針決定 （15分～30分） ✔ それぞれよいと思うアイディアに対して投票します。 ✔ 予め、最終意思決定者を決めておき、いくつかの案が競合するなど多数決だけでは判断できない状況が発生した際に、 方針が決定できるようにしておきます。 22
23. 検証するサービスを実際に立ち上げると仮定して、誰に、どのような価値をどのようにして届けるのか、また 健全な利益をあげながら継続できるものになるか、リーンキャンバスによって概要を整理することで、確認し ておきます。 ビジネスモデル検討 2. 顧客が抱える課題 どんな困りごとを解決する か？（特にアーリーアダプ ターのもの） 4. ソリューション 価値を届けるためにどのよう な機能を提供するか？ 3. 独自の価値提案 他のサービスにはない価値 は何か？どのようなインパク トを提供するか？ !! 機能ではなくインパクトを 考えましょう !! 9. 圧倒的な優位性 競合に簡単に真似できない自 社の優位性は何か？ !! 機能はすぐにコピーされるの で圧倒的とは言えません !! 1. 顧客セグメント 誰がお金を払ってくれるか？ 2. 既存の代替品 課題解決のためにいま（お 金や手間を払って）使ってい るツールは何か？ 8. 主要KPI どのような指標により、プロ ダクトがうまくいっているかを 測定するか？ 5. 顧客獲得チャネル どのようにして顧客にリーチ するか？ 1. アーリーアダプター セグメントの中で、最もお尻 に火がついている人は誰 か？ 7. コスト構造 サービスの開発や運用のために、何にいくらかかるか？ 6. 収益の流れ どうやって収益を上げるか？ ＊各項目にふられている番号順に考えていくとよいでしょう。 23
24. リーンキャンバス例：C2Cフリマアプリ 参照：https://monstar-lab.com/dx/solution/lean-canvas/ 24
25. クラウドファンディング、コンセプト ムービーなど オペレーショナルプロト ファンクショナルプロト セールスデッキ、ランディングペー ジなど デザインプロト モックアップ キャッチコピー、プレスリリース、 ダーティプロトなど ペーパープロト ワイヤーフレーム 主に顧客受容性の検証 プロトタイプには忠実度により様々なタイプがありますが、サービスのアウトラインとその価値をユーザーに 伝え、現時点で必要な検証のために、 最低限必要なプロトタイプはどのようなものかを検討します。 プロトタイピング 参照：https://fintan.jp/page/6873/ ＊多くの場合、検証の初期はサービスが顧客に受容されるかどうかの不確実性が高く、また細かい機能まで検証する必要はないため、できる限りコストをかけないで済む 方法（下図の左下のもの）によってコンセプトの有効性のみを検証し、段階を踏んで忠実度をあげていきます。 主に解決策の有効性の検証 現時点での解決策としての蓋然性 高 低 高 低 得られるフィードバックの具体性 ＝作成コスト 25
26. 検証方法： 設計したソリューション仮説が、顧客にとって「お金を払ってでも買いたいもの」かどうか、顧客の反応によっ て検証し、詳細設計に役立つ情報を集めます。 ソリューション仮説検証・評価 検証方法 ✔ 内容を説明したり、実物を見せたりして反応を確かめる。 ⇒インタビュー、アンケートなど ✔ 実際にサービス提供する前提でプレゼンし、申し込みがどれだけあるかに よってサービスの有効性を確かめる。 ⇒展示会、セールス、ウェブ / ソーシャルマーケティング、クラウドファンディ ング 検証項目 ✔ このサービスに対していくら払えるか？ （直接に「いくら払えるか」と聞くよりは、「 XX円を考えているが、使うか？」と 聞く方がよい。） ✔ 提供価値の実現にあたって、なくてはならない機能は何か？ ✔ 実装されているがなくてもよい機能（ →nice to have機能に再分類）、必須だ が備わっていない機能（ →must have機能として実装）は何か？ 留意点： • 検証したいサービスが有効であるという蓋然性がどれだけ高いかによって、プロ トタイプの内容と検証方法が変わります。適切な方法を選択しましょう。 • 検証する内容によって、どういう結果が出れば仮説が検証できたと判断するか、 判断基準を設定しておきましょう。 • 判断基準の考え方：次のフェーズで、事業立ち上げの準備プロセスに 入ります。立ち上げ直後にどれだけ顧客が見込めると、投資を Goでき るかという観点で考えます。 • 例：インタビューした人の中で、このサービスの利用申し込みの意向を 示した人が3人以上いる。 • 例：ウェブマーケティングしたところ、サービスの事前申し込みをした人 が30人以上いる。 • 課題仮説検証のインタビュー同様、インタビュイーが想定するセグメントに合うか どうかを把握しておくことは非常に重要です。 26
27. 顧客の反応以外にも、対象市場全体の動向や競合の動向やサービスの情報を基に、対象市場自体が魅 力的か、自社としてどのような特徴を有した商品 /サービスにすべきかを検討しましょう。 市場・競合分析 市場分析 ✔ 関連市場の特定：商品 /サービスが属する、もしくは商品 /サービスの盛衰に影 響しうる市場を特定。 ✔ 市場規模推移調査：上記で特定した市場の市場規模推移・将来予測を調査。 政府統計（国勢調査・商業統計等）や民間調査レポート（矢野経済研究所等）を 主に活用。 ✔ 市場トピックの把握：直近の法令改正状況・技術動向・代替市場動向等、当該 市場に影響を与えうるトピックを把握。 競合分析 ✔ 競合となりうる商品/サービス洗い出し：自社商品 /サービスの競合となりうる商 品/サービスを洗い出す。狭義の競合商品 /サービス（＝同様の課題解決手法） のみならず、広義の競合商品 /サービス（＝同様の課題を異なる手法で解決） まで広げられると尚良し。 ✔ 競合となりうる商品/サービスの分析：競合となりうる商品 /サービスをそれぞれ 調査し、対象とする顧客、解決する課題、主要機能・提供方法・価格等を比較 分析。 ✔ 自社における商品/サービス要素洗い出し：競合となりうる商品 /サービスの分 析結果を踏まえ、自社の商品 /サービスとして具備すべき機能や価格を設定。 参照：https://amzn.asia/d/hAJDDIu 27
28. 5. MVP検証 28
29. ユーザーにとって最適かつ事業として持続可能なかたちでソリューションを提供するために、最低限必要な プロダクトの仕様を特定し、開発や運用に関する予算や計画を策定します。 （このドキュメントではサービスブループリントの作成まで） MVP検証フェーズ ✔ 検証済みのプロトタイプ ✔ 見込顧客リスト ✔ サービスブループリント ✔ MVPプロトタイプ作成・検証 ✔ プロダクトバックログ作成 ✔ MVP要件定義 ✔ 事業計画、GTM戦略作成 ✔ MVPプロトタイプ ✔ 要件定義書 ✔ プロダクトバックログ ✔ 承認済みの事業計画 Input Process Output 29 目標 事業性のあるプロダクトと事業計画が定義できている状態。 基準 ✔ プロダクトの購入意思を示す顧客が複数名いる（LOIがある） ✔ セールスやマーケティングの戦略が定義できている ✔ 事業として成り立つ事業計画が定義できている
30. ソリューションの検証を通じて得た情報やフィードバックを基に、顧客にとって費用を払うに値するサービス の全体像を設計し、最低限プロダクトに担わせるべき部分や、将来的に開発すべき機能について明らかに していきます。 サービスブループリント 特定の目的を実現するために顧客がサービスを利用する際 の、顧客の行動を時系列で並べます。場合によっては実際に サービスに入る前の局面（例えばメールやランディングページ など）も含まれます。 サービスにおいて顧客と提供者の接点になるものを挙げてい きます。 サービス提供者（プロダクトも含む）の行動のうち、顧客に見え る部分のものを挙げていきます。 サービス提供者（プロダクトも含む）の行動のうち、顧客に見え ない部分のものを挙げていきます。 上記の要素を実現することを支援するために必要な、システ ムやプロセスを挙げていきます。 サービス立ち上げの初期は、すべてのプロセスをシステムや プロダクトで回さずに、人が対応することでサービス提供を実 現させることもよくあります。 （参照：MVPの例） 30
31. サービスブループリントの例（レストラン） 参照：https://blog.nijibox.jp/article/serviceblueprint/ 31
32. サービスのアウトラインが設計出来たら、事業として立ち上げるための準備が本格化します。各 LoSのワー クフローに従って手続きを進めていきましょう。 MVPの設計 ✔ 事業計画 ✔ 資金調達 ✔ プロトタイプ ✔ UI設計 ✔ 機能一覧 ✔ プロダクト要求定義書 ✔ ユーザーストーリーマップ ✔ プロダクトロードマップ ✔ Go to market 計画 ✔ オペレーション計画 ✔ プロダクト開発計画＆見積 ✔ 提携先との協議・交渉 ✔ ペルソナ ✔ ジャーニーマップ ✔ サービスブループリント ✔ リーンキャンバス 事業、サービスの基本的な構造を整理する ✔ 誰にどんな価値をどうやって提供するか？ ✔ 売上や費用の構造は持続可能か？ 発見した価値を提供するための具体的な方法を設計する ✔ どんな機能をプロダクトに担わせるか？必要な技術は何か（作れるか）？どん な順番で開発するか？ ✔ サービス提供にどんな体制が必要か？ ✔ どのようにしてユーザーに認知、導入、利用してもらうか？ ✔ ビジネスパートナーにはどのような役割を担ってもらい、見返りに何を提供する か？ 収益貢献までの見通しを立てる 立ち上げに必要なファンドを得る このドキュメント ではここまで 32
33. 6. 参考資料 33
34. 参考資料 考え方や全体像 ✔ 「新規事業開発」（TISインテック） ✔ 「なぜ【ロジックだけ】で新規事業は実現しないのか？」 ✔ 「良い課題を選ぶ 💮 - 価値は課題で決まる 💲」 ✔ 「ビジネスの仮説検証と実験の考え方」 インタビュー ✔ 「スタートアップの顧客インタビューのやり方（厳選記事）」 ✔ 「カスタマーマニアになろう 😍」 各種テンプレ ✔ 「カスタマージャーニーマップの書き方」 ✔ 「Service Blueprints: Definition」 ✔ 「肉厚なリーンキャンバスを書くには」 ✔ 「肉厚なバリュープロポジションキャンバスを書くには」 ✔ 「Journey Mapping 101] 実践と並行して参照するとお役に立つようなコンテンツをいくつかご紹介します。 ＊随時更新予定 MVP ✔ 「MVPの作り方 　おすすめの記事3選」 North Star Metrics（プロダクトの成果指標） ✔ 「プロダクト指標の作り方 – North Star Metric」 ✔ 「肉厚なプロダクト指標をつくる - North Star Metricを起点にしたKPIツ リー」 より全体像や考え方を詳しく理解するための本 ✔ 「アントレプレナーの教科書」 ✔ 「リーン顧客開発 ―「売れないリスク」を極小化する技術」 ✔ 「EMPOWERED 普通のチームが並外れた製品を生み出すプロダクトリー ダーシップ」 ✔ 「プロダクトマネジメントのすべて 事業戦略・IT開発・UXデザイン・マーケ ティングからチーム・組織運営まで」 34
35. Thank you 35