日本語

新任Data Scientistの最初の30日・60日・90日

入社3日目の午前9時47分。どのSlackチャンネルが重要かようやく分かってきたところです。コーヒーはまだ温かい。入社時のオンボーディングで一度会っただけの人からメッセージが届きます。「ちょっとチャーンモデルを見てもらえますか？しばらくおかしくて。」

おめでとうございます。あなたは今、18ヶ月分の誰かの意思決定を引き継ぎました。前オーナーは2人、読む価値のあるドキュメントはなし、誰も完全には理解していない特徴量セット、そして「AIへの投資」がいつ回収されるかを6週間前から聞き続けているCFO。モデルは8月から再学習されていません。あなたはまだノートPCの環境構築さえ終えていません。

これがB2B SaaSのほとんどの新任Data Scientistの入社3日目の実態です。衝動は強烈です。何でもいいから早く出荷して、席を守っている証明をしたい。やめてください。最初の90日は、リーダーシップがあなたを収益レバーとして見るか、ボードが「ヘッドカウントはどこが膨らんでいるか」と聞いたときに次に削られる予算項目として見るかのナラティブを決めるときです。そして、ビジネス価値の物語が曖昧なとき、Data Scienceのポジションは他のどの技術職よりも速く削られます。

ここでは英雄的な行動を必要とせず、天才である必要もなく、壊れた解約モデルをKPIとして抱えることで終わらない90日計画を紹介します。

なぜ「構築」より「監査」が先か（そしてなぜほとんどの新任DSがここで間違えるのか）

新任Data Scientistが犯す最大の間違いは、生産的に見えるために2週目に新しいモデルを出荷することです。素晴らしい気分になります。しかし同時に、まだビジネスのコンテキストを理解していないものを所有し、ステークホルダーに「モデルを出荷すること」があなたの価値提案だというシグナルを送り（それは違います）、判断なしに素朴な質問ができる唯一の時間を飛ばしていることになります。

ハネムーン期間はたった一度だけです。構築ではなく、傾聴に使ってください。傾聴は具体的な成果物（監査メモ、ステークホルダーマップ、データウェアハウスのチートシート）を生み出し、マネージャーには半端なモデルと同じくらい生産的に見えて、技術的負債を生み出しません。

1〜30日目: 監査と傾聴

最初の30日間の目標は1つです。何が存在し、何が壊れていて、人々が実際に何を望んでいるかを把握できる確かなマップを作ること。新しいモデルは作りません。「クイック実験」もしません。約束もしません。

本番稼働中のすべてのモデルをリストアップする

スプレッドシートを作ります。本番、定期実行ノートブック、誰も認めたがらないAirflowのあれ、どこかで稼働しているすべてのモデルを1行ずつ。それぞれに3つの列を埋めます:

実際のパフォーマンス対主張されたパフォーマンス。 モデルカードや直近の四半期レビューには何が書かれているか（AUC、上位十分位の精度、MAPEなど）。直近90日のデータで実際には何をしているか。少なくとも1つ、そのギャップが恥ずかしいモデルが見つかります。解約モデルが最悪のケースであることが多いです。顧客ミックスが四半期ごとに変わるB2B SaaSでは、主要特徴量の15〜25%のドリフトは普通です。
公平性とドリフト。 今日モデルが見ている入力分布は、学習時のものにまだ近いですか？表形式モデルでは、上位5特徴量の簡単なPopulation Stability Index（PSI）チェックで大抵のことが分かります。PSIが0.25を超えると、モデルは学習データの分布外で動作しており、予測はシグナルを装ったノイズです。
実際のビジネス価値。 出力を誰が使っているか。どの意思決定を促しているか。モデルが明日から定数値を返しても何が起こるか。「正直、おそらく何も変わらない」が答えなら、書き留めてください。後で必要になります。

3〜5つのモデルは普通です。8つ以上なら、誰かが忙しそうに見えるために作っていて、あなたはお墓を引き継いだことになります。

5つのステークホルダーの定期ミーティングに参加する

5回の会話ではありません。最初の2〜3回はサイレントオブザーバーとして参加し始め、その後から貢献し始める5つの定期ミーティングです。それぞれ以下から1つずつ選んでください:

Sales ops（予測精度、パイプラインカバレッジ、リードスコアリングの不満）
カスタマーサクセス（解約シグナル、アップセル機会、NPSと収益の連動）
プロダクト（機能の採用、アクティベーション、A/Bテストをひどくやっている部分）
ファイナンス（収益予測、ユニットエコノミクス、CFOのビジネスモデルの実際の理解）
エンジニアリング・データプラットフォーム（ウェアハウスのコスト、パイプラインの信頼性、何が炎上しているか）

2つのことを聞いてください。どの意思決定が本来データで下すべきところを感覚でやっているか、そしてどの意思決定が実際には間違ったデータで下されているか。2番目の方が認められているより多い。Sales opsがSalesforceのレポートから更新案件をダブルカウントしてパイプライン予測を立てているのは、ほとんどのB2B SaaSにある定番中の定番です。

データウェアハウスの嘘が潜む場所を学ぶ

すべてのデータウェアハウスには小さくて嫌な真実の層があります。3回名前が変わった列。BIツールが静かに含めてしまうソフトデリートされた行。シンガポールの月曜日を日曜日として表示させるタイムゾーンのバグ。隣り合ったテーブルで、片方は割引前、もう片方は割引後の revenue_usd フィールド。

アナリティクス層を所有している人と1週間一緒に過ごしてください。ノートブックを持参して。「このテーブルをクエリする前に知っておいてほしいことは何ですか？」と聞いてください。3週間dbtのドキュメントを読むより、その1つの質問から多くの価値が得られます。

30日目までには: 監査スプレッドシート、5つのステークホルダーミーティングのメモ、1ページの「データウェアハウスの落とし穴」ドキュメント、そして進行中の新しいモデルがゼロの状態になっているはずです。

31〜60日目: 廃止、出荷、提案

いよいよ目に見える成果を出し始めます。3つの成果物、この順番で。

壊れたモデルを1つ廃止する、メモとともに、公式に

キャリアに終わりをもたらすように聞こえます。逆です。壊れたモデルを廃止することは、新任DSができる最もレバレッジの高い行動です。なぜなら:

計算リソース、チームの注意、ステークホルダーの帯域幅を解放します。
スループットだけでなく判断力を持っていることを示します。
モデルが間違っている場合に「モデルを出荷すること」は美徳ではないことを確立します。

監査から最悪の候補を選んでください。典型的な候補は: 18ヶ月で2度再学習され、特徴量ドリフトが22%、実際のリテンション施策を促していない（CSチームはスコアを無視している）、計算コストが月400ドルかかっている解約モデルです。1ページのメモを書きます。モデルが何を主張していたか、実際に何をしていたか、コストはいくらか、どの意思決定を促すはずだったか、何で置き換えることを提案するか（多くの場合「週次で更新されるシンプルなコホートレポート」）。

マネージャーと元のステークホルダーにメモを送信します。返答を待ちます。9回中9回、「そうですね、数ヶ月前から見なくなっていました」という答えが返ってきます。これで紙の記録とともに廃止完了。そして、作業が結果を出していないときに自分の作業を削減できることをリーダーシップに示しました。

機能するシンプルなテンプレート:

メモ: [モデル名] モデルの廃止
著者: [あなた]
日付: [日付]

今日何をしているか: [1文]
立ち上げ時に何をすると主張していたか: [指標と値]
直近90日で実際に何をしているか: [指標と値]
計算コスト: [$/月]
促している意思決定: [リスト、答えが「なし」なら正直に]
推奨事項: [日付] までに廃止。[シンプルな代替案または何もしない] で置き換える。
廃止しない場合のリスク: [継続的なメンテナンス + 古い予測への誤った信頼]

それだけです。1ページ。付録なし。

ステークホルダーが実際に依頼したクイックウィン分析を1つ出荷する

ステークホルダーミーティングのメモに戻ります。最も小さくて具体的な依頼を見つけます。明確な意思決定が紐づいた、誰かが何気なく言ったもの。「AIを使うべき」ではなく、「最初の14日間で最もドロップオフを引き起こしているオンボーディングのステップが分かればいいのに」のような具体的なもの。

それをやります。Slack向けの短い文書。グラフは最大3つ。1段落目に推奨事項。依頼した人とそのマネージャーに共有します。Kaggleコンテストで勝とうとしているのではありません。10営業日以内に実際の質問を実際の回答に変換できることを証明しているのです。

2〜3つのビジネス指標に紐づいた6ヶ月のMLロードマップを提案する

60日目までには、ロードマップのドラフトを作れるだけのコンテキストが得られているはずです。ビジネス指標は最大2〜3つ。それぞれに1〜2文の仮説、モデルまたは分析のアプローチ、工数の見積もり（小・中・大）、そして最も重要な終了基準（これを止める根拠となるもの）。

終了基準こそがロードマップをウィッシュリストと区別するものです。「8週目までにベースラインの改善が5%を下回ったら止めて再配分する」はロードマップの1行です。「解約モデルを作る」はそうではありません。

あなたを採用したエグゼクティブにロードマップを共有します。フィードバックをもらいます。修正します。目標は、そのエグゼクティブがあなたの次の2四半期をC-suiteの誰にでも1文で説明できるようにすることです。

61〜90日目: 1つの指標を所有し、発表し、下半期を計画する

最後の30日間は「新しいDS」から「Xを所有する人」に移行することです。

モデルに紐づいた1つのビジネス指標を所有する

ここでのフレーミングが重要です。モデルではなく指標を所有します。「解約モデル」を所有すると、あなたが設計していないものの誰かのアイデンティティを引き継ぎ、それで評価されます。「SMBセグメントの12ヶ月ロゴリテンション」を所有すると、その数字を動かすモデル、分析、業務改善のあらゆる組み合わせを使えます。

1つ選んでください。たった1つ。それは:

ファイナンスとエグゼクティブチームがすでに追跡している指標（新しい指標を発明しない）
あなたの影響圏にあるもの（モデルが関わるが、CSのワークフロー、価格設定、プロダクトも関わる）
60〜90日のウィンドウで測定可能なもの、12ヶ月ではなく

B2B SaaSの新任DSに良い選択肢: SMB解約率、リード-商談コンバージョン、フリートライアルから有料コンバージョン、CSM1人あたりの拡張収益。悪い選択肢: 総収益（インプットが多すぎてクレジットが得られない）、NPS（ノイズが多すぎる）、「モデルの精度」（ビジネス指標ではない）。

あなたを採用したエグゼクティブへの90日レポートを発表する

15分の会議。5枚のスライドデッキ。機能する構成:

何を発見したか。 監査を1つのグラフで（廃止されたモデル、健全なモデル、要観察のモデル）。
何を出荷したか。 クイックウィン分析、廃止メモ、今所有している指標。
ビジネスについて何を学んだか。 驚いた2〜3のこと（データ品質の問題、データに基づかずに下されている意思決定、繰り返し上がってくる依頼）。
ロードマップ。 終了基準付きの6ヶ月計画。
何が必要か。 ヘッドカウント、インフラ、ステークホルダーのアクセス、意思決定。

5枚目のスライドが最も重要で、最もよく省かれます。次の90日間に成功するために何が必要かを明確に言えなければ、エグゼクティブは何も必要としていないと思い込み、6ヶ月後に進捗が止まった理由を不思議に思います。

ヘッドカウント、インフラ、終了基準を含むH2 MLプランを提案する

これは60日目のロードマップを3ヶ月のコンテキストで研ぎ澄ましたものです。元のロードマップにはなかった3つのことがH2プランに入ります:

ヘッドカウントの計算。 「このプランを実行するには四半期あたりXエンジニアリング日数とYデータエンジニアリング日数が必要です。今日はZあります。ここにギャップがあります。」具体的に。MLエンジニアは高価です。データエンジニアリングのキャパシティは大半のB2B SaaSショップでDSの仕事の60%のボトルネックであり、それを早く口に出すことで、自分のせいではない納品の問題の責任を負わされることから守られます。
インフラの必要性。 フィーチャーストア？実験管理？管理された推論プラットフォーム？おおよそのコストとともにリストアップ。CFOはQ3で3万ドルの驚きよりも、今3万ドル/年の項目を見る方がよいでしょう。
終了基準、更新版。 6ヶ月の作業では、どの賭けが間違っていたかが常に明らかになります。いつ始めるかだけでなく、いつ止めるかをコード化してください。

CFOがROIについて聞いてくる会話

この会話は必ず来ます。おそらく5週目か6週目に。たいていこのような感じです。「それで、AIへの投資のリターンはいつから見え始めますか？」

間違った答え: 「長期的な投資です」「AIには時間がかかります」「まだ実験段階です」。これらはすべて真実です。どれも機能しません。CFOは正当な質問をしており、正当な答えに値します。

機能する答え:

「今は監査モードです。月約X円のコストがかかりながら何の意思決定も促していないモデルを2つ見つけ、月末までに廃止します。90日目までにSMB解約指標を所有し、あなたがすでに追跡しているビジネス指標に紐づいた、それぞれに終了基準を持つ2〜3の賭けとともにロードマップを持ちます。『いつリターンが見え始めるか』への正直な答えは: 私が正しければQ3末、間違っていれば十分早く気づいて方向転換できます。」

これがフレーミングです。具体的な近期のアクション、1つの所有する指標、日付、そして賭けが外れた場合の素早い失敗の計画。CFOは終了基準に好反応を示します。Data Scientistがそれを言及するのを一度も聞いたことがないからです。

最初の90日を静かに沈める一般的な落とし穴

経験豊富なDSの採用者でさえ引っかかるいくつかのトラップ:

「生産的に見えるため」に2週目に構築する。 そのモデルの責任を永遠に負うことになります。抵抗してください。
実際の意思決定をスコープせずに「AIを使う」依頼にYesと言う。 VPが「[曖昧なこと]にAIを使えますか？」と言ったとき、正しい答えは「その出力によってどんな意思決定が変わりますか？」です。答えられないなら、プロジェクトはまだ存在しません。とにかく作ると言わないでください。（曖昧なAI依頼のスコーピングはここを深く掘り下げています。）
壊れた解約モデルをKPIとして引き継ぐ。 モデルはツールです。リテンションが指標です。指標を所有してください。
データエンジニアリングの税を無視する。 最初の1年の60%の時間はデータの配管作業に使われます。パイプラインの修正、結合のデバッグ、ウェアハウスの数字がBIツールの数字と一致するかの検証。そのための余裕を持ってください。20%で済むふりをしないでください。

90日目の成功の測定

成功した最初の90日の正直なテストは「モデルを出荷したか」ではありません:

上位3つのビジネス指標と、それぞれにどのモデルが関わっているかを言える
壊れたモデルが1つ廃止され、記録がある
クイックウィン分析が1つ出荷され、依頼者からクレジットを得た
5つではなく1つの指標を所有している
あなたを採用したエグゼクティブがあなたのロードマップを1文で説明できる

91日目にこの5つが当てはまるなら、強い1年への準備が整っています。9ヶ月目にバーンアウトするData Scientistは、ほとんどの場合1ヶ月目に新しいモデルを作り、その後の8ヶ月をそれを守ることに費やしています。

Data Scientist 実践ガイド