こんにちは！ミクシィでデザイナーをしているえんあかです😃

前回の記事では今のチームでプロダクトデザインのフレームワークとして採用しているデザインスプリントのメリットに関してまとめました。

意思決定が速くなるし、チームビルディングとしても効果的なデザインスプリント。しかしながら、いざ導入するとなったらハードルが高いと感じた方も多かったのではないでしょうか？

😩デザインスプリント実施にあたっての悩み😩
・実際どうやって進めればいいの？
・そんな5日間もチームメンバーのリソースを確保できない...
・ワークを短縮するとしてもどこを削ればいいのか...

確かに今の業務をストップして、チームメンバー5日間のリソースをもらうってかなり勇気がいることですよね。うまくいくか最初は不安ですし...。

しかし実は、私たちのチームでは教科書通りで進めると5日間かかるデザインスプリントを、2日間（+α）に短縮して実施しています！そこで今回は、私たちのチームで実施している２日間デザインスプリントのアジェンダを紹介したいと思います。

2日間（+α）で行うデザインスプリントとは？

デザインスプリントは「理解＞発散＞決定＞プロトタイプ＞テスト」の5つのフェーズそれぞれを1日ずつ、計5日間で実施するとありました。それを私たちのチームでは「理解＞発散＞決定」までのフェーズを短縮して２日間で実施しています。またその2日間に収まるように実施するワークも絞っています。

進め方としては1日目に理解と発散フェーズ、2日目に決定フェーズを実施します。とはいえ臨機応変に、その時々で発散フェーズを２日目に回したりアレンジすることもあります。

プロトタイプとテストはやらないの？もちろん実施しないわけではありません。ただ、プロトタイプ以降の作業はチーム全体で時間を確保するのではなく、作業を分担して進めていきます。その時間が+αの時間です。私たちのチームでは、プロトタイプはデザイナーが、テストはPOやディレクターがメインで担当しています。
+αの時間はありますが、メンバー全員のスケジュールを押さえるのは2日間だけで済むので、導入ハードルは少し下げられるのではないかなと思います。

では各ステップのアジェンダをさらっと紹介していきましょう！こちら全部ちゃんと読む必要はないです。初めはこんな感じで進めるんだ〜ってざっくり知ってもらえればOKです！
そして、実際やってみようってなったらこのアジェンダを参考に計画してもらえれば嬉しいです。各ワークの内容については詳細を書くと長くなってしまうので、書籍でご確認ください🙏

では、スタート🏃‍♂️🏃‍♂️🏃‍♂️💨

DAY1：UnderStand（理解）

1. プロジェクト背景の理解（30分）
プロジェクトに関する事前知識を共有して、チームメンバーのサービスへの理解レベルを揃えます。プロジェクトのコンセプトや背景、またリリースされているサービスであれは利用状況の定量・定性データなどを共有します。さらに今後の短期的・長期的なビジョンも共有すると、サービスの進むべき方向性が共通認識になり、その後のワークが進めやすくなります。

2. 課題の定義（30分）
付箋に対象の課題を書き出していきます。対象の課題を理解しなければ良い解決策は生まれません。全員で課題の定義について議論し、解決しようとしている一般的な課題について合意します。

3. Who/Do エクササイズ(30分)
ホワイトボードなどを2列に分け、左に「Who」（誰が？）、右には「Do」（何をする？）を書き出していきます。例えば、「Who：サッカー好きな人」が「Do：代表戦の実況や感想を投稿する」などといった感じです。このワークでサービスのステークホルダーを想像することができます。

4. ペルソナ作成(40分)
サービスのステークホルダーになる人物の属性やユーザーストーリー、モチベーションなどを書き出していきます。最も重要なステークホルダーを詳細化するワークで、ユーザーに人間味が加わり、メンバーが共感を持てるようになります。

5. カスタマージャーニーマップ（90分）
以下の項目についてステークホルダーの目的やゴールに到達するまでのストーリーを書き出します。

・ステップ（アプリを知る,登録する etc...）
・チャネル OR タッチポイント（AppStore,SNSでの広告 etc...）
・行動（アプリが気になってAppStoreで検索する etc...）
・思考（人とつながらないSNSってどうな感じなのかな？etc...）

その後、ストーリーの中での心理状態や感情を満足を高い、不満を低いとし、折れ線グラフで繋いでいきます。グラフが下がっているところに対して、ニーズや改善案を検討します。
ユーザーがたどる手順を視覚的に表現でき、プロダクトを使っている時だけでなく、プロダクトに触る前や後まで考慮できます。

6. チャレンジステイトメント（25分）
これまでのワークで顕在化した課題の中から今回解決すべき課題を議論します。課題に関してチームの合意が得られたら、チャレンジステイトメントとして以下のフォーマットにまとめます。

＿＿＿＿＿＿[なぜ]＿＿＿＿＿＿という理由で
＿＿＿[誰か]＿＿＿＿の体験を改善するために
＿＿＿＿＿[何か]＿＿＿＿＿＿を検討する

解決すべき課題を定義することで、以降デザインスプリントで常にその課題を頭においておけるようにします。

DAY1：Diverge （発散）

1. 8アップ（クレイジー8）（30分）
それぞれ紙を1枚ずつ取り8つ折りにします。この1つのマス目に1アイデアを描きます。その際、アイデアは文字ではなく絵で書くよう意識します。５分のタイマーをセットし、時間内に8つのアイデアを出してマスを埋めましよう。（40秒に1アイデアペースですね😇）5分以内に8アイデアって結構辛いんですが、この時間制限があるのことで、参加者はいろんなアイデアを絞り出すので面白いです。また、それぞれのアイデアをみて思いつくことも多いので、私たちのチームではこれを2セットやってます。とにかく質より量、アイデアを発散させます。

2. ストーリーボード（30分）
クレイジー8で出たアイデアから最もよいと思うアイデアを1つ選び、そのアイデアを詳細化していきます。紙の左側に付箋を3枚縦に並べて貼り、そこにはそのアイデアのシナリオを絵で表現します。右側にはそのコマで起こっていることを文章で書きます。プロダクトを利用する様子を視覚的に示すことによって、より現実的なシナリオが生まれます。

3. サイレント評価（10分）
全員のストーリーボードを壁に貼ります。参加者に小さいシールを1人3枚ずつ配り、それぞれ良いと思ったアイデアにそのシールを貼っていきます。その際、相談やアイデアの説明などはしません。貼られたシールの数を通じて、優れたアイデアが一目でわかるようになります。

4. グループでの投票（10分）
サイレント評価で票が入ったものに関して、気に入った理由を各参加者に発表してもらいます。その際、ストーリーボードの作成者が追加で説明したいことがあれば補足説明することができます。発表されたアイデアについてより深い議論をしていきます。

1日の振り返り：レトロスペクティブ
毎回その日の最後にレトロスペクティブという簡易的な振り返りを実施します。ホワイトボードに2列の表を描き、それぞれに+（プラス/うまくいったこと)とΔ（デルタ/変化を表すギリシャ文字）を記入する。1日の中で良かったことを+に、変えたいと思ったことをΔに書きます。Δに挙がった項目は改善案をその場で検討し、翌日のワークに活かします。

DAY2：Decide（決定）

1. １万円テストとリスクの発見（15分）
昨日のクレイジー8やストーリーボードのアイデアの中から、自分が重要だと思うアイデアに細い付箋に貼り、そこに投資する金額を書いていきます。投資の合計額は1万円までです。また、リスクがあると思うアイデアには赤い付箋を貼り、そこにリスクの詳細を記述します。
発散フェーズで出たアイデアを全員ですべて検討するのは多すぎるので、個別ですべてを検討、理解していきます。

2. 代替案の特定（40分）※有力な解決案が複数ある場合
クレイジー８やストーリーボードのアイデアを、ユーザージャーニーマップ上に貼っていきます。貼る際は、ユーザージャーニーマップでそのアイデアが解決しようとしている課題の箇所に貼っていきます。同じ課題を解決するアイデアが複数ある場合は、それぞれのメリットを議論しアイデアを収束させていきます。

3. 仮設のリストの検証ボード（50分）
「課題の定義」の際に出た課題や、絞られたアイデアから考えられる仮説を書き出していきます。仮説を貼り出し、それぞれの仮説の右側に「評価の手段」と「評価成功の条件」を書いていきます。優先度の高い仮説を決め、それを検証するためのユーザーストーリーを選びます。

4. 各自でスケッチ作成（50分）
これまでのワーク中で絞られたユーザーストーリーに沿って、検証が必要な箇所のワイヤーフレームをスケッチしていきます。書き終わったらそれぞれのスケッチを共有し、良いものを議論して決めます。それぞれ良いところを合わせて一つのアイデアにしてもOKです。

5. チームでスケッチ作成（60分）
1人が描く役となり、相談しながら一つのアイデアにまとめていきます。時間内に書き終われるよう、重要な画面から簡潔に描いていきます。

1日の振り返り：レトロスペクティブ
1日目にも実施した振り返りを2日目にも実施します。2日目の最後は2日間通しての振り返りを挙げていきましょう。

これでチーム全員で集まってのデザインスプリントは終了です

DAY +α：Prototype（プロトタイプ）

この後、Decideで決まったプロダクトのプロトタイプをデザイナーやエンジニアが作成します。ここでプロトタイプのクオリティはテストする対象や検証したい仮説の評価の手段に応じて変わってきます。

例えばテストする対象が社内の他チームの人とかであれば手書きの画面モックでも検証が可能かもしれません。しかし、ITリテラシの低い主婦や大学生などが手書きの画面からサービスを想像できるかというと難しい気がします。ラフでもデザインを作成し、見た目上実際のアプリに近いプロトタイプをProttなどで作成する必要があるでしょう。重要なのは検証する対象がサービスを想像できるプロトタイプかどうかです。ただ、短期間で検証するのが目的なので必要以上にクオリティに時間をかけるのはやめましょう。

合わせて、検証したい仮説が検証できるプロトタイプかどうかも重要です。本番に近い形で動くアプリを実装する必要があるのか？、Prottで作成した画面遷移がわかるものがあればいいのか？、またはインタビューで解決できるのか？優先度の高い仮説を検証するための必要なプロトタイプを作成することが大切です。

優先度の高い仮説についてはDecideの「3.仮設のリストの検証ボード」のワークで優先度付けしているので、そ仮説の検証方法を元にプロトタイプを作成しましょう。

DAY +α：Test（テスト）

ではプロトタイプを使ってテストを実施していきます。デザイナーとエンジニアがプロトタイプを作成している間に、プロダクトオーナーやディレクターが被験者のリクルーティング、質問項目などを検討を行います。

被験者としてサービスのユーザーを5〜7人用意しましょう。まだリリースしてない場合はコアターゲットにしたいユーザー属性の人をリクルーティングしましょう。ただ被験者は大勢用意する必要はありません。デザインスプリントのテストは1日で終わらせるワークなので、1日で行えて意味のある結果を得られる限界は5〜7人だと言われています。大体は5人ぐらいで傾向が見えてくると思います。

またテストには一部の人だけでなく、デザインスプリントに参加したメンバー全員が参加するようにしましょう。議事録として共有すると記録者の個人的な捉え方が反映されてしまったり、それぞれの発言の温度感も伝わりにくいです。被験者の声や表情を各メンバーが自分の耳と目で見ることで、テストの分析の際に全員が納得感を持って判断することができます。とはいえ会議室に全員が立ち会うと被験者も萎縮してしまうので、人数が多い場合はモニタリングルームを別で用意しインタビューの様子を配信すると良いでしょう。

ではテストが終わったら、結果を分析していきましょう📝

⭕️期待通りに機能した場合
デザインスプリントが完全に上手くいって、全ての仮説が正しいことが立証されることは稀です。もしそうなら、「仮説は十分に検討したか？」「課題について十分に深く調査したか」をチーム内で確認しましょう。結果、疑問点が残っていない場合はめったにない大成功ということです。検証したプロトタイプを元に本格的に開発を進めましょう。

❌期待通りには機能しなかった場合
提案した解決策の一部や全部が見当違いであったということもよくあります。この場合は改善の作業を繰り返します。これは悪いことではないのです。改善は成功に繋がります。また、早めに失敗したほうが低コストだとされています。早めに気づくことができて良かったと考えましょう。

❓疑問点が残っている場合
上手くいったことと、そうでないこと、それらが混在していて疑問が残る。このパターンがもっとも多いケースです。その場合は、どれがどのような理由で成功・あるいは失敗したのかを理解する必要があります。それぞれの要因を明らかにし、ネクストアクションについて検討しましょう。課題はあっているから発散フェーズからやり直す場合や、ワイヤーフレームからやり直すなど色々なパターンがあるかと思います。

🎉🎉これにてデザインスプリント終了🎉🎉

デザインスプリントを習慣化しよう

どうでしょうか？なんかできそうじゃない？って思ってもらえましたでしょうか？私たちのチームではテストまでを1週間半〜2週間ぐらいで終わらせています。2日間は全員でのワークですが、+αの時間は分担しているため全員が全期間フルコミットって訳ではありません。各々のメンバーが通常の業務と並行して行なっています。

もちろん5日間で集中して終わらせることができるならその方が良いです。しかし、他にも業務がある場合はなかなか難しいかと思います。そのような状況のチームでもこのスタイルだったら導入しやすいのではないでしょうか？

そして大切なのはこのデザインスプリントを習慣化していくことです。習慣化することで、サービスデザインにユーザー視点を盛り込むことができますし、チームの意識のベクトルをその度に同じ方向に揃えることができます。結果、意思決定が早くなり、開発スピードが上がります👆👆

習慣化の第一歩として、ぜひ一度チームに取り入れてみてはいかがでしょうか？

今回も長文を読んでいただきありがとうございました🙇