はじめに

ここでは、新規事業立ち上げのプロセス「ステージ・ゲートプロセス」における「概念実証(SPF)ステージ」を解説します。

※上図の各ステージをクリックすることで対応記事にジャンプできます。

新規事業立ち上げの全体概要を掴みたい方は、まず新規事業開発 ― ステージ・ゲートプロセスによる新規事業立ち上げを一読頂くことをお勧めします。

概念実証(SPF)ステージとは

SPFとは、Solution Product Fitの略で、顧客から吸い上げたソリューションの要件を商品・サービスとしてしっかりと表現できているか、
その商品・サービスによって顧客は課題を解決できるかなど検証します。検証を通じて、セールスやマーケティング戦略を精緻化し、
事業化にむけた準備を進めていきます。

アクティビティ 概要
検証仮説定義 顧客から吸い上げたソリューションの要件を商品・サービスとしてしっかりと表現できているか、その商品・サービスによって顧客は課題を解決できるかを検証するための仮説を構築するステップです。
MVP開発・PoC・テストセールス準備 立てた仮説を検証するために、適したMVPを開発したり、PoCやテストセールスの準備をするステップです。
PoC・テストマーケティング・セールス PoC(概念検証)やテストマーケティング・セールスを実行するステップです。
セールスレポート分析・マーケ・セールス戦略精緻化 検証結果を踏まえて、商品・サービスやマーケティング・セールス戦略のブラッシュアップを行うステップです。
SPF審査準備 審査に向けて、ここまでの活動で検討/検証した内容を整理・統合します。
SPF審査 審査観点に従って、企画を審査するステップです。

検証仮説定義

概要

顧客から吸い上げたソリューションの要件を商品・サービスとしてしっかりと表現できているか、その商品・サービスによって顧客は課題を解決できるかを検証するための仮説を構築するステップです。

実施手順

1. 仮説を洗い出す

SPFでは、顧客が「それがないと商品・サービスとして成立しない」と感じる要件の仮説化と、運営側が「解決策を実現するために最適だ」と考えている施策等の仮説化を行います。PSF段階の「顧客インタビュー」「市場競合・調査分析」で得られた内容を踏まえて、具体的に商品・サービスの仮説に落とし込みます。仮説は大きく分けて2つの観点に分けることができます。

  • 機能観点
  • 非機能観点
    • 品質・精度
    • スピード
    • デザイン
    • ユーザビリティ
    • オペレーション(営業やサービス運用のオペレーション)
    • チャネル
    • 流行への感度（新しいプロダクトをすぐ使用するのか・情報をこまめに得るタイプなのか　など）
    • 価格
2. 仮説を「重要度」と「不確実性」の2軸で評価し、検証すべき仮説を選定する
  • 重要度：その仮説の正誤が商品・サービスに与える影響の大きさ
  • 不確実性：その時点で分かっている仮説の確からしさ

重要かつ不確実性が高い仮説(右上に近いもの)が検証すべき仮説となります。

仮説検証マップ

仮説検証マップ

コツ/注意点

仮説は「6W4H」を意識する

「それがないと商品・サービスとして成立しないもの」がSPFでの仮説となると述べましたが、例えば「レコメンド機能」や「予約システム」といった機能単位では、顧客が本当に求めているものが分かりません。
その機能が必要になる頻度や支払意向金額がいくらなのかまで掘り下げることで、顧客が求めているものと合致しているか検証できるのです。

  • What：何をやるのか？
  • Who：誰が？
  • Whom：誰に？
  • When：いつ？
  • Where：どこで？
  • Why：なぜそうすべきなのか？
  • How：どのようにやるのか？
  • How often：どれくらいの頻度で？
  • How many：何回/どれくらいの量か？
  • How much：それにいくらかかるのか？
解決策が実現できるかも忘れず検証する

解決策を実現するためには、以下のような観点を達成する必要があります。SPFでは、事業性だけでなく、オペレーションや顧客獲得などの実現性も忘れずに仮説化し、検証します。

  • 事業性がある
    • 顧客がその解決策を採用する
  • 実現性がある
    • 顧客に届けられる(アプローチできる)

MVP開発・PoC・テストセールス準備

概要

MVPとはMinimum Viable Productの略で、「仮説を検証可能な最小限の製品」を意味します。
立てた仮説を検証するために、適したMVPを開発したり、PoCやテストセールスの準備をするステップです。

仮説検証のためにMVPが必要となる場合、プロダクトオーナーのロールを担う人がMVP開発の主軸を務めましょう。
事業オーナーとプロダクトオーナーに対する期待については事業オーナーとプロダクトオーナーを、本ステージのMVP開発体制については開発体制と開発要員の確保もご参照ください。

実施手順

1. MVPキャンバスを使って検証内容を整理する

MVPキャンバスとは、仮説検証の内容を明確化するためのフレームワークです。MVPキャンバスを利用することで、検証の目的や適した検証方法を整理できます。MVPキャンバスには、下記の10個の要素があります。
「結果」と「得た学び」については、検証後に記載することが基本ですが、検証前に予想して書いてみると、想定外の結果の洗い出しや検証仮説の優先度を確認できます。

MVPキャンバス

MVPキャンバス

2. 目標数値を策定する

例えば、商品・サービスを注文できるサイトを作って検証をする場合、コンバージョン率(CVR)や顧客獲得コスト(CPA)をKPIとすることが多くあります。
またMVPを顧客に使ってもらい、感想を聞き出す場合、モニターのうち◯％が設定した価格で利用したいと答えるかどうかをKPIとすることもあります。
使用感はインタビューで聞き出します。

KPIとする目標はできるだけインタビューなどの認知データではなく、ユーザーの行動データで検証する方が蓋然性が高く、望ましいです。

3. 「人力で代用できる部分」と「システム開発すべき部分」を切り分けMVPの型を検討する

検証方法を検討する際は、「人力で代用できる部分とそうでない部分」を切り分け、検証方法を決定します。
そして、仮説の内容を鑑み、その仮説を検証できるMVPの型を決めます。MVPの型については以下をご参照ください。

MVPの型 概要 検証できること 事例
ランディングページMVP Webページ（ランディングページ）だけを作り公開するMVP。ユーザーに登録してもらうといった機能のみを持つ ニーズの多さ、顧客のプロフィール ・その業界を知らなくてもBtoB事業は立ち上げられる−やり方とコツ−
・Idea to Paying Customers in 7 Weeks: How We Did It
動画MVP 動画を活用してユーザーがプロダクトに興味を示すかを検証するMVP 1 ニーズの多さ ・How DropBox Started As A Minimal Viable Product
プロトタイプ型MVP 実際に動くものを作り公開するMVP 機能性、デザイン性、体験など ・$12.000, 3 weeks and a business angel: make app like Reddit
オーディエンス開発型MVP 製品を開発する前に顧客基盤を開発するMVPのこと。まず見込み客のセグメントを明確にし、これら顧客と意見交換するための場を構築し、オーディエンスを観察する2 開発する製品の機能、ニーズの多さ3 How Pinterest Grew From 3,000 to 73 Million Users
コンシェルジュ型MVP プロダクトと同じ効果を、自分たちの手で提供する MVP ニーズの多さ、サービスの成果に価値を感じてもらえるか、顧客がお金を払ってくれるか ・フードデリバリーのユニコーンの「DoorDash」が仮説検証に行った人力MVP
・Manuel Rosso, Food on the Table
オズの魔法使い型MVP 顧客は製品が手作業によって動作していることを認識していない上で、完全に機能が実装されているように見せかけ、提供するMVP4 ニーズの多さ、サービスの成果に価値を感じてもらえるか、顧客がお金を払ってくれるか ・「デザイン思考」のプロトタイプ（試作品）とは？
・1年間開発したプロダクトを捨てて、5日でダイニーをリリースした話
4. 必要最小限の機能を定義する

必要最小限の機能を検討する際、まずはユーザーストーリーマップを作り、参考にすると良いでしょう。
ユーザーストーリーマップを理解するためには、まずユーザーストーリーを知る必要があります。

ユーザーストーリーは、「商品・サービスの機能が顧客にどのような価値を提供するかを示す」抽象度の高い機能記述です。具体的なユーザーストーリーの例5が以下です。ユーザーの分類(役割)、ユーザーの目的、その理由を具体的に記述します。このような形で要件の意図と本質を捉えた文章により、チームは後段でより詳細な議論が可能になります。

ユーザーストーリーの雛形

ユーザーストーリーの雛形

ユーザーストーリーマップは、ユーザーの一連の行動を表した図です。商品・サービスを使いはじめてから使い終えるまでのユーザーストーリーについて、横軸は時系列、縦軸は優先度順で整理し、MVPで開発すべき機能を決定します。

ユーザーストーリーマップ

ユーザーストーリーマップ

ユーザーストーリーマッピングは利用者に価値をもたらす大まかな行為(例:「製品を購入する」; エピックと呼びます)を考え、以下のように進めます。

  1. エピックを達成するために必要な手順・一般的なワークフローを考え、時間軸に沿ってテーマを並べる
  2. それぞれのテーマをユーザーストーリーに分解し、優先順位に基づいて縦に並べる
5. サービスブループリントを作成し、検証に向けたオペレーションを策定する

横軸にユーザーの流れを整理し、それに対するフロントステージアクション（ユーザーから見える表側の動き）やバックステージアクション（ユーザーからは見えない裏側の動き）の動きを記入します。これにより、検証中のオペレーションがスムーズに実行できるようになります。
必ずしもシステム化せず、人的なオペレーションで対応する部分を決めることで、低コストでスピーディにMVPを作ることがポイントです。

サービスブループリント

サービスブループリント

6. 組み合わせる既存プロダクトや分析ツールの準備を進める

サイトのアクセスや遷移データを分析する場合、GoogleアナリティクスやGoogleタグマネージャーの用意を進めます。他にも例えば、メッセージのやりとりをするために既存のプロダクトを活用する場合は、アカウント開設等の準備を進めておく必要があります。

7. MVPを開発する

エンジニア主導でMVPを開発します。MVP開発のための要件整理以降をご参照ください。

コツ/注意点

なるべく手間やコストがかからない検証方法を選定する

新規事業には失敗がつきものです。顧客に意見を聞いてみると、自信があるアイデアでもネガティブな意見をいただくことが多々あります。そのため、トライ＆エラーを前提に検証を進めることがとても大切です。

大切なのは、「検証ができるかどうか」であり、必ずしもコードを書いてシステム等を作り込む必要はありません。「本当に検証すべきことは何か」「そのために必要最小限の機能は何か」を整理し、検証方法を検討しましょう。

本番と近い条件で検証する

正確な検証結果を得るためには、事業化後にリリースする本番の環境に近い条件で検証することが重要です。

MVP開発のための要件整理

MVP開発を始める前に、要件を整理する必要があります。
MVPキャンパスで示される「仮説」と「何を学ぶのか」、そしてユーザーストーリーマップをインプットに、エンジニアが主導して「実際に何を作るのか」「仮説をどうやってそのMVPで実証するのか」を検討します。

最小限の努力で仮説を検証できる方法を考えましょう。なぜなら、仮説は間違っていることの方が圧倒的に多いからです。
このため、このステージにおいてエンジニアが考えなければならないのは、「どうやって作るか」ではなく「どうやれば作らずに済むか」です。

MVPに含む機能を増やすとさまざまな悪影響が生じます。その中でも特に問題なのは、市場投入が遅くなるとともに、何が顧客に受け入れられたのかもわからなくなることでしょう。

さまざまなことを一度に検証したいところですが、すべてを作ろうとするのではなく、「最低限必要なものはなにで、どうやれば作らずに済むか」をエンジニアと事業オーナーで考えてください。

機能要件

MVPは素早く作り、素早く検証することが至上命題です。
詳細な要件定義によってアジリティを削ぐのは本末転倒です。チームで多くコミュニケーションをとり、素早く「作るもの」のイメージをすり合わせましょう。具体的には、以下を準備すると良いでしょう。

すり合わせ対象 必要なもの
画面 ・画面遷移図
・個々の画面のワイヤーフレーム (ボタンを押すと何が起きるのかといった機能説明を含む)
対外I/F どの外部システムに、どのような形で連携を行うのか

その後に個々のユーザーストーリーを実現するための要件を整理し、後述する形で見積もりします。

非機能要件

新規事業におけるMVP開発がそのほかの開発と大きく異なるのは、多くの場合MVPは「使い捨て」になることです。
このため、本格的な事業開発とは異なり、非機能要求グレードがスコープとするような非機能要件の多くについては、作り込みを必要としません。

ただし、非機能要求のグレードを最低限とすることにより、バックアップからの復旧ができない等、MVPのユーザーになんらかの不都合が生じ得ます。この点については、必要であればMVPの利用規約で明記しておくべきでしょう。

セキュリティについては、注意が必要です。
大前提としては、個人情報等、守るべき情報資産をできるだけ持たないように検証計画を作成するのがお勧めです。
一方で、仮説によっては情報資産を持たないと検証できない場合もあります。このようなケースでは、当該の情報資産の漏洩を防ぐ等、最低限のセキュリティは具備しておく必要があります。

非機能要求 大項目6 説明7 要求レベル
可用性 システムサービスを継続的に利用可能とするための要求 最低限で良い。仮説さえ検証できれば、MVPの継続利用は必須ではない
性能・拡張性 システムの性能、および将来のシステム拡張に関する要求 最低限で良い。体験(UX)を重視する検証はあり得るが、その場合に必要なのは性能ではなく操作性になる
運用・保守性 システムの運用と保守のサービスに関する要求 最低限で良い。MVPにおける運用・保守は短期間で終わるため、新規事業開発チームが人力で回せる程度の運用・保守性があれば良い
移行性 情報システムの安全性の確保に関する要求 最低限で良い。ほとんどの場合、MVPにおいて移行性が求められることはない
セキュリティ 情報システムの安全性の確保に関する要求 高いレベルが求められ得る。個人情報を含むユーザー情報の漏洩や、決済を伴うMVPの場合の不正利用等があり得る
システム環境・エコロジー システムの設置環境やエコロジーに関する要求 最低限で良い

開発規模見積(MVP)

要件を整理した結果、アプリケーション開発を伴うMVP開発をすることになった際の見積もり・スコープ調整の手法を解説します。

MVP開発に要する期間及び工数の算出

この時点でMVP開発のための要件が固まっていると思います。そのアプトプットを利用してMVP開発に要する期間や工数を算出します。

見積もりの最大の目的は以下の2点です。

  • リスクを検知し、対策を計画に組み込むことでプロジェクトの成功可能性を高める
  • 実際に開発した場合、どのくらいの期間や予算、体制が必要になるのかを知る
要件や仕様に曖昧な点がある場合は、プロダクトオーナーに確認します。見積もりでは、要件整理とは違った視点でプロダクトを眺めることもあると思います。要件整理時には出てこなかった仕様がないか再度確認します。
プロダクトオーナーも答えを持っていない場合は、設定した課題やペルソナ、検証する仮説に立ち返り、チームで一緒に考えましょう。

見積もりは、開発一式でいくらといったような出し方はせず、ユーザーストーリーごとに算出します。ユーザーストーリーごとに算出するのは、後述する開発スコープの調整において大事な役割を果たすからです。

アプリ開発部分はもちろんですが、アプリを運用するためのインフラの見積もりも算出します。
インフラに関しては、本書で扱う技術でも述べたように、Amazon Web Services(AWS)を利用します。

また、見積もりの算出にできる限り時間をかけないようにすることも大切です。MVP開発における見積もり方や構成などをパターン化、整理して、見積もりを素早く行えるようにしましょう。

アプリ見積もり(MVP)

本書で扱う技術にも記載した通り、同じ技術スタックを想定した見積もりになることが多いでしょう。見積もりのための手法や、テンプレートを整備しておくと見積もり作業時間の短縮を図れます。

新規事業開発の見積もりには以下の点が要求されます。

  • 迅速に見積もりを行えること
  • リスクを定量的に評価し見積もりに含められること
  • いわゆる実装だけでなく、要件定義フェーズやテストフェーズ等、フェーズごとの工数を見積もれること
リスクの定量的評価

新規事業開発は本質的に不確実性(=リスク)を内在しており、最初から要件がしっかりと固まっているわけではありません。
一方で、そういった中でも「いつまでにできるのか」「どれだけのコストがかかるのか」という質問には回答せざるを得ません。

不確実性コーン

(プロジェクトの本質とはなにか より引用(2022年3月14日閲覧))

このため新規事業開発における見積もりには、リスクを定量的に評価し見積もりに反映することが必要です。

フェーズごとの工数見積もり

いわゆるスタートアップ企業では、事業開発チームのメンバーを固定し習熟度を積み重ねることがベストとされています。
一方で、多くの開発者を抱える大企業において複数の新規事業開発を並行して進める場合は、以下のような調整が可能になります。

  • 実装やテストフェーズ等、エンジニアを一時的に増員することによってリリースを早められる
  • 方式設計等、限られたエンジニアで進めた方が効率の良い場合に、当該エンジニアを他の事業開発にアサインすることで要員配置の最適化を図ることができる

このような調整をおこなっていくためには、テストフェーズ等のフェーズ毎に工数を見積もることが必要になります。

見積もりの進め方

新規事業開発における見積もりの進め方を以下に記載します。

実装フェーズの見積もり

ここではまず、実際に実装・テストを行うフェーズの見積もりについて説明します。

この時点で機能の詳細までは固まっていないことも多いでしょう。そういった場合に利用するのが「Tシャツサイズ見積もり」と言われる見積もり方法です。

Tシャツサイズ見積もりは、各機能実装に対して相対的な工数を示す「Tシャツサイズ」を割り当てることで見積もる手法です。その他の見積もり手法として、各機能実装で必要なタスクを細分化し、それぞれタスクの工数を積み上げていくような手法もありますが、Tシャツサイズ見積もりの方が圧倒的に簡単です。
これは、人間は絶対的な見積もりよりも相対的な見積もりの方がうまくこなせる8ためです。

Tシャツサイズ見積もりについての考え方は以下の記事で詳しく説明されているのでご参照ください。

上記記事を参考に、Tシャツサイズ見積もりでは以下の順に進めます。

  1. 「Tシャツのサイズ」を決め、各サイズが何を表すのか共通認識を持つ
  2. 各機能の「実装・テスト」フェーズに対して、平均的なTシャツサイズと、最悪の場合のTシャツサイズを割り当てる
Tシャツのサイズを決め、共通認識を持つ

我々は共通認識を持ちやすくするため、Tシャツサイズとして「難易度」を対応させ、「実装・テスト」の規模を示す相対的なポイントを紐付けます。

ポイントについては2の累乗(1、2、4、8、16…)やフィボナッチ数列(1、2、3、5、8、…)のように、差がどんどん大きくなる数列を利用することが基本です。我々は、2の累乗をよく使います。
これは、人間の見積もりは、規模が大きくなるほど曖昧になるためです。例えば見積もりにおいて1 ptと2 ptの間には明確な差がありますが、80ptと81ptという見積もりに大きな差はありません。

その後は基準となるTシャツサイズを設定しましょう。以下がその具体例です。
この場合、DB上のデータを単に表示するだけの難易度はTシャツサイズCとし、その2倍難しそうな機能はサイズBとなります。

難易度 実装フェーズ(ポイント) 難易度の基準
SS 64 サイズSより2倍難しい
S 32 サイズAより2倍難しい
A 16 サイズBより2倍難しい
B 8 サイズCより2倍難しい
C 4 DB上のデータを取得し画面に表示するだけの機能
D 2 サイズCの半分で開発可能

一方で、要件や連携先が固まっていないといった不確実性(=リスク)が多く内在しているため、想定よりも開発工数が膨らむことも考えられます。
このため、リスクを見積もりに反映しておく必要がありますが、個々の機能にリスクバッファを追加してしまうと、コスト大の見積もりとなり、計画が破綻してしまいます。

事業の抱えるリスクに見合う、全体としての「適切なリスクバッファ」がどの程度か。
この課題に立ち向かった事例は多点見積りとスケジューリングの実践を参照していただければと思います。
我々も似たアプローチを採り、以下のようにして計算します。

  1. 機能毎に、リスクを鑑みたときの「最悪の場合のTシャツサイズ」をチームで決める
  2. 個々の機能の不安量として、「Tシャツサイズ(最悪)」-「Tシャツサイズ」を算出する
  3. 全機能に対し、不安量の2乗和平方根を算出し、それをリスクバッファとしてのポイントとする

計算方法は以下の表のようになります。

項目 計算方法
不安量 「Tシャツサイズ(最悪)」-「Tシャツサイズ」
リスクバッファ 全機能に対する「不安量」の2乗和平方根 (√(Σ{不安量^2}))
見積もりポイント 全機能のTシャツサイズ総和 + リスクバッファ

その後、1ポイントあたりがどのくらいの開発時間に相当するのかをチーム内で議論し、
「ポイント×1ポイントあたりの開発工数」という計算にて、全体の開発工数に変換します。

工程ごとの見積もり方法

ここまでで「実装・テスト」フェーズの工数を見積もれました。
ここに、方式設計を含む外部設計、結合テストや総合テストの工数は含まれていません。これらは、個々の機能に対するものではなく、事業の持つ機能全体に対するものとなるため、「機能毎の見積もり」というアプローチを採ることができません。

そこで、本書では工程別の工数割合からそれらのフェーズの工数を算出することを推奨します。

用いたデータはIPAの以下の分析データです。分析対象プロジェクトのプロファイルは新規事業開発のプロファイルと一致するものではありませんが、現時点で最も頼り得るデータとして使用しています。

工程別の実績月数の比率の基本統計量（新規開発）

ソフトウェア開発データ白書2018-2019 P.177より引用(2022年1月18日閲覧)

こちらの表の中央値をベースにして、各工程にかかる時間を算出します9。

工程 中央値 「実装・テスト」を100％としたときの割合
外部設計 0.198 48.5%
内部設計＆製作 (=実装・テスト) 0.408 100.0%
結合テスト 0.184 45.1%
総合テスト 0.176 43.1%

上記の表を元に、「実装・テスト」の工数から、外部設計・結合テスト・総合テストのおおよその工数を割り出します。

以上の手法にて、新規事業開発におけるアプリ見積もりをスピーディに進めることができます。

インフラ見積もり(MVP)

MVPでは高いレベルの非機能要件が求められないため、システムアーキテクチャはパターン化できます。
このため、Amazon Web Services(AWS)を利用する場合のサンプルを作成しています。

MVP時のクラウドインフラ

MVP時の費用をできるだけ抑え、クラウド上でできるだけ簡潔・安価にインフラを構築するためのガイドです。
もちろん、インフラ構成は数多のパターンが考えられますが、構築難易度が低い代表的なパターンをいくつか掲載します。
これをカスタマイズすることにより、おおよそのMVPニーズには応えられると考えています。

なお、AWS Well-Architected フレームワークには必ずしも沿っていません。MVPにおけるインフラ構築の一番の目的は、低コストで迅速に仮説を検証するシステムを構築することであり、非機能要件は最低限で良いと考えているためです。

費用についても一覧化しています。2022年3月11日現在の費用を元にして算出しています。

アーキテクチャパターン
サーバーレスアーキテクチャでのシンプルなWebアプリケーション提供

画面を持つシンプルなWebアプリケーションを構築するパターンです。

  • 画面はSPA(Single-Page Application)で構築し、バックエンドのAPIを呼び出すアーキテクチャ
  • バックエンドAPI数が少ないときに利用推奨

バックエンドAPIをサーバーレスで構築することで、「使われた分のみ」コストが発生するというアーキテクチャです。

SPAを構成する静的コンテンツをAmazon S3(以下、S3)に配置し、REST APIはAmazon API GatewayとAWS Lambdaで提供します。

LambdaとS3ベースの構成サンプル

リソース 費用 メモ
AWS Lambda $0 ユーザーが少なければ呼び出す回数も少なくなるため、多くの場合は無料枠内で収まるでしょう。
Amazon S3 月額 約$0.03 オブジェクトのトータルのサイズが1GBで月額 $0.025の費用がかかります。
Amazon API Gateway 月額 約0.4 月間10万リクエストを想定。
AWS DynamoDB 月額 約$0.4 データストレージサイズ1G、平均項目サイズ1kB、読み書き数は10万回を想定。
Amazon CloudFront $0 インターネットへの転送量が1TBまでは無料です。ユーザーが少なければ、ほとんどの場合無料枠内で収まります。
AWS Certificate Manager 無料 無料
Data Transfer 無料 CloudFrontからS3やAPI Gateway間のデータ転送は無料です。
Amazon Route 53 月額 約$0.54 DNSを利用する場合は1ドメインあたり$0.50がかかります。
また少額のクエリ料金が必要です。$0.04程度を想定していれば問題ないでしょう。
独自ドメイン(.jp想定) 年額 $90 利用できるドメインがない場合は取得します。
AWSで取得する場合、.comで$12、.jpは$90です。
バックエンドで複雑なロジックを持つWebアプリケーション

サーバーレスアーキテクチャでのシンプルなWebアプリケーション提供パターンと比べると、APIの数が多く複雑な場合に選択します。
一般に、MVPはシンプルであるべきです。このパターンを選択する場合は、本当にそれだけ複雑な機能をMVPが持たないといけないのかを何度も検討してください。

ECSの構成サンプル

ECSの構成サンプル

リソース 費用 メモ
AWS Fargate 月額 約$44.36 1CPU、2GB、エフェメラルストレージ20G、停止なしの料金です。
Amazon Elastic Load Balancing 月額 約$18 最低限での利用を想定しています。
NAT ゲートウェイ 月額 約$46 プライベートサブネットからインターネットに出る場合には必要になります。
Amazon RDS for MySQL 月額 約$20 db.t2.microインスタンスをSingle-AZで利用することを想定しています。ストレージは汎用SSD(gp2)、サイズは10GB。
Amazon CloudFront $0 インターネットへの転送量が1TBまでは無料です。ユーザーが少なければほとんどの場合無料枠内で収まります。
AWS Certificate Manager 無料 無料
Amazon CloudWatch $0 インスタンスのステータスチェックやCPU等のメトリクスの取得、簡単な通知程度でしたら無料枠内で問題ないでしょう。
Amazon CloudWatch Logs 月額 約$1.5 毎月1G程度のログをアプリケーションから送信し保存する想定です。長期間のMVPの場合はS3へログを出力することを検討します。
Data Transfer 無料 CloudFrontとELB間のデータ転送は無料です。
Amazon Route 53 月額 約$0.54 DNSを利用する場合は1ドメインあたり$0.50がかかります。また少額のクエリ料金が必要です。$0.04程度を想定していれば問題ないでしょう。
独自ドメイン(.jp想定) 年額 $90 利用できるドメインがない場合は取得します。AWSで取得する場合、.comで$12、.jpは$90です。
EC2インスタンスにミドルウェア全部乗せ

Webサーバー、RDBなどをAmazon EC2(以下EC2)インスタンス上のOSにインストールして利用するパターンです。やむを得ず複雑な構成になってしまったが、費用を抑える必要がある時にこのパターンを検討します。

Amazon RDSやAmazon ElastiCache、Amazon OpenSearch Serviceといったマネージドサービスを利用すると、それぞれのサービスで費用が発生します。高い可用性が必要ない場合は、EC2インスタンスにインストールして利用する方がより費用を節約できます。

ユーザーからのアクセスはすべてCloudFrontを通しています。CloudFrontからEC2へのアクセスにはhttpsを利用します。

転送量が少ない、画像等キャッシュすべきファイルが少ないといった場合は、
Amazon CloudFrontを通さず直接EC2へアクセスしても問題ありません。

EC2インスタンスは、パブリックサブネットに配置します。
プライベートサブネット上に配置すると、Elastic Load Balancing(ELB)を利用する必要があり、こちらが月額でおおよそ$18ほどかかるためです。
また、インスタンスからインターネットへ出る必要がある場合、NATゲートウェイが必要になり、こちらは月額おおよそ$46ほどを見ておく必要があります。

パブリックサブネット上にインスタンスを配置しますので、セキュリティグループの設定で必要なポート(この場合は443)のみ開放するようにします。
リモートログインにはSession Managerを利用します。

EC2インスタンスにミドルウェア全部乗せパターンのサンプル

EC2インスタンスにミドルウェア全部乗せパターンのサンプル

リソース 費用 メモ
Amazon EC2 (t2.medium想定) 月額 約$46.78 月によって日数が異なりますので前後します。
Amazon CloudFront $0 インターネットへの転送量が1TBまでは無料です。
ユーザーが少なく、アクセスも少なければほとんどの場合無料枠内で収まります。
Elastic IP アドレス $0 起動中のインスタンスにアタッチしている間は、インスタンス1つにつき1つまで無料です。
AWS Certificate Manager 無料 無料
Amazon CloudWatch $0 インスタンスのステータスチェックやCPU等のメトリクスの取得、簡単な通知程度でしたら
無料枠内で問題ないでしょう。
Data Transfer $0 この構成の場合、EC2からCloudFrontへの転送費用がかかりますが、
100GBまで無料です。
こちらもユーザーが少なく、アクセスも少なければほとんどの場合無料枠内で収まります。
Amazon Route 53 月額 約$0.54 DNSを利用する場合は1ドメインあたり$0.50がかかります。
また少額のクエリ料金が必要です。$0.04程度を想定していれば問題ないでしょう。
独自ドメイン(.jp想定) 年額 $90 利用できるドメインがない場合は取得します。
AWSで取得する場合、.comで$12、.jpは$90です。
Amazon Lightsail

Amazon Lightsailは、AWSが提供しているVPSサービスです。
事前設定されたWordPressやDrupalといったアプリケーションを簡単に立ち上げることができるとともに、ロードバランサーを利用した冗長構成にもできます。
スペックに制限がある代わりに、基本的に月額固定コストで立ち上げられます。

リソース 費用 メモ
Amazon Lightsail 仮想サーバー 月額 $10 2GBメモリ、1コアプロセッサ、60GBのSSDディスクのサーバーを利用した場合。
3TBのデータ転送もついています。
Amazon Lightsail Elastic IP アドレス $0 起動中のインスタンスにアタッチしている間は、インスタンス1つにつき1つまで無料です。
Amazon Route 53 月額 約$0.54 DNSを利用する場合は1ドメインあたり$0.50がかかります。
また少額のクエリ料金が必要です。$0.04程度を想定していれば問題ないでしょう。
独自ドメイン(.jp想定) 年額 $90 利用できるドメインがない場合は取得します。
AWSで取得する場合、.comで$12、.jpは$90です。

Lightsailを利用した場合のサンプル

Lightsailを利用した場合のサンプル

  • Amazon LightSailはAWS Pricing Calcuratorで計算できないため見積もりサンプルはありません
その他

簡単かつ迅速にバックエンドサービスを立ち上げ可能なサービスとしては、AWS Amplify、AWS App Runnerといったサービスもあります。要件や個々のスキルに応じて最適なサービス、アーキテクチャを選択するのがよいでしょう。

付記: 外形監視について

AWS内でAmazon CloudWatch Syntheticsを利用した外形監視を設定すると月額8000円程度かかります。
そのコストを気にする場合は、SaaSの利用がおすすめです。

開発スコープの調整(MVP)

見積もりをした上で、予算や想定していた開発期間を超えてしまいそうな場合は、開発スコープを調整します。
開発スコープの調整は、実際に開発をするエンジニアがリードして調整した方がよいでしょう。

優先度をつける

各機能に対して、優先度をつけます。
優先度づけは難易度の高い課題ですが、我々がおすすめするのはRICEというフレームワークです。

これは、「RICE」を構成する文字で表現される以下の4つの指標によって、ある種の費用対効果を計算し、優先度を測る方法です。

  • R(Reach): 影響を与えられる人数
  • I(Impact): 個々人に与えられる影響の度合い
  • C(Confidence): RやI、Eの確度
  • E(Effort): 当該機能の開発に必要な工数

優先度を測るスコアは以下の式で算出します。

RICE

RICE

事業オーナーとともにこの値を算出することで、優先度を適切に判断しやすくなるでしょう。

開発計画

開発プロセス(MVP)

MVP開発では、仕様を詳細に記載したドキュメントを作成する必要はありません。仮説を検証することが目的であり、検証の結果によって次々に仮説が変わっていくからです。
この変化に詳細なドキュメントを追従させていても、素早い仮説検証の妨げになるでしょう。
MVP開発はおおまかな仕様だけで開発する必要があり、少しでも早くMVPを完成させるべきだと考えます。

このため、プロダクトオーナーへ動くものを見せながら進めることができ、すぐにフィードバックを得られるアジャイル形式で進めるのが最適です。アジャイルの実践手法として、我々はスクラムを使っています。

スクラムの詳細についてはスクラム概論 | アジャイル・スクラム | Fintanを参照ください。

開発プロセスについては、後述する体制・チーム内のスキルセットを鑑みながら、スプリント運営ガイド | アジャイル・スクラム | Fintanをベースに検討ください。

開発体制と開発要員の確保

必要であれば開発要員を確保した上で、開発体制を整えます。

開発メンバーについては、短期間で開発することを目指すため、少人数かつアプリからインフラまでカバーできるスキルセットを持ったチームを構成するようにしましょう。
人数が多すぎる場合、コミュニケーションコストがどうしても高くなりがちになります。必要なスキルを持ったチームを構成できなかった場合、チームがカバーできていない範囲がボトルネックとなり開発に時間がかかる要因となるでしょう。

このようなチーム構成を目指すことを前提に、チーム内で開発を担当可能なメンバーがいれば担当してもよいですし、そうでない場合は別部署との協業やビジネスパートナーに依頼することも検討します。

スクラムで進める場合、以下のような体制を敷くのが理想です。

スクラムで進める場合の理想の体制

スクラムで進める場合の理想の体制

それぞれの役割の概要については、スクラム現場ガイド10より引用した以下の表を参照ください。

役割 特徴
スクラムマスター ・信頼を醸成する
・問題に気づくよう促す
・影響力を通じてリーダーシップを発揮する
・人を相手にした仕事を好む
・プレッシャーの中でも穏やかでいる
プロダクトオーナー ・顧客の要望を聞いて、何が本当に求められているか判別できる
・ステークホルダーや顧客と機能について合意できる
・プロダクトマネジメントに熟練している
・基礎的な財務会計の経験がある
・開発中のアプリケーションが対象とする業界の経験がある
チームメンバー ・オープンなマインドの持ち主である
・改善したり人の改善を助けたりしたい
・チーム指向である
・尊敬される
・謙虚である

プロダクトオーナーは、一見事業色が強く見えますが、エンジニアリングを理解していることも求められます。メンバーのスキルセット次第ですが、エンジニアがプロダクトオーナーを担うことも検討してもよいでしょう。新規事業開発の文脈において、プロダクトオーナーに求められる資質は、事業オーナーに求められる資質とは異なります。マネジメントやシステム開発の知識や理解が求められます。そのため、プロダクトオーナーは事業オーナーと他のエンジニアとの橋渡しを担う必要があります。

一方でMVP開発は、短期間かつ低コストで行うべき活動です。
結果として、開発チームはがフルスタックエンジニア1名のみで構成されるかもしれませんし、
スクラムマスターを開発チームメンバーが兼務するという状況も発生し得ます。
これらは必ずしもスクラムガイドに則ったものではないため、それに起因する課題も発生するでしょう。以下に、課題と対応例をまとめました。

課題 対応
チームとして習熟する期間が取れない ベロシティが上がるのは、主に「運営方法に慣れるから」ではなく、「要件や設計に対する理解が深まるから」であったり「開発技術に慣れるから」であることが多いです。このため、事業の支障のならない限り、利用するアーキテクチャ設計や技術は他の事業開発と可能な限り統一しましょう。
スクラムマスターと開発チームの兼務 本来スクラムの3つのロールは混ぜるべきではないが、スクラムマスターと開発チームの兼務は最も被害の少ない組み合わせ11です。チーム全員が最初から状況を共有できるように開発プロセスを設計しましょう。
人数が少ないことにより、チーム内の相互作用が難しい 他の新規事業開発チームと状況や学びを共有する場を明確に設定しましょう。
全体計画の策定

アジャイル開発では詳細な計画は立てませんが、全体計画は必要です。
見積もりの時点である程度の目途は立っているはずですが、機能実装がいつ頃完了し、どのようなテストをいつから実施するか、いつリリースするかを事業オーナー・プロダクトオーナーと相談して決定します。
この全体計画の作り方はスプリント運営ガイド – スプリント全体計画をご参照ください。

全体計画上で悩ましいのは、MVPにおいて、どのようなテストをどこまで実施するかでしょう。
MVPの目的は「仮説の検証」です。その目的を前提に、どこまで何を「テスト」しないといけないのかを事業オーナー・プロダクトオーナーとともに「MVPをリリースするために十分なテストが何か」を検討しましょう。

実践リスクベーステスト-PRISMAメソッド-では、テストが「十分」の定義は以下のように説明されています。開発者が独善的に「バグを0にしなければならない」といった勝手な判断しないようにしましょう。その判断がアジリティを削ぐことにもなりかねません。

  1. 現在の状態で十分に価値を出せる事
  2. 重大な問題がない事
  3. その機能が作る価値は、残存する問題（重大ではない）が引き起こす可能性のある損害よりも十分価値がある事
  4. 現在の状況、考えられているすべての事柄において、それを修正するためにリリースを遅らせたならば、利益よりも損害の方が大きい事

テスト種別＆テスト観点カタログにあるテスト種別カタログをベースに、MVP開発における方針を以下のように定めます。
なお、これはあくまでプロトタイプの型としてプロトタイプ型MVPを選択した場合の方針です。事業の特性や選択したMVPの型等によって変わりますので、事業ごとに要否を検討ください。

テスト種別 要否 理由
構文チェック △ 必須ではありません。ただし、複数人で開発をする場合は、構文チェックをCI等で自動化しておくのがおすすめです。チーム内での余計な混乱を防げます。
機能テスト ○ MVPでは必要最小限の機能だけ実装されます。このため、その機能が正常に動作することは不可欠です。
データ互換性テスト – MVPにおいてデータファイルの互換性を重視しなければならない状況は稀です。
業務シナリオテスト ○ MVPで実施する業務については、その業務が定められたスコープで正しく実施できることの確認は必要です。
構成テスト ○ MVPの対象環境で実際にデプロイした上での確認は必要です。なぜなら、その状態でMVPユーザーに使ってもらうためです。
セキュリティテスト ○ 顧客の情報を漏洩させない、他者のデータを操作できないといった、最低限のセキュリティは担保する必要があります。守るべき情報資産を持たないようにMVPを設計することで、テスト負荷を抑えられます。
性能テスト – MVPで性能を求めることは稀です。
ストレステスト – MVPで最大負荷を定めることは稀です。
ボリュームテスト – 将来の負荷増分に対するテストは不要です。MVPはあくまで仮説を検証することが目的であるため、将来の負荷増加に対応する必要はありません。
ロングランテスト △ MVPは長期稼働はしませんが、MVPの期間が長い場合は実施を検討してください。
障害テスト △ MVPにおいて、可用性、運用・保守要件は最低限とします。このため、確認すべき観点は最小限になります。
運用シナリオテスト △ バックアップや監視等を行うのであれば、ある程度のテストを実施することになるでしょう。
移行テスト – MVPで移行が必要になることは稀です。
インフラ環境準備

プロトタイプ型MVPやオズの魔法使い型MVPでは、一般にアプリケーションをデプロイするためのインフラ環境が必要になります。我々は、このためにAWSを利用します。環境構築時には、AWSの環境準備時間を短縮可能なEponaの利用をご検討ください。

用意する環境として、開発環境やステージング環境、本番環境等が考えられますが、我々は開発環境と本番環境の2つにそれぞれ異なるAWSアカウントを準備する形を選択します。

アカウント分離

アカウント分離

このような構成をとる理由は以下の通りです。

  • アジリティを最重要視するため、環境数は最低限に保つべきである
  • 本番環境では個人情報等の情報資産が配置され得ることや、実ユーザーへの影響もあり得るため、アクセス可能な人員を制限する。アクセスを厳密に制限しようとすると、AWSアカウントごと分離することが最善である
各種準備

MVPの開発にあたり、ツールの準備や、社内で事前に済ますべき手続きを進めます。

例えば以下のようなものです。

準備内容 説明
VCSのリポジトリの準備 MVP用のソースコードか管理するためのリポジトリの構築やユーザー登録、権限設定を行います。構築やメンテナンスコストを省くため、GitLabを利用します。理由については、VCS Providerをご参照ください。
ライセンスが必要な開発ツールやライブラリを利用する場合のライセンス購入 開発ツールやライブラリのライセンスには日ごろから留意しておきましょう。
会議体(スクラムイベント)の設定 開発中にリズムを作ることは極めて重要です。事業オーナーやステークホルダーを巻き込み、定期的な会議体を設定してください。
ビジネスパートナーが利用する開発用PCの準備、入館申請 パートナー様の開発力を借りる場合は、パートナー様の力がしっかり発揮できるように開発環境(PC準備やリモートワークの手続き等)を行ってください

MVP開発

MVP開発では、仮説を検証できる最低限のMVPを作ることが求められます。一刻も早い市場投入が必要ですので、できるだけ無駄のない開発を心がけます。

ドメインの理解

前提として、新規事業には必ずユーザーが存在します。新規事業の目的はそのユーザーが抱える特定領域(ドメイン)の課題の解決です。
その課題を解決するためには、開発者が当該ドメインとユーザーの抱える課題を正確に理解することが必要です。
当該ドメインの概念や事象を理解し、そこから得られた知識をアプリケーションに反映しなければなりません。

新規事業開発チームにおいて、これを誰よりも理解しているはずなのは事業オーナーです。
開発者・プロダクトオーナーは事業オーナーと膝を突き合わせ、事業が対象とするドメインの用語、関係について正確に把握してください。
例えばチケット販売のシステムであれば、指定席や自由席の概念、ペア席と個人席、先着発売と抽選発売の違い、販売チャネルといった事項です。このようなドメイン知識がなければ、適切な開発などできるはずがありません。

アプリケーション設計

この時点で実際に開発する機能は多くないはずです。
その中でも本当に設計が必要な箇所のみ設計しましょう。設計が「本当に必要か」の判断基準は以下になります。

  • 現実的な期間でやり直しが可能か (不可逆な判断をする場合は、文書化しチーム内で適切な判断しているかを確認しましょう)
  • チーム内で共通認識をそろえておく必要があるか

設計が必要な具体例は以下となります。

設計 内容
ER設計 MVPでデータストアを利用する場合、テーブルおよびテーブル間の関連の設計(ER設計)が必要でしょう。ERモデルに変更が入ると、プロダクト全体に大きな影響が発生します。
方式設計 HTTPメソッドの使い分けやエラー処理、キャッシュの利用方法等、システム全体として整合性を取らなければならない箇所の設計を行います。
システム利用シーケンス設計 ユーザーがシステムを使い始め、課題を解決するまでのシーケンスを設計します。このような全体像を示す図がないと、全体最適なUXを提供できるMVPには至れません。

ただし、丁寧な文書化に拘るのではなく、MVP開発の目的が「仮説の検証」であることを忘れないでください。

インフラ設計

非機能要件に沿って最低限のリソースを利用した設計・構築をします。ただし、個人情報のような守るべき情報資産を保持する場合、その部分については一般的なインフラと同等のセキュリティを担保すべきです。特に以下のような点に注意します。

注意点 対応
インターネットを通過するデータが盗聴されないか 通信経路の暗号化
関係外の人間(等)がオブジェクトストレージやデータベースにアクセスできないか アクセスコントロールの適切な設計
個人情報などの機密情報が含まれるデータが盗まれた際、機密情報が漏洩しないか データの暗号化
実装

設計を元に、決定した開発プロセスと技術スタックに沿って開発を進めます。

テスト

MVPの開発においては、必要最小限のテストのみ行います。
何を以て「十分」とするかは、開発計画の時点でプロダクトオーナーと認識を合わせているため、迷うことはないでしょう。

ただし、テストを行って発生した問題や対応については、常にプロダクトオーナーと共有できる状態を作りましょう。
時間をかけてその問題を修正することが本当にMVPに資するのかは、それは個人だけではなくチームとして考える問題です。

テストコード

大規模ないし長期間メンテナンスをする必要があるプロダクトの開発時には多くの場合テストコードをきちんと書くことが求められます。しかし、MVPはできるだけ早期のリリースが必要であり、多くの場合は「使い捨て」になります。
このため、テストコードの記述は最低限に抑えましょう。むしろ、ほとんど書かないというくらいの気概が必要です。

テストコードを書く上で重要なのは費用対効果に見合うかです。
判断に迷う場合は、以下の資料を参考にするとよいでしょう。

受入テスト

もちろん、受入テストにおけるテスト観点も「仮説を検証できること」に絞ります。
テストを実施して、仮説検証に影響しない不具合が発見されても、あえて直さずそのままリリースするといった選択も検討します。

PoC・テストマーケティング・セールス

概要

PoC(概念検証)やテストマーケティング・セールスを実行するステップです。MVPが顧客に受け入れられるのか、適切に顧客に届けられるかどうかを検証でき、事業化にむけた改善点が明確になります。その一方で、実行手順や方法等の運営やオペレーションが拙いと、商品やサービスに対してもネガティブな印象を与えてしまう可能性があります。

実施手順

PoC・テストマーケティング・セールスは、一般的に以下の3つのステップで構成されます。

1. MVPをリリースする
  • 開発したMVPをリリースし、ターゲット顧客(被験者)が体験できる状態にします
2. ターゲット顧客(被験者)に対して連絡する
  • メールや電話、プレスリリース、広告などを使ってリリースの連絡をします
3. 顧客に体験してもらう
  • 策定したオペレーション計画に沿って運用します
  • システム部分を人力なオペレーションで代替している場合等では、顧客のアクションに合わせてインタラクティブな反応が必要なため、顧客のアクションに注意を払います
  • (必要に応じて)インタビューやアンケートを行います
  • 検証結果を整理します
    • 検証結果の分析に向けて、ターゲット顧客からのフィードバックやインタビュー/アンケートデータ、アクセスデータを整理します

コツ/注意点

ターゲット顧客に対して詳細な情報を与えすぎない

正確な検証結果を得るためには、被験者に自然な商品・サービス体験をしてもらうことが大切です。そのため、検証前に詳細な検証目的等を伝えるべきではなく、被験者が感じ取った率直な意見を得るようにしましょう。

セールスレポート分析・マーケ・セールス戦略精緻化

概要

PoC・テストマーケティング・セールスの結果を分析し、商品やサービス、マーケティング戦略やセールス戦略の磨き込みを行うステップです。
PoC・PoC・テストマーケティング・セールスをすると、想定していなかった顧客層から、意外な反応を得られることがありますし、仕様等の問題点が浮き彫りになることもあります。
仮説に執着せず、フィードバックを踏まえて顧客や訴求方法を磨き込むことが大切です。

実施手順

1. テストセールスの結果を顧客セグメント毎に整理する

セグメントの異なっているものを混ぜ込んで分析すると、傾向が見えなくなってしまいます。

例えば20代と40代とでは意見が異なる場合が多いでしょう。

そのため、分析を進める前に、セグメントをしっかりと分けて、セグメント毎に反応を分析できるよう準備を進めましょう。

2. KPIの達成度合いを確認する

検証前に設定したKPIが達成できているかを確認します。会員登録数(率)や受注数(率)等々、セグメント毎に分析し、商品・サービスが顧客の要件を満たしているか、その商品・サービスが顧客に求められているかを検証します。

3. 仮説と検証結果の間のギャップを洗い出す

検証前に立てた仮説が正しかったのかを確認します。ニーズを持っている人の割合や支払意向価格、使用頻度などに事前に閾値を設けて仮説が正しかったのかを判断します。仮説と異なっている場合はその原因を探ります。原因を検討する際、下記の観点を意識して考えてみましょう。

  • 「商品・サービス」は適切か
    • 必須の要件に漏れがないか
    • 離脱につながる不要な機能はないか
  • 「価格」は適切か
    • 顧客の支払許容金額範囲内か
  • 「プロモーション」は適切か
    • 適した顧客を集客できたか
    • CPA(顧客獲得コスト)が高すぎないか
  • 「チャネル」は適切か
    • 適した顧客を集客できたか
  • 「顧客」は適切か
    • 顧客は商品・サービスに価値を感じたか
    • 設定していた顧客以外で肯定的な反応をした顧客がいるか
4. ギャップを踏まえて、マーケティング戦略やセールス戦略を見直す

検証をすると様々なフィードバックが得られますが、全てを真に受けて商品・サービスに反映するべきではありません。
顧客にとってその要件が「絶対に必要」なのか、それとも「あれば良い」という程度のものなのかを明確にし、商品・サービスに反映するか判断しましょう。

  • 必須要件を満たした商品・サービスを再定義する
  • 最適価格を算出する
  • 顧客との接点を踏まえ、適したプロモーション方法を検討する
  • 顧客との接点を踏まえ、適したチャネルを検討する
  • 新たな顧客のペルソナを作成する
5. 次の検証計画を作成する

MVP自体の問題で、KPIを達成できなかった場合は、インタビューなどで得られたフィードバックを元に、MVPのブラッシュアップを行いましょう。
顧客設定や検証設計の問題であれば、顧客の定義やオペレーションを見直しましょう。

コツ/注意点

検証結果を客観的に判断し、検証を繰り返す

検証を進めていくほど、立てた仮説を棄却することに躊躇してしまいます。そのため、インタビューで得られた1つのポジティブな意見を全体の意見として解釈してしまうことがあります。
それを防ぐためには、事前に閾値を設けたり、定量的に判断できるよう質問を工夫する等、設計上の工夫が必要になります。
それと同時にSPFのフェーズにおいても仮説検証を何度も繰り返し、本当に良いものを創り上げるというマインドを持つことが大切です。

数字を使って改善効果をみる

改善点の洗い出しをするとき、目標値と実績値の比較やユーザーセグメントの数値を参考に、優先順位をつけてブラッシュアップを行います。

2回目の検証をする際も、改善前と改善後の数値を比較することで、改善効果を検証できます。
数字を使わずに感覚で判断してしまうと、本来変更すべきではない点を変更しかねないため、納得感を持って推進するためにも数字を使って管理/判断をしましょう。

  1. 田所雅之、『起業の科学-スタートアップサイエンス』、日経BP、2017。↩︎
  2. 「製造業の新製品開発プロセスにおけるMVP（Minimum Viable Product）の有効性の検証」↩︎
  3. 「製造業の新製品開発プロセスにおけるMVP（Minimum Viable Product）の有効性の検証」↩︎
  4. 「製造業の新製品開発プロセスにおけるMVP（Minimum Viable Product）の有効性の検証」↩︎
  5. Kenneth S. Rubin、『エッセンシャルスクラム』、翔泳社、2014。↩︎
  6. 「非機能要求グレード2018利用ガイド」より引用。↩︎
  7. 「非機能要求グレード2018利用ガイド」より引用。↩︎
  8. Jonathan Rasmusson、『アジャイルサムライ――達人開発者への道』、オーム社、2011。↩︎
  9. 我々は基本設計を外部設計、詳細設計を内部設計と呼ぶことが多いため、ソフトウェア開発データ白書の工程名から言い換えています。
    ↩︎
  10. Mitch Lacey、『スクラム現場ガイド　スクラムを始めてみたけどうまくいかない時に読む本』、マイナビ出版、2016。↩︎
  11. Mitch Lacey、『スクラム現場ガイド　スクラムを始めてみたけどうまくいかない時に読む本』、マイナビ出版、2016。↩︎