相関と因果のがいねんと、マーケティングとの関係について、わかりやすい例を上げて考えてみた
とりあえず
この前は最後にしたけど、とりあえず告知的なのを最初に書いておく。告知することがないと、blogを書く気にならないのは自分でもどうかと思うが、まあ仕方がない。
- 日時：2016.04.22(金)
- 値段：¥1,000 + Drink (2D ¥1,000/飲み放題 ¥2,000)
- 場所：高円寺CLUB LINER
- その他：ローストビーフ丼とお菓子が食べれるらしい。多分僕は20時くらいからだけど、飲み放題だから、適当に来てずっと飲んでいればいいと思う。
「金曜日だから」「酒飲みたい」くらいの、各人にとって都合のいい理由で遊びに来てくれたら泣いて喜ぶ(出演者も飲み放題っぽい、ただただ楽しみｗ)。
はじめに：“がいねん”について
「数式を並べるんじゃなくて、概念を説明してほしい」的なことを言われた経験がある、いわゆる理系な人は僕だけじゃないはずだ。概念の辞書的な意味は
①同類のもののそれぞれについての表象から、共通部分を抜き出して得た表象
②対象を表わす用語について内容がはっきり決められ適用範囲も明確な意味（岩波 国語辞典）
なので、一般化された数式ほど概念を伝えるのに適した表現方法もないのになぁとずっと不思議だったのだけど、就職活動をしている辺りで僕は気づいた。どうやら、「概念を説明して欲しい」というのは、「抽象化された数式は難しくて理解できないので、具体例を上げて説明してほしい」という意味で日本のサラリーマンの中で用いられる隠語だ。初めて見る数式を、すぐに理解できないことなんて、（少なくともそんなに数学が得意じゃない僕にとっては）日常茶飯事のことなのに、なんでこんなわかりにくい表現を使うんだろ？バカだと思われるのが嫌なのかなぁ・・・？誰もそんなこと思わないと思うんだけど。
ということで、不幸な誤解を避けるために、この隠語を以後“がいねん”と表記し、辞書的な意味である概念とは明確に区別することにする。とても大切なことなのでついでに書いておくと、数式の「見た目の難しさ」と「（辞書的な意味での）概念の難しさ」は何の関係もない。特殊相対性理論の質量とエネルギーの等価性を示す、"E=mc^2"の見た目はとても簡単だけれど、その概念を僕は理解できない。
マサカリを投げられても困るのではじめに断っておくが、僕は数学的に正しく伝える気は全く無い。ちゃんと概念を理解したい人は、数式が載っている本なりwebページを参考にしてほしい。
相関と因果の“がいねん”について
相関と因果の関係
このエントリでは、「片方の数値が変化すると、もう一方の数値も変化する」関係を相関と呼ぶことにする。また、「片方の数値の変化が原因で、もう一方の数値が変わる」という関係を因果と呼ぼう。
こう書くと、紛らわしいし、相関と因果って似てるのかな？と思う人がいるかもしれないが、この２つは全く別の関係だ。簡単な例を出して説明したい。
「傘を持って家を出る人の割合」と「その日の降水確率」
この２つには、相関がある。傘を持って家をでる人の割合が多い日は、降水確率がきっと高い。逆に、降水確率が高ければ高いほど、多くの人が傘を持って家を出るだろう。因果かどうかは、傘を持って家を出る人の割合を増やしたらどうなるかを考えればよい。もし「因果かも！」と思えた人は、一刻も早く「世界の水不足に悩む地域で、傘を持って家を出る人を増やす」という活動をはじめていただきたい。勘違いのしようがないくらい、相関と因果は異質なものだ。
ちなみに、「相関関係であって、因果関係ではない」ということはとても簡単に起こる。例えば、「同じように増加する2つの指標」には全部相関がある。ちょうどいい例があったので載せておく*1と、「自閉症(Autism)とオーガニックフードの売上(Organic Food Sales)」には以下の様な関係がある。
相関係数（どれくらい相関があるか、という数字。1に近ければ近いほど相関がある）は0.9971。素晴らしい。なんでこんな相関があるかは分析するまでもなく、つまり偶然だ。
因果は相関と別にある
せっかくなので、今度はマーケティングに役立ちそうな例題でも考えてみよう。
[問1]
ある広告と、ある商品の購買に相関がありました。その商品をもっと売るには、どうすればいいでしょう？
[問2]
あなたは居酒屋の店長さんです。常連さんを観察したら、あるメニューが大人気であることがわかりました。
そのメニューをお客さんみんなにオススメしたら、常連客は増えるでしょうか？
何も考えずに、「相関があるから簡単だ！」と思ったマーケッターのみなさんは、明日にでも「世界の水不足に悩む地域で、傘を持って家を出る人を増やす」というキャンペーンを始めてほしい。大丈夫、きっとうまくいかない*2。
大切なのは、問題の難しさを理解することだ。散々書いてきたように、相関は因果を教えてくれない。月の満ち欠けと潮の満ち引きに相関があることは昔から観察結果として知られていたが、それが万有引力で説明された*3のはずっと後のことだ。ここで重要なのは、ニュートンが見ていたのは“木から落ちるりんご”であって、月でも潮でもないということだ（ここでは文章のテンポとリズムを優先して、こういう書き方をしているが、正直なところこの表現は僕の真意ではない*4）。相関から因果関係を説明するには“明確な理由”が他に必要で、「相関があるから」と言うのは理由にならない。広告と購買にも、常連さんに人気なメニューも、何か別の理由で因果を説明できてしかるべきだ。例えば「カメラを構える宮崎あおいがかわいい」とか、「そのメニューが安くて美味しい」とか。
最後に
結局のところ何が言いたかったというと、僕がブログを書く頻度と、歌を人前で歌う日程*5には相関があるということだ。
新譜も出るみたいなので、今日は相対性理論の「LOVEずっきゅん」でお別れです。
*1:以下よりありがたく引用させていただく。
こんなのもあった。海賊の減少が、地球温暖化の原因という説があるらしい。さすが空飛ぶスパゲッティ・モンスター教は奥が深い。
*2:かつてないほど煽り口調なのは、某K氏から、前回のエントリ
について「大人しすぎる」「もう少し煽ったほうが面白いのでは？」というありがたいfeedbackを頂いた事による。
*3:もしかしたら知らない人がいるかもしれないから、国立科学博物館の「宇宙の質問箱」を貼っておこう。対象読者をどれくらいの層に設定しているかわからないけれど、とても科学に対して真摯な説明だった。さすが。
*4:言いたかったこと以上のことが
に記載されていたので、ここではこれをありがたく紹介するに留める。
*5:冒頭にも書いた。
- 日時：2016.04.22(金) きっと20時くらい
- 値段：¥1,000 + Drink (2D ¥1,000/飲み放題 ¥2,000)
- 場所：高円寺CLUB LINER
データサイエンティストの憂鬱と退屈
お久しぶりです、サボってました
前回書いた記事
の予想外のPVに満足（補足する必要すらないと思うけど、たいした数じゃないし当然自己満）して、その後サボり続けた。少し前に50回以上続く由緒正しき勉強会 データマイニング+WEB ＠東京 、通称Tokyo Webminingで、同じようなテーマで発表したので*1、今日はそれを掘り下げて書いてみる。ちなみにTokyo Webminingで使った資料は、我ながらよくまとまっていると思っている(当然こちらも自己満)。
もちろん、この「憂鬱」と「退屈」の解決法も同時に提案できれば素晴らしいんだけれど、この手の問題は「相手に理解してもらうこと」自体が解決に向けての小さいけれど大きな一歩、だと僕は信じている。
はじめに：「データサイエンティスト」について
この呼び方が一般的なのかどうかよくわからないし、僕自身はもうそうではない（でも、隣で仕事をしていた人は多分そうだ）。ただ、一般社団法人 データサイエンティスト協会っていう協会*2があるくらいだから、ある程度認知はされているだろう。このエントリでは単に「データ分析を生業にする人」という意味でこの言葉を使う。
当然、データサイエンティストの仕事は以下に述べる憂鬱と退屈を補って余りある魅力とやりがいがあることを、まずはじめに断っておきたい。
データサイエンティストの憂鬱
勉強会でも触れたが、データサイエンティストは特に下記の点で日々憂鬱だ。
- 「顧客がほんとうに必要だったもの」が曖昧
- 「価値の進捗」が顧客から見えにくい
- 日本人は確率と統計に疎い
顧客がほんとうに必要だったもの
ニコニコ大百科の「顧客が本当に必要だったものとは 」がとても詳しいので、ここではかの有名なイラスト*3を貼っておくに留める。
何となく不自然な気もするが、システム開発において「要件定義 (Requirement Definition)」はエンジニア、つまり作る側の仕事だ（参考：要件定義とは： IT用語辞典）。すごく簡単に言えば「顧客が本当に必要な物」を定義する工程で、ある意味必ず失敗するのは上のイラストで察してもらえると思う。僕は、「できる限り手早く片付けて、致命的でない失敗する」ことが要件定義のキモだと考えている（もし間違ってたら、Twitterか何かで優しく教えて下さい）。
開発よりデータ分析でこの工程が憂鬱なのは、顧客からほとんど要件を説明されないことに起因する。開発の時は、少なくとも「作ってほしいもの」は顧客から説明される。一方でデータ分析の場合、少なくとも僕の知っている限りこんな感じだ。
- 売上（もしくはそれに類するKPI）を上げたい
- PDCAサイクルを回したい
最悪な場合
- データを見て何か提案して欲しい
という要件が来たりする（これを要件と呼んで良ければ、だが）。ちなみに、この「最悪な場合」は少なくない頻度で起こる。開発の時以上に、要件定義が辛く苦しい工程になるのは想像に難くないはずだ。
「価値の進捗」が顧客から見えにくい
顧客は、待つのが嫌いだ。逆に言えば、「すぐ価値が提供される」というのはそれだけで価値がある（例えばファストフードやAmazonの「お急ぎ便」がそうだ）。僕は学生時代、居酒屋でバイトしていたけれど、「お通し」の仕組みは本当に偉大だと思う。こいつのおかげで相当数のクレームが未然に防がれているはずだ。もちろん、“ファーストドリンク”は他の注文より優先して提供する。その点で、データ分析作業は宿命的なハンデを抱えている。
基本的にデータ分析は
- 要件定義
- データ収集・データ加工
- 分析
という工程を追う。1. が難しい話はすでに述べたが、2の「データ収集とデータ加工」も相当に厄介だ。簡単に言うと「レシートを集めて、家計簿をつける」作業なので、ただひたすらに面倒ということを除いても、以下の点で辛く苦しい工程なのはわかってもらえると思う。
- レシートを貰い忘れる、もしくは無くすリスクがつきまとう
- そもそも、「レシート」が貰えない場合がある
- 大抵、どこかで数値が合わなくなる
しかし、この工程の本当の憂鬱さは違うところにある。それは、「家計簿をつけただけではお金はたまらない」という周知の事実だ。データを集めて加工しているうちは、顧客に価値の進捗が見えない。
この間顧客は「待たされている」と感じるだろうし、分析している側も「待たせている」自覚があり、そのストレスに苛まれる。
日本人は確率と統計に疎い
「日本人は確率と統計に疎い」というのを、僕は常々思っていて、これには明確な理由がある。それは、高校後半まで習わない上、大学受験で捨てても良いからだ*4。データを分析したり、その結果を解釈したりするには
- 確率と確率分布
- 相関と因果の関係
を理解していることが必要だ（確率分布ついては、また近いうちに別エントリに書く。相関と因果についてはこちらに書いた。）。ところが、大学入学者選抜大学入試センター試験実施要項を見ればわかるように、
『数学Ⅱ・数学B』は，「数学Ⅱ」と「数学 B」を総合した出題範囲とする。 ただし，次に記す「数学B」の3 項目の内容 のうち，2 項目以上を学習した者に対応した出題とし，問題を選択解答させる。
[数列，ベクトル，確率分布と統計的な推測]
つまり、これらを扱うのは高校数学Ⅱ・Bの、しかも選択問題の範囲だ。学生でも数学Ⅱ・Bを得意とする人はそんなに多くないだろうし、そもそも数学Bをがっつり履修するのは、いわゆる進学校で、かつ理系に限られている気がする。
データ分析の顧客は文系の人の方が多いくらいなので、「正しく分析結果を伝える」には、少なくとも高校の数学を教える程度の手間は惜しめないことになる。
恥ずかしい話だが、僕も確率分布を明確に意識したのは、大学で機械学習を勉強したタイミングなので、この辺りの理解が曖昧な人がいることを攻める気は全く無い。学校で習う、ほとんどのサイコロの出る目は「同様に確からしい」のだ（当然ながら、現実はそんなに単純ではない）。
データサイエンティストの退屈
個人的に、データ分析はある意味で「退屈」な仕事だと思っている。僕はかつて、尊敬する先輩に
データ分析の価値は、その分析結果を元にした意思決定が創出する価値によって決まる
と教えられて、まさにそうだと思っている。手段こそ違えど、データサイエンティストの顧客が求めているのは、占い師のアドバイスとそれほど変わらない。
さて、人がデータ分析の結果を重要視するのはどんな場合だろうか？きっと
- 自分では答えを出せない、もしくは出したくない場合
- 自分の判断の正しさを客観的に示したい場合
- その意思決定が自分にとってそれほど重大ではない場合
のいずれか、もしくはその組み合わせだ。本当に「なんとなく」なんだけど、僕はこの「3」が結構重要なファクターじゃないかと思っていて、その意味でデータ分析は退屈だ。
意思決定において、ランキングとかレビューの星の数と言った「客観的なデータ」をどの程度重視するかは、興味とかこだわりに大きく左右される。音楽が好きな人はオリコンのチャートを追いかけないし、本当にコアな部分は、ABテストする時点ですでに決定している。物件選びで内見するのは、その意思決定が「データではない何か」を気にするくらい重大だからだろう。
誤解されたくないのでしつこいくらいしっかりに書くが、ここで言っている“重視”は、あくまでも「意思決定において、データをどの程度重視するか」という意味で、「そのデータで、意思決定がどれくらい正しいものになるか」ではない。
結局のところ、データ分析をありがたがってもらえるのは「顧客にとってそれほど重大ではないことが多い」というのが、僕の感じた、ちょっとした退屈だ。これは段々変わっていくのかもしれないし、変わっていって欲しい。
最後に
「そろそろ人前で歌いたいなー」と思っていた矢先に、飲放題付きで参加費3000円という、願ってもないイベントに誘われたので、ふらっと出ることにしましたｗ
- 日時：2016.04.22(金)
- 値段：¥1,000 + Drink (2D ¥1,000/飲み放題 ¥2,000)
- 場所：高円寺CLUB LINER
- その他：ローストビーフ丼とお菓子が食べれるらしい
金曜日なのでとりあえず飲み食いしたい人、早く帰る言い訳がほしい人お待ちしています。遊びに来てください。
では最後に、月曜日で憂鬱なみなさんにNew OrderのBlue Mondayをお送りいたします。今週も頑張りましょう。
*1:主催の方が丁寧なまとめ記を書いてくださっているので、興味がある方はそちらも是非目を通していただければと思う。
*2:この協会は、以下のようにデータサイエンティストのスキルセットを定義している。「データサイエンティストに求められるスキルセット」に”データサイエンス”という部分空間があるのは、個人的には解せない。
なお、完全に余談だが、下記のWebページのfaviconを設定してほしいとずっと思っている。
*3:調べたけれど、結局正確な出典が分からなかった。知っている方がいらっしゃったらTwitterか何かで教えて下さい。
*4:偉い人が今の入試制度をどう思っているか知らないが、僕が今でもきちんと覚えているのは、結局のところ受験の為に「詰め込んだ」科目ばかりだ。大学以降は一概にそうでもないが。
安保法改正とSEALDsに対する当たり障りない感想と、技術的負債の話
はじめに
このエントリの「当たり障りのなさ」を担保するために、以下のことを確認しておく。
このエントリの目的
このエントリの主眼は、あくまでもライブ告知だ。
- 10/18 18:00 op, 18:30 st @下北沢ラグーナ
- しゅう (@shoe116) までご連絡いただければ ¥1000(D 500別)で入れます
- 詳細は もしもしセカイ — schedule をご確認ください
これが伝えられれば、とりあえず満足だ。
安全保障関連法案と、このタイミングについて
正直な話、僕は「こうするべきだと思う」という意見を論理的に発信できるほどちゃんと理解していないので、法案が通るまでこのテーマでBlogを書くのを保留していた。でも、今回の”騒動”はそんな無知なWebエンジニアから見ても興味深いことがいっぱいあったので、今更感があるのを自覚しながら以下の2つの観点でBlogを書いてみる。
- 一連のゴタゴタと、いわゆる「技術的負債」の関係
- SEALDsに対する共感とデモに対する違和感について
法案が国会を通過して一週間も経って、大学生の夏休みも終わって、しかも福山雅治が結婚した今なら、もう当たり障りもないだろう。
一連のゴタゴタと「技術的負債」の話
技術的負債 (Technical debt)という言葉を聞いたことがある人はどれくらいいるのだろう？Martin Fowlerという人の"TechnicalDebt"という解説がわかりやすくて好きなんだけれど、当然英語で書かれている。恥ずかしいことに僕は英語がそれほど得意ではないのだが、Martin Fowler's Bliki (ja)という、有志の方々による素敵な日本語訳がGitHubにあるので、その該当ページ「技術的負債」からありがたく引用させていただく。
システムに新しい機能を追加するとしよう。2つのやり方があるはずだ。ひとつは、早いけれど、ぐちゃぐちゃになるやり方（将来、変更が困難になることは分かっているよね）。もうひとつは、キレイな設計だけど、導入に時間のかかるやり方。
「技術的負債」とは、Ward Cunningham が作ったメタファーである。上記の問題について考える際に、この言葉が役に立つ。このメタファーを使うと、早いけれど汚い解決方法は（ファイナンスの負債と同じく）技術的な負債が発生する、ということになる。 通常の負債と同じく、こちらの負債も利子を払う必要がでてくる。 早いけれど汚い設計を選んだせいで、将来の開発において余分な労力をさかねばならなくなる、というわけだ。 これからずっと利子を払いつづけていくことも可能だし、 リファクタリングによって良い設計に修正し、元本を減らしてしまうということも可能だ。 もちろん元本を減らすのにはコストがかかる。
憲法9条と安全保障なんて技術的負債そのものだ。「キレイな設計」、つまり憲法改正をしないで自衛隊を作ったせいで、それ以後の安全保障周りの機能拡張には常に「余計な労力」を割く羽目になっている。もちろんリファクタリング（憲法改正）によって元本を減らすことも選択肢の一つだが、それには膨大なコストがかかる。今の日本にそのコストが払えるかどうか、僕にはわからないけれど。
誤解してほしくないのは、はじめに「キレイな設計」をしなかったのが悪いと言っているわけじゃないということだ。技術的負債より、リリースまでのスピードを優先しなければならない案件なんて腐るほどあるわけで、多分日本の安全保障はずっとそうだったんだと思う。
もちろん、そんなやり方を繰り返して拡張してきたシステムの可読性は下がるばかりなので、「今となっては、ちゃんとは誰も把握しきれていないけれど、とりあえず（少なくとも致命的な）問題なく運用出来ている」という状態が出来上がる。一度こうなってしまうと、システムのメンテナンスできる人は限られてくる。憲法9条の元で集団的自衛権の議論とか立法ができるなんて、僕の理解が及ぶところではないし、当然どれだけ説明されてもわからない。だって、可読性が低すぎるんだもん。
しつこいようだが、僕はそれが一概に悪いとは思っていない。「速度を優先する」という選択を繰り返してきたシステムが、適切なタイミングでリリースされ、ちゃんと売上に貢献しているのを僕は何度も見てきた。
SEALDsの共感とデモへの違和感について
別に僕はSEALDsの主張やデモという表現手法に対して、正しいとか間違ってるとか、素晴らしいとか頭が悪いとか言いたいわけではなく、あくまでも僕が個人的に感じたことを書く。
SEALDsに対する共感
安全保障の問題は、法治国家である日本国における技術的負債だ、ということはすでに述べた。これは、SEALDsのWebページ冒頭の
私たちは、戦後70年でつくりあげられてきた、この国の自由と民主主義の伝統を尊重します。そして、その基盤である日本国憲法のもつ価値を守りたいと考えています。この国の平和憲法の理念は、いまだ達成されていない未完のプロジェクトです。
というメッセージと矛盾しない。これはそのまま、日本の平和憲法の理念には「70年分の技術的負債がある」ということだ。先人たちは、「アメリカが日本の武力解除を目的として作った平和憲法の元で、そのアメリカと事実上の軍事同盟を結ぶ自衛隊を持ち、なおかつ民主主義を維持する」という信じられないようなプロジェクト運営を行ってきた（書いていて、これぞhack！という感じがする。きっとどのhackathonに出ても優勝だ）。
僕は、今回の彼らの主張は
- わかりにくすぎる、ちゃんと説明しろ
- なんでお前らだけで決めるんだ、本当に必要なのか？
- 改正するリスクが大きすぎる
だと理解していて、これについてはもうそのとおりだ。僕も、何度も思ったことがある。
- 設計もコードもカオス過ぎる。1から書き直したい、時間ないけど。
- これに機能追加するの？無理矢理過ぎる、なんで今更？
- デグレのテスト不十分だから、事故っても知らないよ・・・
技術的負債を目の当たりにした人の、至極真っ当な感情だ。
デモに対する違和感
その一方で、デモを見るたびになんとも言えない違和感を感じる。軽蔑や嫌悪感と言ってもいいかも知れない。別にこれはSEALDsに関してだけではないし、そのデモの主張に自分が賛成か反対か、ということもほとんど関係しない、「デモ」という表現方法そのものの話だ。この理由がイマイチ自分でもはっきりしていなかったんだけれど、この違和感はどうやら「デモの主張が、僕にはわかりやすすぎる」ということに起因しているようだ。
以前「エンジニアが日々何を考えているか、ということ」というBlogでも書いたけれど、『ソフトウェアアーキテクトが知るべき97のこと』という有名なエッセイ集*1のなかに
というニール・フォードさんのエントリがあって、僕はこれを座右の銘としてエンジニアをしている。
どう考えても「平和憲法の元で、自衛権の話をする」と言うのは本質的な複雑さだ。もちろん、できる限り単純にしたいところだが、前述の通り技術的負債のためにそれも相当に難しい。しかし、だからといって「本質的な複雑さ」を付随的な複雑さとして取り除くのは本末転倒だ。大勢で「戦争法案反対！」と叫ぶ姿は、その本質的な複雑ささえ取り除いてしまっているように、少なくとも僕には見える。「TPP反対！」も「原発反対！」もそうだ。どの主張も、解決すべき問題の複雑さに比べてあまりにも単純で、わかりやすすぎる。これが僕がデモに対して抱く違和感の正体だ。
この過度な単純さは、おそらくデモという表現手法の制約だ。みんなで集まって効果的にメッセージを発信するには、内容は出来る限りシンボリックな、単純化されたものにするしかない。本質的であろうが付随的であろうが、複雑さはすべて取り除く。考えてみれば、ほとんどのデモの主張は「OO反対！」なわけで、逆に言えば「建設的な対案を論理的に主張する」みたいなことは、デモでは難しいということなのだろう。
結局何が言いたかったか
はじめに書いたとおり、これはライブ告知*2を目的とした「技術的負債に苦しんだことのあるエンジニアの当たり障りのない感想文」で、それ以上でもそれ以下でもない。
そういえば敬愛するGreen Dayのビリー隊長がlive "Bullet In A Bible" のholidayのイントロで叫んでいた
This song is not anti-American, its anti-war.
という言葉をふと思い出したので、そのlive動画を貼ってそれで終わりにしようと思う。
ではでは10/18、お暇でしたら是非下北沢まで遊びに来てください！
*1:
CC-by-3.0-USというcreative commonsライセンスに準拠して、webでも読める。エンジニアじゃなくても楽しめると思うし、エンジニアが如何にエモい人種かが垣間見えると思う。
xn--97-273ae6a4irb6e2h2ia0cn0g4a2txf4ah5wo4af612j.com
*2:
ライブ詳細
学生時代の友人のギタリスト・現フィドラーのkatsu氏も一緒に出てくれます。
- 日時：10/18 (sun) 18:00 op, 18:30 st
- 場所：下北沢ラグーナ (DaisyBarの1階)
- 費用:しゅう (@shoe116) までご連絡いただければ ¥1000(D 500別)
-
この前のライブ音源がsoundcloudで聞けます
詳細は もしもし世界？ — schedule をご確認ください
