- 2015/3/6に行われたDesign Sprint Night! 〜 先駆者たちから聞くDesign Sprint の実際 - connpassに参加したときのメモと感想です。
- プログラムの話じゃないですけど、最近仕事でこういうのも関わるようになりまして、メモメモ。
- 本人の発言やスライドの内容をそのまま書いているわけではなく、私の受け取ったイメージで書いてるところもあります。
- 予備知識として「デザインスプリント」について知るには、まず下記の2つのスライドを抑えておくのがいいです。
私の疑問点
この勉強会の話をきいて、私が疑問に思ったことを先に書いておきます。教えて偉い人！
DSの効果としてBlueBottoleCaffeとかPocketで「こんな成果でました」という話があるが、これは最初からKPIとして設定していたのか、結果としてこうなったのか(なぜならデザインスプリント(以下DS)のプロセスの中で目標値の設定の話が出てこないから)
- 「ユーザーストーリー」というのがよく理解できていない。そのシステム、画面を使って、「ユーザーがある目的を達成するために、どういう手順で、何を操作するか」かな？
- Day5でユーザーテストするときはプロトタイピングしたもの。それを本実装するのはいつ？Day5で出てきた課題を解決できたかどうかは再度ユーザーテストが必要になると思うのだけど、そこはまぁ自分たち判断でいいのかな。
- 「前進している感じがある」のと「やった結果が成果につながる」かは別だと思うのだが、成果になっているのかの確認もスプリント内にあるのかな？
デザインスプリント概要 (Microsoft Ventures 馬田 隆明さん)
スプリント＝短い時間で区切って、いかに解決していくか
5日目のインタビューをとおして検証する。その結果の学習を活かして、新しいアイディアを回す
背景コンセプト
- 締め切り駆動開発＆制限による創造性
- 短いタイムボックスでどんどん決める、進める
- 集団の力
- 従来のブレストの効果を否定的に見てる。
- みんなで出すけど、決まったことに関して納得感が薄い、あるいは「結局誰かが決める」
- DSは「アイディアは個人。意思決定は集団」
- 従来のブレストの効果を否定的に見てる。
- Art&Fear
- 「質優先で一個つくる」より「量を優先してたくさん作ったものの中から出てくるもの」のほうが優秀
- 素早く作って、素早く失敗、そこから学ぶ
5日目にユーザーテストした時に「これじゃない」といういう声が聞けているのは成果だ
DSは顧客発見、開発、運用改善、あたりに効果がある(下記スライドのP12)
Day1
- 今あるチームの課題を知る → ユーザーストーリーを書いて、どこにフォーカスするか決める
- 「どの問題を解決するか」が最重要。課題を全ては解決できないので優先度を決める。
- これは登壇者みんなが言ってた。ここがズレてると無駄になるって。
- 小さい過ぎると意味が無い(1人でできるから。みんなで、1週間かけて取り組める粒感…)
- フォーカスポイントを決める時に、「HEART」フレームワークが有効。課題に対して解決するか、を決める。
- Day2
- 発散は個人、決断は集団
- Day3
- ユーザーストーリーをつくる。紙でもいい。
- 画面遷移図とか
- ユーザーストーリーをつくる。紙でもいい。
- Day4
Day5
- インタビューの結果、よかったところ、わるかったところ、気づいたところ、を色分けして書き出す(ヒートマップ的に)
- 30分インタビュー、30分振り返り、そのあと別の人に30分インタビュー、、、の繰り返し
- 1人がインタビュー、もう1人がメモ役。
- 操作しているところを録画する、画面キャプチャする、とかもありそうだが手間かかるよね
- 結果のメモを付箋に書いて張っていく → 学習が進む
- 課題が出てくる → 優先度が必要 → Day1に戻る
上記が基本だけど自分たちにあったプロセスに変えてく
- その後のセッションで数社の人の話があったけど、どこも「集まる人」とか「投下時間」は自分たちなりに変えていた
- 確かに通常業務がある中で5日間フルで拘束する、は厳しいよね...
- DSは全ての問題を解決できるわけじゃない
THE GUILD 深津 貴之さんの話
大事なこと
- 部署をまたいでいろんな人を呼ぶ
- 作業を時間で区切る
- 個人ワークとグループワークを高速で回す
Googleでは「お試し」として5日間ではなく、2時間でやるプランがある
- 5日版は全方向から情報を共有
- 2時間バージョンは、5枚の仮想ペルソナが設定してあってその人の1人に対して何かする
発散
- HMWの精神
- How might we?「我々はいかにして解決できるか？」
- 「どうせできない」という否定的な考えを排除する
- Crazy8
- 元はGameStormingの6-8-5の手法
- アイディアの共有では「YES AND」で答える。他人の意見に上乗せする
- DotVote アイディアの温度感がでる。最終決定者はいる。半民主主義みたいな感じ。
- HMWの精神
決断
- バトルロイヤル(複数の案をもっと練ってから決める) or ベストアイディア(この時点で「これだ！」を一点決める)
試作
- 個人で画面遷移(とは限らないけど)をつくる
評価
- 2時間のワークショップではユーザーインタビューの代わりに1分間のプレゼンをした
スプリントの長所
- 最初から全員を巻き込める
- 全ステークホルダーからの多角的なアイディア
- (関係者の思いの)全体を俯瞰できる
- 民意を把握しつつ責任が明確になる(合意形成)
- →軸がぶれない、政治でひっくり返らない
- エース不在でも、安定して８５点を出せる手法
有効に機能しないケース
- メンバーに突出した人がいるとその人に任せた方がいい(権限の集約)
- 自分の意見を通したい人がいる
- 思ってるより重い。スケジュールの確保とか。軽くする工夫どころが重要
- 全員が参加するだけの重要度が高いところだけやる工夫
- 参加出来ない人には決まったことに対して意見できないくらいの権限委譲をしてもらっておく
- 意思決定に高度な専門知識が必要なもの（新薬とか統計とか）←いろんな視点からの意見を持ち寄れる
- 最低条件
- スプリントの対象(何を改善したいのか)が的確
- 意思決定者から現場まで巻き込む
- フラットな立場で意見いえること
- 何度も繰り返すこと
こういう時は有効
- 全員が初めて会って思い・価値観がバラバラ
- 各人が何を考え、何を大事にしているのかわかる
- チーム内に声の大きい人がいる
- 後半に入ってきた人がひっくり返されることがある
- ボスの権限できまるかつ打率が低い
まとめるとこんないいことがある
- 俯瞰することで、ミスをなくす、
- 全員の共通認識で進められる
政治的にひっくり返されることをなくすために最初に合意できる
デザインスプリントの記事を翻訳している
- http://labs.theguild.jp
- (ここ、すごく役に立つので皆さんにも読んで欲しい)
ここでワークの時間
- 「ビルの入り方」の改善をテーマにCrazy8をやる
- 背景
- ヒカリエに入る時に名刺出したり、名前やIDを申告したりして大変
- もっとラクに入館したい
- とはいえセキュリティも大事
- これを解決するようなアイディアを8つ上げる
- やってみたが7つしか埋まらなかった…
- ワークはここまで。以下、感想
- 35秒というなかで絵に書くって、慣れないと大変。でも楽しい。
- その後のススメ方として
- 自分で書いた中で有力案3つくらいを人に見せられるように清書するみたい
- 全員分張り出す
- Voteする
DeNA 坪田 朋さんの話
- なぜDSか？
- 過去の課題
- ビジョンは分かったが、具現化フェーズで詰まる
- 特定の人（UI担当者とか）に負荷が集中する
- 思考フェーズが長いとスケジュールが押す。やり残したままリリース
作って、壊して、評価して、を超高速で回したい(半強制的に)
こんないいことが
- アイディアの具現化からユーザーテストまでが一連の流れになっていて、ゴールが現実的
- 時間が長い、プロセスが長いと論理破綻がしない
- 短い時間で可能性を出すような設計→全てのプロセスが高速に進む
- 知恵を「ひねり出す」のに体力は使うが、早い。
- 複数のブレストより、１人で考えた案を持ち寄るほうが質が高い
- サイレントクリティーク
- 意思決定者を中心にベストなデザインを決定するルールになっている
- 意思決定をしたことの納得度
- ？？？もう一個あったけど聞き逃した
- アイディアの具現化からユーザーテストまでが一連の流れになっていて、ゴールが現実的
- やってみると疲れる
- やりきった感、前進してる感がある
- エンジニア、企画の人、が中心になるといい
サーバーエージェント 大塚 敏章さんの話
- なぜDSか？
- ブレストで意見がまとまらない
- 結局、限られた人で集まって決める
- エンジニア、デザイナー、プロデューサーの思いや大切にするモノ、違う時間の使い方、ユーザー像が違う
- それで「ユーザーの事を考えて」作っていけるのか？
- みんなが譲りあって、曖昧になる
- 自分のアイディアも捨てきれない（採用されても思ってたんと違う)
- これまでの手法ではユーザーテストは終盤
坪田さん、大塚さんの対談
- DSにファシリテーターは必要か？
- チームメンバーの誰か、でもいいと思う
- ただ、始めの何回かは馬田さんのようにプロセスに慣れた人がいた方がいい
- ムズカシイところ
- いっしょにやる人に理解してもらうところ。
- デザイナ以外は絵を描くとか苦手
- それを促す雰囲気作り
- 時間の作り方。特に運用している案件に対するスプリント
- 集まった情報に対する個々人の理解度、専門性が高いとやりにくい
- 実際は？
O：5日でやってみた。が、次の週また5日拘束、とかは厳しい
T：新規案件の時は5日でガッツリ。
- とはいえ運用案件は全員フルコミットはムズカシイので、フレームワークは使いつつも、必要な人でやる
- ファシリテーターはどの立場の人がいいか？
- T：意思決定者に近い人はしないほうがいい。明るく場を和ませることができる人
- O:中立的な人。決定者はちがう。
- T:得手不得手はあると思うので、全員が回せるようになる、がいい。だれでもできる
- 大手企業ならではの導入しにくさ
- 採用までに政治で一苦労、とかあるらしい
- プロセスを可視化して共有する、のは大事。
- プロデューサーが数字しか見てないことがある。一回でも巻き込むと印象、意識が変わる。
- デザイン、てついてるけど、デザイナーがやるとは限らなくていい
- 「やって意味あるの？」に対しては「5日でデザインできてユーザーテストもできる」という返しは有効。
- オリジナルに忠実？変えてる？
- 試作を全員でやる、は重いので、出来そうなメンツでやっている
- 最初はフレームワークにそってやってるけど、次第に「ここはデザイナとエンジニアで」とかやってる
- スプリントが終わった後のレビューはやってるか？
- やっていない。ひたすら作る。レビューは評価の中で。それを活かして次にやる
- 繰り返しやっていく中でアイディアが固まったら分業になっていく。そこの切り替えしがムズカシイ
- 社内の反響は？
- そんなに浸透してないｗ ブログ書いて外から評価されてると中でもやりやすい。
- 偉い人からの理解
- エンジニアの人たちの巻き込み方は？コードを書きたがると思うのだが・・・
- 新規のときはやりやすい
- やってみるとエンジニアの感想もいいものになる
- なんでこのデザインになったのか、がわかる。
- 特にUIがなんでこうなってるのか、あるいはUIを作るまでの経緯(の大変さ)が考えられるようになる
- プロセス自体が面白い。UIを一緒に考えられる。オーナーともデザイナともシンクロできる。
- UIのプロセスがエンジニアはよくわかってない、が解消される
- やることになって、工数見積もったら間に合わない、的なこと
- 結局やれといわれるのかよ、的なことになりがち
- 品質を求められるときはスケジュールを動かす
- 期間内に成果をだす、は求められる
ココナラ 新明 智さんの話
- スタートアップに大事なこと＝Issue（ユーザー課題)を特定、解決するための多様な観点がある
プロトタイピング(を元にして下記が生まれる)
- concept
- communication
- improvement
タイムボックス
- 時間をかけるほど壊しにくくなる。愛着がわく
- 100%のものではなく、70-80%をどんどん出していく
- ユーザーテスト
- 出す前に触ってもらう
- 意図通りかどうか確認できる
これを繰り返す（Iteration)
苦労したこと
- ユーザーテスト協力者の確保
- 課題の収束のコントロール
- 意思決定者を長い間拘束できない
Standard Inc. 鈴木 健一さんの話
- サービス全体として
- 誰の、どんなことのために作るのか
- どのようにつかわれるのか、使ってほいのか
- どうすれば利用者、事業者にメリットがあるのか
新明さんと鈴木さんの対談
- スタートアップにとってデザインは重要
いろんな観点の人を巻き込むか（ユーザーのことを知ってるのはCSの人だったりする）
DSはスタートアップに対して効果はあるのか？
- 中にデザイナがいないこともある
- 何をしたらいいかわからない
- 短期間で発散と収束ができるのは有効
プロダクト製品(組込みなどH/Wがあるものとか)にも適用できるか？
- スプリント中にプロトタイプができるもの、なら実践できる
- 作って試してもらう、というのが重要
一体感は？
- チームとして何が課題で、どう解決するか、がわかっているのでその後の話がやりやすい
ダメだったところ
- Day1での共通認識が取れなかった
- 課題の設定をミスるとだめ。１週間かけてやることか？と
- 学びたい範囲をはっきりさせる（KPIが明確、とか。それを上げるにはどういう選択肢があるのかとか)
インタビューイの集め方
- 代々木公園で話しかけることもあった
- １周目が大変。２周目は集めやすくなる
- 協力者に協力してくれる人を聞く
- ユーザーテストを常に回してないと集めにくい
- FBの友達経由が多かった
ユーザーテストする歳に、どれくらいペルソナに近い人を集めたのか
- 実際は外れた人もいた
- ココナラ：年代と性別は重視（サービスによって変えるんだろうな)
- ココナラ：自分たちのサービスを知らない人(というターゲットだったのでここは意識した)
スタートアップならではの難しさ
- 人数が少なくてみんなでやってる、事業には向いている
- 分業になってくる（１３人位？）になってくるとやりにくいかも
- 時間拘束はされるので大変
何を課題にするか、は大事。ハマるもの、ハマらないものはある。
Day1で問題意識とか、ギモンを解消させるのはものすごく重要
まとめ
- 会社、文化にあったスタイルに変えていく