Service development lecture in Cookpad Online Summer Internship 2020

Cookpad Online Summer Internship 2020 サービス開発講義で用いた資料です。一部公開用に削っています。

Transcript

1. サービス開発講義 Cookpad Online Summer Internship 2020 1
2. 自己紹介 佐藤 敦也 (あつや) @n_atmark • 2019年新卒入社 エンジニア • 買物プロダクト開発部 モバイルアプリケーション開発グループ ΫοΫύουϚʔτͷ։ൃΛߦ͍ͬͯΔ෦ॺ 2
3. TA紹介 新井 康平 @SpicyCoffee66 (すぱこー) 谷口 浩司 @juschin_ (ジャスティン) 2020新卒　2018夏インターン出身 2017新卒　レシピ事業推進部部長 3
4. •クックパッドのサービス開発に対する考え方を知る •クックパッドのサービス開発プロセスを体験する •サービス開発の難しさや何が求められているのかを知る 講義の目的 4
5. 今日のスケジュール •第一部: 講義パート •10:00-14:30 (90min) •第二部: 実践パート •14:30-18:00(210min) 講義パートでは合間合間で休憩時間を取ります 長丁場ですが頑張りましょう 5
6. はじめに •いつでも・なんでも聞いてください •質問や感想はSlackに どんどん書いてください 6
7. [アイスブレイク] さっそく質問です！ • クックパッドマートで販売している 「まぐろ屋の天然本マグロ ネギトロセット【とろろ付】」 の販売価格はいくらでしょうか？ ①500円　　②700円　　③1,200円 7
8. [アイスブレイク] さっそく質問です！ • クックパッドマートで販売している 「まぐろ屋の天然本マグロ ネギトロセット【とろろ付】」 の販売価格はいくらでしょうか？ ①500円 8
9. サービス開発講義 講義編 9
10. 今日の講義では 10 •クックパッドの新規サービス「クックパッドマート」の 事例を用いて、実際のサービス開発がどのように行われ ているかお話しします •クックパッドマートについて少し紹介します
12. •スーパー ‣ 混雑していてレジに並ぶ ‣ 買いたいと思ったときに営業終わってる ‣ 品揃えが微妙なこともある • かといって、良い感じの店を回る余裕はない これまでの買い物の課題 12
13. •ネットスーパー ‣ 1品から買えない ‣ 送料かかる(送料無料は◦円以上) これまでの買い物の課題 13
14. •送料無料・1品から注文可 •良い品が安く買える ‣ 生産者や卸と直接提携しているので、スーパーには売っていないよう な商品も買う事ができる •買った物はまとめてステーション(後述)で受け取れる ‣ 留守を気にしなくていい。24時間のドラッグストアで、仕事帰りに スッと受け取れる。混雑しているスーパーで並ぶ必要もない。 クックパッドマートのメリット 14
15. 一般的なEC 15
16. クックパッドマートの仕組み 16
17. アプリで注文(User) 17
18. 注文情報が店舗へ(Store) 18
19. 商品ラベルを貼って商品準備(Store) 19
20. 共同集荷場所へ納品(Store) 20
21. 集荷(Driver) 21
22. 配送(Driver) 22
23. 受け取り(User) 23
24. サービス開発とは？ 24
25. •「ユーザに価値を届けること」こそサービス開発である •例えば ‣ 困っていることを解決する ‣ 不便だけど仕方なく使っている仕組みの代わりを提供する ‣ 嬉しい・楽しいといった感情を強くする体験を提供する サービス開発とは 25
26. サービスづくりとは 赤の他人へのプレゼント選び 26
27. •赤の他人に何をプレゼントしますか？ ‣ ちょっと考えてみてSlackに書いてみましょう プレゼント選び 27
28. •赤の他人に何をプレゼントしますか？ ‣ 何を渡せば喜んでもらえるだろうか。。。？ • 友達や家族の欲しい物を理解するのさえ難しい ‣ これを赤の他人に行うのがサービス開発 プレゼント選び 28
29. 分からないなら聞けば良い？ 今日何食べたい？ 29
30. 分からないなら聞けば良い？ 今日何食べたい？ うーん...なんでもいいよ 30
31. 分からないなら聞けば良い？ 今日何食べたい？ うーん...なんでもいいよ 31
32. 分からないなら聞けば良い？ 今日何食べたい？ うーん...なんでもいいよ 自分の欲しい物を言語化するのは難しい 32
33. 分からないなら聞けば良い？ •自分の欲しい物を言語化するのは難しい l΋͠ސ٬ʹɺ൴Βͷ๬Ή΋ͷΛฉ͍͍ͯͨΒɺ
    ൴Β͸ʰ΋ͬͱ଎͍അ͕΄͍͠ʱͱ౴͍͑ͯͨͩΖ͏z ヘンリー・フォード ‣自動車が普及する前の欧米では交通手段は馬車だった ‣自動車を知らない人は自動車の利便性は想像できない ‣人々の本質的なニーズは「速く移動したい」 33
34. サービス開発は難しい 34
35. サービス開発の難しさ •先行きの不透明性 ‣ ゴールが分からない ‣ 指標が無いため今いる場所も分からない • 正解がない中で人が欲しい物を作る必要がある • 失敗は前提 35
36. 不確実で失敗は前提 36
37. 不確実で失敗は前提 →失敗を無駄にしない開発 37
38. 科学的にサービス開発 38
39. [ܗಈ] 1. ߟ͑ํ΍ߦಈͷ͔͕ͨ͠ɺ࿦ཧతɺ࣮ূతͰɺܥ౷ཱ͍ͬͯΔ͞·ɻ 2. ಛʹࣗવՊֶͷํ๏ʹ߹͍ͬͯΔ͞·ɻʮՊֶతͳ஌ࣝʹ๡͍͠ʯ σδλϧେࣙઘ 科学的とは？ 39
40. [ܗಈ] 1. ߟ͑ํ΍ߦಈͷ͔͕ͨ͠ɺ࿦ཧతɺ࣮ূతͰɺܥ౷ཱ͍ͬͯΔ͞·ɻ 2. ಛʹࣗવՊֶͷํ๏ʹ߹͍ͬͯΔ͞·ɻʮՊֶతͳ஌ࣝʹ๡͍͠ʯ σδλϧେࣙઘ 科学的とは？ 40
41. •成功する確率が比較的高い •失敗の原因が特定できる •成否関係なく結果から情報を得られる •特定個人の発想・センスに強く依存しない 科学的なサービス開発 41
42. •サービス開発の失敗とは ‣ 「誰も欲しがらないモノ」を作ってしまうこと サービス開発の失敗 降りてきた これは当たる つくります！ 開発 リリース 膨大なコスト 膨大な時間 42
43. •サービス開発の失敗とは ‣ 「誰も欲しがらないモノ」を作ってしまうこと サービス開発の失敗 利用者が無 今まで一体何を・・・ 降りてきた これは当たる つくります！ 開発 リリース 膨大なコスト 膨大な時間 43
44. •サービス開発の失敗とは ‣ 「誰も欲しがらないモノ」を作ってしまうこと サービス開発の失敗 サービス開発を成功させるためには できる限り早く、作るべきモノを突き止める 44
45. ここまでのまとめ 45
46. •サービス開発はものすごく難しい •失敗が前提なので、失敗からいかに学びを得るかが重要 •そのために科学的なプロセスを意識する必要がある サービス開発の考え方まとめ 46
47. 実際にどうやるのか 47
48. 正解がない中で人が欲しいものを作るには 考えて 確かめる (仮説) (検証) 仮説と検証のループをていねいに、高速に繰り返す 仮説を繰り返し検証していくことで少しずつ判断を適切なものへ変えていける 48
49. 「考えて・確かめる」を高速に スパンの長い開発 スパンの短い開発 一旦正解を決めて突き進む 正解を模索しながら進む 49
50. 検証を繰り返すためのプロセス 50 •例えば… •PDCAサイクル(Plan→Do→ Check→Act) •OODAループ(Observe→Orient→Decide→Act) •BMLループ(Build→Measure→ Learn)
51. 検証を繰り返すためのプロセス 51 •例えば… •PDCAサイクル(Plan→Do→ Check→Act) •OODAループ(Observe→Orient→Decide→Act) •BMLループ(Build→Measure→ Learn)
52. 今日の講義では 52 •リーンスタートアップをベースに 話します •BMLループもリーンスタートアッ プで出てくる手法 •クックパッド社内でも支持が高い
53. BMLループ idea product data Build Measure Learn データから 仮説に 仮説からプロダクトに プロダクトからデータに 53
54. idea(仮説) idea product data Build Measure Learn データから 仮説に 仮説からプロダクトに プロダクトからデータに 54 まずは仮説を立てるところから
55. idea(仮説) •仮説を立てるにはユーザを深く理解することが必要 •理解のポイントは2つ 欲求 課題 やりたい できない 55
56. ユーザ理解の手法 •手法はいろいろ(次ページで紹介) ‣ユーザインタビュー ‣アンケート ‣ドッグフーディング ‣ログ分析 ... 56
57. ユーザーインタビュー 57 •人に話を聞き、じっくり観察をする •行動や態度の深層にある本音、核心 •メンタルモデル（思考プロセス、潜在意識） を導くことができる調査手法
58. アンケート 58 •収集した調査対象者の実態、意識、評価などに関する データを数値化し、統計学的に分析する調査方法
59. アンケート 59 ࣄྫ঺հ ࣾ಺޲͚ ࣾ֎޲͚
60. ドッグフーディング 60 •自社製品・サービスを社員が日常的に利用し改善に役立 てる事(社内テスト) •日常的な利用の中で、ユーザビリティの確認や問題点の 発見を行う ※ ドッグフードのセールスマンが犬用ビスケットを食べて 質の高さをアピールした、というエピソードが由来(らしい)
61. ドッグフーディング 61 ࣄྫ঺հ
62. ログ分析 62 • 「ログ」とは • 時系列データ (いつ、誰が、どこで、何をどうやって、どうした) • 数値データや文字データ • 一口にログと言ってもたくさん種類がある • ユーザ理解のために何のログを見れば良いか • PV(ページビュー)ログ: ブラウザリクエストの記録・分析 • 行動ログ: ユーザ行動の記録・分析 などを見ることが多い
63. ペルソナ作成 • ユーザー理解を深めた後、 共通点をペルソナにする • ユーザーは百人十色。 ‣ ただし、似た属性・志向を持つ ユーザの行動パターンは 数個に収束する • その行動パターンを言語化し ペルソナにしてチーム内で共有する ‣ チーム内でユーザー像の認識を揃える 63
64. Build idea product data Build Measure Learn データから 仮説に 仮説からプロダクトに プロダクトからデータに 64
65. Build •課題の解決策を具体化する ‣まずはユーザーのストーリーを考える ‣ストーリーを実現する解決策の案を出す ‣仮説と解決策をまとめて言語化する ‣それを最小コストで実現する 65
66. Build •課題の解決策を具体化する ‣まずはユーザーのストーリーを考える ‣ストーリーを実現する解決策の案を出す ‣仮説と解決策をまとめて言語化する ‣それを最小コストで実現する 66
67. ユーザーのストーリーを考える • 解決策を点で考えないことが重要 ‣ いきなり機能を考えようとしない ‣ まずは課題を抱えてから解決するまでの流れを線で考える (ストーリーを描く→ユーザーストーリー) 67
68. フリマアプリのストーリー例 • セールで狙っていた服を買い逃してしまった • 諦めきれずフリマで売りに出ているものを探す • 運良く服を見つけ、状態も新品であることを確認 • が、販売価格が高かったのでひとまず保存しておく • 一週間後、値下げされたことを知る • 他の人に狙われないうちに、急いで購入手続きをした 68
69. たとえば • セールで狙っていた服を買い逃してしまった • 諦めきれずフリマで売りに出ているものを探す • 運良く服を見つけ、状態も新品であることを確認 • が、販売価格が高かったのでひとまず保存しておく • 一週間後、値下げ情報がPush通知で届いた • 他の人に狙われないうちに、急いで購入手続きをした 機能名を書くとそこで思考停止する → Push通知以外の選択肢が頭から消える 69
70. アプリでの行動例 • セールで狙っていた服を買い逃してしまった • 諦めきれずフリマで売りに出ているものを探す • 運良く服を見つけ、状態も新品であることを確認 • が、販売価格が高かったのでひとまず保存しておく • 一週間後、値下げされたことを知る • 他の人に狙われないうちに、急いで購入手続きをした ブランド名で検索 商品詳細の確認 いいね Push通知受信 購入申請 70
71. フリーマーケットでの行動例 • セールで狙っていた服を買い逃してしまった • 諦めきれずフリマで売りに出ているものを探す • 運良く服を見つけ、状態も新品であることを確認 • が、販売価格が高かったのでひとまず保存しておく • 一週間後、値下げされたことを知る • 他の人に狙われないうちに、急いで購入手続きをした 会場で探す 手にとって確認 記憶・メモ フリマに再訪 声かけ 71
72. ポイント • ユーザー視点で記述することで、既存の代替手段と比較が可 能になる • あえて画面外の行動も書く • そのままユーザーテストでやってもらうことの リストとすることもできる 72
73. Build •課題の解決策を具体化する ‣まずはユーザーのストーリーを考える ‣ストーリーを実現する解決策の案を出す ‣仮説と解決策をまとめて言語化する ‣それを最小コストで実現する 73
74. 解決策の案を出す 74 発散 収束 • 案を出す時に大切なこと 無理やりにでも アイデアを広げる 発散したアイデアから 着想を得てアイデアを具現化
75. アイデア発散の手法: Crazy8s • 時間を区切ってアイディアやバリエーションを出しまくる 75
76. 具現化の方法: ソリューションスケッチ • 解決策を3コマ程度のスケッチで表現する 76
77. 注意点 •各フェーズできちんと制限時間を設ける ‣ダラダラ考えてもいいアイディアはでない ‣原則この時点では「何もわかっていない」 ‣ここで悩んでいても議論が空中戦になりやすい 77
78. Build •課題をの解決策を具体化する ‣まずはユーザーのストーリーを考える ‣ストーリーを実現する解決策の案を出す ‣仮説と解決策をまとめて言語化する ‣それを最小コストで実現する 78
79. 仮説と解決策の言語化 •抑えるべきポイント 1. 利用者: そのサービスは誰が使う? 2. 価値: そのサービスを使うと何がうれしいの? 3. 体験: その価値はどんな体験から得られる? 4. 機能: その体験がどんな機能があれば実現できる? 79
80. 価値仮説シート 80
81. Build •課題をの解決策を具体化する ‣まずはユーザーのストーリーを考える ‣ストーリーを実現する解決策の案を出す ‣仮説と解決策をまとめて言語化する ‣それを最小コストで実現する 81
82. 最小コストで実現する •課題解決策のアイディアを具体化 •可能な限り小さな実装で仮説を検証する = MVP 82
83. よくないMVPの例 83 • 次のページによくないMVPの例を出します • 生鮮食品が一品から送料無料で買えて、いつでも受け取 れる「クックパッドマートの体験を確かめたい」場合に どこが良く無いでしょうか • 一緒に考えてみよう
84. よくないMVPの例 84 ˞
    ࣮ࡍͷ෺Ͱ͸ͳ͘ɺࢿྉ༻ʹ࡞ͬͨ෺Ͱ͢
85. MVP 85
86. 最小コストで実現する •課題解決策のアイディアを具体化 •可能な限り小さな実装で仮説を検証する = MVP ‣Minimum Viable Product ‣検証を行える可能な限り小さいもの ‣「実装しない」のが最も小さい 86
87. クックパッドマートのMVP ࣄྫ঺հ lΫοΫύουϚʔτ্ཱͪ͛ʹ͓͚ΔϓϩτλΠϐϯά
    
    3ZP
    ,BUTVNBz 87
88. クックパッドマートのMVP ࣄྫ঺հ lΫοΫύουϚʔτ্ཱͪ͛ʹ͓͚ΔϓϩτλΠϐϯά
    
    3ZP
    ,BUTVNBz 88
89. •目的は「最短で仮説が検証できるものをつくる」こと •方法はいろいろ ‣ ペーパープロトタイピング ‣ プロトタイプツールの利用(Flinto/Prott/InVision/…) ‣ デモ環境での実装 ‣ 本番環境での実装 •目的に合わせて最小コストのものを選択する MVP 89
90. Measure idea product data Build Measure Learn データから 仮説に 仮説からプロダクトに プロダクトからデータに 90
91. •つくって終わりじゃ意味がない •出てきた結果をから仮説の答え合わせをして 次に活かすのが何よりも大事 ‣ 仮説は正しかったのか？間違っていたのか？ ‣ どこが正しかったのか？どこが間違っていたのか？ ‣ このまま進んでいいのか？方向転換が必要か？ Measure 91
92. •大雑把に分けると定性と定量 ‣ 定性データ • 数値に表せない質的な情報。 ‣ 定量データ • 数値として把握できる情報。ログを基にした数値情報。 検証方法 92
93. •定性データ ‣ ユーザーインタビューのログ ‣ アンケートの自由記述欄 検証方法 93
94. •定量データ ‣ PV(PageView), CV(Conversion), UU(Unique User), リテンションなど • PV(ページビュー)ログ: ブラウザリクエストの記録・分析 • CV(コンバージョン): 例えば商品の購入や申し込みなど)、獲得できた成果を示 す指標 • UU: 集計期間内にWebサイトやアプリを利用したユーザーの数を表す指標 • リテンション: 継続率のこと。インストールの後に一定の日数が経過しても継 続してアプリを使用しているユーザーの割合。 検証方法 94
95. •前提としてどちらの観点も必須 •それぞれに得意不得意があるので、 施策内容やサービスのフェーズ等で重み付けを変える 定性 vs 定量 95
96. •代表的なのはユーザテスト 定性評価 96
97. •代表的なのはユーザテスト •ユーザーの体験やその理由を直接確認できるので、 行動の裏づけとなる情報が得られる •一方で、情報の正確性には注意が必要 ‣ テスト対象が特殊な属性だったら？ ‣ ユーザーが無自覚に普段の行動と違う話をしていたら？ 定性評価 97
98. •代表的なのはABテスト ‣ ABテスト: Webサイトや広告の バナー等の画像をAパターンとB パターンの2パターン用意して、 「どちらがより良い成果を出せ るのか」検証するもの 定量評価 98
99. (参考資料) クックパッドのデータ活用基盤 99 •クックパッドのデータ活用基盤 https://techlife.cookpad.com/entry/2019/10/18/090000
100. •代表的なのはABテスト •正確な情報を得ることができる ‣ 前提や検証の状況を疑うことは必要 •一方で、行動の理由はわからないため ユーザー体験を裏付ける情報は得られない ‣ 施策の数字 良かった/悪かった のはなぜ？ ↑この問いが仮説の域から出ることはない 定量評価 100
101. 定性 vs 定量 定性評価 定量評価 • 得られる ”情報量” が多い • どうあがいても主観が入る • サンプルが偏る可能性が高い • 明確な結果は出てきづらい • 検証期間自体は短い • 得られる ”情報量” が少ない • サンプルの偏りを減らせる • 明確な結果が出しやすい • それなりの検証期間が必要 101
102. 定性と定量の使い分け 定性評価が向いてる 定量評価が向いてる • サンプル数が少ない • 検証したい体験が複雑 • コンセプトを詰めていきたい • サンプル数が十分に取れる • 検証したい体験がシンプル • コンセプトが成熟している サンプル数の判断は難しい 簡単にやるなら https://www.optimizely.com/sample-size-calculator/ などのサイトが使える FYI: https://techlife.cookpad.com/entry/2016/09/26/111601 102
103. •実際にはつくるものと検証方法はセットで決める ‣ ユーザーテストをするならプロトでいい ‣ ABテストをするなら実装が必要 Buildとの関係性 103
104. Learn idea product data Build Measure Learn データから 仮説に 仮説からプロダクトに プロダクトからデータに 104
105. •調べて終わりじゃ意味がない •出てきた結果から仮説の答え合わせをして、次に活かすのがなにより も大事(再掲) ‣ 測っただけでは答え合わせができていない •学んだ結果を次の仮説のタネにする •組織内に共有できるのがベスト Learn 105
106. “学びを得るために” 106 •Learnについて前もってやっておくべきことがある •気をつけないと得られる”学び”が減ってしまう
107. “学び” とは 107 l4FSWJDF
     EFWFMPQNFOU
     MFDUVSF
     JO
     
     DPPLQBE
     TVNNFS
     JOUFSOTIJQ
     
     ,PIFJ
     "SBJz
108. “学び” とは 108 l4FSWJDF
     EFWFMPQNFOU
     MFDUVSF
     JO
     
     DPPLQBE
     TVNNFS
     JOUFSOTIJQ
     
     ,PIFJ
     "SBJz
109. “学び” とは 109 l4FSWJDF
     EFWFMPQNFOU
     MFDUVSF
     JO
     
     DPPLQBE
     TVNNFS
     JOUFSOTIJQ
     
     ,PIFJ
     "SBJz
110. “学びを得るために” 110 •指標解釈の整理 • この数値が高くてこの数値が低い時はどんな時だろうか •結果の想定 • 測定指標がどのくらいの数字になったらどうするか • 取捨選択のラインを最初に引いておかないと、「少しでも数字が上がっ ていたらなんとなくGO」で機能追加されてしまうことに •「成功のイメージ」を共有する Learnについて前もってやっておくべきこと
111. 学びを共有する社内の取り組み例 ࣄྫ঺հ •kaimono/歴史 ‣ サービス開発における歴史を まとめたページ。 ‣ 過去の重要な意思決定やユー ザテストの記録が時系列でま とまっている 111
112. まとめると 112
113. •「考えて・確かめる」を丁寧かつ高速に繰り返す ‣ Build: 仮説からつくるものを決める、最小の実装で済ませる ‣ Measure: 定性と定量の両視点を持、検証方法も吟味する ‣ Learn: 事前の想定が重要、組織内に情報を共有する •要所要所で社内外のフレームワークを利用 サービス開発のフローまとめ 113
114. •No ‣ 「ペルソナを作らないと先に進めない」みたいなことはない •プロジェクトの状況とメンバー次第 ‣ 「時間を何に使うか」の見極めは重要 •今日の内容は守破離でいう「守」 ‣ 守破離: 物事を学ぶ時の姿勢 守: 学んだことを実践する段階 破: 試行錯誤しながら自分流のスタイルに挑戦する段階 離: 自分流のスタイルを極め一流を編み出すこと 今日の内容は現場でも常に全て実践されている? 114
115. 仮説・検証を繰り返す社内事例 ࣄྫ঺հ • 仮説・検証を繰り返す開発スタイルは クックパッドではよく行われている • ソフトウェアに限らず、 マートステーションのようなハード ウェアのプロダクトでも同じようにス パンの短い開発が行われている 115
116. マートステーションの事例 ࣄྫ঺հ 18ヶ月で3度のアップデート 116
117. マートステーションの事例 ࣄྫ঺հ •受け取り体験向上を目的とした仮説検証 117
118. マートステーションの事例 ࣄྫ঺հ •マートステーションが短いスパンで開発したこと得られた恩恵 ✅ プロダクトの継続的な改善 •例えば「冷蔵庫のラッピングデザインを変えたい」みたいな要望が出ても 大量生産・設置した後だと後戻りができない ✅ 運用後しか分からないような問題への対処 •ユーザーがドアを開けっぱなしにしてしまうことが発生 •コインロッカーなら問題ないが、マートステーションはサービスの性質上 扉を開けっぱなしにされると他のユーザの商品の品質に影響 118
119. サービス開発講義 実践編 119
120. •講義パートで説明したBMLループのidea→Buildの部分 を実践してもらいます 実践編でやること idea product data Build Measure Learn 120
121. 実践パートスケジュール •14:30-14:40 実践パート説明(10min) •15:30-15:45 実践パート1(65min) •15:45-17:45 実践パート2(120min) •17:45-18:00 総評・クロージング(15min) 実践パートでは休憩時間の指示はしません Buildの時間で各自休憩を取りながら進めてください 121
122. https://sozai.katsuma.tv プロダクトをつくってもらいます 「一人暮らしをしている人の料理が楽しみになる」 122
123. 実践パート1でやること ① 価値仮説シートを作成 ② 作成した価値仮説の中から 検証するものを一つ選ぶ ⑤ Crazy8sでアイデアを発想 ③ ユーザーストーリー作成 ④ ユーザーストーリーと価値仮説 にズレが無いことを確認 123
124. 実践: 価値仮説 124
125. • 「ペルソナと行動ログ」から価値仮説シートを埋めてみよう • いくつか価値仮説シートを作成してみよう 価値仮説を立ててみよう(20min) 時刻 行動 9:00 起床 9:15 朝ごはん 9:30 会社の支度 10:00 出社 ・・・ Input: ペルソナと行動ログ Output: 価値仮説シート 125
126. ペルソナについて再掲 126
127. ペルソナと行動ログ 127 • Figmaのワークブックにペルソナを貼っています • ペルソナは2種類用意しています • 先ほど2人1組に別れてもらいましたが、それぞれ別のペルソナに ついて価値仮説を立ててもらいます
128. 欲求と課題を深ぼる •対象となるペルソナの抱えている欲求と課題を発見 • ユーザーの背景や行動からユーザの感情を読み取る • 価値仮説シートのフォーマットにまとめる 128
129. ਓؾॱݕࡧͷՁ஋Ծઆ ϨγϐΛ୳͢Ϣʔβ ࠓ೔ͷϝχϡʔΛૣܾ͘Ί͍ͨ ଟ͘ͷϨγϐ͕͋ΓܾΊΒΕͳ͍ ਓؾϨγϐΛݕࡧͰ͖Δ 129
130. 価値仮説を立てる上での注意 ਓؾॱݕࡧͷՁ஋Ծઆ ϨγϐΛ୳͢Ϣʔβ ਓؾϨγϐΛݕࡧ͍͕ͨ͠ ଟ͘ͷϨγϐ͕͋ΓܾΊΒΕͳ͍ ਓؾϨγϐΛݕࡧͰ͖Δ • 欲求に機能を書かないように注意 • 欲求「〇〇したいので」 機能「〇〇できることに価値があ る」という形式になってしまう • これは、ユーザーの本質的なニーズ を見抜けていない 130
131. (ここはまだ書かないで) ※あとで書く時間をとります 131
132. 価値仮説作成タイム(20min) (ここはまだ書かないで) 132 ϒϨΠΫΞ΢τϧʔϜ࡞੒
133. • 作成した価値仮説の中から検証するものを一つ選ぼう 価値仮説を選ぶ 133
134. 価値仮説選択タイム(5min) 134
135. 実践: ユーザーストーリー 135
136. • ユーザーを取り巻く、環境・文脈を言語化したもの • 本当に作成した価値仮説でユーザーの課題が解決できるの か、確認するために作る • ユーザーのセリフを時系列にシートに書いてみましょう ユーザーストーリー 136
137. ࢓ࣄؼΓͷిं಺Ͱ
     ࠓ೔ͷ൩͝͸ΜͲ͏͠Α͏ɻ
     ͔ͨ͠ྫྷଂݿʹ՘ࢠ͕͔͋ͬͨΒফඅ͍ͨ͠ͳɻ ΫοΫύουΛ্ཱͪ͛ͯ
     
     ΁ʔ՘ࢠͷνʔζম͖͔ɻ؆୯ͦ͏ͩ͠ඒຯͦ͠͏ʂ ؼͬͨΒ࡞ͬͯΈΑ͏ɻͰ΋Ոʹνʔζͳ͔ͬͨΑͳɻɻɻ ؼΓʹӺલͷ౦ٸʹΑͬͯɺνʔζങ͓ͬͱɻ 137
138. • 開発者目線で書かない • ユーザーのセリフ調で書くと、開発者目線になりづらい • サービス利用前後を意識する • サービス外のことも含めて言語化する • 機能名やUI名を書かない (講義パートのフリマアプリの例) 「プッシュ通知を受け取る」 「お知らせをタップする」 ユーザーストーリーを書くポイント 138
139. ユーザーストーリー作成タイム(15min) 139 ϒϨΠΫΞ΢τϧʔϜ࡞੒
140. ユーザーストーリーと価値仮説を見返してみよう • ここで一度、ユーザーストーリーと価値仮説を見比べてみ て、ズレがないか確認してみましょう • もしズレていたら価値仮説・ユーザーストーリーをもう一 度再考して書き直してみてください • ズレてないか不安な場合はメンターに見てもらいましょう 140
141. ユーザーストーリーと価値仮説にズレが無いか 確認してみよう(10min) 141 ϒϨΠΫΞ΢τϧʔϜ࡞੒
142. 実践: Crazy8s 142
143. •価値仮説をもとに、仮説を検証するためのアイデアを 発想します •デザインスプリントの一部であるCrazy8sという手法 をやります Crazy8sでアイデア発想 143
144. •A4の紙を一枚とサインペンを手元に用意してください •A4の紙は8つ折りにしましょう Crazy8sでアイデア発想 144
145. • 8分間で8つのアイデア(1つ60秒)をスケッチします • スケッチは雑でOK、棒人間でもいいし、言葉で説明でもOK • 質より量、思いつきをカタチとして出すことが大事 Crazy8sでアイデア発想(8min) 145
146. Crazy8s: 1 146
147. Crazy8s: 2 147
148. Crazy8s: 3 148
149. Crazy8s: 4 149
150. Crazy8s: 5  (0"-
     
       150
151. Crazy8s: 6  (0"-
     
       151
152. Crazy8s: 7  (0"-
     
           152
153. Crazy8s: 8  (0"-
     
           153
154. • 価値仮説シートの製品の特徴の箇所が空欄だったと思いま す • Crazy8sで出したアイデアを参考に製品の特徴を埋めてみ ましょう Crazy8sを踏まえて価値仮説シートを完成させよう 154
155. • 普段だと複数人でCrazy8sを行い、良いアイデアに投票を行った りすることで、発散したアイデアを収束させるプロセスをとる • 今回は、Crazy8sで発散したアイデアを基に、価値仮説の製品の 特徴を埋めてもらうことで収束のフェーズを取ります • 価値仮説の機能にはCrazy8sで出てきたアイデアそのものを書 いてもOK • Crazy8sやった上で新たに発想を得たアイデアを書いてもOK Crazy8s補足 155
156. 価値仮説シートの製品の特徴を埋めよう(5min) ਓؾॱݕࡧͷՁ஋Ծઆ ϨγϐΛ୳͢Ϣʔβ ࠓ೔ͷϝχϡʔΛૣܾ͘Ί͍ͨ ଟ͘ͷϨγϐ͕͋ΓܾΊΒΕͳ͍ ਓؾॱݕࡧͷՁ஋Ծઆ ϨγϐΛ୳͢Ϣʔβ ࠓ೔ͷϝχϡʔΛૣܾ͘Ί͍ͨ ଟ͘ͷϨγϐ͕͋ΓܾΊΒΕͳ͍ ਓؾϨγϐΛݕࡧͰ͖Δ 156
157. 実践パート2: プロトタイピング 157
158. • 価値仮説シートをベースに、プロトタイプを作ってもらい ます！ プロトタイピング 158
159. プロトタイピング • プロトタイプ作成のコツ • Figmaを使う人: 事前準備資料 「Figma入門 Chapter 5: プロトタイピング」をみてみましょう • 画面遷移の設定などは必ずしも必要ではありません 159
160. プロトタイピング • プロトタイプ作成のコツ • ペーパープロトタイプを行う方 • 大きめ付箋を画面に見立ててUIを 組み立てると作りやすいです 160
161. プロトタイプ作成(18:00) 161 ϒϨΠΫΞ΢τϧʔϜ࡞੒
162. さいごに 162
163. さいごに • サービス開発講義では、クックパッドのサービス開発を紹介 したあと、実際にユーザの欲求を解決するためのプロトタイ プを作成してもらいました • 時間の関係で紹介できたのは一部でしたが、今後サービス開 発を行う際は今日学んだことを生かしてもらえると嬉しいで す • インターン残り3日も頑張ってください！ 163