2016年最初の記事ということで、もはや1月下旬に差し掛かりつつありますがこちらでは改めて、あけましておめでとうございます＆本年もよろしくお願いいたします。
で、新年一発目のお題は。。。実は似たようなお題で過去にも記事を書いていますが（笑）、年も改まったことなので今一度備忘録的におさらいしてみたいと思います。観点としては、どちらかというと「これからデータ分析のカルチャーを職場に導入していくとしたらどうやってステップアップさせていくか」みたいなところです。なお過去記事はこちら。
この辺の話題を踏まえながら、過去記事リンクのオンパレードで恐縮ですがちょっと一席やってみます。なお以下に挙げる「ステージ」はあくまでも一例であり、業界によってはもっと高度な方向に展開させられる（orもっとプリミティブなレベルに留まる）こともあるので、参考程度に見てもらえればと。
特にここでは「まだデータ分析を始めていない現場」を念頭に置いているので、そこへのデータ分析の導入ステップということでアドホック分析をメインに書いています。システム＆アルゴリズム実装系の話題は最後の最後に出てきます。
1.データをビジネスの「エビデンス（根拠）」とし、「データドリブン」に変えていく
いやそれ大前提でしょ！とこの記事をお読みのどなたも言いたくなるかもしれませんが、ぶっちゃけこれまでデータ分析してこなかった現場であればどこでも「根拠に基づく」(evidence-based)ビジネスをやるとか、「データドリブン」(data-driven)に変えていく、というところがスタート地点です。一方でその意思決定の際にデータをきちんと活用していないという人も少なくないのではないでしょうか。それこそKKD（勘と経験と度胸）だけでビジネス上の意思決定をしているという現場がむしろ多数派かもしれません。
そういう従来の「常識」に対して、昨今の「ビッグデータ」という言葉はある意味「データドリブン」の代名詞として用いられてきた感があります。
「データドリブン」という言葉に冷たい響きを感じる人も多いかもしれませんが、例えば最近話題になった日本酒「獺祭」で知られる旭酒造がデータドリブンな酒造りに取り組み始めたきっかけは、一時的に経営難に陥った時に杜氏に逃げられてしまったから、というエピソードが広く知られています。
ベテランの勘と経験を数値化して全て再現できるなら、データさえあれば新卒1年目の社員でも同じように獺祭を仕込むことができる。。。それが旭酒造の事例が示す凄味だと思います。それはベテランが持つ匠の技を、ベテランが何らかの事情でいなくなった後もデータさえあれば再現できる、ということでもあるのです。
ところで、旭酒造の事例はどちらかというと「ビッグデータ」に基づくものではないようです。言い方を換えると、別に「ビッグ」なデータでなくても良くて、例えば「スモール」なデータでも良いわけです*1。大事なことは「データドリブン」で「エビデンス」になり得るデータをきちんと確保し、それを確実に貯めていくことなのかなと。
そのための特別な基盤として例えばDBであったりDWHがあるというだけの話なので、まだデータドリブンに移行し始めたばかりの現場であればそれこそExcelファイルの羅列であっても構わないと思います*2。いきなりHadoopとか言い出さずに、まずは出来るところからデータの確保と整理を始めましょう。
2.次にデータを集めて「可視化」する
こんなの当たり前じゃん！と思う人も多いかもしれませんが、侮ってはいけません。ただ時系列プロットを並べるだけでも様々なことが分かりますし、場合によっては可視化アルゴリズム自体に特徴があるが故にプロットするだけで重要な意義を見出せることもあります。1番目のステップでデータを確保し貯めるようになったのならば、まずは可視化してみるべきです。
例えば時系列プロットは、季節性や異常スパイクのような特徴を分かりやすく我々に見せてくれます。
エッジリストから成るグラフ構造データは、Fruchterman-Reingoldのような「近しい関係にあるものをより近くに配置するアルゴリズム」で描画することで、例えば人間関係のデータであれば「誰と誰が近しい関係にあるか」を示してくれます。
どんな現場であっても、データ活用は「可視化」から始まります。今や「テクノロジー酒造り」とまで称される獺祭の旭酒造も、そのデータ分析の始まりはただのExcelプロットからだったようです。
このように、可視化するだけでも大きなメリットの得られるデータは世の中非常に多いので、もしExcelシートの類に漫然と数字を並べただけで満足しているのであれば、今すぐとにかくプロットし、可視化するべきかなと。
3.データを比較して「A/Bテスト」する
これまた当たり前じゃん！と思う人も多いでしょうが、意外とちゃんとやってない現場は珍しくありません。ビジネスの現場ではA or Bのような二択を迫られるシーンの繰り返しが多いわけですが、思いの外「これでいっちゃえ！」と最初に思い付いた選択肢のまま突き進んでしまう人も少なくないという。。。
と、猪突猛進する前に一度振り返ってみましょう。最低でもAとBとで結果がどれくらい異なるかを、第2ステップで振り返ったようにとにかくグラフ（プロット）にしてみるべきです。例えばこんな感じに。
現実には単一要因でないことも多く*3、正確を期すならA/Bテストが厳密にはworkしないこともあり得ます。しかし、これまでやったことがないのなら何はともあれ何事もA/Bテストしてみるべきです。そこで初めて分かることも多いはずです。
これを怠ると、例えば「平均への回帰」というややこしい事態に陥ることがあります。現実には自分たちが打った施策と売上・利益との間に何も関係がないのに、見かけ上両者の間に関係があるかのように見えてしまう、一種の計量経済学的な現象です。こうなると、自分たちが正しいビジネスアクションをしているかどうかさえ分からなくなってしまいます。
なので、施策を打ったら売上・利益が上がった！とその瞬間瞬間に一喜一憂するのは危ないということも言えます。これを避けるためには「ベースライン」と「施策を打った後の数字」とをきちんと比べるしかありません。
そういう比較のためにこそA/Bテストがある、というわけです。
ただしそもそもタスクの性質上A/Bテストのしようがない*4現場も少なくないので、そういうところはいきなりステップ5に飛んで良いかなと思います。
4.A/Bテストに「統計学的検定」で信憑性を与える
A/Bテストは意思決定のためには有用なツールですが、パッと見AとBのどちらがより良いかが分かりにくいケースがあります。例えば以下のようなケースです。
このように、現実のビジネス指標には必ず何かしらの「ばらつき」が伴います。こういう状況では人が目でグラフ（プロット）を見てAとBとの大小を見分けるというのは危ういです。それを解決するために、ここで初めて統計学によるサポートを得ることになります。それが「統計学的検定」です。t検定で純粋に期間中のばらつきを加味して大小を比較するとか、カイ二乗検定で異なる分母（e.g.流入総数）のもと分子（e.g.コンバージョン数）の大小を比較するとか、そういう手法選択が必要になってきます。
また、時系列データであればもう少し高度なやり方もあり得ます。Rの{CausalImpact}パッケージによるキャンペーン効果比較などはその一例でしょう。
いずれにせよ、現実のA/Bテストではもはや人の直感では判定できないような大小を比較するケースが多々あり、その解決のためには統計学に拠る必要がある、ということをここでは強調しておきます。
5.「多変量モデル」を導入して同時に複数の要因にアプローチする
ということでA/Bテストを導入している現場は数多いですが、先にちょろっと書いたように要因が2つ以上あると途端に「A/B」という比較の仕方は難しくなります。例えば、あるECサイトのコンバージョン数に寄与し得る要因として、「ある部分その1のUIデザイン」「ある部分その2のUIデザイン」「導線設定（複数パターン）」「外部広告からの流入vs.サイト内検索からの流入」などなど、というように幾つも挙がるようだとその組み合わせを考えているだけで日が暮れてしまいます。
このように、2つ以上の要因がKGIやKPIに寄与していることがほぼ確実で、にもかかわらずそれらの要因の優劣を決めたいというようなケースでは、「多変量モデル」を導入するべきです。特に、ヒトは直感的には1つの要因間での比較しかできないもの。ヒトの直感を超えた2つ以上の要因のミックス同士の比較は、多変量モデルに拠るしかないかと。
下の過去記事で挙げたケースでは、ワインの味わいをアルコール度数やpHといった単一要因から予測するよりも、11項目の化学測定指標から多変量モデルで予測した方が精度が高かったわけです。現実のビジネスでも同じシチュエーションは多数あるはずで、そういう現場ではなおさら多変量モデルの導入を進めるべきだと思います。
そしてここからは統計学のみならず、機械学習の出番が出てきます。一般に、統計学は「線形」*5な関係性に強いものの、そうでないものには脆弱です。一方で機械学習には「非線形」*6な関係性にも威力を発揮する手法が沢山あります。ステップ5以降では、機械学習についても統計学同様に学ぶことをお薦めします。
6.「モデルによる予測（推測）」で未来のアクションや意思決定をサポートする
多変量モデルはそれ自体だけでも大きなメリットがあり、ステップ5で紹介したワインテイスティングスコアに関する多変量モデルの過去記事ではどの化学測定指標がどれくらい（そしてどのように）ワインの味わいに寄与しているかを、しかも互いの指標同士の関係性も加味した上で解き明かすことができるという例を紹介しました。
しかしながら、多変量モデルの凄味はもう一つあります。それが「予測（推測）」です。
つまり、過去の目的変数＋説明変数から成るデータセットを「学習データ」としてモデルを作り上げ、未来の説明変数のデータセットを得ることでそのモデルから予測値を得る、ということができるわけです。特に説明変数が我々の側から「操作可能」なものである場合（例えばサイト施策・広告プラン・UI改善プランなど）は、事前に未来の説明変数を用意することができるので、モデルにただ突っ込むだけで未来の値が予測できます。
その結果が芳しくなければ、未来の（説明変数に紐付く）アクションプランを変更するべきだということが言えます。例えばモデルの予測結果が良くないクライアントに対しては営業が提案するプランを変更するとか、やはり予測結果の良くないwebサービスについてはUI改善プランを変更するとか、そういう使い方もできるでしょう。
そして実は、これらのモデルの良し悪しを決める際にもステップ4で取り上げたA/Bテストを使うことがあります。当然ながら、これだけ統計学や機械学習が多様に進歩した現在では、一口に「多変量モデル」と言っても一通りには決まりません。幾つかの手法を選び、異なるモデルを複数作り上げた上で、最も優れたモデルを実地に投入してみて選ぶ必要があります。その際にもA/Bテストは役に立ちます。
7.「機械学習」とその「システム実装」による自動化を導入し、人手による「アドホック分析」とバランス良く使い分ける
これまでは主に「ヒトのオペレーションをいかにしてデータドリブンにするか」というお題で話を進めてきました。いわゆる「アドホック分析」についての話題です。一方、現実には初めからカスタマーやクライアントに対するアウトプットを機械（システム）に任せていて、そちらの効率化をデータ分析で進めるという現場もあります。これはいわゆる「システム＆アルゴリズム実装」に当たる方向性です。
こちらについては、webサービスを展開する企業ならば既に先に実践していることの方が多い話かもしれません。即ち、実際にweb上で直接接するカスタマーに対して、機械学習に基づく多変量モデルに拠るレコメンデーションや動的コンテンツ生成を通じてアプローチしていく、というような取り組みです。
言うまでもなくwebサービスのように、カスタマーやクライアントに対するアウトプットがシステム化されている場合はこちらの方が有用です。しかしながら、ヒトのオペレーションをデータドリブンにするケースであっても、可能であればシステム実装して自動化する方が合理的であろうと僕は考えます。
この過去記事では、タイムスケールやビジネス規模によってデータ分析の取り組み方を変えるべきだ、というお話をしました。カスタマーと直接やり取りするゾーンではガンガン機械学習でデータ分析によるビジネス改善を自動化し、マーケットレベルでの大局的な取り組みについて意思決定するゾーンでは人間がその都度アドホックに分析し、その中間ぐらいのゾーンでは人手によるアドホック分析と機械学習アルゴリズム実装による自動化システムでバランス良く効率化する、というビジョンです。
これら「ビジネス課題の規模・タイムスケール」に合わせて「統計学・機械学習に基づくデータ分析手法＆実装を使い分ける」ステージに至ってこそ、ステップ1でうたった「データドリブン」の完成形に近付く。。。そう僕は理解しています。
