データサイエンティストの一日
Turn this article into takeaways for your work.
Each assistant summarizes the article only for you and suggests best practices for your work.
朝8時07分。午前6時42分にMLflowからのモデルの劣化アラートでスマホが鳴りました。PMは7時55分にSlackのDMを送ってきました：「ちょっと聞きたいんだけど、このユーザーがなぜ解約フラグ立てられたの？」まだラップトップを開いていません。LinkedInで正確に説明されることのない仕事へようこそ。
サインアップした職務記述書は「MLモデルを構築し、インサイトを引き出し、ステークホルダーとパートナーになる」と約束していました。技術的にはそれはすべて本当です。比率が違います。B2B SaaS企業でのある火曜日、モデル構築は一日の多分4分の1です。特徴量エンジニアリングとSQLの配管がさらに大きな塊を占めます。残りは翻訳作業です：VPになぜ精度は正確度ではないかを説明すること、営業リーダーに信頼区間を正当化すること、誰も見ないLoomを作ること、そしてプラットフォームチームに毎水曜日に壊れるdbtモデルが相変わらず壊れていることを思い出させること。
これはLinkedInのシニアデータサイエンティスト版の仕事ではありません。実際のものです。3ヶ月経ってもインタビューした時のロールと一週間が似ても似つかないなら、それはあなたのバグではありません。ロールがそうなのです。
本当の火曜日がどんな一日かを紹介します。
午前8時〜8時30分：モデルパフォーマンスの確認
コーヒーを持ってラップトップを開くと、最初のタブは常にMLflowかWeights & Biasesです。前夜に来たラベルと照合して昨日の予測を確認します。週末で解約モデルのAUCが0.84から0.79に下がりました。大惨事ではありませんが、スタンドアップ前に調査するには十分です。
まず分かりやすいことを確認します。入力分布がシフトしましたか？ 特徴量ドリフトダッシュボードを開きます。2つの特徴量がドリフトしています。1つは「最終ログインからの日数」で、製品チームが金曜日に新しいオンボーディングフローをリリースして多くの古いユーザーが再度引き込まれたため、これは意味をなします。もう1つは「過去30日間のサポートチケット数」で、明らかな説明がありません。スタンドアップ後に掘り下げるメモを取ります。
この30分間のチェックは仕事で最も過小評価される部分の1つです。私が知っているシニアデータサイエンティストの半分は、他の誰も見つけなかったことをここで発見した強みで昇進しました。モデルは壊れませんでした。モデルが学習した世界がわずかに変わり、他の誰かより先に気づいたのです。
また、MLflowで昨日の実験ランを確認します。チームメンバー2人が夜11時に学習ジョブを起動しました。1つは収束しました。1つは誰かがソーステーブルのカラム名を通知なしに変更したため爆発しました。データ作業へようこそ。
午前9時30分〜11時30分：実験デザイン（指標についての議論で90分）
PMがスタンドアップに質問を持ってきます：「新しい価格ページのコンバージョンはより良いですか？」簡単でしょ？ サンプルサイズ、2比率検定、リリース。
決してそんなに簡単ではありません。
Hexで実験をスコープするのに90分を費やします。数学は簡単な部分です。実際に時間を食うのはこちらです。
「勝利」の定義。 PMは「無料トライアルを始める」ボタンのクリック数を測定したいと思っています。クリック数はスタート数と同じではなく、スタート数はアクティベーション数と同じではなく、アクティベーション数は有料転換数と同じではないことを指摘します。終わる頃には成功指標が3回変わり、アクティベーション後に既知のリークがあった旧価格ページのファンネルにより、初週の維持率のガードレール指標が追加されます。
検定力計算の現実確認。 現在の週次トラフィックで、有料転換の3%相対リフトを検出するには6週間のテスト実行が必要です。PMは2週間で結果が欲しいと思っています。早期読み取りにはノイジーな代理指標（トライアル開始）、最終判断には本当の指標（有料転換）に合意します。
ガードレール指標。 新しいページがトライアル開始を増やすが、それらのトライアルの質を下げるとしたらどうでしょう？ アクティベーション率のガードレールを追加します。プランティアの選択ミックスを変えるとしたら？ 新規顧客の平均収益のガードレールを追加します。今、3つの指標、2つのガードレール、ストップルールがあります。
セグメンテーションの事前コミット。 PMは「後で会社規模でスライスできますか？」と尋ねます。「いいえ」と言い、次に「はい、ただしBonferroni補正とテスト開始前に書き留めたセグメントのリストとともに」と言います。一緒にリストを書きます。後に誰かのキャリアを救います。
実験デザインドキュメントをチームのHexワークスペースに公開し、プロジェクトのNotionページにリンクし、PMとエンジニアリングリードにタグを付けます。数学は15分かかりました。会話は75分かかりました。そのレシオはキャリアの残りでおおよそ正しいです。
午後12時30分〜2時：本番デプロイについてエンジニアリングと非同期作業
デスクでランチを急いで食べます。午後のブロックは新しいデータサイエンティストが最も不満を感じる部分です：モデルは3週間「リリース準備完了」で、ブロッカーはモデルとは全く関係ありません。
モデル自体は問題ありません。問題は特徴量パイプラインです。解約モデルにはweighted_engagement_30dという特徴量が必要で、これは過去30日間のログイン、メッセージ送信、ミーティング参加の重み付き合計です。その特徴量はfct_user_engagement_dailyというdbtモデルで計算されます。dbtモデルはSalesforceの同期が不定期に完了するため、毎水曜日の朝6〜7時（太平洋時間）に壊れます。
dbtモデルを所有しているのはあなたではありません。アナリティクスエンジニアリングチームです。彼らは壊れやすいことを知っています。チケットがあります。2ヶ月間そのチケットがあります。
今日の仕事はステージングデプロイに長いPRコメントを書くことです。説明します。
- 特徴量パイプラインに既知の週次障害ウィンドウがある
- モデルは最大24時間の鮮度でその特徴量が必要
- dbtモデルの現在の監視は特徴量が既に古くなってから発火する
- プラットフォームチームに上流のdbtモデルを修正するか、または鮮度フラグ付きで特徴量の最後の良いスナップショットを使うフォールバックを組み込んでほしい
プラットフォームチームリードにタグを付け、証拠として先週水曜日のdbt監視アラートをリンクし、モデルの鮮度要件ドキュメントをリンクします。エスカレーションしません。不満もこぼしません。希望順にランク付けされた3つのオプションとデフォルト推奨を持つ冷静で具体的なPRコメントを残します。タブを閉じます。
これがJDで「クロスファンクショナルコラボレーション」と呼ぶ部分です。ほとんどの場合、修正できない何かが他の誰かによって修正されるのを待ちながら、間欠的に冷静に主張することです。早く折り合いをつけてください。
午後2時〜3時：「この予測は間違っている」ミーティング
セールスリーダーがカレンダーに30分予約しています。件名：「解約モデルについてちょっと話したい、フラグ立てた顧客の1人が3年間更新した」。
このミーティングの展開が分かります。入社以来これを約14回経験しています。スクリプトがあります。だいたいの形はこうです。
好奇心から始め、防衛からではない。 「その顧客について教えてください。どんなストーリーですか？」セールスリーダーに5分間、モデルがチームを恥ずかしくすること、顧客がそれを知ったら怒ること、モデルが信頼できないと感じていたこと、について話させます。
バカにせずに指標を再フレーミングする。 「モデルは「ハイチャーンリスク」コホートで87%の精度で予測します。つまりモデルがフラグを立てた100アカウントのうち、約87社は実際に90日以内に解約します。残りの13社はしません。このアカウントはその13社のうちの1社です。それはモデルの失敗ではありません。設計通りのパフォーマンスです。」
防衛的なトーンではなくLookerダッシュボードを持参する。 画面を共有し、解約モデルパフォーマンスLookerを開きます。精度-再現率曲線を見せます。チャーナーをより多く検出するためにしきい値を下げると偽陽性がさらに増え、上げると本当のチャーンを見逃すことを見せます。先四半期に検出したチャーンのドル価値（$2.4M）対すべてのフラグ立てアカウントが去った場合の偽陽性のドル価値（それよりはるかに高いが、今は言いません）を見せます。
彼らの言語でモデルの目的を締めくくる。 「このモデルはトリアージツールです。判決ではありません。チームが週の最初の1時間をどこに費やすかを伝えます。フラグ立てされた1アカウントが更新したという事実は、チームが仕事をしたことを意味します。介入しました。それが成功条件です。」
セールスリーダーは来たときより落ち着いてコールを終えます。会話を実験ログに追加します。次月のDS-営業定期同期に「精度は正確度ではない」というスライドを追加します。この会話を14回経験しているなら、残りの営業組織はそれ以上の頻度でこの会話をしているはずです。
午後4時〜5時30分：ノートブックのクリーンアップと実験ログ
一日の最後のブロックはJupyterに戻ります。今朝の価格ページ実験スコープの分析ノートブックを開きます。混乱しています。スケッチコードが半分あります。コメントなしでdf.head()だけのセルがあります。軸ラベルのないチャートがあります。間違ったスキーマに対するSQLクエリがあります。
クリーンアップします。ここでの規律はきれいさよりも重要です。自分のためにきれいにしているのではありません。なぜサンプルサイズを5,000ではなく4,200にしたかを覚える必要がある3ヶ月後の自分のために読みやすくしています。チームの規則：
- 質問、日付、結論を含むノートブックの先頭のMarkdownセル
- 各セクションにコードの上に1行のMarkdownヘッダー
- チャートにはタイトル、軸ラベル、下に1文の解釈
- 最後のセルは推奨と次のアクションを含むMarkdownセル
ノートブックをチームリポジトリにコミットします。チームの実験ログ（共有のNotionページにある）に200語のサマリーを書き上げます。今朝書いたdbtモデルの変更もプッシュします。別ブランチで、明日レビューにタグ付けされます。
ラップトップを閉じる前の最後のこと：午後2時のセールスリーダーミーティングのノートを確認し、チームのバックログにTODOを追加します。「解約モデルの精度と再現率を平易な日本語で毎週更新するセールス向けLookerダッシュボードを構築する。」3回目にそれを考えました。今週こそ実際に作るかもしれません。
JDが伝えないこと
初日に知っておく価値のある、JDが流してしまうことをいくつか。
PythonよりSQLをより多く書きます。 SnowflakeまたはBigQueryが第二言語になります。SQLがクリーンであるほど、イテレーションループが速くなります。一週間のほとんどのボトルネックはモデリングではありません。「データがまだ正しい形になっていない」です。
特徴量エンジニアリングがモデリング時間の40%を食います。 XGBoostモデルの学習は20分かかります。それに入る特徴量は、構築し検証しパイプラインに組み込むのに2週間かかりました。新しいデータサイエンティストは毎回これを過小評価します。
最も難しい「ML問題」は通常アウトプットを信頼しないステークホルダーです。 公開に値するAUCで美しくキャリブレーションされたモデルを持てますが、誰も行動しないためインパクトがゼロになりえます。信頼は繰り返し可能な説明、ステークホルダーの言語でのダッシュボード、「この予測は間違っている」ミーティングに冷静に参加することで構築されます。
「この予測は間違っている」パニックは週次のイベントです。 スクリプトを準備しておいてください。ダッシュボードを持参してください。防衛的にならないでください。会話は仕事であり、仕事の邪魔ではありません。
本番デプロイは思うより遅いです。 コードが難しいからではありません。データの依存関係が不安定で、ステージング環境が先四半期の本番のミラーで、プラットフォームチームも最善を尽くしているからです。
実際に使うツール
スタックは会社によって異なりますが、形は一定しています。2026年の本物のDS機能を持つほとんどのB2B SaaS企業で：
- PythonとJupyter（分析とモデリング向け）。一部のチームは重い作業をVS Codeとノートブック-パーセントファイル形式に移しましたが、Jupyterはまだ探索のデフォルトです。
- SnowflakeまたはBigQueryのSQL（本番データに触れるすべてのもの向け）。Postgresを直接使う場所から来た場合、倉庫のメンタルモデルは異なり、クエリあたりのコストを初めて考えます。
- dbt（変換向け）。書くより読むdbtモデルの方が多いですが、いくつかは書きます。
- MLflowかWeights & Biases（実験管理向け）。ほとんどのチームはどちらか一方を持っています。どちらかはほとんど問題になりません。
- Hex（PMやアナリストが読める協働ノートブック向け）。HexはFigmaがデザインに対してしたことをアナリティクスに対してしています。
- Looker（ステークホルダー向けダッシュボード向け）。ここで構築するダッシュボードは、それを支えるモデルが実際の作業であっても、ステークホルダーがあなたを判断するものです。
- オプションだが一般的： オーケストレーションにAirflow、Prefect、またはDagster。所有するかどうかはチームによります。
すべてのチームでこれらすべてを使うわけではありません。最初の90日で新しいものを学ぶことになるでしょう。
90日後の「良い状態」
新しいロールに就いたばかりなら、3ヶ月時点での成功の有用な定義があります。モデル数は忘れてください。これらを見てください。
- ドキュメントを参照せず、ステークホルダーのトップ3の本当の問いを、彼らの言語で言えます。
- 1つのモデルが本番にあります。小さくても構いません。1つのフィーチャーに対するロジスティック回帰でも。本番はノートブックに勝ります。
- ステークホルダーが「この予測は間違っている」とpingしても、もうドキドキしません。スクリプトがあります。ダッシュボードを持参します。
- 毎週壊れるdbtモデルと不安定な特徴量を知っています。水曜日の障害にもう驚かなくなりました。
- チームの別のデータサイエンティストがリンクしたドキュメントを少なくとも1つ書きました。忘れられる分析に勝る知識の蓄積。
それがバーです。「5つのモデルをリリースした」や「チームのベロシティを2倍にした」ではありません。それらの指標は現実に接触すると生き残りません。上のリストは生き残ります。
技術的な作業と翻訳作業の50/50の分割はロールの欠陥ではありません。それがロールです。翻訳はモデリングの下ではありません。それがモデリングが実際に何かを変える方法です。同世代より早くそこに踏み込むデータサイエンティストが、30ヶ月ではなく18ヶ月でシニアに昇進する人です。
明日の朝6時42分にまたモデルの劣化アラートが鳴ります。先に朝食を食べてください。
関連ガイド
Principal Product Marketing Strategist