ビジネスアナリストの1日（B2B SaaS、ICトラック）

ラップトップを開く前に、MRRが下がっている理由を尋ねるSlackメッセージが11件届いています。どれも間違っていません。どれも同じ答えではありません。

あるPMはdbtモデルから引っ張っているエグゼクティブダッシュボードを見ています。そのモデルは午前5時に実行されました。あるCSMはMRRをコミット済み契約金額として定義するSalesforceレポートを見ています。財務VPはまだ請求されていないものを除外する収益認識ビューを見ています。どれも正しく、全員が異なる数字を見ていて、9時半までに誰かが「本当のMRR」はどれか聞いてきます。その答えを出すのに20分、守るのにさらに20分かかります。火曜日へようこそ。

JDが約束したこと vs 火曜日の現実

職務記述書には「ビジネスインサイトを推進する」「戦略的意思決定においてリーダーシップと協力する」とありました。受け入れました。実態は、私の週は大体60%がSQLとデータの配管仕事、30%がエンジニアリングとプロダクト（そして営業、財務、そして音声メモでしかコミュニケーションしないそのCSディレクター）の間の翻訳業務、そして10%が実際の分析です。インサイトは配管がきちんと動いているときのみ生まれます。ダッシュボードを緑に保てないBAは、戦略の席に招かれることはありません。地下室でパイプの修理をしているから忙しすぎるのです。

これが普通の1日の時間別の記録です。スタック: ウェアハウスはSnowflake、変換はdbt、BI（アドホック向けのHexノートブックも）はLooker、仕様はNotion、チケットはJira。

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

Slackメッセージに1件も返信する前に、毎朝同じ5分間のパスを実施します。

dbtの実行は完了したか？ dbt Cloudのジョブ概要を確認します。全体的にグリーンか、午前4時47分に誰かがスキーマ変更をリリースしたためにfct_revenueが失敗したか？
エグゼクティブダッシュボードの鮮度タイムスタンプ。 エグゼクティブのLookerダッシュボードを開きます。「最終更新」タイルは「今日、午前6時頃」と表示されているべきです。「昨日」と表示されていたら、上流が古くなっています。
前日比の行数。 ウェアハウスに対する3つのクエリ（注文、商談、アクティブアカウント）。行数が5%以上減少していれば、上流のFivetranの同期が壊れています。
上位3つのKPI。 新規ロゴ数、MRR、グロス維持率。正常な範囲内か、それとも「定義が壊れた」と叫ぶような前週比40%スイングが1つあるか？
「昨夜誰かがセマンティックレイヤーに触れたか」のチェック。 過去12時間のLookMLリポジトリのマージを確認します。

Snowflakeにピン留めしているサニティチェッククエリがこれです。5秒未満で実行されます。

select
  date_trunc('day', created_at) as day,
  count(*) as orders,
  sum(amount) as gmv
from analytics.fct_orders
where created_at >= dateadd('day', -7, current_date)
group by 1
order by 1 desc;

今日の行が欠けているかGMVが大きく振れていれば、CEOよりも先にわかります。それが全部です。壊れたJOINを午前8時5分に発見するのは3分の修正です。全社ミーティングが始まった後の午前9時35分に発見するのは90分の火消しとお詫びメールです。

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

キューは3か所あります、当然のように。正式な依頼用のJiraの受付ボード。「簡単な質問」用の#data-helpSlackチャンネル。そして1人のDirectorがJiraの使用を断固拒否してAsksを追加し続けている共有のNotionページ。3つすべてを確認します。

今朝: 5件の新規依頼です。私の仕事は答えることではありません。トリアージすることです。

「先四半期のプランティア別の解約率を引き出せますか？」 ブロッキング。CFOが木曜日のボードデッキに必要です。セマンティックレイヤーがクリーンなら、これは15分のクエリです。fct_subscription_eventsにまだ古いplan_idのJOIN問題があれば、2時間です。見積もり: 30分。引き受けます。
「興味本位ですが、トライアルユーザーの何人がLinkedInから来ていますか？」 興味本位で、ブロックされていない。マーケティングダッシュボードには既に獲得ソースの内訳があります。スクリーンショットとリンクで返信します。2分。
「業界別のQ1の勝率を知りたい。」 営業パフォーマンスのLookerダッシュボードに既にあります。リンクと適用するフィルターについての1文を送ります。3分。
「新しい価格実験のダッシュボードを作れますか？」 本物の仕事です。このダッシュボードが推進すべき意思決定をスコープするための30分の会話が必要で、SQLクエリではありません。返信:「了解しました。木曜日に20分でこのダッシュボードが推進すべき意思決定のスコープを設定しましょう。」
「CSダッシュボードのこの数字が変に見えます、確認してもらえますか？」 何もないかもしれないし、全てかもしれない。開きます。数字は問題ありません。誰かが指標の名称を変更したためにレジェンドが間違っています。LookMLで10分の修正です。

私の正気を救ったトリアージルール: 「ブロック中」と「興味本位」を切り分けること。 ブロック中とは答えがなければ意思決定が前に進めないことを意味します。興味本位とは誰かがLookerのexploreにいて好奇心をくすぐられたことを意味します。興味本位はセルフサービスに案内します。ブロック中はキューの最上位に来ます。すべてが「ブロック中」なら、何もブロック中ではありません。

私がいるデータチームは3人です。私たちにわたって、週に8から12件の正味新規アドホック依頼があります。トリアージなしでは、キューが仕事全体を食い尽くします。

午前11時: 昼頃の要件インタビュー

PMが私のカレンダーに45分ブロックします。議題:「エンゲージメントダッシュボードのスコーピング。」以前にもここにいました。PMは「エンゲージメントのダッシュボード」を望んでいます。それは依頼ではありません。感覚です。

このミーティングでの私の仕事は、ダッシュボードが推進する実際の意思決定に到達し、そこから虚栄の指標でない2つか3つの指標に逆算することです。私が使う質問スクリプトがあります。ミーティングが始まるとNotionドキュメントで文字通り開いています。

このダッシュボードを見た後、あなたはどんな意思決定を違うようにしますか？（答えられなければ、ダッシュボードは虚栄の依頼です。ここで止まります。）
他に誰が見る必要があり、彼らはどんな意思決定をしますか？
どの頻度で見ますか（日次、週次、月次）？（日次はダッシュボードではなくSlackアラートが必要を意味します。）
どの数字が変わったら、今週何かをしますか？
閾値は何ですか？「良い」対「悪い」とは何を意味しますか？
既にあって、これにほぼ近いが完全ではないものは何ですか？（既存のLookerのexploreが80%をカバーしていることがよくあります。）
2つのグラフしかリリースできないなら、どちらが最も重要ですか？

今日のPMは「エンゲージメントダッシュボード」と言いました。それらの質問を30分した後、実際に必要なのは1つのグラフ（フィーチャーコホート別の週間アクティブユーザー数）とWAUが前週比10%以上下落したときのSlackアラートです。構築工数: 半日。額面通りに受け取った元の依頼: おそらく最初のスプリント後に誰も開かないものに2週間。

「ダッシュボード」を依頼するPMは、通常1つのグラフとSlackアラートが必要です。私の経験では、大体70%の確率で。

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

ランチはdbt PRをレビューしながらデスクでサンドイッチでした。これが翻訳の仕事の部分で、インタビューで誰も教えてくれない部分です。

dbt PRにコメントする。 アナリティクスエンジニアがdim_accountsをリファクタリングして、列の名称をaccount_owner_idからowner_user_idに変更しています。PRの説明は古い名称を参照する4つのダウンストリームのLooker exploreについて言及していません。影響を受ける各exploreへのリンクと、（a）後方互換性のためのカラムエイリアスが必要か、（b）同時にリリースされるコーディネートされたLookML PRが必要か、というノートを残します。この10分のコメントが明日の午前9時に「なぜ営業ダッシュボードが壊れているのか」という3件のSlack DMを防ぎます。

プロダクト仕様書に返信する。 PMが新しいアプリ内オンボーディングフローの仕様書を書いて、「各ステップのエンゲージメントをトラッキングできますか？」とタグをつけました。イベントトラッキングを見ると、彼らが欲しいイベントが存在しません。現在のプロダクトのインストルメンテーションはonboarding_startedとonboarding_completedのみを発火します。彼らが本当に気にしていること（ユーザーがどこでフローから離脱するか）に答えるためには、ステップレベルのイベントが必要です: step_nameプロパティを持つonboarding_step_viewed。それを仕様書に書き込み、Notionの既存のトラッキングプランを案内し、エンジニアリングのバックログにそれらのイベントを追加するJiraチケットを作ります。

これがどのダッシュボードにも表示されないけれど、再採用されるBAとそうでないBAを分ける仕事です。エンジニアリングはテーブルとスキーマで話します。プロダクトはフィーチャーと成果で話します。ステークホルダーは感情とSlackメッセージで話します。BAは3つすべてを橋渡しします。昼食前にdbt PRをレビューすると、昼食後のLookerの停止を防ぎます。それが仕事です。

午後3時: 退勤前のエグゼクティブデータプル

営業VPから午後2時55分にピンが来ます。ボードプレップの通話が4時にあります。セグメント別、ステージ別に分類し、ステージ確度で重み付けしたQ-to-dateのパイプラインが必要です。スライドが今作られています。

SQLは問題ありません。このカットに対してまさにそのような保存済みクエリがあります。大体このような感じです。

select
  segment,
  stage,
  count(*) as opps,
  sum(amount) as pipeline_amount,
  sum(amount * stage_probability) as weighted_pipeline
from analytics.fct_opportunities
where close_quarter = 'Q2-2026'
  and is_active = true
group by 1, 2
order by 1, 2;

難しいのはクエリではありません。注記事項です。VPはスライドに1つの数字を望んでいます。どれにするかを決めてなぜかを伝えなければなりません。3つの選択肢、どれも弁護できます。

パイプライン金額（生の合計): 最大の数字、見栄えが良い、クローズする確率が10%の商談も含む。
重み付けパイプライン（合計 × ステージ確度): より正直で、小さく、ほとんどのCFOが好む。
コミット済みパイプライン（ステージ4以上のみ): 最も保守的、QBRで報告するもの。

1段落のノートと共にデータを送ります:「スライドには重み付けパイプラインを使うべきです。それが先四半期にCFOがプレゼントしたものであり、今四半期に別の定義を使うと『なぜ方法論を変えたのか』という質問が飛んでくます。VPがナラティブのために生の数字を望むなら、脚注として記載します。」

データに4分。推奨に12分。推奨が来四半期も私を招いてもらえる理由です。

午後4時30分: 「このレポートが間違っている」パニック

タイミングよく。CSディレクターからSlackが来ます。「ねえ、CSダッシュボードの4月の新規ロゴ数が47と表示されているけど、Salesforceは52と言っている。確認してもらえる？」

これが仕事で最も一般的な緊急事態で、ほぼ常に同じ根本原因です。私が実施する20分のデバッグをこの順番で示します。

定義の確認。 ダッシュボードは「新規ロゴ」を何と呼んでいますか？Lookerではis_first_paid_invoice = trueでフィルタリングされています。Salesforceのレポートはopportunity_stage = 'Closed Won'かつaccount_type = 'New Logo'でフィルタリングされています。これらは異なる定義です。商談はClosed Wonでも支払い済み請求書がまだない場合があります（5日間の請求ラグ）。それだけで通常5件の差を説明できます。
タイムゾーンの確認。 Salesforceはユーザーのローカル時間でレポートします。LookerダッシュボードはUTCです。太平洋時間の4月30日はUTCでは5月1日です。常に1つか2つの商談がここに引っかかります。
フィルターの確認。 SalesforceレポートはリニューアルやアップグレードをなんらかのかたちIで含んでいますか？「新規ロゴ」フィルターが誤設定されていることがあります。
データの鮮度の確認。 SalesforceからSnowflakeへの同期は最後にいつ実行されましたか？10分前に実行されていれば問題ありません。6時間前に実行されていれば、それ以降に2件以上の商談がクローズしている可能性があります。
実際のデータバグ。 最初の4つを排除した後のみ、上流の問題を確認します。

今日の答え: 定義の不一致。LookerはPaid invoiceを使用、SalesforceはClosed-wonを使用。どちらも「正しい」ですが、異なる質問に答えています。Lookerの数字はCSチームの目的に対して正しいもの（書類上のクローズではなく支払い済み顧客を祝うべき）ですが、来月再び起きないようにダッシュボードの説明に違いをドキュメント化します。

コミュニケーションが診断と同じくらい重要です。「Salesforceのレポートが間違っている」とは決して返信しません。代わりに:「両方とも正しいですが、異なるものを測定しています。それぞれが何を意味するか、今月なぜ違うか、CSのQBRにはどちらを使うべきかを示します。」誰も防衛的にならない。誰もエスカレーションしない。ディレクターは礼を言って先に進みます。

「このレポートが間違っている」はほぼ常に定義の不一致であり、データバグではありません。おそらく80%の確率で。残り20%は本物のバグであり、それはJiraチケットとポストモーテムになります。

午後5時30分: ラップアップ

今朝5件のアドホック依頼が来ました。3件をクローズしました。2件は明日に先送りにし、なぜかを説明するSlackの返信をしました。誰も不思議に思わないように。1件はアナリティクスエンジニアリングのバックログに定期依頼として追加しました。「プランティア別の解約率」のプルは四半期に大体2回来ます。キューに入ってくるのをやめさせるために、セルフサービスダッシュボードにする時期です。1日でやる中で最もレバレッジの高い動きで、2分かかりました。

ラップトップを閉じる前の最後の作業: Notionの日次ログへの1行のメモ。今日リリースしたもの、学んだもの、先送りになったもの。翌朝、11件のSlackメッセージがまた始まったとき、そのログがどの火がすでに燃えていたかを思い出す方法です。

正直なスコアカード

良い1日の終わりに、BAは1つの本物の分析をリリースし（エンゲージメントダッシュボードのスコーピングで2週間のビルドを半日のグラフとアラートに変えた）、3つのステークホルダーをアンブロックし（CFOの解約プル、営業VPのパイプラインカット、CSディレクターの新規ロゴ質問）、1つの間違った数字インシデントを防ぎました（明日のLookerの停止を防いだdbt PRのコメント）。

それが仕事です。「インサイトを推進する」でも「戦略的パートナーになる」でもありません。出勤して、ダッシュボードを緑に保って、互いに話せない人々を橋渡しして、質問の裏にある質問に答える。

実際の戦略的分析の10%は、90%がきちんと動いているときのみ実現します。昇進するBAは、これを入社3ヶ月目に気づいた人たちです。

ビジネスアナリスト Playbook