データ分析のサポートやフォロー
データ分析にあたっていくつかサポートやフォローが必要になります。先ほど説明したドキュメンテーション整備もサポートの1つに該当しますが、そもそものSQLの入門的な内容の解説やハンズオンによる教育なども有効でしょう。
データ分析は労働集約的なタスクであり、担当者がプロジェクトのボトルネックとなることが多いです。そのために他のメンバーも分散して分析ができるようにしておく必要がありますし、さまざまな視点の分析により新たな視点を持った分析結果が生まれるなどの良い循環が生まれることもあります。また、分析を実施したい場合のレビューなども担うと良いでしょう。
エンジニアが開発する際にGithub上などでコードを修正しPull Requestと呼ばれる工程を経て複数の別のエンジニアにコードレビューをお願いする工程がありますが、データ分析においてもこのような工程により質の高いアウトプットが生まれてくるはずです。これにより、以前にも紹介したようなトンチンカンな集計軸の誤用もなくなることでしょう。
また、ABテストの際の設計のフォローなどもあるとなお良いでしょう。ウェブサービスの場合は厳格な実験サンプルの群を分けることが難しいため、それらの実験方法や仮説の立て方、それらの実験計画に応じたサンプルサイズの設計、適切な検定方法の選択、解釈の妥当性などをフォローできると良いでしょう。よく指摘されることに統計的有意性を出すためにだらだらと実験を続けてしまいサンプルサイズを拡大させ、p値をさげることで有意な結果を求めようとする行為を散見しますが、それは避けたほうがよいです。
多変量のABテストの場合も、直交計画表により実験に必要な条件を減らすこともできるので、それらのサポートなどもできるとなお良いです。
これらの結果を受けてバンディッドアルゴリズム の実装などがあると良いですが、ここはエンジニアとの調整が必要です。
また、因果関係を明らかにする「因果推論」のようにある事象を確認するにはかなりの専門性や手間を有する場合もあります。その時はどこまでの結果が判断できれば意思決定できるのかを決め、それを元に実験計画を立てるなどの現実的な対応が必要でしょう。
機械学習や統計モデリングなどの適用
さて、ある程度習熟してきた組織において、次のステップとなるのは機械学習や統計モデリングの適用です。いずれの場合においても最も大事なことは自身の携わるサービスのどの部分に機械学習や統計モデリングを適用すべきかの検討が必要ですが、ここが最も難しく、最も重要なところです。このタスク設定ができてしまえば、あとは適切なデータを用いて適切なアルゴリズムを選定し、パラメータをチューニングし、汎化性能を検証し、結果を解釈することで適用することは可能です。
ここまでくると、統計学やある程度の数理的な情報を知っておかねばなりませんので、その知識をきちんと理解しておく必要があります。また、チームメンバーにもこれらを促す場合は、勉強会を開催したり、kaggleのようなデータサイエンスのコンペティションに参加したりして経験を積むことが良いでしょう。近年では海外のオンラインコースで学ぶことのできるコースも増えているので、そこで学習をすることも効果的です。また、機械学習や統計モデリングを行う環境の統一もある程度は配慮したほうが良いですが、筆者もまだその段階には踏み込めていませんので、ここでは割愛します。
実データに対して高度なアルゴリズムや統計モデリングを当てはめる場合に注意したいのは、簡単なモデルから始めるということです。
実際のサービスのデータは日々生成されているので、それなりの規模になっています。そこにいきなり高度なモデルを当てはめると現実的な計算時間では終わらないケースが非常に多いです。さまざまなアルゴリズムが出ているものの未だにこれまでのもの(決定木やロジスティック回帰、K-meansなどのクラスタリング手法、リニアなSVM:サポートベクターマシン)が使われているのはこの処理時間に帰着することが多いです。
また乱数を発生させ、確率実験を行なう「モンテカルロ法」などでモデルを組んでシミュレーションする場合も、複雑なモデルを組んで実施してしまうと計算時間が相当かかる上に収束せず、残念な結果になってしまうでしょう。stan(統計モデリングのためのプログラミング言語)などを用いると高度なシミュレーションができますが、モデルの組み方次第ではまったく役に立たないので、注意が必要です。