Databricks Certified Data Engineer Associate合格体験記およびベンダ試験について考えたこと

先日、Databricks Certified Data Engineer Associateを受験し合格した。せっかくなので受験に際し考えたことなどを記録に残しておこうと思う。

受験の経緯・準備

昨年11月にはじめてDatabricksをさわった。その後、受験を要請されたので準備を開始し、年末に公式の模擬試験を解いた。
Databricks歴は2ヶ月、受験の準備期間は1ヶ月といったところか。

AWSのように受験に特化した書籍は出版されていないので、入手した各種資料を読みながら概要を理解しつつ、公式に加えてudemyの模擬試験を5回分解いた。
www.udemy.com

模擬試験の正答率は以下のようだった。
公式:23/45
udemy1回目:27/45
udemy2回目:27/45
udemy3回目:22/45
udemy4回目:32/45
udemy5回目:33/45

合格するには32問正解しなければならない。模擬試験は本番より難しいものの、受験3日前(この時点で申込はしていない)の時点で半分を切ってまずいかなと思ったが、翌日一気に得点が上がったので勢いで申し込んだ。
この話からわかるように、申込は直前でもできる。画面の表示を見た感じだと最速で申込1時間後くらいから受験できるようだ。

受験本番

監視アプリを入れて家のPCで受験するようになっている。
OSのバージョンによっては監視アプリをインストールできなかったりするので事前に確認したほうがよい。
また、机などの受験環境についても物を置かないようにといった指定がある。
念のため、何も置いていない折りたたみのテーブルをリビングのど真ん中に設置して受験した。

指示に従って5、6問解いたところで強制的に一時停止がかかった。
すぐ受験に戻れるみたいなことが書いてあるものの5分くらい待っても何の音沙汰もない。
サポートのボタンが表示されていたので押して問い合わせたらすぐに再開された。
ちなみに現時点では英語でしか受験できないので問い合わせも英語に限られると思われる。

その後は特に変わったところがなく、制限時間90分のところ見直しの時間も含め35分ほどで終わって提出した。
この点、時間の余裕はあるので英語がそんなに得意でなくてもなんとかなると思われる。
すぐに結果が出てきて、36問正解で合格した。

9年ぶりのベンダ試験

ベンダ試験を受けたのは9年ぶりだ。
新卒1年目に最初の職場でITコンサルティングの仕事をしていたときに、Oracle MasterJavaの試験を受けた。
SilverかBronzeのどちらかだったと思うがいまとなっては記憶があやふやだ。

その後転職してからはOracle DatabaseもJavaも使う機会がなく、同じく新卒1年目に受けた応用情報技術者はなんだかんだいっても知識の基盤として役に立っている側面があるのに対し、ベンダ試験はその製品や言語を使わなくなったらほぼ意味がないのでは、という印象を抱いていた。

そういうわけで仕事でクラウドサービスを使う機会が増えてきても、AWSやAzure、Google Cloudの試験を積極的に受ける気にはならなかったのだが、今回は頼まれたこともあり久しぶりにベンダ試験を受ける運びになった。

ベンダ試験を仕事でどう役立てるのか

上に書いたようにクラウド関係の試験は受けたことがなく、かつ利用経験が豊富というわけでもないので適当な印象論なのだが、クラウドによるシステム開発は確定申告みたいだなと思うことがある。

やりたいことがあって、そのための手順が複数存在して、各々に条件やらルールがあって、どれが最適なのかがわからない。
税理士が節税のための最適な申請方法を知っているようにクラウド有識者は最適なサービスの組み合わせを提示できる。
マネージドなサービスであるという性質上、クラウド開発が得意になるにはプログラミング能力や数理的思考力よりも先にサービスを知悉していることが必要とさえ思われる。

そう考えると、対象サービス群に対しひととおりの全体像を与えてくれるクラウドのベンダ試験は有用なのかもしれない。
Oracle DatabaseやJavaと比べても目的に対する機能の組み合わせが複雑な点からもそういえそうだ。

一方で、自分の職務によって同じ試験でも大事な範囲とそうでない範囲があると思う。
Databricks Certified Data Engineer Associateにしても、たとえばSQLの方言に関する出題がけっこう多い。
こういう知識は毎日Databricksでがりがり設定をするような人には有用だろう。その反面、データ基盤導入のコンサルティングのような場面ではそうでもなく、そういうものもあるんだなとインデックスを貼るくらいの感覚でよいのではないか。

その分、必要な領域については実務も含め知識・ノウハウを深めていくのがよいと思う。私も受験後、自分の仕事で大事そうな領域については自分の仕事の文脈で自分の言葉でまとめ直してみた。

データサイエンティストが競技プログラミングAtCoderをはじめてやってみた

きっかけ

会社の仕事関係で数理最適化を学ぶことになった。
入門書などを読んで以下のように理解した。

  • 数理最適化は連続最適化と組合せ最適化に大きく分かれる
  • 会社の業務レベルで設計や実装に工夫が求められるのは組合せ最適化のほう(連続最適化は問題のモデル化ができた後は優れたソフトウェアに解いてもらえばよい)
  • 組合せ最適化の手法は問題によってまちまちで、実務でも個々の問題をいかにアルゴリズムへ落とし込むかが求められる
  • 実際、組み合わせ最適化の教科書の内容はアルゴリズムの教科書とかぶっている

それならば、問題を解く形式でプログラムを書くのはアルゴリズムを学ぶいい方法だと思い、前から存在は認識していたれどもやろうとまでは思わなかった競技プログラミングに手を出すことになった。

AtCoderへの登録と参加

ほかにも競技プログラミングは存在するのだろうが、おそらく最大手であること、開催頻度と参加可能レベルという意味で参加ハードルが低いことから、AtCoderをやってみることにした。

ふと思い立ったのが土曜に電車に乗っているときで、サイトの登録ページをスマホで開いてから1、2分で登録を完了した。世の中のいろんなサービスへの登録もこれくらいスピーディになればいいのに、と思うほどの手軽さだった。

ちょうど土曜の21:00に初心者も参加しやすいコンテストが開催され、たまたま妻も外出しており暇だったので参加する。

開始1分前までJリーグを観ていたのだが、もうちょっとアディショナルタイムが長かったら時間どおりに始められなかったかもしれない。幸か不幸か贔屓のチームが負けてしまったので、何の未練もなくテレビを消して開始することができた。

結果と感想

本当に何の準備もせずに参加したので、標準入力をどうやって書けばよいかわからずその場で調べたり、なんなら提出の後出てきた赤いマーク(もちろんエラー)の意味がわからずこれも調べたりをしているうちにどんどん時間が過ぎていって、2問目に正解して3問目を考えているうちに時間切れになった。

結果は以下のとおり。
atcoder.jp

2、3問目までくらいは、高度なアルゴリズムを使いこなせるかというよりも、もっと普通の仕様を実装できるかが問われているようだ。このような問題を解くには変数や条件分岐、ループといったプログラミングの基本要素を的確に使いこなすことが必要であり、業務でのプログラミングにもある程度役に立ちそうなので少し続けてみたいと思った。いい感じの実装ができず時間が溶けていく日が定期的に訪れるので。

コンテストのページも興味深かった。最近は企業が協賛していることが多いらしく、今回はサントリーの名前が入っていた。競馬の「神戸新聞杯」みたいな感じなのだろうと勝手に理解している。
企業の採用活動も兼ねているようで、おもに学生向けと思われる企業紹介が載っているのだが、これがけっこうおもしろい。そんなにアンテナを張り巡らしている人間ではないので、自分の仕事と関係のない業界のIT関連情報がこうやって入ってくることは貴重である。
atcoder.jp

コンテスト終了後に出る解説もよい。比較的簡単な問題に対しても自分が考えたこともなかった異なる解法が示されていて驚いた。しかもとても合理的かつ仕事で使えたら役立ちそうな解き方だ。プログラミングができる人にはこういう風に世界が見えているのか、同じことをやっているようでぜんぜん違うのだな、とけっこうな衝撃を受けた。
atcoder.jp

今後

AtCoderには色によるレーティングがあり、最初のレーティングである茶色をまずは目指すものらしい。
最初から茶色をはるかに超えるレベルの人とかでなければ、だいたい最速で2、3ヶ月で茶色になっているようだ。
私は就活でアピールしたい学生でもないしそこまで急ぐつもりはないが、1年後とかだと間延びしそうなので、とりあえず今年度中、だいたい半年後の茶色をゆるく目指して継続しようかと思っている。

阪神タイガースの優勝(アレ)をデータから紐解く

阪神タイガースが18年ぶりにセ・リーグ優勝(以下アレとする)した。

データに関するブログなので、今回は阪神のアレをデータから考えてみたい。

プロ野球を観ていた方なら、今年の阪神はとにかく投手力が充実していたという話を何度も聞いたはずだ。
一方で、攻撃力はそれほどでもなく、そのわりに得点はまあまあ多かった、という話も聞いただろう。

ここでアレ決定日時点でのセ・リーグの勝敗、得失点および攻撃・守備のスタッツを引用する。スタッツ項目はスポーツナビに準ずる。

これを見ると確かに失点はリーグ最少で高い投手力が裏付けられているのだが、それどころか得点もリーグ最多なのである。つまり攻撃力も高いのである(失点の少なさのほうが傑出はしている)

次に各種スタッツを見ると、攻撃力があまり高くないという風評にもある意味根拠があることがわかる。
この表に掲載されている攻撃に関するスタッツは打率、本塁打数、盗塁数だが、打率は4位と僅差のリーグ3位で、本塁打数はなんと5位、盗塁数も2位である。打撃は普通で、長打力は低く、機動力も飛び抜けてよくはないように見える。

ではなぜ得点数がリーグ1位なのか?をこの表にないデータから考えてみた。

まず、阪神はどの選手も四球をよく選んでいた。この話は今年の阪神の特徴としてよく取り上げられていたので聞いたことがある方もいるかもしれない。その結果として阪神出塁率はリーグ1位である。本塁打を打たない限り得点するにはまず塁に出なければならないし、走者なしの状況なら単打でも四球でも同じくらいの価値があるといえる。この塁に出る能力が阪神は高かったのだ。

次に本塁打数は選手の力量だけでなく本拠地に左右される。球場の広さがまちまちだからだ。大まかにいって、セ・リーグでは神宮、東京ドーム、横浜スタジアムマツダスタジアム、甲子園、バンテリンドームの順で本塁打が出やすいとされる。つまり、阪神本塁打数の少なさは甲子園の影響を受けていると考えられる。実際、(部分的には本拠地が狭いことにより)本塁打数が多い巨人やヤクルトとの直接対決での本塁打数を見ると、いずれの球団よりも阪神のほうが本塁打を打っているのだ。

機動力は盗塁数リーグ1位の広島に劣っていたのだろうか。実は盗塁の失敗数や成功率では阪神のほうが優れていた。盗塁は成功だけでなく失敗も試合結果に影響するので、総合的には阪神のほうが機動力が高いといえる。さらにいうと盗塁が上手いことは走塁が上手いことにもつながる。今年の阪神の得点パターンとして、ランナー2塁から単打で1点入ることが多いと言われていた。

要するに、今年の阪神は塁に出る能力も機動力もリーグトップだし長打力も決して低くなかったと考えられる。
こういった結果にもかかわらず攻撃力が低いような印象を受けていたのは、引用元のスポーツナビをはじめ各種メディアが取り上げる攻撃スタッツが基本的に打率、本塁打数、盗塁数だということが大きいと思われる。

野球のルールを知っていれば、ヒットだけでなく四球にも価値があること、球場が狭ければ本塁打が出やすいこと、盗塁を失敗すればチームにとってマイナスであることは誰でもわかるが、目立つ指標に引きずられてしまうのだろう。
個人のタイトルでも、最高打率は首位打者と呼ばれるだけあって最高峰の位置づけである一方、最高出塁率はそんなタイトルが存在することを知らない人も多いと思われる。どの球場で打とうと1番本塁打が多い選手が本塁打王になるし、盗塁王というタイトルはあっても最高盗塁成功率というタイトルはない。

ちなみに守備はどうかというと、消化試合数を補正すれば防御率と失点の順位が一致する。防御率自責点(ざっくりいうと失策絡みでない失点)を9イニングで割ったものなので、よほど失策による失点が多くない限り一致するのは当たり前である。極端な話、防御率は失点を少し異なる形で表現しているだけともいえる。

最後に失策にも触れておく。阪神はリーグワースト2位の失策数だが、一概に守備が悪いともいえない。まず、守備も本拠地によって左右される。内野が土の甲子園は守備が難しいとされる。また、たとえば痛烈な打球に内野手が飛びつくが弾いてしまってエラーになったとき、その内野手の守備力は低いのだろうか。守備範囲が狭いと、グラブが打球に届くこともなく普通のヒットになったかもしれない。ベテランになり守備範囲が狭くなった結果として失策数が減ることがあるが、この場合守備力が向上したとは言いがたい。阪神の野手は他球団と比べ全体的に若く、失策数は多めでも守備力は高いかもしれない。

またそもそも失策とは何なのか?という話もある。先の例だと、場合によっては内野安打と判断されるかもしれず、失策と内野安打に明確な基準はない。失策だろうと内野安打だろうとアウト数やランナーといった試合のステータスに影響はないので、失策は状況に対する解釈の一種ともいえる。

まとめると、目立つ指標が必ずしもチームの強さと相関せず、地味な指標のほうがむしろ相関が高いという結果で、最近(データオタクでない)普通の野球ファンにも知られつつあるセイバーメトリクスを想起するような結果だ。プロスポーツは興行なので、目立つ指標は目立つ指標で大事だと筆者は考える。四球を含めた出塁する率が最も高い選手ももちろんすごいが、ヒットを打つ確率が最も高い選手が打者として抜きん出ているとするのは自然な考えだ。岡田監督もアレした後は、狙える個人タイトルは積極的に狙わせるらしい。そういった選手個人への配慮も含めた総合的なマネジメントがアレにつながったのだろう。

誤解しやすい統計・機械学習・データサイエンス用語10選

AIやDXが広まるにつれ、ビジネスの現場で統計や機械学習の用語を耳にすることが増えている。

一方、字面からの類推によるものか誤った用語の意味がひとり歩きすることも少なくない。

多少意味が間違っていても意思の疎通に問題がなければまだよいが、ときに不幸な認識の齟齬を生むこともあり、そのような事態は避けたい。

今回は、とくに誤解されることが多いと筆者が感じた10語について解説する。

個人的には、ビジネスの場面であらゆる誤用をいちいち正す必要はないものの、誤用による認識の齟齬は避けるべきと考えている。そのために誤用のパターンを頭の中で整理しておくことは意味があるかなと思う。

なお、偉そうに書きながら筆者が間違っている可能性もあるので、その際はコメントなどで優しくご指摘をいただけるとありがたいです。

1 母数

「母数警察」を入れてTwitterで検索すれば数多のツイートが引っかかる、誤解されている統計用語界のスターといっていい。
おおかた、「分母」のような意味で誤用されることが多いと感じる。
「母数が少なすぎてこのアンケートの結果は信頼できない」といった形で使われる。
正しい意味は英語にすると簡単で、「パラメータ」である。
世論調査から内閣支持率を知りたいとき、母数は質問に答えた人数ではなく、全国民に聞いたときの内閣支持率である。
筆者の観測する範囲ではパラメータのことを母数ということをむしろ聞いたことがないので、意外と名前の衝突が起きておらず無害な誤用のではと思っている。

2 サンプル数

誤解しやすいと指摘しながら、自分でも誤用してしまうことがある。
サンプルというのはひとまとまりのデータを指すので、世論調査を1回実施すれば、回答人数が100人だろうと1,000人だろうとサンプル数は1である。
そうではなく100人や1,000人を指す用語を使いたい場合のほうが多いと思われるが、これは「サンプルサイズ」という。
サンプル数が1以外になるのはどういう場合かというと、たとえば東京と大阪での内閣支持率の違いを調査し、各々からまとまった数の回答を得たとすると、サンプル数は2になる。

3 見かけの相関

相関関係と因果関係は違いまぁす!とデータサイエンティストが口うるさくいっているのを聞いたことがある方もいるかもしれない。
ところで見かけの相関があるとは、相関関係がないのではなく、むしろ相関関係はあるが因果関係がないことを意味する。
ならば見かけの因果というべきなのではという指摘はもっともだと思う。
個人的に、見かけの因果とあえていって無用な誤解を避けようとしている。「見かけ」という一般的な語と「因果」という用語を組み合わせて使っているだけで、何も間違った言い方はしていないし。

4 精度

機械学習モデルを改良した結果、異常検出の精度が10ポイントも上昇しました!」というとき、いったい何が10ポイント上昇したのだろうか。
(余談だが、たとえば精度が40%から50%になったときは10ポイント上昇したと表現することが好ましいらしい。10%上昇したというと、40%から44%になったと受け取られかねないからだとか)

何らかの異常を検出する場合、異常を異常と判定することの裏返しとして正常を正常と予測している。
異常を陽性、正常を陰性を定義すると、精度は異常と判定した対象が本当に異常である率、すなわち陽性の的中率を指す。陰性を含めた全体の的中率は「正解率」と呼ぶ。
実用上これらの使い分けはけっこう重要であり、たとえば1万個に1個程度発生する不良品を検出するシステムの正解率が99%以上といわれても、それだけですごいシステムと信じる理由にはならない。全部に対して問題なし!ヨシ!と判定しても、正解率は99.99%くらいになるからだ。
逆に新型コロナウィルスの検査のように、陰性のケースが大半であっても陰性の人を正しく陰性と判定することが社会的に有益である場面もある。
(このあたりは感度(これは精度と同じ)と特異度を使われることが多いらしく、以前に記事を書いた)

なお、日常的な用法と紛らわしいことを避けるためか、精度の代わりに適合率という向きもあるらしい。

5 信頼区間

調査会社によるある番組の視聴率の95%信頼区間が10%から11%であったとき、「真の視聴率は95%の確率で10%から11%の間に入っている」と理解されることが非常に多いが、信頼区間が仮説検定の用語であることを踏まえるとこれは間違いである。
95%信頼区間とは「95%の確率で真の値が含まれるような幅のとり方をした区間」であり、10%から11%という幅はあるサンプルから信頼区間を算出して得られた結果に過ぎない。
そもそも仮説検定の考え方に従えば、真の視聴率は観測できないだけで特定の値に決まっているのだから、区間が10%から11%だろうとそれ以外だろうと、真の値を含む確率は0か1にしかならない。

一方、「真の視聴率は95%の確率で10%から11%の間に入っている」という理解のされ方の背景には、得られたデータをもとに知りたい値に対してあたりをつけられる(確率分布を作れる)という考え方があり、これはベイズ統計の「信用区間」で理論化されている。
ざっくりいえば、仮説検定(が依拠する頻度論)の用語が使われているのに、ベイズの文脈で理解されているということになるのだろうか。
そういうわけで、直感的でないわりに実用上とくに有用でもない仮説検定の用語を極力使わなければいいように思う。

6 有意な結果

これも仮説検定をはじめ頻度論で出てくる用語である。ある分析の結果が統計的に有意であることが、「ビジネス上意味がある」と解釈されることがあるが、そんなことはない。

インターネット広告の画像を変更した結果クリック率が1.0%から1.1%になり、統計的に有意という結果が出たとして、ビジネス上有意かどうかは統計の枠組みの外で決まることである。
0.1ポイントの上昇がビジネスにもたらす利益は画像の変更にかかるもろもろの費用を差し引いても大きいかもしれないし、むしろマイナスかもしれないが、仮説検定は何の答えも提供してくれない。

7 検証データ

機械学習モデリングでは訓練データに加え検証データとテストデータが使われる。
モデルを「検証」するのも「テスト」するのも同じように思われるが、両者の使い道は異なる。
テストデータが文字どおりモデルの性能をテストするために使うデータであるのに対し、検証データはハイパーパラメータの更新のために使う。
講義の訓練フェーズで用いられるデータという意味で、検証データはむしろ訓練データに近い立ち位置くらいに思ったほうがいいかもしれない。

8 ロジスティック回帰

「回帰」とついているのに、「分類」問題を解くために使う手法である。
なんで回帰とつくのかはよく知らないのだが、一般化線形モデルの文脈でそう呼ばれるようになったとかなのだろうか。
なお、そもそも「回帰」が「連続値の予測」という意味だと知られていない場合もあるようだ。
「予測か分類のどちらかで〜」などという言い方を聞くことがあるが、分類も予測の一種である。連続値の予測が回帰で、カテゴリ(離散値)の予測が分類。

9 トレンド

時系列分析で出てくる用語である。
「アイスの売上予測モデルでは、毎年夏になると売れるトレンドが反映されるように〜」などと言われたりするが、そういった傾向は時系列分析の世界では「周期性」という。
トレンドとは、ここ5年くらいアイスの売上が平均的に上がっているといった、まとまった期間の変化の傾向のことをいう。

10 パラメータ

これはデータサイエンティストがモデリングしているときに聞くものだが、グリッドサーチなどを使ってチューニングするとき「パラメータをチューニングする」ということがある。
ここでチューニングするのは正しくは「ハイパーパラメータ」である。
本当に混同している場合と、「ハイパーパラメータ」というのが長く面倒なので、文脈的に誤解がない範囲であえてパラメータといっている場合があるような気がする。

データ加工スニペットを書いて公開したがよい名前を思いつかない

最近、とあるデータ加工の実装にけっこう頭を悩ませたので、せっかくだからと実装内容を整理してGitHubに公開した。

github.com

しかし、処理内容を端的に説明するよい名前を思いつかない。実際、最初はChatGPTにやってもらおうと思ったがよい聞き方が思いつかず、結局自分で考えるはめになったのだ。

しょうがないので、ノートブックの名前も「untitled_data_wrangling_snippet_1」にした。

そういうわけなので、内容を知りたい方には上のリンクからプログラムとコメントを読んでいただくのがよいのだが、一応ブログにも具体例を使った概要を書いておく。

  • テーブル1には日・時間帯別ウェブサイト訪問者数が入っている。列は「日」「時間帯」「訪問者数」。
  • テーブル2には日別の開始時間帯と終了時間帯に関する条件が入っている。列は「日」「開始時間帯」「終了時間帯」。
  • テーブル2の条件が意味するところは、日によって開始時間帯と終了時間帯が異なるということである。
  • このとき、日ごとに開始時間帯から終了時間帯までの訪問者数を取得したい。つまり、日によって訪問者数を取得する時間帯を変えなければならない。

データ分析向けのGitHubの使い方について考えて、ChatGPTにも聞いてみた

チーム開発と同様に、チームでデータ分析を進める場合にもGitHubによるソースコードの管理を求められることが多い。

目的がデータ分析であれプログラムを作成しているのだからとGitHubを使うことが当たり前に受け入れられがちだが、実際に作業を進めるとGitHubを使いこなせていないと私は感じてきた。

理由のひとつには私がGitHubに習熟していないことがあるのだが、チーム開発とデータ分析ではGitHubの使い方を変えるべきなのにできていないことも別の理由として考えられる。
ところがデータ分析向けのGitHubの使い方を検索しても情報はあまり多く得られなかった。後述するが、話題のChatGPTに質問しても求める回答が得られなかったので、自分の思うところを文章にまとめることにした。

なお、私はチーム開発でGitHubを本格的に使ったことがない(ソフトウェアエンジニアの方から、こうブランチを切ってこうプルリクを出してください、といった指示どおりに使ったことがある程度)ので、チーム開発におけるGitHubの使い方については表層的なことを書いており、もしかしたら適当なことを書いてしまっているかもしれない。

ここでのデータ分析とは

プロダクト開発やサービスへの連携とは切り離されたデータ分析業務の成果物をGitHubで管理する方法について考える。データ分析関連のソースコードがmain(master)ブランチにpushされたら何らかのプロダクトやサービスにデプロイされるようなことはないということだ。言い換えれば、データ分析に閉じた目的でGitHubを使う。

GitHubの機能を改めて整理する

GitHubは複合的な機能を備えたサービスであるが、プロダクト開発と密結合してしまったためにユーザが機能の切り分けをしておらず、データ分析のように一般的な開発からずれたユースケースで違和感をもたらしているのではないかと考える。そこでGitHubの機能を4つに整理した。

第一にソースコードをはじめとするファイルの保管・共有である。GitHubの特徴的な機能というよりは機能の前提となっている仕様といってもいいくらいだが、この観点からだとGitHubはS3やGoogle Driveと似たような機能を提供しているといえる。

第二にバージョン管理である。バージョンごとのソースコードの差分を容易に確認もでき、レビューにも便利である。

第三にブランチの管理である。本番環境と開発環境をブランチで切り分けることで、本番環境への影響を取り除きながらGitHubを活用したチーム開発を進められる。

第四にCI/CDとの連携である。おもにmainブランチをCI/CDに組み入れることで、デプロイが自動化できる。

データ分析で使うGitHubの機能とは

では、4つの機能をデータ分析ではどのように使うのか。

ファイルの保管・共有機能は当然に使う。

バージョン管理はどうだろうか。データ分析はJupyterのようなノートブックで進めることが多いが、ノートブックではバージョン管理自体はできるものの差分をわかりやすく可視化できない。そもそも「ノートブック」はその名のとおり、ソースコードの実行結果を見やすくするフォーマットであり、バージョン管理を前提としていない。

ブランチの管理は本番環境と開発環境の切り分けが肝であるが、データ分析業務単体ならば本番環境という概念は存在しない。ということは、本番環境を前提にしたブランチの管理は不要ということになる。

言わずもがな、CI/CDとの連携も不要である。

こうしてみると、ほとんどファイルの保管・共有にしか使っていない。バージョン管理もできるが、差分を見たりといったチーム開発での用途とは異なる。

データ分析向けのGitHub利用でやらなくていいと思うこと、やったほうがよさそうなこと

以上を踏まえると、開発用ブランチを切ったりせずに最初からmainにpushすればいいのかなと思った。
それに付随して、プルリクエストなどもやらなくてよさそうだ。データ分析におけるレビューはプルリクを介してでなく、pushしてからやればいい性質のものだと思う。
それとは別に、作成したノートブックを見やすくするようなフォルダ構成とか、間違ってほかの作業者のファイルを削除しないようにする運用とか、チーム内でのルールは決めておくべきだろう。

ChatGPTに聞いてみたら

ここまで考えてから、ChatGPTに聞けば全部答えてくれたのではと思い、事後的に質問を投げてみたら、ブランチの管理が〜、バージョン管理が〜、といった答えが返ってきた。私はChatGPTはどんどん活用すべきと考えているのだが、幸か不幸か今回に関してはChatGPTとかぶらない内容になった。

元データサイエンティスト採用担当者が未経験からデータサイエンティストになる方法について考える

自分程度の実力・実績のわりに私この業界わかってますよ感が出る気がして、この手の記事を書くつもりはなかったのだが、学生時代の同級生から未経験からデータサイエンティストになるにはどうすればいいのかと聞かれたので、この機会に自らの経験と考えの棚卸しを兼ねて文章にしてみようと思う。そして少しでも同級生の参考になれば。

筆者は何者か

会社員であり、職種はデータサイエンティストである。おおまかな経歴を組織の仮名とともに記す。

  • A大学(文学部・大学院文学研究科、在籍8年)
  • B社(ITコンサルティング、在籍約2年半)
  • C社(広告、在籍約5年)
  • D社(広告、在籍約1年半)
  • E社(SI、在籍数ヶ月、現職)

B社ではITコンサルタントとして働いており、C社からデータサイエンティストのキャリアを開始した。
またC社とD社ではデータ分析チームのマネージャーをやっていて、データサイエンティストの採用業務にも従事した。
したがって採用する側とされる側の両方を経験しており、とくにB社からC社への転職は今回のテーマの「未経験からのデータサイエンティスト転職」に当てはまる。

中途採用とは何か?未経験とは何か?

同級生はすでに社会人をやっており、今回の「未経験からデータサイエンティスト」には中途採用という前提がある。
経験者採用がほぼ同じ意味で使われることからわかるように、中途採用では当該業務の経験者を採用することが通例である。
データサイエンティストの場合、データ分析業務の経験があれば経験者として扱われるわけだが、データ分析業務を必要なスキル・知識・経験から分解すると大きく3つになる。

  • 数学・統計・機械学習系スキル
  • プログラミング・ITスキル
  • 業界知識・経験

業界知識・経験はデータサイエンティストであっても所属組織によってまちまちなので強く求められることはない。したがって残りの2つのスキルに関わる業務経験があれば経験者だし、なければ未経験だ。

未経験からデータサイエンティストになった事例を考える

自己紹介に書いたように筆者は未経験からデータサイエンティストになった。
なぜなれたかというと、採用する側が「未経験の人を採用してもいい」と判断したからである。でなければ採用されることはない。
未経験を採用する理由として、採用目標数が多い、下手な経験者を採用するより長期的に戦力になる、入ってから社内で育成できる、などが考えられる。
ひと言で表すなら「余裕がある組織」にでもなろうか。最終的には会社の方針によるので、可能性のありそうな会社を研究していくことになるだろう。

別の理由としてB社でシステム開発をしていたことが考えられる。
システム開発をしていればプログラミング・ITスキルを持っていることになる。いわば「半経験者」になるわけだ。
筆者以外で未経験からデータサイエンティストになった人を見てもプログラミング・ITスキルを持っていた人が多い。

これは採用する側に回ったときの感覚として理解できる。
プログラミングはいま労働市場にいる人の小中高時代には教えられていないので、本当に一度もやったことのない人が大多数である。ちょっとしたプログラムを組むくらいならさほどハードルが高くないものの、ある程度の体系的な学習が必要で向き不向きもある。そしてデータ分析においてプログラミングはあくまで手段なので、プログラミング自体に強い興味を持っているデータサイエンティストないしその志望者は少ない。
したがって、プログラミングのバックグラウンドが見えない人を採用するとプログラミングへの適性がなく業務を進められないリスクがある。
逆にプログラミングができれば、昨今の分析の多くはライブラリの組み合わせで実装できるので上司や先輩の指示のもとに手を動かして作業をしてもらえるし、会社の都合で分析と関係の薄い開発業務へコンバートもできるので採用に踏み切りやすい。

たとえば情報系専攻でもないしシステム開発の経験もないが社会人大学院の修論でRを使って分析に必要なくらいのプログラムは普通に書けるとする。コーディング試験が実施されないかぎり、会社の採用担当者は本当にプログラムを書けるとこれだけでは確証を持てないが、修論で使ったプログラムをGitHubなどにアップロードして職務経歴書にリンクを貼っておけばちゃんとした証拠になるだろう。

あとはデータサイエンティストが働いているスタートアップの事務職としてとりあえず入ってから異動した知り合いもいる。
未経験の人が最初からデータサイエンティストとしてスタートアップへ入ることは大企業より難しいと思われる。採用数が少なく、即戦力が必要で、育成する余裕がないからだ。
一方で少人数ゆえにデータサイエンティストと社内で関係を構築しやすく、人の出入りが激しいゆえに突発的に人手が必要になることも多く、部署横断的な働き方も求められることから、入ってからの異動はスタートアップのほうがやりやすいかもしれない。

その他、考えられる戦略

現職に関連する事業の会社なら、業界知識・経験を持った経験者としてアピールできる。業界知識・経験は強く求められないと書いたが、当然持っているに越したことはない。データ分析のスキルはあとから身につけてもらうからやる気さえあればよく、それよりも業界のことをよくわかっていて関心を持っている人が欲しいと考える会社もあるだろう。

また、「アナリスト」などといった名前で募集がかかっているような、BIツールやExcelで完結するくらいの分析までしかやらない分、営業的な仕事を兼任する職種もある。こういった職種のほうが求められる統計などの水準は低く、未経験でも採用されやすい傾向にある。場合によってはプログラミングは不要かもしれない。もちろん、その分ほかのスキルや経験は求められるだろう。

あとはあの手この手で実務経験がなくても大丈夫だとアピールするしかない。考えられる手段については以前に書いた。個人的にはここに書いたなかならどれも一定の評価はされるべきだと思うが、たとえばKaggleひとつをとってもコンペに参加しているだけでやる気があると思う人もいればMasterやGrandmasterでも意味ないと言い放つ人もいるので、可能な範囲で手を広げておけたほうがどこかしらで目に留まる確率は高まるだろう。
nora-ds.hatenadiary.jp


年々未経験お断りになっている説への私見とまとめ

2023年現在ではデータサイエンティストの数が増えて転職市場にあふれ返っているから未経験者は無理という話もある。
私は2016年にC社に入ったが、システム開発の経験があったほかにアピールできるものは何ひとつ準備していなかった。いまにして思えばよく採用されたと思う。
一応、大学院で統計やらRをやった話を職務経歴書に入れたが、面接をしていた上司と入社後に話した感じだと何のアピールにもなっていなかった(これは大学院に意味がないというよりは私が学んだ内容と書き方が悪かったという話)

さすがにここまで丸腰だといまなら採用されないだろうが、一方で未経験の人がスキルを身につける環境は年々充実している。
また自分が観測した範囲だけも、この1、2年で未経験からデータサイエンティストになった人は普通にいる。
以前よりなりやすいとはいえないと思うが、ちょっと前ならなれたけどいまは無理、みたいな0か1の話ではないと思う。会社単位ではそういうところもあるかもしれないが。

なお、未経験からデータサイエンティストになれるとしても相当な苦労があるのではないかと思われるかもしれないが、筆者の個人的体験ではぜんぜんそう感じなかった。なぜなら新卒の就活のほうがはるかに大変だったからだ。
自己紹介に書いたように、筆者は人文系の院卒であるうえ、学部と院あわせて8年も在籍した。新卒としては相当歳を食っているうえ、専攻も労働市場で一切評価されない。体育会所属でもないし、ほかにアピールできる材料もない。あえていうなら英語がちょっとできるくらい。
ついでに学者になるつもりでいたところを急に就職することに決めたので、就活を開始したのが2月の途中である。エントリーさえ間に合わなかった企業がざらにあった。
学部で就職していった同級生を見た感じ履歴書で落とされた例をほぼ見たことがなかったが、筆者のような経歴の人間には当てはまらず、40社以上応募して書類が通ったのは10社程度だった。
学部に入学した当時にこんな事態は想像だにしていなかったわけで、人生簡単だと思っていたことが難しかったり、難しいと思っていたことが簡単だったりするので、やってみるまでわからないことも多いのでは、と思う。