この記事は、THE GUILD勉強会#3「データ×UXデザイン」の 第１部で登壇された、大竹さん（dely）（@EntreGulss）の講演内容のレポートです。

実際に使われたスライドはこちら↓

では講演内容です。

認知バイアスを回避するためのアイデア検証プロセス

多くのデザイナーにとってはお馴染みでしょう、delyのCTOである大竹さん。delyはレシピ動画サービスKurashiruを運営するスタートアップ企業です。
今回は、Kurashiruを運営する上で得た知見をお話していただきました。

まずはDesign in Tech Reportからの抜粋。今後デザイナーに必要とされるスキルの一覧です。ここでは、デザイナーが今後ビジネススキルなど、オールマイティなスキルを持つことが求められています。
それは何故でしょうか？大竹さんは以下のように考えます。

今、企業の中でデザインの力を使おうとしても、売上に直結しづらいことが障害となる場合が多くあります。それをデザイナー自身で数値（売上）に繋げるようになるために、上記のようなスキルが求められているのです。
そのために、今回のテーマである「データ」がデザイナーにとっても重要になってきます。

delyの方々も通ってきた道だそうですが、データを見る時にいくつかの問題が生じます。

・感覚値でデータを判断し、精度が上がらない
・正のデータと負のデータとを、間違って解釈する
・データを意思決定に不必要なほど細かく見すぎて、時間を無駄にする

そのような間違いを起こさないためには、
「データは意思決定のための材料」
であることを意識し、データを見ることが重要です。そのためにdelyでは
「改善プロセスをフォーマット化して、正しい意思決定ができる仕組み」
をチームに導入しようとしています。

そのために重要なことが２点あると大竹さんはお話されます。

①改善プロセスを整理する

delyでは開発プロセスを、下記のように大きく２つに分類します。

課題発見からプロトタイプ作成、テストまでがデザインフェーズ。これは、アイディアの検証をするフェーズです。
そのデザインフェーズを通ったものを実際に作るのが、実装フェーズ。

今回は、デザインフェーズで何を意識してアイディアの検証をしているのか、に着目します。

大竹さんは改善プロセスにおける要素を「課題事実」「原因仮説」「解決策」の３つに分解しているそうです。
このプロセスを分かり易く表現するために、下記ような表を用意していただきました。（実務では使っていないそうです）

改善プロセスでは、まず何が課題なのかを発見することが重要です。そこに「データを見ることの価値」があります。
例えばKurashiruの改善の場合、ユーザーが食材名を検索したとき、きちんとお目当のレシピにたどり着けているか否かを見ることがあります。

上のグラフでは、緑の折れ線グラフが検索離脱率なのですが、例えば以下のことが読み取れます。
・「ハンバーグ」でキーワード検索した人の離脱率が低い → 検索がうまくいってそうだ
・「豚肉」でキーワード検索した人の離脱率が高い → 検索結果がよくなさそう → 課題を発見しました！

これはあくまで「解釈」ではなく、誰がどう見てもそうだと言える「事実」である必要があります。例えば、なぜ離脱率が高いのかという自分の考えをここに入れてしまうと、後々改善プロセスの軸がずれてしまいます。

次にデータから得た事実から、何故こうなったかを分析します。

・豚肉をがっつり消費したいのに少量しか使わないレシピが表示されている
・今冷蔵庫にない食材を使うレシピばかりが表示されている
これらが原因ではないかという仮説をたてたことにしましょう。

これに対して、解決策を考えます。データを見ることで課題を発見することはできますが、ソリューションは見つけられません。そこはデザイナーとしての引き出しの多さやリサーチ力が効いてきます。

解決策を考えるときには、基本的には以下のような大きく２パターンの方法をとります。

一つは、他社事例からUIの案出しをする。レシピサービスはもちろん、他業種のサービスも調べます。
加えて、デザイン原則という先人の知恵を借ります。特にアプリのUIは限られたデザイン領域であるため、先人の知恵を借りやすい。限られた画面の中でユーザーに、どのようなUIを用いて情報提示するのが良いかのを、ロジック的に考えていきます。

では、仮に以下のように、原因仮説それぞれに対して２つずつソリューション（解決策）が出たとします。

とりあえず課題発見したから解決策を考えて検証する、違ったから事実に戻る、のように行ったり来たりすると、何が事実だったのかが曖昧になったりして、多くの場合良いソリューションが出てきません。
ここまで考え切って整理してから、アイディアの検証に移ります。

②アイデアを検証する

アイデアを検証するためにdelyでは、社内社外含めユーザーテストをメインで行うようにしています。

何故ユーザーテストをするのでしょうか？（上記スライド詳しくはこちら）大竹さんは次のように考えます。

ユーザーテストは
「定性的な検証アプローチでアイデアの大局的な反応を見る」
のに一番適しているからです。

ABテストは、どちらが数値が高くなるかがわかっても、何故そのような結果になったのかがわからないことが往々にしてあります。

ユーザーテストでは、目の前でユーザーに使ってもらうことで、何故そこでよくなかったのか、その場の肌感でわかるのが一番のメリット。
リリースできるほど作り込まずに行えるためスピード感持って進められる上、得られる情報も多いため、アイデアの検証にはまずユーザーテストをしているそうです。

では、表にまとめた解決策についてユーザーテストをしたとしましょう。

例えばユーザーテストの結果、一番左端の解決策が良くなかったとします。

またユーザーテストをすると、そもそも原因仮説が全然違ったということが良くあります。

すると、その間違った原因仮説に対するもう一つの解決策は、テストをせずとも、あまり効果がないことがわかります。

では右の原因仮説にいきましょう。左の仮説に対するソリューションのテスト最中に、右の仮説が正しそうだということが分かったとします。さらに、一番右の解決策が、UI的に使いにくいという難点があったりすると。

解決策が一つだけに絞られました。
これが検証済みのアイデアとして、確度が高いアイデアとして存在するようになります。

そこまで検証した上で、アイデアは実装フェーズに受け渡しされます。

ユーザーテストをすることで、いきなり作ってABテストをするよりも、スピード感もって、自分たちが何故それが上手くいくのか/いかないのかが分かった上で進められます。

「データで失敗するパターン」は、ここで説明されたような改善プロセスを経ることで、以下のように変わります。

・事実（データ）を元に判断しようという動きになる
・目の前でユーザーの行動を見れば、間違った解釈はほとんど起きない
・検証したいことを整理することで、必要以上にデータを見ようとしなくなる

データは意思決定のための材料なので、用法用量を守ることでデータを使うことによってプロダクトをより改善できる開発チームが生まれます。