1 pixel|サイバーエージェント公式クリエイターズブログ

サイバーエージェントのクリエイターの取り組みを紹介するオフィシャルブログです。最新技術への挑戦やサービス誕生の裏話、勉強会やイベントのレポートなどCAクリエイターの情報が満載です。


Theme:
はじめまして。
ディレクター、UXデザイナーをしている大塚です。
今回は、5日間でアイデアを形にし、利用者に評価してもらい検証する「デザインスプリント」というプロセスについてご紹介します。

新規サービスを立ち上げたり、新機能を検討し、延々とブレストを繰り返し、いつまでたっても話がまとまらず、ようやくかたちになったら、あまり利用されずに終わってしまうということは、想像しているより良くあることです。
新製品の70-80%が投資分が回収できないという統計もあります。また、その失敗の理由の一番が42%で、市場にニーズがなかったというものです。熱意をもって開発し、仲間と散々議論を交わした製品がそのようになってしまうのは悲しいですが、現実としてよくあることなわけです。

サイバーエージェントで10年間ディレクターとUXデザイナーとして、いろんなプロジェクトに関わってきた私にとって、成功確率をあげ、素早く市場に出すことは常に命題です。
プロジェクトで議論するときにいつも思っていたのが、アイデアを形にするプロセスで、ブレストが単にメンバーのはけ口を形式的 に出す場になっていると感じたり、議論するなかで意見の強い人の話に延々と付き合わされて不毛に感じたり、内向的な方の意見を上手く引き出せないということです。
また、ユーザーファーストと言いつつも、リサーチをしたり、本当の利用者と向き合う時間やプロセスが十分にできていないと感じることもありました。

そんな時、先にも述べましたが、5日間でアイデアを形にして、利用者に試してもらい検証する「デザインスプリント」というプロセスは、非常に魅力的に思えました。
Googleでは既に多くのプロジェクトで実績があるとも聞いたので、さっそく試してみようということで、日本でデザインスプリントを啓蒙されているMicrosoft Venturesの馬田さんにご協力いただき教えていただきました。
社内の勉強会や実践したプロジェクトで良い点や難しい点など見えてきた部分があるの で、その話も交えて、デザインスプリントについてご紹介したいと思います。



デザインスプリントとは?

デザインスプリントとは、Google Venturesが提案しているスタートアップ向けのプロセスで す。
Design Thinkingの手法をベースにLean Startupの考えを発展させています。5日間という時間制限に区切られてアウトプットする手法で、時間でフレーム区切り自らを追い込みます。また、決定のプロセスが効率的且つ民主的に行われるという特徴をもっています。概念や具体的なプロセスも、馬田さんのスライドにまとまっているので、そちらを参考にしてみてください。
ここでは、簡単な5日のプロセスだけ書き出しておきます。


http://www.slideshare.net/takaumada/design-sprint

http://www.slideshare.net/takaumada/design-sprint-process

DAY1: Understand
課題を理解し、競合を調べ、戦略を検討します。

DAY2: Diverge
可能な限りたくさんの解決法を検討します。

DAY3: Decide
ベストなアイデアを選んで、ユーザーストーリーを打ち出します。

DAY4: Prototype
デザインがある程度はいった、プロトタイプをつくります。

DAY5: Validate

プロトタイプを本当の利用者に見せて、何がうまくいき、なにがうまくいかないのかを学びます。


デザインスプリントのプロセスについて

スプリントのプロセスにはいろいろな手法が組み込まれてますが、やり方はスライドにのっているので、ここでは実際にやってみてどうなのかという部分を中心にご紹介していきます。

デザインスプリント社内勉強会の様子

DAY1: Understand(理解)

初日は、メンバーがあつまりプロジェクトについて様々なことを理解を深め検討する日です。プロダクトオーナー(プロデューサー、事業責任者、社 長など、事業の種を持ち決定権を持っている人)に必ず参加してもらいます。プロジェクトの最初のころは、大体、どういうプロジェクトなのか各メンバー説明 をうけているのが普通ですが、じつは蓋をあけてみると、それぞれの理解度や知識、アイデアや、思いにかなりのバラつきがあります。それぞれの考えを出して チームをシンクロさせることが必要です。
このタイミングでリサーチが既に終わっていたり、利用中のサービスの定量分析などの資料が あれば、そこからスタートもできると思いますが、ない場合は、リーンペルソナなど作ったり、そもそもだれが本当のユーザーになりそうなのかという仮説の認 識をあわせても良いかもしれません。指標についてみんなで話し合うのもプロジェクト理解をかなり深めます。Heartフレームワークは指標を絞り込むやり方としては便利かもしれません。
ス プリントで解決する課題をこのタイミングで決めるようにします。とはいいますが、ここは実際難しいと感じる部分かもしれません。新規の開発で、課題やス コープが複雑すぎて捉えられない、よく見えないということもあります。最初のスプリントはこのぼやっとしたところを明確にするぐらいのスタートでも良いか もしれません。できる限りの情報を事前に集め、課題の整理がしっかりとできるところまでやりきれた方がよいでしょう。

DAY2: Diverge(発散)
このプロセスはデザインスプリントの中でも比較的楽しいプロセスです。DAY1で話した課題に対しての解決法をチームみんなで具体的 な案としてアイデアを出す日です。社内でデザインスプリントの勉強会を馬田さんにやっていただたい時も、この部分を中心に行っていただきました。
  • Crazy Eights:UIを作成するときにアイデア出しのための練習。A3の紙を8つに区切って1区切り40秒で画面のアイデアをだしていく
  • Silent Critique:各個人で作成したアイデアを張り出して、静かに見て、良いと思ったアイデアに投票していきます。
Crazy Eightsはやってみると、非常に楽しいのと同時に、非常に頭も使うので、上手く休憩なども織り交ぜてやるとメリハリがつきます。Silent Critiqueは、なるべく喋らずに投票して、個人の意見がしっかりと出せるようにします。わからないと人の意見に頼りたくなりますが、決めるタイミングは静か周りと喋らず に考えて決めていきます。
UIを投票で決めるというと、「えっ、多数決かよ!」と思う人もいると思いますが、議論して多数決をするのとは違います。議論して多数 決をすると、多くの人が最初に発言した人、強い意見の人の発言にながされてしまいます。Silent Critiqueの場合は、声の大きい人の意見だけで話がすすむことは避けられます。個人の意見をしっかりと出した上で、皆が共通で感心のあるアイデアだ けに絞り、議論して、最終の投票を行います。
なぜ、これが良いのかというと、同時にチーム全員のアイデアの引き出し、同時にチーム全員の意思を反映させる ことができるので、非常に効率的な意思決定ができます。また、自分の意見がしっかりと反映されるという安心感がチームにできるとこもメリットです。
もし、これを通常のブレストで行うと、最後まで結論がでずに、次回に持ち越しや、決められる人数2-3人に減らしたところで最終決定するとかになってしまう ケースもあると思います。また、1人ひとり話をしていくとチームメンバーが8人いて平等にアイデアを述べ、更に意見交換までし始めるといくら時間があっ てもたりません。限られた時間のなかで、アイデアを出しきり、ルールによって決定を導き出す手法は実際にやってみて有効に感じられるポイントでした。



DAY3: Decide(決定)

この日は、色々と整合性があわないアイデアや、どっちか悩んでいるアイデアを両方つくるのか、片方だけのテストにするのかなど決めて収束する日となっています。しかし、実際に行ってみると、もうデザインし始めないとヤバいという感じになります。2日後には既にアポイントをとっている人たちに対してプロトタイプを試してもらう必要があるので、とにかく創りながら議論しながらみたいな感じになります。
前日まで、手書きのラフばかりだったので、もっと多くの詳細がないと つくれないということに気がつきます。例えば、ラベリングや説明文、画像などをどのようにしようかとなります。場合によっては、実現可能性を再検討する必要もあ るかもしれません。
DAY2のときにそこまで検討できればよいのですが、発散のフェーズではそういう思考になりにくかったりするので、現実的にこの日で収束させるよう頑張るしかないという感じです。スプリントの良い所でもあるのですが、ユーザーテストが開始されてしまうという約束があるので、ここでチーム が立ち止まることが許されません。
また、大事なポイントとして、決定するときにプロジェクトオーナーの関わってもらうということがあります。関わりが薄いと、後で覆ってしまう原因にもなるので、できるだけスプリントを通して、プロジェクトオーナーが関われるようにミーティングに入ってもらった り、必要なポイントでアイデアをぶつけるタイミングをつくる必要があります。



DAY4: Prototype(プロトタイプ)
ユーザーテストと前日なので、ここからは作りきることに集中します。
Keynoteをつかってプロトタイプをつくるとなってますが、ここら辺は、ProttFlintoinvision といったプロトタイピングツールをつかうのが楽です。既存のUIパターンも出回ってるので、そういうものを使って素早く組 み上げます。もし運用しているサイトで既にUIパターンがあれば、それを使って組み上げても良いかもしれません。
最初の段階では、デザインのブラッシュ アップ作業はする必要はなく、試作品として、テストできるレベルでつくります。プロトタイプの形容詞によく"汚く、粗く、素早く"といった単語がでてきますが、荒すぎるとあまり機能しません。例えば、急ぐあまり、読ませるべきテキストが"ダミーダミーダミー"みたいな仮のものになっているとテストにならないので、現実に近いものを入れる必要があります。また、画像も荒く汚すぎると、肝心な部分がみえなかったり、印象が悪すぎてその部分に気を取られてしまうので、ユーザーになにを読み取ってもらうのかを意識してつくりましょう。また、デザインが間にあわない箇所は、画面キャプチャーの組み合わせをつかう時 があります。そういう時に、スプリントの最初のころに行う競合調査や、既存のサイトを確認する段階で、キャプチャー画像を取り貯めて、チームみんなが使え る様にしておくと便利でしょう。

DAY5: Validate(検証)
出来上がったユーザーテストを実施する日です。
初期の段階でのユーザーテストで以外と大事なのはヒアリングです。プロトタイプの精度がたかければ、細かいユーザビリティーのフィードバックを観察によって 得られますが、ペルソナもぼんやりしている初期の段階では、ヒアリングフォーカスした方がより価値のある情報が得られるように思います。
テストの実施は、ユーザー1人に対して、2人で行います。1人がファシリテーターと録画係を兼務し、1人がユーザーの思考発話を記録するのが良いでしょう。実施人数は5人程度で十分と一般的にされますが、現れない方のための人数調整などは必要かもしれません。
ユー ザーテストをすると、その後のチームへのフィードバックにも時間はとられるので、テスト実施者以外にも現場にのぞきに来てもらうと良いかもしれません。 (ただし、全員ユーザーを囲って無駄にユーザーにプレッシャーをかけると本来のテストができなくなりますので、ご注意を。)
テストの際に事前にGoogle Formなどでつくったアンケートフォームを用意しておき、すぐに集計して、チームメンバーに展開できるようにしておくと素早いフィードバックが可能になります。
ユーザーテストは事前に仮説でたてたユーザーストーリーに沿って検証できるように設計する必要があるので、想定する利用シーンを描いて、スプリントでたてた仮説が検証できるようにしましょう。
つくるのに夢中になって、仮説や検証する項目を見失うこともあるので、スプリントの途中からユーザーテストの設計とつくっている内容をシンクロさせる必要があります。早めにテストを設計しておくのもひとつの手段かもしれません。



デザインスプリントの良い所、難しい所

振り返ってみて、デザインスプリントの良い所は下記と感じています。

・チームのシンクロ
・効率的なアイデア出し
・素早い検証

UIデザインをみんなで考えるので、逆にデザイナーが力量を発揮する領域を減らして要るんじゃないかと心配になりもしたのですが、やってみるとデザイナーも1人で考えるよりアイデアの引き出しも増え、1人でなんとかしなくちゃ行けないという呪縛からも放たれるようです。
多くのプロジェクトでは、構成案をプラン ナーやディレクターが1人で考えたり、デザイナーに丸投げだったりすることが普通だと思うので、そこでやっていた押し付け合いや、その後に発生するエンジ ニアからの突っ込みや、さらにその後に発生するオーナーからの突っ込みなども十分吸収できる手法だと思います。
また、何よりプロジェクトの補正が聞く段階で ユーザーによる検証があるので、そこで正解/不正解が確かめられるというのは、大きな安心でもあります。もちろん、リリースするまで安心など幻想ではあり ますが、リスクが不安になり消極的になる必要もないと思える事はチャレンジを前進させてくれます。

逆にデザインスプリントの難しい部分は下記だと感じました

・ファシリテーターの学習
・スプリントのスコープ
・チームメンバーの拘束時間の調整

デザインスプリントをやる時には、ファシリテーター役が必要で、そのファシリテーターの力量によってもスプリントが変わってきます。しかし、どうやってやるのかは、ネット上に挙がっている情報を元にやってみるぐらいのことしかできず、本に書かれているわけでも、講座があるわけでもないので、そういう意味で実践しながらやるしかなく、ハードルがやや高いのかな思っています。また、実際やるとスプリントのスコープをどれくらいにすれば良いのかの判断が難しいなと思 う場合があります。また、実際のプロジェクトでは、メンバーもビジネス要件もすべて揃ってから開始ということもなく、最初は少人数で動き始め、徐々にチー ムメンバーと情報も揃ってくるというのが実際なので、どのタイミングでスプリントを実施すべきかというのも以外と迷うポイントになります。
5日でアイデアを形に検証するというのは、非常に素早くデザインができて、要件も速く固まる印象がありますが、実際は繰り返しのスプリントを行わないと良い仕上が りにならないので、そこで誤解がうまれないようにしておかないといけません。
そして、1番の問題は、チームメンバーの拘束時間が結構とられてしまうという部分もあります。チーム全員でタックルするから良いというのはあるものの、継続していくためには、チームメンバーの時間的な部分を配慮する必要があり、そういったところは上手くチームにフィットできるよう上手く調整する必要があります。

まとめ

デザインスプリントは、弊社ではまだ試みているフェーズです。
デザインプロセスにとって面白いアプローチの一つであり、GoogleやBBCのような企業では既に多くのプロジェクトで実践されているということなので、懐疑主義になるより実践して理解を深めることで、チームのアイデアと向き合う方法になるのではないかと思ってチャレンジ しています。


* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

デザインスプリントの勉強会はMIcrosoft Venturesの馬田さんにご協力いただきました。
ご協力いただいたMicrosoft Ventures馬田様に、デザインスプリントやスタートアップについてご相談があれば、ご連絡いただければより詳しい情報が得られると思います。

ここまでご覧いただきありがとうございました。

(記事作者:Toshiaki Otsuka)
いいね!(21)  |  リブログ(0)
ページトップへ戻る