渋谷駅前で働くデータサイエンティストのブログ

元祖「六本木で働くデータサイエンティスト」です / 道玄坂→銀座→東京→六本木→渋谷駅前

アルゴリズム実装=定量的ソリューション、アドホック分析=定性的ソリューション

これは先日うちの教授氏と話していて出てきた話題なんですが、

  • データ分析とは「データドリブンなソリューション」を提供すること
  • アルゴリズム実装=定量的ソリューション
  • アドホック分析=定性的ソリューション


だよね、という。これは結構一般的なコンセプトとして使えそうだなー、と思ったのでちょっと簡単に論じてみようと思います。ちなみにここで挙げられている「アルゴリズム実装」「アドホック分析」という軸に分けるという発想については、


という以前の記事で論じたことがあるので、ご参考までに。ちなみに2012年度中はこの両者はかなりごっちゃにされていたイメージですが、2013年度も下期になってこの両者の区別はどんどんはっきりしてきている気がします。


データ分析とは「データドリブンなソリューション」を提供すること


これだけ「ビッグデータ」だの「データサイエンティスト」だのというバズワードが飛び交ってる中で、わざわざ「データ分析の重要性とは」みたいなことを書くのもアホらしいので書きませんが、前にこんな記事も書きましたよということで。


要は、広告効果改善・集客改善・課金率改善などなど何であれ、事業改善の施策を立案する際に主観的な勘・経験・度胸といったものに拠るのではなく、客観的な数値としてのデータに拠る(data driven)ということです。


その方法は、もしかしたら統計分析や機械学習を駆使するアカデミックなレベルのものかもしれないし、一方でもうちょっとマイルドにBIツールに表示されるサマライズされた売上や利益はたまた費消といったインデックスの上下動を見ながらマーケット知識と合わせて総合的に判断するようなものかもしれないし、現場によってそれぞれだと思います。


ただ、できる限り主観を排除したいということであれば、やはり統計分析や機械学習のような最大限データそのものの性質に基づく方法の方がより適していると言えるでしょう。


アルゴリズム実装=定量的ソリューション


ここからが重要で、まずはアルゴリズム実装のケースで考えてみましょう。アルゴリズム実装で何か事業改善施策を打つというと、よく引き合いに出されるのが*1

  • レコメンデーション(eコマース、キュレーションサービス、集客導線最適化etc.)
  • パターン認識・分類(画像診断、スパム判定、DMPベース広告配信*2etc.)
  • 最適化計画(RTB、ソシャゲの各種パラメータ設定etc.)


あたりだと思います。この辺はズバリ「アルゴリズムそのものが明確に事業を改善する効果を持つ」ものばかりで、基本的には学習データ次第ですが「改善効果を定量的に評価&予測できる」というのがそのメリットです。


特に機械学習系であればその辺ははっきりしていて、既に事業サイドに蓄積されている・蓄積され続けている最中のデータを学習データとして、これを向上させるようなアルゴリズムを作るのが仕事になるわけです。その気になれば、cross validationなどを引き合いに出して改善効果を定量的に示すことも可能です。しかも、パラメータを操作することで改善効果そのものも定量的に操作できるという。


なので、「改善施策そのもの(に関係するパラメータ)も含めて何もかも定量化できる」ようなケースではきっちりアルゴリズムを立てて、事業システムに実装するというのが効果的だと言えるでしょう。


アドホック分析=定性的ソリューション


次に、アドホック分析のケースを考えてみましょう。アドホック分析で何か事業改善施策を打つというと、よく引き合いに出されるのが*3

  • 変数重要度の算出(広告レイアウト最適化、サイト導線最適化etc.)
  • クラスタリング(購買行動に基づく顧客分類、デモグラ情報に基づく顧客分類etc.)
  • ネットワーク分析(オンライン広告アトリビューション分析etc.)


あたりでしょうか。この辺は打って変わって「アドホック分析結果が事業サイドの受け手にとって改善のためのエビデンスとなる」のが特徴で、「改善効果はあくまでも定性的なものとして示される」ものです。


もちろん、中には普通にSVMとか使って直近の未来値の予測を出したりするようなミッションもありますが、そのようなミッションは一度恒常化したらシステムを組んで対処するようになり、以後アルゴリズム実装へと移行するのが通常です。


しかしながら、世の中何でも定量的に示せるものばかりでもないので、「打ち手を選ぶ材料が必要」とか「デザインを変えたらどうなるか知りたい」といったような「そもそも改善施策そのものが定性的」というようなケースでは、ある程度アドホックな分析に基づいてレポートや改善アドバイスといった形での貢献がメインになるのだと思います。


事業内容やその発展フェーズによってどちらのソリューションが必要かは異なる


究極的には「定量的な打ち手が欲しい」か「定性的な打ち手が欲しいか」の二択だと思います。これはどれほどIT・情シス部門が整備された企業であっても、そうでない企業であっても変わりません。むしろ事業内容やその発展フェーズ次第と言っても良いでしょう。


例えばスタートさせてすぐの事業であれば、多分どれほどレコメンデーションなどを強化してもどうにもならないと思います*4。最初のうちはUI/UX改善などをデータドリブンに地道にやっていくぐらいが関の山でしょう。その場合は、アドホック分析で定性的なソリューションを探りながら事業改善していくことになるのだと思います。


一方で、既に何十万何百万ものユーザーがいるサービスを手掛けるのであれば、ある程度自動的にすべての会員に働きかけられるようなソリューションを打ち出していく必要があり、そういうケースでは学習データに基づいて自動的に最適なソリューションを選択するようなアルゴリズム実装が役に立つはずです。


もちろん、どちらにも当てはまらないケースはたくさんあります。ある事業で、既に何百万ものユーザーがいる中で新たなサービスを打ち出したいという場合では、いきなりアルゴリズムを実装して何かしらの影響を全ユーザーに与えてしまうのはリスキーでしょう。そういう場合はまずいくつかテストケースを用意した上でそれに対してアドホックな分析を行い、どういうサービス内容にすればユーザーに好影響を与えられるかを予測し、その結果に基づいてアルゴリズムを立案して実装するという流れになるのが普通かと。


どんなビジネスであれ、定量的&定性的ソリューションの双方を必要とするケースは多いと思われるので、データ分析体制を敷くならどちらも手厚くしておいた方がまぁ良いのだろうと思っているところです。

*1:例は適当です念のため

*2:広義のレコメンデーションと言えなくもない

*3:これも例は適当です念のため

*4:そもそもユーザーが少ないので

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy