Design Sprint ガイドブック v2

1. Design Sprint ガイドブック: Step-by-Step for Sprint Masters (2015 March Update) デザインスプリントのプロセス詳細について Takaaki Umada April 11, 2015 (v 2.0) Big Thanks to Google Ventures 1

2. 2 Design Sprint とはデザイン上の問題を解決するための短期間でのスプリント (短距離走)

3. デザインスプリントを実施して効果を上げたスタートアップの例 And Others…. • Gmail, Google X, From Google Ventures 3 Case Study: Design Sprint Blue Bottle Coffee Pocket CustomMade Sales growth & Time on site X2 1 sprint+ New users saved the first item more +58% 3 sprints (3 weeks) Customer engagement +300% 3 sprints (3 weeks)

4. 4 Design Sprint の最近のアップデート Google Ventures Official Book (洋書、発売未定) Design Sprint Methods (SXSW 2015 by Google & Google [x]) Design Sprint (洋書、8 月発売予定)

5. SXSW Interactive 2015 Design Sprints at Google: UX Methods and Mindset で発表された内容を中心にアップデート。 • Day 0 のアクティビティを追加 • Day 1 のアクティビティの詳細化と追加 • Day 2 のプロセスに一部を追加何十回か実施してきた中で感じた幾つかの知見も含みます。 5 2015 March Update

6. Design Sprint とは 6

7. デザインスプリントとは迅速に学習とプロトタイピングを行うためのメソッド Design Sprint とは • Design Sprint もしくは Product Design Sprint と呼ばれる、デザイン上の問題（新規顧客の離脱率を下げる、新製品を考える等）を解決するための短期間でのスプリント • Design Thinking や IDEO のメソッド、アジャイルや Gamestorming の方法論などを Google Ventures の Design Studio が特にスタートアップ向けにカスタマイズして提供したもの • Google Ventures や Google X で採用されているほか、すでに 200 以上のスタートアップやプロジェクトで利用された実績がある 7 Method for Rapid Learning & Prototyping

8. http://www.gv.com/lib/the-gv-research-sprint-a-4-day-process-for-answering-important-startup-questions 8 従来のパターン

9. http://www.gv.com/lib/the-gv-research-sprint-a-4-day-process-for-answering-important-startup-questions 9 ×

10. 10http://www.gv.com/lib/the-gv-research-sprint-a-4-day-process-for-answering-important-startup-questions

11. デザインスプリントの目指すところ 11 Design Sprint http://www.gv.com/lib/the-gv-research-sprint-a-4-day-process-for-answering-important-startup-questions

12. デザインスプリントの目指すところ 12 Design Sprint http://www.gv.com/lib/the-gv-research-sprint-a-4-day-process-for-answering-important-startup-questions Day 1-3 Day 4 Day 5

13. http://www.fastcodesign.com/1672887/how-to-conduct-your-own-google-design-sprint 13

14. 14 LearnDesign Sprint は迅速な学習にフォーカスする

15. コアコンセプト • 制限を設ける。特に時間を制限して、短いスプリントを何度も回す。 • 問題と解決策をピンポイントにするためにプロセスを分ける • User Experience をストーリーボードで表す • リアルに近いプロトタイプを作り、インタビューを通して学習する 15 Design Sprint Core Concepts

16. タイムライン 16 Timeline 1Day Understand (理解する) チームの意見を聞いたり、リサーチや競合製品を通して解決したい問題を深掘りする (2 ∼ 5 時間) 2Day Diverge (発散する) できるだけ多くの解決策をラピッドに作る (2 時間 ∼ 1 日) 3Day Decide (決める) もっともすぐれたアイデアを選び、全員でユーザーストーリーに同意する (2 ∼ 5 時間) 4Day Prototype (プロトする) ユーザーに実際に見せれるものを素早く（汚く）全員で作り上げる (4 ∼ 8 時間) 5Day Validate (検証する) ビルの外に出て、プロトタイプを実際のユーザーに見せ、何が良くて何が悪いのかを素早く学ぶ (4 ∼ 6 時間) 0Day Prepare (準備する) 必要な人とモノを集める (所要時間は数時間)

17. Prepare Day 0 17

18. キーとなるチャレンジを決める Design Sprint を通して解決したい「キーとなるチャレンジ」を考えて、Challenge Statement を作る準備をしておく。良い Challenge Statement の条件は以下の 3 つ。 1. 簡潔で、チームのゴールに強く関連付けられている 2. インスパイアされるもの 3. ターゲットとなる顧客あセグメントにフォーカスしているもの例）Chrome Kids Challenge の Challenge Statement 「2014 年の第 4 四半期にフォーカスした、4 ‒ 7 歳の子供向けの直感的な読書体験を提供するアプリをデザインする」 18 Key Challenge

19. スプリントに必要なチームメンバーを集めてくる必要なチームメンバーを構成する。プロダクトマネージャーなど、決定権者も構成メンバーに必ず入れること。理想的には 5 ‒ 8 人。大きなチームになった場合は小さなチームに分けて、同じチャレンジか異なったチームに分ける。例）デザイナー x 2 エンジニア x 1 サポート担当者 x 1 プロトタイパー x 1 スプリントマスター x 1 リサーチャー x 1 19 Sprint Team

20. 既存のデザインに関する経緯を把握する既存プロダクトの場合は特に、スプリントマスターが Design Audit (デザイン監査) をリードする。 Design Audit には以下のような活動が含まれる。効果的なスプリントのために必要な情報を集める。 1. キーとなる stakeholder やプロジェクトをリードする人にインタビューをする 2. 既存のすべてのドキュメントをレビューする 3. 関係するユーザーリサーチをレビューする 4. 現在のデザインをレビューする 5. コアとなるユースケースを特定＆レビューする 20 Design Audit

21. 準備物 21 Resource Preparation • 5 ⽇日間使えるワークルーム（5 ⽇日間ずっと使える場所）また 5 ⽇日⽬目⽤用に • インタビュールーム • オブザーベーションルームを⽤用意する。インタビューに必要なものとしては、 • Skype (⾳音声を拾拾ったり、Web サイトの操作画⾯面をデスクトップ共有する) • カメラ (ユーザーのボディランゲージを⾒見見る) • Miracast や AirPlay (モバイルの場合、ユーザーの操作画⾯面を⾒見見る) など 4 〜～ 8 ⼈人程度度（上下しても構わない）の少なくとも下記の役割の⼈人を⼀一⼈人ずつ • デザイナー • CEO (決定者) • Product Manager • User Expert そのほか、エンジニア、マーケター、関係者など。また、 • ファシリテーター（できれば取り組む製品についてあまり知らない⼈人）を⽤用意する必須 • ⼤大量量のポストイット • 太めのペン • ホワイトボード（できるだけ多く） • ホワイトボードマーカー • 丸形の⼩小さなステッカー • PowerPoint or Keynote • 多めの A4 の紙 (A3 も便便利利) あると便便利利なもの • Time Timer • Bit Timer • セロテープ or 3M のコマンドタブ • PPT/Keynote ⽤用のプロトタイピングライブラリ (Keynotopia, etc) • プロトタイピングツール (Pop, Flinto, Briefs, etc) • Conference Microphone • スナック People Place Materials 5 ⽇日間の時間。スプリントの間、すべての⼈人がすべての時間に参加できるようにする Time 以下のものをそろえる。

22. まず最初にインタビューするユーザーをリクルートしてから始める次にやることはインタビューするユーザー 5 人を確保すること。今現時点で何の製品もなく、何が問題か明らかでなくても、とにかく 5 日目のユーザーインタビューのユーザーをリクルートして、インタビューの時間割を決める。何故 5 人かは Nielsen Norman Group のリサーチを参照のこと 22 Recruit, Recruit, Recruit Users ⽉月⽕火⽔水⽊木 10:00 〜～ 10:30 11:00 〜～ 11:30 12:00 〜～ 12:30 13:00 〜～ 13:30 14:00 〜～ 14:30

23. Day 0 用の tips • インタビューのユーザー集めは人づてになることが多いが（特に日本はユーザーインタビューに応じてくれる人が少ない）、工数を減らすために外部のサービスを使ったほうが楽だしスクリーニングできる。外部のサービスには以下のようなものがある。 • Craigslist • ゴチソー • 事前にみんなで意識を合わせておくべきことは以下 • 時間を守る。5 分と言われたら 5 分で必ず収める。例外は認められない。 • PC は 4 日目までほぼ使わない。必要がないときは閉じておく。メールもチェックしない。 • スケッチを恐れない • 「絵心がない」は禁句。Day 3 までは伝われば何を描いてもいい • スケッチであることを示すために、太めのペンを使うことを推奨 23 Tips for Day 0

24. Understand Day 1 24

25. Day 1 の成果物はユーザーストーリーダイアグラム http://www.gv.com/lib/the-product-design-sprint-understandday-1 25 Day 1 Outcome is User Story , looks Like:

26. Day 1 の目的ユーザーのニーズ、ビジネスニーズ、テクノロジのキャパシティを特定し、何がキーとなる戦略でどこにフォーカスするのかを決める。そのために： 1. 問題に対する全員の知識や見解を共有し、現状の理解を一致させる 2. 今回のスプリントの中でフォーカスするべき一つの問題を決める 26 Objectives of Day 1

27. Day 1 の主なプロセス Day 1 のプロセスはエクササイズによる問題に対する理解の一致と、問題の発見に充てられる。最終的にはユーザーストーリーと、その中で今回のスプリントで解決したい問題を決める。そのユーザーストーリーは最終日までの議論の土台となるので、腹落ちしていないところがあれば各自必ず言うこと 27 Day 1 Process 360 Lightning Talk (15 - 30 分) 競合調査 (10 - 30 分) 顧客インタビュー (30 - 240 分) Stakeholder Map (30 分) 学びや洞察の要約 (30 分) ユーザストーリー (30 分) デザイン原則決定 (30 分) 解決したい問題の決定 1 2 3 4 5 6 7 8

28. 360 ライトニングトーク 360 Lightning Talks はスプリントチーム全体で、様々な視点から課題を検討するために行われる。特にビジネス、ユーザー、テクノロジの 3 つの観点について検討することを忘れないようにする。少なくとも以下の議題については話すようにすること。 1. ビジネスゴールとサクセスメトリクス (5 分) 2. 技術的な可能性とチャレンジ (5 分) 3. 関係するユーザーリサーチ (5 分) サクセスメトリクスの設定については HEART Framework を参照。 28 1.1 360 Degree Lightning Talk 360 Lightning Talk (15 - 30 分) 競合調査 (10 - 30 分) 顧客インタビュー (30 - 240 分) Stakeholder Map (30 分) 学びや洞察の要約 (30 分) ユーザストーリー (30 分) デザイン原則決定 (30 分) 解決したい問題の決定 1 2 3 4 5 6 7 8

29. 29 HEART Framework & Goals-Signals-Metrics UX のゴールやメトリクスを設定するときには HEART Framework と Goals-Signals-Metrics プロセスが使いやすい (Google でも利用)。今回のスプリントの中で HEART の中でどれを改善したいのか選び、 Goal から Metrics を決める。以下のような表の一行が埋められる。 • Goals: そもそも達成したいこと (Youtube のビデオを見つけやすくする、等) • Signals: ゴールに対する少し低いレベルの数値 (Youtube のビデオ視聴時間、等) • Metrics: より詳細なレベル (A/B テストが行えるぐらい) の数値 (Youtube の一日のユーザーあたりのビデオ視聴時間の平均、等) Definition Goals Signals Metrics Happiness ユーザーの態度度（満⾜足度度、使いやすさ、NPS） Engagement ユーザーの関与（頻度度、関わりの深さ：PV, DAU） Adoption 製品や機能に対する新規ユーザー（過去⼀一週間の登録ユーザー、新機能利利⽤用） Retention 既存ユーザーの動向（次に帰ってくる時間、チャーンレート） Task Success タスクの成功率率率（タスク達成の時間、成功率率率） 360 Lightning Talk (15 - 30 分) 競合調査 (10 - 30 分) 顧客インタビュー (30 - 240 分) Stakeholder Map (30 分) 学びや洞察の要約 (30 分) ユーザストーリー (30 分) デザイン原則決定 (30 分) 解決したい問題の決定 1 2 3 4 5 6 7 8

30. 競合の調査チームをインスパイアして、やる気をキックスタートすることができそうなプロダクトやサービスを調査する。 3 ‒ 10 の似たようなプロジェクトを選び簡単なレビューをしてみること。競合だけでなく、例えば EC サイトのようなサービスを作っている場合は Google Play や App Store などの類似のサービスを探して、どのように商品をリスト化してみると良い。 30 1.2 Competitive Overview 360 Lightning Talk (15 - 30 分) 競合調査 (10 - 30 分) 顧客インタビュー (30 - 240 分) Stakeholder Map (30 分) 学びや洞察の要約 (30 分) ユーザストーリー (30 分) デザイン原則決定 (30 分) 解決したい問題の決定 1 2 3 4 5 6 7 8

31. 顧客インタビュー顧客こそプロダクトが良いか悪いかを判断する究極の審判である。そのため、スプリントをインタビューから始めるのはとても良いアイデアと言える。既存のプロダクトのインタビューではどうやってユーザーがプロダクトを使っているのか、そして好きなところや嫌いなところなどを聞く。新しいプロダクトの場合は、プロダクトが解決したい課題をユーザーが他のどんな方法で解決しているかを中心に聞く。 Lean Customer Development の手法などを参照すると良い。（筆者の下記ドキュメントも参照のこと） 31 1.3 User Interview 360 Lightning Talk (15 - 30 分) 競合調査 (10 - 30 分) 顧客インタビュー (30 - 240 分) Stakeholder Map (30 分) 学びや洞察の要約 (30 分) ユーザストーリー (30 分) デザイン原則決定 (30 分) 解決したい問題の決定 1 2 3 4 5 6 7 8

32. 顧客インタビュー - フィールドビジット必要があればインタビューに加えてフィールドビジットも検討する。顧客にインタビューするよりも、顧客のもとに出向いて顧客がプロダクトを使うコンテキストを見てみることがより効果的なケースもある。たとえばテクニカルサポートを行うチームのためのプロダクトを作っている場合、彼らがサポートをしている現場に赴き、何をしているのかを観察するのかを見てみると良い洞察が得られやすい。フィールドビジットはインタビューの効果があるだけではなく、チームがコンテキストを理解するのに役立つ。 32 1.3 User Interview: Field Visit 360 Lightning Talk (15 - 30 分) 競合調査 (10 - 30 分) 顧客インタビュー (30 - 240 分) Stakeholder Map (30 分) 学びや洞察の要約 (30 分) ユーザストーリー (30 分) デザイン原則決定 (30 分) 解決したい問題の決定 1 2 3 4 5 6 7 8

33. 関係者マッププロダクトやサービスは複数のタイプの顧客に対して設計されていることがある。Stakeholder map では関係しそうな人をリスト化し、どの stakeholder に注目するかを決める。順序は以下の通り。 1. プロダクトに関係する stakeholder をリスト化する (10 分) 2. 関係者を意味のあるセクションにグループ化する (2 分) 3. スプリント中にフォーカスしてデザインする stakeholder を決める。またその順序も決める。 4. それぞれのセクションのグループに分けてチームを作るかどうかを検討するたとえば医療系サービスでは、「医療関係者 (医者、ナース、ER)」「サポートグループ (オンライン、対面)」「患者 (患者本人、子供、親、友達)」など、3 つのグループと複数の関係者が考えられる。 33 1.4 Stakeholder Map 360 Lightning Talk (15 - 30 分) 競合調査 (10 - 30 分) 顧客インタビュー (30 - 240 分) Stakeholder Map (30 分) 学びや洞察の要約 (30 分) ユーザストーリー (30 分) デザイン原則決定 (30 分) 解決したい問題の決定 1 2 3 4 5 6 7 8

34. 関係者マップ理解を深めるために、最初のアイデアや洞察をまとめる。ポストイットを使いアイデアを描き、張り出して見てグループ化する。良いアイデアについては Silent Critique (後述) で投票し、どの洞察をより深堀りするのかを決める。これは「最初のチェック」であり、方向性の最終決定ではないことに注意すること。また How might we (どうやったらできるか) ということを中心に考えてみると良い。 34 1.5 Summary of Learnings and First Ideas 360 Lightning Talk (15 - 30 分) 競合調査 (10 - 30 分) 顧客インタビュー (30 - 240 分) Stakeholder Map (30 分) 学びや洞察の要約 (30 分) ユーザストーリー (30 分) デザイン原則決定 (30 分) 解決したい問題の決定 1 2 3 4 5 6 7 8

35. ユーザーストーリー 35 1.6 User Story 360 Lightning Talk (15 - 30 分) 競合調査 (10 - 30 分) 顧客インタビュー (30 - 240 分) Stakeholder Map (30 分) 学びや洞察の要約 (30 分) ユーザストーリー (30 分) デザイン原則決定 (30 分) 解決したい問題の決定 1 2 3 4 5 6 7 8 共通理解の上で、協調しながらユーザーストーリーのマップを描く。必要があれば「最初の利用者」「再来者」「エキスパート」など場合分けをしてみる。その際には重要なユーザーストーリーに絞ること。何が重要かは、今回のスプリントで解決したい問題による。たとえば、 • 顧客の製品の理解を助けたい → 顧客が製品を初めて見た時の体験を改善する • 新しい製品のコンセプトを作りたい → Value Prop とコアとなる機能を決める • Landing Page のコンバージョンを上げたい → なぜ顧客が LP にたどり着くのか、彼らのゴールは何かを理解したい

36. デザイン原則の定義 3 つの単語でプロダクトを記述できないか考えてみる。たとえば「簡単さ」「楽しさ」や「完璧さ」「パワフルさ」なのか。 1. 個々人でチームが気にするべきデザイン原則をリスト化する 2. ベストなアイデアをチームで検討して選ぶ最終的に顧客を通して検証するときに、この 3 つの原則が伝わっているかどうかを顧客に聞いてみると良い。 36 1.7 Defining Design Principles 360 Lightning Talk (15 - 30 分) 競合調査 (10 - 30 分) 顧客インタビュー (30 - 240 分) Stakeholder Map (30 分) 学びや洞察の要約 (30 分) ユーザストーリー (30 分) デザイン原則決定 (30 分) 解決したい問題の決定 1 2 3 4 5 6 7 8

37. 解決したい問題の決定すべてのアイデアについてプロトタイプを作ることはできないので、このスプリントでどの問題/アイデアにフォーカスするかを決める。決めるうえで重要なのは、 • プロトタイプを見せたときに、ユーザーから何を学びたいのか？ • 学ぶためにどんなプロトタイプを作るべきなのか？ • 問いかけるのをためらうぐらい「明確な質問」をしてみる：みんなの理解が進むをしっかりと考える。ファシリテーターは時間制限を付けて問題を決めるようにする。 37 1.8 Focus on the Problem 360 Lightning Talk (15 - 30 分) 競合調査 (10 - 30 分) 顧客インタビュー (30 - 240 分) Stakeholder Map (30 分) 学びや洞察の要約 (30 分) ユーザストーリー (30 分) デザイン原則決定 (30 分) 解決したい問題の決定 1 2 3 4 5 6 7 8

38. Day 1 用の tips • 問題に対する共通の理解をすることが大事 • 時間がないことをみんなに理解してもらう：インタビューまですでに残り 4 日 38 Tips for Day 1

39. Diverge Day 2 39

40. Day 2 の成果物はストーリーボードとそれに対する投票（決定） Crazy 8s や、それを基にしたストーリーボードの作成、そして最終的な投票結果が Day 2 の成果物となる。 http://www.gv.com/lib/the-product-design-sprint-divergeday2 40 Day 2 Outcome: Voted Storyboards

41. Day 2 の目的 1. Day 1 で決めた問題を解決するための多くの可能性を明るみに出す 2. 短い期間で可能性を出すために、時間に明確な制限を設けて進めていく 41 Objectives of Day 2: Diverge

42. Day 2 のプロセス Day 2 のプロセスで重要なのは • 各自が個別に静かに自分のアイデアを書き出す (No Brainstorming!!) • 実は古いアイデア（以前思いついていたアイデア）が有効だったりする……古いアイデアから書き出そう！（新しく思いついたアイデアには往々にして過大評価の傾向にある） • 紙を使おう。早く書こう。High fidelity なモックアップは不要。神を使えばみんなで貢献できるし、特定のアイデアに固執することもなくなる。できれば太いペンを使おう。気を付けておきたいのは、 • Storyboard (Step 5) を書き出すまでは誰とも何もシェアしないそれまで気にせず書こう！ 42 Day 2 Process 問題を分けて選ぶマインドマップ (10 - 15 分) Crazy 8s (7 分) 1 Big Idea & Storyboard (20 分) Silent Critique (5 - 10 分) 3 min Critique (3 分/idea) Super Vote (5 分) デザイン批評 (必要があれば) 1 2 3 4 5 6 7 8

43. ユーザーストーリーをチャンクに分けられる場合は分けるユーザーストーリーダイアグラムが2つ以上のチャンクに分かれる場合（多くの場合はそうなる）は、問題を分けてから取り組む。 2つ以上のチャンクに分かれた場合、それぞれの問題について Step 2 以降のサイクルを回していく。ただしそれぞれの問題に別のチームをアサインするのは避けること。全体観がなくなる。チャンクが多すぎる場合は、今回のスプリントで行う問題をさらに小さく選ぶこと。 43 2.1 Choose Part of the Problem 問題を分けて選ぶマインドマップ (10 - 15 分) Crazy 8s (7 分) 1 Big Idea & Storyboard (20 分) Silent Critique (5 - 10 分) 3 min Critique (3 分/idea) Super Vote (5 分) デザイン批評 (必要があれば) 1 2 3 4 5 6 7 8

44. マインドマップ 44 2.2 Mind Map 問題を分けて選ぶマインドマップ (10 - 15 分) Crazy 8s (7 分) 1 Big Idea & Storyboard (20 分) Silent Critique (5 - 10 分) 3 min Critique (3 分/idea) Super Vote (5 分) デザイン批評 (必要があれば) 1 2 3 4 5 6 7 8 思いついたものをどんどん繋げていマインドマップを紙に書いていく。マインドマップは今後の UI スケッチの cheat sheet となる。自分しか見ないので、絵でも文字でもリストでもなんでもいい。 How might we (どうやったらできるか) を中心に意識して書くと良い。

45. 5 分で 8 つのデザインを描いていく 45 2.3 Crazy8s 問題を分けて選ぶマインドマップ (10 - 15 分) Crazy 8s (7 分) 1 Big Idea & Storyboard (20 分) Silent Critique (5 - 10 分) 3 min Critique (3 分/idea) Super Vote (5 分) デザイン批評 (必要があれば) 1 2 3 4 5 6 7 8 A4 (A3) の紙を 8 つのパネルができるように折り、それぞれのパネルに問題を解決できるようなデザインをなんでもいいので書いていく。 5 分ですべてを完成させる、つまり 1 パネル 40 秒で書こう！（実際は 30 秒で書いて 10 秒休むぐらい）詰まってしまった場合は、前のスケッチを少し変えてみたりして、深堀りしてみてもよい。また古いアイデアでも OK。 Crazy 8s は慣れないうちは 2 度行うとコツがつかめる。このとき Bit Timer を使うと便利。

46. 5 分で 8 つのデザインを描いていく 46 2.4 1 Big Idea & Storyboard 問題を分けて選ぶマインドマップ (10 - 15 分) Crazy 8s (7 分) 1 Big Idea & Storyboard (20 分) Silent Critique (5 - 10 分) 3 min Critique (3 分/idea) Super Vote (5 分) デザイン批評 (必要があれば) 1 2 3 4 5 6 7 8 Crazy8s で出たアイデアの中で、個々人で一つのアイデアを選び、 5 分かけてより詳細に描いてもらう。1 ページに収まらない複雑なアイデアのときは、キーとなるステップを中心にストーリーやフローで描いてもらうようにする。その際の注意点は以下の通り。 • 独立させる（口頭の説明がなくても意味が分かるように） • 匿名のままにする（自分の名前を書かない） • アイデアにタイトルを付ける（あとで議論しやすくするため）終わったら紙を壁に張り付けていく。美術館の絵画のように横一列に。

47. 喋らずに、良いと思ったアイデアにシールを貼っていく 47 2.5 Silent Critique 問題を分けて選ぶマインドマップ (10 - 15 分) Crazy 8s (7 分) 1 Big Idea & Storyboard (20 分) Silent Critique (5 - 10 分) 3 min Critique (3 分/idea) Super Vote (5 分) デザイン批評 (必要があれば) 1 2 3 4 5 6 7 8 全員が丸型のシールを持ち、壁に張り出されたアイデアのうち、良いと思ったものにシールを張っていく。シールを貼る数に制限はないし、自分のアイデアにシールを貼って行ってもいい。ただしこのとき誰もしゃべらないようにすること。この結果、アイデアに対するヒートマップが出来上がり、どのアイデアに人気が集まっているかが一目でわかる。

48. みんなが良いと思ったアイデアの発案者は 3 分間でそのアイデアの詳細を話す権利を得る全員でどのアイデアが好きだったかを議論し、人気のあるアイデアを書いた人に 3 分間以内で説明してもらう。（全員が全員のアイデアを話すのは時間がかかりすぎるので避ける）必要であれば、写真でアイデアを撮って、それを PC に取り込んでプロジェクターに映しながら検討するのもいい（ただし時間は 15 分+) 48 2.6 Three-minute Critique 問題を分けて選ぶマインドマップ (10 - 15 分) Crazy 8s (7 分) 1 Big Idea & Storyboard (20 分) Silent Critique (5 - 10 分) 3 min Critique (3 分/idea) Super Vote (5 分) デザイン批評 (必要があれば) 1 2 3 4 5 6 7 8

49. 決定権者を中心に、ベストなデザインを決定する全員が special なシール（シールにマークを書いたりしたもの）を 1 or 2 つ持ち、ベストだと思うアイデアに super vote する。もし CEO がすべての決定権を持つような文化のチームであれば、 CEO に 3 つのシールを渡してもいいし、CXO なら CXO に渡す。そこは正直に、make the call できる人に extra vote の権利を作ろう。エリート主義的ではあるが、コンセンサスはデザインを殺すし、決定権者が納得していない案を進めるとあとで後悔する。 49 2.7 Super Vote 問題を分けて選ぶマインドマップ (10 - 15 分) Crazy 8s (7 分) 1 Big Idea & Storyboard (20 分) Silent Critique (5 - 10 分) 3 min Critique (3 分/idea) Super Vote (5 分) デザイン批評 (必要があれば) 1 2 3 4 5 6 7 8

50. デザイン批評決定権者が納得できない場合は Design Critique を行う。ただし必ず時間を短時間にして行うこと！ Google Ventures の提案するデザイン批評の注意点は以下の通り。 http://www.gv.com/lib/critique 50 2.8 Design Critique 問題を分けて選ぶマインドマップ (10 - 15 分) Crazy 8s (7 分) 1 Big Idea & Storyboard (20 分) Silent Critique (5 - 10 分) 3 min Critique (3 分/idea) Super Vote (5 分) デザイン批評 (必要があれば) 1 2 3 4 5 6 7 8 批評ガイドライン • 率直であること • 詳細であること • ゴールとすべて関連づけること • うまくいっているところを認めること • 課題が先で、ソリューションは後 • 命令ではなく示唆であること • 楽しもうステージの設定 • ビジネスのゴールを確認する • 顧客のゴールを確認する • 制限を確認する • スケジュールを確認する • 同意できるかのチェック • 忠実度の期待値の設定 • フィードバックの方向付け体験をシミュレートする • タスクを選ぶ • コンテキストを確認する • 紙ではなくスクリーンで • ラフなプロトタイプ • 熱くピッチしない • フィードバックを黙って紙に書き出す

51. 次のチャンクに進むサイクルが終わったら、次にフォーカスすべきチャンクについて議論し、チャンクを決める。そして次のチャンクで同じサイクルを回す。 2 回目以降のサイクルはもっと簡単なので安心しよう！でも大体 1 日 2, 3 回すると疲れ切るので注意。 51 2.x Next Chunk 問題を分けて選ぶマインドマップ (10 - 15 分) Crazy 8s (7 分) 1 Big Idea & Storyboard (20 分) Silent Critique (5 - 10 分) 3 min Critique (3 分/idea) Super Vote (5 分) デザイン批評 (必要があれば) 1 2 3 4 5 6 7 8

52. Decide Day 3 52

53. Day 3 Outcomes: Whiteboard User Story http://www.gv.com/lib/the-product-design-sprint-decideday3 53

54. http://www.gv.com/lib/the-product-design-sprint-decideday3 54 Battle Royale

55. Day 3 の目的 1. どの解決策のプロトタイプを作るのか、Best Shot もしくは Battle Royale するかを決める Point • 意思決定はつらいものだけれど、すべてのアイデアをプロトタイピングしたりテストできないので絞る必要がある • スプリント中は、通常の会社の意思決定の仕組みよりもより民主的になる傾向があるが、これは実際にプロダクトなので、会社の意思決定の仕組みを採用する。たとえば CEO がやるといったらやる！という会社ならこのスプリントでもそうするし、ファシリテーターはそのように促さなければならない（衆愚の罠にかからないように） • ファシリテーターは Make the call (最終決定してくれ) と決定権者に言い続ける 55 Objectives of Day 3

56. Day 3 のプロセス Day 3 では主に「どのプロトタイプを作って最終日に検証するか」を決める。議論していると、議論の最中に新たにスケッチや探索が必要な場合がある。そのときは怖れずに Day 1 や Day 2 のプロセスに戻ること。最初にするのはコンフリクトを探す。コンフリクトを探すために、前日のストーリーボードをじっくりと読み込むところから始める。準備が整ったら次に進もう。 56 Day 3 Process 意見のコンフリクトを探す best shot か battle royale かを決める前提とテストの方法を決める詳細なユーザーストーリーを描く 1 2 3 4

57. 皆の意見が分かれている場所、コンフリクトを探す同じ問題に対する複数のアプローチが出ている場合、それを Conflict と呼ぶ。この Conflict が製品のための金脈となる。 Conflict はそれぞれポストイットに書き出すこと。たとえば、 Landing Page のユーザーダイアグラムに、「ビデオ」「一枚ぺら」「一枚の製品画像」という3案が出ている場合 Conflict が発生している。すべての Conflict をポストイットに書き出して、カテゴリに分けて壁に貼っていく。 57 3.1 Search for Conflicts 意見のコンフリクトを探す best shot か battle royale かを決める前提とテストの方法を決める詳細なユーザーストーリーを描く 1 2 3 4 通常デザイナーはアプローチを一つ選び、詳細なプロトにして持っていくが、このようにすることで決定すべきポイントがマップされ、さまざまな可能性が検討されるようになる。

58. コンフリクトを解消する (best shot を選ぶ) か、もしくはコンフリクトを並立させて battle roylae を行うコンフリクトに対して二つの対処法がある。「Best Shot」か「Battle Royale」である。Best な一つのプロトタイプだけを作るか、複数のプロトタイプを作るか、である。 Best shot はプロトタイプをより早く作れるし、ユーザースタディも簡単になるし、ユーザーの競合に対する反応なども聞く時間ができる。 Battle royale は新しい領域に対するアプローチの時に有効で、どの方法がユーザーにとって最適なのかが分かる。ただし時間はかかるし、ユーザースタディの効率も悪くなる。なお面白いことに、 Battle royale はダークホース的なデザインがユーザースタディでは最もウケが良かったりする驚きを提供してくれる。もちろんこれらのハイブリッドでも問題がない。たとえば best shot でプロトを作ってみたものの、ユーザースタディでうまくいかなければ battle royale を行う、など。最終的には gut check を行って best shot か battle かを決める。納得していない人が多ければ battle すべき。 58 3.2 Best Shot or Battle Royale? 意見のコンフリクトを探す best shot か battle royale かを決める前提とテストの方法を決める詳細なユーザーストーリーを描く 1 2 3 4

59. 検証するべき前提 (assumption) と、それに対応するテストの方法を決めるユーザースタディでテストしたいことを決めるには、前提や想定 (assumption) を明らかにすることが有効。テストに対する前提にはたとえば、ユーザーの前提（e.g. 写真をアップロードしたいユーザーがいる）、ビジネスの前提（e.g. 市場規模）、技術の前提、メッセージングの前提などがある。これらの前提を確認するためにプロトタイプを使ってテストする。たとえば、ユーザーが製品を使って写真を快くシェアするかどうか、といったようなものをプロトタイプを使ってもらってテストする。 59 3.3 Test Your Assumptions 意見のコンフリクトを探す best shot か battle royale かを決める前提とテストの方法を決める詳細なユーザーストーリーを描く 1 2 3 4 技術の前提はエンジニアに試してもらえばいいが、そのほかの前提すべてをテストできそうにない場合は重要度の低いものは次に回す。どのコンフリクトを探求すべきか、どの前提のテストをするかを決めれば、次はついにプロトタイピングの時間。

60. 詳細なユーザーストーリーをホワイトボードに描き、プロトタイピングのベースとするプロトタイピングする前に詳細なストーリーボードをホワイトボードに書いていく。ユーザーが実際に体験するものになるので、click by click で画面を分ける。これがプロトタイプの spec になる。なおこのストーリーボードはスプリント最後のグループワークである。ホワイトボードに大きなグリッドを描き、それぞれの大きさは A4 の紙 2 つ分ぐらい。それぞれのセルには一つのアクションを置く。クリックやテキスト入力、ピンチなどなど。セルの画面の詳細は気にしなくていいが、すべてのアクションがストーリーに入っていることが重要。 60 3.4 Whiteboard the User Story 意見のコンフリクトを探す best shot か battle royale かを決める前提とテストの方法を決める詳細なユーザーストーリーを描く 1 2 3 4 書いている途中に、ユーザースタディのことを考えながら書くといい。どうやって製品にたどり着くのか？等ファシリテーターは⼀一⼈人が全部を書かないように気を付ける。グループ全体が参与するように気を付ける。

61. Day 3 の tips • 常に戦う準備をしておくこと (Keep the gloves off) • ストーリーボードを描くには、たくさんの小さな決定をしなければならない。そのときに集団の同意を取るのではなく、CEO に make the call してもらう。 • どうしても決められないときは battle royale にする • ただし Battle royale を「決めることから逃げる」ことに使わない • チームが新しかったり、意見にバイアスがかかっている傾向にあれば「Thinking Hats」のメソッドを使い、無理やり視点を変えさせてみるのも良い。 • アイデア発想者 • 楽観主義者 • 悲観主義者 • 技術的な実現可能性チェッカー • ユーザーアドボケイト • など 61 Tips for Day 3

62. Prototype Day 4 62

63. Day 4 の成果物は「ユーザーに見せることができて」「最大限の学習効果が得られる」プロトタイプユーザーに触ってフィードバックをもらえるプロトタイプが Day 4 の成果物となる 63 Day 4 Outcomes: Prototype

64. Day 4 の目的 1. Day 3 のストーリーボードを基に、ユーザースタディのための High Fidelity なプロトタイプを作る Point • Crazy Deadline はすぐそこ：明日にはユーザースタディが始まる • プロトタイプは Day 5 の Validate を通した「学習」のためにあることを忘れないこと（デザイン上の傑作はいらない） • 学習を行うに十分なプロトタイプ作成のポイント • 見た目が最低限リアルであること (Keynotopia などを使う) • リアルなテキストを書くこと（lorem ipsum ではないテキスト） • データの品質や Email のパーソナルコンテンツに関係する場合はコードを書く • でも十中八九 PowerPoint や Keynote で事足りる • プロトタイピングサービスをうまく使おう 64 Objectives of Day 4

65. パワポと Keynote をプロトタイプに使いましょう PowerPoint や Keynote がメインのプロトタイピングツールとなる。これらなら: • デザイナーでなくてもデザインできる • アニメーションも簡単 • PDF にしてしまえばモバイルでも開ける • ユーザースタディのフィードバックも反映しやすい。現実の製品に近づけるには、Keynotopia などの素材をうまく使う。コードを書き出すと時間がかかるので、コードは極力書かないようにする 65 PowerPoint / Keynote: Prototyping Tool

66. Day 4 のプロセスプロトタイピングの時間は少ないので、Time Timer で管理していく。完璧なものを作るならデザイナー一人でやったほうがよいが、今回はユーザーテストに Good Enough なプロトを作るのが目的なので、 • 役割分担しながら全員で行う • 1 人もしくは少数のプロトタイパーが作るのどちらで進めるかを決める。プロトタイパーに任せる場合は、残りの人たちは Day 5 のインタビュースクリプト作成などを行うと良い。 66 Day 4 Process 作業分担を決める Asset Library を作る（必要あれば）各自作業を行う Lightning Critique を定期的に行う (5分) Outsider Review を行う (30 分) 細部をチェックする 1 2 3 4 5 6

67. 役割を分けて担当を明確にする極力多くの人が PowerPoint や Keynote を持っているのがベスト。それぞれ画面の担当を振り分けて、最終的なクリーンアップはデザイナーが行えばいい。担当振り分けの際、昨日のストーリーボードを見て、battle royale のところはチャンクを分けてアサインする。進みの速い人を大変なところにアサインしていくなどの工夫が必要。一人を「Stitcher」としてアサインすること。スライドを一つにまとめてフローにする。Battle royale の場合はそれぞれに stitcher を用意。そのほかメールチェックしている人がいたら指摘する人、時間管理する人（1時間に1回休憩を入れる人）などが必要（ファシリテーターが兼任する場合も）。 67 4.1 Divide and Conquer 作業分担を決める Asset Library を作る（必要あれば）各自作業を行う Lightning Critique を定期的に行う (5分) Outsider Review を行う (30 分) 細部をチェックする 1 2 3 4 5 6

68. ライブラリが必要なら作る共通のビルディングブロックが発生しそうなところは、アセットライブラリ化を検討する。テンプレートを作ったり、スクリーンショットや、ユーザーアバター、ロゴ、サンプルテキスト等々、必要だと思うものはライブラリ化する。ブラウザーバーなどもリアリズムのためには大事なので、持っていない場合は必ずつくること。 68 4.2 Build an Asset Library 作業分担を決める Asset Library を作る（必要あれば）各自作業を行う Lightning Critique を定期的に行う (5分) Outsider Review を行う (30 分) 細部をチェックする 1 2 3 4 5 6

69. 各自作業！各自担当した UI 作成の作業！ 1 時間に一度ぐらいは休憩を取りましょう。 69 4.3 Work 作業分担を決める Asset Library を作る（必要あれば）各自作業を行う Lightning Critique を定期的に行う (5分) Outsider Review を行う (30 分) 細部をチェックする 1 2 3 4 5 6

70. 簡単な批評を行う途中で簡単な critique を行うのが有効。一貫性を担保するためや、外からデザインを見てもらってフィードバックをもらう。しかし critique は時間を使う傾向にあるので、5 分に収めることを推奨する。他人のデザインを見て他のデザインを進めたくなる場合、それは次回のスプリントのためにとっておく。（Lightning critique は疑問を生むのに良い機会となるけれど、この画面は今作っている人が責任をもって作っているものと心得る） 70 4.4 Lightning Critique 作業分担を決める Asset Library を作る（必要あれば）各自作業を行う Lightning Critique を定期的に行う (5分) Outsider Review を行う (30 分) 細部をチェックする 1 2 3 4 5 6

71. 外の人を読んで簡単なレビューを行ってもらう 30 分、今日デザインに関わっていない人にユーザーリサーチャーとして来てもらう。もしくは PowerPoint などを持っていなかった人でもいい。外からの目は groupthink の罠から遠ざけてくれる。できれば一日の早い段階で見てもらうこと。遅かったらもう出来上がってしまっているので、できれば早いうちに見てもらう。 71 4.5 Review with an Outsider 作業分担を決める Asset Library を作る（必要あれば）各自作業を行う Lightning Critique を定期的に行う (5分) Outsider Review を行う (30 分) 細部をチェックする 1 2 3 4 5 6

72. 十分な製品に見えるように細部に気を付けるマウスポインタやテキスト、ユーザーがどこをクリックするか、とか、テキスト入力後の画面など、細かいところはできるだけ入力するようにする。そのほうがユーザースタディがよりリアルになる。そのほか細部で気を付ける点として、 • 一貫性やタイポには気を付けること。特にユーザーデータ（山田太郎とかになっていないか）。 • コンテンツは最新で関連のあるものにしておくこと。たとえばシアトルでテストするなら、新聞は Seattle Times にすべき。 • スタックしたときには「何を学ぼうとしているか」を思い出すこと。 30分をボタンのスタイルなどで失ってはいけない。ユーザーに何の Value Prop を理解してもらいたいかを考える。「細部」の具体的な例として Google Ventures で実際に作られた以下のプロトタイプが参考になる。 https://www.dropbox.com/sh/b5le4kch8m3eor8/aZ6qZcUBTk /Design%20Staff%20Prototypes 72 4.6 Crucial Details 作業分担を決める Asset Library を作る（必要あれば）各自作業を行う Lightning Critique を定期的に行う (5分) Outsider Review を行う (30 分) 細部をチェックする 1 2 3 4 5 6

73. Validate Day 5 73

74. 74 Day 5 Outcome: Scoreboard

75. 75 LearnDesign Sprint は迅速な学習にフォーカスする

76. Day 5 の目的 1. どのアイデアが受け入れられ、どのアイデアが受け入れられないのかを、ユーザーにプロトタイプを見せることによってテストを行い、テストを通して学ぶ Tips • インタビューはユーザビリティテストではない！「顧客が製品をどのように理解したか」「競合製品や代替品として何を使っているか」などを学習するためのテスト 76 Objectives of Day 5

77. インタビューを効果的に行うためのリソース集インタビューを行うコツを解説したリソースは多数あるので、外部リソースを参照のこと。「半構造化インタビュー」で検索すればある程度 Web でもやり方は書いてある。 • 本 • Interviewing Users: How to Uncover Compelling Insights • Running Lean • About Face 3 • ユーザビリティエンジニアリング • IDEO Human Centered Design Toolkit • Google Ventures • GV Guide to Research • Get Better Data from User Studies: 16 Interviewing Tips • How to Hack Your Body Language for Better Interviews • Startup Lab Workshop: User Research, Quick n Dirty (Video) 77 New to Interview?

78. Day 5 のプロセス始める前に何より、インタビューは学習するために行うということを意識すること。プロトタイプを改善していくための示唆を得る。インタビューする人と観察する人は分ける。ユーザーにとって不快にならないように、できれば大勢の観察者は異なる部屋で観察を行うこと。 78 Day 5 Process キークエスチョンをリスト化する観察ルームをセットアップする AV テストを行う役割分担を決めるインタビューを行う (BR 案すべて) 振り返りミーティングを毎回行う 1 2 3 4 5 6 次のスプリントの検討をする 7

79. キーとなる質問をリスト化して半構造化インタビューの準備を行う全員でキーとなる質問をリスト化して、半構造化インタビューに備える。そのための Tips として、 • Conflict と assumption についてもう一度確認すること。ユーザースタディでテスト可能な assumption であればリストに加える。 • Battle royale 状態のプロトタイプがあるかどうか。もしあるのであればインタビュワーはその違いをきちんと理解して正しい質問をすること • 本物の競合製品などを比較のために見せることを検討する • 今日のユーザーテストはユーザビリティテストではないことに気を付ける。ユーザーがきちんと製品を理解できているか、どんな競合製品や代替品を使っているかなどを見つけるためのテストである • 予想だにしなかったインサイトを見つけることフォーマットは独自のものでも良い 79 5.1 List Your Key Questions キークエスチョンをリスト化する観察ルームをセットアップする AV テストを行う役割分担を決めるインタビューを行う (BR 案すべて) 振り返りミーティングを毎回行う 1 2 3 4 5 6 次のスプリントの検討をする 7

80. 観察ルームをセットアップするインタビュールームと観察ルームをできれば分けて行う。そのために、観察ルームをセッティングする必要がある。観察ルームからはビデオでインタビューセッションの内容が見れたり、ノートをとれたりするような環境にすること。そのために、 • 部屋全体の雰囲気を撮影するための PC のカメラ + 音声を拾って Skype や Hangout での共有 • ユーザー操作用 PC での Skype を通した PC 操作画面の共有 • Miracast / Airplay でのユーザー操作モバイルの画面の共有などをセットする。 80 5.2 Set Up the Observation Room キークエスチョンをリスト化する観察ルームをセットアップする AV テストを行う役割分担を決めるインタビューを行う (BR 案すべて) 振り返りミーティングを毎回行う 1 2 3 4 5 6 次のスプリントの検討をする 7

81. AV テストを行う利用するツールの AV テストは必ず事前に行う。特に、 • 音質 • ビデオの位置 • 画面共有の状況については必ずチェックする。音質が悪ければ conferencing microphone などを用意する。また、観察ルーム側のマイクは mute にしておく。このテストはできるだけ毎セッションごとに行う。大体デモには悪魔が潜む。 81 5.3 Test the AV Ahead of Time キークエスチョンをリスト化する観察ルームをセットアップする AV テストを行う役割分担を決めるインタビューを行う (BR 案すべて) 振り返りミーティングを毎回行う 1 2 3 4 5 6 次のスプリントの検討をする 7

82. 役割分担を決めるインタビュワーと観察ルームの2つで大きく役割分担を行う。観察ルームの中でさらに役割分担を行う。 • 基本的に全員紙にノートを取る役目を負う。良いところも悪いところも予想外のことも、気づいたことはすべてノートにメモっておく（PC は閉じておくことが望ましい） • 一人のみ PC を開いて裁判報告官のようにすべての言葉をリアルタイムに筆記するようにする（疲れるので毎回変わると良い）。これはのちにリファレンスとして利用される。録音に逃げないように。 82 5.4 Roles キークエスチョンをリスト化する観察ルームをセットアップする AV テストを行う役割分担を決めるインタビューを行う (BR 案すべて) 振り返りミーティングを毎回行う 1 2 3 4 5 6 次のスプリントの検討をする 7

83. 効果的なインタビューを行うインタビューを行う。 83 5.5 Doing an Interview キークエスチョンをリスト化する観察ルームをセットアップする AV テストを行う役割分担を決めるインタビューを行う (BR 案すべて) 振り返りミーティングを毎回行う 1 2 3 4 5 6 次のスプリントの検討をする 7

84. 1セッションが終わるごとにスコアボードに全員で記入していくスコアボードを用意して、皆のノートをまとめていく。列ごとにインタビュイーの枠を設け、行は各インタビューパート（バックグラウンドや、プロトタイプ 1 / 2、etc）に充てるインタビューセッション一つが終わるごとに、スコアボードに全員の気づきを書いていく。そのとき、 • 緑色：良かった点 • 赤色：問題点、疑問点 • 黒色：その他としておくと分かりやすい。 84 5.6 Make a Scoreboard キークエスチョンをリスト化する観察ルームをセットアップする AV テストを行う役割分担を決めるインタビューを行う (BR 案すべて) 振り返りミーティングを毎回行う 1 2 3 4 5 6 次のスプリントの検討をする 7 書き終え次第、次のインタビュイーへのインタビューを⾏行行う。

85. インタビューの傾向インタビューを行うと、観察者側は大体こういうパターンをたどる傾向にある。 • 1つ目のセッション「俺たちは天才だ」「俺たちはバカだ」 • 人はそれぞれ違うので気にしないこと。次のセッションに行こう • 2 ∼ 4 つ目のセッション「これは複雑だ…」 • 5 ∼ 6 つ目のセッション「パターンが見えてきた！」 • パターンが見えてきたらノートをダブルチェックするとさらに有効。スコアボードに 2, 3 度出てきたことをチェックして、大きな印をつけておく「うまくいったこと」「解決すべき問題点」がインタビューを通して分かってきたら、次にやるべきことを CEO や決定権者がリスト化しておく。 85 Observing Humans

86. 次のスプリントの計画を立てるインタビューがすべて終了したら、スプリントを終わる前に次のスプリントについて検討する。その時、ケースによって次のスプリントを行うかどうかを決める。 A) ほとんどの物事がうまくいったケース修正すべき点を見つけて、プロトタイプを修正し、Day 3 (Decide) からやり直すと良い B) いくつかの大きな疑問が生まれたケース最も多いケースがこちら。いくつかは上手くいったが、いくつかは微調整が必要、いくつかはダメ、というケース。幸いなことにプロトタイプは修正しやすいので、次のスプリントに行く。次のスプリントは Day 2 (Diverge) からやり直すと良い C) 全部だめだったケースよくあるケース。ただ失敗ではない。何がダメだったか学べたのは前進であるし、実際にモノを何か月も使って作ってリリースしたときよりも短い時間で分かったのは良いことだと思おう。次のスプリントは Day 1 (Understand) から始めると良い。その時に今回の結果を Day 1 の Exercise のときに使おう。 86 5.7 How to Start the Next Sprint キークエスチョンをリスト化する観察ルームをセットアップする AV テストを行う役割分担を決めるインタビューを行う (BR 案すべて) 振り返りミーティングを毎回行う 1 2 3 4 5 6 次のスプリントの検討をする 7

87. Day 5 の tips • リサーチの前に • 必ず何を学びたいのかを明確にすること • ユーザーを dis らない • ユーザーが何かに困ったり手が止まったりしてもユーザーを非難しない。デザインをテストしているのであって、ユーザーが変な行動をとったのはデザインのせいであり改善ポイントと考える • インタビューのこつ（代表的なもの） • メモのときには Why に集中する • ユーザーが考えていることを口に出していってもらう (Think aloud) • ユーザーが言ったことだけではなく行動も観察する • チームのエンジニアに聞いて、技術的な実現性のチェックも怠らない 87 Tips for Day 5

88. See You Next Sprint!! 88