データサイエンティストのよくある落とし穴（そして繰り返しを止める方法）
同じパターンを3つの異なるチームで見てきました。新しいデータサイエンティストが入社し、6ヶ月で最初のクリーンなモデルをリリースし、全社ミーティングで名前を呼ばれます。その後、9ヶ月か12ヶ月あたりで車輪が回らなくなります。昇進が来ません。PMが静かになります。組織再編で「優先度の低い」チームに配属され、次の1年間、何が起きたのか考え続けます。
ほぼ毎回、7つのミスのうちの1つです。2つか3つが重なることもあります。
これは「避けるべきトップミス」リストではありません。ステークホルダーが実際のビジネスインパクトを期待し始め、新卒の好意が切れる入社6〜18ヶ月の間にデータサイエンティストのキャリアを壊す具体的なことのリストです。各落とし穴には自分に見つけられる症状、コストを具体化する実際の数字、今週実行できる改善策があります。
なぜ今これが重要なのか
入社1年目はフリーパスです。人々は忍耐強く待ちます。立ち上がりを期待します。ノートブックをリリース物と呼べます。
2〜3年目にはそれがなくなります。本番稼働中のモデル、変わった意思決定、節約または獲得したドルという出荷済みビジネスアウトカムで評価されます。2〜3年でシニアになるデータサイエンティストと、IC2で止まるデータサイエンティストの差は、ほぼ決してIQや統計の実力ではありません。このレベルでは全員が技術的なベースラインを持っています。差はこのリストを避けられたかどうかです。
入社6〜18ヶ月で何かおかしいと感じるが言葉にできないなら、ここから始めてください。
落とし穴1：問題ではなくモデルから始める
症状。 モデルが何の意思決定を知らせるべきかを書き留める前にノートブックを開いてデータを引き出し始めました。既にXGBoostを選んだかもしれません。トランスフォーマーを試すかどうか考えているかもしれません。ステークホルダーとのSlackスレッドには3つのメッセージしかありません。
コスト。 GartnerとVentureBeatは何年も同じ暗い数字を発表しています：MLプロジェクトの60〜70%が本番稼働に至りません。技術的な作業が通常の原因ではありません。ほとんどはモデルが知らせるべきビジネス上の意思決定を誰もフレーミングしなかったため、モデルが「完成」したとき差し込む場所がないことで死にます。誰も開かないダッシュボード。誰も行動しないスコア。あなたの人生の6ヶ月。
改善策。 ノートブックを開く前に1ページの問題ブリーフを書いてください。Confluenceのエッセイではありません。1ページです。
- 誰が何の意思決定をしているか
- 現在のベースラインは何か（ルールエンジン、直感、先四半期の平均）
- 「改善」とはドルまたはビジネスKPIでどう見えるか
- 誰がモデルの出力に基づいて行動し、どのサーフェスを通じて（ダッシュボード、アラート、APIコール、メール）
- 両方向で間違えた場合のコストは何か
5つすべてに答えられなければ、まだプロジェクトがありません。サイエンスフェアがあります。ステークホルダーに戻って会話をしてください。
落とし穴2：ノートブックで構築して壁越しに投げる
症状。 引き渡しドキュメントはハードコードされたパスとdf = pd.read_csv('/Users/yourname/Downloads/data_v3_FINAL.csv')と書かれたセルを持つJupyterノートブックです。エンジニアリングは「本番対応化」に6〜8週間を見積もります。その労力の半分はあなたのコードをスケジュール実行できるものに書き直すことに費やされます。
コスト。 Anacondaのデータサイエンス状況調査は、DS時間の約38%をデータ準備とデプロイの摩擦に費やしているという数字を何年も出してきました。ノートブックから本番への書き直しがそのデプロイ摩擦の最大の塊です。エンジニアリングがノートブックを本番コードに変換するたびに、タイムラインに数週間を追加し、来四半期エンジニアリングチームをあなたと仕事することに熱意を失わせています。
改善策。 プロジェクトの初週から、チームメンバーが異なるマシンで明日実行できるようにコードを書いてください。これはDevOpsではありません。基本的な衛生管理です。
- クリーニングと特徴量のロジックをインポート可能な
.pyモジュールに移してください。ノートブックがそれらを呼び出します。再定義しません。 requirements.txtまたはpyproject.tomlに依存関係を固定してください。「3月に私のラップトップにあったもの」ではありません。- パスと日付をパラメータ化してください。
/Users/yourname/はありません。ハードコードされた2024-Q3もありません。 - 開発環境と本番環境の間で変わるものにはconfigファイルまたは環境変数を使ってください。
- 引き渡す前に、クリーンな環境で自分のコードを実行してください。クリーンなインストールであなたのために動かなければ、エンジニアリングでも動きません。
Kubernetesは必要ありません。他の誰かがZoomをスケジュールせずに実行できるコードが必要です。
落とし穴3：本番監視をスキップする
症状。 モデルがリリースされました。次のプロジェクトに移りました。3ヶ月後、サポートチケットが急増します。カスタマーサクセスが叫んでいます。2日間掘り下げ、モデルは4週目からサイレントにドリフトしていたことが分かります。
コスト。 業界調査は継続的に、再学習なしの典型的なビジネスモデルにおいて6〜12ヶ月以内に20〜40%のモデル性能劣化を示しています。顧客行動が変わります。上流のデータソースが通知なしにスキーマを変更します。新しい製品フィーチャーが入力分布を変えます。監視なしでは、傷ついた人々から知らされます：顧客とステークホルダー。
改善策。 モデルをリリースした同じ週に監視ダッシュボードをリリースしてください。「次のSprintの後で」ではありません。同じ週です。
- 上位5〜10特徴量のPSI（Population Stability Index）を追跡してください。PSI > 0.2でアラートを設定してください。
- 日次の予測分布を追跡してください。平均または形状の急激な変化は先行指標です。
- モデルに紐付いたビジネスKPI（コンバージョン率、解約率、不正検出率）を追跡してください。KPIがドリフトしたとき、VPより先に知る必要があります。
- 再学習ケイデンスを設定してください。四半期ごとがほとんどのビジネスモデルの最低ライン、動きの速いドメインでは月次です。
- ダッシュボードに名前と連絡先を付けてください。所有してください。
監視のないモデルは資産ではなく、負債です。そう扱ってください。
落とし穴4：特徴量を過剰エンジニアリングする
症状。 最終パイプラインには200の特徴量と12ステップの前処理チェーンがあります。AUCは0.81から0.83になりました。誇らしいです。ステークホルダーは違いに気づきません。
コスト。 それら追加の180特徴量は学習時間を2倍にし、本番の障害面を3倍にし（各特徴量はnull、スキーマ破損、または上流インシデントの可能性）、「勝ち取った」リフトはテストセットのノイズバンド内にあります。誰も要求しなかった2% AUCバンプのために壊れやすいパイプラインを保守する責任を負っています。
改善策。 少ないところから始めてください。数字が正当化するときだけ追加してください。
- 10〜20特徴量から開始してください。ドメインエキスパートがミーティングで名前を挙げるもの。
- SHAPまたは置換重要度がホールドアウトセットで>1%のリフトをもたらすことを示すときにのみ特徴量を追加してください。
- ステークホルダーがその1%を気にするときのみ追加してください。解約の1%が$50Kなら良いです。$500なら落としてください。
- 追加する特徴量はすべて保守の約束です。保守にコミットできなければ追加しないでください。
- 迷ったらアブレーション。重要度の低い特徴量を落として、実際に何かが壊れるか確認してください。
シニアデータサイエンティストの基準は「最高AUC」ではありません。「パイプラインの複雑さ当たりの最大のビジネスインパクト」です。
落とし穴5：ビジネス指標なしにAUCを報告する
症状。 報告スライドに「AUC 0.87、F1 0.74、log loss 0.21」と書いています。ステークホルダーは丁寧に頷きます。翌四半期のレビューまでにプロジェクトの存在を忘れます。
コスト。 直接的なドルはゼロですが、誰もVPにそれを説明できないためプロジェクトが資金調達されなくなります。機能するものを構築したのに、誰もそれが機能することを知りません。6ヶ月後、予算が厳しくなったとき、「本当に価値を表現できなかった」プロジェクトが最初に削られます。
改善策。 すべてのモデルレポートはビジネス指標から始めます。常にです。
- ドルまたはKPIで開始してください：「このしきい値で$2.1Mの解約節約」「ルールエンジン比で14%精度向上」「不正チャージバック23%削減」。
- トレードオフカーブをビジネス用語で示してください。「しきい値0.4で、不正の80%を検出し正当な取引の3%にフラグを付けます。しきい値0.6では60%を検出し0.5%にフラグを付けます。それぞれのコストはこちらです。」
- 指標をステークホルダーが既に気にしている数字に紐付けてください。ARRで生きているなら、ARRでフレーミングしてください。NPSで生きているならNPSでフレーミングしてください。
- AUC、F1、log lossは付録に入れてください。あなたとDS Reviewerのためであり、VPのためではありません。
- モデル自体ではなく、モデルが可能にする意思決定で終わってください。
ビジネス価値から始まらないモデルレポートはステータスアップデートであり、結果ではありません。
落とし穴6：ソースのデータ品質を無視する
症状。 ノートブックに「データが汚い」ためのクリーニングコードが400行あります。直近3回のスタンドアップでこれを説明しました。自分を顧客イベントテーブルのどこに問題が眠っているかを知る人として考え始めています。
コスト。 IBMの旧数字は米国経済全体で悪いデータのコストを年間$3.1兆と見積もっていました。会社レベルでは、調査は継続してDSチームがクリーニングに40〜60%の時間を費やしていることを示しています。それはあなたの時間。あなたの給与。そして、ノートブックに書かれたすべてのクリーニングルールは、上流のスキーマが変わると次の機会にサイレントに腐るルールです。誰も存在を知らないから。
改善策。 すべてのクリーニングルールをデータエンジニアリングチームへのバグレポートとして扱ってください。
- バグを報告してください。一度だけ。明確な再現手順と影響を添えて（「これは3つの本番モデルに影響します」）。
- ノートブックでの修正をやめてください。ソースパイプラインで、下流のすべての消費者が恩恵を受ける上流で修正してください。
- 依存するテーブルに対してデータコントラクトを要求してください。スキーマ、nullable、鮮度SLA、オーナー。
- データ品質を共有指標にしてください。チームとデータエンジニアリングの両方がダッシュボードに「データの鮮度」または「スキーマ破損率」を持てば、修正が速く起きます。
- エンジニアリングが押し返す場合（「今四半期は優先度ではない」）、ドルコストで来てください：無駄にしたDSの時間、劣化したモデル、ブロックされた意思決定。
ノートブックでの修正は永遠に払い続ける税金です。上流での修正は一度払う投資です。一度払ってください。
落とし穴7：「モデルは問題ない、データが悪い」と言ってデータを修正しない
症状。 3回以上のスタンドアップでこの言葉のいずれかのバリエーションを使いました：「モデルは機能しています。学習データが悪いだけです。」先週のレビューでもまた言いました。ステークホルダーが静かになりました。
コスト。 あなた自身が対象です。約6ヶ月以内に、ステークホルダーは「実際にリリースする」データサイエンティストを経由するようになります。次の戦略的なプロジェクトに引き込まれません。昇進の会話が得られません。「問題ない」モデルは本番で誰も信頼しないモデルです。つまり問題ないわけではありません。
改善策。 フルパイプラインを所有してください。期。
- モデルはあなたの責任であり、モデルにはそれを供給するデータが含まれます。アウトプットが壊れているとき「あなたの仕事」が終わって「データエンジニアの仕事」が始まるクリーンなラインはありません。
- データが間違っていれば、エスカレーションします。受動的なSlackではありません。名前と締め切りが付いたメールで。
- 「正しい」がどう見えるかの仕様を書いてください。数値範囲、鮮度、スキーマ。解釈の余地を残さないでください。
- 修正がスコープされているとき、エンジニアリングのレビューに参加してください。正しい問題を解決していることを確認してください。
- 本番で修正され、監視ダッシュボードで確認されるまで、それを手放さないでください。
「自分の問題ではない」はこの段階でキャリアを終わらせる言葉です。本番で機能しなければモデルは問題ありません。本番で機能させることがあなたの仕事です。
7つの根底にあるパターン
7つの落とし穴を読み返してください。すべて同じミスです。
データサイエンスをモデリングの仕事ではなくビジネスアウトカムの仕事として扱うこと。
落とし穴1は「モデルではなく意思決定に集中した」。落とし穴2は「モデルではなく引き渡しに集中した」。落とし穴3は「モデルではなくリリース後に起きることに集中した」。4は「モデルではなく保守コストに」。5は「モデルではなくドルに」。6は「モデルではなくそれを供給するデータに」。7は「モデルではなくその周りのシステムに」。
シニアデータサイエンティストの基準は「測定可能なビジネスインパクトをリリースする」です。IC2-foreverの基準は「誰も使わない精度の高いモデルを生産する」です。チームで2〜3年でシニアになった人を見てください。その後、4年間IC2だった人を見てください。差はほぼ決して数学ではありません。モデルをリリース物として扱ったか、それとも実際にビジネスのために機能しなければならないシステムの1つのコンポーネントとして扱ったかです。
セルフ監査
最後の2〜3プロジェクトに対してこれを実行してください。正直に。目的はひどく感じることではなく、自分がどこにいるかを知ることです。
各プロジェクトについて尋ねてください。
- ノートブックを開く前に1ページの問題ブリーフを書いたか？
- エンジニアリングへの引き渡しはハードコードされたパスのノートブックではなく、インポート可能なモジュールのクリーンなコードだったか？
- モデルをリリースした同じ週に監視をリリースしたか？
- SHAPが正当化し、かつステークホルダーが気にする場合にのみ特徴量を追加してリーンに保ったか？
- 報告はAUCを付録にして、ビジネス指標から始まったか？
- 上流のデータ品質の問題を報告したか、それともノートブックでクリーニングしただけか？
- データが間違っていたとき、修正をエンドツーエンドで所有したか？
「いいえ」を数えてください。
- 0〜1個のいいえ：順調です。続けてください。
- 2〜3個のいいえ：今すぐ軌道修正してください。最もレバレッジが高いものを選び、次のプロジェクトで修正してください。
- 4個以上のいいえ：今週マネージャーと本当の会話をしてください。組織再編から優先度の低いチームまであと一歩であり、おそらくもう感じているはずです。
「良い状態」がどう見えるか
2〜3年でシニアになるデータサイエンティストはあなたより賢いわけではありません。仕事の異なる定義を内面化しただけです。
彼らはすべてのプロジェクトをノートブックではなく問題ブリーフから始めます。初週からエンジニアリングが月曜日に実行できるようにコードを書きます。モデルと同じ週に監視をリリースして週次でチェックします。特徴量をリーンに保ち、徹底的にアブレーションします。ドルから報告を始め、AUCは付録です。データ品質の問題を上流に報告してフォローします。データが間違っているとき、デプロイされて確認されるまで修正を所有します。
その人はノートブックをより少なく、リリースされ監視され、ビジネスインパクトのあるシステムをより多くリリースします。ステークホルダーは現在のプロジェクトが終わる前に次の戦略的プロジェクトに引き込みます。「Xをリリースし、ビジネス価値でYをドライブした、これがダッシュボード」というクリーンなストーリーがすべてのプロジェクトにあるため、昇進パケットは自分で書けます。
その人になれます。ほとんどの差は実力ではなく習慣です。
