データアナリストの一日

求人票には「インサイトを推進してビジネス上の意思決定に貢献する」と書いてあった。そして初日の午前8時47分、Slackに届いたのは「ちょっと確認なんだけど、先週のボードデッキとMRRが3,000ドルずれてるのはなぜ?」というメッセージで、その後90分を費やしてデッキが正しいことを証明することになった。

求人票と実際の仕事のギャップが、SaaS企業においてアナリストの年間離職率がおよそ22〜28%に達する理由です。SQL半分、翻訳半分、そして3ヶ月前に自分が書いた数字の説明に4分の1を使うとは誰も教えてくれない。(合計125%になる。その計算がまさに問題の核心です。)

これは、B2B SaaSまたは中堅企業で働く経験1〜4年のData Analyst ICにとっての、実際の火曜日の姿です。LinkedInバージョンではなく、本当の意味での。

なぜ今これが重要なのか

セルフサービス分析ツールが普及して以来、アドホックな依頼の量はほぼ倍増しています。すべてのPMは火曜日までにカスタムコホートを切り出したがり、すべてのVPは金曜日までに自分の仮説を検証してほしがっています。ツールはデータの民主化を約束し、依頼の洪水をもたらしました。

「静かなデスクでモデルを構築し続ける仕事」だと思って入社した人は18ヶ月以内に辞めていきます。残る人は、求人票には一切書かれていないあるスキルを身につけます。それは、レスポンシブに見せながらも自分の思考時間を守ることです。それが上級者の本当のスキルです。

採用担当者がこれを知っていれば、スクリーニングの方法が変わります。アナリストとして働いている方は、パターンを言語化することで乗り越えやすくなります。一日を見ていきましょう。

午前8時, ダッシュボードのヘルスチェック

Slackを開く前に、ステークホルダーが起き出す前に、経営幹部が実際に開く6〜8個のダッシュボードをスキャンします。自分が構築した20個すべてではなく、実際にクリックされているものだけです。

確認するのは3点です。

• あるべき場所にNULLがないか。 昨日の売上数字が空欄になっている。水曜日なのにサインアップ数がゼロと表示されている。
• 昨夜のdbt実行後にテーブル結合が壊れていないか。 モデルがサイレントに失敗して、ダッシュボードが新しいタイムスタンプで古いデータを表示している。これは最悪の種類のバグで、誰かがその数字を使って意思決定するまで誰も気づかない。
• 異常なスパイクがないか。 トラフィックが通常の4倍? マーケティングが知らせずに何かをローンチしたか、トラッキングイベントが二重発火しているかのどちらかです。どちらもCFOが聞いてくる前にSlackで報告しておく価値があります。

すべて問題なければ15分で終わります。問題があれば45分かかります。目的は、CFOが午前9時15分にダッシュボードを開いて「これは正しい?」と連絡してくる前にバグを見つけることです。

朝のチェックが正常に終わることは、見えない仕事です。誰にも評価されません。でも、スキップした日に取締役会メンバーが壊れた数字を見ることになり、その日は静かな100の朝よりもはるかに騒がしくなります。

午前9時30分, アドホック依頼のトリアージ

Jiraのキューに11件の新規チケット。Slackに6件のDM。VP1名から個人の携帯に直接メッセージが来ています。クリスマスパーティーで番号を教えたことを後悔しているはずです。

トリアージは整理であって、解決ではありません。すべての依頼を4つのバケツのいずれかに振り分けます。

• 10分で完了。 件数、リスト、簡単なフィルタリングが欲しい場合。そのままやって、スレッドに答えを投稿して、次に進む。
• 2日かかる分析。 モデル、コホート、またはライトアップが必要な本質的な問い。スケジュールに入れる。
• 重複。 先月誰かが同じことを聞いている。古い答えを探して、リンクして、チケットをクローズする。丁寧に。
• 不明瞭。 依頼がどの意思決定につながるか書かれていない。4時間を無駄にしないために5分で返信して確認する。

その質問とは、**「この結果を使ってどんな決断をするのですか?」**です。

丁寧に言えば「ぜひ調べます。まず確認させてください。データの結果によって何か変わることはありますか?」です。答えが「特にないけど気になっただけ」なら、率直に後回しにできます。「金曜日にトライアルフローを廃止するかどうか決める」という答えなら、優先度を上げます。いずれにせよ、SQL を書く前に仕事を果たしたことになります。

依頼受付フォームとして使えるテンプレートをJira/Linear/どのツールでもよいのでこれをコピーしてください。

**この分析が反映する意思決定:**
**必要な日時:**
**結果を確認する関係者:**
**すでに確認済みの情報:**
**必要な精度（概算か監査レベルか）:**

依頼者がまだ意思決定を持っていないことに気づいて、フィールド1で止まる依頼が半分あります。それは仕様どおりです。

午前11時, 昼間の要件ヒアリング

「チャーンデータが必要」と言ったPMとZoomで30分。

本当の依頼は常に3つ深い階層にあります。あなたの仕事は、相手を愚かだと感じさせることなく、漠然とした状態から具体的な状態へと掘り下げることです。コツは、尋問ではなく診断的な問いを立てることです。

実際に使えるフロー。

1. 言い換えてから広げる。 「チャーンを把握したいということですね。正しく集計するために確認させてください。顧客チャーン、収益チャーン、それともロゴチャーンですか? それぞれ動き方が違います。」
2. 意思決定を聞く。 「この結果を得たらどうしますか? カスタマーサクセスの人員規模を決めるためですか、それともまず直すべきセグメントを特定するためですか?」
3. コホートを定義する。 「"解約した顧客"とは、直近30日以内にキャンセルしたという意味ですか、それともキャンセルして再アクティベートされていないという意味ですか? ダウングレードは含みますか?」
4. 精度の目標を設定する。 「今日中に方向性だけ分かればよいですか、それともQBRに向けた監査レベルの精度が必要ですか? 答えによって作業量が約1日変わります。」

多くのPMは、経営幹部の前で自信なさそうに見られたくないので、提示予定のスライドの言語で依頼します。あなたの仕事は、それをSQLが答えられる問いに翻訳することです。質問することは彼らを否定しているのではなく、「自分で思っているのとは違うことを示すグラフ」を提示する状況から守ることです。

Camelliaのルール: ステークホルダーが要件ヒアリングを終えるとき、成果物が何か、コホートが何か、どの意思決定を反映しているかを、二人で声に出して確認してから終わること。会議後のSlackメッセージ1通に収まらなければ、まだ仕様が固まっていません。

午後1時30分, エンジニアリング・プロダクトとの非同期作業

昼食から午後4時の間が、誰も頼まない仕事をする時間帯です。でも、来四半期を生き延びられるかどうかを決めるのはこの時間です。

これが非同期ブロックです。3種類のインプットがあります。

dbt PRのレビュー。 データエンジニアがfct_subscriptionsモデルのトライアルコンバージョン処理を変更しました。差分を読みます。実際に役立つコメントの例。

この変更は新規トライアルには正しく見えますが、同一四半期内に
コンバートし、ダウングレードし、再コンバートしたアカウントを
二重カウントする可能性があると思います。該当するのは
四半期に約40件あります（先月#data-qualityで確認済み）。
このPRをマージする前に、ステージングモデルで
`subscription_id`の一意性テストを追加できますか?
よければ私が書きます。

具体的で、実際のデータを参照していて、サポートを申し出ており、曖昧な理由でPRをブロックしていません。

プロダクト仕様へのコメント。 PMが新しいオンボーディングフローの仕様を投稿しました。イベントトラッキングのセクションに「ユーザーが完了したらonboarding_completedを発火する」と書いてあります。コメントを残します。「完了」とみなされるのはどのステップですか? ステップ3をスキップした場合は? すべてのフローバリアントでonboarding_completedを発火しますか、それとも別々のイベントにしますか? 今聞かないと、6週間後に不良データを掘り起こすことになります。

スキーマ変更の通知。 エンジニアリングが金曜日に本番環境のカラム名を変更します。Lookerのすべてのexplore、Hexノートブックとdbtモデルでそのカラム名を検索します。4つのダッシュボードが壊れます。エンジニアリングリードにリストをメッセージして、リネームを遅らせるか、カットオーバーを調整します。この20分の作業が、静かな土曜日と、子どもがテレビを見ている間に経営幹部のダッシュボードを再構築する土曜日の違いをつくります。

ここでシニアアナリストはタイトルの価値を証明します。ICはSQLを書きます。シニアは3週間前に壊れを見つけます。

午後4時, 営業終わりの経営幹部向けデータ取得

CFOが明日のボードプレップに向けて3つの数字を必要としています。午後3時47分にメッセージが来ました。ボードミーティングは午前8時です。

これがSQLと重要性が交差する瞬間です。Snowflake（またはBigQuery、またはPostgres）にクエリを発行し、前四半期の報告数字と照合してすべての数字を二重確認します。新しい数字が古い数字と一致しなければ、理由が分かるまで何も送りません。

成果物は3つの数字ではありません。3つの数字とコンテキストです。NotionまたはConfluenceのノートに使えるフォーマット。

**Q1 2026 ボードプレップ向け速報**

1. 純新規ARR: 142万ドル
   (Q4デッキで報告された138万ドルと比較, +3%、誤差範囲内)
   注記: 3/31にクローズ日が設定されたが4/2に計上された
   2件の案件を含む。厳密なQ1ビューは下記参照。

2. ロゴ解約率: 4.1%（年換算）
   厳密なQ1ビュー: 140万ドル、4.4%
   4/28 16:35時点で取得。午前8時までに必要であれば更新します。

3. トライアルから有料への転換率: 18.7%
   (Q4の17.2%と比較, 2月の価格テストコホートによるもので
   一時的な上昇であり、永続的な変化ではありません。
   この数字をそのまま直線外挿しないでください。)

ソースモデル: fct_subscriptions, fct_trials, dim_accounts。
何か見ている数字と一致しない場合はご連絡ください。

4つのポイントと4行の注記。CFOはこれで再確認せずにプレゼンできます。最も重要なのは、取締役会の会議中に「これ、2月に話した数字と違うんじゃないか?」と誰かが言ったとき、CFOはすでに答えを準備できています。

これが昇進につながる仕事です。SQLではありません。その下にある4行のコンテキストです。

繰り返す2つの危機

放置すると一週間を食いつぶす2つのパターンがあります。名前をつけると対処しやすくなります。

危機その1: アドホック爆発

月曜日に「簡単な依頼」に快諾した。依頼者が同僚に「あの人は助けてくれる」と話した。水曜日には4人からDMが来ている。金曜日には18件のチケットがあり、自分のマネージャーが実際に評価する戦略的プロジェクトに使う時間がない。

これが重複依頼のループです。その場でYesと言う方がプロセスを作るより速く、「ちょっとした質問」のひとつひとつは依頼には見えず、ただの会話のように感じられるため、悪化し続けます。

実際に機能するパターン。

• 週2回のオフィスアワー。 誰でも質問を持って来られる60分のブロック。多くの「数字をサクッと出して」系の依頼はこの形式に収まり、Jiraチケットすら不要です。
• それ以外はすべて依頼受付フォームへ。 Slackプロフィールとチャンネルトピックにリンクをはっておく。DM が来たら「優先度をつけるためにフォームに入れてください、リンクはこちらです」と返信する。
• 毎週クローズした内容のダイジェストを投稿する。 金曜日に#dataチャンネルへ。クローズした各チケットについて3行: 誰が依頼したか、何が欲しかったか、答えは何か。検索可能な履歴が蓄積し、重複依頼が減り、実際に何をアウトプットしたかがチームに見えます。

邪魔をしているわけではありません。週10時間の集中作業時間を守っているのです。そこで、本当に重要なものを作れます。

危機その2: 定義の不一致パニック

木曜日の午後5時55分、DirecrorからSlackが来ます。「このレポートはおかしい。アクティブユーザーが週次で30%落ちているけど、マーケティングが見ているのとまったく違う。」

90%のケースで、レポートは正しく、Directorが2つの異なる定義を比較しています。マーケティングはサイトにアクセスした人を「アクティブ」とカウントします。プロダクトダッシュボードは意味のあるアクションを完了した人を「アクティブ」とカウントします。どちらも正確です。そして両者は永遠に一致しません。

トリアージのスクリプト。

1. 緊急性を認め、パニックをもらわない。 「確認します、10分以内に状況をお伝えします。」
2. 数字より先に定義を確認する。 Directorのソースはどのフィールドを使っているか? ダッシュボードはどのフィールドを使っているか? 違っていれば、もう解決しています。
3. 並べて見せる。 「定義が違います」とだけ言わない。2つの数字を定義とともに並べて示す。「マーケティングのソース: ページビューアクティブ、142K。ダッシュボード: アクションアクティブ、98K。アクションアクティブで見れば30%の落ちは本物で、ページビューアクティブで見れば4%の落ちです。」
4. 不一致を記録する。 データディクショナリや定義ドキュメントにメモを追加する。返信にリンクをはる。次回同じことが起きたときは、リンクで返答できます。

Directorは間違っていません。別の定義で見ているだけです。あなたの仕事は、誰もスライドを作り直さずに済むよう、定義のギャップを素早く浮かび上がらせることです。

ツールの実態

実際に触れるツール。

• SQL。 Snowflake、BigQuery、またはPostgres。会社が使っているものを選ぶ。1つをしっかり習得すれば他にも応用できます。ウィンドウ関数、CTE、そしてQUALIFY（SnowflakeおよびBigQuery）が仕事の90%をカバーします。
• BI ツール1つ。 Looker、Tableau、HexまたはMode。それぞれ哲学が異なります。Lookerはセマンティックレイヤー寄り、Tableauはドラッグアンドドロップ視覚化、HexとModeはSQL+Pythonのノートブックスタイルです。会社が選んだものを専門とすることになります。LookMLとTableauの計算構文はきれいには移植できないので、LookerエキスパートとTableauエキスパートを同時に目指さないでください。
• dbtでモデリング。 YAMLを読んでSQLを書きます。会社にデータエンジニアリングチームがあれば、自分でモデルを書くよりもPRをレビューすることが多くなりますが、すべてのダッシュボードの上流にあるものを理解するためにdbtを読める必要があります。
• NotionまたはConfluence。 ドキュメント作成、意思決定記録、4行の注記のために。ツールは何でもよい。大事なのは書き留める習慣です。
• Jira（またはLinear、Shortcut）。 依頼キュー用。会社がエンジニアリングのチケットに使っているものを、データの仕事も同じシステムに流す。データが別のシステムにあると、無視されます。

求人票がこの5つすべてを「必須」かつ「エキスパートレベル」で求めているなら、それは注意のサインです。5つすべてでエキスパートな人はいません。正直なバージョンは、BI ツール1つを深く、SQLは流暢に、dbtは読める、Notionは整理できる、Jiraはレスポンシブに、です。それだけです。

求人票が教えてくれないこと

週の約50%はコミュニケーションと翻訳であり、分析ではありません。要件ヒアリング、Slackスレッド、定義の議論、非同期PRレビュー、営業終わりの注記。SQLは氷山の一角です。

最も使うスキルは「どんな決断をしようとしていますか?」と聞くことです。2番目は、邪魔に聞こえずにNoと言うことです。3番目は、次のアナリストが同じ議論を繰り返さないように意思決定を記録することです。

燃え尽きるICアナリストはSQLが仕事だと思っている人たちです。昇進する人たちはSQLが価値の20%であり、残りの80%はその周辺にあるすべてのもの、つまりトリアージ、翻訳、注記、定義のドキュメント、金曜日のダイジェストだと気づいた人たちです。

それが望む仕事に聞こえるなら、うまくいくはずです。釣り書きと違うと感じるなら、それも正当な反応で、3年後ではなく今知れてよかったと言えます。

関連記事

• データアナリスト職務記述書テンプレート
• アドホックなデータ依頼をトリアージする方法
• ステークホルダーとの要件ヒアリングの進め方
• ディレクターに「この数字はおかしい」と言われたときの対応