新規事業開発のためのステージ・ゲートプロセス

本ドキュメントでは、当社が新規事業を開発する際のベストプラクティスとなる開発プロセスを公開します。

はじめに

社会課題の複雑化、国内市場の成熟、事業ライフサイクル短期化を背景に、急速に進展するデジタル社会に対応するため、各社はこれまで以上のスピードで変化していく必要性に迫られています。 このような状況下で、自社単独、あるいは大企業同士や大企業とスタートアップ企業で新規事業開発を検討する企業が増えています。

以下、新規事業開発アプローチの6パターンより引用¹します。

新規事業開発アプローチの6パターン

新規事業開発は、本質的に不確実性と不透明性に満ちており、高速で仮説検証サイクルを繰り返しながら「学び」の量を最大化していくことが必要です。 このため、計画性と予測可能性が重視される大規模開発とは、全く異なるプロセスが求められます。

一方でそのプロセスについては、現時点でほとんど言語化がされていませんでした。 結果としてこれまでの新規事業開発の関係者は、誰もが悩み試行錯誤を繰り返しながら、毎回1からノウハウを積み重ねざるを得ない状態でした。また、誰が何をするのかといった相互理解すら得にくかったのが実態です。 そのような状況を打破すべく、新規事業開発のノウハウを得られる「知の高速道路」²を整備したいという思いで、本書を作成しました。

もちろん、現時点でこの本書の内容は「最適」ではないかもしれませんし、未実践のものも含まれています。 しかしここで記述したことを自分たちで実践・改善しながら、新規事業開発のベストプラクティスを本書へ逐次反映していきます。

本書の構成

本書の構成は、前半・後半に分けられます。

前半では、新規事業開発を進めるためのプロセス(ステージ・ゲートプロセス)や、開発全体を貫く考え方を記載しています。 後半では、個々のステージの具体的な進め方、コツや注意点、エンジニアリングについて記述しています。

前半部を読んで新規事業開発の考え方を掴んでいただき、その後、興味のあるステージ・担当する事業が位置するステージの章を読んでいただくのがお勧めです。

対象読者

本書は、新規事業開発に携わる方を対象としています。

特に、これまでいわゆるSI、受託開発を行って来た方にとって、新規事業開発はかなり異質に見える部分が多く、戸惑う部分が多いはずです。 本書では既に記載の通り、読者の方が我々の感じた戸惑いや悩みをスキップし、高速に新規事業開発のノウハウと相互理解を獲得していただくことを目指しています。

ステージ・ゲートプロセスとは

当社が新規事業開発に使用しているのは、「ステージ・ゲートプロセス」と呼ばれるプロセスです。

一般に、ステージ・ゲートプロセスは多産多死を前提に作られています。 プロセスを数段階の「ステージ」に区切り、ステージの間に「ゲート」を設け、そのゲートで事業アイデアをふるいにかけて絞り込んでいきます。 明確な基準を用い、ゲートで段階的に絞り込んでいくことで、以下のような投資の無駄を防ぎます³。

1. 基準が明示されていない結果として、事業化の出口が見えないまま滞留してしまう
2. 事業化目前になってから致命的な問題が発覚し、事業開発が中止に追い込まれる
3. フィージビリティスタディではある程度の市場が見込めたが、市場の環境が変わり、試作品はできても顧客が見つからなくなる

TISのステージ・ゲートプロセス

当社で用いているステージ・ゲートプロセス（以下、本プロセスという）は以下となります。

ステージ・ゲートプロセス

市場トレンドの変化への対応や「死の谷」⁴を回避するため、事業化の見極め期間は6ヵ月に設定しています。 この期間に、リーン・スタートアップ手法^5 6やデザイン思考を基に、アイデアのブラッシュアップから想定顧客像の構築、ニーズの仮説構築、プロトタイプ(試作品)を通じた検証、顧客に価値を提供できる最小限のプロダクト開発・実証実験を行います。 それぞれのフェーズにゲートを設け、有識者を巻き込んで次フェーズへ進むレベルに達しているかを審議することにより、事業化に向けた精度向上を図っています。

ここにはCPFやPSF等、さまざまな略語が登場しますが、これらはスタートアップのフェーズとして登場するものです。概要は以下の図をご参照ください⁷。

フェーズ

全ての創業チームに必要な力

創業チームに必要な力は以下の3つです。これは、『新規事業の実践論』⁸を参考にしています。

これらは新規事業開発の「チームとして」持っておくべきものです。 どれかに偏ってしまうと、新しい価値を生み社会実装をすることはできません。

新規事業開発の考え方

改めてステージ・ゲートプロセスの全体像と、個々のステージの流れを示すと以下のようになります。

ステージ・ゲートプロセス

ステージ・ゲートプロセスの2つの考え方

このステージ・ゲートプロセスに沿って行われる新規事業開発は、大きく以下の2つのフェーズに大別されます。

1. 事業仮説を構成する「顧客」「課題」「ソリューション」を”探索し検証”するフェーズ
2. 実際に事業を”ローンチさせ、ユニットエコノミクス⁹を健全化”するフェーズ

それぞれのフェーズの目的は明確に異なります。 そして目的が異なる以上、それぞれのフェーズに対し、異なるアプローチ・異なるエンジニアリングが必要になります。 例えば「事業仮説の探索と検証」フェーズにて構築したMVPを「ローンチとユニットエコノミクスの健全化」フェーズには持ち越すことを前提として考えてしまうと、 前者のフェーズのスピードが上がりません。両フェーズは明確に切り分けましょう。

事業仮説の探索と検証

このフェーズで必要なのは、仮説検証サイクルの高速化です。 これは新規事業開発チームの思い込み・検証されない仮説の下で大きなコストを投入し市場に求められない製品を作ってしまわないよう、細かく仮説を設定・検証し、進むべき道を探索していく必要があるためです。

このフェーズでは、事業仮説を構成する以下の仮説を構築し、検証しなければなりません。

• 「顧客」は誰か
• お金を払ってでも解決したい「課題」は何か
• 課題を解決できる「ソリューション」は何か
• ソリューションは製品として実現できるのか

仮説検証によって、これらの問いへの確度と解像度を高めていかねばなりません。 そしてMVPにより、確かに顧客が存在し、ソリューションによって課題が解決され、お金を支払ってもらえることを検証します。

これらの検証は、仮説を形にし、顧客のところに持っていき、顧客の反応に応じて仮説を修正するというサイクルをひたすら回すことによってのみ行えます。 有限の時間とコストの中で、不確実性を下げ、プロダクトの解像度を上げていくために、事業オーナー・エンジニア・デザイナーはこの仮説検証サイクルをどうすれば高速に回せるのかを真剣に考える必要があります。 まず全員が最初に考えるべきなのは、「いかに作らず、いかに高速に検証するか¹⁰」でしょう。

仮説検証サイクル

『新規事業の実践論』¹¹では、「仮説を顧客のところに持っていく」回数として300回が必要だとされています。このフェーズに半年をかけるとすると、1営業日2.5周が必要になる計算です。

ローンチとユニットエコノミクスの健全化

このフェーズで必要なのは、事業の迅速なローンチと、顧客を観察した上での素早い改善の積み重ねです。

本フェーズに至ったということは、課題を持った顧客が確かに存在しており、私たちのソリューションによってその課題を解決でき、お金を支払ってもらえることがわかったという状態にいます。 つまり、MVPのような「実験」をするプロジェクトではなくなり、ビジネスとして収益を追い求める¹²フェーズになります。

このフェーズにおいては、課題を解決するソリューションは定まっています。 従って、事業計画を作成してビジネスとして成立することを確認し、まずはサービスを早期にローンチすること、そしてその後はユニットエコノミクスを健全化することがPMFへ至る道です。

ユニットエコノミクスとは、顧客1人あたりの採算性を示す指標のことです。具体的には、顧客1人あたりの生涯価値(LTV)と顧客獲得コスト(CAC)の差で定義されます。 『新規事業の実践論』¹³では、それぞれのメトリクスを以下のように定義しています。

ユニットエコノミクス

ユニットエコノミクスの成立に向けて「LTV ＞ CAC」の構造を作る(『イノベーションの再現性を高める 新規事業開発マネジメント──不確実性をコントロールする戦略・組織・実行』¹⁴より)

「LTV > CAC」ならば顧客が増えれば増えるほど利益が積み重なる構造になるため、顧客数拡大に邁進すれば良くなり、ユニットエコノミクスは健全といえます。従って、この状況に達するためには、LTVを高め、CACを下げなければなりません。

LTVを高めるには、事業から「お金を払ってよかった」いう体験を作り出すことが重要です。そしてそのためには、提供するサービス上での顧客の行動を観察した上で、顧客価値を向上させる仮説を立て、改善・改良を短いサイクルで積み重ねることが必要です。

新規事業開発のエンジニアリング

我々は、本書における「エンジニアリング」を以下のように定義しています¹⁵。

• Boost new business with technology (技術で新規事業開発をBoostする)

この定義に従い、新規事業開発のエンジニアリングについて以下にまとめています。

なお、先のステージ・ゲートプロセスにマッピングすると以下のような形となります。

ステージ・ゲートプロセスのエンジニアリング

2つのフェーズの考え方

不確実性の海の中を泳いでいく新規事業開発のエンジニアリングでは、検証された学び (Validated Learning)を積み重ねていくことになります。 限りある時間と予算の中で多くの仮説検証サイクルを回さなければ、学びを得られないまま、ユーザーの求めないものを作り続けてしまうことにもなりかねません。

繰り返しになりますが、私たちは、新規事業開発が大きく以下の2つのフェーズに大別されると考えています。

1. 事業仮説を構成する「顧客」「課題」「ソリューション」を”探索し検証”するフェーズ
2. 実際に事業を”ローンチさせ、ユニットエコノミクスを健全化”するフェーズ

それぞれのフェーズの目的は明確に異なるため、異なるエンジニアリングが必要になります。

事業仮説の探索と検証

このフェーズで行うことを一言で表現すると、「事業の進むべき方向を決める」です。

「顧客」「課題」「ソリューション」 仮説検証によってこれらの問いへの確度と解像度を高めていかねばなりません。そして、MVPによって確かに顧客が存在し、ソリューションによって課題が解決され、お金を支払ってもらえることを検証します。 これらの検証は、仮説を形にし、顧客のところに持っていき、顧客の反応に応じて仮説を修正…というサイクルをひたすら回すことによってのみ行えます。有限の時間とコストの中で、不確実性を下げ、プロダクトの解像度を上げていくためには、この仮説検証サイクルを高速に回す必要があります。

私たちの行うエンジニアリングも、この高速な仮説検証サイクルを支えていかなければなりません。 つまり、「如何にして顧客のフィードバックを得られるアウトプットを素早く作り上げるか」が求められます。

また、顧客からフィードバックを得ることによって、顧客課題を解決するソリューションはどんどん変わっていきます。したがって、このフェーズのエンジニアリングには以下の事柄が求められます。

エンジニアリングに求められるもの

このようなエンジニアリングを行うためには、エンジニアには「作る」だけでなく、「使う」ための知識も必要でしょう。

• アイデアを受けて、顧客の反応を得られる形にアウトプットする力 (プロトタイピング力)
• 特定の機能を提供してくれる外部サービスやOSSプロダクトの理解とその選択のための審美眼
• それらサービスを利用するための技術的知識、ライセンスの知識
• インフラを所有することなくサービスを構築できるクラウドアーキテクティング力、実装力

本フェーズではこれらを総動員し、仮説検証のためのプロダクトを素早く形にしなければなりません。 試行錯誤を繰り返し、作るものも頻繁に変わる中でのエンジニアリングが前提となるため、多くの場合は作り直しを余儀なくされます。このため、「保守性 (Maintenability)」は切り捨てても構わないと考えています。

ローンチとユニットエコノミクスの健全化

MVPのような「実験」をするプロジェクトではなくなり、ビジネスとして収益を追い求めるフェーズです。 この後にエンジニアが行わなければならないことは、以下になるでしょう。

1. 事業(サービス)を素早く市場に展開するための高速なサービス開発の計画と実行
2. サービスのブラッシュアップと、フィードバックに基づく迅速な機能追加やUX改善
3. 顧客数の拡大に耐えられるようなサービスのスケーリング

このフェーズにおいては、課題を解決するソリューションは定まっています。 従って、まずはサービスを早期にローンチすること、そしてその後も迅速な改善を繰り返していくことがエンジニアリングには求められます。 これを言い換えると、本フェーズには新規開発・修正開発の開発生産性の向上を追求するエンジニアリングが必要です。

このエンジニアリングは、受託開発、保守開発等、SIerがこれまで行ってきたエンジニアリングでも求められてきたものであり、Fintanに公開された様々なノウハウを活用できます。

本書で扱う技術

我々は多様化する技術の中から、適切な技術を選定しなければなりません。 新規事業開発のエンジニアリングにおいて、使用すべき技術は何でしょうか。 我々は以下の技術スタックを選定しました。

アーキテクチャ

新規事業開発においては、ユーザー数やトラフィック量が予測し難いものです。 このため、基本的には「使われた分」だけ課金されるようなアーキテクチャが望ましいでしょう。

事業アイデアが技術的な制約を課さない場合、我々はSPA+REST APIでのサーバーレスアーキテクチャを基本に考えています。 もちろん事業ごとに細部は異なるでしょうが、AWS上で実現するときは以下のようなアーキテクチャ¹⁶になるでしょう。

REST APIを提供するバックエンドを含めサーバーレスアーキテクチャを前提とすると「使われた分」だけ費用が生じる形のアーキテクチャが実現できます。 一方で、API仕様が複雑になりそうなら、Amazon ECS (ECS)を利用してAPIを構築します。

基本アーキテクチャ

プロトタイピング

プロトタイピングツールについてはFigmaを利用します。

クラウドインフラ

上記のアーキテクチャ図からもわかるように、我々の新規事業開発ではクラウドサービスとしてAWSを利用します。 また、Infrastructure as Code (IAC)のツールとしてはTerraformを使用します。 これは、習熟している開発者が多いことと、DevOps環境構築キット Eponaで両者をサポートしているためです。

言語

言語としては、型の存在による生産性の向上と安全性の確保のため、JavaとTypeScriptを選択しました。

フレームワーク

VCS Provider

VCS Providerとしては、GitLabを使用します。

技術の選定基準

なぜ上記のような技術スタックを選定するに至ったのかは、以下の3つの基準に依ります。

• 利用する技術の数を少なくすべき
• 作らないエンジニアリングを支援できる
• インフラを所有しない

利用する技術の数

さまざまな分野の事業開発に取り組みながら組織学習をしようと思うと、扱う技術の数は少数に抑えるべきです。これにより、特定技術に関する知識を、組織の中で共有・応用できるようになります。 例えばプログラミング言語などはその良い例で、新規事業開発に取り組む組織の中でよく使われている言語を選択すると、組織から技術的なサポートも得られやすくなります。

また、本章の冒頭で述べたように新規事業開発では2つのフェーズがあり、それぞれで求められるエンジニアリングが異なります。 その異なるエンジニアリングにおいても技術は「使いまわせる」方が学習効率も良いでしょう。

2種類のエンジニアリング

作らないエンジニアリングを支援できる

事業には、競争力のコアとなる箇所と、競争力のコアではないが事業を成立させるために必要な箇所があります。 「競争力のコアとなる箇所」は、市場競争にさらされながら生き残っていくために頻繁な改善が必要となる一方で、 「競争力のコアとならない箇所」は変化することも少ないでしょう。そして、このような「コアとならない箇所」には、利用できる外部サービスやOSSプロダクトが多くあります。 例えば、モニタリングSaaSであるDatadogやNew Relic、カスタマーサポート用SaaSであるZendeskなどはその一例でしょう。

変化することが少ない「競争力のコアとならない箇所」まで自分達で開発してしまうと、莫大な費用が必要になります。そのような不要な開発コストを避け「専門家」の構築したサービス品質を得るためには、それらを自分達で「作らず」、サービスを「つなぐ」ためのテクノロジーが必要になります。

つまり、「業界で多く使われているSaaSやOSS」を使うのに適したテクノロジーを選択すべきということになるでしょう。例えばSaaSがSDKを提供しているのであれば、そのSDKを利用できる言語を使う、といったことが考えられます。

インフラを所有しない

新規事業開発では仮説検証を繰り返すことになります。 その際、多くの場合においては、サーバーやネットワークが必要になるでしょう。 しかし、それらを所有していたのでは、大きな初期投資が必要になるとともに、その維持管理にも多大なコストが必要になります。

このため、いかにして「所有せずに済む」エンジニアリングを完徹できるかという点も重要になります。

その代表的な例がAmazon Web Services (AWS)や Microsoft Azure (Azure)といったクラウドサービスの利用です。 クラウドサービスは、必要な時に必要なだけリソースを作成でき、破棄することも簡単です。

クラウドサービスには様々なアーキテクチャがありますが、その中でも注目したいのがサーバーレスアーキテクチャです。 実際にサーバーを用意する必要はなく、クラウド事業者が用意した環境上にユーザーがソースコードを配置することでアプリケーションを運用できます。 サーバーレスアーキテクチャの場合、アプリケーションが実行されている時間での課金になりますので、例えばWebアプリケーションでしたら、アクセスがあった時にだけアプリケーションの実行時間に応じて課金されます。アクセスがない時間は課金されません。 アプリケーションの規模にもよりますが、ユーザー数の読めない段階では多くの場合メリットを享受できるでしょう。常時起動が必要なサーバーと比べて費用がかからない上、サーバーOSの管理といった作業からも解放されます。

企画立案ステージ

企画立案とは、「誰」のどのような「課題」をどのように「解決」するのか、といった事業アイデアの骨子を検討するフェーズです。 事業アイデアを具体化し、課題が本当に存在するか、解決策が適切かを検証するための準備します。

企画検討

概要

「誰」のどのような「課題」をどうやって「解決」するのかを考えるアイディエーションのステップです。

「アイデア」を発想する手法は一見ブラックボックス(≒センス)のように感じるかもしれませんが、いくつか体系化された手法があります。また、新規事業開発の目的や前提条件(目標売上高や目標時間等)によって、適した手法が異なります。

ここでは質の高いアイデアを生み出すための手法や検討ステップ、注意点をご紹介します。

実施手順

1. 新規事業開発の目的や前提条件を押さえる

新規事業を検討するとき、「自由に発想してください」と言われるとなかなかアイデアを出しづらいと思います。では、次のような前提情報があればいかがでしょうか？

• 「自社が持つ技術を活用した事業を考えてください」
• 「これまでと違い一般消費者向けの事業を考えてください」
• 「5年後に売上高10億円達成できる事業を考えてください」

何も制約がないときと比べると、アイデアに求められる要件が明らかになり、アイディエーションがスムーズに進むようになると思います。このように、アイディエーションを始める前に、新規事業開発の「目的」と「前提条件」を押さえておきましょう。

もしも前提条件が何も決まっていない場合や、自分で決める必要がある場合、「顧客」や「ビジネスモデル」「成長モデル」「活用する技術」など、身近で考えやすい観点を用いて、ご自身の中で前提条件を作ることをお勧めします。ただし、前提条件を決めないままアイディエーションをする方が考えやすい方もいるため、前提条件は必須ではありません。

前提条件を検討する場合、ポイントは以下の通りです。

• 新規事業開発の目的を仮置きする
  • 新たな顧客獲得による収益拡大
  • 成長速度の改革
  • 既存顧客の更なる満足度向上
  • 破壊的イノベーションの対策　等
• 目的を達成するための条件を検討
  • 例えば、目的が成長速度の革新であれば、指数関数的な成長を目指し、プラットフォーム型のビジネスを前提条件としたりできます

2. 適したアイディエーションの手法を選択する

1で確認した条件などを踏まえて、アイディエーションの手法を選択しましょう。ここでは4つの手法をご紹介します。注意点として、手法は1つに限定する必要はなく、並列で利用されることもあります。大切なのは手法に囚われすぎず、まずはアイデアを沢山出してみることです。

• マーケットドリブン
  • 市場や顧客が今抱えている課題から考える手法
  • 新規事業を通じて、幸せにしたい顧客や課題が抽象的でも決まっている場合はこの手法が適切
• アセットドリブン
  • 自社の経営資源や強みで生み出せる提供価値や解決策から考える手法
  • 新規事業で活用したい自社アセットや他社アセットがある場合はこの手法が適切
• ビジョンドリブン
  • 自社が目指したい姿を実現するための提供価値や解決策から考える手法
  • 新規事業を通して、自社のなりたい姿/あるべき姿を実現することを目的としている場合はこの手法が適切
• ミッションドリブン
  • 社会や顧客が目指すべき姿との差分や今後抱えるであろう課題から考える手法
  • 新規事業を通して、社会の変化やそのリスクに対応することを目的としている場合はこの手法が適切

3. 選択した手法に応じた検討の進め方を実施する

4つのアイディエーション手法の最初の着眼点をご紹介します。 ただ、どのアイディエーション手法であっても、「どんな課題を解決するのか」「なぜ課題が生まれるのか」を検討し、「本当にその課題は(将来的に)存在するのか」を検証していきます。 アセットドリブンやビジョンドリブンで生み出したアイデアであっても、解決すべき課題は存在し、その解決方法は沢山存在するため、まずは課題の検証から着手することになります。

• マーケットドリブン
  • 日頃相対している人や前提条件となっている顧客が何に困っているか考えてみる
• アセットドリブン
  • 自社の経営資源や強みを起点に、世の中の不満を解決できないか考えてみる
• ビジョンドリブン
  • 自社のなりたい姿や実現したい世界を考えてみる
• ミッションドリブン
  • 社会の変化に伴って発生しそうな課題を考えてみる

4. 良いアイデアを選ぶ

アイディエーションで考え出した全てのアイデアをリーンキャンバスで整理することは現実的ではないと思います。そのため、多くのアイデアの中から検討を進めるものを選ぶ際には、「課題」または「解決策」に独自性があるアイデアを選ぶと良いでしょう。

社会や技術の変化に伴って、人々の悩みや価値観も大きく変わります。例えば、新型コロナウィルスによって、「接触」や「密」に関する課題や解決策が続々と出てきました。このように、まだ潜在的かつ有望な課題やニーズをいち早く捉えることがポイントです。

企画検討

5. 簡易リサーチを実施し、アイデアに「根拠」を持たせる

上記のアイディエーション手法にはいくつかの種類がありますが、すべての手法に共通しているポイントがあります。それは、どの手法を採用してもアイデアの骨子となる「顧客」「課題」「解決策」の確からしさを客観的な視点で検証するという点です。初期構想の段階であっても、客観的な「根拠」があるのとないのとでは説得力が全く異なります。

アセットドリブンやビジョンドリブンのような内発的な発想手法であっても、アセットの競争優位性やビジョンの実現性は、市場動向や競合情報をリサーチしなければ、確からしさは評価できません。初期段階ではデスクリサーチや身近な人へのヒアリングを通じて、客観的な根拠を集めましょう。

6. リーンキャンバスにアイデアを記入し、言語化にチャレンジする

リーンキャンバスに含まれる9つのポイントの検討を進め、事業アイデアを整理・深掘りしていきます。まずは、下記の1〜9を固め、事業アイデアの骨子を作りましょう。

1. 課題：どんな課題や困りごとを解決するか
2. 顧客：誰を幸せにしたいか
3. 独自の提供価値：どんな価値を提供するのか
4. 解決策：提供価値を実現する具体的な機能やサービスは何か
5. 顧客獲得チャネル：どうやって顧客にリーチするか
6. 収益の流れ：どうやって収益をあげるか
7. コスト構造：どんなコストがいくらかかるのか
8. 主要指標：どの指標をKPIとして計測するか
9. 圧倒的な優位性：優位性はどこにあるか

7. 市場規模を概算し、ビジネスモデルやスキームから収益性を検討する

顧客や解決する課題、解決方法がリーンキャンバスの整理によってある程度固まれば、市場規模と収益性を検討します。市場規模や収益性の検討方法は以下の通りです。

• 市場規模を検討する
  • レポートを活用する
    「顧客」と「課題」「解決策」を元に、デスクリサーチでキーワードを打ち込み、官公庁や業界団体、企業が公表している市場規模の調査レポートを探す
  • 算出する
    レポートが見つからない場合は、市場において商品やサービスを購入する消費者の数や平均単価などをもとに市場規模を算出する
    例）子供・高齢者向け屋外見守り・防犯関連サービスの市場規模：884億円
    • 顧客数：ニーズがある子供の数＋ニーズがある高齢者の数
      • 「子供の防犯のために取り組みたいこと」 GPSを使った所在地の確認：45.4%
        5歳~14歳人口(2021.9)：約1,040万人
      • 「介護と仕事を両立する上であると良いもの」 情報通信機器を活用した認知症の徘徊高齢者の探索システム：23.5%
        2020年の65歳以上の高齢者の認知症有病率は16.7％
        65歳以上人口(2021.9)：約3,620万人
    • 単価：競合製品
      • ココセコム：年間14,400円
  • 収益性を検討する
    • ビジネスモデルやスキームを検討する
      • 誰から何をどうやってもらうか
      • 誰に何をどうやって渡すか
    • リーンキャンバスの「収益の流れ」と「コスト構造」を踏まえて、販売価格に対して、自社の取り分がいくらになるのかを検討する
      • 自社が顧客からお金を直接得る場合、原価や販管費を概算し、事業の収益性を算出する

コツ/注意点

とにかく「顧客」と「課題」を深堀りする

企画立案の段階でよくある失敗例として、解決策の内容だけが充実していたり、収支を精緻に出すことにこだわりすぎて時間を費やしてしまうことがあります。

解決策の仕様やその優位性の検討にばかり時間をかけてしまうと、実はとても市場が小さかったり、顧客が求めている要件に対して、オーバースペックだったことが後になって分かってしまいます。そのような事態になるのを防ぐため、課題を生じさせている構造や課題の大きさを理解することを優先しましょう。

チームビルディング

概要

事業企画を推進するチームに必要なスキルセットを整理し、チームビルディングしていくステップです。

事業化するプロジェクトには2つの共通点があります。1つ目は事業アイデア自体のクオリティです。2つ目は推進者の能力と熱意です。どちらか一方でも欠けると事業は失敗に終わってしまう可能性が高いです。ここでは推進者の能力と熱意に着目し、求められる要件の策定方法や注意点をご紹介します。

実施手順

1. 必要な役割を整理する

新規事業開発プロジェクトを推進する際に求められる役割の例を以下の表に整理しました。新規事業開発では少人数のメンバーで推進をすることが多く、プロダクトマネージャーがリサーチャーの役割も担ったり、非エンジニアがノーコードツールを活用し、プロトタイプを開発する等、役割横断的に推進するケースが多くあります。

新規事業開発はリスクを小さくすることが大切であり、他に活動予算を使うためにも、メンバーは必要最小限とし、積極的な役割横断をしましょう。

役割整理

2. プロジェクト推進に求められるスキルを整理する

次に、前のアクティビティ「企画検討」の内容を踏まえて、プロジェクトを推進するうえで、必要なスキルを定義します。ただし、事業アイデアとは直接関係のないようなスキルを挙げる必要はありません。確認するスキルを検討するため、まずは観点の整理から着手すると良いでしょう。以下はスキルの観点例です。観点が整理できれば、具体的なスキルを挙げていきましょう。

• 事業開発スキル
  • 事業企画スキル
  • 仮説検証/PDCA
  • マーケティング
  • 営業
  • プロダクト開発
  • プロジェクトマネジメント　等
• ビジネス知識全般
  • 事業戦略策定
  • 会計
  • ファイナンス
  • 法務
  • 業種・業界知識
  • テクノロジー知識　等
• ビジネススキル全般
  • 資料作成
  • プレゼンテーション
  • ファシリテーション　等

3. スキルをMUST要件/WANT要件に分ける

2で整理したスキルをプロジェクトの推進に「必須なもの(MUST要件)」と「あれば嬉しい(WANT要件)」スキルに分けることができます。 1で検討した役割毎に、そのスキルがMUST要件かWANT要件かを整理しましょう。 このとき、MUST要件に該当するスキルに漏れがないか、改めて確認します。

4. 評価の基準を策定する

スキル評価にむけて、評価基準を事前に検討しておきます。以下は評価基準の一例です。

評価基準

5. 審査後、整理したスキル要件を元に、メンバーをアサインし、スキルマップの自己評価を行う

事業アイデアの検討が審査会で承認された後、整理したスキル要件を踏まえて、メンバーをアサインし、スキルの自己評価をします。

6. 人材が不足している場合はメンバーの追加を検討

推進に必須なスキルが不足している場合、メンバーを見直すか、不足しているスキルを持った追加のメンバーのアサインを検討します。 ただ、すでに述べている通り、本当にそのスキルが必要なのか、そのスキルを補う代替手段がないかどうかをしっかりと検討し判断しましょう。

• MUST要件にも関わらず、評価が△以下であれば、メンバー変更検討
• WANT要件が誰も満たせていない場合、メンバー追加検討

実際のメンバー追加に際しては企画審査のタイミングで不足ロール、スキルセットについて報告の上、 メンバーアサインの打診をして下さい。

以下の表はスキル評価のフォーマットの一例です。

フォーマット

コツ/注意点

メンバーは少数精鋭で奇数が望ましい

人数が多いとコストが増えてしまい、事業のリスクになりますし、意思決定が遅くなってしまいます。一方で、事業内容を検討する際に視野が狭くなり、独りよがりになってしまう可能性があるため、企画立案のステップ以外は、1人で推進するのは避けましょう。また、意思決定をスムーズに行うためには、チームメンバー数を奇数とし、どちらの意見の方が優勢かはっきりさせましょう。

コスト計画(SPFまで)

概要

SPFまでの活動に必要なコストを洗い出すステップです。

実施手順

1. SPFまでの活動内容を簡潔に整理する

ここまでのアクティビティ「企画検討」と、以下の図で記載している活動ステップ毎のゴールや検討事項を踏まえ、どのような活動をするのか簡潔に整理しましょう。

• 調査：インタビューやアンケートの実施、業界レポートの入手等
• 開発：プロトタイプやMVP開発、デザインの制作等
• 広告：検証時に出稿する広告やデザインの制作等
• 解析：商品・サービスへのアクセス解析やアンケートの分析

フォーマット例

2. SPFまでの活動コストを計算する

1で整理した活動にかかるコストを算出します。検証方法等を具体化することで、コストを計算しやすくなります。コストを試算するうえで、押さえておきたい観点は以下の通りです。

• 調査
  • 対象者
  • 人数
  • 回数
  • 調査方法
  • 活用するサービスや製品
• 開発
  • 開発・デザインするもの
  • 活用するサービスや製品
• 広告
  • 広告期間
  • 広告の種類
  • デザインするもの
  • 目標CVから逆算した費用
• 解析
  • 活用するサービスや製品
  • 実施期間

外部サービスや製品を活用する場合、サービスページの料金体系を確認したり、問い合わせすることで料金を調べましょう。

システム開発やデザイン制作、その他自社で工数を投入して活動を進める場合、「チームビルディング」で検討したメンバーの特性/スキルと工数を踏まえて、人件費を概算することでコストを割り出しましょう。

下記にコスト計画のフォーマット例を記載しているので、参考にしてください。

フォーマット例

コツ/注意点

コストを考えること自体に意味がある

企画立案の段階で、活動コストを検討し決裁者の承認を得ておくことで、活動の途中でプロジェクトが予算上の理由で頓挫してしまうリスクを下げることができます。 また、コストを下げる打ち手(既存プロダクトと組み合わせる等)を考えることで、優先して検証すべきポイントの整理につながります。

正確さを求めすぎない

企画立案の段階では、活用するツールなども定まっておらず、活動を進めていくうちに変更することが多々あります。既に述べた通り、初期段階で活動コストを検討すること自体に意味があるため、大きな費用に抜け漏れがないかに注意し、スピード重視でコスト計画を作成しましょう。

課題検証(CPF)ステージ

CPFとは、Customer Problem Fitの略で、顧客が課題を持っているかを検証するフェーズです。

顧客が持つ、まだ解決されていない課題（仮説）の言語化と精緻化を行います。

顧客定義

概要

事業にお金を払ってくれる人=顧客を設定するステップです。 ここまでのアクティビティ「企画検討」の内容をさらに具体的な顧客像（=ペルソナ）に落とし込むことで、その人の生活がイメージしやすくなり、抱えている困り事や問題点を発見しやすくなります。

実施手順

1. 「一人の人物」を想定して、そのプロフィールを、趣味や嗜好、価値観や行動パターンまで、かなり詳細に設定していく

あくまで、以下の内容は一例です。

• 基本情報（名前/年齢/性別/最終学歴/居住地　など）
• 何をしている人か（学生/勤務先・職業/主婦/パート　など）
• 生活様式（何時に勤務・退社か/インドア派かアウトドア派か　など）
• 性格
• コミュニティ（家族・配偶者・恋人の有無/友達は浅く広くか　など）
• 収入・金銭感覚（すぐ使ってしまうのか・貯蓄をするタイプか　など）
• 趣味
• 流行への感度（新しいプロダクトをすぐ使用するのか・情報をこまめに得るタイプなのか　など）

2. 企業向けアイデアの場合は、「企業」と「企業の担当者」の2つのペルソナを合わせた形式になる

• 企業の情報（会社名/会社の規模/業種/会社の課題　など）
• 担当者の情報（名前年齢/性別/所属部門/役職/決裁権の有無/対象業務年数　など）
• 部門の情報（体制/業務内容）

3. 上記で顧客が定義できたら、どのくらいの数がいそうなのかを確認する

• toCの場合は、e-statなどで検討した顧客がいそうかを調べてみましょう
• toBの場合は、Baseconnectが良いでしょう

コツ/注意点

初期顧客として考えてみる

事業が拡大したときの顧客を考えると、複雑かつ多方面の検討が必要になるので、まずは最初に自分の考えたサービスを買ってくれる人を想像すると、迷いがなくなり書きやすくなります。

ペルソナに優先順位をつける

元々のターゲット戦略が広く、複数のペルソナが考えられる場合は、この段階で簡易的なペルソナをいくつか作っておくことをおすすめします。そうすることで、後々どの候補を深く作り込んでいくか、優先順位をつけやすくなります。

本当に存在するか、客観的に振り返る

存在しない人物/企業を設定しないよう、きちんと存在するかどうか客観的に判断してみてください。

想定する課題の保有状況に差分が生まれそうな”軸”を複数検討する

軸により切り分けられたそれぞれが「セグメント」で、検証では「セグメント間の比較」を行います。顧客をセグメントすることで、顧客を分解でき、課題の具体性も上がります。

• セグメント例
  • toCの場合
    • 年齢
    • 性別
    • 居住地
    • 世帯構成
    • 職業
    • 年収
    • ITリテラシー
    • 興味・関心
    • 競合・代替品の利用状況
  • toBの場合
    • 上場 / 非上場
    • 事業規模
    • 従業員数
    • 業種・業界
    • 人材の流動性
    • サプライチェーンにおける立ち位置

セグメント

課題仮説定義

概要

前のアクティビティ「顧客定義」で検討した顧客の課題（=お金を払ってでも解決したいこと）を深掘りするステップです。
表面的な課題で満足せず、その発生要因まで深掘りをすることで、解決しなければならない課題を特定できます。

実施手順

1. 様々な観点で掘り下げ、構造化する

観点はいろいろ挙げられますが、ここでは5つ紹介します。

• 具体性：具体的には何が課題なのか
• 場面：どのような場面で発生している課題なのか
• 発生要因：なぜそのような課題が発生しているのか
• 未解決要因：なぜ既存の製品やサービスでは解決していないのか
• 代替策：現状はその課題に対してどのように対処しようとしているのか

2. 発生要因を掘り下げる

1で出した課題を分解して掘り下げていくと、最初の課題を発生させている要因が出てくるはずです。この要因、すなわちお金を払ってでも解決したい課題を見つけることが重要です。

コツ/注意点

発生要因を突き詰めるためには「Why?」を問い続ける

課題を深掘りする際に、「なぜその課題が存在するのか」と自分に対して問いかけることで、要因を特定しやすくなります。あくまで目安ですが、大体3-5回程度繰り返すと、これ以上深掘りができなくなります。

課題の深堀りが不足すると…

解決すべき課題を特定できていない状態ということになるので、この後検討していく解決策が見当違いのものになってしまいます。

顧客インタビュー(CPF)

概要

顧客が抱える「お金を払ってでも解決したい課題」かどうか、インタビューを通じて理解するステップです。

ここまでのアクティビティ「顧客定義」「課題仮説定義」を通じて検討した顧客の課題を、顧客の声を通じて検証することで、取り組む意義や構築すべき解決策の解像度が高まります。

実施手順

顧客の課題を理解するまでの流れは以下になります。

1. 顧客/課題を整理する

まずは、顧客や課題を整理します。

2. インタビュー相手をリクルーティングする

• 一般的には、5人（社）程度にインタビューすればある程度の傾向が分かるといわれているので、これを目安としてください。 3人（社）程度でも多くの発見が得られる場合もあるので、どの程度スピード感を重視するかで最終的な人数を決めましょう。 ただし、顧客インタビューに慣れていない人であれば、設定したペルソナと実際にインタビューした人との乖離も起きがちです。 その場合は、10人（社）程度に増える可能性がありますが、しっかりとペルソナに近い人を見極めていきましょう
• インタビュー相手の探し方は、「パネル会社（例：ビザスク、Spreadyなど）に依頼」「人脈を使う」の2種類に大別されます
• もし上記で見つけられない場合は、「SNS経由での募集（拡散を含む）」、「想定顧客が集まるコミュニティ（例：FBコミュニティなど）での告知」、「想定顧客が集まるSNSアカウント（例：インスタグラマーのフォロワーなど）からDM経由で連絡」「LinkedInやFacebookのDM経由で連絡（著名人など、その人物像がよく分かっておりかつ想定顧客と一致する場合）」「ネットに記載してあるメールから問合せ/飛び込み電話（企業ヒアリングの場合）」などで実施してみましょう

3. インタビューの準備をする

• インタビューが集まった後の得たい結果を明確にします
• 得たい結果を明確にしてから、逆算して必要なインタビュー項目を列挙します。（必要十分な項目を意識する）
  • 課題を特定するために、代替手段を把握しましょう。具体的には、「今までに解決しようとしたか」「それはどの様な方法か」「どれくらいの費用をかけているか」「それらの代替手段の何が問題か」「それらの代替手段より優れた解決策があれば乗り換えたいか」の視点で質問してみましょう
• 出てきた質問をまとめましょう（出てきた質問の中から「似ている質問内容」を大項目としてグルーピングする）
• 質問の想定時間と優先度（高/中/低）を記載しましょう
• 優先度「高」の項目のみでバッファ（約10分）込みの想定時間に収まっているか確認しましょう
• インタビュー相手が回答しやすい順番に各項目の質問順序を決めましょう

4. インタビューを実施する

インタビューを実施します。

5. インタビュー結果をまとめる

• インタビュー結果を元にインタビュー項目をブラッシュアップしましょう
  • 複数回のインタビューを重ねていく上で、質問の内容が伝わりにくいと感じた場合はチューニングしましょう
  • インタビュー先の個人（企業）によって回答の変わらない質問項目が見えた場合は、優先度を下げて他の質問項目の優先度を上げましょう
  • 元々の仮説と回答内容が異なることが多い場合、必要に応じて質問項目を更新しましょう
• インタビュー結果を記載しましょう
  • 個人（企業）ごとにインタビュー結果が共通していることと、共通していないことを抽象化して、明確にしましょう
  • 共通していないことの理由を元に顧客セグメントを分割しましょう
  • 対象者一人の個人的な回答内容だとしても貴重な示唆になる可能性があるため、特記事項として残します

コツ/注意点

質問はオープン型で

Yes/Noで回答を求めるクローズド型ではなく、相手が自由に意見を発言できるオープン型の質問にすることで、質問攻めをしなくとも相手から課題に関するストーリーを引き出すことが可能になります。「昨日の旅行はどうでしたか？」「このお菓子についてどう思いますか？」のように、相手が自由に意見を発言できる質問になるべくしましょう。

感情移入しすぎない

インタビューをしていると感情移入する場合があるため、1件のインタビュー結果に引っ張られてしまわないよう、複数人にヒアリングしましょう。

第1版のヒアリング項目にとらわれない

インタビュー項目はブラッシュアップする前提で作成しましょう。

ヒアリング中は誘導するような質問はしない

話を聞くことに徹しましょう。

バーニングニーズの発見と検証

概要

本当に解決すべき課題なのかを客観的に評価するステップです。

前のアクティビティ「顧客インタビュー(CPF)」で得た声を客観的に評価することで、ソリューション検証(PSF)ステージに移行した後、スムーズに解決策検討に着手できます。

実施手順

以下のステップで評価していきます。

1. 課題の広さ：同様の課題を抱える顧客が世の中にどの程度いるのか

お金を払ってでも課題を解決したい人が十分な数存在するかを検証する必要があります。

• 例）一人の課題＜日本中の多くの人の課題＜世界中の多くの人の課題

【検証方法】

• 定量アンケート調査
  • 利用ケース
    • ターゲット顧客になり得るセグメント条件が多くあり、セグメントごとに何％ほど顧客になるか判断しづらい場合
  • 結果概要
    • ターゲット顧客のセグメントの明確化。各セグメント内で課題に感じている人の割合を出すことができる
• インタビュー等で課題をターゲット顧客に提起した際のリアクションから調査
  • 利用ケース
    • ターゲット顧客のセグメントの深堀りが浅く、セグメントの条件分岐が曖昧な場合
  • 結果概要
    • 顧客の反応からターゲット顧客になり得るセグメント条件を推定し、ターゲット範囲を割り出すことができる

2. 課題の発生頻度：どの程度の頻度で課題が発生するのか

いくら課題感を持っている人が多くとも支払う額が小さく、頻度が少ない場合はマネタイズが出来ません（※ただし、頻度が低くても成り立つ高単価の場合やサブスク等の課金モデルの場合は頻度が低くても成立し得ます）。

• 例）月1の課題＜1日1回の課題＜1日3回の課題

【検証方法】

• 定量アンケート調査
  • 利用ケース
    • 発生頻度が画一的な場合
  • 結果概要
    • ターゲット顧客の頻度の平均や中央値/各セグメントの頻度が網羅的に把握できる
• 顧客インタビュー
  • 利用ケース
    • 発生頻度が不定期な場合
  • 結果概要
    • 一定ユーザーの頻度とその頻度の決定要因まで把握できる
• 顧客の行動観察やウェブ上の行動ログといったデータを分析
  • 利用ケース
    • 顧客自身が自覚して計測できない場合
  • 結果概要
    • 実際の行動やログからユーザー自身が認識できていない部分を把握できる

3. 課題の深さ/深刻さ：どの程度困っているか、悩んでいるのか

顕在ニーズの場合、これは課題解決のために既に支払っているコストの大きさで測ることができます。コストは金銭/時間/労力/それに伴う精神的な苦痛等でも良いですが、できるだけ具体的に把握することが必要になります。金銭の場合は何円で利用するのかまで確認が必要です。

潜在ニーズの場合、課題解決のために無意識化で顧客に与えている負荷を測ることで検証できます。顕在ニーズとは異なり、顧客から具体的な数値等を聞き出すことが難しくなります。

• 例）多額のお金を払っている課題、多くの時間を使っている課題

【検証方法】

• 顧客インタビュー
  • 利用ケース
    • 顕在ニーズの検証をする場合
  • 結果概要
    • 実際に支払っているコストから顧客の課題感を具体的に把握できる
• 顧客の行動観察などの定性調査
  • 利用ケース
    • 潜在ニーズの検証をする場合
  • 結果概要
    • 実際の行動を「注視」「観察」し、無意識の行動の背景にある本人が気付いていない課題を把握できる

4. 課題の発生構造：課題は一過性のものではなく構造的に存在・拡大を続けるのか

• 課題が一度解決したとしても、再度早い頻度で同じ課題が発生します。または、社会や情勢等の影響から発生数が上昇し、課題が拡大していくことです
  • 例）毎日着る衣服に関する課題、日本の少子高齢化に関する課題

【検証方法】

• 顧客を取り巻く環境や社会情勢などを本やウェブ検索から情報収集
  • 利用ケース
    • 一過性の課題ではない場合
  • 結果概要
    • どのような周期で同じ課題が何回発生するのか。また、今後同様の課題を抱える人の増減傾向を把握できる

課題の深掘

コツ/注意点

発見した課題のテーマや領域ごとに最重要論点は異なる

頻出する論点の全項目は検証すべきですが、論点ごとの深堀り度が異なります。

例）日常生活の中で生まれる課題なのか、将来の不安に対する課題なのか。日常生活であれば課題の発生頻度が重要ですが、将来の不安に対する課題であれば課題の深刻さが重要であったり、捉える課題によって、優先順位は変わります。

以下の観点でチェックするとより妥当性を担保できる

• その顧客の抱えている課題の中でも、広さ・頻度・深さの観点で優先して解決すべきと言えるか？
• もしくは、その課題が解決されれば、その顧客の抱えている他の課題が連鎖的に解決できると言えるか？

評価の結果と対応パターン

1. 評価が十分にできない場合、改めて課題を深堀りして取り扱う課題を特定し、再度評価します
2. 取り扱う課題の広さ・頻度・深さが不十分な場合、もしくは一過性な課題の場合、同じ顧客の別の課題に目を向けます
3. 1, 2を実行しても、どの課題も広さ・頻度・深さが不十分な場合、もしくは一過性な課題の場合、別の顧客に目を向けます

ソリューション検証(PSF)ステージ

PSFとは、Problem Solution Fitの略で、解決案が適切かを検証するフェーズです。 顧客が、検討している商品・サービスを利用する理由を言語化し、課題解決できるソリューション及びプロトタイプを完成させます。

ユーザーシナリオ整理

概要

顧客が商品・サービスを認知し、興味・関心を持ち、商品を購入し、利用する、というような顧客の一連の行動をフレームワークを用いて可視化するステップです。

事業を推進する中で、自分たちの目線でサービスを考えてしまいがちですが、顧客の行動や心理を明確化することで、顧客目線で事業案を評価できるようになります。

実施手順

顧客の一連のフローを可視化するまでの流れは以下になります。

1. ペルソナを確認する

• CPF で設定したペルソナを改めて確認しましょう

2. ペルソナの行動を仮説で設計する

• 設定したペルソナが、自社の商品・サービスを購入するまでにどのような行動を取るのかを仮説で設計してみます
• ここでは、顧客の行動をフェーズごとに考えてみましょう。フェーズには、後ほどお話するフレームワークの横軸である「認知」→「興味・関心」→「比較検討」→「購入」→「利用」を利用します。各フェーズでペルソナがどのような行動を取るのか、洗い出し、整理しておきます
• このフェーズの設定はあくまで一例です。例えば、ホテル宿泊予約サービスであれば、「購入」→「利用」ではなく、「利用」の部分が「ホテル一覧」→「ホテル基本情報」→「宿泊プラン」→「予約（=購入）」のような順番になります
• 上記例のように、詳細にフェーズを作ることで、顧客を深く理解することができるようになります

3. ペルソナの行動を固める

• 上記のステップごとに洗い出したペルソナの行動が正しいかどうか、設定したペルソナが取らないような行動がないか確認してみましょう。近くにペルソナに近い人がいるなら、クイックに違和感がないかヒアリングしてみるのも一つの手です

4. フレームワークを決定する

• 続いて、フレームワークを決めます。慣れないうちは、下記のようにシンプルなフレームワークを使うと良いかもしれません
• 横軸：「認知」「興味・関心」「比較検討」「購入」「利用」
• 縦軸：「タッチポイント・行動」「思考」「感情」
• 「タッチポイント」はユーザーと商品・サービスの接点を指し、Webサービス、SNSなどが当てはまります
• 「行動」はユーザーがそのフェーズでとる行動を、「思考」、「感情」は、その行動をとるときに、抱いている思考・思考を指します

フォーマット

5. 内容を書き込む

• 上記フレームワークが埋まるようにそれぞれの項目に内容を書き込んでいきます。考えている解決策を顧客の行動に当てはめてみて違和感がないか、丁寧に確認しながら進めていきましょう
• また、この時のポイントは、視覚的に分かりやすく記載することです。ただ文章を並べるのではなく、図・アイコンを多く用いることで、ひと目で分かるようなマップに仕上げることを意識しましょう。最後に漏れがないか確認し、全ての情報が書き込まれたらマップは完成となります

入力例

コツ/注意点

周囲の人間に、バイアスがかかっていないか確認してもらう

自分の視点/体験に引っ張られている可能性があるため、複数の周囲の人に確認してもらいましょう。

内容整理は費やす時間をあらかじめ決めて実施

時間を決めて取り組むことで、自分一人で思いつかない場合に区切りをつけ、他の人の意見をもらうようにしましょう。

次のプロトタイプ作成を意識する

「プロトタイプ作成」につなげるため、現時点での理想（仮説）となる解決策をしっかりと定義し、それをどう使ってもらうかまでを可視化（フロー化）することを意識してください。

プロトタイプ作成

概要

顧客や内部関係者が確認・評価をして、商品・サービスの仕様を固めていくための試作品を開発するステップです。

プロトタイプを作ることで、顧客のより具体的なフィードバックを得ることができ、商品・サービスのアップデートに貢献できます。

実施手順

プロトタイプを作る上で、以下が完了していることが前提となります。

• 顧客と課題が存在することを検証できていること
• 課題解決のための要件が洗い出せていること
  ※この時点で要件は仮説でも可

上記の確認が終わったら、まずは検証項目を策定します。

1. 解決策の価値提供に対して顧客がお金を払ってでも使いたいと思うか？　を確認するための質問のあり方を検討
2. ソリューション/提供価値仮説の要件の重要度に応じて分類し、検証項目を設定

続いて、プロトタイプを選定します。

• 選定基準
  • 得られるフィードバックの具体性(=投下できるコストや期間)
  • 現時点の解決策の蓋然性
    • 受容性と有効性どちらを主に検証するか等
      ※上記に従って適切なプロトタイプを選定する

プロトタイピング手法と位置付け

プロトタイプの分類方法/定義は様々ありますが、以下一例を紹介します。

• 種類
  • キャッチコピー/プレスリリース
  • ダーティープロト
  • ペーパープロト
  • クラウドファンディング
  • コンセプトムービー
  • LP(サービス紹介ページ)
  • ワイヤーフレーム
  • デザインプロト(外観モデル)
  • モックアップ
  • オペレーショナルプロト(手作業/既存品組み合わせ)
  • ファンクショナルプロト(機能施策)

プロトタイピング手法ごとの特徴やポイント

プロトタイプ選定後、プロトタイプを作成していきます。

コツ/注意点

プロトタイプを作ることを目的化しない

プロトタイプはあくまで完成形となるプロダクトの仕様検討や、アイデア自体のブラッシュアップにつなげることが目的であり、プロトタイプ開発自体が目的化してはいけません。

プロトタイプに要件を盛り込みすぎない

要件を過剰に盛り込んでいる場合、ターゲットユーザーや内部関係者に対して確認するポイントが曖昧になり、検証が失敗する可能性が高くなってしまいます。

プロトタイプ作成プロセス

本章では、「プロトタイピング」のプロセスについて定義します¹⁷。

プロトタイピングは、デザインの忠実度(fidelity)を高めていくためのものです。 プロダクトのイメージを具体化・詳細化していくために、プロトタイプを作成し、ユーザー視点で評価し、必要な改修点をプロトタイプに反映してプロダクトとデザインの忠実度を上げていきます。 従って、プロトタイピングは反復的なプロセスになります。

プロトタイピング

前章で述べた通りプロトタイプにはさまざまな分類がありますが、本プロセスで示すのはペーパープロトからワイヤーフレーム、デザインプロトへと手法を発展させ、この忠実度を高めていく過程です。

「忠実度(fidelity)」は、完成したデザインに対してどのくらい「本物っぽいか」を意味しており、最終的なプロダクトにどのくらい近いかを指します。 このように書くと、作成するプロトタイプは忠実度の高い方が望ましいように見えますが必ずしもそうではありません。

例えば、初期段階の評価で重要なのは、見た目の良し悪しではなく、本質的な機能が何かという適切な判断です。 製品イメージが異なっている場合には作り直すことが必要になるため、いかに簡単に作り直すことができるかが重要なポイントになります。

忠実度の低いプロトタイプは、紙とペンだけを用いて作れます。 そうして生まれたペーパープロトを用いて、頭の中のアイデアを概要レベルのデザイン案として素早く確認でき、ユーザー体験や実現するプロダクトが視覚化されます。 視覚化できれば、チームメンバーの間でもプロダクトイメージや方向性を明確に把握できるとともに、ユーザーからのフィードバックも得られます。

一方で、忠実度の高いプロトタイプには必要なデザインやコンポーネント、インタラクションが組み込まれ、最終的なプロダクトへ近くなります。 FigmaやAdobe XD等のツールで作成することになるでしょう。

このような、より「本物」に近いプロトタイプによって、ビジュアル、機能・インタラクションについてのユーザビリティ、ワークフロー上の問題の有無といった評価ができます。

本書では、プロダクトとデザインを明確化するために以下4つのフェーズを定義します。

一度にプロダクト全体のプロトタイピングをおこなっていくのではなく、 課題検証(CPF)ステージで発見したユーザーの課題を解決する機能を検討し、その個々の機能に対して上述の4フェーズを進めます。 これらのフェーズで、プロトタイプを作りながらプロダクト・デザインの忠実度を上げていくことになります。

なお、1つのプロトタイプを作って評価すれば次の段階に進んで良いわけではなく、評価結果によっては前の段階に戻ってプロトタイプを修正し再度評価することも多々ある点に注意してください。

評価基準については、プロダクトによって変化しますが、コンセプトテストの尺度を基準とすることで効果的な評価が可能です。¹⁸

また、実際の現場においてプロトタイプの段階からデザイナーがいるとは限りません。
その場合は、オブジェクト指向UIデザインという方法論を学んでおくとプロダクト・デザインの忠実度を上げていく際に役立ちます。
オブジェクト指向UIデザインを適用した事例は、アップサイクル事業のトレイルを参照ください。

検討段階

プロダクト・デザインを明確化するための検討フェーズ

本フェーズでは、以下を行います。

1. カスタマージャーニーに沿ってデザインコンセプトの策定
2. 策定したデザインコンセプトからデザイン対象物についてのペーパープロトを作成
3. 想定するユーザーの行動とペーパープロトを見比べながら、当該の画面遷移・画面イメージでユーザーの課題が解決できるのか、良好なUXを提供できるのかを評価

この作業は、実質的に顧客の課題に対するソリューションが何かをアウトプットすることになるため、事業オーナーが実施します。

デザイン対象物の基本的な構造、UXを実現するための構造の検討が行われていることが重要であり、 画面間のつながりなどは十分検討できなくても問題ありません。 評価結果をもとに、ユーザーが情報を整理しやすく、またユーザー自身が情報を探しやすくなるような構造を検討・設計します。

振る舞いと認知の検討フェーズ

本フェーズでは、ユーザーが行う一連の流れを想定したプロトタイプを作成し、具体的なナビゲーションのデザインやレイアウト、インタフェースの動きを詳細に検討します。 具体的には、前フェーズで作成したペーパープロトから忠実度の低いワイヤーフレームを作成することで、簡易にデザイン対象物の動作を表現して評価していきます。

この作業は、デザイン対象物の基本的な振る舞いを検討するため、デザイナーが主体となって実施することを想定しています。

想定するユーザーの行動に沿ってデザイン対象物の基本的な振る舞いを確認しながら、可能であれば業務の専門家やUXデザイナーの専門家で評価し、具体的なナビゲーションのデザインやレイアウト、インタフェースの動きやアニメーションなどを検討します。 また、感情面では意欲を高めて維持するためのメタファーやモチーフなどの検討が必要です。

見た目のデザインの検討フェーズ

本フェーズでは、忠実度の高いワイヤーフレームを作成し、実際のプロダクトにより近い形でユーザーとの接点となるインタフェース、デザインの検討をします。この作業は、インタフェースや外観などの見た目のデザインを作成するためデザイナーが主体となって実施することを想定しています。

具体的には、プロトタイピングツールを使い、PCやスマートフォンでインタラクションを手軽に試しながら評価し、使いやすく操作を誤りにくい表現・わかりやすく誤解しにくい表現を検討します。 誤りや誤解は一連の操作の流れの中で起こるため、プロトタイピングツールを使い、ユーザー参加による評価によって改善に役立つ情報を得ることができます。

実際のユーザーに近い形で検証・評価を実施できるのが望ましいですが、それが難しい場合は社内の協力者等の協力を得て実施することで、より多くの改善に役立つ情報を得られるはずです。

デザインの洗練フェーズ

本フェーズでは、デザインする範囲を広げ、より完成形に近い状態のプロトタイプを作成しユーザビリティ上の問題点の改善します。

この作業は、UXの問題点を発見し改善をおこなうためデザイナーが主体となって実施することを想定しています。 ユーザー参加によるユーザビリティテストを実施することで、プロトタイプがどれだけ使いやすいかを評価できます。

具体的には、ユーザーの操作方法や感じ方の仮説を立て、実際の利用文脈を想定したタスクを設計しプロトタイプを利用してもらいます。 その結果、どの程度使いやすいか使いにくいかの問題が明らかになり、プロダクトの課題が発見できます。

プロトタイププロセスの見える化のためのプロトタイプカンバンボードについて

上記で述べたように、プロトタイピングのプロセスは反復的なものです。 各機能ごとに反復プロセスを繰り返していくようなケースでは、自分たちが今どの課題に取り組んでいて、どの機能にフォーカスしているのかを可視化すべきです。そうすることで、チーム内で取り組んでいる機能とそのフェーズが共有できます。

この用途に対し、スクラム等でよく使われるのがカンバンボードです。 カンバンボードとは、作業を視覚化し、進行中の作業(WIP)の数を制限し、効率を最大化するために設計されたアジャイルプロジェクトの管理ツールです。

• かんばんボードによるプロジェクトの見える化

特にプロトタイピング用のカンバンボードが「プロトタイプカンバンボード」¹⁹です。これは下図のように、課題検証で明らかになった顧客の課題や当該課題を解決するための機能案、それらの機能に対するプロトタイプの状況等をカンバンとして表現するものです。

プロトタイプカンバンボード

これにより、以下のメリットが得られます。

• プロセスを見える化することにより、検証プロセスが明確になり、メンバー間のコミュニケーションが活性化する
• 適切なタイミングでフィードバックを得るというプロセスを担保できる
• ボトルネックになっている場所が明確になり、リソースを適切に配分しやすくなる

顧客インタビュー(PSF)

概要

前のアクティビティ「 プロトタイプ作成」にて作成したプロトタイプを用いて、顧客や内部関係者が確認・評価をして、商品・サービスの仕様を固めていくステップです。

ここで仕様を固めることで、製品開発スピードを飛躍的に上げることができます。

実施手順

検証の目的に応じて、プロトタイプを、どのように顧客に利用してもらうかを検討します。

• 検証方法一例
  • インタビュー
  • セールス
  • Webマーケ
  • アンケート
  • 展示会
  • クラウドファンディング

その後、以下の内容を中心にして顧客に聞きます。

1. お金を払ってでもほしいものになっているか、インタビューする

• マネタイズの可能性を確認する質問ではなく、あくまで商品・サービスの受容性を、間接的に検証するための質問という位置付けになります
• 商品・サービスの受容度合いがある程度測れたり、今後の価格設定の1つの材料になるので、「この商品・サービスに対して実際どの程度お金を払えるか」も確認しておきましょう

2. 提供価値を実現するために必ず必要な機能をオープンクエスチョンで確認する

• 検証対象となる提供価値を顧客に提示した際、同時に提供価値の実現にあたって、なくてはならない機能は何か？
• 実装されているがなくてもよい機能（→nice to have機能に再分類）、必須だが備わっていない機能（→must have機能として実装）は何か？

事業化を進める中で、「もしかしたらこんな層にも受け入れられるかもしれない」という別の顧客イメージがある場合、そういった層へのインタビューを行えると、市場拡大の可能性の発見することに繋がるかもしれません。

コツ/注意点

お客様ではなく、仲間になってもらう意識で良好な関係を築く

フィードバックの中身がとても重要なので、距離を近づけた方が、より深いコメントが得られます。プロトタイプの検証は1回で終わるものではないので、前回使った時よりも具体的に何が良くて、何が悪くなってしまったのか聞ける点でもとても意味があります。

具体的な答えを収集できる質問項目を作る

プロトタイプを使ってもらうことで得たユーザーの声を、問題解決に活かさないと意味がありません。フィードバックを全て対象者に委ねるのではなく、正確な情報がもらえるような質問項目をつくることが大切です。

たとえば新型のヘッドホンを使ってもらったとすれば、「このヘッドホンで使いにくい点は何ですか？」という曖昧な質問の仕方ではなく、「音質を5段階で評価してください」「着け心地の良さを5段階で評価してください」など、ポイントを絞って回答が得られるようにすると良いでしょう。

市場競合・調査分析

概要

前のアクティビティ「顧客インタビュー(PSF)」を通じて商品・サービスに関する顧客の反応を確認した後は、商品・サービスに関するマクロ動向=市場と、そこでの競争相手=競合の分析を進めていきます。 「市場分析」では、対象市場全体の動向を基に市場自体が魅力的かを示し、「競合分析」では、想定競合企業の動向や商品/サービス内容を基に自社としてどのような特徴を有した商品/サービスにすべきかを示すステップです。

実施手順

市場分析、競合分析を実施する流れについてご紹介します。

1. 市場分析を実施する

• 関連市場の特定：商品/サービスが属する、もしくは商品/サービスの盛衰に影響しうる市場を特定
• 市場規模推移調査：上記で特定した市場の市場規模推移・将来予測を調査。政府統計（国勢調査・商業統計等）や民間調査レポート（矢野経済研究所等）を主に活用
• 市場トピックの把握：直近の法令改正状況・技術動向・代替市場動向等、当該市場に影響を与えうるトピックを把握 以下、市場分析結果として国内ポイントサービス市場の例示となります。

2. 競合分析を実施する

• 競合となりうる商品/サービス洗い出し：自社商品/サービスの競合となりうる商品/サービスを洗い出す。狭義の競合商品/サービス（＝同様の課題解決手法）のみならず、広義の競合商品/サービス（＝同様の課題を異なる手法で解決）まで広げられると尚良し
• 競合となりうる商品/サービスの分析：競合となりうる商品/サービスをそれぞれ調査し、対象とする顧客、解決する課題、主要機能・提供方法・価格等を比較分析
• 自社における商品/サービス要素洗い出し：競合となりうる商品/サービスの分析結果を踏まえ、自社の商品/サービスとして具備すべき機能や価格を設定

以下、競合分析の評価軸例です。

コツ/注意点

そのものズバリの参入する市場が現在存在しない場合

ターゲット顧客の数/推移/動向で代替します。

競合分析は何度も行う

競合分析の見直し（またはアップデート）を怠ると、事業戦略が無意味なものになってしまう可能性があるので、小まめにリサーチしましょう。

マーケティング戦略立案

概要

どのような場所（メディア）でどのような施策を実施すると、商品・サービスへの認知獲得から購買検討まで顧客の感情を押し上げることができるかを考えるステップです。

顧客への正しいアプローチ方法を検討することで、効率良く商品・サービスを届けることができます。

実施手順

1. 購買に至るプロセスについて検討する

一例ですが、認知→課題認識→解決策模索（比較検討）、という順序が一般的なプロセスになります。

続いて、購買プロセスの中で顧客がどのような状態であるかについて検討してみましょう。

一例ですが、以下のような順序が一般的です。

1. 匿名リード（氏名、連絡先などの情報が取得できていない、個人を特定できない潜在的な見込み客）
2. リード（企業の商品・サービスに興味を持ってくれていて、将来的に購入してもらえることが予測できる顧客）
3. ホットリード（商品・サービスに対する興味関心度が高く、購買までもう少しの段階にある見込み顧客）
4. 有望リード（ほぼ購買することを決めている顧客）、

次に、各購買プロセスで、どんな場所（メディア）でアプローチすべきか検討してみましょう。以下、場所（メディア）例です。

• 認知
  • オンライン
    • ソーシャルメディア
    • インフルエンサー
    • コンテンツ
    • マーケティング
    • テレビCM
    • プレスリリース
  • オフライン
    • リスト購入/コール
    • 展示会
• 課題認識
  • オンライン
    • SNS広告
    • 記事広告
    • SEO（情報探索ワード）
      情報探索ワード：何らかの情報を「知りたい」という意志がある検索ワード
    • ホワイトペーパー
  • オフライン
    • DM（郵送/FAX）
    • セミナー
• 解決策模索（比較検討）
  • オンライン
    • リスティング広告
    • Webサイト改善
    • SEO（購入ワード）
      購入ワード：ある特定の商品・サービスを「買いたい」という意志がある検索ワード
    • メールマガジン～LP誘導
  • オフライン
    • インサイドセールス
    • 代理店からのアプローチ

前のアクティビティ「市場競合・調査分析」を通じて把握した市場に属する商品・サービスや、競合の戦略も考慮に入れ、参考にすべき部分は参考にし（同質化）、違いを出す部分も検討しましょう（差別化）。

上記の検討が済んだら、実際に施策の中身を検討してみましょう。

コツ/注意点

想定している顧客がどのようなメディアに触れているか、どのような場所に行くかをまず想像する

施策から考えるのではなく、顧客の普段の活動から検討すると施策の選定がしやすくなります。

施策の中身はベンチマークしている企業や競合からヒントを得る

先行事例をリサーチした上で、具体的な施策を検討すると進めやすくなります。

ペルソナを広げない

エンドユーザー向けビジネスは、どうしても範囲が広くなってしまうので、マーケティング施策が曖昧になりがちです。ペルソナを絞って、具体的なマーケティング施策を検討します。

セールス戦略立案

概要

ビジネスが成功するためのシナリオを描き、目標達成するための計画を策定するステップです。

前のアクティビティ「マーケティング戦略立案」にて策定したマーケティング戦略が正しいかどうかをこのステップで精緻化・具体化していきます。また、チームメンバーの意思統一をするために欠かせません。

実施手順

以下が大まかな流れです。

1. いつまでに何を達成しないといけないかを決める

• いつまでに何を達成しないといけないのかを確認し、すり合わせを行いましょう。目標を設定したら、しっかりとその理由も明確にしましょう

2. 実施期間と具体的な数値目標を決める

• 上記でゴール設定ができたら、期間を区切って、それぞれの数値目標を立てましょう。具体的な数値が示されると、ゴールが定まり、チームの士気が上がります

3. 商品・サービスの価格を設定する

• いくらで販売するのか、できそうなのか、顧客目線と開発目線で検討しましょう。どのくらいの量を販売するのかによってもコストが変動するので、その視点も忘れないでください

4. 商品・サービスをどこで販売するのか決める

• ECサイトで販売するのか、店舗で販売するのか、はたまた小売店に卸して販売するのか。顧客が商品を買おうと思ったときに買える環境を考えましょう

5. マーケティング戦略を確認する

• 前述で策定したマーケティング戦略を改めて齟齬がないか確認します

6. 営業プロセスを作成する

• 広告・Webサイト経由で獲得したリード顧客に対して、どうやって営業（アプローチ）していくかプロセスを確認します
• 例えば、以下の図のように関係者ごとにそれぞれのフェーズでどんなアクションがあるのか整理するとわかりやすくなります

営業プロセス

7. 見込み客リストを作成する

• リード獲得後に使用する見込み客リストを作成します
• BtoBの場合は以下の内容のように詳細な情報を入れましょう。BtoCの場合は、取得できる情報を入れられるようにしてください

8. 提案・交渉条件を策定する

• 顧客のセグメントによって、伝える内容を変えましょう
• BtoCの場合は、何を売り文句にするのかキャッチコピーを考えましょう。BtoBの場合は、提案する資料の構成やメッセージを検討しましょう
• 加えて、顧客セグメントで、値引きをするのか・特典をつけるのかなど、交渉条件を整理しましょう

9. 契約締結について

• BtoCの場合は利用規約を作り、それに同意している前提で購入できる状況を生み出します
• BtoBの場合は契約書を作り、その内容を前提にすり合わせができる状況を生み出しましょう
• どちらの場合でも、弁護士や法務に相談し、何を事業として守らなければならないのかの視点で項目を洗い出しましょう

10. 売上管理方法を策定する

• 顧客の基本情報、 購入履歴、アフターフォロー含むやりとりの記録を残せるように準備しておきましょう
• かつ、誰が担当者なのか、誰が責任者なのか、所在をハッキリさせましょう
• 顧客管理ツールは世の中にたくさん存在するので、どれが良さそうかリサーチしておきましょう

コツ/注意点

あまりに高すぎる目標を設定しない

現実離れした目標は社員のモチベーションを下げてしまうので、妥当性も考慮した目標を設定することが大切です。

数字だけ掲げるのは避けること

数字だけを掲げても、「なぜその数字を達成しなければいけないのか？」という疑問が残る以上、最大パフォーマンスは発揮できません。数字と合わせて目的や意義を提示することが大切です。

収益性分析

概要

ビジネスにおいてどれくらい売上を上げれば利益が出るのか、言いかえればどれくらい売上を上げないと赤字になってしまうのかを見極めるステップです。

ここまでのアクティビティ「マーケティング戦略立案」「セールス戦略立案」を通じて検討した内容も踏まえて費用構造を理解することで、目標利益を実現する上で必要な売上高を求めたり、価格設定やコストダウン施策のヒントにできます。

実施手順

以下の順番で分析を進めていきます。

1. LTVとCACを確認する

• まずは最低限の収益性の状態として、LTV≧CACの関係が成立しているか確認します
• LTVとは、「Life Time Value」の略称で、日本語では「顧客生涯価値」と呼ばれています。ある顧客が、取引を開始してから終了するまでの期間に、自社に対してどれだけ利益をもたらしたか、収益の総額を算出するための指標です
• CACとは、「Customer Acquisition Cost」の略であり、日本語では「顧客獲得費用」を意味します。具体的には、顧客1社を獲得するために必要となるマーケティングや営業のコストのことを指し、ある一定期間に投資したマーケティングおよび営業コストの合計金額を獲得した顧客の数で割ることによって算出します

2. より具体的な収益性を確認する

• 変動費の数字と内訳を洗い出す
  • 変動費とは、売上（生産量・販売量）に比例して増減する費用のことで、原材料費、仕入原価、販売手数料、外注費などが挙げられます
  • 一つ作るあたりのコストだと捉えるとわかりやすいです
• 固定費の数字と内訳を洗い出す
  • 固定費とは、生産量や販売量の増減に関わらず一定にかかる費用のことで、人件費、広告宣伝費、減価償却費（開発等で先行投資が必要な場合）が必要な費用などが挙げられます
  • 月々の固定費として考えてみるとわかりやすくなります
• 顧客インタビューで聞いた理想的な販売価格を確認
• 利益が0のときの売上高「損益分岐点売上高」を算出する
  • 計算式=固定費÷｛1 -（変動費÷理想的な販売価格）｝
• X軸（数量）、Y軸（売上/コスト）を作る（損失をイメージ）
  • 固定費をY軸のコストの起点に入れます。また、損益分岐点売上高の金額も書き入れ、それを達成するためをX軸の数量に記載します。交点よりも左は損失となりますので、斜線などを引いて「損失」と書いておきます
• X軸、Y軸を作る（利益をイメージ）
  • 損益分岐点の右領域は黒字で、利益が出ている状態です。斜線などを引いて、「利益」を書いておきます。目標としている数量と売上高も記入してください
• 理想的な販売価格を実現できそうか確認する -「 〇〇個売れれば、●円の利益が出る」というように目標売上数の時にどのくらい利益が出るか算出してみてください
  • 上記の時に、あまりにもありえない数を売らないと成立しないようなことがあれば、変動費、固定費のコストダウンを検討してください
  • もしくは、販売価格を上げられそうかの視点でも評価してください

コツ/注意点

この分析の際、便宜的に以下の前提を置いていることを理解する

• 生産量と販売量は等しいものとする
• 販売価格は一定とする
• （複数の製品がある場合）製品ミックスは一定とする
• 単位当たりの変動費は一定とする
• 固定費は一定とする

エキスパートレビュー

概要

デザイン原則や経験則の知見を持ったUXの専門家が商品・サービスを検証したり、ストラテジックプランナーやマーケターがマーケ/セールス面について分析し、問題点の指摘と改善方法の提案をレポートするステップです。

通常のレビューで得られる課題の検知だけでなく、専門家による具体的なアドバイスや改善方法の提案までを受けられます。

実施手順

基本的には、エキスパートレビューをサービスとして提供している企業に依頼するのが効率的です。以下が大まかな流れです。

1. 計画

• エキスパートレビューの目的、目的を達成するための方法、どの企業に依頼すべきか、を検討します
• 依頼
  • 実施できる企業に上記内容で依頼をします
• 評価指標の設定
  • 評価する対象が決まったら、分析者の主観が影響することを防ぐため、どの観点で評価するかの指標を決めます
• 評価の実施
  • 上記で定めた指標をもとに、チェックしたい項目をリスト化しておくと効率的です。チェックリストをもとに確認し、問題があると感じた箇所をリストアップしていきます
• データ分析〜レポート
  • 問題点を洗い出した上で、評価対象の改善施策を作ります
• 分析
  • レポート内容をもとに、アップデートしなければならない項目を整理します

コツ/注意点

n数が少ないため、結果に偏りが出る可能性がある

現実的に1,2名への依頼となる場合も多く、結果の信頼性と品質は、その専門家の知識と経験に依存してしまいます。ですので、まず5名を1つの目標値として、十分注意して依頼先を選定しましょう。

専門家が見つからない可能性があるので、事前にネットワークを共有しておく

専門家を見つけることは容易ではありません。個々人の伝手に頼らず、組織的にネットワークを共有しておきましょう。

概念実証(SPF)ステージ

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

検証仮説定義

概要

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

実施手順

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やテストセールスの準備をするステップです。

実施手順

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

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

MVPキャンバス

2. 目標数値を策定する

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

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

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

4. 必要最小限の機能を定義する

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

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

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

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

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

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

1. エピックを達成するために必要な手順・一般的なワークフローを考え、時間軸に沿ってテーマを並べる
2. それぞれのテーマをユーザーストーリーに分解し、優先順位に基づいて縦に並べる

5. サービスブループリントを作成し、検証に向けたオペレーションを策定する

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

サービスブループリント

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

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

7. MVPを開発する

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

コツ/注意点

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

新規事業には失敗がつきものです。顧客に意見を聞いてみると、自信があるアイデアでもネガティブな意見をいただくことが多々あります。そのため、トライ＆エラーを前提に検証を進めることがとても大切です。 大切なのは、「検証ができるかどうか」であり、必ずしもコードを書いてシステム等を作り込む必要はありません。「本当に検証すべきことは何か」「そのために必要最小限の機能は何か」を整理し、検証方法を検討しましょう。

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

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

MVP開発のための要件整理

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

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

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

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

機能要件

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

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

非機能要件

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

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

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

開発規模見積(MVP)

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

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

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

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

• リスクを検知し、対策を計画に組み込むことでプロジェクトの成功可能性を高める
• 実際に開発した場合、どのくらいの期間や予算、体制が必要になるのかを知る

要件や仕様に曖昧な点がある場合は、事業オーナーに確認します。見積もりでは、要件整理とは違った視点でプロダクトを眺めることもあると思います。要件整理時には出てこなかった仕様がないか再度確認します。 事業オーナーも答えを持っていない場合は、設定した課題やペルソナ、検証する仮説に立ち返り、チームで一緒に考えましょう。

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

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

アプリ見積もり(MVP)

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

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

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

リスクの定量的評価

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

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

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

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

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

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

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

見積もりの進め方

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

実装フェーズの見積もり

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

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

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

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

• Tシャツのサイズは意外と便利？プロジェクトの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となります。

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

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

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

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

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

工程ごとの見積もり方法

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

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

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

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

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

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

工程	中央値	「実装・テスト」を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の構成サンプル

• 見積もりサンプル

リソース	費用	メモ
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インスタンスにミドルウェア全部乗せパターンのサンプル

• 見積もりサンプル

リソース	費用	メモ
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

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を利用した場合のサンプル

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

その他

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

付記: 外形監視について

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

• StatusCake – Uptime monitoring, Page speed monitoring, and more
• UptimeRobot: Free Website Monitoring Service

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

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

優先度をつける

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

• RICE: Simple prioritization for product managers

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

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

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

RICE

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

開発計画

開発プロセス(MVP)

この時点で、詳細な仕様書を作成していることは稀でしょう。ですが、詳細な仕様書は必要ありません。 MVPは仮説を検証することが目的であり、検証の結果によって次々に仮説が変わっていきます。 次々に変わる仮説を検証するたびに仕様書を作成したのでは、仮説検証プロセス高速化の妨げになります。 そのため、ここではおおまかな仕様だけで開発する必要があり、そのための開発プロセスやスキルが求められます。ガイド内で何度も記していますが、少しでも早くMVPを完成させる必要があるためです。

このため、動くものをベースに事業オーナーへ見せながら進めることができ、すぐに事業オーナーからのフィードバックを得られるアジャイル形式で進めるのが最適です。 アジャイルの実践手法として、我々はスクラムを使っています。 スクラムの詳細についてはスクラム概論 | アジャイル・スクラム | Fintanを参照ください。

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

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

必要であれば開発要員を確保した上で、開発体制を整えます。 開発メンバーについては、チーム内で担当可能なメンバーがいれば担当してもよいですし、そうでない場合は別部署との協業やビジネスパートナーに依頼することも検討します。

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

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

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

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

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

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

全体計画の策定

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

全体計画上で悩ましいのは、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は出来るだけ早くリリースする必要があり、長期間のメンテナンスもしないでしょう。 このため、テストコードの記述は最低限に抑えましょう。むしろ、ほとんど書かないというくらいの気概が必要です。

もちろん、今後も多く利用しそうなライブラリや共通機能を開発しているような場合は、長期間メンテナンスすることも考えられます。このような場合、テストコードを記述することを否定しません。

テストコードを書く上で重要なのは費用対効果に見合うかです。 判断に迷う場合は、t-wadaさんが公開されている以下の資料をご参照ください。

受入テスト

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

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

事業計画立案ステージ

事業計画立案とは、どのくらい投資をして、どのくらい儲かりそうかを検証するステップです。 決裁者に対して、意思決定に必要な情報をわかりやすく伝達できるように、これまで準備してきた情報を整理することに加えて、収支計画を策定します。

アクティビティ	概要
事業計画策定	事業のロードマップ及びKPIを設計するステップです。 「ロードマップ」という形で、今後どのようなスケジュールで事業を推進するかを大枠で示します。 「KPI」では、新規事業は売上や利益といった成果が出るまでに時間がかかるため、売上・利益を担保するための重要な指標をKPIとして設定します。 これまで検討してきたマーケティング戦略、セールス戦略も含めて検討します。
収支計画	いつ、どの程度の収支・投資対効果となるかを可視化するステップです。
事業計画レビュー	審査観点に従って、事業計画を審査するステップです。

事業計画策定

概要

決裁者から意思決定を引き出すために必要な事業計画書を作成するステップです。事業計画書は、事業を思考するための道具であり、思考の伝達の道具でもあります。そして、事業計画書を適切に用いて、決裁者の意思決定を引き出します。

実施手順

事業計画書は、一般的に以下の1から15で構成されます。

1. 目指す世界観

事業アイデアの検証を通して最終的にどのような世界を実現したいか描きます。「企画検討」の内容や「顧客インタビュー(PSF)」「PoC・テストマーケティング・セールス」を通じて得られた検証結果を踏まえてまとめます。

2. 事業概要

事業アイデアの骨子となる顧客、商品・サービス概要、提供価値・メリットなどを紹介します。 「PSF」「SPF」を通じて検討した商品・サービスの内容、「PoC・テストマーケティング・セールス」を通じて検証した提供価値などを踏まえてまとめます。 この時に、大事なのは、半永久的にどのように事業を継続するかの視点です。 立ち上げたら終わりではありません。 参入障壁が何か、特異点が何か、初期アイデアの商品・サービスをどのようにアップデートさせていくかなどの視点が重要です。 JV設立や新たな事業部の設立など、事業の推進体制についても言及します（後のアクティビティ「事業化準備」で再度具体検討します）。

3. 技術実証

事業アイデアの信憑性・実現性を担保するために技術面での証明が必要な場合、先行研究や事例などのエビデンスを用いて説明します。 例えば、論文ならCinii、特許技術ならJ-PlatPat、技術トレンドならGartnerなどがあります。

4. ビジネスモデル

ステークホルダーを含めたヒト/モノ/カネ/情報の流れを整理し収益を生み出す仕組みを整理します。

5. ステークホルダー整理

事業を実現するにあたって絶対に必要な役割を検討し、巻き込むべき組織を把握します。

6. 市場分析

市場の規模/成長率/トレンドをふまえ市場の魅力度やリスクを分析します。「市場競合・調査分析」の内容を踏まえてまとめます。

7. 競合分析

競合他社の商品ラインナップや顧客基盤、技術・ノウハウをふまえ自社の競合優位性を分析します。こちらも「市場競合・調査分析」の内容を踏まえてまとめます。

8. KPI設計

新規事業は売上や利益といった成果が出るまでに時間がかかるため、売上・利益を担保するための重要な指標をKPIとして設定し、重点的に状況を把握します。ここまでのアクティビティであまり触れていない点ですので、以下の設計の手順をご覧ください。

KGIを設定

まず、最終目標となるKGIを設定します。KGIは数値で測れて、達成可能な目標を設定することが大切です。

KGIからKPIを設定

各KPIは「検索流入数月間100人」のように具体的な数値化をして設定します。

KPIツリーを作成

KPIを細分化して、達成するための行動をわかりやすくするために、KPIツリーを作成します。これにより、目標の達成には何が必要なのか一目で全体像を把握できるようになります。

9. ロードマップ

計画達成に向けた進め方の合意を得るための大まかなスケジュールを整理します。こちらもここまでのアクティビティであまり触れていない点ですので、以下の作成の手順をご覧ください。

マイルストーン設定

• 事業推進に際し、マイルストーンとなる時期・状態をトップダウンで設定
• 出口に関連する、事業部設立やJV設立などの重要な節目を含めて検討
  • 例：市場先駆者となるためには3ヶ月以内のβ版ローンチ必須、法改正となる1年後までに正式版をローンチすべき、等

主要実施事項の洗い出し

• マイルストーンに向け必要な事項を洗い出し、それぞれの必要事項に掛かる期間をボトムアップで積み上げ

ロードマップ全体調整

• マイルストーン（トップダウン）及び主要実施事項（ボトムアップ）の整合性を取るべく、ロードマップ全体を調整

10. マーケティング戦略

どのような場所（メディア）でどのような施策を実施すると、商品・サービスへの認知獲得から購買検討まで顧客の感情を押し上げることができるかを考えます。「PSF」「SPF」を通じて検討/精緻化した「マーケティング戦略」を踏まえてまとめます。

11. セールス戦略

ビジネスが成功するためのシナリオを描き、目標達成するための計画を策定します。「PSF」「SPF」を通じて検討/精緻化した「セールス戦略」を踏まえてまとめます。

12. 収支計画

事業目標を実現するために必要な売上や獲得ユーザー数、発生コストなどを3~5年の計画として策定します。この後のアクティビティ「収支計画」で詳細を説明します。

13. 自社との親和性

「自社のビジョン/戦略と合致していること」「経営リスクの分散/既存事業の強化につながること」「自社の強みを活かせること」などの観点で、事業化する意義を考えます。

14. リスク要因

これが満たされないと事業として存続できない点を洗い出します。 法務/技術/経済的観点などで、様々な事例を把握します。 例えば、法律でNGになることはよくあります。また、特許技術などでこの会社と組まないと実現がかなり厳しい、などが考えられます。

15. 今後のアクションプラン

いつ、どのような実施事項を行うかを整理し、実施事項間のつながりや、大まかな役割分担を明確化します。 ロードマップを踏まえ、直近で対応が必要なタスクを列挙します。

コツ/注意点

ロードマップでは、細かなタスクを作らないこと

ロードマップは目標達成までの全体的な道筋や方向性を捉えることを意識して、詳細や個別的な細かいことはプロジェクトの計画段階に委ねましょう。

人によって解釈が変わる内容やあいまいな目標などはKPIとして設定しない

誰が見ても同じ内容で理解・解釈ができるように数値を使用することが大切です。

リスク要因で、リスクが見つからなかった場合は…

成功に必要な条件の視点で考えてみてください（例：●●の特許を取得する / サイト投稿者を自動的に集める仕組みの構築　など）。

収支計画

概要

いつ、どの程度の収支・投資対効果となるかを可視化するステップです。 前のアクティビティ「事業計画策定」の中でも重要な一要素です。 大きな支払いがあるために一時的に資金がマイナスになってしまう月があったとしても、事前にわかっていれば、支出を見直したりするといった対策ができます。

実施手順

以下の流れで算出していきます。

1. 収入の試算

• 収入を構成する要素を洗い出し、各要素がいつどのような水準になるかを試算
• 顧客数×単価×利用回数などの大きな要素から、必要に応じ細分化することが必要

2. 支出の試算

• 支出を構成する要素を洗い出し、各要素がいつどのような水準になるかを試算
• 固定費（生産量や販売量の増減に関わらず一定にかかる費用）・変動費（売上（生産量・販売量）に比例して増減する費用）ごとに費用項目を細分化することが必要
• 開発費用の見積もりについては後述するサービス開発における開発規模見積・開発スコープ調整を参照。

3. 累計収支算定

• 収入・支出を基に、累積収支がいつマイナスからプラスへ転じるか等を表記
• この際、自社の投資基準（例：投資回収3年以内等）に合致するか、合致させるために何をどう見直すかを検証することが必要

収支計画

コツ/注意点

収入・支出試算に際し、いきなり細かな項目を洗い出さない

大きな項目（顧客数や単価など）洗い出し、その後、必要に応じて項目を細分化することがポイントです。

複数のシナリオで収支をシミュレーションしてみる

収支計画は基本となるシナリオ（ベースケース）を作った後、顧客数や開発費用、広告宣伝費などの重要な数字を変動させてベストケースとワーストケースを作成し、とてもうまく行った場合のシナリオと、最も悪い場合のシナリオの数字を確認しましょう。 ベストケースを目指した活動の検討や、ワーストケースを避けるための対策・対応の検討に役立ちます。

ロードマップとの整合性を担保する

こういうマーケティング施策を打ったらこういう効果が出る、といった繋がりをここで担保しましょう。

サービス開発における開発規模見積・開発スコープ調整

この項では、サービス開発時の見積もりとスコープ調整について説明します。

MVP開発時でも開発規模見積や開発スコープ調整を行います。 見積もりや開発スコープ調整の手法自体はほぼ同じですが、大きく異なるのはサービス開発では開発期間が長くなり、その間にチームはさまざまな知識を得ることでしょう。 チームが抱える大きなリスクは、見積もりが外れることではなく、見積もりや計画を守ることに拘泥し「間違ったプロダクト」を開発することです。そうしたことにならないよう、得た知識を利用して見積もりとスコープ調整をイテレーティブに行い、見積もりと計画に反映していきましょう。

前提として、見積もりと、見積もりを踏まえた計画づくりの目的を知っておきましょう³¹。

特徴	概要
リスクを軽減する	見積もり作業によって、潜在的なプロジェクトの問題点に行き当たる。そのようなリスクを検知し、対応に要する時間を見積もりに盛り込むことができる。
不確実性を減らす	開発を通して、チームはプロダクト・技術・チーム自身に対する新しい知識を得ます。それらを計画に都度取り込むことで、不確実性を減らせる。
意思決定を支援する	見積もりと計画があって初めて、プロジェクトの開始是非、要員構成等の意思決定が下せる。
信頼を確立する	約束通りの機能を安定して頻繁に提供し続けることでチーム内・顧客との信頼を培うことができる。また、見積もりが信頼できると、開発を持続可能なペースで進められる。そうすれば、コード品質も上がり、不具合も少なくなる。
情報を伝達する	なぜそれだけの期間と工数が必要なのか、見積もりに関する情報を提供する。それにより、前提や進捗の確認か可能になる

機能要件

大前提として、もっとも情報が少ないサービス開発当初から、機能要件を明確に詰めることは不可能です。 このため、我々は要件をユーザーストーリーという「ソフトウェアの機能が顧客にどのような価値を提供するかを示す」抽象度の高い機能記述として扱います。そして詳細に踏み込まないまま、抽象度の高い状態で見積もります。

ユーザーストーリー

再掲しますが、具体的なユーザーストーリーの例³²が以下です。ユーザーの分類(役割)、ユーザーの目的、その理由を具体的に記述します。このような形で要件の意図と本質を捉えた文章により、チームは後段でより詳細な議論が可能になります。

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

なお、このユーザーストーリーを詳細化していくのは後述する「スプリント」であり、継続的に事業オーナーと対話しながら調整していくものになります。なぜなら、自分達が作っているものについて理解が増していくほど、仕様は変わっていくためです。これが、サービス開発当初に要件定義へ大きな投資をしない理由です。

ユーザーストーリーの収集

プロダクトのユーザーストーリーを並べればそれが要件一覧になりますが、ユーザーストーリーを洗い出すのは難しいものです。 そこで行うべきはストーリーマッピングです。基本的な考え方は、抽象的なユーザーの行為を、詳細タスクによって組み立てられるワークフローに分解していくというものです³³。

利用者に価値をもたらす大まかな行為(例:「製品を購入する」)をエピックとしたとき、以下のように進めます。

1. エピックを達成するために必要な手順・一般的なワークフローを考え、時間軸に沿ってテーマを並べる
2. それぞれのテーマを実装可能なストーリーに分解し、優先順位に基づいて縦に並べる

これをエピックごとに繰り返すことで、プロダクトが必要とするユーザーストーリーが収集できます。

ストーリーマップ

非機能要件

非機能要件はシステムアーキテクチャに大きな影響を与え、時に不可逆な判断が必要になります。 このためこの段階で、非機能要求グレードを参考に、事業オーナーと非機能要件を定義しましょう。 一方、非機能要求グレードで定められる全項目について非機能要件を定義するのは、スモールスタートを目指す新規事業に対してはオーバースペックです。 この非機能要件定義を軽量化するために、以下のような進め方を行いましょう。

非機能要件グレードには3種のモデルシステムとそれらモデルシステムに紐づく非機能要求の例が示されているため、 これをベースにすることで、非機能要件の大枠を定めることができます。

モデルシステムのイメージ

(非機能要件グレード³⁴より引用)

あとは、具体的な項目に関するモデルシステムと開発対象プロダクトとの要件の差を確認しましょう。具体的には以下の手順となります。

1. 非機能要求グレードに含まれるモデルシステム3種を参考に、システムが機能低下/利用不可能な状態になった場合の影響の程度、システムの役割として開発対象プロダクトにもっとも近いモデルシステムを選択する
2. 選択したモデルシステムと開発対象プロダクトとの非機能要件の差を、事業オーナーと確認する
3. 非機能要求グレード中の「重要項目」³⁵を対象に、それぞれの項目に対する非機能要件を事業オーナーと合意する

サービス開発に要する期間及び工数の算出

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

見積もり

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

• リスクを検知し、対策を計画に組み込むことでプロジェクトの成功可能性を高める
• 実際に開発した場合、どのくらいの期間や予算、体制が必要になるのかを知る

ユースケースや業務フロー、機能一覧を対照し、要件や仕様に曖昧な点がある場合は、事業オーナーに確認します。 見積もりでは、要件整理とは違った視点でプロダクトを眺めることもあると思います。要件整理時には出てこなかった仕様がないか再度確認しましょう。 また、見積もり作業により、内在するリスクについても見えてきます。

• 利用したことのないSaaSとの連携
• 特定の業務フローの解像度の低さ

こういった点は、リスクの大きさをチームで検討し、適切な対策あるいはリスクに備える時間を見積もりに反映する必要があります。この方法については後述するアプリ見積もりの章を参照ください。

MVP開発を行った場合、MVPを引きずらず新たに開発することをまず検討します。MVP開発とサービス開発とでは規模も目的も違うためです。ただし、再利用できる部品は流用しても構いません。

MVP開発の際は、MVPにおいて必要な機能のみを作ることに重きを置いていましたが、サービス開発では今後サービスを拡大するために必要になる保守性や、拡張性に重点を置きます。

ユーザーストーリーごとに見積もりを算出する

見積もりは、開発一式でいくらといったような出し方はせず、ユーザーストーリーごとに算出します。ユーザーストーリーごとに算出するのは、後述する開発スコープの調整において大事な役割を果たすからです。 また、アプリ開発部分はもちろんですが、アプリを運用するためのインフラの見積もりも算出します。

アプリ見積もり(プロダクト)

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

見積もり手法は見積もりの進め方をご参照ください。ポイントベースの見積り方、リスクの見積もりへの反映手法を記載しています。

インフラ見積もり(プロダクト)

インフラの見積もりには以下の2種類があります。

• 初期構築時のアーキテクチャ設計やインフラ構築工数の見積もり
• サービスリリース後の運用保守費用や毎月のインフラ費用の見積もり

アーキテクチャ設計・インフラ工数見積もり

必要なインフラアーキテクチャは事業ごとに万別であり、事業ごとに設計し見積もる他ありません。 一方、本書で扱う技術に示したように、我々はSPA+REST API構成でのサービス提供を基本として考えています。 これらのアーキテクチャ例は、DevOps環境構築キット Eponaで提供しています。

• SPAのサーブ
  • cacheable_frontend
• REST APIサーバーのサーブ
  • public_traffic_container_service
• SPA静的コンテンツ用のデプロイメントパイプライン
  • cd_pipeline_frontend_trigger
  • cd_pipeline_frontend
• REST APIサーバー用のデプロイメントパイプライン
  • cd_pipeline_backend_trigger
  • cd_pipeline_backend

また、AWS上でインフラを実現する際のベストプラクティスはAWS Well-Architected フレームワークで示されています。 これらを意識した構成を検討してください。

インフラ運用費用見積もり

少なくとも1年間、出来れば5年間のインフラ運用費用の見積もりを算出します。 この費用の算出に影響がある要素の例をいくつか列挙します。

項目	影響範囲
ユーザー数	RDSのディスクサイズ
アクセス数	ECS Fargateのスペック、同時起動数 RDSのスペック、インスタンス数 Cloud Watch Logsへのログ量
ユーザーによるデータアップロード	S3バケットのストレージ使用量
ユーザーによるデータダウンロード	CloudFrontからインターネットへの転送量

事業化準備ステージ

事業化準備とは、事業を運営するための体制作りやサービス開発等、事業化に向けた準備をし、リリース判断を行います。

アクティビティ	概要
JV設立・事業部化	事業化する際に最適な推進体制を選択するステップです。
オペレーション/人員設計	オペレーションの流れと必要な人員を設計するステップです。
会議体設計	事業の進捗を適切にマネジメントするために、適切な会議体を設計するステップです。
サービス開発	事業の開始に向けて、本格的にサービス開発を行うステップです。
リリース判定準備	開発したサービスをリリースするかどうか判断するステップです。

JV設立・事業部化

概要

事業化後の最適な推進体制と資本政策を検討するステップです。「事業計画策定」の中で検討した出口を改めて検討/具体化します。 事業の特性によって、どのような推進体制が望ましいのかを検討し、事業の管理や拡大にとって重要な資本政策を策定します。

実施手順

1. 事業の特性を整理する

下記のような事業の特性によって、適した推進体制が異なります。まずは検討中の事業の特性を整理しましょう。

• 事業領域における自社アセットの優位性
  • 自社のアセットがその事業領域で勝ち残るための重要な鍵になるか
  • 他社のアセットへの依存度が大きいか
• 事業が自社に及ぼすリスクの大きさ
  • ブランドイメージのダウンにつながる可能性が高いか
  • 不確実性が高く、事業の失敗が自社の既存事業や企業評価低下につながる可能性が高いか
  • 既存事業や取引先と顧客を奪い合うような事業で、反発が生まれる可能性が高いか
• 事業推進に求められる自由度やスピード
  • 既存事業部での進め方やスピードだとチャンスを逃す可能性が高いか

2. 適した推進体制を選定する

以下の図は、適切な推進体制を検討するために単純化した条件分岐です。1で整理した特性をもとに最適な推進体制を選定しましょう。

推進体制の検討観点

3. 資本政策を検討する

資本政策とは、事業資金を調達するために立てる計画のことを指します。策定した事業計画をもとに、将来的に必要になる資金を見積り、計画的に確保していきます。ただし、必要以上に株式を発行してしまうと、経営権を奪われたりするリスクがあるため、計画的な資本政策が重要となります。

資本政策のゴールを定める

最初に資本政策のゴールを設定します。例えば、株式公開を目指すのか、上場せず事業運営で獲得した自己資金や銀行からの借入金で事業を運営していくのかを定めます。株式公開を目指す場合、JPX(日本取引所グループ)が定めている上場審査基準があり、その数値が目標値となります。

財務数値を予測する

これまでの実績や類似上場企業の財務数値を参考にし、将来的な予想損益計算書、予測貸借対照表、予想キャッシュフロー計算書を作成します。

「誰に」「いつ」「どんな方法」で資金を得るのかを検討する

予測した財務数値と目標値を比較することで、現状と目標のギャップが把握できます。そのギャップを埋めるために、「誰に」「いつ」「どんな方法」で資金を調達するのかを検討します。

• 「誰に」
  • 投資家、ベンチャーキャピタル、取引先、役員、従業員等
• 「いつ」
  • シード、アーリー、シリーズA、シリーズB、シリーズC等
• 「どうやって」
  • ストックオプション、従業員持株会、第三者割当増資等

資本政策表を作成する

上記で検討したゴールや資金調達の計画をもとに、資本政策表を作成します。

資本政策表

コツ/注意点

出口戦略はなるべく早く検討すべき

事業化直前で初めて出口戦略を検討してしまうと、立ち上げに時間がかかってしまいます。事業の特性自体は初期段階でも整理できるため、出口の選択肢を確保しておき、事業化が近づいたときにスムーズに移行できるよう、準備を整えましょう。

資本政策で攻めるタイミングを見極める

資金は多ければ安心できますし、資金の利用用途は沢山思い浮かぶでしょう。しかし、資金政策に失敗すると、会社や事業をコントロールできなくなります。市場の動向を踏まえて、いつ資金を投入して勝負に出るのかを見極めることが大切です。

オペレーション・人員設計

概要

オペレーションの流れと必要な人員を設計するステップです。商品・サービスを提供するために必要な業務を洗い出し、必要な人数を算出します。

実施手順

オペレーション設計および人員設計は、一般的に以下の5つの手順があります。

1. 「何」のオペレーションを設計するのかを決定する

利用申し込み時があった際のオペレーションや問い合わせがあった時のオペレーション等、切り取る対象によって、オペレーション内容は異なります。まずは設計する対象を選定しましょう。

2. 事業に関わる主要な関係者を洗い出す

オペレーション設計の対象が決まれば、次にその業務に必要な関係者を洗い出します。

例）

• 事業企画
• カスタマーサポート
• セールス
• 契約・法務確認
• アフターサービス
• 請求

3. 関係者のオペレーションフローを記載する

以下の図は問い合わせがきた際のオペレーション図の一例です。作業が発生する条件やアウトプットを明確化することで、わかりやすいオペレーション図を書くことができます。

• インプットが何か
• どのようなプロセシング(処理)をするか
• アウトプットは何か

オペレーション・人員設計

4. 関係者毎に対応に要する時間を設定する

• 関係者毎に1つの問い合わせを完了させるまでに要する時間を設定する
• 関係者毎に1日で対応可能な問い合わせ数を算出する

5. 必要な人員を算出する

収支計画で算出した顧客数から問い合わせ数を試算し、関係者毎に必要な人員数を算出する。

コツ/注意点

業務の開始と終了のタイミングを押さえる

作業がいつ始まるのか、いつ終わるのかがわからないと、流れが把握できず、間違ったタイミングで作業を設計してしまう可能性があります。担当者に確認をとり、明らかにしておきましょう。

条件分岐がある場合、分岐した場合の作業を明確にする

業務フローに意思決定など条件分岐がある場合、どのような条件によって分岐するのかを明確にします。

サービス開発

概要

事業の開始に向けて、本格的にサービス開発を行うステップです。 システム開発の場合は、何を作るのかを大まかに決めてから、どう作っていくのか具体的に設計し、開発していきます。 システム開発以外のサービスの設計においては、前述した『オペレーション/人員設計』を参考に設計し、実際にオペレーションが問題なく回るかどうか、求められる水準に達しているかどうかを繰り返しテストしてください。

実施手順

具体的な進め方については、後述の開発プロセスを参照してください。

コツ/注意点

スケジュールを決め、進捗管理を徹底する

開発する要件が決定した後、具体的な開発スケジュールを作成し、進捗管理を行います。特に関係者の確認/レビューが必要な部分は、いつまでに確認結果が欲しいのか等のスケジュールを明確にできていないと、進捗に遅れが生じてしまうことが多くあります。「いつまでにどのような状態になっている必要があるのか」「誰が今、どのような業務を担当しているのか」等を明確にして進めましょう。

開発プロセス

概念実証(SPF)ステージを通過した事業では、実証された事業仮説と収益の得られる事業計画が手元にあります。 一方で、MVPでは成立したはずの仮説が、プロダクトをリリースしてみたら間違っているということも新規事業開発においては起こり得ます。

開発に多大な時間とお金をかけてリリースしたものの、仮説が外れていたために売上を確保できなかった場合、 損失も大きく事業継続が困難になる可能性があります。

そのため、短いスパンで製品をリリースし、ユーザーに使ってもらい手応えを掴みながら改善を繰り返し、より良いものを目指しましょう。 顧客の要求や市場の変化に素早く柔軟に対応し、改善を重ねながら開発を進められるのがアジャイル形式です。我々は、その実践手法としてスクラムを使います。

アジャイル・スクラム

概念実証(SPF)ステージでもスクラムを利用していましたが、本ステージでは開発チームの規模も大きくなります。 開発を円滑に進めようと思うと、まずはアジャイルの基本となる考え方を関係者全員が理解し、開発をチームで自律的に推進できるようになる必要があります。

まずは、チームの中でロールを決めましょう。 基本的なロールの考え方を図示します。

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

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

スクラムの基本となる考え方、開始準備、開発における特徴については、Fintanで公開されている以下のコンテンツを参照してください。特に、スプリント開始条件チェックリストで開始できる状態にあるかをチェックしてください。

見落とされがちですが、スプリント期間およびスクラムイベントの設定は重要です。 スクラムガイドではスプリント期間は1ヶ月以内であると明記されていますが、1週間あるいは2週間がおすすめです。スプリント期間が短くなるほど、スプリントイベントに費やす時間割合が大きくなり相対的に開発時間が短くなってしまいます。しかし、その分だけチームの改善は進み、計画の精度も高くなります。 一般に、スクラムに不慣れなチームほど、一週間スプリントの方が望ましいとされています。以下も合わせてご参照ください。

• Q. 初めてのスクラムでは、スプリント期間はどれくらいがおすすめですか？スプリント期間を決める上でのポイントはありますか？

以下に、スプリントイベントそれぞれの目的と、2週間スプリントの所要時間の目安について記載します。 なお、目的はスクラムガイドから抜粋しました。

記述すべきドキュメント

本格的にスクラムで開発を進めるにあたり、どこまでドキュメントを整備するのかはいつも問題になります。

プロセスやツールよりも個人と対話を、 包括的なドキュメントよりも動くソフトウェアを、 契約交渉よりも顧客との協調を、 計画に従うことよりも変化への対応を、 価値とする。

上記はアジャイルソフトウェア開発宣言の一節ですが、 ドキュメントに価値がないと言っているわけではありません。新規事業開発でも、どこまで設計をドキュメントに記述するのかの方針が必要となるでしょう。

最初期には、記述すべきドキュメントは揃っていないかもしれませんが計画的に以下のドキュメントを揃えるように活動することが重要です。 保守・運用の資料はリリースまでに揃っておけば良い一方で、アーキテクチャや各種方式の実現方法(方式設計)については、共通理解を醸成するために初期から「継続的」にメンテナンスしていく必要があります。

新規事業開発は、プロダクトもそれを支えるシステムも、時事刻々と変化していきます。 このためドキュメントについても「継続的に」更新し、一貫性を持たせ、システムの状態を常に反映させるようにしましょう。 この継続的なメンテナンスを行うためには、後述する「完成の定義」に、ドキュメントの更新を含めておくと良いでしょう。

1st. リリースまでの全体像

新規事業開発における開発の全体像は下図で示す形になります。

1st. リリースまでの全体像

スプリント0

スプリント0は、本格的な開発を始める前の準備期間になります。ここでしっかりと準備ができない場合、後続となるスプリントが空回りしてしまいます。しっかりと準備しましょう。

準備すべき内容については、スプリント開始条件チェックリストを参照していただければと思いますが、主となる準備内容は以下になります。

1. ステークホルダーに対して、スクラムの価値観や進め方、報告内容について共有されていること
2. プロダクトの価値、開発する対象やその規模感が明らかになっていること
3. スクラムチームが構築されていること
4. リリースプランや開発の進め方、完成の定義が合意されていること
5. チームビルディングが完了していること
6. アーキテクチャや開発・テスト環境が提供されていること
7. チーム作業を支えるファシリティの準備が済んでいること

こちらの資料もぜひ参考にしてください。

• Scrumプロジェクト開始のベストプラクティス #RSGT2018

スプリント

決定したタイムボックスのスプリントを重ねていきましょう。

スクラムのスクラムイベントは、それぞれが確固とした目的を持っています。 忙しくなってくると各イベント開催の負荷が気になり省略したくなることもあるかもしれませんが、目的をしっかり理解し、粘り強く開催しましょう。徐々にチームがその開発に適応してくるはずです。

また、開発を続ける限り、プロダクトバックログを更新していきましょう。開発中のプロダクトがある限り、プロダクトバックログの変更が止まることはあり得ません。新たなアイテムの追加や既存アイテムの変更に応じ、見積もりを行い優先度を設定し直しましょう。

各スプリントで開発した成果物(インクリメント)は、スプリントレビューにてプロダクトオーナーやステークホルダーに確認してもらいましょう。 プロダクトのゴールを達成するのに十分に価値を感じるものになっているのかというフィードバックをもらい、より価値のあるプロダクトへと昇華させます。

スプリント

テストスプリント

理想的なスクラムにおいては、各スプリントで「出荷可能」なプロダクトが構築されているのが理想です。 しかし毎スプリントで「出荷可能」と判断できるだけの品質を確認するためには、チームに相応の負荷がかかり、 開発が思うように進まないことも多いです。

そこで、アプリケーションの総合的な品質を確認するため、リリース前にテストスプリントを配置します。 このスプリントにて、「出荷可能」なプロダクトになっていることを担保します。

注意していただきたいのは、テストスプリントがあるからといって通常のスプリントで品質担保を疎かにすべきというわけではないことです。スプリント単位で、おおよそ問題ないと言える程度の品質を担保しなければ、テストスプリントで大量の不具合が発覚することになります。

全体テスト計画

プロダクトの品質を担保するにあたり、スプリント0で作成する「完成の定義」が出発点です。以下にスクラムガイドの定義を引用します。

完成の定義とは、プロダクトの品質基準を満たすインクリメントの状態を⽰した正式な記述である。

前章のスプリント構成で進める場合、どのテスト観点を各スプリントで担保し、どのテスト観点をテストスプリントで担保するのかを明確にしましょう。 各スプリントで扱うテスト観点を多くするほど各スプリントのインクリメントの品質が担保されますが、 テスト時間(自動化したとしても、そのテスト整備の時間)が増えていきます。

どのテスト観点をどちらで扱うのかは事業の特性やチームの実力にも依存しますが、だからといって0から考える必要はありません。 まず、アジャイルなプロジェクトにおけるテストは「アジャイルテストの4象限」³⁷で整理されます。

アジャイルテストの4象限

アジャイルテストの4象限は、「開発支援」「プロダクト評価」「ビジネス観点」「技術観点」の4象限でテストを整理したものです。 開発支援に該当する左側の象限に該当するテストは、自動化を検討しスプリント内で担保しましょう。 逆に、プロダクト評価に該当するものについては、プロダクトの全体像がある程度見えた段階でテストを実施します。ここでのテストは「テストスプリント」まで持ち越すのではなく、できるだけ早い段階で露払いを行いましょう。最後までこれらを実施しないままの場合、リリース直前まで大きなリスクを内在したままになってしまいます。

基本的な方針として以下を定めます。

進捗管理

本章の記述は、エッセンシャルスクラム³⁸を参考に、いくつかのカスタマイズを行なって記述したものです。

スクラムで進める開発であっても、「いつリリースできるのか」という問いには答える必要があります。そのためには、ある程度の長期にわたる計画を立て、その進捗状況をトラックしなければなりません。 本書では、長期にわたる計画の立案を「リリースプランニング」と呼びます。

リリースプランニングではリリースの制約を明らかにする必要があります。一般に主な制約となるのはスコープ、期日、予算の3つであり、リリースごとに制約の組み合わせが以下のどちらになるのかを検討します。

この判断は、継続的に行う必要があります。後述する進捗の可視化で進捗上の問題が検知された場合に、見直しを行いましょう。

固定スコープのリリースプランニングと進捗管理

スコープが固定の場合のリリースプランニングは以下の手順になります。

1. スコープに含まれるプロダクトバックログアイテムを詳細化し、そのサイズを見積もる
2. スコープに含まれるプロダクトバックログアイテムの見積もりについて、合計サイズを計算する
3. チームのベロシティの範囲を決める
4. 合計サイズを最も遅い場合のベロシティで割り、端数を切り上げる。これがリリースに最低限必要なスプリント数となる
5. 合計サイズを最も早い場合のベロシティで割り、端数を切り上げる。これがリリースに必要となるかもしれない最大のスプリント数となる

このリリースプランニングにより、「対象スコープの開発を完了させるためには○回から○回のスプリントが必要になる」という答えが得られます。回答が範囲になっている通り、ここに不確かさが残ることは避けられません。 しかし前述した不確実性コーンが示す通り、時間が経つにつれてその不確実性は下がっていき、次第に信頼性の高いものになっていくはずです。

不確実性コーン

開発の進捗状況を掴むためには、バーンダウンチャートを使います。 固定スコープの場合のバーンダウンチャートは、現在のリリースのゴールに達するまでの残作業の量をスプリントごとに示す、右肩下がりのグラフになります。 以下が、エッセンシャルスクラム³⁹から引用したバーンダウンチャートの例となります。これを事業オーナーやステークホルダーの常に見える場所に配置し、進捗状況を共有しましょう。

リリースバーンダウンチャート

固定期日のリリースプランニングと進捗管理

期日が固定の場合のリリースプランニングは以下の手順になります。

1. リリースまでのスプリント回数を計算する
2. プロダクトバックログを適切な詳細度まで分割し、優先順位を決める
3. チームのベロシティの範囲を決める
4. 最も遅い場合のベロシティと1.のスプリント回数を乗じ、そのポイント分のプロダクトバックアイテムを選択する。これが「完成するであろう」ラインになる
5. 最も早い場合のベロシティと1.のスプリント回数を乗じ、そのポイント分のプロダクトバックログアイテムを選択する。これが「完成するかもしれない」ラインになる

固定期日の場合のプロダクトバックログ

これにより、期日までにどこまでできあがるのかの答えがある程度わかります。ここでも不確実さは排除できませんが、不確実さの程度は次第に小さくなっていくはずです。

アーキテクチャ設計・方式設計

アーキテクチャ設計は、非機能要件と業務要件に左右されるため、どうしても事業ごとの設計が必要になります。 このため、本書でもアーキテクチャ設計のテンプレートを示すことはできません。 以下では、システムのアーキテクチャを設計する上で押さえておかなければならないポイントを説明します。

最終的なソリューション像を描いた上で設計を実施する

アーキテクチャ設計で重要なのは、ビジネスにどのような機能要件・非機能要件が求められるのかを正確に把握し、それをアーキテクチャに落とし込むことです。 この「アーキテクチャに落とし込むべき要件」は、1st. リリースで必要になる要件ではなく、サービスの将来像を見越した要件であることに注意しましょう。 これはアーキテクチャに落とし込むときの判断は時に「不可逆」な判断となり、あとで修正が効かない、あるいは修正するのに多大なコストがかかるためです。

アーキテクチャ設計の際は、事業オーナーと「最終的なソリューション」がどうあるべきかを議論し、システムの変化する方向性を認識しておきましょう。 例えば、将来的にどのような機能を入れていきたいのかを議論するだけでも、アーキテクチャ上のどこに拡張ポイントを用意しておくべきなのかの勘所がつかめます。

保守性を強く意識する

受託開発においては機能適合性やセキュリティが重視されがちですが、自ら運用し素早く成長させていく新規事業においては、保守性を強く意識しなければなりません。 なぜなら、保守性こそがアジリティの根源であるためです。 ぜひt-wadaさんが公開されている以下の資料をご一読ください。

保守性の高いソフトウェアアーキテクチャを設計するためには、「保守性」の品質副特性を把握しておく必要があります。 以下の図はソフトウェア品質モデルSQuaREに関するつながる世界のソフトウェア品質ガイド～あたらしい価値提供のための品質モデル活用のすすめ～からの引用ですが、保守性の品質副特性は以下となっています。

• モジュール性 (Modulability)
• 再利用性 (Reusability)
• 解析性 (Analyzability)
• 修正性 (Modifiability)
• 試験性 (Testability)

システム/ソフトウェア製品品質

これらは一般的なソフトウェアアーキテクチャでも作り込みが必要なものであり、本書での言語化は控えますが、新規事業開発ではこれらを強く意識したアーキテクチャ設計が必要な点を理解してください。

新規事業開発では、短いスパンで製品をリリースすることが求められるため、これらの品質(内部品質)を犠牲にしてスピードを優先するといった判断が行われることは少なくありません。 しかし、これらの品質を犠牲にすることでシステムの保守性も犠牲になるため、短期的なスピードが得られようとも、中長期的には逆効果になります。この損益分岐点は数週間だとされている⁴⁰ため、内部品質を下げるという判断が行われないようにしましょう。

環境を明確に分離する

本番環境とそれ以外の環境は、明確に分離する必要があります。 開発環境の変更が本番環境へ影響することはあってはなりませんし、同様にステージング環境の脆弱性によって本番環境で情報漏洩につながることも避けなければなりません。 また、多数の開発者が本番環境上の個人情報にアクセスできるのは望ましくなく、厳密なアクセスコントロールも必要になるでしょう。

これらを防ぐため、アプリケーションが動作する環境(開発環境や本番環境等)に対してそれぞれ異なるAWSアカウントを用意する形で環境を分離することを基本形とします。なお、本書ではこの「アプリケーションが動作する環境」のことをRuntime環境と呼びます。 サービス開発当初、Runtime環境については開発環境と本番環境の2環境とし、オンデマンドで増やしていくのが良いでしょう。 DevOps環境構築キットEponaでも同様の構成をとるため、必要に応じてご利用ください。

Eponaでの環境分離

アプリケーション方式設計

サービスを開発する上では、 開発者が開発時にどのような方式で実装すればよいのか、ある程度ルールを定めておく必要があります。

その最大の目的は開発者内での意識合わせです。個々の開発者が例えばブラウザのキャッシュ制御をばらばらに違った方式で実装したらどうなるでしょうか？　簡単には修正できないプロダクトの出来上がりです。サービス開発では保守性の高いプロダクトを作るべきです。

また、後から入った開発者に対して説明するための資料・ドキュメントとしても活用できます。 開発・運用から学びを得て変化を繰り返し続けるサービス開発で常に最良の判断をし続けるためには、「なぜそのアーキテクチャを採用したのか」「なぜこの実装方式を選択したのか」という動機を追跡可能にしておかねばなりません。 最初から最後まで、さらにリリース後の保守まで同じ人が関わるとは限りませんし、そうであっても全てを記憶しておくことは難しいのです。

方式設計はスプリント0での実施を推奨します。実際に開発へ入る前にルールを制定しておくと、スムーズに開発を始められます。

方式設計の例を以下に列挙しておきます。 また、方式設計書についてはサンプルがあります。こちらのサンプルをすべて網羅する必要はありませんが、参考にしてください。

• アプリケーション方式設計書サンプル | Nablarch | Fintan

アーキテクチャ・方式設計の管理

アジャイルで進めるプロダクトにおいては、システムのアーキテクチャが一度で決まるわけではありません。そういったとき問題になるのは、以下の点があります。

• アーキテクチャ上重要な意思決定が特定の開発者だけで行われ、他の開発者が設計の動機や目的、経緯を理解できない
• アーキテクチャ変更を変更する際に、すでに解決されている課題が後の変更で再発してしまう
• 新規アサインメンバーへの情報の共有に時間がかかる

このような問題の結果、設計当時と事業のコンテキストが変わっていたとしても既存のアーキテクチャを変更すべきかという判断もできなくなり、事業の変化に追随できなくなってしまいます。

このような課題を、我々はADR(Architecture Decision Records)を導入して解決します。 ADRとは、「アーキテクチャ上重要な意思決定」を、そのコンテキストや結果とともに記載した文書になります。 Architecture Decision Recordsの導入例・効果・運用については以下をご参照ください。 Architecture Decision Records導入事例

ADRのフォーマットは種々ありますが、ADRを作成・運用するコストを最小限に抑えるため、我々はMichael Nygardのフォーマットを利用します。 長いADRを書いても運用の負担になるため、1-2ページで収まる程度の分量を目安とします⁴¹。

# タイトル

## ステータス

提案中、受理、拒否、非推奨、等のステータスを記載する。

## コンテキスト

ADRが対象とする技術的・政治的・組織的な問題を記載する。
本記述内容は、中立的に事実のみを記載すること。

## 決定事項

ADRで提案する変更・実施事項を記載する。

## 結果

ADRの内容をプロジェクトに適用した際の結果を、良い面・悪い面の双方について記載する。

開発

ここでは、開発にあたっての開発プロセス上のプラクティスを記載します。

ブランチ戦略

我々が利用するのはGitLab Flowです。

GitLab Flowでは、環境ごとに対応するbranchを用意します。 下図の例では、開発環境にdevelop branch、本番環境用にproduction branchを用意しています。 develop branchの内容が開発環境に反映され、production branchの内容が本番環境に反映されます。

GitLab Flow

新機能を開発する開発者はdevelop branchから機能開発用branch(feature branch)を作成し、当該branchにて開発します。 テストとレビューを通過したら、develop branchにマージできます。開発環境に反映し、そこで実環境でのテストを行いましょう。 開発環境でテストし正しい振る舞いを行うことが確認できれば、production branchにマージし、本番環境に反映します。

このようにGitLab Flowでは、環境に対応するリリースブランチが存在すること、mergeが単方向で行われることに特徴があります。 これにより、各環境にデプロイするバージョンをコントロールできるとともに、本番環境にデプロイされるコードはそれ以前の環境でテスト済みであることが担保できます。

ピアレビュー・プルリクエスト駆動開発

システムを開発する際は、アプリケーションやインフラを何度も変更することになります。 その変更はチーム内のピアレビューにてその品質を担保しましょう。ピアレビューは、変更の品質を向上させるだけでなく、相互訓練、ピアラーニング、スキル向上の効果を持っています⁴²。

ピアレビューを確実に行うために、開発チームではプルリクエスト駆動開発を行ってください。 「The DevOpsハンドブック　理論・原則・実践のすべて」の記述を参考にすると、おおよそ以下のような開発スタイルになります。

1. 何か新しく作業を始める際、エンジニアはわかりやすい名前（たとえば、“newoauth2scopes”）をつけたブランチを分岐させる
2. エンジニアはローカルのそのブランチに修正をコミットし、定期的にサーバーの同名のブランチに作業内容をプッシュする
3. フィードバックや支援が必要なとき、あるいはブランチをマージする準備が整ったと思ったときに、エンジニアはプルリクエストを送る
4. ほしいと思っていたレビューが送られ、マージのために必要な承認が得られると、エンジニアはブランチをマージできる
5. コード変更がマージ、プッシュされると、エンジニアはそれを本番環境にデプロイする

プルリクエストの駆動開発は、以下のメリットがあります。

• 変更点や課題が見えやすいためマネジメントを行いやすくなる
• コードの書き方や注意点を学ぶことができる
• プルリクエスト送ることでコードをレビューする文化が身に付き品質が高まる
• コードについて議論することで途中段階から素早くコードの書き方や設計等のフィードバックを得ることができる

Infrastructure as Code (IaC)

我々はインフラもコードで記述し、バージョン管理、上の述べたブランチ戦略、プルリクエスト駆動開発の実践をインフラ開発でも行います。

手作業でインフラを構築する場合、最初の段階では一貫性を保ちながら構築・設定しても、時間が経つにつれて一貫性が失われ、管理も難しくなります。これが、絶えず変化が必要な新規事業開発にとって強く足枷になります。 例えば、以下のような課題が代表的です。

• 本来同じ設定であるはずのサーバー群の1台のみ誤った設定をしてしまう (構成ドリフト)
• 他のサーバーとの差異が管理されず、誰も当該サーバーに手が触れられなくなる (スノーフレークサーバー)

これを防ぎ、インフラが変化の足枷にならないためには以下のような原則を守らねばなりません⁴³。これを実現することがIaC導入の目的です。

1. インフラの任意の部分を簡単に変更・再構築できること
   • 構成変更・設定変更を行う際に恐怖感がない
   • 再構築するときに各種の判断が不要
2. インフラが統一的であること
3. インフラの構築プロセス・設定変更プロセスが反復可能であること (そうしないと自動化できず人為的ミスを誘発し、結果として変更を恐れるようになってしまう)

IaCツールとしてはTerraformを利用します。DevOps環境構築キットの提供するモジュールを利用することで、IaCを利用して開発を効率化可能です。

継続的インテグレーション(CI)

複数の開発者が個別のbranchで自分の作業を進めると、それぞれの作業を統合(merge)するときに問題が発生しやすくなります。例えば、以下のような事が起こり得ます。

• 開発者Aが使う共通コンポーネントを開発者Bが修正しており、結果として開発者Aの開発した機能が正しく動作しない
• 開発者Aと開発者Bが同じコンポーネントに変更を加えてしまい、mergeしたときに整合性が取れなくなる

複数人で開発するときにはこのような問題は不可避ですが、その影響を小さくするプラクティスが継続的インテグレーション(CI)です。 変更を可能な限り頻繁にメインとなるブランチ(develop branch)にマージすることで、mergeしたソースコードに対してテストを実施し早期にフィードバックを得られます。 これによりアプリケーション全体に影響のないことが確認でき、自動化されたテストによってアプリケーションを素早く容易に高頻度で改修できます。

CIを実践する上で開発チームは以下の点を心がけてください。

1. テストコードを記述する
2. 頻繁にdevelopブランチにmergeする (変更するバッチサイズを小さくする)
3. 自動化できるレビューポイントは自動化する

頻繁にdevelopブランチにmergeすることがCIの要諦です。そのためには変更するコード量を少なくしなければなりません。 変更するコード量が少なければ、レビューのスピードと質は向上し、mergeも頻繁に行えます。 以下は「The DevOpsハンドブック　理論・原則・実践のすべて」⁴⁴から引用した図ですが、変更量が大きいほどレビューに時間のかかることがわかります。 レビューに時間がかかるほど、mergeが遅れ、CIが有効に機能しなくなります。また、開発者にとっての待ち時間も多くなり、リソース効率を削ぐことになるでしょう。

レビューのリードタイム

本書ではVCS ProviderとしてGitLabを利用します。 このため、CIを実装するときはGitLab CI/CDを使います。

静的チェック

静的解析では、ソースコードや設定ファイルを解析し、特定のコーディングパターンに違反している箇所をチェックします。 これにより開発の極めて早い段階でエラーを検出できるとともに、優れたコーディングスタイルを推進でき、可読性や保守性も向上します。 また、機械的に指摘できるエラーを摘み取ることもできるため、ピアレビューではより高度な問題にも集中できるようになります。たとえばJavaでは、SpotBugsやCheckstyleが静的解析ツールの代表例でしょう。

具体的な実装例としては、example-chatでの適用例をご参照ください。例えば以下が参考になります。

• GitLab CI/CDでの静的解析を含むステップの定義
• Mavenを使ったtestライフサイクルの実行
• pom.xmlへのSpotBugsの組み込み

ユニットテスト

アプリケーションのコードが期待通りに振舞うことを検証する基本となるのがユニットテストです。 継続的インテグレーションがもたらす核でもある「素早いフィードバック」は、ユニットテストのカバレッジが十分にないと可能になりません。素早く実行でき、カバレッジの高いユニットテストを記述していきましょう。

具体的なサンプルについては、上述の GitLab CI/CDでの静的解析を含むステップの定義をご参照ください。

CIをパスしないコードをマージさせない

継続的インテグレーションにとっての最大の過ちは、壊れているコードをチェックインしてしまうことです。 パイプラインをパスしないコードについては、マージさせてはならず、開発者は直ちに修正しなければなりません。 これは、この状態で変更をマージしてしまうと以下のような問題が発生するからです。

• 原因を特定しコードを修正するのに時間がかかるようになる
• コードが壊れている状態にチームが慣れてしまい、常に壊れたままの状態に陥ってしまう

GitLabでは、パイプラインを通過していないコードをマージさせないようにできます。 設定方法についてはOnly allow merge requests to be merged if the pipeline succeedsをご参照ください。

継続的デリバリー(CD)

デプロイが不安定な場合、デプロイそのものがリスクになります。 結果としてデプロイ作業は重くなり、例えば半年に一度しかデプロイができないなど、事業が目指すべき素早い改善とかけ離れた状態になります。 このような状態をもたらす、デプロイのアンチパターンとして以下が知られています⁴⁵。

1. ソフトウェアを手動でデプロイする
2. 開発が終わってから擬似本番環境にデプロイする
3. 本番作業について手作業で構成管理を行う

安定したデプロイを手に入れることで、本番デプロイもリスクではなくなり、高頻度なサービスの改善が可能になります。 これを行うためのプラクティスが継続的デリバリーです。

デプロイ作業は自動化し、デプロイメントパイプラインに組み込みましょう。 アプリケーションによってデプロイ作業は様々ですが、AWS CodePipelineなどを組み合わせれば、自動化は難しくありません。

以下はDevOps環境構築キット Eponaの方法ですが、Eponaを使わずとも、同様の構成でCDを実現できます。

• アプリケーションコンテナを無停止でデプロイできる
• 静的コンテンツを無停止でデプロイできる
• サーバーレスアプリケーションをデプロイできる

会議体設計

概要

事業の進捗を適切にマネジメントするために、適切な会議体を設計するステップです。事業の規模や状況によって、設定すべき会議は異なります。事業化後は、顧客からのフィードバックや問い合わせの数、事業の関係者の数等が一気に増加します。また、システム開発を通じて、商品やサービスも変化していきます。このように事業化後は、調整の必要性が高まるため、無駄な会議によって時間を浪費しないために、ここで適切な会議体設計の方法をご紹介します。

実施手順

会議体設計は以下の3つの手順で実施します。

1. 会議の目的を定義する

2. 会議体を選定する

3. 目的を踏まえて、参加が必要な関係者を洗い出し、頻度を設定する

コツ/注意点

会議が本当に必要か考える

会議は参加者を拘束することになるため、メールや書類での報告等、会議以外での手段で代替できないかを検討してみましょう。

アジェンダ(議題)を設計する

会議を効率的・効果的に運営するために、アジェンダを設計し、関係者に対して事前に展開しておきましょう。

ゴールを明確にする

その会議がなぜ開催されているのか、どうなれば会議の目的が達成するのかを明確にすることで、無意味な議題で時間を消費せず、効果的な会議運営につながります。

事業性確認・事業性拡大ステージ

事業性確認・事業性拡大

概要

事前に立てていた収支計画と実績値を照らし合わせ、大きなギャップがある場合は原因を分析し、事業の改善と更なる拡大を目指して施策を検討するステップです。

実施手順

事業性確認・事業性拡大は以下の3つの手順で行います。

1. 収支計画と実績値を比較し、ギャップがある項目を洗い出す

「売上高」や「費用」といった結果だけを見るのではなく、「顧客数」や「平均単価」等の結果を構成している項目に注目し、予想とギャップがあった項目を見つけましょう。

2. AARRR指標を参考に、ギャップの原因を深堀りする

• 1で確認した「ギャップがある項目」に関して、そのギャップを生み出した原因を深堀りします。AARRR指標を参考にすると、顧客がどのフローで止まったのか等を明らかにすることができます
• 例えば、「顧客数」が少なかったのは、訪問数が原因か、注文ページまでの画面構成が原因か等が確認できます

3. 打ち手を検討し、実施する

2で洗い出した原因を踏まえて、実施すべき施策を検討し、実施します。

• 購買単価の向上：関連商品のレコメンド/会員ランク等
• 購買頻度の向上：プッシュ通知等
• 平均継続期間の伸長(解約率の低下)：ポイント制度等
• コストの削減：仕入れやチーム体制見直し等
• CVRの向上：画面遷移等の改善/チュートリアル等
• 広告費の削減：紹介制度/コンテンツマーケティング等

コツ/注意点

「数」ではなく、「割合」を見て顧客の反応の変化を見極める

リリース後は、追加開発や広告予算の拡大等、運営側は様々な施策を打ち出します。その際、顧客の反応がポジティブに変化しているのかどうかを見極めることが重要です。 そのためには、単に「数」を見るのではなく、「割合」を見ることが大切です。 例えば、広告費のコストを多くかければ、露出量が増え、結果的に訪問者数や購入者数が増える可能性が高いです。 このとき、訪問者数や購入者数といった「数」だけを見ると、顧客の反応がポジティブな方向で変化したのかどうか、適切な判断ができません。 「数」が増えている裏側で、効率は下がっている可能性があるからです。 もしも効率が下がっていることに気づかずその施策を継続した場合、多くのコストをかけ続けなければならず、ジリ貧になってしまいます。 一方で、訪問者数に占める購入者数等の「割合」を時系列で見ることができれば、顧客の反応がポジティブな方向に変わっているかどうかを見極めることができ、施策や商品・サービスの改善効果を正しく理解できます。

各ステージの審査

新規事業は一般的に多産多死を前提としており、段階的に検証活動を進め、成功確率を上げる/失敗確率を下げることが重要です。 具体的にはプロセスを数段階の「ステージ」に区切り、ステージの間に「ゲート」を設け、そのゲートで事業アイデアをふるいにかけます。 各ゲートの審査観点と、審査に用いる成果物は以下の通りです。