紙と鉛筆だけでも十分 今日からできる「プロダクトプロトタイピング」のススメ：新規事業の不確実性との向き合い方（2）（2/2 ページ）

[大庭 亮，株式会社Relic]

印刷

通知 連載「新規事業の不確実性との向き合い方」の新着をメールで通知

見るPost

Shareシェア

はてなブックマーク

SharePocket Button

検証すべき仮説の特定

　仮説定義で多くの問いと仮説を抽出しました。ですが、列挙した仮説を全て検証するわけにはいきません。膨大な費用がかかってしまいますし、時間もかかります。「検証をしている間に競合に先行されてしまった」といった事態も起こり得ます。そのため、全ての仮説を検証するのではなく「検証する価値のある仮説」の検証に注力しましょう。

　では、「検証すべき仮説」と「そうでないもの」をどのように切り分ければいいのでしょうか。

続きを読む

　著者は『ザ・ファーストマイル イノベーションの不確実性をコントロールする』（著：Scott D. Anthony）の中で紹介されている、仮説の確信度と影響度から重要度を明らかにするというアプローチが有効だと考えます。

仮説を重要度によって分類する方法（出典：ザ・ファーストマイル イノベーションの不確実性をコントロールする）

　仮説定義の例に挙げたように、列挙した仮説に対して確信度と影響度を設定していきます。『ザ・ファーストマイル』ではそれぞれ以下のように定義しています。

• 確信度：「期待通りの結果になること」にいくら賭けるか？
• 影響度：自分の仮説が間違っているとわかったときの対応は？（間違っていた場合、どういった対応をするか）

　確信度と影響度という2つの基準を使い、仮説をゾーン1～3に分類します。このアプローチをそのまま使ってもいいのですが、今回は判断しやすいように簡略化したものを使います。

仮説を重要度によって分類する方法（簡易版）

　これは影響度と確信度に「高」「中」「低」のレベルを設け、どのゾーンに当てはまるかを分かりやすくした図です。優先度が最も高いのはゾーン1で、最も低いのはゾーン3となります。ゾーン1の検証は必須です。それに対してゾーン3は、仮説を外したときのリスクが低いため検証を見送っても問題ありません。ゾーン2は中間に位置し、「簡単に検証できる（リソースがそれほどかからない）のであれば、検証した方がよい」となります。

プロトタイピング手法の検討

　影響度と確信度によって検証すべき仮説が決まったら、次はプロトタイピングの手法を選択します。プロトタイピングの手法はさまざまです。デザイン、機能、体験というテーマで絞っても幾つもの手法があります。下図はその一例です。

3種類の仮説とそれぞれに対するプロトタイピング手法

　プロトタイピングの目的は仮説を検証することです。もっと簡単に言うと「『プロトタイプを使ってみてどう思ったか』というフィードバックをユーザーからもらう」ということです。プロダクトの完成度を高めるためには、できるだけ具体的なフィードバックが必要です。ですが、それがもらえるかどうかはプロトタイプの「忠実度」（Fidelity）に比例します。

　忠実度とは「プロトタイプが、最終的なプロダクトを、どれだけ詳細に再現しているか」という度合いです。適切なフィードバックを得るためには、コストや時間をかけて忠実度を高めることが重要だといえます。

　さまざまな方法はありますが、初めは図の左側に位置する「忠実度は低いが低コストなプロトタイピング」を採用し、より具体的なフィードバックが必要になってきた段階で、右側に位置する「コストは高いが忠実度も高いプロトタイピング」を選ぶという流れがお勧めです。

プロトタイプの構築・検証

　プロトタイピングの手法が決まったら、いよいよ実践です。それぞれの手法を使ってプロダクトのプロトタイプを作り、検証し、ユーザーのフィードバックを受けます。そのフィードバックを基に、必要に応じて修正を加える、別のプロトタイピング手法を試すといったことを繰り返し、プロダクトの完成度を高めていきます。

　難しそうと感じる方がいらっしゃるかもしれませんが、例えば「紙にアイデアを描いて周りに見せてみる」だけでも立派なプロトタイピングです。しかも、紙を使ったプロトタイピング（ペーパープロトタイピング）は低コストで瞬時に検証できるというメリットもあります。

　余談ですが、Twitterの創業メンバーであるジャック・ドーシー氏は、サービスのアイデアをメモ帳に描く手法を使っていました。今では巨大なサービスであるTwitterも1枚の紙から始まったことを考えると、この手法の有効性はなかなかあなどれません。

ドーシーが書いたTwitterのアイデアになるメモ（出典：Wikipedia「ジャック・ドーシー」のページ）

---

　ここまで「仮説を列挙し、検証すべき仮説を特定してプロトタイピング手法を検討。その手法を使って作成したプロトタイプを検証する」というプロダクトプロトタイピングの進め方を説明しました。ハードルが高いように感じるプロトタイピングも、ドーシー氏がやった紙を使ったものであれば簡単に実施できるのではないでしょうか。

　ただ検証が進むと、より具体的なフィードバックが必要なシーンが増え、紙だけでは十分なプロトタイピングが難しくなっていきます。そこで役立つのがノーコードツールやローコードツールです。次回はそれらのツールの紹介も含めて、プロトタイピングの手法の具体的な手順や事例を解説します。

この連載を「連載記事アラート」に登録する New

筆者紹介

大庭 亮

株式会社Relic　取締役 CTO　プロダクトイノベーション事業本部長

奈良先端科学技術大学院大学 情報科学研究科に在学中、産業技術総合研究所の技術研修生としてロボット工学の研究やロボット開発に従事。卒業後は株式会社ディー・エヌ・エーに入社。エンジニアとして主にEC事業領域の新規事業や新規サービス、大手小売業との協働事業であるECサイト、ショッピングモールの開発・運用をリードする。

100万人以上のユーザーが利用するスマートフォンアプリの開発や新規事業の開発リーダーも経験しており、全体のアーキテクチャの設計から実装まで、インフラを含めた幅広い領域を得意とする。2015年からは複数のスタートアップのサービス開発や運用支援をする技術アドバイザリーとして活動を開始。2016年に株式会社Relicの取締役CTOに就任。一般社団法人日本CTO協会正会員であり、技術アドバイザリーとして活躍しつつ、多数の講演、執筆を手掛ける。