「事実」と「解釈」 -プロダクト改善ってなんだろう- 前編
21新卒デザイナーとしてついこの間社会人になりました、綾鷹です。
先日新卒研修期間を終え、配属先での仕事にドキドキしているところです。
この記事は、私が新卒研修期間中に、私と同じ新卒の同期に向けて開催した、ミニ勉強会の内容を文字に起こしたものです。
主な内容は、ビジネス書などでよく言われる内容の「事実と解釈を分ける」とはどういうことなのか、そして、事業会社でマーケター・デザイナー・エンジニアとして働くならきっと耳にするであろう「プロダクト改善業務」とはどんな業務なのかです。
noteに起こすに当たって、多少内容を絞ろうかと考えましたが、勉強会に参加してくれた同期から「全部重要な内容だ」という意見をもらったため、勉強会で話した全ての内容を書き起こす代わりに、前後編で書くことにしました。
この前編では、主に「事実と解釈を分ける」ことについて書いていきます。
初めての投稿のため、拙いところもあるかもしれませんが、ぜひ最後までお付き合いください😌
特に「事実と解釈を分けましょう、とは聞いたことがあるけど、実際どんなふうに分ければいいの？」とモヤモヤしている社会人一年目の人に届いたら嬉しいなと思います。
（このnote、およびこのnoteの元になった勉強会の内容は、私が最近読んだビジネス書の内容を私なりに解釈して構成したものです。「それは違うのでは？」という箇所があれば、ぜひコメントでご意見を教えてください。また、私も勉強中の身であるにも関わらず、「〜が重要です」など、やや上からな感じの、教科書的な文体になっている箇所が多々あります。ご容赦ください。）
はじめに：私の好きな漫画
いきなりですが、本題に入る前のチェックインとして（自己紹介も兼ねて）私の好きな漫画を紹介します。
◼︎AKIRA（大友克洋・講談社）
◼︎いぬやしき（奥浩哉・講談社）
◼︎亜人（桜井画門・講談社）
※講談社さんいつもお世話になっております状態
この漫画のラインナップを見ると、それぞれの漫画の内容を知っている人ならこう思うかもしれません。
「綾鷹は“バイオレンスな青年漫画が好き”なのかな？」
実際、これまで私が好きな漫画について話した時、それを聞いた多くの人はこのような印象を受けたようです。
しかし、この「綾鷹は“バイオレンスな青年漫画が好き”なのかな？」という考えは正確ではありません。
別に、私はこれらの漫画を「バイオレンス描写があるから」好きと思っているわけではないからです。
私はこの3冊を、聞き手の推測とは異なるまた別の要因によって好きだと思っているのです。
そもそも「事実」と「解釈」とは？
さて、唐突に本題に入りますが、前に述べた「綾鷹バイオレンス漫画好き説」を用いて最もシンプルに「事実と解釈の区別」を説明すると、下の図のようになります。
なんとなくお分かりいただけるでしょうか。
「綾鷹は『AKIRA』『いぬやしき』『亜人』が好き」という情報は事実ですが、この事実をどう受け取るか、すなわち「綾鷹はバイオレンスな青年漫画が好きなのかな？」という考えは解釈ということになります。
そして、事実は客観的かつ誰にとっても不変のデータですが、解釈は主観を用いて物事を捉えた結果であるため、不変ではなく、また必ずしも正しくはありません。
事実と解釈を分けて物事を考えるためには、まずこの2つの定義を知っておくことが大切です。
（余談）
ちなみに、先ほど挙げた3つの漫画を含めて私が好きな漫画の系統・特徴を言語化するならば、私としては「コマ割りあっさりで描き込みが細かいSF漫画」と思っています。
ところで、ここまでの内容と同じことを私がビジネス書で読んだ時、私は「これぐらい普通に区別できるでしょ…」と思いました。
今このnoteを読んでくれている人の中にも、おそらく同じ気持ちの人はいると思います。
しかし、私はここから先に紹介する内容を知り、世の中のビジネス書や新卒研修でなぜ耳タコレベルで「事実と解釈を分けましょう」と言われているのかを思い知りました。
ここからは、私が思うBAD COMMUNICATION（©︎B'z）の例を交えつつ、「事実を解釈を混同するとどういう不都合があるのか」を説明していきます。
ダメな対話例とその修正例を通して、一見簡単な「事実と解釈の区別」が重視される理由をなんとなく感じ取ってもらえると嬉しいです。
結論、事実と解釈の混同は「非効率」
究極の結論、事実と解釈の混同は「非効率」を生むため、事実を解釈を区別することがビジネスにおいて重要とされている…というのが私の考えです。
どう非効率なのかは、こちらの会話を見て考えてみてください。
上司：この前リリースしたLPの経過どう？
部下：かなり良いと思います。
上司：おー、目標のCV〇〇件ついたってこと？
部下：いえ、それはまだです。
上司：どこに問題がありそうか検討ついてる？
部下：フォームの項目を減らしてはどうかと思いました。
上司：なんでそう思ったの？
部下：スクロール率はまあまあなので、コンテンツには問題ないのかなと。
上司：他の数値も見てみないと何もわからないな…
この会話を一文ずつ見ていくと、事実の確認に解釈で回答していることがわかるのではないでしょうか。（例えば、LPの経過を尋ねられて「かなり良い」と自分の解釈を返答しています）
これでは、今後このLPについて何をどう進めるべきかが見えてきません。
また、最終的に上司は「他の数値を見ないと何もわからない」と結論づけており、LPについてのデータを再確認する手間が増えています。
このように、事実と解釈を混同したコミュニケーションは非効率で、非常にBADなCOMMUNICATIONであると言えます。
では、事実と解釈を混同しないスムーズなコミュニケーションを実現するには、どのように物事を捉えてどのように伝達すると良いのでしょうか。
雲・雨・傘のフレームワーク
事実と解釈の区別を身につけるために活用されるフレームワークの１つに、「雲・雨・傘のフレームワーク」というものがあります。
雲・雨・傘とは、それぞれ下図のように事実・解釈・アクションの関連を分かりやすく例えたものです。
「空に黒っぽい雲が多く浮かんでいる」は事実です。
それを見て頭に浮かんだ「雨が降りそうだ」という考えは解釈です。
その解釈を踏まえて「傘を持って行く」という選択をすることはアクションであるといえます。
この雲・雨・傘になぞらえて情報を区別し、順序立ててまとめると、他者に伝わりやすくて効率的な報連相が可能になります。
また、雲・雨・傘のフレームワークを活用して施策立案などをすれば、どんな事実をどう解釈して施策＝アクションにたどり着いたのかが明確に伝えられるため、議論も円滑になるでしょう。
雲・雨・傘のダメパターン
ここまでやや抽象的な話が続いたので、このセクションでは、雲・雨・傘のフレームワークを用いて、ダメな会話を修正してみます。
具体的にはどんなコミュニケーションが「事実と解釈が区別された良いコミュニケーション」と言えるのか、参考になれば幸いです。
◾︎ダメパターン1：「雨」だけ伝える
先ほど挙げたBADなCOMMUNICATIONを一部抜粋しました。この対話のどこがダメなのか考えてみてください。
上司：この前リリースしたLPの経過どう？
部下：かなり良いと思います。
上司：なんでそう思ったの？
部下：スクロール率はまあまあなので、コンテンツには問題ないのかなと。
場面設定としては、デザイナーあるいはマーケターが、先日リリースしたLPについて話していると想像してください。
この対話に赤ペンを入れるとすると、このようになります。
この会話は、何か質問をされた時「雨が降りそう」＝自分の解釈だけで返事をしてしまうと、論点が見えずプロジェクトが前に進まない、という例です。
上司やチームメンバーに物事を報告するときは、どんなデータに基づき、なぜそのような解釈に至ったのかをセットにして伝えることが重要です。
この会話を、よりプロジェクトを前進させる建設的な会話にするとしたら、以下のように修正するのはどうでしょうか。
◾︎ダメパターン2：「傘」だけ伝える
続いてのダメパターンはこちらです。
上司：どこに問題がありそうか検討ついてる？
部下：フォームの項目を減らしてはどうかと思いました。
上司：なんでそう思ったの？
部下：スクロール率はまあまあなので、コンテンツには問題ないのかなと。
若干受け答えの態度が悪そうな文体になっているのは気にせず、事実と解釈の区別の観点でダメポイントを指摘してみてください。
この対話に赤ペンを入れるとすると、このようになります。
この会話は、部下が「フォームの改修」というアクションを唐突に一つだけ提示しており、上司は意思決定のしようがない…という例です。
私たち新卒のように経験の浅い社員が、決め打ちで一つのアクションを提示しても、上司にとっては「他にもっと良いアクションがあるんじゃないの？」となってしまいます。
それに加えて、問題箇所の特定で合意が取れていないままいきなりアクションを提示しては、アクションの妥当性について議論することができません。
雲・雨も揃えた上でアクションを提案すれば、そのアクションを提案する理由を納得してもらい、さらなる議論を誘発し、プロジェクトを前進させることができます。
こちらが対話の修正例です。
◾︎ダメパターン3：「雲」だけ伝える
ここまでダメパターンを2つ紹介しましたが、実は2つダメパターンを知っただけではさらなるダメパターンに陥る危険性があります。
それが、「雲」＝事実だけ伝えてしまうパターンです。
私の場合、雲・雨・傘について初めて知った時、「解釈だけ伝えてはいけない」「アクションだけ伝えてはいけない」と来て「じゃあ事実＝データをたくさん集めれば良いよね！」と考えてしまいましたが、データは集めれば良いというものではありません。
言い換えると、データを集めることが目的にすり替わってはいけません。
正確なデータを土台にした解釈、そしてそれに基づくアクションを順序立てて説明することが肝要なのであって、データをたくさん提示されても、報告や提案を受ける側はどうしたら良いかわからなくなってしまいます。
ここまでに、3つのダメな対話を説明しました。
雲・雨・傘は、シンプルに言えば事実・解釈・アクションを区別するためのフレームワークですが、雲・雨・傘をそれぞれバラバラで伝えても良いビジネスコミュニケーションは成立しません。
3つの違いを意識しながら順序立てて情報を整理することによって、強力な1つの提案を作るための考え方であるということがお分かりいただけたかと思います。
事実＝データを集める時の心構え
ここで、事実と解釈を区別する話から少し話題を移します。
事実＝データを集める時、ぜひ思い出してほしい心構えを紹介します。
前のセクションで「データをたくさん提示されても困る」みたいな内容を取り上げた直後に言うのも何ですが、雲・雨・傘のフレームワークは、まず適切なデータ収集を行うところからスタートすると言っても過言ではありません。
雲・雨・傘のストーリーは、空に浮かぶ雲を見つける、つまりデータを手に入れるところからスタートしているからです。
上の画像のストーリーを読んでみてください。
このストーリーでは、あなたは空の雲を見て、迷った末に「傘を持っていく」というアクションを選択しました。
少々くどいですが、「雲が多い」という事実（データ）に着目し、それを「雨が降りそうだ」と解釈し、最終的に「傘を持っていく」という意思決定をしています。
では、こちらはいかがでしょうか。
今度は、自分で空を見るだけでなく、テレビをつけて天気予報から情報を得ているようです。
前に出した例よりも、降水確率や雨が降る時間帯など、多くのデータを集めていることがわかると思います。
その結果、「雨が降りそうな雲はあるが、降水確率は低め、かつ降るとしても夜なので、大きい傘を持っていくほどではない。折り畳み傘を持って行こう」という意思決定が可能になりました。
この例のように、データは多く集めるほど解釈とアクションの解像度を高めます。
人によっては、前のセクションで説明した「ダメパターン3：「雲」だけ伝える」を見た後、もしかすると「データを取りすぎるのは良くないことなのかな」と感じたかもしれませんが、データをたくさん集めること自体は決して悪ではありません。
大切なのは、目的を持って適切なデータ収集を行うことです。
どんなデータがあればもっと細かい解釈が可能になるのか、どんなデータを集めればアクションの詳細を詰めることができるのか、といった目的意識を持ちつつ適切な量のデータを取りに行くよう意識すると、優れた雲・雨・傘のセットを作れるようになります。
事実＝データを集める時に大切な考え方はまだまだありますが、ここではもうひとつだけ紹介します。
データに基づいて意見を言おう・提案をしようという時、どうしても「データ＝数字」というイメージに囚われ、データ収集に行き詰まってしまったという経験がある人は、少なくないと思います。私もあります。
私の経験上、「データ＝数字」という誤ったイメージは、「データには定量データと定性データがあり、それらに優劣はない」という考えを頭の中に叩き込むことである程度取り除けます。
定量データと定性データとは、以下のように定義されます。
定量データ…数値として把握できるデータ
定性データ…数字で表すことに適さない質的なデータ
Webサービス改善のための調査行動になぞらえて具体例を挙げると、定量データとは、Googleアナリティクス等を用いたアクセス分析によって確認できるCVRや平均滞在時間のようなデータのことです。
一方、定性データとは、ユーザーインタビューで集めたユーザーの声や、ユーザー一人一人のログデータのようなものを指します。
事実を解釈してアクションを考える際、定量データ・定性データをどちらも活用するのが理想的です。
もっと実践的に言えば、まず定量データを集めてざっくり解釈をした後、数値だけでは測りきれない部分を定性データで補完し、深い解釈ができるまで定量と定性を行き来するという進め方が有効だと考えられます。
その解釈は「仮説」か「想像」か
さて、ここまでで既に5,500文字ほど書きました。ちょっと疲れてきました。読んでくれている人もきっと疲れてきているかと思います。
ですが！前編はこのセクションがラストですので、もう少しだけお付き合いください…！
最後に、「解釈、解釈って言ってるけど、解釈ってよくわからないのよね」というあなたの疑問を解消してから「事実と解釈-プロダクト改善ってなんだろう-」前編を終えたいと思います。
ここまで散々「事実と解釈」について書いてきましたが、実はまだ「解釈とは何か」についての説明があっさりしすぎていました。
前の方のセクションでは、「解釈とは、主観を用いて物事を捉えた結果である」と説明していましたが、これでは漠然としすぎているので、もう少し「解釈」とは何か掘り下げてみましょう。
解釈とは何か、もっと深く調べた結果、解釈には2種類あるということがわかりました。「仮説」と「想像」です。
この2つは、どちらも大切な「解釈」です。
ですが、解釈に基づいて次のアクションを決定するべき時、成果を出せる可能性が高いアクションを導き出すには、どちらかと言えば事実とロジカルに繋がっている「仮説」の方が有用でしょう。
「仮説」に基づいて施策を行っていると思っていたら、実際はかなり論理が飛躍した「想像」から生まれた施策だった…ということは望ましくありません。
（仮説から生まれたアクションしか選択してはいけない、というわけではありません。思いつきや直感的閃きは、時に大きなインパクトのあるアクションの種になります。心理学や認知科学領域では、「洞察」や「創造性」を課題解決に活かすための研究も多く存在します。「想像」はビジネスシーンも含めた私たちの生活において大切なものである、ということはここで補足しておきます。）
仮説も想像もどちらも大切な解釈ですが、上述の理由で、自分の解釈が仮説と想像のどちらなのかを区別しておくことはとても意味のあることです。
仮説と想像を区別して自分の解釈を伝えれば、「まだ想像の域を出ない部分」について追加調査を行い、成果につながるアクションを導く「仮説」へとレベルアップする糸口が見つかるからです。
例えば、下記の対話を見てください。
あるWebサービス運営会社の若手社員が、ページAの直帰率上昇について解釈し、上司に自分の解釈を伝える場面です。
この会話の場合、「ページ来訪の目的をはっきりと持っている層のユーザーに対して、目的とは違う訴求内容のポップアップを出すと、鬱陶しいと感じられて直帰率が上がる」というのはあくまで自分の想像です、とはっきり区別して報告をしています。
そのため、詳しいテスト内容について言及はしていませんが、おそらく上司は「ページ内容と異なる訴求内容のポップアップと離脱率の関連」を調査するためのテスト＝想像を仮説にレベルアップするためのテストをすぐ計画することができるようになっています。
この例のように、「仮説」も「想像」も、区別さえして伝えればどちらも必要な「解釈」です。
言い換えると、すべての「解釈」が、バチバチにロジカルでガチガチにデータと紐づいた「仮説」である必要はないということです。
あるサイトを見て、「このボタン、高齢のユーザーにとってはわかりにくいだろうな」という風に想像力を働かせることがサイト改善において大切であることを思い浮かべれば、想像も大切な解釈であることは理解に難くないと思います。
区別さえできていれば、「想像」もプロジェクトを前進させることができるのです。
前編の軽いまとめ
ここまで読んでいただき、ありがとうございました！
前編では、ひたすらに「事実と解釈の区別」について説明しました。
「ビジネスにおいて、事実と解釈を区別しないと、非効率が生じる」
「事実と解釈を区別して報連相や施策提案をするには、雲・雨・傘のフレームワークを活用するのがおすすめ」
「雲・雨・傘はまず適切なデータ収集からはじまる」
「解釈もまた区別することができ、仮説と想像を分けて伝えることが大切」
これらの内容がなんとなく伝わっていれば嬉しいです。
後編では、事実と解釈の区別とはどういうことかを踏まえた上で、「プロダクト改善」と呼ばれる業務とはどういうものなのかについて書きたいと思っています。
内容は前編（このnote）と同じく、社内で私が行った勉強会を再構成したものにする予定です。
もしよかったら後編も読んでください、よろしくお願いします。
このnoteの参考書籍
この記事が気に入ったらサポートをしてみませんか？