新規事業を成功に導くPoCの進め方 Part7. 適切な検証サイクル
新規事業のスペシャリストが成功の秘訣を伝授
私、えいるですが普段はITコンサル系企業で、皆さまのビジネスを成功に導くために日々、ITサービスにおける提案・設計・構築などをしております。
また、今の会社に転職する前は、大手IT企業で自ら新規サービスの企画立案・経営戦略策定・営業訪問・サービス構築と0→1の段階で必要なことのほぼすべてを経験してきました。
ITコンサルとしてクライアントの要望を形にしてきた経験
自分でサービス立ち上げた経験
両方の成功体験を知る私の経験から得た「新規事業を成功に導くノウハウ」を皆さんに紹介したく記事を連載しております。
今回のテーマはPoCに軸を通す定量的な評価指標
第5回の記事ではPoCと、その先にある新規事業を成功に導くメソッドとして以下3を紹介させて頂きました。
定量的な評価指標の事前策定
適切な検証サイクルの構築
明確な事業継続の判断基準
第7回となる今回は、そのメソッドから「適切な検証サイクル」をテーマに、PoCのメインとなる構築・検証で最大限の効果を得るための方法を紹介してきます。
PoCの検証サイクルとは?
ここではまず、PoCにおける検証サイクルがどのようなものか、その具体的な進行イメージをみていきましょう。
広義の検証サイクル
PoCがスタートし、計画フェーズで今回の実施目的、スケジュール、検証内容が決まると、その後は以下の3つが順に進みます
構築:今回の検証に必要なアプリやデモサイトを作る
検証:構築したものを想定ユーザーなどに使ってもらい検証する
分析:検証結果を確認し、目的を満たしているかを分析する
この構築から分析までの一連の流れを1サイクルとし、何度か繰り返すことが広い意味での検証サイクルとなります。
例を挙げると以下のイメージになります。
電子書籍が読めるデモアプリを構築
利用者100名に使ってもらいアンケートを実施
アンケートの結果から不評な部分を改善して、再度使ってもらう
後ほど詳しく説明していきますが、この広義での検証サイクルを最低2回は実施することを私は強く推奨しています。
狭義の検証サイクル
実際の検証フェーズが始まると、その中でも構築から分析までの小さなサイクルが生まれることがあります。
先程の電子書籍のデモアプリを例にすると以下のイメージです。
検証中に利用者から明るさを変更したいと要望がある
簡単に対応できるので、その場でアプリを修正
修正後の感触を確認
このように検証フェーズの中で生まれる小さなサイクルを「狭義の検証サイクル」として定義します。
明確に広義・狭義を区別する理由は、後ほど詳しく説明しますが私自身の経験から過度な狭義の検証サイクルは非推奨と考えており、ここに時間をかけすぎるとPoCが失敗に近づくリスクがあるためです。
適切な検証サイクルの構築
それでは、ここかららは実際の検証サイクルをどように計画・進行していけばよいのか、その具体策について紹介していきます。
ポイントとなるのは以下の3つです!!
広義の検証サイクルは最低でも2回は実施する
目的に合わせて構築時間を最小限に絞る
狭義の検証サイクルはなるべく削る
ここから先は
この記事が気に入ったらサポートをしてみませんか?