最終更新日：
数多くのデータサイエンティストの履歴書をチェックしてきた同氏は、多くのデータサイエンスプロジェクトが記載された履歴書がよい、と思い込んでいるデータサイエンティスト志望者があまりに多いことを指摘します。しかし、企業がデータサイエンティストを雇用する際に注目するのは、取り組んだプロジェクト数ではなく良質なプロジェクトを経験しているか、ということなのです。
同氏は雇用主の目にとまりやすいデータサイエンスプロジェクトの特徴として、以下の4項目を挙げています。
- 独自に作成したデータセットを利用していること
- プロジェクトにおいて解決すべき問題は、自力で発見していること
- ウェブアプリでプロジェクトの結果を実際に試すことができること
- プロジェクトを説明するにあたって、いつくかの意外な洞察があること
以上の4項目に加えて、履歴書に記載したいデータサイエンスプロジェクトを様々なヒトに繰り返し解説することを通して、プロジェクトの完成度を上げると同時に自分自身のスキルを磨くことも推奨されています。
上記4項目は、企業のデータサイエンティスト採用担当者が優秀なデータサイエンティストを見分ける際のチェックポイントとしても活用できることでしょう。
なお、以下の記事本文はJeremie Harris氏に直接コンタクトをとり、翻訳許可を頂いたうえで翻訳したものです。
スタートアップ界隈の用語で、「バニティメトリックス」というものがある。これは、企業が実際より良くやっていると世間を ―そして時には企業自身を― 納得させるために追跡している数値のことである。
バニティメトリックスの有名な例を挙げると、約8年前にTwitter社が発表したTwitterアプリでは1日に200万ツイートが送信されているというものがある。200万ツイートという数値は大きいものだが、この数値は思っているより実情とは関連していない。というのも、200万ツイートのうちの大部分がボットから送信されたものだからだ。さらに言えば、企業としてのTwitter社の長期的な競争力に本当に関係する数値は、1日に送信されるツイート数ではない。本当に関係するのは1日当たりのアクティブユーザ数であったり、ユーザがサイトから離れる前に見せることができる広告数だったりする。
バニティメトリックスはいたる所に存在し、それを是正するために本当に重要なもので最適化しようとしても、わたしたちを捉えて離さないものだ。バニティメトリックスはわたしたちを駆り立て、わたしたちのハードワークがなぜ結果に結びつかないのかについての理解を妨げてしまう。
ところで、わたしはデータサイエンスに関するメンターシップを手がけるスタートアップで働いている。わたしの仕事の一部には、志の高いデータサイエンティストがまとめたGitHubのポートフォリオを数多くレビューするというものがある。こうした仕事において、多くのヒトが実際に進歩することを犠牲にしてまで最適化しているように思われる特別なバニティメトリックスを無視するのが難しくなっている。その数値とは、ポートフォリオにおけるデータサイエンスプロジェクトの数である。わたしが見た限りでは、志の高いデータサイエンティストの大多数がsklearnやpandasのようなツールを使ったデータサイエンスプロジェクトの経験を増やしてキャリアを築こうとするスパイラルに陥っている。ちなみに、scikit-learnとpandasはどちらも今までずっと改善されていることを特徴にしている。
わたしがこの記事で探求したいのは、以上のようなスパイラルから脱却する方法である。その方法とは、わたしが今まで見てきた自身のプロジェクト経験にてこ入れをして面接にこぎつけ、ついには採用にいたったメンティーたちから学んだカギとなる教訓を生かすことである。
面倒な物言いをしないでわたしが書きたいことを述べると、次のようになる。scikit-learn／pandasのスパイラルを超えて、可能な限り早く面接にこぎつけられるような素晴らしいデータサイエンスプロジェクトの職歴を築くための方法を一歩ずつ説明するガイド。
0．カギとなるプロジェクトの設計原則
詳しい解説をする前に、経験するデータサイエンスプロジェクトが面接や採用につながる確率を最大化するための一般原則を示したい。
- 経験するプロジェクトはオリジナルであるべき
- 経験するプロジェクトは、可能な限りあなたが身につけたスキルを証明するものであるべき
- 経験するプロジェクトは、あなたが単に何かを計算した以上のことを実行できることを明白に伝えられるものであるべき
- 経験するプロジェクトは、見せるのが簡単であるべき
それでは、以下に以上の4つの原則がどのようにしてプロジェクトの特徴として落とし込まれるか見ていこう。
1．データを取得する場所
仕事で使いたいと思っているデータセットをどのようにして決めるか、ということはプロジェクトを設計するうえで重要なステップのひとつだ。
データセットの取得時には、原則1：「経験するプロジェクトはオリジナルであるべき」を常に思い出すこと。
生活のために履歴書に目を通すテクニカルマネージャーや面接官は、3つか4つのデータサイエンスプロジェクトが書かれた履歴書を1日に何百と見る。こうしたなか、タイタニック号生存者のデータセットあるいはMNIST（※註1）の分析を売りにしている自分の履歴書が、23番目と見なされることは望まないだろう。目を引く履歴書の原則として、有名なデータセットを使わず、ましてやMNISTのような「補助輪」データセットも使わないことだ。わたしが以前に論じたように（※註2）、こうしたお手軽なデータセットを履歴書で引用することはあなたを助けるどころか傷つけかねないのだ。
MNISTとは、アラビア数字の画像認識モデル作成のために用意された手書きの数字画像を集めたオープンソースのデータセットのこと。
- （タイタニック号生存者予測やMNISTを使ったような）月並みなプロジェクトを記載している
- （英語圏で最も有名な機械学習が学習できるオンライン講座である）UdacityまたはCourseraプロジェクトのリストを記載している
- バージョン管理やデータベースを伴わないプロジェクトを記載
- 自分が構築したプロジェクトについて無知である
原則2：「経験するプロジェクトは、可能な限りあなたが身につけたスキルを証明するものであるべき」も忘れないでいて欲しいものだ。
あなたが大企業で働いて携わる業務が高度に専門化されてでもいない限り、あなたが関わる業界のデータはおそらく汚いものだ。とても汚い。貧相にデザインされた図表、float型であるべきものがint型であったり、NaN値が混じっていたり、入力そのものがなかったり、入力値の半分が消失していたり、カラムの名前がなかったりするのだ。もしあなたが自分のスキルが生産的であることを初日から雇用主に見せつけたいのならば、汚いデータに取り組むことは素晴らしい方法だ。以上のような理由から、わたしはおおむね（しばしば事前にデータクリーニングされた）Kaggleのデータセットを履歴書で書くことを避けるべきとすすめている。
Kaggleのデータセットが使えないならば、そのほかに何が残るのか。ウェブスクレイピングだ。それもたくさん集めるのだ。
beautifulsoupやscrapyのようなライブラリを使えば、ウェブから必要なデータをスクレイピングできる。ほかの誰も持っていないようなカスタムなデータセットを構築するためにフリーのAPIを使うという手もある。この手を使う時にはあなた自身がデータをクリーニングし、データと格闘しなくてはならない。
以上のような自分でデータセットを構築するのは、scikit-learnからIrisデータセットをインポートするより手間がかかる（※註3）。だがしかし、手間がかかるということこそ、ほとんどのヒトが独自のデータセットを構築しようとしない理由なのだ。そして、もしデータセットを構築すれば、あなたがよりヒトの注意を引くようになる理由ともなる。
2．model.fit()を使う前にすること
「補助輪」データセットは、たいていひとつかふたつの明白な応用事例をもっている。
例えば、タイタニック号のデータセットは明らかに分類問題であることを示している。このデータセットを見て、もっとも明白にできることは所与のヒトが大事故から生き残れるかどうかを予測することを試す、と考えないほうが難しい。
しかし、現実の業界の問題はタイタニック号のデータセットのようにはいかない。ほとんどの場合、あなたが持っているのは（汚い）データの塊であり、企業のために価値を創出するためにはデータをどのように扱うべきかを調べる必要があるのだ。ここで原則3が登場する。理想的なデータサイエンスプロジェクトとは、重要なデータサイエンスの問題に答えることを可能とするばかりでなく、そうした問題を問いかけることができるものなのだ。
一般的に言って、どうすれば問いかけるべき質問を思いつくか。質問を見つけるための第一歩としては、データ探索を行うのが良い。
散布図、相関行列、次元削減および視覚化技術は、このステップにほぼ常に関わっているはずである。これらの概念と技術はあなたが集めたデータを理解することを助けてくれ、データを理解できるとプロジェクトにおける機械学習／予測フェーズに移行した時に問いかけるべきよい質問が考えられるようになる。加えて、原則4を満たすという追加的な効用もある。つまり、データ理解は面接前と面接中に面接官と採用担当者にプロジェクトをわかりやすく見せられる構想をあなたに与えてくれるのだ。
データ探索の重要性を軽視することは容易い。しかし、データ探索はすべての良いデータサイエンスプロジェクトにおけるもっともミッションクリティカルなステップのひとつなのだ。理想的には、データ探索を行うだけでひとつかふたつの驚くべき洞察が導かれるのが望ましい。そして、こうした洞察は技術的な面接の最中に素晴らしい議論のネタとなるのだ。
3．主要な結果
クレジット：https://www.youtube.com/watch?v=BxizdTrItTkよりスクリーンショットを引用
あなたのプロジェクトの主要な出力がどうあるべきを決める時（例えば予測の戻り値は何か、あるいはプロジェクトの主要な結果から導き出せる結論はどんな種類のものか）、原則4を思い出すことが重要である。出力がどんなものであれ、もしそれを見せるのが簡単あるいは操作するのが楽しいならば（もしくはその両方ならば）、そんな出力がベストである。
以上のような理由により、わたしはプロジェクトを（Flask、あるいは何らかのPythonベースのウェブ開発フレームワークを使って）ウェブアプリとして外の世界に見せることをすすめている。理想的には交流会や面接の最中にプロジェクトを見せたいヒトにアプローチすべきであり、そんな時には見せたヒトに少しの変数を入力させてみたり、あるいはノブで遊んでもらったり、（理想的には視覚的にアピールするために）入力に対する結果を渡すのが望ましい。
最終的なモデルをウェブアプリとして実装することで得られるもうひとつの優位性は、もしあなたがウェブアプリ開発の方法をまだ知らなければ、あなたにウェブアプリ開発の基礎を学ばせることだ（もしウェブアプリ開発をすでに知っていたならば、そのスキルがあることの証拠を雇用主に提供することになる）。製品製造指向の企業のほとんどは自社の製品をなんらかのかたちでウェブ開発しているので、サーバ／クライアントアーキテクトとウェブ開発の基礎を理解していることは、もしウェブアプリ開発が必要になった時にモデルをウェブ製品の設定に統合することを助けてくれるだろう。
4．ピッチ
いったんプロジェクトを立ち上げてしまったら、あなたはそれを潜在的な雇用主にピッチしたくなるだろう。そして、そうしたピッチにおいては話すヒトの面前でスマホのスクリーンで何かを表示したほうがよいし、そのヒトにいくつかのノブを試してみるように言うべきだ。
プロジェクトのピッチを印象深くするためには、プロジェクトをどのように進めたのかについて説明するストーリーを用意しよう。理想的には、そのストーリーにはデータ探索あるいはモデル評価のフェーズにおいて得られた予期せぬ洞察がひとつかふたつ含まれているべきだ（例えば、じつはこのクラスはほかのこのクラスから分けるのが難しいことがわかったのです、その理由は[以下、理由を述べる]、というように）。
プロジェクトについてのストーリーを作ることは、以下のような理由であなたを助けもする。
- プロジェクトについての語りを紡ぐことは、あなたのプロジェクトを面接官に覚えてもらうことを容易にする（そして、プロジェクトを興味深いものともする）。
- あなた自身がプロジェクトにおいて取り組んだデータサイエンス上の問題の根底にあるものを理解しているヒトになる。
繰り返し
あなたのプロジェクトを潜在的な雇用主に披露したり、ほかのデータサイエンティストに見せたりする時、可能な限りフィードバックを得て、プロジェクトのインパクトが増すようにそのフィードバックを取り入れてプロジェクトを繰り返そう。
そして、フィードバックから得られた結果にもとづいてプロジェクトの改善点が何かわかった時には、新しいスキルを学び、学んだスキルのなかでもっともその時点で需要のあるものに親しむことを優先するようにしよう。プロジェクトを開発し終えた時には、広く浅く自分を成長させたというよりは、バランスのとれたスキルセットを身につけたことになるだろう。
いずれにしても以上の解説を参考にすれば、立ち上げたプロジェクト数のようなバニティメトリックスを無自覚に最大化することに没頭して時間を無駄にすることから免れて、雇われるというたったひとつの重要な指標に焦点を合わせることができるだろう。
もしわたしとチャットしたければ、どうぞお気軽にTwitterでわたしとつながってください。Twitterアカウントは@jeremiecharrisです！
原文
『Quality over quantity: building the perfect data science project』
著者
Jeremie Harris
翻訳
吉本幸記（フリーライター、JDLA Deep Learning for GENERAL 2019 #1取得）
編集
おざけん
