【勉強会】Cookpad Tech Conf2018レポ

昨年気になっていた Cookpad TechConf2018に参加してきたので
個人的な振り返りも含めてざっくりレポート書きます。
(※開発や考え方メインです。個人的な感想もあります。)
 
(写真は懇親会のお料理です。)
講演で印象に残った内容をキーワードにまとめると以下の4つになります。
「ユーザ理解」
「ユーザと自社のサービスを理解するための仮説と検証」
「手戻りを防ぐ」
「サイクルを回す」

 

ユーザ理解

グローバル展開の話の中で、
「ユーザを理解するために直接現地のユーザの家庭を訪問する」ということをまず行ったそうです。
サービス開発の基本はやはり「ユーザ理解」。その一番の近道は「直接声を聞く」こと。
当たり前のことですが、当たり前だからこそ大切にしていかなければならないと感じました。

 

ユーザと自社のサービスを理解するための仮説と検証

講演の中でサービス開発は難しいという話がありました。
ユーザの欲求は本人でもわからない、かつ時間とともに変化する。
さらに開発者も自分のサービスを正しく理解できていないときがあると。

そこで適切なサービスを開発するために利用しているフレームワークが「BMLサイクル」で、
仮説と結果(ユーザの反応)の検証を繰り返すのに役立つそうです。
BMLサイクルについてまとめると長くなるので、
ここでは仮説を立てるフェーズ(build)を取り上げます。

※BMLサイクルは下記に詳しくあります。(英語の記事です)
    https://www.mindtools.com/pages/article/build-measure-learn.htm

 

・build
検証したい対象の明確化を行うフェーズ。
クックパッドでは「価値仮説シート」というフレームワークで明確化しているそうです。(下記のxxxを埋めて明確化する)

xxx(ターゲットユーザ)は、

xxxしたいが(欲求)、

xxxので(背景)、

xxxに価値がある(価値基準)

パッと見ただけでもわかりやすいので、このフレームワークを初めて見た人でも、「ユーザの欲求」、「その欲求が生まれた背景」、「その欲求に対して生み出せる価値」を整理できそうですね。

 

手戻りを防ぐ

開発サイクル(BMLサイクル)で手戻り防止をするためには、下記の点が必要になってくるそうです。

・適切な仮説の立て方をすること

前述の価値仮説シート参照

・全体を見通した上で各フェーズを進めていくこと

仮説を立てて先まで見通す(全体を設定する、その場の思いつきはダメ)

・仮説と結果を比較して、次の施策へ生かす

サービスへの理解(=施策に対する仮説)と現実(=結果)を「比較」、そして両者の「ギャップが生まれた原因」を行うこと

適切な仮説の立て方をすれば、自ずと「全体が見えてくる」、「得た結果を正しく認識できる」ようになるのだろうと聞いてて感じました。

 

サイクルを回す
どの講演でも「サイクルを回す」という言葉が何度も使われていましたが、ハードウエア(スーパーに置いてあるCookpad store TV)開発の話がイメージしやすかったので紹介。
初の試みで徐々にサービスを広げて行ったときのステップは以下。

1.最小価値検証

・最小価値から仮説を立てる

最小価値=売り場で料理動画を流すこと
仮説 = 売り場でレシピ動画を観れることはユーザにとっていいこと
実施結果は直接店舗の声をヒアリングと売り上げを確認。

・実施結果の分析

実施結果: 対象商品の売り上げは上がった
問題点: 毎日流すには動画数が少ない、端末が目立たない etc…

2.スケールアップ

・1で出た問題点の改善

自分たちでやること、やらない(外注で対応)を切り分けをする
ex.動画量が少ない:自分たちで改善できる、端末が目立たない:デザインを依頼

・改善した端末で台数を増やす

・実施結果の分析

問題点:売り場に置くにはサイズが大きい、バグが出てくる

3.収益化

・2で出た問題点の改善
・収益を得る方法(広告配信)を構築する

新しいことを行う際にも、まず最初は「仮説と検証」。
そして、出てきた「問題点の分析と改善」の繰り返しがどのステップでも徹底されていることがわかりますね。

 

以上、開発話で気になったキーワード4点まとめでした。

開発のお話だけでも情報量が膨大で…。
初投稿かつ初レポで非常に読みづらい点もあったと思いますが、ここまで読んでくださった皆様、ありがとうございます!
(これからより読みやすい内容にできるよう精進します)
コメントはご自由に記載いただけると幸いです。

技術に関しては画像識別の話やテスト自動化の考え方などがありましたので、
こちらはまとめられたらまとめます。

 

 

補足 「問題(課題)解決」の考え方

講演中に「ユーザの課題を正しく定義して〜」「ユーザの課題への理解が〜」という言葉が出てきました。
この言葉を聞いた時、「問題解決」の考え方がふと思い浮かび、
問題解決の考え方が自然と身についているんだろうなと思いました。

あわせて読みたい

コメントを残す

メールアドレスが公開されることはありません。