クックパッドさんで行われた「s-dev talks ～サービス開発勉強会～＃ 1」に参加してきました。

サービス開発に携わるエンジニア、プロダクトマネージャー、デザイナーそれぞれの「仮説検証」について、おいしいお料理の香りに包まれながら（さすがクックパッドさん…）お話を聞く会です。

発表内容の詳細については、コンフィデンシャルも含まれていたので割愛させていただきつつ、今さらながら以下、メモ＆所感です。

エンジニア的　仮説検証

・仮設とはそもそも「問い」であり、その「問い」は正しかったか？が、検証で判断できるように立てること。

・仮説（問い）を磨きあげる＝未定義の言葉をなくしていく。

・そのプロセスをチーム一丸となって行うことで、認識のズレを最小限に抑える＆共通言語を持つことができる＝＞チームビルディングにつながるので大事。

・仮説検証の方法のひとつとしてABテストがある。

・ABテストならではの落とし穴 1: 周期や時期など外的要因はきちんと加味して行うべし。（生身の人間が使っているからこそ、本来検証したい仮説とは別の、周期や時期的な外的要因が検証数値に影響を及ぼす可能性がある）

・ABテストならではの落とし穴 2: 検証したい要素は、1度に複数混在しないよう気をつけるべし。

・そもそもABテストはは仮説検証手段のひとつでしかないので、検証方法として本当にABテストが向いているのか見極めよう。

・機能追加する際、仮説はできるだけ分解しスモールに検証するとよい。

・検証すれば、なにかしらの学びがあり、1歩が小さくとも着実に前進できる。

・検証方法として、全体公開の前にクローズドにテストするのもひとつの手。

・「〇〇は△△だから、××のはずである。」というスタンス。

デザイナー的　仮説検証

・ユーザーの”気持ち”に寄り添って定性的な仮説を立てることを得意とするデザイナー。

・定性で立てた仮説は、定量データと照らし合わせながら、セグメンテーションし、ユーザーインタビューを通じてさらに深掘りする。

・定量分析をうまく使うことで、仮説が"妄想"ではなくなる。

・ユーザーの行動、思考プロセスを可視化してインサイトを導き出すのだが、そのアウトプット、ツールとしてUXMなどを用いる。

・「〇〇は△△だから、××かもしれない。」というスタンス。

プロダクトマネーシャーの仮説検証メモ

サービスのキーが”ヒト”であった場合、どう仮説検証するか。（※以下、リソースマネージングを想像しながらお話を伺ってました。）

ヒトが運用のキーとなるサービスは、デジタルで完結するサービスよりも属人性に頼る部分が多く、プロセスの絶対的データを取るのが難しい。

本人による説明(発言)と行動は必ずしも一致しない。（全然勉強してない～っていう子はだいたいめっちゃ勉強してる説。笑）

検証工程において、事実確認は時系列を意識してヒアリングする。その後に実行動として残るメールのやりとりや電話応対の場に同席するなど、"追跡"を行う。

仮説検証の振り幅がかなり大きくて大変だけど、それを楽しいと思えることも大事。

所感

普段のお仕事の中でエンジニアさんと話していて、「デザイナー的にはこの1ページ全体でバランスとって考えてたのに、その1部だけ切り離してリリースされちゃうの！？」とか、そもそもサービス開発初心者なので戸惑う部分が多々ありましたが、"小さく検証を繰り返す"の意味がようやく理解できた気がしました。

フレームワークやアウトプットの形式は様々あるけれど、個人的にはこれらを作り出す過程に価値があると思っているので、事業サイドの関係者をどうこのプロセスに巻き込んでいくかが個人的には課題だなと思ったり。