Googleデザインスプリントの進め方とは？5日間の手順・準備・成功事例を徹底解説

新しい商品やサービスを開発するとき、長期間にわたって議論を重ねても、本当に顧客が求める解決策であるかどうかは、実際に形にして検証するまで分かりません。会議では良い案に見えても、利用者が操作すると理解されなかったり、想定していた課題そのものが間違っていたりすることがあります。

Googleデザインスプリントは、こうした不確実性を短期間で減らすための実践的な進め方です。通常は5日間という限られた期間の中で、課題を整理し、解決案を考え、ひとつの方向性を選び、試作品を作成して、実際の利用者に確認します。完成品を開発する前に重要な仮説を検証できるため、時間や費用を大きく投入する前に、進むべき方向を判断できます。

本記事では、Googleデザインスプリントの意味、5日間の具体的な進め方、参加者の役割、準備物、顧客体験マップ、試作品制作、利用者検証、短縮版の実施方法まで詳しく解説します。初めてデザインスプリントを実施する担当者でも実践できるように、会議の進め方やコード例を含めて説明します。

1. Googleデザインスプリントとは

Googleデザインスプリントとは、複雑な事業課題や商品開発上の不確実性を、短期間の集中作業によって検証する方法です。一般的には5日間で、課題理解、発想、意思決定、試作品制作、利用者検証を行います。

ここでは、Googleデザインスプリントがどのような目的で使われ、一般的な会議や開発工程と何が異なるのかを解説します。

1.1 5日間で重要な仮説を検証する方法

Googleデザインスプリントでは、数か月かけて商品を開発する前に、事業上の重要な仮説を5日間で検証します。完全な商品を作るのではなく、利用者が本物に近い体験をできる試作品を用意し、その反応から方向性を判断します。

検証対象は、画面の使いやすさだけではありません。顧客が価値を感じるか、説明を理解できるか、利用したいと思うか、事業として成立する可能性があるかなど、商品やサービスに関する重要な疑問を扱えます。

1.2 議論よりも具体的な形を重視する

一般的な会議では、参加者が意見を述べ、話し合いによって案を絞り込むことが多くあります。しかし、発言力の強い人の意見に流されたり、抽象的な言葉の解釈が参加者ごとに異なったりする問題が起こります。

デザインスプリントでは、各参加者が個別に考え、紙や画面案として具体化したうえで評価します。話し合いだけに依存せず、目に見える形を比較するため、より客観的に意思決定を進めやすくなります。

1.3 完成品ではなく学習を成果とする

デザインスプリントの主な成果は、完成した商品ではありません。利用者がどこで迷い、何を評価し、どの部分に価値を感じなかったのかを明らかにすることが成果です。

試作品の評価が低かった場合でも、実際の開発前に問題を発見できたという意味では成功です。方向性が間違っていることを早期に確認できれば、大規模な手戻りや不要な投資を防げます。

1.4 複数部門が協力して進める

顧客が体験する商品やサービスは、企画、設計、開発、営業、問い合わせ対応など、複数の部門によって提供されます。ひとつの部門だけで改善案を考えると、顧客体験全体を捉えられない可能性があります。

デザインスプリントでは、異なる専門性を持つ参加者が同じ課題に集中します。部門ごとの事情を共有しながら、顧客にとって望ましい体験と、事業として実現可能な方法の両方を検討します。

1.5 デザイン思考との関係

デザイン思考は、利用者への共感、課題定義、発想、試作、検証を繰り返す問題解決方法です。デザインスプリントは、その考え方を限られた期間と明確な手順にまとめた実践形式と考えられます。

デザイン思考が柔軟に繰り返されるのに対して、デザインスプリントでは日ごとの目的と作業があらかじめ整理されています。初めて利用者中心の開発に取り組む組織でも、進行手順に沿って実践しやすい点が特徴です。

2. Googleデザインスプリントを実施する目的

デザインスプリントは、すべての会議や開発作業を置き換える方法ではありません。重要な疑問があり、複数の選択肢を比較し、短期間で利用者の反応を確認したい場面に適しています。

ここでは、企業がGoogleデザインスプリントを実施する主な目的を整理します。

2.1 新規事業の不確実性を減らす

新規事業では、顧客が本当に課題を感じているか、提案する解決方法に価値があるか、どのような説明なら理解されるかが分かりません。予測だけで開発を進めると、完成後に需要がないと判明する危険があります。

デザインスプリントでは、事業の中心となる体験を試作品として表現し、対象顧客に確認します。実際の利用者の反応を得ることで、継続、修正、中止の判断に必要な材料を短期間で集められます。

2.2 商品改善の優先順位を決める

既存の商品やサービスには、利用者から多くの要望が寄せられます。しかし、すべての要望に対応することは難しく、機能を増やし続けると商品が複雑になる可能性があります。

デザインスプリントを利用すると、重要な課題に対する複数の改善案を比較し、利用者にとって価値の高い案を確認できます。社内の意見だけではなく、利用者の行動に基づいて優先順位を決めやすくなります。

2.3 関係者の認識をそろえる

同じ商品を担当していても、経営者、営業担当者、開発担当者では、重要だと考える課題が異なります。認識がそろっていない状態では、開発途中で目的や要件が変わり、手戻りが発生します。

デザインスプリントでは、最初に長期目標、課題、顧客の行動を共同で整理します。同じ資料と試作品を見ながら判断することで、抽象的な言葉だけで議論するよりも共通認識を形成しやすくなります。

2.4 大規模開発前の判断材料を得る

大規模なシステム開発や店舗改装には、多くの時間と費用が必要です。実施後に顧客の期待と合っていないことが判明しても、簡単には変更できません。

デザインスプリントでは、重要な体験部分だけを低い費用で再現し、実施前に顧客の反応を確認します。すべての危険をなくすことはできませんが、重大な思い違いを早い段階で発見できます。

2.5 意思決定を速める

複雑な課題では、情報収集や議論が長期化し、結論が出ない場合があります。すべての情報がそろうまで待とうとすると、市場や顧客の状況が変わってしまう可能性もあります。

デザインスプリントでは、限られた時間の中で必要な情報を集め、決定者が方向性を選びます。完全な確実性を求めるのではなく、試作品と利用者検証によって次の判断へ進むことが重視されます。

3. Googleデザインスプリントと一般的な開発方法の違い

Googleデザインスプリントは、企画会議、試験的な小規模開発、柔軟な開発方法などと似ている部分があります。しかし、目的、期間、成果物、意思決定の方法には明確な違いがあります。

ここでは、代表的な進め方との違いを比較します。

3.1 一般的な企画会議との違い

一般的な企画会議では、参加者が順番に意見を述べ、話し合いによって結論を出すことが多くあります。議論が中心になるため、声の大きい参加者や役職の高い参加者の意見が影響しやすくなります。

デザインスプリントでは、個人作業と匿名性のある投票を多く取り入れます。参加者全員が案を出し、具体的な内容を見ながら評価するため、発言力だけで方向性が決まる危険を抑えられます。

3.2 柔軟な開発方法との違い

柔軟な開発方法では、短い期間で設計、開発、確認を繰り返し、商品を段階的に改善します。実際に動作する機能を継続的に提供することが重視されます。

デザインスプリントでは、本格的な開発前に重要な仮説を検証します。動作するシステムではなく、本物らしく見える試作品を利用することで、開発期間をかけずに利用者の反応を確認します。

3.3 小規模な試験提供との違い

小規模な試験提供では、必要最低限の機能を実際に開発し、市場へ提供して反応を調べます。実際の利用状況や継続率を確認できる一方、一定の開発費用と運用体制が必要です。

デザインスプリントでは、試験提供よりも前の段階で、画面、接客、情報提供などを試作品として再現します。事業として運用する準備を整える前に、方向性が利用者に受け入れられるかを確認できます。

3.4 利用者調査との違い

通常の利用者調査は、既存の商品や顧客行動を理解するために行われます。聞き取りや観察を通じて、多くの課題や期待を発見できます。

デザインスプリントは、調査だけで終わらず、調査結果を基に解決案を作り、試作品を利用者へ提示します。課題の理解と解決策の検証をひとつの短期間の流れとして実施する点が特徴です。

3.5 違いを比較表で確認する

各方法には異なる役割があり、どれかひとつだけを利用すればよいわけではありません。デザインスプリントで方向性を確認した後、柔軟な開発方法で実装し、試験提供で継続的な利用状況を確認する流れも有効です。

目的に応じて方法を使い分けることで、調査、意思決定、開発、運用を効率的につなげられます。

4. 実施前に決めるべき課題と対象範囲

デザインスプリントの成否は、開始前の課題設定によって大きく左右されます。対象範囲が広すぎると5日間で扱いきれず、狭すぎると事業上の重要な判断につながりません。

ここでは、実施前に明確にすべき課題、対象顧客、体験範囲について説明します。

4.1 解決したい事業課題を明確にする

最初に、なぜデザインスプリントを実施するのかを整理します。「新しい画面を作りたい」ではなく、「初回利用者が価値を理解できず、登録後に離脱している」といった事業課題として表現します。

画面や機能を出発点にすると、既に決められた解決方法の確認になってしまいます。顧客と事業の両方に関係する課題を設定することで、複数の解決方法を検討できます。

4.2 対象となる顧客を具体化する

すべての顧客を対象にすると、異なる目的や行動が混在し、具体的な試作品を作りにくくなります。新規顧客、継続顧客、法人担当者、個人利用者など、対象を明確にします。

対象顧客を決めるときは、年齢や職業だけでなく、利用目的、経験、置かれている状況を整理します。同じ年齢層でも、初めて利用する人と経験者では必要な支援が異なります。

4.3 検証する体験の開始点と終了点を決める

顧客体験全体を5日間で検証することは難しいため、対象となる行動の範囲を決めます。広告を見てから登録するまで、問い合わせを開始してから解決するまでなど、開始点と終了点を設定します。

範囲を決めるときは、顧客が重要な判断を行う場面を含めます。単に操作画面を切り取るのではなく、顧客が価値を理解し、次の行動を決めるまでの流れを対象にします。

4.4 最も危険な仮説を選ぶ

商品やサービスには多くの仮説がありますが、5日間ですべてを検証することはできません。間違っていた場合に事業全体へ大きな影響を与える仮説を優先します。

たとえば、「顧客は自分で設定できる」「有料でも利用したい」「担当者に相談せず購入できる」といった仮説です。最も危険な仮説を検証することで、次の投資判断に役立つ情報を得られます。

4.5 成功と失敗の判断基準を決める

利用者検証後に都合よく結果を解釈しないために、事前に判断基準を設定します。五人中四人が価値を理解する、全員が支援なしで手続きを完了するなど、具体的な状態を決めます。

ただし、利用者数が少ないデザインスプリントでは、統計的な証明を目的にしません。共通して発生した問題や、強い反応が見られた箇所を次の判断材料として利用します。

5. デザインスプリントに必要な参加者と役割

デザインスプリントでは、多くの人を集めれば良いわけではありません。意思決定できる人と、課題に関する異なる知識を持つ人を適切に選ぶ必要があります。

ここでは、実施に必要な役割と参加者の選び方を解説します。

5.1 進行役

進行役は、時間管理、作業説明、議論の整理を担当します。自分の案を通すのではなく、参加者全員が手順に沿って作業できる環境を整えることが役割です。

進行役は、話が脱線したときに目的へ戻し、発言が一部の人に偏らないよう調整します。課題の専門家である必要はありませんが、デザインスプリントの流れを理解している必要があります。

5.2 決定者

決定者は、複数の案から最終的な方向性を選ぶ権限を持つ人です。全員の意見が一致するまで話し合うのではなく、必要な情報を確認したうえで決断します。

決定者が不在の場合、作業後に別の責任者から反対され、スプリントの成果が使われない可能性があります。可能な限り全日程に参加してもらい、難しい場合でも重要な意思決定の時間には必ず参加してもらいます。

5.3 顧客を理解している担当者

営業、問い合わせ対応、顧客調査の担当者など、顧客の行動や不満を日常的に把握している人を参加させます。社内資料だけでは分からない顧客の言葉や具体的な事例を共有できます。

ただし、一人の担当者の経験をすべての顧客に当てはめないよう注意します。問い合わせ記録、調査結果、行動データなど、複数の情報と組み合わせて判断します。

5.4 商品や技術を理解している担当者

商品担当者や開発担当者は、既存の仕組み、技術上の制約、実現可能性を説明します。自由な発想を妨げない範囲で、明らかに実現不可能な条件や安全上の問題を共有します。

技術的な制約を最初から強く意識しすぎると、既存の方法から抜け出せません。発想段階では顧客価値を優先し、絞り込み段階で実現方法を検討することが重要です。

5.5 試作品と利用者検証の担当者

試作品担当者は、選ばれた案を短時間で本物らしく見える形へ変換します。利用者検証担当者は、利用者へ質問し、行動や発言を引き出します。

ひとりが両方を担当することもできますが、作業量が多くなるため、可能であれば役割を分けます。検証担当者は、試作品を作った本人ではないほうが、利用者を誘導せず中立的に進めやすくなります。

6. デザインスプリント開始前の準備

5日間を有効に使うためには、参加者を集めるだけでなく、資料、会場、道具、利用者の手配を事前に行う必要があります。特に最終日の利用者検証は、スプリント開始後に募集すると間に合わない可能性があります。

ここでは、開始前に準備すべき項目を解説します。

6.1 必要な資料を集める

既存の商品資料、顧客調査、問い合わせ記録、行動データ、競合情報などを準備します。すべてを詳細に読むのではなく、課題を理解するために必要な情報を選びます。

情報が多すぎると、初日が資料説明だけで終わります。重要な数値、代表的な顧客の声、既に判明している制約を短くまとめ、必要に応じて原資料を確認できる状態にします。

6.2 作業場所と道具を整える

対面で実施する場合は、参加者全員が壁や大型の掲示面を見られる部屋を用意します。付箋、太い筆記具、投票用の印、紙、時計なども必要です。

作業内容を壁へ残すことで、前の判断を確認しながら次の作業へ進めます。毎回資料を開き直す必要がなくなり、参加者が全体の流れを把握しやすくなります。

6.3 遠隔実施の環境を確認する

遠隔で実施する場合は、共同編集できる掲示板、映像会議、試作品制作、録画の道具を準備します。参加者全員が事前に操作できるか確認します。

接続不良や操作説明で時間を失わないよう、短い練習時間を設けると効果的です。共同掲示板には日ごとの作業領域をあらかじめ用意し、迷わず書き込める状態にします。

6.4 利用者を事前に募集する

最終日の検証対象者は、開始前に募集します。対象顧客の条件を明確にし、実際の利用者に近い人を選びます。

社内の担当者や商品をよく知る人を対象にすると、一般の利用者とは異なる反応になる可能性があります。商品知識、利用経験、購入状況などを確認し、検証目的に合った参加者を集めます。

6.5 日程と参加条件を共有する

参加者には、デザインスプリントの目的、日程、必要な準備、途中参加が難しい理由を事前に伝えます。通常業務の連絡や会議が頻繁に入ると、集中作業の効果が下がります。

全日程を完全に空けられない場合は、決定者や専門家が参加すべき時間を明確にします。重要な判断が必要な場面に必要な人が不在にならないよう調整します。

コード例：準備状況を確認する簡易処理

準備項目 = {    "課題資料": True,    "参加者確定": True,    "決定者参加": True,    "作業場所": True,    "利用者募集": False,    "試作品道具": True } 未完了項目 = [    項目名    for 項目名, 完了状態 in 準備項目.items()    if not 完了状態 ] if 未完了項目:    print("開始前に対応が必要です。")    for 項目名 in 未完了項目:        print(f"・{項目名}") else:    print("デザインスプリントを開始できます。")

この例では、準備項目の完了状態を確認し、未完了の項目だけを表示します。実際の運用では、担当者、期限、状態、備考も追加すると、開始前の確認漏れを防ぎやすくなります。

7. 1日目の進め方：課題理解と目標設定

1日目の目的は、参加者全員が課題、顧客、長期目標を理解し、今回検証する重要な場面を選ぶことです。すぐに解決策を考えるのではなく、まず問題の全体像を整理します。

ここでは、1日目に行う具体的な作業を解説します。

7.1 長期目標を設定する

最初に、半年後や一年後にどのような状態を実現したいかを考えます。目先の画面改善ではなく、顧客と事業の両方にとって望ましい結果を表現します。

たとえば、「初めて利用する顧客が自信を持って商品を選び、継続利用できる状態をつくる」と設定します。長期目標は、その後の意思決定が迷ったときに戻る基準になります。

7.2 失敗につながる疑問を整理する

長期目標が実現しないとすれば、どのような理由が考えられるかを質問形式で整理します。「顧客が価値を理解できないのではないか」「設定が難しすぎるのではないか」など、危険な仮説を明確にします。

楽観的な目標だけでなく、失敗の可能性を具体的に考えることで、検証すべき内容が見えます。後から都合よく解釈しないためにも、重要な疑問を初日に記録します。

7.3 専門家から情報を集める

参加者や外部の専門家から、顧客、技術、事業、法務、運用に関する情報を聞きます。一人ずつ短時間で説明し、他の参加者は重要な気付きを記録します。

専門家への聞き取りでは、完成した解決策を求めるのではなく、課題、制約、過去の失敗、顧客の行動を確認します。異なる立場の情報を並べることで、問題の全体像が見えやすくなります。

7.4 顧客体験マップを作成する

顧客が目的を達成するまでの行動を、開始点から終了点まで時系列で整理します。左側に顧客や関係者、右側に目標を置き、その間の主な行動を記載します。

体験マップは詳細に作り込みすぎず、主要な段階を5個から15個程度で表現します。後で検証対象を選ぶため、顧客が重要な判断を行う場面を含めます。

7.5 検証対象となる場所を選ぶ

長期目標、疑問、専門家の情報、体験マップを確認し、今回のスプリントで扱う場所を決定します。最も危険な仮説と関係し、改善した場合の影響が大きい場所を選びます。

参加者全員の意見を参考にしながら、最終的には決定者が選びます。複数の対象を同時に扱うと試作品が複雑になるため、中心となる体験をひとつに絞ることが重要です。

8. 2日目の進め方：解決案の発想

2日目の目的は、選ばれた課題に対して複数の解決案を生み出すことです。自由な話し合いだけで案を出すのではなく、個人で考え、段階的に具体化します。

ここでは、2日目に行う発想作業を詳しく説明します。

8.1 既存事例から参考要素を集める

最初に、競合商品や異業種の優れた事例を確認します。商品全体をまねるのではなく、情報の見せ方、選択の支援、不安の減らし方など、参考になる要素を探します。

同じ業界だけを見ると、似た解決案に偏ります。顧客が感じている問題を抽象化し、異なる業界で同じ問題を解決している事例を探すことが重要です。

8.2 重要な気付きを個人で整理する

1日目に得た情報や参考事例を振り返り、解決案に関係する内容を個人で記録します。すぐに完成案を描くのではなく、顧客の目的、必要な情報、避けるべき問題を整理します。

個人で考える時間を設けることで、発言力の強い人の意見に影響されず、参加者全員が自分の視点を出せます。異なる専門性から生まれた案を後で比較できます。

8.3 複数の小さな案を短時間で描く

短い時間で複数の案を描き、最初の考えに固定されないようにします。画面の見た目を美しく描く必要はなく、情報や操作の流れが分かれば十分です。

同じ課題に対して異なる方法を考えることが重要です。説明を増やす、選択肢を減らす、担当者が支援する、順序を変えるなど、解決方法の種類を広げます。

8.4 最も有望な案を詳しく描く

複数の小さな案から、自分が最も有望だと考える方向を選び、利用者が体験する流れを数場面で描きます。開始、重要な操作、結果が分かるようにします。

説明者がいなくても内容を理解できる状態にすることが重要です。翌日の評価では、作者が案を説明せず、描かれた内容だけを見て判断します。

8.5 解決案を匿名で掲示する

完成した案には作者名を大きく表示せず、壁や共同掲示板へ並べます。役職や発言力ではなく、案の内容を基準に評価するためです。

作者がその場で説明すると、話し方の上手さが評価に影響します。必要な説明は案の中へ記載し、参加者が自分の速さで内容を確認できるようにします。

コード例：発想案を簡易保存する画面

<form id="発想案フォーム">  <label for="案の名称">案の名称</label>  <input id="案の名称" type="text" required>  <label for="解決する課題">解決する課題</label>  <textarea id="解決する課題" required></textarea>  <label for="体験の流れ">利用者が体験する流れ</label>  <textarea id="体験の流れ" required></textarea>  <button type="submit">案を保存する</button> </form> <script> document.getElementById("発想案フォーム").addEventListener("submit", function (操作) {  操作.preventDefault();  const 発想案 = {    名称: document.getElementById("案の名称").value,    課題: document.getElementById("解決する課題").value,    流れ: document.getElementById("体験の流れ").value,    登録日時: new Date().toISOString()  };  localStorage.setItem(    `発想案-${Date.now()}`,    JSON.stringify(発想案)  );  alert("発想案を保存しました。"); }); </script>

この例では、案の名称、解決する課題、体験の流れを端末内へ保存します。実際の共同作業では、利用者情報や機密情報を不必要に入力せず、組織が許可した共有環境を使用する必要があります。

9. 3日目の進め方：解決案の選定

3日目の目的は、2日目に作成した複数の案を評価し、試作品にする方向性を決めることです。長時間の議論ではなく、個別確認、投票、決定者の判断を組み合わせます。

ここでは、案の評価から試作品の設計図を作るまでの流れを解説します。

9.1 案を静かに確認する

参加者は、掲示された案を自分の速さで確認します。良いと思った部分、疑問がある部分、長期目標と関係する部分を記録します。

最初から全員で議論すると、最初に発言した人の意見へ引っ張られます。個別に確認する時間を取ることで、それぞれの専門性を生かした評価ができます。

9.2 良い部分へ投票する

参加者は、案全体だけでなく、特に良いと思った部分へ投票します。ひとつの案からすべてを採用する必要はなく、複数案の優れた要素を確認します。

投票結果は最終決定ではありませんが、参加者がどこに価値を感じたかを可視化できます。票が集中した部分だけでなく、専門家だけが評価した重要な要素も確認します。

9.3 疑問点を短く確認する

案ごとに進行役が内容を説明し、参加者が確認したい点を短く質問します。作者は必要な事実だけを補足し、長い弁明や販売説明を行いません。

目的は案を守ることではなく、正確に理解することです。批判への反論が始まると議論が長引くため、時間を区切って進めます。

9.4 決定者が方向性を選ぶ

参加者の投票と専門的な意見を参考にしながら、決定者が試作品にする案を選びます。人気投票だけで決めるのではなく、事業上の重要な仮説を検証できるかを重視します。

複数の案を組み合わせる場合は、体験が複雑にならないよう注意します。すべての良い要素を入れるのではなく、今回の検証に必要な部分だけを選びます。

9.5 絵物語形式で体験を設計する

選ばれた案を基に、利用者が最初に見る場面から検証終了までの流れを絵物語形式で整理します。通常は10場面から15場面程度に分けます。

この設計図は、4日目の試作品制作に使われます。画面の内容、表示する文章、利用者の操作、次の場面を具体的に決めることで、制作中の追加議論を減らせます。

10. 4日目の進め方：試作品の制作

4日目の目的は、3日目に作成した設計図を、利用者が本物だと感じられる試作品へ変換することです。完成品を開発するのではなく、検証に必要な部分だけを作ります。

ここでは、短時間で効果的な試作品を制作する方法を説明します。

10.1 検証に必要な範囲だけを作る

試作品には、利用者検証で触れる部分だけを含めます。裏側の処理、管理画面、実際の情報連携などは、検証に不要であれば作りません。

すべての機能を再現しようとすると、1日では完成しません。利用者が重要な判断を行う場面と、その前後の体験に集中します。

10.2 本物らしさを適切に調整する

試作品が粗すぎると、利用者は実際の使用場面を想像できません。一方、細部を作り込みすぎると時間が不足し、本来検証したい流れが完成しない可能性があります。

利用者が操作や判断を現実的に行える程度の本物らしさを目指します。商品名、画像、文章、価格など、判断に影響する情報は具体的に用意します。

10.3 制作担当を分担する

画面制作、文章作成、画像準備、試作品の接続、内容確認など、作業を分担します。全員が同じ画面を同時に作ると、調整に時間がかかります。

作業開始前に、共通の文字表現、画面幅、部品の使い方を決めます。最後にひとりが全体を統合し、体験の一貫性を確認します。

10.4 検証用の文章を具体的に書く

仮の文章や意味のない文字列を使うと、利用者が内容を理解できず、正しい反応を確認できません。実際の提供時に近い説明、選択肢、料金、注意事項を記載します。

文章の分かりやすさ自体が検証対象になる場合もあります。社内用語を避け、顧客が日常的に使用する言葉で書きます。

10.5 事前確認を行う

完成後は、検証担当者が利用者役となり、最初から最後まで操作します。リンク切れ、表示不足、説明の矛盾、次に進めない場所がないか確認します。

試作品の不具合によって検証が止まると、利用者の反応ではなく制作上の問題を確認することになります。検証開始前に修正できるよう、4日目の最後に確認時間を設けます。

コード例：画面遷移型の簡易試作品

<div id="試作品">  <section class="画面 表示中" data-screen="1">    <h1>あなたに合うプランを確認します</h1>    <p>三つの質問に答えると、候補を絞り込めます。</p>    <button data-next="2">確認を始める</button>  </section>  <section class="画面" data-screen="2">    <h2>最も重視することを選んでください</h2>    <button data-next="3">費用を抑えたい</button>    <button data-next="3">支援を重視したい</button>  </section>  <section class="画面" data-screen="3">    <h2>おすすめのプラン</h2>    <p>初期費用を抑えた標準プランが適しています。</p>    <button id="申込ボタン">このプランを選ぶ</button>  </section> </div> <script> document.querySelectorAll("[data-next]").forEach(function (ボタン) {  ボタン.addEventListener("click", function () {    document.querySelector(".画面.表示中").classList.remove("表示中");    const 次の画面番号 = ボタン.dataset.next;    document      .querySelector(`[data-screen="${次の画面番号}"]`)      .classList.add("表示中");  }); }); </script> <style> .画面 {  display: none; } .画面.表示中 {  display: block; } </style>

このコードは、複数の画面を順番に表示する簡易試作品です。実際の申し込み処理は行わず、利用者が情報を理解し、選択できるかを確認する用途に適しています。

11. 5日目の進め方：利用者検証

5日目の目的は、対象顧客に試作品を使ってもらい、重要な仮説が成立するかを確認することです。利用者に感想を聞くだけでなく、実際の行動、迷い、発言を観察します。

ここでは、利用者検証の具体的な進め方を解説します。

11.1 検証前に目的を説明する

利用者には、本人の能力を試すのではなく、試作品の分かりやすさを確認することを伝えます。正解や不正解はなく、迷った点を率直に話してもらうよう依頼します。

試作品であることも伝えますが、作り手へ遠慮しないよう説明します。利用者が担当者を喜ばせようとすると、実際よりも好意的な回答になる可能性があります。

11.2 最初に普段の行動を聞く

試作品を見せる前に、関連する経験や現在の行動を聞きます。過去にどのような商品を利用したか、どこで情報を探したか、何に困ったかを確認します。

最初から試作品への意見を求めると、表示された内容に回答が影響されます。普段の行動を先に理解することで、試作品が現実の状況に合っているか判断できます。

11.3 考えながら操作してもらう

利用者には、何を見ているか、何をしようとしているか、どの部分が気になるかを声に出してもらいます。操作結果だけでは分からない判断の理由を理解できます。

ただし、検証担当者が正しい操作を教えてはいけません。利用者が迷った場合は、「今、何を探していますか」と質問し、行動の背景を確認します。

11.4 観察担当者が記録する

別室または遠隔環境で、参加者が検証の様子を観察します。利用者の発言、行動、感情、問題が発生した場面を個別に記録します。

観察中に解決案の議論を始めると、重要な行動を見逃します。まず事実を記録し、すべての検証が終了してから共通点を整理します。

11.5 複数の利用者に共通する傾向を探す

ひとりの利用者だけが迷った場合は、個人差の可能性があります。複数の利用者が同じ場所で迷った場合は、設計上の問題である可能性が高くなります。

利用者の人数が少ないため、単純な割合だけで結論を出しません。強い拒否反応、重大な誤解、予想外の使い方など、事業判断に影響する発見を重視します。

コード例：利用者検証の記録を集計する

検証記録 = [    {"利用者": "A", "価値理解": True, "完了": True, "迷った場面": "料金説明"},    {"利用者": "B", "価値理解": True, "完了": False, "迷った場面": "申込確認"},    {"利用者": "C", "価値理解": False, "完了": False, "迷った場面": "料金説明"},    {"利用者": "D", "価値理解": True, "完了": True, "迷った場面": "なし"},    {"利用者": "E", "価値理解": True, "完了": False, "迷った場面": "料金説明"} ] 価値理解数 = sum(    1 for 記録 in 検証記録    if 記録["価値理解"] ) 完了数 = sum(    1 for 記録 in 検証記録    if 記録["完了"] ) 迷いの集計 = {} for 記録 in 検証記録:    場面 = 記録["迷った場面"]    if 場面 == "なし":        continue    迷いの集計[場面] = 迷いの集計.get(場面, 0) + 1 print(f"価値を理解した人数: {価値理解数}") print(f"操作を完了した人数: {完了数}") print("迷いが発生した場面:", 迷いの集計)

この例では、価値理解、操作完了、迷った場面を集計しています。数値だけでなく、利用者が発言した理由や、迷う直前に見ていた情報も記録すると、改善案を考えやすくなります。

12. 利用者検証後の判断と次の行動

デザインスプリントは、5日目の検証が終わった時点で自動的に終了するわけではありません。結果を整理し、継続、修正、再検証、中止のどれを選ぶか判断する必要があります。

ここでは、検証結果を次の行動へつなげる方法を解説します。

12.1 事実と解釈を分ける

利用者の発言や行動を事実として整理し、その後に原因や意味を考えます。「購入ボタンを押さなかった」は事実ですが、「価格が高いと感じた」は確認が必要な解釈です。

事実と解釈を混ぜると、担当者の思い込みによって結論が変わります。利用者が見た情報、行った操作、発言した内容を基に判断します。

12.2 仮説ごとに結果を整理する

初日に設定した疑問や仮説に戻り、それぞれが支持されたか、否定されたか、判断できなかったかを整理します。単に「反応が良かった」とまとめないことが重要です。

たとえば、価値は理解されたが、料金への不安が強かった場合、商品全体を否定する必要はありません。価値提案は維持し、料金説明を修正して再検証できます。

12.3 問題の重要度を評価する

すべての問題を同じように扱う必要はありません。利用者が一瞬迷っただけの問題と、商品価値を誤解して利用を中止する問題では、重要度が異なります。

顧客への影響、発生人数、事業への影響、修正の難しさを考慮します。重大な問題から優先的に修正し、細かな表現は実装段階で改善する方法もあります。

12.4 次の選択肢を決める

結果に応じて、本格開発へ進む、試作品を修正して再検証する、別案を試す、課題設定から見直すといった選択を行います。良い結果だけを理由に即座に大規模開発へ進まないことも重要です。

デザインスプリントで確認できるのは、限られた顧客と体験範囲です。技術、収益性、運用、安全性など、別の検証が必要な場合があります。

12.5 学びを組織へ共有する

試作品だけでなく、利用者の発言、問題が発生した場面、否定された仮説を共有します。結果だけを短く報告すると、なぜその判断に至ったのかが伝わりません。

録画、観察記録、体験マップ、試作品をまとめ、後の開発や別の事業でも参照できる状態にします。失敗した案も、同じ間違いを繰り返さないための重要な知識になります。

13. 短縮版デザインスプリントの進め方

通常の5日間を確保できない場合は、2日間や3日間へ短縮して実施する方法があります。ただし、単に作業時間を削ると、課題理解や利用者検証が不十分になる可能性があります。

ここでは、短縮版を実施するときの考え方と進め方を解説します。

13.1 2日間で実施する場合

1日目に課題理解、目標設定、顧客体験マップ、発想、案の選定まで行い、2日目に試作品制作と利用者検証を行います。事前準備の完成度が特に重要です。

課題や対象顧客が既に明確で、既存の調査結果が十分にある場合に適しています。初めて扱う複雑な事業課題では、情報整理だけで時間が不足する可能性があります。

13.2 3日間で実施する場合

1日目に課題理解と発想、2日目に選定と試作品制作、3日目に利用者検証を行います。5日間版よりも圧縮されていますが、主要な流れを維持できます。

試作品を短時間で作れる商品や、検証する体験範囲が狭い場合に適しています。制作が複雑な場合は、2日目だけで完成できるよう、事前に部品や資料を用意します。

13.3 分割して実施する場合

連続した日程を確保できない場合は、課題理解、発想、制作、検証を複数週に分ける方法があります。ただし、作業の間隔が長いと、参加者の集中や共通認識が失われます。

各回の終了時に決定事項、未解決事項、次回の作業を記録します。可能な限り短い間隔で実施し、参加者が変わらないようにします。

13.4 事前作業を増やして短縮する

専門家への聞き取り、資料整理、顧客体験マップの下書き、利用者募集などを事前に行うことで、当日の時間を短縮できます。

ただし、進行役だけで課題や体験マップを確定すると、参加者の理解が不足します。当日は内容を共有し、必要な修正と意思決定を行う時間を残します。

13.5 省略してはいけない作業を理解する

短縮版でも、課題の明確化、複数案の比較、決定者による選択、試作品、利用者検証は残す必要があります。これらを省略すると、通常の企画会議と変わらなくなります。

特に利用者検証を後回しにすると、社内で案を選んだだけで終了します。短縮する場合でも、実際の対象顧客から反応を得ることを最優先にします。

14. Googleデザインスプリントで起こりやすい失敗

明確な手順があっても、課題設定や参加体制を誤ると、デザインスプリントは十分な成果を生みません。形式だけをまねるのではなく、各作業の目的を理解する必要があります。

ここでは、実施時に起こりやすい失敗と対策を解説します。

14.1 課題の範囲が広すぎる

「新規事業を考える」「顧客体験を改善する」といった広い課題では、5日間で具体的な試作品を作れません。参加者ごとに想定する顧客や体験も異なります。

対象顧客、重要な行動、検証したい仮説を明確にします。広い事業課題の中から、最も危険で影響の大きい体験を選びます。

14.2 決定者が参加していない

決定権を持つ人が不在だと、参加者が案を選んでも、後から承認されない可能性があります。全員が納得するまで議論を続け、時間を使い切ることもあります。

開始前に決定者を明確にし、重要な判断の時間を確保します。代理人が参加する場合は、どの範囲まで判断できるかを事前に確認します。

14.3 解決案を早く決めすぎる

初日から特定の案に決めていると、デザインスプリントが既存案を正当化する場になります。別の案を考えても形式的な比較になり、本当の検証ができません。

課題と仮説を先に整理し、2日目に複数の案を作ります。経営者や商品責任者が持つ案も、他の案と同じ条件で評価します。

14.4 試作品を作り込みすぎる

本物に近づけようとして細部へ時間を使うと、重要な体験が完成しない可能性があります。制作したものを変更したくないという心理も生まれます。

検証する仮説に必要な部分だけを作ります。裏側の処理や利用者が触れない画面は省略し、見せる部分の内容を具体的にします。

14.5 利用者へ誘導してしまう

担当者が試作品の使い方を説明したり、良い点を強調したりすると、実際の利用時とは異なる反応になります。作り手は無意識に案を守ろうとすることがあります。

質問は中立的に行い、「このボタンを押してください」ではなく、「次に何をしますか」と尋ねます。検証担当者と試作品担当者を分ける方法も有効です。

コード例：失敗要因の危険度を整理する

失敗要因一覧 = [    {"要因": "課題範囲が広い", "発生可能性": 5, "影響度": 5},    {"要因": "決定者が不在", "発生可能性": 3, "影響度": 5},    {"要因": "利用者募集が遅い", "発生可能性": 4, "影響度": 4},    {"要因": "試作品を作り込みすぎる", "発生可能性": 4, "影響度": 3} ] for 項目 in 失敗要因一覧:    項目["危険度"] = 項目["発生可能性"] * 項目["影響度"] 危険度順 = sorted(    失敗要因一覧,    key=lambda 項目: 項目["危険度"],    reverse=True ) for 項目 in 危険度順:    print(f'{項目["要因"]}: 危険度{項目["危険度"]}')

この例では、発生可能性と影響度を掛け合わせて危険度を計算します。開始前に危険度の高い項目を確認し、担当者、期限、予防策を決めると実施上の問題を減らせます。

15. Googleデザインスプリントを成功させるポイント

Googleデザインスプリントを成功させるには、5日間の手順を守るだけでなく、課題設定、参加者、意思決定、利用者検証、実施後の行動まで一貫して設計する必要があります。

最後に、実務で成果を生み出すための重要なポイントを整理します。

15.1 検証したい仮説をひとつに絞る

多くの機能や課題を同時に扱うと、試作品も利用者検証も複雑になります。検証結果が悪かった場合、どの要素が原因なのか判断できません。

事業への影響が大きく、不確実性の高い仮説を中心に設定します。関連する体験を含めながらも、利用者に確認したい中心的な疑問を明確にします。

15.2 利用者の行動を重視する

利用者が「良いと思う」と回答しても、実際に操作できなかったり、申し込みを選ばなかったりする場合があります。意見だけでなく、行動と発言の両方を確認します。

特に、迷った場所、戻った場所、読み飛ばした情報、誤解した表現は重要です。肯定的な感想よりも、具体的な行動から改善点を判断します。

15.3 時間制限を守る

デザインスプリントでは、完成度よりも学習速度を重視します。ひとつの議論や制作作業に時間を使いすぎると、利用者検証まで到達できません。

進行役が各作業の終了時間を明確にし、未解決の問題は別に記録します。限られた情報の中で決定し、試作品を通じて確認する姿勢が必要です。

15.4 結果が悪くても隠さない

利用者の反応が悪かった場合、それを担当者や商品への否定と捉えると、結果を都合よく解釈してしまいます。デザインスプリントの目的は、案を成功に見せることではありません。

問題を早期に発見できたことを成果として扱い、否定された仮説を組織へ共有します。失敗から得た情報を次の案へ生かすことで、開発全体の成功確率を高められます。

15.5 検証後の行動を事前に決める

スプリント終了後の責任者や意思決定日が決まっていないと、成果物が保存されるだけで終わります。開始前に、誰が結果を整理し、いつ次の判断を行うか決めます。

開発へ進む場合は要件整理、再検証する場合は修正範囲、課題から見直す場合は追加調査を計画します。5日間を単独の催しではなく、事業開発の意思決定工程として位置付けることが重要です。

おわりに

Googleデザインスプリントは、複雑な事業課題に対して長期間議論を続けるのではなく、課題理解、発想、意思決定、試作品制作、利用者検証を通常5日間で行う方法です。完成品を開発する前に重要な仮説を確認できるため、大きな投資を行う前に方向性を判断できます。

進め方は、1日目に長期目標と顧客体験マップを整理し、2日目に複数の解決案を作成し、3日目に試作品へ進める案を選びます。4日目には検証に必要な範囲だけを本物らしい試作品へ変換し、5日目に対象顧客の行動と発言を確認します。

成果を高めるには、適切な課題設定、決定者の参加、対象顧客に合った利用者募集、中立的な検証、終了後の意思決定が欠かせません。最初から完璧な商品を目指すのではなく、小さく形にして早く学び、得られた事実を次の判断へつなげることが、Googleデザインスプリントを活用する最大の意味です。