【結論】優秀なデータサイエンティストが3ヶ月で辞める最大の理由は、「分析・モデリングをさせてもらえないこと」です。採用時に期待された高度な分析業務の代わりに、データクレンジング・ETL修正・スプレッドシート統合といった「整地作業」に時間を奪われ続け、能力を活かせないまま離職します。本稿では、このアンチパターンが生まれる組織構造の本質と、防止策を解説します。
「整地」とは何か：データサイエンティストの業務実態
データサイエンティストに期待されるスキルセットを採用要件票に書く際、多くの企業は「機械学習モデルの構築」「予測分析」「A/Bテスト設計」といった高度な業務を列挙します。しかし実際にオンボーディングが完了し、業務を開始してみると、現実はまったく異なります。
彼らが直面する日常業務の内訳は、一般的に以下のような割合になりがちです。
- データ収集・結合（SQLによる手作業、スプレッドシートのVLOOKUP統合）：30〜40%
- データクレンジング（欠損値処理、重複除去、型変換）：20〜30%
- ダッシュボードのメンテナンス・定期レポートの更新：15〜20%
- 実際の分析・モデリング業務：10〜20%
データサイエンティストの業務配分に関する各種調査（Kaggleのデータサイエンス実態調査など）では、実際の分析・モデリングに使える時間が全体の20〜30%に留まるという結果が繰り返し示されています。残りの70〜80%はデータ収集・クレンジング・コミュニケーションに費やされています。これは日本企業に限らず、グローバルでも共通する課題です。
「整地（せいち）」とは建設業界の用語で、工事前に土地を平らに均す作業を指す。データサイエンスの文脈では、分析の前段に必要なデータ整備・基盤整備の作業全般を指す。これ自体は必要な作業ですが、高度な専門職であるデータサイエンティストが時間の大半をここに費やすことは、組織にとっても本人にとっても損失です。
3ヶ月で辞める会社の特徴5選
採用・離職を繰り返すデータサイエンスチームには、共通のパターンがあります。5つの特徴を整理します。
特徴①：データエンジニアがいない（またはDSが兼務している）
データパイプライン構築・データウェアハウス管理・ETLの運用は、本来データエンジニアの領域です。この職種が存在しない組織では、これらの作業がデータサイエンティストに押し付けられる。「データエンジニアとDS、どちらか1名採用するなら」という問いに、多くの経営者は「DS」と答える。しかし実際にはデータエンジニアが先にいなければ、DSは「整地」しかできません。
特徴②：「データ基盤はDSが整備してから使う」という認識
データウェアハウスや分析基盤が整備されておらず、「採用したDSに整備させれば良い」という発想の組織は少なくない。これはDSをデータエンジニアとして使う誤用です。モデリングとパイプライン構築は、必要なスキルセットも思考回路もまったく異なります。優秀なDSほど「自分はそのために採用されたのではない」と感じ、早期に離職します。
特徴③：分析リクエストが「急ぎ・スポット」ばかりで計画的プロジェクトがない
「来週の役員会に向けてこのデータを集計してほしい」「昨日のキャンペーン結果を今日中にまとめて」。こうした短期スポット依頼が常態化している組織では、DSは常に受け身の作業者になります。機械学習モデルの構築や予測分析は、数週間〜数ヶ月の集中した取り組みが必要です。スポット依頼の消化に追われる環境では、そもそも高度な分析が育ちようがありません。
特徴④：成果が「レポート提出」で測られ、ビジネスインパクトで評価されない
「月次レポートを定期的に作成する」「依頼された集計を期限通りに提出する」。これらをKPIにされているDSは、高度な分析をする動機を持てない。優秀なDSが求めるのは「自分の分析がビジネス意思決定を変え、売上や顧客体験に影響を与えた」という実感です。プロセス遵守型の評価制度の中では、その実感を得られない。
特徴⑤：データの品質問題を「DSが解決すべき問題」と見なしている
データ品質の問題は、本来データを生成するシステムや業務プロセスの側で解決されるべきです。しかし多くの組織では「データが汚いのはDSがなんとかするもの」という暗黙の前提があります。このアンチパターンが蔓延すると、データ品質問題が永遠に構造的に解決されることなく、DSが毎回手作業でパッチを当て続ける消耗戦になります。
なぜ整地が永遠に終わらないのか：組織の構造的問題
「今だけ」「立ち上げ期だけ」のはずの整地作業が、なぜ永遠に終わらないのか。それは構造的な問題が放置されているからです。
| 構造的問題 | 表面に出る症状 | 本質的な解決策 |
|---|---|---|
| データ生成システムの品質管理不在 | DSが毎回クレンジングを手作業で実施 | データオーナーシップの明確化とデータ品質SLAの設定 |
| データエンジニアリング不在 | DSがETLを自作・管理 | データエンジニアの採用とパイプライン責任の分離 |
| データウェアハウスの未整備 | 各部門がExcelで独自管理 | 統合データ基盤の構築をDSより先に実施 |
| スポット依頼の優先度が常に高い | 戦略的プロジェクトが進まない | DSの工数の60%以上をプロジェクト型業務に確保するルール設定 |
これらの問題に共通するのは、「データサイエンティストを採用すれば解決する」という誤った期待です。DSは分析・モデリングの専門家であり、データ基盤の設計・構築・品質管理のプロではありません。役割の混同が整地の永続化を招く。
採用面接で「整地地獄」を見抜く方法
転職活動中のデータサイエンティストが、入社前に「この会社は整地地獄か否か」を見抜くための質問リストを示す。同時に、採用企業側が自社の状況を正直に評価するための鏡でもあります。
- 「データエンジニアはチーム内に何名いますか？」。ゼロの場合は要注意
- 「現在稼働しているデータウェアハウスはありますか？」。「整備中」は赤信号
- 「直近のDSが手がけたプロジェクトで、ビジネス意思決定に影響したものを教えてください」。具体例が出てこない組織はスポット依頼中心の可能性が高い
- 「DSの工数の何%が分析・モデリング業務で、何%がデータ準備ですか？」。分析50%以下の組織は整地中心
- 「過去1年でDSが何名退職しましたか？」。複数名退職している場合は構造的問題の可能性
離職を防ぐための組織設計
優秀なデータサイエンティストを定着させるために、組織として取り組むべき施策を整理します。
第一に、データエンジニアを先に採用します。DSより先にデータエンジニアを確保することで、分析に使える「土台」が整う。「DSが来たらデータ基盤を整備してもらおう」という発想を捨てる。
第二に、DSの稼働配分ルールを設ける。「DSの工数の60%以上はプロジェクト型の分析・モデリング業務に使う」というルールを明文化し、スポット依頼による蚕食を防ぐ。残り40%でレポーティングや整地対応を行う。
第三に、ビジネスインパクトで評価する仕組みを作る。「提出物の数」ではなく「分析が意思決定に与えた影響」を評価するKPI設計に切り替える。具体的には、四半期に1件以上、ビジネス施策への直接貢献案件を担当するという形で目標設定できます。
第四に、心理的安全性とキャリアパスを明示します。「データサイエンティストとして何年後にどのポジションを目指せるか」「どんなプロジェクトに挑戦できるか」を具体的に示せる組織は、優秀な人材の定着率が高い。漠然とした「活躍できる環境」という表現ではなく、直近1〜2年の実績を示すことが採用・定着の両面で有効です。
整地地獄が生み出す悪循環：退職コストと採用コストの罠
データサイエンティストの採用にかかるコストは、求人媒体費用・エージェント手数料・採用担当者工数・オンボーディング費用を合算すると、一人あたり200万〜500万円規模になることが多い。さらにオンボーディング完了後3〜6ヶ月の立ち上がり期間も含めると、実質的な「採用から戦力化までのコスト」は年収の1〜2倍に達すると言われる。
3ヶ月で離職した場合、このコストはほぼ丸ごと損失になります。加えて、離職理由が社内外に広まると（エンジニアコミュニティやSNS等）、次の採用難易度が上がるという二次被害も発生します。「データサイエンティストが定着しない会社」というレッテルは、一度貼られると剥がすのが難しい。
悪循環の構造はこうです。整地地獄でDSが離職する→採用コストをかけて次の人材を採用する→同じ環境で同じ離職が起きる→「DSは定着しないもの」という誤った諦めが組織に広まる→構造問題が放置され続ける。この循環を断つには、「次の人材を採用する」前に「なぜ離職したか」を組織として直視し、構造を変える決断が必要です。
「整地」を適正に位置づけるためのロードマップ
整地作業自体をなくすことはできません。重要なのは、それを誰がどのような優先度で担うかを明確にすることです。以下のロードマップは、整地地獄から抜け出すための段階的なアプローチです。
- フェーズ1（1〜3ヶ月）：DSの現状業務を「整地vs分析」で仕分けし、整地比率を可視化する。問題の認識を経営層と共有する
- フェーズ2（3〜6ヶ月）：データエンジニアを採用または外部委託でパイプライン整備を開始する。定型レポートをセルフサービスBIに移行しスポット依頼を削減する
- フェーズ3（6〜12ヶ月）：データオーナーシップとデータ品質SLAを制度として確立する。DSの評価制度をビジネスインパクト型に刷新する
- フェーズ4（12ヶ月以降）：DSが分析・モデリングの専門家として稼働できる環境を持続的に維持する。採用ブランドの向上と人材定着の好循環を作る
よくある質問
データサイエンティストとデータエンジニア、どちらを先に採用すべきですか？
データ基盤が整備されていない組織であれば、データエンジニアが先です。データサイエンティストは整備された土台の上で初めて価値を発揮できます。「DSに基盤整備もさせよう」という発想は、DSの離職とプロジェクトの失敗を招きます。
スポット分析依頼をゼロにすることはできますか？
ゼロにする必要はありません。しかしDSの稼働時間の40%以内に抑えるルールを設けることが重要です。それ以上になると、戦略的プロジェクトが進まなくなり、DSのモチベーションが低下します。セルフサービス型のBIダッシュボードを整備して、定型レポートの依頼自体を減らすアプローチも有効です。
データ品質問題はDSが解決するべきではないですか？
データ品質の「発見・報告・問題定義」はDSが担うべきですが、「構造的な修正」はデータオーナー（データを生成するシステムや部門）が責任を持つべきです。DSがクレンジングを手作業で毎回行うのは対症療法であり、根本原因を解決しません。データ品質ガバナンスの仕組みとして、データオーナーシップを明確にすることが解決の近道です。
まとめ
優秀なデータサイエンティストが3ヶ月で辞める原因は、待遇でも人間関係でもなく「分析をさせてもらえない環境」です。データエンジニアの不在、基盤未整備、スポット依頼の氾濫、プロセス評価型のKPI。これらが重なった組織では、いくら優秀な人材を採用しても同じ悲劇が繰り返される。
「採用ではなく環境を先に整える」。これが整地地獄から抜け出すための最短経路です。データエンジニアリング基盤の整備、スポット依頼の管理、ビジネスインパクト型の評価制度、そしてデータオーナーシップの明確化。これらは一朝一夕で実現しないが、計画的に着手すれば12〜18ヶ月で状況は大きく変わる。逆に何もしなければ、採用と離職のコストを払い続けながら、組織のデータ活用能力は永遠に向上しません。
まず自社の整地比率を計測することから始めよ。数字が明らかになれば、次に何をすべきかは自ずと見えてきます。
- DSより先にデータエンジニアと分析基盤を確保する
- DSの稼働の60%以上をプロジェクト型業務に守る仕組みを設ける
- データ品質問題はデータオーナーシップの明確化で構造的に解決する
- 評価指標を「レポート提出数」からビジネスインパクト型に切り替える
- 採用前に自社の整地比率を正直に確認し、候補者に開示する
関連記事：海外ツールの日本語対応の実態：「日本語対応」5段階レベルと選定チェックリスト｜SaaS契約の落とし穴：年間契約・従量課金・解約条件の見極め方と交渉チェックリスト｜データカタログを2回作り直した話：メタデータ管理が定着しない本質的な原因