2つのプロトタイピングで「正しく」「早く」失敗する：新規事業の不確実性との向き合い方（1）
変化が激しい市場において、価値のあるプロダクトを提供するために必要な「新規事業の不確実性との向き合い方」について解説する本連載。第1回となる今回は「新規事業が抱える不確実性とその対処法」について解説する。
この記事は会員限定です。会員登録（無料）すると全てご覧いただけます。
企業の経営を取り巻く環境は急速に変化しています。新型コロナウイルス感染症（COVID-19）の影響もあり、会社の仕組みや事業、働き方を根本的に見直す必要が出てきています。競争優位性を得るために、イノベーションの創出やDX（デジタルトランスフォーメーション）の実現に向けた新しい取り組みを始める企業もあります。
ですが、新しい取り組みには「不確実性」が伴います。それを認識せずに開発の初期段階から多大な投資をしてしまうと「（作ってみたら）想定していた顧客課題が違っていた」「不要な機能を実装していた」「ユーザーインタフェースがユーザーに受け入れられなかった」といった問題が起こりがちです。その結果、プロジェクトの遅延や開発の手戻り、仕様変更などが頻発し、プロジェクトが頓挫してしまうことも珍しくありません。
そこで本連載では、企業の新規事業開発を支援するRelicの知見を基に「新規事業における不確実性との向き合い方」について解説します。第1回は「新規事業が抱える不確実性とその対処法」についてです。
新規事業が抱える不確実性とは何か
新規事業開発に携わる上でまず認識すべきは「新規事業における開発は既存事業での開発とは違うアプローチが必要だ」ということです。さまざまなケースがありますが、新規事業は文字通り「これまでやったことのない新しい事業」ですので、市場や顧客に関する情報がほとんどない状態（不確実性が高い状態）でのスタートとなるからです。
不確実性が高いため、どのくらい予算やリソースを確保すればいいか分からないという問題があります。情報が不足する中で調査や開発を進めることになるため、既存事業開発と比べて成果が出るまでに時間がかかることにも注意が必要です。そのため新規事業開発は「仮説を立て、実際に試してみること」が重要になります。実際に試すことで「分からないこと（不確実性）」を減らしていこうというわけです。
では、新規事業が抱える不確実性とは何でしょうか。
「見積もり」の不確実性
不確実性を表すものとして、ソフトウェア開発における見積もりの難しさを表すときによく取り上げられる「不確実性コーン」という図があります。横軸は時間、縦軸は見積もりスケジュールのブレ（最小と最大の見積もりスケジュール）を示しています。
「初期コンセプト」の時期は不確実性が最も高く、見積もりのブレが大きくなっています。その後、プロセスが進むのに連れて不確実性は減っていき、見積もりのブレは少なくなります（見積もりの精度が上がっていく）。「詳細設計の完了」のプロセスまで行くと、見積もりのブレはほとんどなくなっていることが見て取れます。この図で分かるのは「開発の初期段階における不確実性を下げる取り組みが特に重要である」ということです。
これはソフトウェア開発における不確実性の話ですが、コロナ禍によって「非対面を前提とした新しいサービス」の構築が必要となった現在、大抵の新規事業はソフトウェア開発を兼ねています。新規事業はソフトウェア開発と同じような不確実性を持っていると考えた方がいいでしょう。
「ニーズ」の不確実性
新規事業に携わった経験のあるエンジニアであれば「このサービスは本当にニーズがあるのだろうか」「この機能は本当に必要なのか」などと考えたことがあるのではないでしょうか。
これは先に述べたように、新規事業開発では市場や顧客の情報が不足しているため、「顧客が本当に必要としているものは何か」が分からないのです。
顧客のニーズはサービスの根幹に関わる重要な要素です。「多分これが必要なんだろう」と十分な検証をせずに開発を進めてしまうと、投じたコストや時間の割には成果が得られない事態になりがちです。
実際の例を紹介しましょう。料理のレシピを閲覧するアプリを開発していたときです。「週末に食材のまとめ買いをするときに1週間分の買い出しリストがあったら便利ではないか」という新しい機能のアイデアが出ました。
かなりの時間と労力をかけて「1週間分の買い物リスト生成機能」を実装しましたが、その機能はユーザーからはほとんど使われませんでした。後で調査すると、アプリを使うユーザーの大半が大都市圏に住んでおり、週末にまとめてではなく、必要に応じて週に何度も買い出しに出掛けていることが分かりました。事前にターゲットユーザーの課題についてよく検証していれば、このような事態は避けられたかもしれません。
不確実性を減少させる「プロトタイピング」のススメ
こうした新規事業に潜む不確実性は「適切な仮説検証」で減少させることができます。筆者は仮説検証の方法として「プロトタイピング」を推奨しています。プロダクトのたたき台（プロトタイプ）を作ることで、本格的な開発を始める前にさまざまな角度から仮説を検証できます。
プロトタイピングには幾つかの種類がありますが、著者が実際に新規事業で利用しているのは「ビジネスプロトタイピング」と「プロダクトプロトタイピング」という2つのプロトタイピングです。
それぞれのプロトタイプの特徴を説明します。
ビジネスプロトタイピング
ビジネスプロトタイピングは「誰のどのような課題をどのように解決することでどのような価値を提供するか」という問いに答えていく取り組みになります。検証する仮説は以下の3つです。
- 課題仮説（課題の広さと深さ、頻度）
- ソリューション仮説
- 価値仮説
新規事業を検討する上で起点となるのは「課題仮説」です。これは「ユーザーはどういった課題に困っているのか」といった仮説で、「課題の広範さ（想定顧客のボリューム）」「深刻度」「発生する頻度」に分解できます。それぞれの要素が大きければ大きいほど「質の高い課題を見つけられた」といえます。ただし、「その仮説が正しいこと」が前提となりますので注意してください。
課題仮説で解決すべき課題を特定したら「ソリューション仮説」を検証します。質の高い課題を発見したからといって解決できなければ意味がありません。そのため「こうすれば課題を解決できるだろう」という仮説を立て、検証します。
課題を特定し、実現できる解決方法の仮説を検証したら、次は「価値仮説」です。「課題を解決したときにどんな価値を感じるか」を検証します。
プロダクトプロトタイピング
「プロダクトプロトタイピング」はプロダクトの機能やデザインなど“あるべき姿”を明確にするための検証です。検証する項目はプロダクトに関する以下の3つです。
- デザイン性
- 機能性
- 体験
「このデザインや機能でどのような体験を提供するか」ということを検証し、プロダクトのイメージを固めます。
2つのプロトタイピングを使い分ける理由
2つのプロトタイピングを使い分けることでさまざまなメリットがあります。
1つ目は「プロダクトの意義の明確化」です。ビジネスプロトタイピングは「どのような課題をどのように解決することでどのような価値を提供するか」という問いを探索する作業です。「プロダクトの存在意義は何か」を探索する作業ともいえます。初期段階でプロダクトの意義を明確にし、共有することで新規事業開発全体の方向性を定めることができます。
2つ目は「検証作業の効率化」です。例えば本来は課題仮説のみを検証すべきタイミングで、デザインも一緒に検証してしまうと「ぱっと見て意見を出しやすいデザインのフィードバックばかりが集まってしまい、肝心の課題仮説の検証が進まなかった」といったことがよく起きます。課題や項目を絞り込むことで検証すべき内容に集中できるのです。
実際の開発では、ビジネスプロトタイピングで作成したものを発展させて、プロダクトプロトタイピングを実施することもあれば、それぞれを独立させたプロトタイピングとして実施することもあります。重要なのは2つのプロトタイピングを明確に分けることです。
検証すべき仮説の優先順はどうやって決めればいいのか
2つのプロトタイピングを組み合わせることで、抜け漏れを防止し、効率的な仮説検証を進めることができます。ですが、もし新規事業の仮説の全てを一度に検証しなければならないとしたら、膨大なコストと時間がかかってしまいます。新規事業は予算やリソースが少ないこともあるので、検証する仮説には優先度を付ける必要があります。
優先度の付け方はさまざまですが、著者は「既知領域からの距離」と「仮説が誤っていた場合の影響度」でマトリクスを分ける方法を使っています。その仮説がどの領域に位置するのかで検証する仮説を選別します。
既知領域からの距離
既知領域からの距離は「新規事業で取り組む領域にいる顧客や商品、ビジネスモデルが、既存事業の領域（既知領域）とどのくらい離れているか」で判断します。これまでと変わらない領域であれば、最初からある程度「正しい仮説」を立てることができる領域だといえます。一方で、全く新しい顧客や商品、ビジネスモデルを扱う場合は「立てた仮説が適切な仮説かどうか」を慎重に判断しなければならない領域となります。
仮説が誤っていた場合の影響度
仮説が誤っていた場合の影響度は「もしその仮説が外れていた場合にどれだけ事業に影響するのか」で判定します。「間違っていた場合、事業が成立できなくなる」といった仮説であれば優先的に検証すべきです。影響度が小さい場合は「検証を行わない」という判断もできます。
優先度が最も高いのはマトリクスの「右上の領域」です。この領域にある仮説は課題仮説、価値仮説といった「事業の根幹を左右しかねない仮説」となります。
このような重要な仮説についてはアンケートやインタビューといったヒアリングベースの検証に頼るのは避けた方がいいでしょう。なぜなら既知領域から遠く、適切な観点で設問や質問の作成が難しいためです。仮説の検証が適切でなかった場合の影響度も高いため、ビジネスプロトタイピングによってユーザー視点での仮説検証が有効です。
次に優先度が高いのは「右下の領域」です。この領域は、影響度は限定的なものの、既知領域から離れているために不確実性が高い仮説となります。この領域の仮説を検証せずに開発を進めると、事業への影響は少なかったとしても「ターゲットユーザーに刺さらないデザインになる」「機能が多過ぎる／少な過ぎる」といった事態に至る可能性があります。そのため、プロダクトプロトタイピングで、そういった不確実性を減少させるべきです。
ここまで新規事業が内包する不確実性と、その不確実性を減少させる手法について紹介しました。次回は「不確実性をどのようにコントロールしていくか」と題し、ビジネスプロトタイピングやプロダクトプロトタイピングの具体的な手法や評価方法について解説します。
筆者紹介
大庭 亮
株式会社Relic 取締役 CTO プロダクトイノベーション事業本部長
奈良先端科学技術大学院大学 情報科学研究科に在学中、産業技術総合研究所の技術研修生としてロボット工学の研究やロボット開発に従事。卒業後は株式会社ディー・エヌ・エーに入社。エンジニアとして主にEC事業領域の新規事業や新規サービス、大手小売業との協働事業であるECサイト、ショッピングモールの開発・運用をリードする。
100万人以上のユーザーが利用するスマートフォンアプリの開発や新規事業の開発リーダーも経験しており、全体のアーキテクチャの設計から実装まで、インフラを含めた幅広い領域を得意とする。2015年からは複数のスタートアップのサービス開発や運用支援をする技術アドバイザリーとして活動を開始。2016年に株式会社Relicの取締役CTOに就任。一般社団法人日本CTO協会正会員であり、技術アドバイザリーとして活躍しつつ、多数の講演、執筆を手掛ける。
Copyright © ITmedia, Inc. All Rights Reserved.
注目のテーマ
ITmediaはアイティメディア株式会社の登録商標です。