(Image by Gerd Altmann from Pixabay)
元々Quora英語版で回答を書いた話題なのですが、「データサイエンティストの典型的なワークフロー」というのは当たり前の話題のようでいて意外と難しいトピックです。それこそ例えば巷の営業やエンジニアの人々に向かって「あなたの『職種』の典型的なワークフロー」について教えて欲しいとリクエストしても「それは個々の現場・会社ごとに千差万別だろう」と言われてしまうのが関の山だと思われます。
ただ、おそらくこの質問がQuora英語版でされていた理由として「まだデータサイエンティストという職種がそれほど世間に広まっていないので、そもそもどのような仕事の流れをたどるかのイメージ自体が未経験者には思いつかない」ということがあるのではないかと個人的には見ています。ここが明確になっていないせいで、新たにデータサイエンティストの仕事に就きたいという新規参入者たちにとってもその職務の具体像が見えてこないという問題があり、それがそのまま各現場で新米データサイエンティストたちが暗中模索と四苦八苦*1を余儀なくされるという構図に繋がっているのではないでしょうか。
そういう事情を踏まえて書いたのがQuoraの回答なのですが、スペースの都合上*2そこまで仔細に渡った解説を付すことも憚られるので、言いたかったことの数々を端折って書いてあります。ということで、今回のブログ記事ではその僕個人が自分の経験に基づいて考える「データサイエンス実務の典型的なワークフロー」を再録した上で、さらにその詳細についても細かく書いていこうと思います。
個人的に考える典型的なワークフロー
Quoraに載せた回答の焼き直しみたいなものですが、概ね以下の通りだと考えています。ちなみにここでは、以前のスキル要件記事で定義した「データサイエンティスト」の実務のワークフローを想定しているため、基本的には「アナリスト的な仕事が7割以上＆エンジニア的な仕事が3割以下」ぐらいだと思ってください。また、ここでは「ステークホルダー」という言葉は基本的には「プロジェクトの成果を求めている人・組織」を指すものとします。よって内製・外注といった業態の違いは想定していない点にご留意ください。
- プロジェクトの目的、期限、進め方、予算（リソース）についてステークホルダーと議論する
- プロジェクトをどのようにデータサイエンスによって解決可能な問題に変換するか定める
- データソースを確認する
- ステークホルダーが自前のDBなどデータ基盤を持っていない場合は、プロジェクトを延期してその整備からやり直す
- ステークホルダー自身に前処理をしてもらう
- データサイエンティストが自前でデータの前処理をしない方が良いため（データの持ち主が前処理をした方が効率が良くかつ確実）
- 前処理されたデータセットを受け取り、それが予測に役立つかどうかをチェックする
- ダメなら#3/4に戻る
- データセットから予測モデルを推定・構築する
- 当然ながらデータセットを学習／検証／テストそれぞれのパートに分け、交差検証を行い、注意深くパラメータをチューニングしてモデルを汎化させる必要がある
- 何をおいても汎化性能が最重要
- 最適なモデルを選択し、その上でアウトプットを準備する
- アウトプットを提供する
- アウトプットがステークホルダーの要件を満たしたかどうかを確認する
- ダメなら#8もしくは#6に戻る（ここのロールバックが非常に多い）
- ステークホルダーの合意が得られたら、そこで案件をクローズする
なお、ここではデータサイエンティストが全て一人でやることは想定しておらず、必要に応じて実装を担当するエンジニアなど諸職種の同僚とチームを組むことを想定しています。
詳細な説明など
まず#1ですが、あえて言うなれば「要件定義」に当たるフェーズです。ただ、以前の記事でも書いたようにデータ分析プロジェクトは得てしてアジャイル的なワークフローをたどりがちなので、この時点で「何度か手戻りが起きるので覚悟しておいてください」とステークホルダーには伝えておく必要があります。
もしここでウォーターフォール的にやれみたいな圧力がかかった場合は、この後に続くのはただの地獄になるという点を覚悟した方が良いです。ここの議論というか交渉は、分析側の事情とステークホルダー側の事情の双方が分かる人に間に入ってもらった方が確実でしょう。
次に#2。ここはデータサイエンティストのある種の「センス」や経験が試されるところです。例えば「これこれのモノ・コンテンツなどなどを顧客向けに推薦できるようにしたい」と言った場合に、オーソドックスな行列分解もしくはいわゆるレコメンデーション系の開発をするのか、それとも実は機械学習で分類ラベルを予測する形にするのか、はたまたバンディット的なもので済んでしまうのか、もしくは実は機械学習で自動化するのではなくデータマイニング的な発想で一定期間ごとに変えながら決め打ちの組み合わせを提供していくのか、というような切り分けを適切にできることがそのままプロジェクト全体の成否に繋がりがちです。
#3は言うまでもないと思いきや、ここでコケることが非常に多いです。全てDBに入っていれば話は早いですし、BigQueryのようなスケーラブルかつフルマネージドなDBに入っていればそのままAutoMLにぶん投げるみたいなこともできます。しかしこれが全て日付ごとにバラバラに記録されたExcelファイルとか、紙で印刷されたものをスキャンしてPDFにしたものしかないとかいったことになると、ただの地獄です。僕の場合は、DBに入っていなければ「DBに全部ステークホルダーの側で入れてもらう」というロールバック的な対応をすることが多いです。そこまでコストがかけられないという理由で#1に戻ることもあり得ます。
意外に思われるかもしれないのが#4。実は、ここ数年僕は自分で前処理をしていません。これについては「自分で前処理すべき」派と「前処理は外注すべき」派とに分かれることは承知していて、特に特徴量エンジニアリングを重視する人たちには前者が多いということも知ってはいますが、ビジネスオペレーションという観点からは「分析者が自ら前処理をするといざそこから得られた特徴量がステークホルダーの意図と食い違った場合にかなりのロールバックが発生する」という危惧があるため、よほどステークホルダー側に前処理のリソースand/or技術がないケースを除いて原則としてステークホルダー側に前処理をやってもらっています。
その前処理の結果をチェックするのが#5。ステークホルダーに前処理してもらっているから大丈夫だろう。。。と油断していると大間違い、みたいなケースは枚挙に遑がありません。せめて順序尺度でつけて欲しい変数が名義尺度（つまり0/1）になっていたとか、データソースの抜け漏れで本来0でないはずの変数に0が入っているとか、あるあるネタだと思います。ダメなら当然#4に、そもそもデータソースからしてダメなら#3まで戻ります。
#6は統計分析・機械学習問わず*3モデリングするフェーズで、いわゆるデータサイエンティストにとってはここが最も楽しいところでしょう。なればこそ、適切に交差検証*4したりパラメータチューニングしたりするのは基本中の基本。なお、色々なところで書いている通りモデリングの目的が予測でも解釈(reasoning)でも、汎化性能の低いモデルを使うと問題が起きやすいので、汎化性能を確保することが最重要です。
モデルさえ出来上がってしまえば#7に移るわけですが、機械学習で予測をするならどこかしらの環境にデプロイすることになるかと思います。なのでAPIを立てるなり、アウトプット先のシステムへのパイプラインを作るなり、はたまたUIを用意してそこにアウトプットする、といった工程が必要です。一方でマーケティング分析などでステークホルダーの意思決定に役立てる用途でモデリングをする場合は、そのモデルの解釈や信頼性のような情報について「専門家でなくても分かりやすく」レポートを用意する必要があります。ここの工程は、ステークホルダー側の事情に明るい人を交えてやった方が無難です。
#8は単なるアウトプットフェーズなので、特に説明は要さないでしょう。ここの工程は協働するエンジニアやコンサルタントにも入ってもらうことが僕の場合は多いです。特にシステム実装する系の仕事だと、クソコードしか書けない僕は頑張ってプロトタイプまでは何とか組んで、それをもとにエンジニアの人に本番系の実装を書いてもらうというパターンがほぼ全てです。
そして緊張が走る#9。機械学習システムだと実際に運用してみないと分からないことが多く、試しに運用してみたところ思わぬ不具合や性能不足が発覚してやり直しになるなんてことは珍しくありません。一方統計分析してステークホルダーにレポートする系の仕事だと、ステークホルダーからの「現場感覚とあまりにもかけ離れている」「他の要因で説明できることが課題評価されている」とか、酷い場合は「そもそも腹落ちしない」みたいなクレームを受けてやり直しになることがザラにあります。なので、ワークフローの最後の方のフェーズでありながらここで最も多くロールバックが発生するという印象があります。なので、大事なこととして「#1の最初の議論の際に#9で多数回のロールバックが発生する」と予め認識しておいてもらうべきだ、というのがあります。これを欠くと、最後の最後で大モメにモメて全てがパーになるという最悪の事態もあり得ます*5。
めでたく全てがうまく行ったら、#10に到達しておしまいです。ただし、#1で終了条件を決めていないと「また来年もお願いします」みたいな謎の約束と共に延々と続行することになったりします。。。
最後に
一通りお読みいただければお分かりかと思いますが、僕自身それほど学術的・技術的なスキルが高いデータサイエンティストというわけではないので、どちらかというと高度なデータサイエンスを駆使して華麗に問題を解決するというよりは地道にビジネス要件を満たすような手堅い課題解決策を見出して、それを泥臭く実装or実行するというスタイルでずっとやってきています。上記のワークフローが固まったのは大体前職時代の末期ぐらいで、以後僕にとっては定番となっています。
そして言うまでもありませんが、これは僕が過去に体験した様々なデータサイエンスプロジェクトのワークフローの「最大公約数」を取っただけのものであり、業界や職掌さらには職階によっても異なるワークフローがそれこそ無数に存在すると思っています。願わくば、他のデータ分析職の皆さんの「典型的なワークフロー」についても読んでみたいと願う次第です。
