フレームワーク活用ガイドひとことで言うと#
Google Venturesが開発した5日間のデザインスプリントを4日間に短縮し、より実践的に改良したワークショップ手法。Day1で課題定義とソリューション発散、Day2で意思決定、Day3でプロトタイプ作成、Day4でユーザーテストまで完了する。AJ&SmartのJonathan Courtneyが提唱した。
押さえておきたい用語#
- HMW（How Might We）
- 「どうすれば〜できるか？」の形で課題をリフレーミングする手法。問題をそのまま扱うのではなく、解決可能な問いに変換する。
- ライトニングデモ（Lightning Demo）
- 参加者が各自3分以内で他業界や競合の優れた事例を紹介するセッション。発想の幅を広げる起爆剤になる。
- スーパーボート（Supervote）
- 意思決定者（Decider）が持つ最終決定権のある投票。民主的な投票の後、最終的にはDeciderの判断でプロトタイプの方向性を決める。
- ファサードプロトタイプ（Facade Prototype）
- 実装せずに見た目と操作感だけを再現したプロトタイプ。Figma、Keynoteなどで1日で作れるレベルに留める。
- 5幕構成（Five-Act Interview）
- ユーザーテストの進行フォーマット。アイスブレイク→背景質問→プロトタイプ紹介→タスク実行→振り返りの5ステップで構成される。
デザインスプリント2.0の全体像#
こんな悩みに効く#
- 新機能のアイデアが会議で出ては消え、検証されないまま放置される
- 5日間のスプリントは長すぎて参加者のスケジュールが確保できない
- チーム内でソリューションの方向性が割れて、議論が平行線になる
- 開発に着手してから「そもそもニーズがなかった」と判明するケースが多い
基本の使い方#
旧版の2日分を1日に凝縮する。午前に課題を構造化し、午後にソリューションを発散させる。
- 午前: 長期ゴールの設定 → スプリント質問の作成 → 課題マップの作成 → エキスパートインタビュー（15分×3名）
- 午後: HMWノートの作成と投票 → ライトニングデモ（各3分）→ 4ステップスケッチ（メモ→アイデア→Crazy8s→詳細スケッチ）
- Decider（意思決定者）は必ず参加させる。不在だとDay2が機能しない
前日のスケッチから方向性を1つに絞る。午前中に完了できるのが2.0の特徴。
- スケッチを壁に貼り出し、サイレントで閲覧 → ヒートマップ投票（全員がドットシールで投票）
- Deciderがスーパーボート（3票の特別投票）で最終方向性を決定
- 選ばれたソリューションをストーリーボード（6〜8コマ）に展開
- 午後はプロトタイプ担当者がストーリーボードを読み込み、素材準備を開始
ストーリーボードをもとに、1日でテスト可能なプロトタイプを完成させる。
- Figma、Keynote、PowerPointなど最速のツールを使う（コードは書かない）
- 「本物に見えるが動かない」ファサードプロトタイプで十分
- 並行してテストシナリオと質問リストを準備する
- リクルート済みのテスト参加者にリマインドを送る（リクルートはスプリント開始前に完了しておく）
5名のユーザーにプロトタイプを触ってもらい、Go/Pivotを判断する。
- 5幕構成（アイスブレイク→背景質問→紹介→タスク→振り返り）で各45分
- チーム全員が別室でライブ観察し、付箋にメモを取る
- 全セッション終了後にパターン分析: 5人中3人以上が同じ反応なら強いシグナル
- 最後に「Go（このまま開発）」「Iterate（修正して再テスト）」「Pivot（方向転換）」を決定
具体例#
従業員80名のHRテック企業。新入社員向けオンボーディング機能の開発を検討していたが、PM・エンジニア・CSの間でソリューションの方向性が3つに分かれ、2か月間議論が停滞していた。
スプリント実施:
- Day 1: 「入社30日以内の離職率を下げる」を長期ゴール設定。HRマネージャー3名へのエキスパートインタビューで「最初の1週間の体験が決定的」という洞察を得た。参加者7名が個別にスケッチを作成
- Day 2: 投票の結果、「チェックリスト型」「チャットボット型」「メンター型」の3案から、スーパーボートでチェックリスト＋メンター組み合わせ型に決定
- Day 3: Figmaでプロトタイプ作成。10画面のフローを1日で完成
- Day 4: 入社6か月以内の社員5名にテスト。全員が「チェックリストの進捗が見えるのが安心」と回答。一方で「メンターへの質問タイミングがわからない」が4名共通の課題
テスト結果を受けてメンター機能を「プッシュ型（メンターから声をかける）」に修正し、2週間後に再テスト。最終的に開発にGoを出し、リリース後の入社30日以内離職率は**12% → 5%**に改善した。2か月停滞していた議論が4日間で解決した。
全国150店舗の飲食チェーン。モバイルオーダーアプリの利用率が**15%**に留まっており、店頭レジの混雑解消につながっていなかった。
Day 1の課題マップ: ユーザーの行動を「アプリ起動→メニュー選択→カスタマイズ→決済→受取」の5段階にマッピング。エキスパートインタビューで店舗スタッフから「カスタマイズが複雑すぎてアプリでは無理と思われている」という洞察を得た。
Day 2の意思決定:
- 案A: メニューをAIレコメンドで絞り込む
- 案B: カスタマイズを3ステップに簡略化する
- 案C: 「前回と同じ」ワンタップ注文を追加する
スーパーボートで案B＋案Cの組み合わせに決定。
Day 3: Figmaプロトタイプ。カスタマイズ画面を「サイズ→トッピング→確認」の3ステップに、リピート注文をホーム画面トップに配置。
Day 4のテスト結果: 5名中5名がリピート注文を「便利」と評価。カスタマイズも4名が「前より迷わない」と回答。ただし1名が「前回と違う注文をしたいときの導線がわかりにくい」と指摘。
この指摘を反映して開発開始。リリース3か月後、アプリ注文率は15% → 38%に上昇し、ランチタイムのレジ待ち時間が平均4.2分短縮された。
大手損害保険会社のデジタル推進部。紙ベースの保険金請求フローをデジタル化するプロジェクトが立ち上がったが、「どこまでデジタル化すべきか」「高齢者ユーザーは使えるか」で部門間の意見が割れていた。
スプリント参加者: PM、UXデザイナー、コールセンター長、保険査定担当、外部のUIデザイナー（計6名）
Day 1: 現行の請求フロー（書類送付→受領→査定→振込）を課題マップ化。コールセンター長から「書類不備による再送が全体の32%」という衝撃的なデータが出た。HMWを48枚作成。
Day 2: 「写真で書類をスキャン＋AIで不備チェック」案にスーパーボートが集中。ストーリーボードは「事故発生→アプリで写真撮影→AI不備チェック→送信→進捗確認」の7コマ。
Day 3: Figmaで請求フローのプロトタイプを作成。フォントサイズを通常より1.5倍大きくし、各ステップに進捗インジケーターを配置。
Day 4: テスト参加者は30〜70代の5名（うち60代以上2名）。
- 全員が「紙より楽」と回答
- 60代の2名も写真撮影→送信まで完了できた（ただし「撮影ガイド枠が欲しい」と要望）
- 書類不備チェック機能は5名全員が「安心感がある」と高評価
開発にGoを出し、6か月後にリリース。書類不備率は32% → 8%に激減し、請求から振込までの平均日数が14日→6日に短縮された。
やりがちな失敗パターン#
- Decider（意思決定者）を参加させない — Day2のスーパーボートが機能せず、スプリント後に「やっぱり違う方向で」とひっくり返される。Deciderの4日間確保が成功の必須条件
- プロトタイプの完成度を上げすぎる — Day3で細部にこだわると時間切れになる。テストに必要な最低限のフローだけを作る。ピクセルパーフェクトは不要
- テスト参加者のリクルートを後回しにする — Day4に人が集まらないとスプリント全体が無駄になる。スプリント開始1週間前にはリクルートを完了しておく
- スプリント結果を放置する — 4日間で得たインサイトを「良い経験だった」で終わらせてはいけない。2週間以内に次のアクション（開発着手/再テスト/ピボット）を実行する
まとめ#
デザインスプリント2.0は、旧版5日間の「Map」と「Sketch」を1日に統合し、4日間で課題定義からユーザーテストまでを完了させる。成功の鍵はDeciderの参加確保、テスト参加者の事前リクルート、そしてプロトタイプの「ちょうどいい粗さ」。完璧な計画を立てるより、4日間で実際のユーザーの反応を得る方が、はるかに正確な意思決定ができる。