Slide 1

Slide 1 text

サービス開発とは?

Slide 2

Slide 2 text

サービス開発とは 赤の他人へのプレゼント選び • プレゼントを渡して他人を喜ばせるのは難しい • 友達でも悩むし、家族ですら悩む • なのに赤の他人がほしいものなんて分かるわけがない

Slide 3

Slide 3 text

今日何食べたい? んー… 分からないなら本人に聞けばいい?

Slide 4

Slide 4 text

今日何食べたい? なんでもいいよ 欲しい物を言葉にするのは難しい

Slide 5

Slide 5 text

今日何食べたい? じゃあ素麺でいい? なんでもいいよ えー、、素麺かぁ… 欲しい物を言葉にするのは難しい

Slide 6

Slide 6 text

サービス開発における大前提 誰も正解がわからない

Slide 7

Slide 7 text

・何をつくるべきなのかは誰も分からない ・社長も上司もユーザー自身も分からない ・意見や思考は変わるもの 明日は早起きして3km走るぞ!! PM 21:00 同一人物 AM 6:00 眠い…もうちょっとだけ布団に… 正解がわからないことを知る

Slide 8

Slide 8 text

サービス開発とは 誰も正解がわからないなかで 人が欲しがるものをつくること

Slide 9

Slide 9 text

サービス開発とは どうすればいい ?

Slide 10

Slide 10 text

・誕生日プレゼントをあげて喜ぶかは、あげてみないと分からない ・年に一回の誕生日プレゼント以外の方法で好みを知ることもできる   ・何気ない会話から推察する   ・服装や持ち物、行動を観察してみる   ・手軽にコンビニで買ったお菓子をあげてみる どうするのが合理的か

Slide 11

Slide 11 text

考えて (仮説) (検証) 確かめる これを、ひたすら繰り返す 正解がない中で人が欲しがるものを作るには

Slide 12

Slide 12 text

・最初から100%ユーザーが喜ぶものを作るのは難しい ・ひたすら作って壊すの繰り返し  ・壊しやすく作るのも大事 ・失敗を恐れるのではなく、当たり前と考えて  時間をかけ過ぎずに前に進めるのが大事 失敗は前提

Slide 13

Slide 13 text

サービス開発とは ピントを徐々に合わせる行為

Slide 14

Slide 14 text

現場で実践される開発プロセス 仮説 考える 実行 作ってみる 検証 答え合わせ

Slide 15

Slide 15 text

仮説 考える 実行 作ってみる 検証 答え合わせ 現場で実践される開発プロセス 高速に回す

Slide 16

Slide 16 text

仮説 考える 実行 作ってみる 検証 答え合わせ 各工程の大事なポイントと手法をお話していきます

Slide 17

Slide 17 text

仮説 考える 実行 作ってみる 検証 答え合わせ 仮説フェーズで大事なこと

Slide 18

Slide 18 text

仮説フェーズで大事なこと① ・仮説を立てるにはユーザーを深く理解することが必要  ユーザー理解の深さが高い精度の仮説につながる ・理解のポイントは2つ 欲求 やりたい できない 課題

Slide 19

Slide 19 text

・手法はいろいろ ・ユーザーインタビュー ・アンケート ・ドッグフーディング ・ログ分析 ・etc.. ユーザー理解の手法

Slide 20

Slide 20 text

・手法はいろいろ ・ユーザーインタビュー ・アンケート ・ドッグフーディング ・ログ分析 ・etc.. 午後の実践はこれをやってみます ユーザー理解の手法

Slide 21

Slide 21 text

ユーザーインタビュー ・ユーザーを理解するための基礎であり、最も汎用的な手法 価値観、文脈、行動 ・例:ユーザーに起床から就寝までの一日の流れを教えてもらう   ・ユーザーの を理解する ・Contextual Inquiry (文脈的調査)  ・ユーザーを師匠と見立てて、弟子入りして教えを請う

Slide 22

Slide 22 text

・共通点をペルソナにする ・ユーザーは百人十色 ・その行動パターンを言語化し、  ペルソナにする 数個に収束する ・似た属性・志向を持つユーザーの  行動パターンは ユーザー像の認識を揃える ・チーム内で ペルソナ作成

Slide 23

Slide 23 text

・対象となるペルソナの抱えている課題を発見 ・解決すべき課題はなにか? ・どうやって解決するか? ・解決によって得られるものは? ・解決にかかるコストは? ・代替手段を使ってでも解決しようとしている? 仮説の定義

Slide 24

Slide 24 text

仮説フェーズで大事なこと② いつでも立ち戻れるコンパスを作る ・仮説を言語化することで  実行、検証フェーズで ・サービス開発は“誰も正解が分からない”  正解が無いので迷ったときの判断は人それぞれ  開発するチームで目線を合わせるため ・このコンパスを何度も見返すことで効率よく  形を作り、学びを得られる

Slide 25

Slide 25 text

No content

Slide 26

Slide 26 text

No content

Slide 27

Slide 27 text

そのサービスは誰が使う? そのサービスを使うと何が嬉しいの? その価値はどんな体験から得られる? その体験はどんな機能があれば実現できる? 1. 利用者: 2. 価値: 3. 体験: 4. 機能: 考える順序 仮説と解決策の言語化

Slide 28

Slide 28 text

状況と目的に合わせて、組み合わせる ・ペルソナ ・ジャーニーマップ ・ストーリーボード ・リーンキャンバス ・価値仮説シート ・EOGS ・アプリケーション定義ステートメント 一般的な手法 クックパッド独自の手法 フレームワーク

Slide 29

Slide 29 text

ペルソナシート 一般的な手法

Slide 30

Slide 30 text

ジャーニーマップ 一般的な手法

Slide 31

Slide 31 text

価値仮説シート クックパッド独自の手法

Slide 32

Slide 32 text

価値仮説シート 午後の実践はこれをやってみます

Slide 33

Slide 33 text

仮説 考える 実行 作ってみる 検証 答え合わせ  ユーザーを深く理解すること  いつでも立ち戻れるコンパスを作ること

Slide 34

Slide 34 text

仮説 考える 実行 作ってみる 検証 答え合わせ 実行フェーズで大事なこと

Slide 35

Slide 35 text

実行フェーズで大事なこと 最小コスト 「実装しない」のが最も小さい ・ で仮説が検証できるものをつくる ・可能な限り小さな実装で仮説を検証する = MVP  ・Minimum Viable Product  ・検証を行える可能な限り小さいもの  ・

Slide 36

Slide 36 text

MVP 「最短で仮説が検証できるものをつくる」 ・目的は こと ・方法はいろいろ  ・ペーパープロトタイピング  ・プロトタイピングツールの利用  ・実装する 午後の実践はこれ

Slide 37

Slide 37 text

実例:チャットbotのMVPを作る 社内FAQの問合わせbotを作りたいが そもそも需要があるのかどうかを試したい 実装する?? down

Slide 38

Slide 38 text

Misaki Kubosaka Misaki Kubosaka 実例:チャットbotのMVPを作る 社内FAQの問合わせbotを作りたいが そもそも需要があるのかどうかを試したい 自分がbotになってみる down

Slide 39

Slide 39 text

実行 作ってみる 仮説 考える 検証 答え合わせ  最小コストで仮説が検証できる ものをつくること

Slide 40

Slide 40 text

仮説 考える 実行 作ってみる 検証 答え合わせ 検証フェーズで大事なこと

Slide 41

Slide 41 text

検証フェーズで大事なこと ・想定する結果と現実とのズレを学びに変えること ・仮説の答え合わせをして次に活かすのが大事  ・仮説は正しかったのか?間違っていたのか?  ・どこが正しかったのか?どこが間違っていたのか?  ・このまま進んで良いのか?方向転換が必要か?

Slide 42

Slide 42 text

検証方法 ・大雑把に分けると定量と定性  ・どちらの視点も必須だが施策内容や開発フェーズで使い分ける ・定量データ  ・人数や割合、傾向地など、何かしら明確な“数値や量”で表されるデータを   集計・分析する ・定性データ  ・個人による発言や行動など、数量や割合では表現できないものの“意味”を   理解する

Slide 43

Slide 43 text

定量評価 ・正確な情報を得ることができる  ・前提や検証の状況を疑うことは必要 代表例:A/Bテスト なぜ良かったのか?/悪かったのか? ・一方で、行動の理由はわからないため  ユーザー体験を裏付ける情報は得られない  

Slide 44

Slide 44 text

定性評価 ・ユーザー体験のその理由を直接確認できるので、  行動の裏付けとなる情報が得られる ・一方で、情報の正確性には注意が必要  ・テスト対象が特殊な属性だったら?  ・ユーザーが無自覚に普段の行動と違う話をしていたら?

Slide 45

Slide 45 text

定性評価例:ユーザーテスト 明日の実践はこれ ・短期間で検証可能 ・サービスの初期のコンセプト検証  や、更なるユーザー理解に有効 ・想定と違う行動をした場合  その理由を直接確認できる

Slide 46

Slide 46 text

検証 答え合わせ 仮説 考える 実行 作ってみる  想定する結果と現実とのズレを 学びに変えること

Slide 47

Slide 47 text

まとめ

Slide 48

Slide 48 text

サービス開発まとめ 失敗は当たり前 ・「考えて⇔確かめる」を丁寧かつ高速に繰り返す。 ・開発プロセスを高速に回すためのポイント   ユーザーを深く理解すること   いつでも立ち戻れるコンパスを作る   最小コストで仮説が検証できるものをつくること   想定する結果と現実とのズレを学びに変える