データサイエンティストとして「全体知」を獲得するために
はじめに
データサイエンティストと一口に言っても、様々な業務・職種に分かれてきています。
AIや機械学習のモデルをつくるAIエンジニアもいれば、データをシステムや分析基盤でつかえるように加工するデータエンジニア、機械学習のモデルをシステムに組み込むバックエンドエンジニアも、データサイエンティストが関係する職種・業種と言っていいでしょう。
最近では、分析した結果をビジネスで使いやすいように翻訳するビジネストランスレーターと言われる職種も出てきています。
もちろん、どの領域に自身の強みを持たせていくかということは、非常に重要なので、このように分けて考えたいという思いはわからないではありません。
ただ、個人的にはデータサイエンスを分ければ分けるだけ、１つ１つが希薄になってしまっているように感じ、「自分はデータを用いてビジネスについて語れるから、分析は人の任せればいい」といった風潮が少し感じられることに危機感を覚えています。
（これはデータサイエンスに限らないでしょうが、とりあえず今回はそこに絞って話します）
そこで、タイトルにあるデータサイエンティストとしての「全体知」を獲得することを目指して、少しお話をしていきたいと思います。
想定読者
「全体知」を１つの山だと考えると、現在データエンジニアの人の登頂ルートと、データアナリストの人のルートは違ってくるでしょう。
私としては、多くの人に「全体知」の獲得を解いていきたいところですが、私自身まだまだ途上の身。まずは自分の立場から話すことがメインになるため
①ビジネスサイド（経営企画とかコンサルティングとか）から、データサイエンスの領域に足を踏み入れた方（ここでは便宜上、「データアナリスト」と称させていただきます）
こちらをメインターゲットとさせていただきます。
一方で、
②テクノロジーサイド(IT部門)から、データサイエンスの領域に足を踏み入れた方（踏み入れさせられた方）
③学生の方（特にデータサイエンス系の学部で学ばれていて、将来そういう職業を目指したい方）
にもぜひ読んでいただきたいです。
②のいわゆるエンジニアと呼ばれる方にとっては、逆に、①の人がなぜシステムを意識できていないか。何を教えて挙げたらいいのかが、多少なりともわかっていただけるかと考えるためです。
③の学生の方については、多くの優秀なビジネスサイド出身の方が、教授になられているようなので、あまり無い（と思いたい）ですが、教科書的なデータを如何に上手く分析できても、結局実務だとそれ以外にも、色々と考えることがあるんだなと知っていただければと。
データアナリストが目指す、データサイエンティストの「全体知」獲得プロセス
1.DEPLOYを意識したTRAINを考える
様々なライブラリが充実したり、AutoMLなどでほぼノーコードでも機械学習ができるようになる中で、学習モデルをつくる際に重要になることは、ほぼほぼ特徴量の選択であるといっても過言ではありません。
例えば、私が主に見ていたPOSデータを用いて、来月の店舗売上を予測しようといったときに、店内の情報だけでモデルをつくるのか、近隣の学校でイベント（体育祭や文化祭など）があったといった外部情報も使うのかで精度は大きく変わってきます。
しかし、一方で未来を予測する際に、未来の数値が曖昧なものを使って予測すると、逆に精度が下がる危険性があります。
上記の例で言うと、店舗の売上にはその日の天候や気温といった要素が重要です。
ただ、残念ながら今の気象の情報を用いても、1〜2週間先が限度です。
3ヶ月予報というのもありますが、気温が平年より高い・同程度・低いといったレベルで、中々活用が難しいです。
この様に、DEPLOYを考えたときに、TRAINで使っても意味が（ほぼ）ない特徴量。
これを考えたモデルか否かで、受け取る現場の人の印象も大きく変わります。
2.TRAINとDEPLOYを分けて考える
1と矛盾したようなタイトルになってしまっていますが、こちらはコードを書く際の留意点です。
分析用に準備したデータを、TRAINとTESTに分けて学習。TESTで精度が基準以上になったので、はいOK。
そんなプロジェクト推進になっていないでしょうか。
そこで作成されたコードを、DEPLOY用の本番データで動かすと、多くの場合にエラーになります。
ありがちなのは、データ加工に1-hot encodingを用いていて、TRAIN時とDEPLOY時で項目数が合わなくなるパターンです。
例えば、職業という項目でTRAIN時には「会社役員」「会社員」「自営業」「学生」の4種類があったので、1-hot encodingして4つの項目ができていたとします。
しかし、DEPLOY時の限られた期間の項目では、「会社員」「自営業」「学生」の3種類しかありませんでした。
そうなると、「職業_会社役員」という項目がつくられないので、エラーになるわけです。
こういうエラーを考慮して、DEPLOY時に動くようにしておかないと、システムを動かしてくれているIT部門から白い眼で見られます。（実体験）
3.自分で分析環境をつくってみる
段々とテクノロジー寄りになってきます。
これとかは、プログラムをしてきた先人には当たり前のことだったと思うのですが、私もある時期からGoogle Colabとか便利な分析環境に依存するようになって、環境づくりの大切さというのを完全に忘れてしまいました。
忘れるとどうなるのかというと、Colabでつくったプログラムを、IT部門に渡して、「これを明日から日時バッチで回したいんだけど」とだけ伝えて、白い眼で見られます。（実体験）
もちろん、!pip install xx しているので、ライブラリをインストールしないといけないというのはわかっているんですが、Colabでは見えないライブラリ同士の依存関係だったり、元データソース（私の場合は、多くがBigQueryです）との認証だったり、色々と考慮しないといけないことがあるわけです。
それが分からずに、「精度がいいプログラムができたから、明日から本番運用します」とか言ってしまうと、諸々の歪が生まれて、多くの場合運用が上手くいきません。
4.データエンジニアリングをやってみる
例えば、DWHとしてのBigQueryにデータが入っているとして、じゃあそこに入れるまでに何をしているのか（IT部門がしてくれているのか）を分かっていないと、やっぱり上手くいきません。
1の天気情報ではないですが、本番で予測をしていこうとすると、外部から継続的・自動的にデータを取得・加工し、DWHに蓄積していくことが必須です。ただ、自身でエンジニアリングした経験が薄いと、その際に考えるべきことというのが分からないものが多くあります。
で、それをIT部門に丸投げしたら、白い眼で見られる。だけでなく、想定したデータ型で蓄積されていなかったり、データに過不足があったりと本番運用が最初からコケる大きな原因になります。
5.Pipelineの思想を理解し実際につくってみる
Pipeline的な発想ができてくると、1〜4番目の解消に大きくつながるように思います。
AI・データサイエンスでいうと、Kubeflow Pipelines（GCP環境だと、Vertex AI Pipelines）や、Apache Beam (Dataflow)などを勉強するのはオススメです。
私も最初は、Pipelineなんてなくても、全部BigQueryとPythonで順番に加工する処理を書いて、バッチジョブで動かせばいいじゃんと思っていました。（正直に言うと、今でも３０％くらい思っています。）
ただ、やはり偉大な先人がPipelineという発想を考えたことは意味があり、大量のデータが分散によってスムーズに処理されたり、それぞれの処理に合わせた最小限の環境で動かすことができたりと、実際にやってみると様々なメリットが見えてくる＆自身のプログラムで考慮しきれていなかったこと（１〜４番めのような）が白日の下に晒されることでしょう。
まとめ
いったん、ここまででまとめさせていただきます。
もちろん、＃５まで行けばデータサイエンスの頂かというとまだまだで、３合目といったところでしょう。
ただ、それでもデータアナリストが、エンジニアリング周りを理解しようという態度でビジネスに臨んでいくと、チームマネジメントという点でも、個々人のスキルアップという点でも大きく変わってくると思います。
今回、自身にとっても幹となる内容をまとめさせていただいたつもりです。
５の先についても、まだまだ出てきますし、１～５の内容を実例を踏まえつつ、「じゃあ何を学ぶべきか」についても、今後順番に内容をリッチにしていければと考えています。
Discussion