誰かの参考になるかもしれないと思って、僕の前職時代の取り組み方や他の現場で僕とよく似たアドホック分析系の仕事をされている方から聞き取った内容をもとに、適当にまとめてみました。
ということで、これは正確には「アドホック分析系データサイエンティストがどうやってデータ分析しているか」のまとめ、です（笑）。ちなみに、僕が既に公開している資料としてはこんなものもあります。
こちらのp.59以降はまさに前職時代に最後に所属していた部署での僕の取り組みそのものを書いたものなので、どなたかの参考にでもなれば。
ちなみにその前に所属していた部署では、普通にHadoopエコシステムベースのBIフレームワークの保守とかやってました。定期集計用のHiveクエリを100個ぐらいズラリと並べたスクリプトを本番環境にコミットしてビルドするとか。。。
今の現場の話は、現職場で始まった本物の公式ブログ（RCO アドテクLabブログ）にでもupしようかと思いますのでそれまでお待ちを（笑）。
ということで、冒頭に挙げたslideshareの資料に大体のところは書いてありますが、もう少し具体的に細かく書いていってみます。多かれ少なかれ、データ分析を企業でやっている人ならほぼ同じプロセスをたどるんじゃないかと思います。
ヒアリング・要件定義・仮説構築
- 「何が」「どのように」「いかなる背景のもとで」問題なのか
- その上で「何を」知りたいのか
を事業部門の人からとにかく根掘り葉掘り聞き出す作業です。ここでしっかり要件定義を固めておくのがデータ分析成功のための最重要ポイントですね。情シス案件と全く同じですが、要件定義がしっかりしてないと大抵デスマになります。
大事なのは「ビジネスの枠組みを踏まえた上で何が求められているのか」を明確にすること。論文書くわけではないケースが大半なので、ビジネスとしてのゴールを第一義に置くように僕は心掛けてます。
なお、ここで僕がもう一つ心がけているのは、「最終的にどういう構造のデータを得て分析したいか」というデータ分析者側の事情をある程度強く押し出すということです。というのは、デタラメなデータを押し付けられて困るのは他でもない自分たちなので（笑）。個人的には、データ分析手法の得手不得手や慣れの問題もあって
- 複数の時系列を並べたスプレッドシート
- 何がしかの目的変数1列に対して、いくつもの列の説明変数が並ぶ回帰分析向けデータテーブル
- 何らかの個々の要素を表現するユニークIDに対して、何がしかの分類フラグ1列といくつもの列の説明変数が並ぶ機械学習分類器向けテーブル
のどれか*1に必ず帰着させるように、事業部門の人とは対話しながら決めるようにしています。1番目は単純なので割愛するとして、2番目なら
| d1 | d2 | d3 | d4 | d5 | d6 | click |
|---|---|---|---|---|---|---|
| 0 | 1 | 1 | 1 | 0 | 1 | 49536 |
| 0 | 1 | 1 | 0 | 0 | 0 | 49541 |
| 1 | 1 | 1 | 0 | 1 | 0 | 49584 |
| … | … | … | … | … | … | … |
というデータテーブルになり、3番目なら
| a1 | a2 | a3 | a4 | a5 | a6 | a7 | cv |
|---|---|---|---|---|---|---|---|
| 0 | 1 | 0 | 1 | 0 | 0 | 0 | Yes |
| 0 | 0 | 1 | 1 | 0 | 0 | 1 | No |
| 1 | 1 | 0 | 1 | 0 | 0 | 0 | Yes |
| … | … | … | … | … | … | … | … |
というデータテーブルになるようにしています。と言うか、これらのどれにも帰着させられない時はやっぱり辛いです。。。
個人的に最も大切にしているのは「目的変数と説明変数をきっちりはっきり決めること」。何をするのかと言うと、要するにこれです。
（データ分析を「させる（依頼する）」側に最低限知っていて欲しい4つの分析コンセプト - 銀座で働くデータサイエンティストのブログ）
この図の中で言うところの「x1, x2, x3,...にどの指標を充てて、yをどの指標にするのかを決める」ことが最重要です。これさえ決まれば代表的な4つの分析のどれも出来るし、おのずとアウトプットのイメージも固まります。逆にこれがいい加減だと、そもそもいかなるモデルを使ったとしてもアウトプットは固まらないし解釈も難しくなります。なので、
というように「yってどれにします？」とはっきり聞くことが大事だったりします。でも、これ事前に決まってないケースって結構あるんですよね。。。この辺は聞く側も聞かれる側もちょっと忍耐が必要なフェーズかも。
データ準備＆取得
ここからが現場によってスピードに差が出る工程です。完全な分析専用DBやプライベートDMPを完備している現場であれば、ここはちょろっとクエリを書いてしまえばおしまいの工程です。そうでなければ、アホみたいに手間がかかります。
クレンジング＆前処理
ここも現場によってはスピードに差が出る工程です。前述の「分析用DB基盤・プライベートDMPが完備している」現場なら、ぶっちゃけデータ出しの時点で同時に全部済ませることも可能です*4。
元データがアクションログの場合、一般に個々のユーザーの行動データの類は匿名化されたユーザーIDに紐付いてこんな感じで記録されているものだと思います。
| user_id | time | action |
|---|---|---|
| 1001 | 2013-11-14 12:00:15 | login |
| 1001 | 2013-11-14 12:05:47 | entry |
| 1001 | 2013-11-14 12:07:39 | comment |
| 1001 | 2013-11-14 12:11:51 | post_comment |
| 1238 | 2013-11-14 15:31:25 | entry_view |
| 1238 | 2013-11-14 15:33:08 | post_entry |
| ... | ... | ... |
これを例えばピボットテーブルにするようなイメージで、あるタイムゾーンに限定して切り出して以下のように直すと思えば合ってます。
| user_id | login | entry | comment | post_entry | post_comment |
|---|---|---|---|---|---|
| 1001 | 1 | 1 | 1 | 0 | 1 |
| 1238 | 0 | 1 | 0 | 1 | 0 |
| ... | ... | ... | ... | ... | ... |
ExcelやAccessでやるという手もありますが、もちろんこれをSQL / Hive上でやってのけることもできます。上記の通り、分析用DB基盤・プライベートDMPが完備しているところならそこで全ての前処理が済んでしまいますので。。。ローカルにファイルをもらってくる場合は、言うまでもなくかなりの手間になります。
なお、ピボットするくらいなら前処理としては楽な方で、例えば特定のキーワードにマッチする投稿だけを抜き出してフラグを立てろとか、MeCab使って単語頻度出さなきゃいけないとか、ネットワーク分析したいのでグラフデータに直せとかになると、言うまでもなくそれなりの工数を食います。NAの対応なんかもここに入りますね。
またローカルでやらなきゃいけない場合に陥りがちなのが「データが重すぎてローカルのスタンドアローンのマシンでは扱えなくなる」ケース。ちなみにAccessではダメだった時に、昔の職場のMGR氏はスケールアップしたサーバに搭載されていたSPSSにリモートでデータを転送して、そこでJOINとかの処理をしてました。。。
手法選択
ぶっちゃけ、これが全てだと思います。改めて列挙してみると、
- 回帰
- 分類
- 推定
- 予測
のどれにテーマを絞るか？ということですね。イメージ的に言えば、
OR 
みたいな軸です。この辺のところは理想的には要件定義のところで既に決まっているはずなので、それぞれのテーマに合わせて選ぶだけです。一般には「自分の得意パターンを持っておく」と良いと思います。この手法で分析するように持ち込めば、大体うまくいく！みたいな自分のカタチに合わせるだけで話が進むので。
ただーし。手法選択のところは割とフリーダムだとは言え、データが出揃ったところで「SVM一発じゃleave-one-out誤差減らないよー」とか「決定木やりたいんだけどジニ係数がアレで全然枝が繁らない」とか「どう見ても正規分布してないから正規線形回帰モデルなんか使えないよ」みたいなことは往々にして起きます。
そこで、適切な分析手法を改めて吟味した上で選定できるだけの、手数の多さも大事なポイントになってくるんじゃないかなと思ってます。
データ分析実行＆分析結果精査
あとは分析するだけです。基本的にはRだろうがPythonだろうが、何でもいいのでとにかく要件定義と手法選択で定めた手順通りに間違いなくやれればOKだと思います。
・・・なのですが、この「間違いなくやれれば」が意外にもクセモノ。ひとたびデータ分析のフレームワークの中に入れてしまうと、初歩的なレベルで言えば「データ型の不整合」「NAの処理洩れ」、キツいレベルで言えば「多重共線性」「系列相関」「ハイパーパラメータの不適切な設定」「分かりにくいオーバーフィッティング」みたいなことが起きていても、気が付かないケースが少なくないのです。
この辺は毎回検証用のプロセスを挟むことによっても解決できますが、ビジネスの現場的に最もお薦めなのは「とにかく場数を踏んで分析結果『だけ』を見て分析の中のミスや間違いはたまたデータの性質上の不具合に気付くように自らのセンスを磨く」だったりします。
へ？そこかよ！とか突っ込まれそうですが、最初にデータテーブルをザッと概観した時点でこれが分かるようになれば、必要に応じて先手を打って型変換したりNAを弾くスクリプトを書いたり、次元削減したり操作変数法とか打ったりはたまた系列相関回避したり、といったことが出来るはずです。この辺の「センス」の重要性はデータ分析の現場であっても大きいと思ってます。
レポーティング
このフェーズですが、大前提として「依頼元＝ビジネス側の視点からのソリューションをまとめる」ものだというマインドセットを持つべきだと思ってます。
すなわち、単に「○○モデルを当てはめて推定したら△△になりました」ではなく、「事業上のクリティカルなポイントである□□について○○モデルの推定結果から××とすべきだと考えられます」のように、具体的なビジネス面でのソリューションになるようにレポートするということですね。
さらに、僕のポリシーとしては基本的にはデータ分析者以外の人に必ずレポーティングに入ってもらうことにしています。理由は簡単で、
- 単純に自分以外の人の方がプレゼンを作るのが上手いケースが多い
- 他の人に入ってもらって第三者としての意見をもらうことで、依頼元が理解しやすいレポートに仕上がる
からです。極端に言えばこれは論文を査読してもらうのと同じで、そういう意味では「レポート・レビュー」と呼んでもよいかもしれません。出来る限り独り善がりなレポートにならないようにするのが大切だと思ってます。
後は、個人的には「表現やニュアンスをどのように変えたとしてもデータサイエンス的に間違っていることは書かないor言わない」というのをルールにしています。色々なところで話したり書いたりしてますが、やはりデータ分析というのは「科学的方法でやるからこそ意味がある」もの。科学的であるということは「客観的な根拠を大切にする」ことでもあると信じてますので、その意味で言えば「客観的な根拠を主観で歪めない」という点は譲ってはいけないと思う次第です。
