データサイエンティストの基本的な副業の流れ
データサイエンティストのsatomacoto（@satomacoto）です。普段は、解析に必要なIoTデバイスやWebアプリのソフトウェア開発から機械学習モデルの開発・デプロイまで携わるソフトウェアエンジニア/データサイエンティストとして働いています。本稿では、データサイエンティストとして短期間で成果を出すために気をつけていることについて執筆します。
1.契約前・オンボーディング
一口にデータサイエンスの案件といっても、その言葉が表す職務は、「モデル開発」「特徴量エンジニアリング」といったデータサイエンスそのものに関わるところから「アーキテクチャ」「データ整備」といったソフトウェア・インフラに関わるものまで広範囲に及びます。
契約前・オンボーディングでは、クライアントがどこまでの範囲をどの程度の期間で実現したいか、そして限られた自分の時間でどこまで関われるかを明確にします。短期間のスポットで入る副業において、ここはもっとも大事なことのひとつです。
実際のところ、データサイエンティストにとってモデル開発や特徴量エンジニアリングが、一番価値を発揮できるところです。短時間でしか関われない副業では、これらに集中して業務を行えるかが鍵になるかと思います。
一方で、プロダクトの開発体制にもよりますが、インフラ・デプロイ・運用まで考慮した形で副業先と話し合いながらモデル開発を進められると、貢献できる可能性を広げられるかもしれません。
例えば、機械学習のデザインパターンなどを網羅的に知っておくと、その知識を活かして少ない時間で最終的にどんな成果物を出すとよさそうかも提案できるでしょう。
2.分析・アウトプット
実際に業務を開始したらマイルストーンを切って進めて行きます。例えば、機械学習のモデル開発であれば、以下のようなプロセスとなります。
- 1.対象となるプロダクトに対する理解
- 2.蓄積されているデータスキーマの聞き取り
- 3.EDA（探索的データ解析）
- 4.モデル構築と学習
- 5.結果のレポート
- 6.フィードバックをもらった上で、EDA〜レポートのサイクル
- 7.最終的に成果物の提出
成果物は、Pythonなどで解析したEDAの結果をJupyter notebookの形式にまとめたり、機械学習モデルのコードをまとめたりしたものであることが多いです。
1.案件の契約前・オンボーディング時に確認したいこと
▲AIとマーケティングについてのイベント登壇時の写真
副業で成果を出せるかどうかは、最初が肝心だと思っています。契約前後で気をつけるべきことをまとめました。
ヒアリング項目
候補契約前・オンボーディング時に聞いておきたいトピックには、下記のような項目が挙げられます。
- 対象のプロダクト
- 目的・ゴール
- 期間
- 現状のインフラやデータ
- すでに始まっているなら既存のモデルの開発や運用
限られた時間でデータサイエンティストとして成果を出すため、特にどんな項目を聞けばいいのかを具体的に示します。
データサイエンスを使う明確な背景はあるか
なぜデータサイエンスを必要としているかを聞いておきます。その背景が明確でないと、言語化から入る必要がありオンボーディングコストが掛かります。
- 対象のプロダクトはどんなものであるか。
- 目的は何か
- 最終的なゴールは何か
- やりたいことは手作業ではできないのか
- モデルはルールベースでやったものでもいいのか
- 機械学習モデルのもののほうがいいのか（すなわち、モデルの推論結果がどのように利活用されてどのようなKPIを実現できるとよいのか）
上記について 多角的に聞けると貢献のイメージがつきやすいです。
データサイエンスへの理解のある人がいるか
副業で参画する限り、プロダクトに掛かりっきりになることはできません。長期的なビジョンを持って様々なステークホルダーとビジネス的な関わり方をしたり、インフラ構築、データ整備、監視を含めた継続的なソフトウェアの開発や運用などに、携わることはなかなか難しいです。
そのため、データサイエンスの知識を活かして開発したモデルをプロダクトに組み込むためには、副業先がどの程度データサイエンティストの仕事に対して理解があるかが重要です。
ビジネスとソフトウェアの側面がわかっていて、さらにデータサイエンスが現実的にどの程度プロダクトに貢献することができるかを把握している方とやりとりできる環境だと望ましいでしょう。
ビジネスだけがわかっている方だとデータサイエンスまわりのインフラやソフトウェアのコストの見積もりが難しく、ソフトウェアだけだとデータサイエンスがどの程度価値を生み出せるかの見積もりが難しいことがあります。
副業先（受け入れ側）に求められるスキルセットは、データサイエンティスト協会が公開しているスキルチェックリストが参考になります。③Associate Data Scientistレベル以上でビジネス力、データエンジニアリング力があることが望ましいです。
具体的には、以下のようなことができるか確認できるといいでしょう。
- ビジネス判断を含めた要件の整理
- 検討結果を取りまとめた現場への説明
- データ処理・環境構築をデータサイエンティストに相談しつつ推進
- 分析要件に合わせたインフラ環境（GPU/CPU、クラウド/オンプレミスなど）を設計・実装
これらを基本とし、
- データレイクの設計、構築
- データパイプライン(Kafka, AWS Kinesis, Spark, etc)設計
- バッチ処理、ストリーム処理を含むデータ処理設計と実装
などを運用に落とし込んだり、プロダクトとして組み込んだりと意味ある形に変えるためのスキルがないとモデルを作ってもPDCAサイクルが回りません。
データサイエンスの環境は整っているか
すでにどの程度環境が整っているか、また成果物をどのような形で運用するかを聞いておきます。
- 分析用のDBやBIツール、その他分析環境がすでに準備されているか。あるいはエクスポートしてもらうようになっているか
- データ加工に対応できる、もしくは対応できる環境があるか
- 機械学習のようなアプローチをする場合、初期の訓練データを作るところを協力してくれそうか
- モデルを運用し、PDCAサイクルが実現できそうか
最初は、必ずしも全部にチェックがつくことはないと思うので、業務開始後にどの程度まで対応してくれそうかも確認します。ここが前段で述べたDSに理解がある人がいるか、またデータエンジニアがいるかに関わってきます。
業務を進める上での段取りの付け方
最終的な成果物が何かがわかったら、上記のヒアリングを通して、ゴールから逆算して一応のマイルストーンを切ります。「一応」というのは実際に手を動かしてみないとわからないところが多々あるからです。
週に一度くらいのペースで「こんなデータがほしい」「こんな環境がほしい」「こんな加工をしてほしい」みたいなことをお願いをします。
私の場合、ルールベースで行っているモデルから機械学習モデルへ置き換えのタスクをいただいたときは、以下のようなリクエストを出しました。
- プロダクトの理解のため、実際に開発したモデルの推論結果がユーザからどのように見えるか確認したいのでアプリへのアクセス権限がほしい
- データソースの理解のため、生のデータを直接アクセスする環境がほしい。また、その各属性の意味やビジネスでKPIとなっている指標を教えてほしい
- 実データを確認しつつ、解析から除外したほうがいいデータ、実際に予測するタイミングでは使えないようなデータ、加工が必要なデータなどを教えてほしい
- 新しいモデル開発のため、最初期の機械学習を回すために教師データになるものを手作業で付けてほしい
- 未知のデータに対して、モデルが算出した数値を確認して、それに対するフィードバックがほしい
上記のようなお願いをしつつ、解析やモデリングを行います。そして、一週間から二週間に一度くらいで成果物の中間報告を出して、都度フィードバックをもらって進めます。
何らかのリクエストをするときは、事前にヒアリングしたプロダクトの環境や社内の人的なアセットも踏まえて、先方がなるべく最小限で動けることを意識した形にします。
2.業務を進める中で意識していること
業務を進める時にはコミュニケーションの量と質を意識しています。
副業先との密なコミュニケーション
特に業務開始直後はわからないことが多いので、コミュニケーションを密に取るようにします。単純な質問はもちろん、認識の齟齬がないかをなるべく詳しく列挙して確認したり。このときは非同期のコミュニケーションを意識します。
結果のみならず過程を伝えること
プロダクトのコードに直接コミットしない場合、副業先が再実装しやすい形で書くことを意識します。EDA、モデルの構築に関して、ブラックボックスを残さないように、必要以上にコメントを書いたり。AutoMLが選択肢にあるときも、各サービスの制約などがわかるように参考リンクなどを残しておくとよいでしょう。
選択肢の提示、Pros/Consの明示
成果物の中間報告にあらかじめ複数の選択肢を用意しておくと、手戻りが少なく、しかもコミュニケーションを減らすことができます。まずはベースラインになるめちゃくちゃシンプルなモデルを作り、それに対していくつかのモデルを作って、それぞれのPros/Consを示したりすると、クライアントが本当に欲しかったものが掘り起こされる場合もあります。
▲副業の収入で購入したキャンプ用具
Pythonを使う時に特に意識していること
データサイエンティストであればPythonを使う機会が多いかと思いますが、次のような点に気をつけています。
環境の構築
再現性を担保できるようにDockerを使ったり、利用する各パッケージのバージョンを固定するためにPipenvやPoetryなどのツールでパッケージ管理を行ったりします。また、基本的に成果物のコードメンテナンスはお願いすることになるので、一般的な、あるいは指定されたコーディング規則に則って記述するようにします。READMEには環境構築を含めた実行の方法も記述します。
解析結果を示すJupyter notebook
普段からよく使う関数は、自前のパッケージにまとめて参照することも多いですが、解析結果を載せた成果物としてのJupyter notebookの場合、管理の煩雑さを防ぎ、それ単体で完結して動作するようにすることが多いです。
副業で良かったのは収入とスキルアップの両立
パブリックではないプライベートなデータを通していろんなことを考えられるので、知的好奇心が満たされます。また、できる人のお手伝いをすると仕事の進め方など新しい発見が生まれるでしょう。正直、普段向上心だけで勉強するための時間を作るのはなかなか難しいのですが、副業で目に見える形でお金が増やせると家族の理解を得ると同時に知識や経験値も増えて一石二鳥かと思います。
