データサイエンティストとして働き出した昔の自分に伝えたい事

どうも。
Libora社長 兼 データサイエンティスト（仮）の山下です。

大学院で画像解析の研究生活を送った後に、データサイエンティストとして新卒採用いただき、働いていました。
その後、エンジニアの期間を経て今の会社経営に到っています。

複数の立場でサービス開発に携わってきたからこそ、昔の自分に伝えたい事をつらつらと書いていきます。
ひいては、データサイエンティストとして働き始めた人にちょっとした参考になれば嬉しいかなと思って書きました。

経験上、エンジニア寄りの課題感となってます。

対象とするデータサイエンティスト

そういえば、最近はデータサイエンティストって何なのか？という議論がされる事が減ってきましたね。
ですが、未だに人によってデータサイエンティストの定義は違うでしょうし、もはやマーケティングワードにもなってしまっているので、統一される事は困難なのではないか？と思っています。

この記事では、その深淵なる問いに答えを出す事が目的ではないため、
企業内でデータサイエンティストと呼ばれて働いている人
くらいの軽い意味合いでデータサイエンティストを使う事にします。

データサイエンティストとして働いている方は様々なルートがあると思いますが、
今回は、
大学等を卒業してすぐにデータサイエンティストとして働いている方
へ向けた話を中心に話をしたいと思います。

環境に潜む課題

増えましたね。データサイエンティスト採用。
一部の業界では、既に数が絞り始められているところもチラホラあるかと思いますが、
全体としてはまだまだデータサイエンティストの採用をしている会社が多いかと思います。

それと同時に、
「データサイエンティストを雇ったが、どう働いてもらったら良いかわからない。」とか
「うちのデータサイエンティストはパフォーマンスの出せない人ばかりになっている」
みたいな話も耳にしたりするようになりました。

個別の事象があるのは承知の上ですが、
指導のできるシニアデータサイエンティストがいない組織が多い事が１つの大きな問題ではないかと思います。

データサイエンティストが注目され、活躍するようになったのは2012年頃にセクシーと呼ばれた頃からでしょう。
もちろん、それ以前から統計手法等を駆使して働かれていた方はいますが、人口的には多くないと思います。

なので、データサイエンスについて理解があり、サービス開発やエンジニアリングにも精通しているシニア人材がどうしても少なくなってしまっています。
（10年近くたったので、そのような人材も増えてきましたが。）

そういった背景もあって、
指導できるシニアがいないのは半分仕方がない部分もありますが、
できる限り、環境を整える事が必要ではないかと思います。

---

ここからは個人の抱える問題にフォーカスしていきます。

開発できる気になってしまう問題

データサイエンティストとして入社する多くの人は、プログラミングができます。
特に機械学習系をサービスに活かす仕事をするデータサイエンティストには、プログラミングは必須であり、採用試験にも何らかの要素が取り入れられている事が多いでしょう。
なので、ついつい「自分は開発ができる！」と思ってしまう事があります。

しかし、「開発ができる」事と「プログラミングができる・知ってる」事は似て非なるものです。
更に、研究家としての経験があると、1人で開発をしようとする人が出やすくなります。

言ってみればこれは、ダニング=クルーガー効果に嵌ってしまった状態に近いと思います。
（完全に理解した！で有名なグラフのやつですね。）

この状態になると、以下のような行動をとったり、問題が起こるようになり、
エンジニアや他部署の人から後ろ指をさされる自体になりかねません。

・ コードの品質が保持できず、初期開発よりも長いリファクタリングが始まる。
・ テストを書かず、サービス障害を起こしてしまう。
・ コミットを綺麗に残さず、パンドラの箱となる。

こんな状態に陥ってないか、陥る可能性がないか一度考えてみることをお勧めします。

コードの品質問題

過去の自分を反省する問題です。笑
結果、後輩や関係者各位には後に多大なるご迷惑をかける事になります。

学生の書くコードは、ほぼ書き捨てのコードです。
将来的に見直す必要も低いですし、持続的に動くことを目的にコードを書くこと自体が少ないです。
（ちゃんとしてる研究室や、メンターがちゃんと見てるインターンとかは別ですよ！）

そうすると、平気で
関数化もされていない、責務も何もない、処理効率も関係ない
コード・システムが出来上がります。
過去の自分のコードを思い出すと恐ろしいですが、そうでした。

過去の自分を擁護するようですが、
これは、学生あがりのデータサイエンティストが悪いのではなく、経験がないので致し方ないのです。

なので、なんとかしてレビューやペアプロをしてくれるようなエンジニアを見つけ出し、
自分のコードを見て指摘してもらうようにしましょう。

テストちゃんと書いた事ない問題

これもほぼ同じですが、学生はテストなんて書かなくてもなんとかなるんです。
なので、テストの重要性も知りませんし、知らないものは使えません。

自分は、テストをちゃんと書かなかったことで、
数百万レベルの損失を出してしまった事があります。笑

また、「テストもできていないシステムなんて本番にいれれるか！」
と社内のエンジニアに怒られ、半年かけて作ったシステムを導入できなかった事もありました。

が、これは持続的にサービスを提供していく事を考えると当然の事なのです。

ユーザーやサービス、会社にとって価値あるものを作るためにも、
必要なテストを予め学び、しっかり対応できるようにしておく事が良いと思います。

また、コミットをきれいに書くことも同じような観点です。
長期的にサービスを展開していくのであれば、書いたコードはいつか自分の手を離れ、誰かが保守・改善を行っていく事になります。

『fix』 とだけかかれたコミットを見て、何があったのか分かる人はいません。
「何のために、何をどう変えたのか。」を相手に伝えるよう、しっかりコミットログを残していく事をお勧めします。

意外と気にしていない会社の数字

これは、データサイエンティストに対するイメージとは真逆かもしれませんが、
意外と会社やサービスの数字を知らずに働いている人が多い気がします。

具体的には、

・ サービスの規模（売上やユーザー数）
・ 会社の売上と特定のサービスが占める割合
・ 特定作業における人件費等の費用

などです。

これはデータサイエンティストに限った話ではないものの、
これらの数値を知らないと、改善はするがインパクトのない施策を乱立する事になりかねません。

また、これらの数字を知らないからこそ、
コードの品質やテストの重要性、ひいてはサービスの安定性を考える事の重要性に目がいかない要因にもなり得ます。

データサイエンティストは、最終的には他部署の人を巻き込む事が大半です。
上記のような数字をきちんと把握し、問題なくプロジェクトを進めれるようにしましょう。

学び続ける事のできる環境を作ろう

まるで全てをわかったかのような感じで書いてきましたが、
私もまだまだデータサイエンティストとしても、エンジニアとしても未熟な存在です。

なので、私の場合は人と働く事で学べる事が多い事から、自分より経験豊富な人と一緒に働けるように気をつけています。
（というか、絶対に他人は何かしら自分よりもできるもの・経験豊富なものを持っています。）

そのため、自分が経営しているLiboraでは役割・職業に関係なく一緒に働き、それぞれの分野を学び合える環境を作るように気をつけています。

環境を作るのは労力のかかる事ではありますが、
自身のステップアップのためにも環境を整えるところからスタートしてみてください。

---

Twitter（@LiboraPacabro）もやっているので、よければフォローしてください。