データサイエンティストの職務経歴書、何を書けば刺さるのか

データ職の職務経歴書でいちばん差がつくのは、技術の羅列ではなく「その分析・モデルが事業にどう効いたか」を書けているかどうかだ。PythonやSQLが書けることは応募者全員の前提であって、採用側が知りたいのは「この人に任せたら何が良くなるのか」に尽きる。

骨格はプロジェクト単位で書く

職務経歴書は在籍企業の時系列より、プロジェクト単位で書くほうがデータ職には合う。1プロジェクトの書式はこうだ。

・課題。何がビジネス上の問題だったか（1〜2行）・打ち手。何を分析し、何を作ったか。使用技術はここに添える・結果。数字で。売上、工数削減、精度改善、意思決定への影響・自分の役割。チームの何割を自分が担ったか

「LightGBMで需要予測モデルを構築」で止めず、「欠品率をx%からy%に下げ、廃棄コストを年z万円削減した」まで書く。数字が出せない案件でも、「この分析を根拠に◯◯の投資判断が行われた」のように意思決定への接続は書ける。

スキル欄にPython/SQL/AWSと並べるだけでは情報量がない。プロジェクト記述の中で「どう使ったか」が見えていれば、スキル欄は索引程度でいい。逆に、プロジェクトに登場しない技術をスキル欄だけに書くと、面接で突かれて崩れる。書いた技術は全部説明できる状態にしておく。

・分析手法の説明に終始して、事業への影響が書かれていない・「〜に携わった」「〜を支援した」ばかりで、自分が何をしたのか分からない・精度指標（AUC 0.85など）だけ書いて、それが業務で何を意味するかがない・全案件を同じ粒度で書いて長大になる。誇れる2〜3件を厚く、残りは1行でいい

読み手は採用担当と現場マネージャーで、書類1通あたり数分しか使わない。冒頭に要約を3〜4行置いて、詳細は絞る。

職務経歴書は過去の記録であると同時に、「次に何をやりたいか」の表明でもある。応募先で活きる経験を厚く書き、関係の薄い経験は削る。この取捨選択には自分の市場価値の物差しが必要で、考え方の整理には転職の思考法が定番だ。生き残り戦略の話は事業会社のDSが生き残るために必要なことにも書いた。

・差がつくのは技術の羅列でなく「事業にどう効いたか」・プロジェクト単位で、課題→打ち手→結果（数字）→役割の順に書く・書いた技術は全部説明できる状態に。スキル欄は索引でいい・誇れる2〜3件を厚く、残りは薄く。冒頭に要約を置く・応募先から逆算して取捨選択する。経歴書は次のやりたいことの表明でもある

※本記事にはアフィリエイト広告を含みます。