新任データアナリストのための最初の30/60/90日

3日目の午前9時47分。VPNの設定がやっと終わったところです。見知らぬ名前からSlackが届きます。「ようこそ! 一つ聞いてもいい? 明日のボードデッキ用にMRRをセグメント別に出してほしいんだけど。ARRバンドと獲得チャネルでスライスするだけ。よろしく!」

このメッセージへの答え方が、次の12ヶ月を決めます。

Yesといってクエリを走らせれば、契約にサインしたも同然です。あなたは今日から「アドホック対応要員」です。週40時間を「ちょっとした依頼」に費やし、戦略的な仕事の成果物はゼロになります。91日目にマネージャーから「何を達成しましたか?」と聞かれたとき、手元にあるのはSlackのアーカイブだけです。

Noといえば、ボードデッキを止めた新人アナリストです。それも問題です。

3つ目の道があります。このガイドはその道です。

アナリストが誰よりも30/60/90日のフレームを必要とする理由

エンジニアにはバックログがあります。PMにはロードマップがあります。デザイナーには動いているFigmaファイルがあります。アナリストが入社するのは、すべてのステークホルダーが自分を最優先だと思っており、前任者がドキュメントを残しておらず、8ヶ月間誰も触れていないダッシュボードが会社のモニターに表示されている職場です。その半分は間違っています。どちらの半分かは誰も知りません。

フレームがなければ、SQLの自動販売機になります。フレームがあれば、30個の壊れたダッシュボードを削除し、正規の収益モデルを1つリリースし、VPが求めていなかったのに突然必要だと気づかれたアナリティクスロードマップを持って下半期の計画会議に臨める存在になれます。

フレームはシンプルです。棚卸し、次に1つ成果物を出し、次に指標を担当する。 3ヶ月、月1つの仕事、先に進まない。

1〜30日目: 作るより棚卸しを

新人アナリストがよくやる最大のミスは、4日目にSQLエディタを開いて何かを「修正」しようとすることです。何が壊れているかまだわかっていません。何が重要な役割を担っているかもわかっていません。どの「壊れた」ダッシュボードがCFOが唯一信頼しているものかもわかっていません。

最初の月は偵察です。クエリはほとんど書きません。メモをたくさん取ります。

第1週: ダッシュボードの棚卸し

BI ツール（Looker、Mode、Tableau、Metabase、引き継いだもの何でも）にあるすべてのダッシュボード、レポート、保存済みクエリのリストを取得します。各項目について5つのフィールドを記録します。

• 名前
• オーナー（不明の場合は「不明」）
• 最終閲覧数（直近60日間）
• 最終編集日
• ステータス（稼働中 / 要確認 / 廃棄）

廃棄とは、60日間の閲覧数がゼロ、または6ヶ月以上前に退職した人が最後に編集したもの、のどちらかです。典型的な中堅SaaSでは、ダッシュボードの60〜70%が廃棄状態であることがわかります。私の前職では312個のダッシュボードがありました。棚卸し後に実際に使われていたのは47個でした。残りはゴーストシップです。

まだ何も削除しないでください。ただリストを作るだけです。

第2週: スキーマツアーと正規収益の議論

次は読みます。dbtリポジトリ（dbtがない場合はウェアハウス）を開きます。毎週触れることになる5つのテーブルを見つけます（通常はaccounts、subscriptions、events、users、そして収益テーブルのいずれか）。モデルの定義を読む。カラムのコメントを読む。マクロを読む。

統計的に確実なこととして、会社に収益の複数の定義が存在することに気づきます。私が勤めたある会社では、ウェアハウスに収益の定義が14通りありました。ARR計上、ARR請求、ARR予測、純新規ARR、グロス維持ARR。それぞれある目的では正しく、別の目的では間違っていました。財務部門は一つを使い、セールスは別のものを使い、CEOは3つ目の定義が入ったGoogle Sheetを持っていました。

これは普通のことです。そして第2週の最重要タスクでもあります。財務カウンターパートとのミーティングを設定してください。「ボード向けの信頼できる情報源はどれですか?」と聞いてください。Slackのメッセージではなく、ドキュメントで回答をもらってください。その会話がその後すべての基盤になります。

財務部門が答えられない場合、それ自体が発見事項です。記録しておきます。

第3週: ステークホルダーとの同期（聞く、売り込まない）

5つのミーティングに参加します。RevOps、カスタマーサクセス、マーケティング、プロダクト、財務。プレゼンをする場ではありません。自己紹介をする場でもありません。繰り返し出てくる問いを聞くための場です。

探すべきパターン: 3つの異なるチームが3つの異なる言い方で同じ問いを聞いている。それが第5週のダッシュボードです。

第3週の同期ミーティングで聞いたことの例。

• RevOpsリード: 「パイプラインが実際にどのセグメントに集中しているか、いつもわかりません。」
• CSディレクター: 「Excelに出力せずに業種別のExpansion ARRが見られたらと思います。」
• CMO: 「マーケティング起点のパイプラインをセグメント別に見るデータが5か所に分散しています。」

これは同じ問いが3回出ています。これが第2ヶ月に構築するダッシュボードです。

ノートを持参してください。ラップトップを開かないでください。「サクッと出します」とは申し出ないでください。聞かれたら「今後2週間は棚卸しモードです。依頼受付フォームが立ち上がったら入れてください」と言ってください。(依頼受付フォームについては後ほど。)

第4週: 削除リスト

ここで廃棄ダッシュボードの削除を提案します。新人アナリストが怖くてスキップしがちなところです。スキップしないでください。

棚卸しリストに戻ります。廃棄ダッシュボードごとに、作成者（または担当チーム）を探して「これはX日間閲覧がありません。アーカイブしていいですか?」と聞きます。80%の場合、答えは「ぜひ、存在を忘れてました」です。15%は「実は月に一度使っています。残しておいて」です。5%の場合はビジネスについて重要なことを知ることになります。

書面で了承を取る。Slackスレッドで問題ありません。それからアーカイブ、削除ではない。多くのBI ツールでワンクリックで復元可能なアーカイブができます。記録を残したいのです。

私が使って効果のあったスクリプト。

[名前]さん、オンボーディングの一環としてダッシュボードの整理をしています。「[ダッシュボード名]」は73日間閲覧がなく、[退職した人]が最後に編集しています。アーカイブしたいと思います（復元可能で削除ではありません）。よろしいですか? 残したい場合はまったく問題ありませんが、誰かが管理者であることを確認したいと思っています。

10件ずつまとめて送ります。返信を追いかけないでください。5営業日経って返信がない場合はアーカイブ。すべて記録します。

第4週の終わりまでに、通常40〜150個のダッシュボードを削除できます。これが最初の成果物です。SQLを1行も書かずに達成できる唯一の成果物でもあります。それがまさにこのポイントです。

31〜60日目: 1つ成果物を出し、SLAを設定する

第2ヶ月が実際に仕事が始まるときです。でも3つのことしかできません。ダッシュボードを1つリリースする。SLAを公開する。dbtモデルを1つ構築する。それだけです。もっとやりたい衝動に抗ってください。

全員が求めているあの1つのダッシュボードをリリースする

第3週で3チームが聞いていたあの問いを覚えていますか? そのダッシュボードを作ります。その1つだけを。

ここでの規律は厳しいものです。「ついでに、これも追加できますか?」という依頼が来ます。答えはNoです。その依頼が悪いからではなく、「ついでに」が積み重なるたびにアドホック対応要員の罠に余分なステップを踏んで近づくからです。1つのものをリリースする。しっかり作る。リリースする。

「良い」最初のダッシュボードとは。

• 1つの問いに明確に答える。5つではなく。
• 指標の定義は第2週で議論した正規のものであり、ダッシュボードのフッターにその旨が明記されている。（「収益はdbtモデルに基づいて定義されています [リンク]。財務部門と最終確認済み [日付]。」）
• フィルタは最大3つ。セグメント、日付範囲、チーム固有のカット。
• 上部に1段落の「見方」。
• オーナー（あなた）と「質問はこちらへ」のSlackチャンネル。

最後の箇条書きは譲れません。オーナーのないすべてのダッシュボードは18ヶ月後にゴーストシップになります。あなたはそのパターンを断ち切るアナリストになります。

アドホックSLAを公開する

これがSQLの自動販売機でなくなる瞬間です。1ページ（Notionドキュメント、Confluenceページ、何でも会社が使っているもの）を公開して、こう書きます。

アドホックなデータ依頼の受付

1. [フォーム / #data-requestsチャンネル]から送信してください。私へのSlack DMはこちらに誘導します。
2. 必須フィールドは3つ: 必要なもの、必要な日時、どの意思決定に反映するか。
3. SLA: 4時間以内の作業は当日中または翌朝。4時間超の作業は次のSprintにトリアージ。
4. 「ボードデッキ」または「役員レビュー」タグのものはキューの先頭へ。

3つの必須フィールド。7つではなく。14項目の依頼受付フォームでもなく。3つ目のフィールド（どの意思決定に反映するか）が魔法をかけます。依頼の半分はここで止まります。依頼者が「実はデータは必要なく、ただ気になっていただけ」と気づくからです。残り半分は依頼者が先に考えるようになるので、より絞られた形で来ます。

アナウンスはあなたからではなく、マネージャーに送ってもらいましょう。「みなさん、[あなたの名前]がアナリティクスの受付を担当します。今後はフォームを使ってください。」この一文は、あなたが受け取らずに済む100件のSlack DMに相当します。

SLAは「No」と言うためのものではありません。「次のSprintで」を、抵抗ではなく通常の答えにするためのものです。

dbtモデルを1つ構築する

dbtモデルは、第2週で議論した正規の収益定義です。それだけ。指標レイヤーではなく、セマンティックなリファクタリングでもなく。1つのモデルです。

リポジトリの命名規則に合わせてfct_revenue_canonicalなどと名前をつけます。ドキュメントブロックを書きます。テストを追加します。レビューを受けます。マージします。第5週のダッシュボードをそのモデルからソースするよう更新します。

これが「自分はここにいる」と証明できる瞬間です。ミーティングで誰かが「どの収益の数字を使っているの?」と聞き、チームメンバーが「正規のものです。[あなたの名前]がリリースしたdbtモデルです」と答えるとき、あなたは「新入りアナリスト」ではなく「このチームのアナリスト」になっています。

いかなる状況でも、第2ヶ月にウェアハウス全体のリファクタリングを試みないでください。第6週に「すべて作り直す」と試みて第8週にボードレポートを壊した新人アナリストたちの歴史が示す教訓があります。1つのモデルをリリースして、次に進む。

61〜90日目: 指標を担当し、計画をピッチする

第3ヶ月は、クローズしたチケット数で評価されるのをやめ、担当しているものによって評価されるようになる月です。

インサイトまでの時間を自分の指標にする

チームレベルの指標を1つ選んで担当します。アナリストにとって最も効果的なのはインサイトまでの時間です。「依頼が届いてから」「データ上の答えが出るまで」の中央値時間です。チームによっては「最初のデータ回答までの時間」と呼ぶこともあります。同じ考えです。

依頼受付フォームから計測します（今はフォームがあります）。第9週にベースラインを確立します。第12週の目標を設定します。私の場合、中央値6時間、目標4時間以内でした。

「ダッシュボードの利用定着度」や「実行クエリ数」ではなくこの指標なのはなぜか? インサイトまでの時間はステークホルダーが実感できる指標だからです。利用定着度が上がっても気づかれません。でも「火曜日の翌週ではなく昼前に問いへの答えが出た」ことは気づかれます。

チームのスタンドアップで週次で報告します。3つの数字のみ: 中央値、p90、件数。それだけ。

90日間レポート

85日目あたりで、マネージャーに1ページのレポートを書きます。この順序で4つのセクション。

削除したもの。 アーカイブしたダッシュボードの数とリスト。測定可能であればウェアハウスの推定計算削減量。

リリースしたもの。 ダッシュボード1つ。dbtモデル1つ。2ヶ月分のスループットデータが入った依頼受付フォーム。

壊れているもの。 今もおかしいと気づいたこと。具体的に。「MRRのセグメント別モデルがEMEAリージョンのトライアルコンバージョンを二重カウントしています。4つのダッシュボードに影響しています。修正は1週間のプロジェクトです。」曖昧にしないでください。マネージャーはリストを求めています。

次にやること。 戦略的プロジェクト2つ、プラットフォーム投資1つ、必要であれば人員に関する要望1つ。具体的に、大まかな時間軸とともに。

1ページ。それ以上書かないでください。ドキュメントとして送り、1on1で一緒に確認します。

下半期計画のピッチ

90日間レポートはウォームアップです。ピッチが本番です。同じ1on1で、こう言います。「下半期のアナリティクス計画を担当したいです。大枠はこうです: 戦略的プロジェクト2つ（XとY）、プラットフォーム投資1つ（指標レイヤー / リバースETL / 実験フレームワーク）、人員の意思決定1つ（2人目のICを採用するか、リード役のシニアを採用するか）。[日付]までに完全なドキュメントを用意します。」

これが、5年間ICにとどまるアナリストと18ヶ月でチームを率いるアナリストを分ける瞬間です。ほとんどのアナリストはマネージャーが自分のために計画してくれるのを待ちます。あなたはマネージャーのために計画します。

フィードバックを受けることになります。計画は修正されます。2つのプロジェクトは取りやめになります。それで問題ありません。重要なのはピッチという行為であり、成果物ではありません。

落とし穴（誘惑されますが、落ちないでください）

第1ヶ月にすべてのアドホック依頼にYesと言う。 冒頭でも言いましたが、もう一度。アドホック対応のサイクルは一方通行のドアです。第1週にYesと言えば、2年目もYesと言い続けます。

第2週にウェアハウスを作り直す。 まだビジネスが理解できていません。「明らかに壊れている」モデルは、まだ会っていない誰かにとって重要なものです。まず棚卸しをしてください。

60日間沈黙した後に40ページの監査レポートを出す。 誰も監査レポートを求めていませんでした。あなたが存在しているという証拠が欲しかっただけです。第4週に削除リストをリリースする。第6週にSLAを公開する。姿を見せる。

間違った収益定義でダッシュボードをリリースする。 第2週の財務部門との整合をスキップした結果です。ダッシュボードがボードデッキと矛盾します。信頼が損なわれます。取り戻すのは難しい。やめてください。

実際に使えるテンプレート

ダッシュボード棚卸しスプレッドシート。 6列: 名前、オーナー、最終閲覧（日付）、最終編集（日付）、ステータス（稼働中/要確認/廃棄）、削除または維持の判断。1行1ダッシュボード。最終閲覧日の昇順でソートすると廃棄ダッシュボードが上に来ます。

ステークホルダー同期用の質問リスト。 5つの問い、この順序で。(1) 前四半期に、より良いデータがあれば違う決断ができたと感じた意思決定は何ですか? (2) 毎朝確認する数字は何ですか? (3) 実際に使っているダッシュボードと、あなたのために存在するダッシュボードは何ですか? (4) 上司からよく聞かれるが、素早く答えられない問いは何ですか? (5) もし私がビジネスへの一つの新しい視点を提供できるとしたら、それは何ですか? 「私に何が必要ですか?」という質問ではないことに注意してください。その問いはウィッシュリストを生み出します。これらの問いは本音を引き出します。

アドホック依頼受付フォーム。 3フィールド。依頼内容。期限。反映する意思決定。それだけ。

90日間レポート。 1ページ。削除したもの。リリースしたもの。壊れているもの。次にやること。段落ではなく箇条書き。

90日目の「成功」とはどんな状態か

90日目には、BI ツールのダッシュボード数は増えてではなく、減っています。会社が以前議論していた指標に対して、正規のdbtモデルが1つ存在します。ステークホルダーはあなたにDMする代わりに依頼受付フォームを使っています。マネージャーはあなたから書かれた下半期計画を受け取っています。逆ではありません。そして会社のモニターのどこかで、ダッシュボードの数字が火曜日も金曜日も同じです。

あなたは「アドホック対応要員」ではありません。アナリストです。

それがこの仕事です。

関連記事

• データアナリスト職務記述書（このPlaybookと対になるJD）
• データアナリストの一日
• スケールするSQLとデータモデリング
• ステークホルダーとの翻訳: 曖昧な依頼をリリース可能な分析に変える
• データアナリストの指標: インサイトまでの時間、利用定着度、インパクト
• データアナリストのよくある落とし穴