TL;DR
データサイエンティストはエンジニアではなく、コンサルタントである。なので、エンジニアの延長線上としてデータサイエンティストを考えるべきではない。
データサイエンティストは、「データ分析をすることで、顧客に本当に価値を提供できるのか」を(時にはビジネスサイドよりも)本気で向き合う必要がある。なぜならビジネスサイドはデータの見方に熟知しているわけではないからだ。
課題に向き合うときは、なぜその課題を解決する必要があるのか、から出発して、課題の難易度を下げることに注力しよう。あなたのミッションは難易度の高い問題を解くことではない。
(プロダクションの実装時に)機械学習の手法を採用するデメリットを述べられないならば、特に運用面で他のエンジニアに迷惑をかけることになるだろう。
ちょっと言い方きついですが、へこまないでね 
あくまで、一個人としての意見でありポエムです。
はじめに
いつもは、割とお固めな記事ばかり書いているのですが、年末なので、たまにはポエムもいいでしょう。
何気にIT業界に入って1年生が終わりにさしかかろうとしており、同時にデータサイエンティストを1年やってきましたが、「データサイエンティスト = データ分析とか機械学習の知識が必要」みたいに書いているブログ、記事が非常に多く、個人的に違和感を感じていました。確かに、必要なんだけど、一番必要な素養はそこじゃないんだよなぁ、と。
そこで、その違和感を言語化しました。TL;DRに書いてあることは、強調してもしすぎることはない項目ばかりだと思います。
ちょっと注意) ほぼ完成されたアプリやサービスに対して、ログデータを眺めることで小さな改善を積み重ねる、みたいなことを日常の業務としている方にとっては、いかに述べる主張はあまり当てはまらないかもしれないです。
データサイエンティストのミッションとは
データサイエンティストのミッションは、統計的、あるいは機械学習の手法を適用して、問題解決を図ることではありません1。データを主として、顧客に対して価値を提供することです(あくまで、機械学習は手段なのです)。なぜ、そのようなことを強調する必要があるのでしょうか？？
まず、エンジニアが陥りやすい、間違った(そしてよくある)データ分析のフローを示します2：
1.データの抽出
2.抽出したデータの集計
3.集計したデータによる現状分析
4.予測モデルの構築
5.予測モデルを利用した施策の最適化
間違っているところはなさそうやん？、って思ってしまったら、アウトです。(エンジニアとしてやっていくほうが良いと思います。)
正しくは、こんな感じ。
0. ある課題が見つかった時に、なぜ、それをするか、
その課題を達成することで、顧客に本当に価値を提供できるのかを吟味する。
1. それがデータ分析で解決する類の課題なのか、ビジネスサイドと議論する
(例えば、データ分析できていないことが真の課題なのではなく、単に業務フローの一部がボトルネックなのかもしれない。
または、サービスのUIが悪いことが根本的な原因かもしれない)
2. 0,1を踏まえた上で、ある課題を達成するために、
どのようなアウトプットを出せば良いのかの大枠をビジネスサイドと共有する
3. 課題に対して、仮説を立て、アプローチの大枠を描いておく
(例えば、自然言語処理でキーワード抽出が適切にできれば所用のアウトプットが得られる、とか)
4. その仮説に基づいて、データを取得する
5. 抽出したデータの集計
6. 集計したデータによる現状分析
7. 現状分析した結果、仮説を修正する場合 (初回、2回目はだいたいそうなる)は、0からやり直す。
うまくいっている場合は、8にすすむ
8. 予測モデルの構築
9. 予測モデルを利用した施策の最適化
ということです。
一見、0~2までは、データ分析のお仕事には見えないかもしれないのですが、データの適切な調理方法をビジネスサイドが握っていない場合が結構多いので、「データ分析をすることで、顧客に本当に価値を提供できるのか」を(時にはビジネスサイドよりも)本気で向き合う必要があります。実感として、問題設定や定義が最初から明確であることは、残念ながら殆ど無いです。
3.は何を言っているのかというと、一見すると、時系列分析の問題だったものが、全く質の異なるデータを取得することで、全く違うアプローチで問題がとける場合がある、ということです。
また、よく、4~5の抽出したデータの加工に時間かかるわぁ、っていうのがありますが、0~2に向き合う時間のほうがはるかに長いです。
データの取得、抽出は、仮説を擦り合せる材料にすぎないので、割と後のフェーズですね。それよりも、大まかなロードマップと、その手法のボトルネックとなりそうなところをブレストするほうが先です。
そう考えると、これってもはやエンジニアの領域というよりは、コンサルタントの領域に見えませんか？？
ということで、TL;DRの最初の2つ
データサイエンティストはエンジニアではなく、コンサルタントである。なので、エンジニアの延長線上としてデータサイエンティストを考えるべきではない3。
データサイエンティストは、「データ分析をすることで、顧客に本当に価値を提供できるのか」を(時にはビジネスサイドよりも)本気で向き合う必要がある。ビジネスサイドはデータの見方に熟知しているわけではないからだ。
を説明しました。
問題の本質を理解する
前章のミッションを理解した上で、課題に向き合うフェーズに入りました。エンジニア気質の人ならば、あの新しい手法使ってみたい、とか思うかもしれませんが、難易度の高い問題を解くことがあなたのミッションではありません。アウトプットをビジネスサイドとすり合わせながら、ビジネスサイドが欲しいアウトプットと問題の技術的な難易度とのすり合わせを行うことがあなたに求められています。
つまり、このアウトプットのレベルならば、かなり簡単に解けるような手法が存在するし、十分サービスとして価値がありそうだ、となったら、それを採用しない理由は何一つないのです。問題の難易度を下げることで、得られるメリットは大きく二つあります：
開発工数の削減
運用コストの減少
より複雑なモデルや手法を採用することで、開発工数が増大するのは許容範囲だ、と思われるかもしれません。実際には、運用面でのコストが限りなく増大します。以下、Q&Aを記載します：
問答
Q.ちゃんとドキュメント書けば、きちんと運用できるんじゃない？
A. まず、開発したアルゴリズムの手法は、事細かくドキュメント化できるかもしれませんが、パラメータをどのように決定しているかは、当人も「決めで」定めている場合が多いです。また、複数のフェーズでアルゴリズムが構成されている場合、各フェーズが独立に動作しているわけではないことがほとんどなので、あるパラメータを変化させると、他のパラメータを変化させる必要がある、みたいなことは多いです。そこまでを言語化するのはほぼ無理だと言っていいでしょう。
Q. 検証段階でちゃんと確認して、アルゴリズムの正しさを確認できれば、運用コストはいうほどかからないんじゃない？
A. アルゴリズムのバグがなかったとしても、長い間運用していく中で、データの質が変わっていく可能性があります(というか、かなり高い)。その中で、パラメータを調整するのは秘伝のタレを継ぎ足していくようなものです。実装者が近くにいなかったときは、大変ですね
ということで、TL;DRの後半の二つ：
課題に向き合うときは、なぜその課題を解決する必要があるのか、から出発して、課題の難易度を下げることに注力しよう。あなたのミッションは難易度の高い問題を解くことではない。
(プロダクションの実装時に)機械学習の手法を採用するデメリットを述べられないならば、特に運用面で他のエンジニアに迷惑をかけることになるだろう。
を説明しました。
終わりに
最初、なんか年末だしエモい記事書きたい、と思って書いたものだったのですが、思ったより堅苦しくなっちゃったかも
ちなみに、データサイエンティストと機械学習「エンジニア」を同じものとしてあつかっています。(「」をつけたのは、コンサルタントだぜ、ってことを強調したかったから)
-
手法の適用がメインではない、ということを言いたかった ↩
-
もちろん、ログデータから異なった傾向を発見する(俗に言う、データドリブン)、みたいなことからスタートすることもあると思いますが、漫然とデータを見ていても時間を浪費してしまうので、あんまり意味はありません。 「違いを発見した => 違いの根本的な原因は何なのか頭を捻る(仮説を立てる)」フローが初期の段階で必要だと思います。原因不明なデータの異常があれば、ビジネスサイドと共有、議論する必要があるでしょう。 ↩
-
ここで、エンジニアと言っているのは、技術的な視点からコードを書くぜ、って言う方のことを指しています。例えば、サービスを0から立ち上げるエンジニアも当然いらっしゃるでしょうし、その場合は、そのサービスの意義や顧客のニーズを考えることはマストでしょう(その辺のノウハウは、少なくともqiitaには数多の記事があると思うので..)。ただ、データサイエンティスト、機械学習エンジニアの界隈をざっくり見る限り、手法に偏重しすぎているんじゃね？、と思ったので、あえて言い切った主張をしています。 ↩