プロトタイプ 初級

ラピッドプロトタイピング・ツールキット｜低コスト高速検証の6手法と使い分け

ラピッドプロトタイピングの代表的な6手法（ペーパープロト・ロールプレイ・スケッチ・クリック可能モック・Wizard of Oz・サービスサファリ）を、コスト・忠実度・用途の3軸で整理。いつ・どの手法を選ぶべきかの判断基準をd.school・IDEOの知見をもとに解説する。

所要時間 30分〜3時間（手法により異なる）
参加人数 2〜8名
準備物 紙、付箋、マーカー、カッターナイフ、プレゼンツール（手法により異なる）

プロトタイプを「完成品に近づけてから見せる」という発想は、デザイン思考の原則と逆行します。Stanford d.schoolが繰り返し強調するのは「バイアス・トゥワーズ・アクション（bias toward action）」——考える前に作り、作ることで考える、という姿勢です。

ラピッドプロトタイピングの目的は精度の高い試作を作ることではありません。「今わかっていないことを、最も早く・安く検証する」ための手段を選ぶことです。

プロトタイピングの「忠実度」を理解する

手法を選ぶ前に、忠実度（fidelity）の概念を整理しておく必要があります。

忠実度とは、プロトタイプが最終製品にどれほど近いかを示す指標です。低忠実度プロトタイプ（Lo-Fi）は粗く、素早く、安価です。高忠実度プロトタイプ（Hi-Fi）は精巧で、時間とコストがかかります。

重要な原則は「問いに合わせて忠実度を選ぶ」ことです。「このコンセプトは解くべき問題に対応しているか」という問いには、紙1枚のスケッチで十分です。「このUI操作は直感的か」という問いには、クリック可能なモックアップが必要です。

忠実度が高すぎるプロトタイプは、二つの問題を引き起こします。第一に、ユーザーが「批判しにくい」と感じます。精巧に作られたものに対して「これは違う」と言うことへの心理的抵抗が生まれます。第二に、チームが「作ることへの投資」を守りたくなり、ユーザーのフィードバックを歪めて解釈し始めます。

6つの手法と使い分け

1. ペーパープロトタイプ

概要：紙に手書きでUI・サービス画面・フロー図を描き、ユーザーに操作してもらう。

向いている場面：概念の妥当性確認、画面設計の初期段階、複数のコンセプトを比較する場合。

基本手順：

  1. A4用紙に主要画面を1枚ずつ手書き（デジタルツール不要）
  2. 「進む」「戻る」「選択する」操作を想定した別紙を用意
  3. ユーザーにタスクを与え、紙を操作させながら観察
  4. ファシリテーターが「コンピューター役」として、ユーザーの操作に応じて次の紙を差し替える

注意点：スケッチの上手さは関係ありません。粗ければ粗いほど「まだ初期段階だから意見を言いやすい」とユーザーが感じます。

2. ロールプレイ・シナリオ演技

概要：サービス体験をチームメンバーが演じることで、インタラクションの問題点を発見する。

向いている場面：サービスデザイン、対人接点（受付・コールセンター・カウンセリング）を含む体験設計。

基本手順：

  1. ユーザー役・サービス提供者役・観察者役を割り当て
  2. シナリオを口頭で確認（台本不要）
  3. 実際に演じ、観察者がメモをとる
  4. 演技後に全員で「引っかかった瞬間」を振り返る

注意点：完璧に演じる必要はありません。演じながら止まって「ここはどうするんだっけ」と相談する瞬間が、最も重要な発見になることがあります。

3. コンセプトスケッチ（絵コンテ形式）

概要：サービス・製品の体験を漫画的なコマ割りで描く。

向いている場面：ユーザージャーニー全体の検証、時系列のある体験設計（到着→利用→離脱等）。

基本手順：

  1. 体験の主要タッチポイントを洗い出す（5〜8ポイント）
  2. 各タッチポイントを1コマの絵と短い説明で描く
  3. ユーザーに見せながらフィードバックを収集
  4. 「ここで何を感じますか」「次にどう動きますか」を問う

注意点：絵が下手でも構いません。スティックマン（棒人間）で十分です。コマ割りの「流れ」こそが検証の対象です。

4. クリック可能モック（ハイパーリンクモック）

概要：スライドツール（PowerPoint・Keynote・Google Slides）やFigmaの画面遷移機能を使い、クリックに反応する画面を作る。

向いている場面：UIの操作性確認、特定の画面フローのユーザビリティテスト。

基本手順：

  1. 主要画面をスライドとして作成（デザインは粗くてよい）
  2. ボタン・リンクに「次の画面」への遷移を設定
  3. ユーザーに特定タスク（例：「商品を購入する」）を与え、操作させながら観察
  4. 行き詰まった箇所・予想外の操作をメモする

注意点：非対応のボタンは「準備中」のプレースホルダーで示し、ユーザーが触れたら口頭で「そこをクリックしたんですね、なぜそこだと思いましたか？」と問います。

5. Wizard of Oz プロトタイプ

概要：AIや複雑なバックエンドの動作を、人間が裏側で操作することで「動いているように見せる」手法。

向いている場面：AIチャットボット・音声認識システム・パーソナライゼーション機能など、実装前に体験を検証したい場合。

基本手順：

  1. フロント（ユーザーが見る画面）と裏側（操作者が操作するインターフェース）を用意
  2. 「Wizard役」がユーザーの入力を見て、手動でレスポンスを返す
  3. ユーザーはシステムと対話していると信じたまま操作する
  4. セッション後に種明かしをしてフィードバックを得る（倫理的な実施として重要）

注意点：「どの機能が本当に必要か」を開発前に検証するために有効ですが、ユーザーへの事後開示は必ず行います。

6. サービスサファリ（体験偵察）

概要：自分たちのサービスや競合・隣接サービスを実際に体験し、ユーザー視点でインサイトを得る。

向いている場面：既存サービスの課題発見、競合分析、アナログ体験のデジタル化前の基礎調査。

基本手順：

  1. 体験するサービス・店舗・施設を選定
  2. チームで実際に訪問・利用（バラバラに行き、後で比較する）
  3. 体験中に写真・メモ・音声録音でデータ収集
  4. 「驚いた瞬間」「不満を感じた瞬間」「期待を超えた瞬間」を分類して共有

注意点：自社サービスのサファリは「慣れ」でインサイトが薄れます。初めて使うユーザーを連れて行くか、全く異なる業界の類似サービスを組み合わせて体験するとよいでしょう。

手法選択マトリクス

手法忠実度時間コスト人数主な用途
ペーパープロトタイプ低30分〜2〜4名UI概念の妥当性
ロールプレイ低1〜2時間3〜8名サービス体験設計
コンセプトスケッチ低1時間〜2〜4名ジャーニー全体
クリック可能モック中2〜4時間2〜4名UI操作性
Wizard of Oz中〜高半日〜3〜6名AI/自動化機能の事前検証
サービスサファリ参照2〜3時間2〜6名インサイト収集

プロトタイプを作る前に問う3つの問い

IDEOのデザイナーが実践する習慣として、プロトタイプを作る前に以下を明確にすることが推奨されています。

  1. 「何を検証したいのか」：機能の有無？使いやすさ？コンセプトの理解？問いによって手法が変わります。
  2. 「誰に見せるのか」：ユーザー？ステークホルダー？チーム内？対象によって忠実度が変わります。
  3. 「何が明らかになったら次のステップに進むのか」：検証の「合格基準」を先に決めることで、プロトタイプの目的がぶれません。

この3問に答えられないまま作り始めると、「見た目は良いが何も学べないプロトタイプ」が完成します。

参考資料

  • Stanford d.school. Prototype: Getting Tangible. (d.school method cards, standord.edu/dschool)
  • Brown, T. (2009). Change by Design: How Design Thinking Transforms Organizations and Inspires Innovation. HarperCollins.
  • IDEO.org. The Field Guide to Human-Centered Design. (2015, ideo.org/post/field-guide-to-human-centered-design)