見出し画像
Photo by imocos

【プロトタイプ】アイデアを検証する時のポイント

古仲 蘭🇺🇸🍕@Institute of Design

こんにちは！👋
最近低浮上ですみません。。。
8月末から学校がはじまり、例の如く忙しい日々を過ごしております。🐏 あまり更新はできませんが、時間があるときに少しずつ執筆できればと思っておりますので、どうぞ気長にお待ちいただけると幸いです。。。🥺

過去数本に渡ってご紹介していたデザイン思考の各プロセスのポイントをまとめていました。
まずは、リサーチを通して発見したインサイトをどうHow Might Weを使ってリフレームするかまとめたこちらの記事。

課題を設定した後にどうアイデアを量産すればよいか、複数フレームワークをご紹介したこちらの記事。

そして前回投稿したのは、数あるアイデアの中で次のステップ、すなわちプロトタイピングにすすむアイデアを選別する意思決定プロセスをご紹介した記事でした。

そして今回は、このデザイン思考シリーズの一旦最終回になります、どのようにしてプロトタイプをすすめていくか、どのような観点でアイデアを検証していくのかご紹介したいと思います。

"Create Experience Not Explanation" - 説明より体験を創る

プロトタイピングとは何か？

プロトタイピングとはアイデア（と仮定）を低コストで物理的に可視化し、アイデアの妥当性をクイックに評価するためのプロセスです。アプリであれば紙のスケッチ、物理的なプロダクトであればダンボールや粘土、レゴ、身近な文房具などのモノを組み合わせて作ることが多いと思います。プロトタイピングの重要なポイントは、アイデアの詳細を作り込むことに集中するより、そのアイデアを通してどのような体験を提供したいのかを表現することです。
例えばIDEOの有名なこのプロトタイプは医師の手術用デバイスをラフに表現したものですが、マーカー、フィルム容器、クリップをテープで貼り付けただけの簡易なものですが、どんな形で何がしたいかはなんとなく想像がつくと思います。

左：プロトタイプ
右：実際の商品

Palm Pilot（スマートフォンの先駆け的商品）の発明者であるジェフ・ホーキンスは、商品を開発する前に数週間にわたって木片を持ち歩いたという逸話があります。彼は、将来人々がタブレットなど、小さい電子デバイスを使うと予想し、それがどのような体験であるか、木片を持ち歩くことによって実験していたのです。プロトタイピングはこれくらいシンプルでも成立するのです。

Jeff Hawkins

なぜ重要なのか?

  • クイックにアイデアを可視化し、それをもとに、改善策や新しいアイデアを発想することができる

  • 早い段階で失敗案を見つけ、その学びをその後に活かすことができる(Fail fast)

  • アイデアが実際に望ましいか、実行可能か、実現可能か(Desirable, Feasible, Viable)をより具体性を持って判断することができる

良いプロトタイピングとは

良いプロトタイプは以下の要素を満たすものであるとされています。

  • 発想のためのプロトタイプ ：プロトタイプを通じて改善策や新たなアイデアを発想できる)

  • 体験のためのプロトタイプ：アイデアがどのような体験を生み出すかが表現されている

  • 検証のためのプロトタイプ：アイデアがユーザーにとって望ましいか、技術的に実現可能か、ビジネスモデル・オペレーション的に実行可能か、評価することができる

【注意】すべての要素を網羅したプロトタイプを一つ作ろうとするよりも、主要な機能を説明するために、サブ的な立ち位置のプロトタイプをいくつか作る方が良いとされています。（MVP的な）

プロトタイピングの準備プロセス

1. 仮説を立てる - このアイデア成功の必要条件は何か？

このアイデアがユーザーに受け入れられる前提には、何が正である必要があるでしょうか？言い換えると、このアイデアを自信を持って製品化・商品化に進める為には、ユーザーはどのような反応・行動をすることが前提になるでしょうか？授業ではこれらの仮説をWMBT（What Must Be True）と呼んでいます。
例えば、私のnoteで度々例として挙げているThe Sill（アメリカのD2C植物ショップ）の既存・潜在顧客が持つ「ECサイトの植物の写真は実際の見た目と異なる可能性が高いので、実店舗で実際に触って見てから購入するか意思決定したい」という課題に対して、例えば「VRを使ってバーチャル空間上にThe Sillの実店舗を構築し、顧客は購入前にVR上で商品を手にとって見ることができる」というアイデアを挙げたとします。このアイデアが成功するための前提条件(WMBT)は例えばこのような条件です：

  • 顧客がVRのヘッドセットにアクセスできること。且つ顧客のVRに対する心理的なハードルが低いこと。

  • VRの技術が成熟して市場に根付いていること。

  • VR上で見る植物は、大きさ的に自分の家に置けるかシミュレーションできること。

  • 複数人が同時に仮想店舗でショッピングができること。

などなど。

私たちの考えたWMBT

うまく思いつかなければDVF(Desirable, Viable, Feasible)のフレームワークを元に以下を自問してみるとよいです。

望ましさ / Desirableの考慮点

  • このコンセプトはユーザーに価値を生むか？ユーザーはその変化を望むか？

  • スイッチングコストは妥当か？

実行可能性 / Viabilityの考慮点

  • コストは合理的か？

  • このアイデアが訴求する顧客セグメントは魅力的か？（十分なリターンが望めそうな顧客セグメントか？）

  • 業界・産業は魅力的か？（十分なリターンが望めそうな業界・産業か？）

実現可能性 / Feasibilityの考慮点

  • そのアイデアが実現できる技術は既に存在するか？

  • その技術を実装するための能力・スキルはあるか？

  • アイデアを製品化する為に適切なパートナーシップとチャネルは存在するか？

例えば、綺麗好きなユーザーがビジネスホテルにより気持ちよく滞在してもらえるように、Dysonの掃除機を設備したり、ワイプや使い捨てのアメニティを置くサービスアイデア（Clean Roomと呼びます）があった場合、以下のようなWMBTが考えられます。
Desirable: ゲストがより部屋の変化に気づきやすくなり、それをポジティブに受け取る。（NPSサーベイで検証可能）
Viable: 清掃時間が以前より削減され、コスト減につながる。
Feasible: 清掃スタッフは、各部屋の清掃時間を大幅に増やすことなく、このオペレーションの変更に対応することができる。

2. 検証のポイントを決める - 一番失敗しそうな条件は何か？

アイデアが成功するための必要条件(WMBT)を洗い出したら、どの条件が最も成立しにくいかを検討します。最もWMBTの成立可能性が低い条件から検証を始めることで、アイデアの最大の弱点を最初にテストすることになります。以下の四象限にWMBTをマッピングしていくようなイメージです。この段階では、Yes And…の精神というよりか、クリティカルな観点で議論するのが良いです。

3.優先度の高い障壁をクリアできるか検証する方法を決める

検証の課題が決まったら、次はそれをどのように実行するか決めます。いろんな検証方法があるので、状況に応じてググっていただければと思いますが、ここでは例えば3つの検証方法が紹介されています。

ゲリラテスト
ググったら「その場の思いつきで実施するテスト」という日本語訳が出てきました。例えば、ルームクリーニングサービスの例では、会議室の一室でもダンボールで作った部屋でも何でもよいので、サービスを再現したプロトタイプを作って、被験者に来てもらって意見を聞く、というようなものです。最も迅速にでき、コストも他に比べてあまりかからないとされています。

小規模テスト
それに対して小規模テストは実際の環境で、極めて小規模で行うテストのことです。例えば実際のホテルを10部屋借り切って、そこにサービスを再現し、2週間稼働させ、滞在客のNPSを確認する、というようなプロセスになります。この手法は比較的に少ない投資額で実施可能且つ、ゲリラテストより正確なデータを取ることができます。

本番テスト
これは更に規模が大きくなり、例えば、業界大手のホテルのうち2棟にクリーニングサービスを導入し、NPSなどを通して顧客の反応を検証します。パイロットテストや大規模な市場テストもこのテストで同時にカバーすることが多く、多額の投資を必要とし、信頼度の非常にデータを入手することができます。

もちろんここで挙げた以外にも多種多様な規模・手法の検証方法があるので、状況に応じて決定していただければと思います。（最初に挙げたIDEOやJeff Hawkinsのプロトタイプはゲリラテストよりも、より解像度が低く、クイックで低コストのプロトタイプです）

1つの検証課題に対して、3つの検証方法案

4.具体的なテスト計画を立てる

テストの目的や方向性がズレないように、クイックに文章化をしておくと良いと言われています。（もちろん組織の方針に寄りますが）フォーマットは何でも良いのですが、考慮すべきことは以下の通りです。

  1. このテストは、ステークホルダーとともに、ステークホルダーによる、ステークホルダーのためのものであるべきである。（＝ステークホルダーが気にしているところを優先的に検証してあげて、その検証プロセスにステークホルダーも巻き込もう）

  2. アイデアを通して実現したい体験の「リアルさ」を追求すること。

  3. テストの目的を明確にし、それだけに集中し、無駄を省く。

  4. 実際のユーザーがフィードバックを行い、アイデアを進化させ、適応させる。一回のテストで終わり、ではなく、サイクルを作る。

  5. パートナー企業及び関係者（ステークホルダー）とどのような協力関係を築くべきかを検討する。大規模のプロトタイプの場合、開発およびリスクをどのように分担するか？

  6. 規模・コスト感を確認すること。A/Bテストは可能か？複数の時間/場所でのテスト実行は可能か？

  7. 被験者の調達方針を確認すること。実際のユーザーやクライアント企業の社員、友人を使ってテスト可能か？それともリクルーターを通す必要があるか？

  8. スケジュールは数ヶ月単位ではなく、数週間単位で検討すること。

  9. 予算は1000ドル単位ではなく、100ドル単位で検討すること。

フォーマットは例えば以下3つあるので、状況に応じて使い分けていただけると◎ どれも情報の解像度が違います。例1が一番解像度の低いフォーマットで、次に例2が解像度が高く、一番詳しいのは例3です。プロジェクトのスピード感とステークホルダーのお好みに合わせてどれくらい詳しくドキュメント化するかは決定していただければと思います◎

例 1
例2
例3
例3続き

プロトタイピングのその先

アイデアの最終決定

プロトタイピングが終わったら、最終的にアイデアの展開/開発 or 中止の決定を行います。そして、その判断は、十分に時間（通常は数週間）をかけて収集したデータの分析に基づいて行うことが望ましいとされています。（ただし、完璧なデータがないからといって、決断を引き延ばさないことが重要です。）
良い意思決定は定量データ、定性データ、専門家としての勘、3つすべてに裏付けされたものだと言われています。

教授によると、アイデアの成功パターン・失敗パターンがなんとなく存在しているようで、例えば以下のような特徴があるみたいです。

成功パターン

  • 模倣が難しいこと（アイデアが複雑性を持ちつつ、ユーザー体験をリッチなものにしていること）

  • 誰の目にも明らかに最良の選択であること

  • リーダーがこのアイデアにコミットしている

  • チームからの賛同がある

失敗パターン

  • 本能と直感に頼るしかない（定性・定量データが存在しない）

  • リーダーからのサポートがない

  • アイデアのインパクトが小さい

アイデアからプロジェクトへ

プロトタイピングを以って一旦構想策定のフェーズは終わりで、その後は最終的に決定したアイデアを実際に開発したり商品化・製品化したりする、ことになります。デザイナーが考慮しなければならないことも構想策定とプロジェクト化以降で全く異なるので、ここでマインドシフトが必要だよ、と教わりました。具体的にはこんなこと：

これまで：以下の要素を伴うアイデアの発想

  • 明確なユーザー価値提案

  • 組織の戦略をサポートする計画

  • それが何であるか、何をするものであるかが明確である

  • リターンが得られる可能性

これから：以下の要素を伴うプロジェクトの構築

  • 予算

  • 明確な目標

  • 成功の基準

  • タイムラインと決定事項

  • （現場の）リーダー

  • リソース(人を含む)

  • （クライアント企業の）リーダーシップとの整合性

  • 導入の意図

From portfolio of Ideas to Portfolio of Initiatives

これまではユーザーを中心に考え、平行でビジネスモデルや技術的実現可能性を考えながら、アイデアを考えてきましたが、これ以降のフェーズは（ユーザー中心は前提ですが）プロジェクトのオペレーションを具体的に考えていく方にシフトしていかなければならないということです。

終わりに

今回は構想策定の最終タスク、プロトタイピングについてご紹介しました。正直、Institute of Designのプロトタイピング、結構慎重に進めるのね、と、びっくりしました。（結構2日のワークショップで一気にプロトタイピングまで進めることが多いので）どちらのアプローチも長所・短所あると思います。
Institute of Designのアプローチは、仮説を立てて、検証ポイントを決めて、手法を考えて、という感じなので、無駄なプロトタイピングを減らせたり、目的を持って検証ができるという点では良いと思いますが、数週間レベルで進めるので、アイデアが生まれた直後のチームの盛り上がり・勢いみたいなものがその後数週間保てるかというとなかなか難しそうだなと思いました。また、クライアントも巻き込んで発想するCo-design/Participatory Design的なアプローチを取るなら参加者のスケジュール調整の観点で厳しいかもと思いました。割と大規模な検証を前提にしているような気もします。

これまで数ヶ月に渡って、Institute of Designの名物教授（？）Jeremy Alexis先生のAnalysis and Synthesisという授業から一部抜粋して、日頃の業務に役立ちそうな部分を日本語化してご紹介してきました。時にはたくさんの反響を頂き、とても嬉しかったですし、私自身にとってもよい復習の機会になりました。😊
今後は今私が授業で学んでいるDesigning Futures（Speculative Design的な）のお話であったりCommunity Designのお話であったり、ざっくばらんにご紹介していきたいなと思います！
今学期もJeremyの授業は取っていて、North Western Mutualというアメリカの生命保険会社の将来（10年後レベル）のビジネスを考えるプロジェクトをしています。未来のビジネスを考えているので、クライアントが抱える現状の課題ドリブンの発想方法では上手くいかず、Analysis and Synthesisで習ったことが必ずしも応用できず、苦しんでいます😂 その授業でも学びがあればまた紹介できればと思います！楽しみにお待ちいただければ嬉しいです！🕊

最後まで読んでくださり、ありがとうございました！
スキ・フォローなどいただけると励みになります🕊💐

では👋


いただいたサポートは怒涛のインフレ&円安で圧迫されつつある留学軍資金の足しにさせていただきます…！😂