「事実」と「解釈」 -プロダクト改善ってなんだろう- 後編
こんにちは、社会人になって早くも1ヶ月経った綾鷹です。
このnoteは、「事実」と「解釈」 -プロダクト改善ってなんだろう- というタイトルで以前投稿したnoteの後編です。
後編では、主に「プロダクト改善とはざっくり言うとどんな業務なのか」「中でもABテストとはどういうものか」「ABテストを行う時に必要な考え方」などについて書いていきます。
一見タイトルにある「事実と解釈」から離れたように見えるラインナップですが、事実・解釈・アクションのサイクルとプロダクト改善は切っても切れない関係にあると私は考えています。
それら二つの繋がりについては後ほど説明していくので、ぜひ最後までお付き合いください。
また、導入として前編のまとめから入っていくので、この後編からでも読めるような内容になっているかと思いますが、前編も読んでもらえるととっても嬉しいです。
ちなみに私のnoteにスキを押すと、ランダムにモン娘が出て来てお礼を言う設定になっています（何を言っているかわからないかと思いますが本当です）ので、ぜひ押してください。
前編のまとめ：事実と解釈の区別
前編では、（特に若手社員の方は）新卒向けのビジネス書や社員研修などでよく耳にするであろう概念「事実」と「解釈」の区別について、いろいろな例を交えつつ「事実と解釈を区別すると何が良いのか」を説明してきました。
前編の一番最初に出したこの変な画像、前編を読んでくださっている方ならきっと見覚えがあるかと思います。
この画像は「事実」と「解釈」の関係をシンプルに表したものです。
詳しく言えば、これは「綾鷹が好きな漫画はこの3冊である」という事実を受けて、友人が「綾鷹はバイオレンス青年漫画が好きなのかな」と解釈している図です。
事実と解釈とは下記のように定義されます。
事実…実際に起こった事柄。現実に存在する事柄。
解釈…物事や人の言動などについて、自分なりに考え理解すること。
先ほどの画像にぴったり当てはまることがお分かりいただけるでしょうか？
事実と解釈を区別することには、「効率が良く、プロジェクトを前進させるコミュニケーションを実現する」という大きな意義があります。
事実と解釈を混同しないよう心がけ、区別し、順序立てて情報伝達することは、ビジネスにおいて非常に重要で効果的です。
事実と解釈の区別は、一見簡単です。
言葉を読み書きできて、話したり聞いたりできるなら、注意すれば誰でも実践できそうに思えます。
しかし「事実と解釈の区別」は案外難しく、だからこそ多くのビジネス書に取り上げられていますし、世の中には「事実と解釈の区別を身につけるためのフレームワーク」も存在します。
そのフレームワークの一つとして、前編では「雲・雨・傘のフレームワーク」を取り上げました。
事実を適切に解釈し、その解釈をもとにアクションを提案する。
「雲・雨・傘」を意識して情報を整理すると、納得度が高く、さらに建設的な議論を喚起する報告や提案ができるようになると言われています。
報連相のしかたに悩んでいる新卒の方には、特に試してみてほしいフレームワークです。（私も普段意識しています）
前編では、この「雲・雨・傘」を使った、良いコミュニケーションの例をより詳しく紹介していますので、ぜひ読んでみてください。
良い「雲・雨・傘」を成り立たせるための、データ収集についての説明もしました。
例えば、データ（＝雲）を集める際には「目的意識を持ちつつ適切な量のデータを取りに行くことを目指すと良い」「定量データも定性データもドリたも大切なデータである」と言う話を取り上げました。
なんで「プロダクト改善」？
前編の内容をまとめ終えたところで、いよいよ後編の内容に突入していきます。
このnoteのタイトルにある、「プロダクト改善」についての話に移ります。
※このnoteに登場する「プロダクト」は、だいたいWebサービスやアプリケーションなどの製品だと思って読んでください。
まず、プロダクト改善とはどんな業務か、想像してみてください。
そして、なぜさっきまで「事実と解釈」の話をしていたのに、プロダクト改善の話に移るのかを、予想してみてください。
ぼんやりとでもいいので、何か想像できたでしょうか？
私の答えはズバリ、「プロダクト改善」と呼ばれる業務の考え方が、事実と解釈のフレームワークである「雲・雨・傘」の考え方そのものであるから、です。
下の図を見てみてください。
プロダクト改善とは、非常にざっくり言えば「すでに世に出したWebサービスやアプリケーションなどのプロダクトについて、より良くできるポイントはないか？とユーザー満足度や自社の利益など様々な観点から分析し、考えうる改善策を日々試していく」業務だと私は考えています。
このことを図にしたものが、上のサイクル図です。
まず最初にプロダクトの現状があり、それを解釈し、解釈をもとに施策を試す。
施策を行った結果、プロダクトの現状は（好転であれ悪化であれ）アップデートされ、それを解釈するとまた別のアクションが浮かび上がってくる。
事実・解釈・アクション、雲・雨・傘を繰り返すサイクルになっているのがお分かりいただけるでしょうか。
このように、「雲・雨・傘」の考え方は、プロダクト改善のフローとそっくり重なるのです。
プロダクト改善の根底に「雲・雨・傘」の考え方がある。
あるいは、「雲・雨・傘」の思考法はプロダクト改善の必須スキルであるといっても良いかもしれません。
先ほどの問いに立ち返ってみます。
なぜさっきまで「事実と解釈」の話をしていたのに、プロダクト改善の話に移るのか。この回答は、
「事実・解釈・アクションの区別をスキルとして最もわかりやすく活かせる業務の一つが、プロダクト改善だから」
です。
私の意図をお伝えしたところで、さらに具体的な業務の話に入ります。
プロダクト改善と呼ばれる業務の中でも代表的な、ABテストについて説明します。
プロダクト改善業務の代表、ABテスト
ABテストの詳しい説明はネット上にたくさん存在するので、「ABテストってどういう業務なの？」はここではシンプルに説明します。
上の図は、ABテストをかなりざっくり図解したものです。
ABテストとは、ある目的に基づいて複数のUIを用意し、どのパターンが最も目的に合致する結果を出すか調査するテストです。
ユーザーを無作為にAパターン群とBパターン群にふり分け、それぞれA案とB案を表示し、A案とB案のどちらがユーザーによりウケたかを調べる、と言うともっとわかりやすいでしょうか。
具体的にテスト内容の例を挙げると、
「“登録する”という文言と、“参加する”という文言のLINE登録ボタンでは、どちらがクリックされやすいか？」
「写真メインのUIと、文字情報メインのUIでは、どちらがコンバージョン率が高いか？」
…こんな感じです。
一つ目の例を取り上げると、このテストは「LINE登録ボタンのクリックを促したい」という目的があり、「その目的を達成するには“登録する”と“参加する”のどちらがユーザーにウケるのだろうか？」という謎を解明するために行われたABテストです。
------------------
テストを行う際、既存のUIに対して、改善案や実験的要素を盛り込んだ方のUIを「挑戦者」とすると、多くのABテストは「既存vs挑戦」の構造で実施されます。
対立構造になっているということは、ABテストには勝敗があります。
ABテストとはどんなものか、の次に説明するのは「ABテストの勝敗」についてです。
先に結論を言ってしまうと、ABテストの目的は、勝つことや、CVRを高めることだけではありません。
「ABテストの勝敗」について話すと言っておきながら、これから説明するのはABテストの必勝法ではありません。
「ABテストの勝敗」という事実を、どう解釈するのかについて説明していきます。
以下に具体例を持ってきました。
まず、とある小さな漫画ECサイトがあるとイメージしてください。
あなたはそのサイトの管理者で、もっと漫画の売り上げを伸ばしたいと考えています。
売り上げを伸ばすには、ユーザーの好みにあった漫画をトップページの目立つ位置に表示するのが効果的ではないか、と思ったあなたは、まずそのサイトに来るユーザーが好む漫画をアンケートで調べました。
すると、このような結果が出ました。
そのサイトに来るユーザーが好む漫画
・AKIRA
・いぬやしき
・亜人（このnote投稿の少し前に完結しましたね）
さて、現状このサイトのトップページには「ONE PIECE」と「鬼滅の刃」が出ています。
あなたは、ユーザーの好みにあっていると思われる漫画を表示してCVRの変化をみる、ABテストを実施することにしました。
⬛︎パターン1：勝った場合
このサイトのユーザーは「鬼滅」のような少年漫画よりも青年漫画を好むと考えたあなたは、「鬼滅」（既存）vs「20世紀少年」（挑戦）のABテストを実施しました。
その結果、「20世紀少年」（挑戦）が勝ちました。
この場合は、「青年漫画の方がCVRが高いことが分かった。テストに勝った！めでたい！」となります。
しかし、それだけではありません。
「このサイトのユーザーは、少年漫画よりも青年漫画を好む」というあなたの仮説が支持されたことになります。
ABテストを実施し、振り返るときには、テスト実施前に立てた仮説が結局のところどうだったのかを忘れずに確認・分析することが大切です。
⬛︎パターン2：負けた場合
今度は、同じ「このサイトのユーザーは、少年漫画よりも青年漫画を好む」仮説に基づいてテストを実施したのに負けたパターンです。
「鬼滅」（既存）vs「ゴールデンカムイ」（挑戦）のABテストを実施しました。
ところが、予想に反してテストは負け。
正確には、「ゴールデンカムイ」の方が「鬼滅」より売れると思ったのに「鬼滅」が売れた、というよりも、「ゴールデンカムイ」を表示してもCVRが伸びなかったのです。
この場合は、「青年漫画はCVRが上がらないことが分かった。テストに負けた、残念…」で終わってはいけません！
ABテストは、負けにも意味があるからです。
負けたからと言って、ただ残念がって分析せずに終わったり、テストをなかったことのようにするのは勿体ないことです。
今回の例でいくと、「青年漫画であることはCV要因ではないんだ、他に何かCV要因があるんだ」ということを、テストを実施して発見できたと捉える方が良いです。
…さて、また長々と漫画の話をしてしまいましたが、要するに言いたいのは、ABテストは「勝ちを求める」業務ではなく、仮説を検証することでユーザー像を一段階明らかにするための業務であるということです。
ABテストは、言葉では「勝ち負け」という風に結果を表現しますが、「CVRが高いUIトーナメント」ではありません。
どちらかというと、ユーザーがどんな人なのかを探り続ける「無限アキネーター」なんだと覚えておくのがオススメです。
私自身、この考え方にはつい最近やっと辿り着いたのですが、「ABテストはユーザー像を明らかにする意味を持つんだ」と知っておくと、テストの結果の分析が格段に深くなりますし、面白くなります。
ユーザー像を明らかにしようとテストを繰り返すと、それによってユーザーニーズの理解が深まるので、ニーズに応じたプロダクトを提供できるようになり、結果的にCVR向上につながる…という状態を目指すと良いと思います。
間違った解釈を防ぐテスト設計
ユーザー理解が深まる良いABテストを行っていくためには、テストの結果を適切に解釈することが肝要になります。
適切な解釈をするためには、間違った解釈を防ぐようにABテストを設計することが効果的です。
ということでここからは少し、間違った解釈を防ぐテスト設計について説明します。
まず、もう一度先ほどの漫画ECサイトの例を思い出してください。
先ほどのテストパターン1では、既存に対する挑戦として「20世紀少年」を表示して勝ちました。
しかし、このABテストには、誤った解釈を引き起こす不備がありました。
それは一体どんな不備でしょうか？
「鬼滅と比べて古すぎ」など様々な異論はあると思いますが、ここでの正解は、「対照実験になっていないから」です。
「鬼滅」と「20世紀少年」とでは、少年漫画と青年漫画である点だけでなく、バトル漫画とSF漫画である点など、異なる点が多すぎます。
そのため、ABテストで「20世紀少年」が勝ったとしても、何が要因で勝ったのか、すなわち、何がユーザーにウケたのかが非常に特定しづらいです。
ABテストを設計する際は、一度のテストで変える事柄は一つに絞りましょう。
そうすれば分析の方向性が一意に定まり、誤った解釈を防ぐことができます。
このことについては、WebコンサルやWebマーケティング調査についての書籍にもよく登場するのですが、もっとシンプルに「変数を絞る」という表現で語られることもあります。
※鬼滅と金カムも全然別物だと思いますが今回は見逃してください…
------------------
補足：変数を絞ることのメリット
「変数を絞る」考え方には、プロダクト改善のPDCAサイクルをより早く回せるというメリットもあります。
上の画像の例では、Aさんはサイトの現状を解釈しないままにあれやこれやと問題のありそうな箇所を列挙しており、変数を絞りきれていません。
そのため、問題を特定するためにまず基本的なデータを整理しなければならず、すぐにはABテストに移れません。
Bさんは、サイトの現状に対して、変数を一つに絞った自分の解釈を持っており、問題のありそうな箇所としてボタンに見当をつけています。
そのため、すぐにABテスト実行に移れます。
どんな課題解決でも、まずは現状の解釈から始め、変数を一つに絞ったテストを設計することが大切です。
これは、よく言われる「仮説思考」「仮説ありきの考え方」に通じるものであり、PDCAサイクルを素早く回すポイントではないかと私は考えています。
おまけ：事実と解釈と心の健康
ここまで長い長い文章を読んでくださり、ありがとうございます。
最後にもう少しだけ、もしかしたらこれまでの中で一番あなたのお役に立てるかもしれないエピソードをご紹介して、このnoteを終わります。
突然ですが、今これを読んでいるあなたは、仕事でもプライベートでもどんな場面でもいいですが、「よくわからないけどものすごくしんどい！！」という心理状態になったことはあるでしょうか。
きっと人間誰しも「よくわからないけどものすごくしんどい！！」経験はあると思います。
私は、最近で言えば、新卒研修期間に何度か経験しました。
あらゆる物事が頭の中でグルグルして、これといって特定の不安の根源はないのに、なぜか漠然と不安な気持ちでした。
この現象も、これまで散々紹介してきた「事実と解釈の区別」によって解消できると私は思っています。
例えば仕事で頭がグルグルになった時、「どこからどこまでが事実で、どこからが私の解釈なのか？」を一度考えて見てください。
事実と解釈を整理してみると、案外追い込まれていないなと気づくことができると思います。
逆に、「これはもう自分ではどうしようもないことだ」という事実にも気づくことができ、それはそれで心を静めます。
「つらいという解釈をしているのは自分なんだから頑張れ」ということではなく、「一度事実と解釈を分けてみると、突破口が見えてくるかもね」ぐらいの感じです。
------------------
…さて、「事実と解釈の区別」はビジネス以外にも応用できるということがフワッと伝わったでしょうか？
ここまでお読みいただき、本当にありがとうございました。
小難しい表現が入ってしまった箇所も多々ありますが、最終的に「事実と解釈の区別って便利で面白いな」ということが伝わっていたら幸いです。
このnoteの元になった勉強会で同期に褒められ、調子に乗ってこんな分量の書いてしまいましたが、私自身の復習にもなり、とてもいい経験になりました。
今後も、今回のように読んだビジネス書の内容を自分なりに噛み砕いた記事はまた書きたいですし、しょうもないネタ記事も書いてみたいなーと思っています。
よかったらまた読みに来てください！
そして繰り返しになりますが、私のnoteにスキを押すと、ランダムにモン娘が出て来てお礼を言う設定になっていますので、ぜひ押してくださいね。
それでは！
このnoteの参考書籍
この記事が気に入ったらサポートをしてみませんか？