短期間でサービスのプロトタイピングから検証までを実施するDesign Sprintで得られるものとは？

Webやアプリの新規サービスを制作する際、チームの予想だけで仮説を構築し、最後までそのアイデアが効果があるものかどうか分からないままローンチをしてしまった、という事はないでしょうか。または、新しい機能のアイデアが閃き、半年以上かけてメジャーアップデートをしたにも関わらず、成果に結びつかなかった、という経験はないでしょうか。
CB Insightsが発表した調査結果によると、スタートアップが手がけるサービス失敗のほぼ半数は、市場のニーズがなかったことに起因するとされています。なぜこのような事が起こっているのでしょうか。それは新規のアイデアをサービスとしてリリースまたはサービスの一部として追加する際に、アイデアの妥当性や効果を検証しながら導入していくというプロセスを経ることなく世に出されているということが要因として考えられます。ここでは、短い期間で検証したいアイデアを具体化し、必要最小限のプロトタイプを用いて実際の顧客に対して価値の検証を実施するDesign Sprintというスプリントプロセスと、プロセスを実践してみたことにより得られたことをご紹介していきます。

Design Sprintとは

Design Sprintとは、米Google Venturesがスタートアップ支援の為に用いているプログラムで、5日間で新規のアイデアをプロトタイプとして具体化し、実際の顧客に近しい被験者へのインタビューを通じてアイデアの妥当性や効果の検証を行うものです。今回Standardでは、このプログラムを積極的に日本で導入し、スタートアップ支援に活用しているMicrosoft Venturesの馬田さんにご協力をいただき、以前から社内で出ていたサービスアイデアの0→1の立ち上げのための取り組みとして実施をさせていただきました。また、実施にあたってはStandardから鈴木2名と吉竹、FICC inc.三宅さん、dely在籍中のデザイナー貴島さん、フリーランスのサービスデザイナー塚由さんの6名でチームを組み参加しました。

実施した事

プログラムの細かな説明は、SlideShareでご説明をいただいているのでそちらをご紹介させていただきます。通常5日間で実施するプロセスを2日に分けて実施するということでかなりのスピード感でそれぞれのプロセスを体験することとなりました。今回作ろうとしているサービスについての具体的な説明は割愛しますが、1日毎に定められたステップを実践し、成果物をアウトプットしながら具体化のためのアウトラインを固めていくという流れで進行していきました。

Day1 : Understand

ここでは、チームメンバー間でのディスカッションを通して、これから作ろうとしているサービスを求めているユーザーが抱える問題に対するチーム全員の知識や見解を共有しあい、現状の理解を一致させます。また同時に、今回の5日間のスプリントの中でフォーカスすべき1つの問題を決めることが目的です。
ディスカッションを通じて理解の度合いを合わせておくトピックとしては

• 市場やビジネス機会
• 競合製品や類似製品
• 現製品の操作方法の理解
• デザイン上のメトリクス
• 製品の調査データ等を元にした顧客の理解
• カスタマーサービス等顧客と接触しているメンバーへのヒアリング
• Analyticsの各数値に対する考察

のようなものがあり、定められた時間の中で、1トピックにつき10分間のディスカッションを行い、議題に上がったキーワードは全てポストイットで掲出していき、後で参照できるようにします。

共通理解をすることができたら、メンバー全員で協調しながら、サービス内で重要なユーザーストーリーにフォーカスしたマップを描きます。新規サービスであれば、そのストーリーの中でコアとなる機能とサービスのバリュープロポジションを決めていきます。既存サービスであれば、解決したいポイントを定め、スプリントでのゴールを定めます。全ての課題を解決できるプロトタイプを作ることはできないため、今回のスプリントでどんな事を検証したいのかを決めます。
決める際には、プロトタイプを見せたときにユーザーから何を学びたいのか？また、学ぶためにどんなプロトタイプを作るべきか？をしっかり議論します。また、問いかけるのをためらうくらい「明確な質問（そもそもこれって◯◯か？のような）」をしてみることで、メンバーの理解を深めることができます。

Day2 : Diverge

2日目では、Day1で決めた問題を解決するための可能性をチーム全員で出し合って、最適なソリューションを絞り込んでいきます。

Day1で作成したユーザーストーリーのうちの1つの区切り（チャンク）毎に、必要とされる要素や機能を含んだUIのアイデアを手書きのスケッチとしてまとめます。
まとめる際は、A3の用紙を8つに折り目をつけ、それぞれのマス目に1つの画面アイデアを40秒で描くのを8回＝5分で実施する「Crazy 8s」という方法でアイデアを拡散させていきます。
各メンバーは他のメンバーのものを見ずに、個別に静かに自分のアイデアを書き続けます。Crazy 8sが終わったら、次のステップではA3用紙に書いたスケッチを参考に、該当する画面のUIアイデアを説明するためにユーザーが画面上で何が出来るかをまとめたユーザーダイアグラムを書いていきます。書き終えたらそれぞれの紙を壁に横一列に貼り、投票を通じて最適なソリューションを絞っていきます。票が割れた際は、決定権があるメンバーが採用すべきアイデアを決定します。

Day3 : Decide

ユーザーストーリーの各チャンクのUIアイデアが揃った所で全体のストーリーボードを作っていきます。ユーザーが実際に触るものに限りなく近い状態で作成するのが望まれるため、詳細な仕様やタップやクリックした際の挙動など、詰め切れていない部分をこの時間を使ってチーム全員で明確化していきます。また、前日のUIアイデアの中で似通った部分や競合（コンフリクト）する部分が出てきたら、意思決定者は2種類のプロトタイプを作ってテストするか、複数の案のうちどれが最良かを決定しなければなりません。

Day4 : Prototype

Day3のストーリーボードを基に、ユーザースタディのための詳細なプロトタイプを作っていきます。ストーリーボードで詳細な要素や仕様を明確化しているため、検証したい全ての画面のプロトタイプが出来るよう分担して作業を進行していきます。プロトタイプではビジュアルデザインの要素（装飾やボタンの色や角丸の比率など）の作り込みではなく、見た目が最低限リアルなUIコンポーネントやステンシルのようなものを使って高速にプロトタイプを作成していく必要があります。またその際は限りなく実際の使い心地に近くなるよう、仮のダミーテキストや◯◯◯さんのような名前ではなく実際に読んで理解できる文章やラベル付けを心がけます。
最終的にFlintoやinVisionなどのツールにアップロードし、学習したい部分の画面遷移を繋いでいきます。

Day5 : Validate

Day4で作成したプロトタイプをユーザーに使ってもらうことで、どのアイデアが受け入れられ、どのアイデアが受け入れられないのかを学びます。
テストを始める前に、インタビューを通して何を学びたいのかを明確にします。キーとなる質問をリスト化して、半構造化インタビューの準備をします。SkypeやHangoutでの画面共有を利用して、インタビュールームと観察ルームを分けて実施する準備をします。

インタビューが始まったら、観察ルームでは基本的に全員がそれぞれ気付いたことを紙にメモしていきます。一人のみはPCでインタビュー中のすべての言葉をリアルタイムに筆記するようにし、インタビュー後の参照用の情報として用います。
1人のインタビューが終了する毎に、30分の時間を設けてメンバーの気付きをまとめていきます。メモは良かった点／問題点／その他で分かりやすいよう色分けし、書き終え次第、次のインタビューを開始します。インタビューで明らかになった点を踏まえた次のアクションや解決すべき問題点は、決定権者が別途リスト化していきます。

インタビューが全て終了したら、スプリントを終える前に次のスプリントについて検討します。インタビューの結果によって次のスプリントを実施するか、するならどのステップから実施するかを決めます。

• ほとんどの物事がうまくいったケース：修正すべき点を見つけてプロトタイプを修正し、Day3からやり直す。
• いくつかの大きな疑問が生まれたケース：いくつかは上手くいき、いくつかは微調整が必要、いくつかはダメだったケース。Day2からやり直し、プロトタイプのアイデアを練り直す。
• 全部だめだったケース：よくあるケース。ただの失敗ではなく何がダメだったかを学べた意味では前進したと言える。Day1から再び始める。その際に今回の結果をDay1のエクササイズの材料として用いる。

スプリントを終えて

今回のスプリントはこの日のために集まったチームでの参加となったため、サービスアイデアについての共通認識の形成や市場やビジネス機会の理解、ターゲットとする顧客の潜在的な課題についてのインサイト調査等が浅い状態での進行となり、冒頭の合意形成やサービスとしての網羅性に重きを置いた時間の使い方をしてしまい、最も検証したい仮説にフォーカスしきれていないという課題がありました。ただそれを差し置いても、短時間で必要最低限の共通認識を形成し、その前提を元にアイデアの拡散と収束、プロトタイプとしての具体化をし、実際にユーザーを招いてのインタビューを実施できた、という事自体が非常に学びとなる2日間となりました。

Design Sprintは、新規サービスの立ち上げにも、既存サービスの改善にも活用できるプロセスとのことですが、決めることが多い新規立ち上げのフェーズで導入する際は、サービスの全ての機能をいかに漏れ無く網羅するか？ではなく、最も検証が必要なポイントに絞り、関係するシナリオのみをプロトタイプとして落としこむことでサービスのコンセプト部分の検証ができるのではと感じています。
また、既存サービスであれば、改善したいポイントや課題と感じられている要因が明確なため、その箇所を改善するためのアイデアの発散と収束が可能になり、短い期間で改善案の効果を検証できるのではないでしょうか。予め最終日のユーザーインタビューで学びたい事は何か？を明確化した上で、該当する箇所のユーザーストーリーやプロトタイプ作成、インタビュー設計をすることが重要です。

Standardでは、スタートアップやIT系企業の新規事業としてのサービス立ち上げや改善に関わる事が多いですが、個人的にはサービスがリリースされた後のグロースに貢献する改善のアイデアを練る際に、クライアント企業内のチームと合同で実施することが学びと成果に繋がるのでは？と感じました。

プロセスを実施するだけでは良いサービス・プロダクトは生まれない

ビジネスモデルキャンバスやLean Startupに始まり、Lean UXや顧客開発モデル、今回のDesign Sprint等、サービスデザインをする上で進め方の指針となるようなプロセスや情報が、事業会社やサービスデザインファームだけでなく企業内の担当者レベルまで普及してきているのを今年になって実感しています。かつて日本に初めてSNSやB2Cサービスが出現した頃と比べ、サービスデザインをする上でのハードルはとても低くなったように思えます。

しかし、これらのプロセスを習得し実践するだけで必ず良いサービスが出来るのか？と言えば、そこには疑問が残ります。
リーンキャンバスを用いて各マス目をただ埋めたとしても収益モデルに貢献するKPIを探し出し、その行動を促す体験を感じさせるようなUIが設計出来ていなければサービスは存続しません。
ペルソナやカスタマージャーニーマップを作ってサービスを使うであろう人物や行動を明確にしたとしても、それを元にステークホルダー間での合意を得ていなければただの社内資料になってしまいます。
これらのプロセスや手法は目的達成のための手段でしかなく、実現したい事に対して適したアプローチを取らなければ、プロセスを実施したとしてもそれ以降活用されない資料になってしまったり、実施すること自体が目的になってしまったり、意図が汲み取られないまま最後は自分たちの主観でアウトプットを決めてしまう、という事に繋がってしまいます。
どのようなプロセスがあるのかを知ること、正しい実施方法を学ぶことは重要ですが、それだけではなく、プロセスを実施することで得られることは何か？何のために実施すべきか？を踏まえた上で、目的によって必要なプロセスやアプローチを選ぶような、プロジェクト自体を設計していく能力がより重要になってくるのではないでしょうか。

今回ご協力いただいたMicrosoft Venturesでは日本から海外と戦えるスタートアップを輩出すべく様々な取り組みをされています。Design Sprintの実施や実施時の詳細については、Microsoft Ventures馬田様宛にご連絡いただければより詳しい情報が得られると思います。