The Design Sprintのトレーニングセッションに参加してきました。

先日、機会をいただいて、Google Venturesが提唱している、
The Design SprintというDevelopment Process(開発手法)のトレーニングセッションに参加してきました。

The Design Sprintは、

【新しいプロダクト・アプリ・Webサイト・機能を考える】

際に、

【 個人 】でアイデアを考える・プロトタイプを考える
【 皆 】でフィードバックする、分岐する、検証する

ことを繰り返します。

そのサイクルの中でアイデア・プロトタイプを具体化・洗練していきます。
最終的にプロトタイプを実際に使ってもらう・プレゼンしていくという所まで持っていきます。

Google Venturesでは、投資先のスタートアップの機能のブラッシュアップなどを行う際に、
この手法を利用しているようです。

最近日本に上陸したブルーボトルコーヒーもこの手法を利用して、オンラインでの販売方法のアイデアを練ったようです。

The design sprintのWebサイトでは、5日間という期間で、
このサイクルを行うと書いてあります。
実際には、2日間で行ったり、と様々な期間で行うことがあるそうです。
今回は、2-3時間程度という短い時間の中で、
大まかな流れをグループワーク形式で実践してきました。
僕のチームは5人で実施しました。

やったこと(概要)

※あくまで、ワークショップの中でやったことで、実際のDesignSprintとは異なります。

1.今回のスプリントの対象プロダクト・アプリの説明を受ける
2.メンバー同士の紹介を行う

5人ほど、様々な職種の特徴が書かれたカードを渡される

3.この人が価値を置いていること、求めていることを考える(個人)
4.1人選び、その人のニーズや価値観の認識をチーム皆で共有する
5.その人のために、実際に作ってみたい機能を考える(個人)
6.意見交換しながら、価値があるアイデアを投票によって決める
7.紙にその機能が使われる象徴的なシーンを考える(個人)
8.みんなでフィードバックしながら、これだというシーンを1つ選ぶ
9.そのアプリ・機能の名前を決定する
10.UIの絵コンテを考える(個人)
11.説明しつつ、フィードバックをうける
12.プロトタイプのUIを検討する
13.プレゼンする

やったこと(詳細)

1.

今回のスプリントの対象プロダクト・アプリの説明を受ける
メンバー同士の紹介を行う

ここは今回の研修で一番時間の制約上使えなかったことだと思います。

ただ、今回のテーマになるアプリ・製品・機能について、
どういったことを大切にしているかということを説明していただきました。

・製品・機能コンセプト
・デザインコンセプト
・サンプル
などを説明してもらいました。

実際にDesign Sprintを行う際も
メンバーは何かしらの組織や、プロジェクトに属している状況で行われることが多いと思います。
ここで大切なのは、可能性を狭める(こういうことは出来ません)とかを共有するわけではなく、
大きなレベルでのコンセプトや、大切にしていることの共有、課題の共有ということになるでしょう。

その後で、各チームメンバーの紹介を行いました。
実際は職種毎に持っている知識や問題点の共有を行うのだと思います。

参考(The First Step In A Design Challenge: Build Team Understanding(英語))

本当は、ここでもう少し話が出来ればよかったんですが、
研修では時間の都合上あまり時間がとれませんでした。

1-2.ペルソナの定義

5人ほど、様々な職種の特徴が書かれたカードを渡される
1人選び、その人のニーズや価値観の認識を共有する

次にペルソナを考える所からグループワークを開始しました。
これはいわゆるDesign Sprintを始める為の前準備のようなものだと思います。

http://www.gv.com/sprint/

に記載している「Set the stage」に該当する作業の一つだと思います。

今回は最初に6人の異なる職種、趣味を持つ人のカードが配られました。
その中から1人選び、その人の

1.必要としていること
2.求めていること(こういうのがあったらいいな
3.一番価値を置いていること(価値観

は何かということをまず個人で考えます。(5-10分)
ここで出すアイデアは具体的なアプリの機能にとらわれる必要はありません。

・自分の経験を共有することを必要としている
・旅行のサポートをしてくれるものがあったらいいな
・実体験に価値を置いている
・子供とのコミュニケーション
・おいしいレストランが知りたい
など

個人で考えた後で、みんなの考えをシェアします。
その後で、どのペルソナがいいと思ったか、というのを投票で決めます。
(時間が短いのもあったと思うんですが、ここでは議論せずにスパっと決めました)

ペルソナについて
http://smmlab.jp/?p=20107
http://itpro.nikkeibp.co.jp/article/Keyword/20080124/291960/

2.

その人の為に実際に作ってみたい機能を考える(個人)
意見交換しながら、価値があるアイデアを投票によって決める

ペルソナが決まった所で、いよいよアイデアを練る作業に移行していきます。
まずは、ペルソナを元に、この人にあったらいいな、、という機能を個人でたくさん考えます。(10分)
イデアを付箋に次々と貼っていきます。
(ここでは実現の可能性などは一旦置いておいて、とにかくたくさんのアイデアを出すことにフォーカスします)

10分でアイデアを出した後で、

ホワイトボードに書いたグラフに1人2,3個ずつ順番にアイデアを説明しつつ、プロットしていきます。(10分)
(2,3個ずつにするのは一人がずっと話続けない為)

f:id:takahiro-f:20150207205427p:plain

x軸、y軸はそれぞれ下記を表しています。
X軸 : Complexity(複雑さ)
Y軸 : Value(ユーザへの価値)

ちなみに、これは相対評価なので、意見が出るたびに、それぞれの付箋の位置がずれたりするようです。
一通り、出た後で、一人2枚のシールが渡されました。

それぞれが気に入ったアイデアにシールを貼っていきます。
(どうしてもこれ!というのがあれば、一つのアイデアに2つシールを貼ってもいいそうです。)

そして、投票の結果、これだ!というのを一つチームで決めました。
傾向としては、やはり【 難しいけど、価値が高い 】 という所に投票が集まりました。
一方で技術的に難しくなくとも、盲点だった点や、価値の点でやはりこっちがいいということで、
比較的難しくないながらも価値が高いアイデアにもある程度投票が集まりました。

そうして、一つのアイデアが選ばれました。

3.

紙にその機能が使われる象徴的なシーンを考える(個人)
みんなでフィードバックしながら、これだというシーンを1つ選ぶ
そのアプリ・機能の名前を決定する

次に、紙を8等分におって、
考えたアイデアが使われている代表的なシーンを8つ絵コンテ的なものを書きます。(個人で5-10分)

f:id:takahiro-f:20150207205437p:plain

ここで、大切になのは、考えたアイデアがユーザにどんな体験をもたらすものなのか、考えるということです。

特に、Googleのサイトでは多いのですが、サービスを紹介するサイトで、
「機能の紹介をするのではなく、象徴的な体験を紹介する」
ことが多いということを聞いて、なるほどなと思いました。
特にandroid関連のプロダクトは徹底されているように感じます。

https://www.google.co.jp/intl/ja/drive/
http://www.android.com/auto/
http://www.android.com/wear/

今回の研修の中で、一番悩んだのがこのフローでした。
以外と、実際使っている象徴的なシーンが、ビビっと出てこなかったりします。

書いた後は、一個一個のシーンをそれぞれが説明していきます。
その後で、このアプリをどんなシーンで使って欲しいのかというのを考えて、象徴的なシーンを一つ投票で選びます。
それと同時に、アプリの名前をこのタイミングで今回は決定しました。

どんな時に、どんな風に使ってもらうか

というのは、コンセプトそのものです。
たしかに、このタイミングで名前を決めるのも理にかなっているなと思いました。

4.

UIの絵コンテを考える(個人)
説明しつつ、フィードバックをうける

さて、実現したいアイデア、象徴的な利用シーン、アプリ・機能名
が決まったので、次はUIイメージを描いていきます。
先ほどと同じような紙に、UIを描いていきます。(個人で10分)

次にそれぞれがUIのコンセプトについて説明をしていきます。(10分程度)
ここではどんどんFBしていきます。が、基本的にはポジティブフィードバックで、
どこがいいのかというのを探していく感じでした。

5.

プロトタイプのUIを検討する
プレゼンする

その後、最終的なUIをどうするか、みんなでまとめる作業に入っていきます。(5-10分程度)
ここでは、ある程度みんなの意見をハイブリットしていきました、特に意識していたわけではなく、
自然とそうなっていったという感じです。

そうして出来たプロトタイプを、他のチームのメンバーに向けて発表していきます。
今回は1チーム1分という非常に短い発表時間でしたが、これは時間の制約も大きかったと思います。


振り返り

まず、今回は1日完結のワークショップということも書いてあり、
上のワークショップと実際のDesign Sprintでは異なる点も多くあります。

そんな中でも今回の機会を通じて一番面白いと思ったことは、


【 個人作業とフィードバックを短いサイクルで繰り返す 】
【 ニーズの共通認識がある 】

ことです。これは、個人のアイデアを洗練させてく上で、非常にいいやり方だと思いました。

【 個人作業とフィードバックを短いサイクルで繰り返す 】

フィードバックと個人のアイデア出しの感覚が長いと、改善のステップはやりにくくなります。
長いサイクルの場合は、改善というよりは、ちゃぶ台返し(やりなおし)するか自分の意見を押し通すかのパターンになることがおおいです。
また、長い時間考え抜いた個人のアイデアに対して、短い時間のフィードバックで直す場合は、
色々納得できないなと思うことがおおいです(絶対俺のアイデアの方がいいのにといか

それに対して、短い時間でアイデアを考え、FBして、段々と考えていくことが、 具体化 されていく。
という今回のDesign Sprintの流れでは、自然と個々人の考えの中で価値があると感じたものが残り、改善、洗練されていきます。
また、万が一、自分のアイデアが選ばれなくても、すぐに挽回のチャンスが来るんですw
自分の意見が選ばれなかったら興味を失うタイプの人も比較的多いと思うのすが、この手法だと、
常に自分のアイデアを考えるフェーズがやってきます。

そのため、一人で考えるのが好きだという僕のようなタイプでも、
議論がやりやすかったなと感じました。

【 ニーズの共通認識がある 】

これも、アイデアを出す上で非常に重要だなと思いました。
最初にペルソナを定義し、この人が価値を置いていること、という部分で共通の認識をもってからアイデアを出し合います。
そのため、「いやいやそんな機能全然いらねーし」みたいなことはなかったし、そもそもニーズの想定が違かった
なんてことで意見がぶれることも無かったです。
このおかげで、どの機能が有益か、ということに集中して作業が出来たと感じました。

この先

まずは、The Design Sprint自体に興味が出たので、まずはこの記事をちゃんと読んでみようと思いました。
僕はエンジニアですが、エンジニア内でアイデアを出す際にも、
プロトタイプを考えることを【 個人作業とフィードバックを短いサイクルで繰り返す 】という手法は、
使えるなと感じました。
早速取り入れていけたらなと。