新任ビジネスアナリストの最初の30日・60日・90日

入社3日目。どのSlackチャンネルが重要かまだ把握できていない段階で、14件目のDMが届きます。「ちょっと確認なんだけど、今日中にセグメント別MRRを出してもらえる？」Lookerのアクセス権もまだ取得できていません。ノートパソコンを使い始めてわずか19時間しか経っていないのに。

Wikiを開くと、前任のBAが残した47個のダッシュボードが目に入ります。そのうち12個は壊れています。残り35個はrevenue_FINAL_v3_use_this_oneといった名前がついています。Finance、RevOps、CEOのチーフ・オブ・スタッフの3チームが、それぞれこっそりと「うちの売上数字が正しい」と主張してきます。そのうち2つは8%以上も数字が合っていません。

これが実際の仕事です。求人票に書かれた仕事ではなく、現実の仕事です。注意しないと、最初の90日間は前任BAとまったく同じ道をたどることになります。アドホック依頼に溺れ、自分の仕事を何一つ完成させられず、4ヶ月目に静かに燃え尽きていくのです。

多くのBAが最初の四半期をSlackの対応に費やして終わります。ここでは、そうならないための方法を紹介します。

なぜBAには特に30/60/90プランが必要なのか

エンジニアには30/60/90プランがあります。チケット、PR、オンコールローテーションという明確な境界線があるからです。PMにもあります。ステークホルダーとのスタンドアップミーティングがあるからです。BAがそれを省略することが多いのは、仕事の輪郭がはっきりしないように感じるためです。

それこそが問題です。

書いたプランがなければ、あなたはSQL自動販売機になります。誰かがDMで質問する、クエリを書く、答えを貼り付ける、次へ移る。これを週80回繰り返します。90日目に上司から「何を完成させましたか？」と聞かれたとき、「312件のアドホック依頼を処理しました」と答えることになります。それは自分の成果物ではありません。心拍数を持ったJiraキューです。

仕事は「データを引き出すこと」ではなく「インサイトを生み出すこと」です。30/60/90プランは、本来の仕事をする時間を取り戻すための手段です。自分自身と（暗黙的に上司とも）交わす契約であり、「最初の1ヶ月は成果物を約束しない、2ヶ月目には積み上がる1つのものを完成させる、3ヶ月目には1つの指標を自分で担当する」と宣言するものです。

上司がそのアークに賛同してくれないなら、それ自体が情報です。この役割は「チケットをこなす人」であり「アナリスト」ではないということです。2ヶ月目に入る前に再交渉するか、履歴書を更新すべきです。

1日目から30日目：監査と学習（完成も約束もしない）

最初の1ヶ月のルールは1つだけです。新しいダッシュボードを作らない、新しいレポートを作らない、「火曜日までに確認します」以上のコミットをしないこと。このフェーズは受信モードです。

すべてのダッシュボード、レポート、定期エクスポートを棚卸しする

Looker（またはTableau、Mode、チームで使っているツール）を開きます。全アセットリストをエクスポートします。スプレッドシートで以下のようにタグ付けします。

中規模のSaaS企業には40から200程度のBI アセットがあり、その30〜50%は陳腐化または破損状態です。これは前任者の怠慢ではありません。誰も BI の資産管理に報酬をもらっていないと自然に起きることです。

削除候補リストを作る（まだ送らない）

21日目までに、削除すべき15〜25個のダッシュボードのリストを書き上げておくべきです。しかし、21日目にメモを送ってはいけません。少し待ちましょう。入社3週間のあなたにはまだ何かを削除する信頼性がありません。3週間目の新人からの削除メモは、無謀か無知かのどちらかに見えます。

下書きを保存しておきましょう。1つ何かを完成させて実績を積んだ35日目に送ります。

スキーマの深掘り

データエンジニアリングチームを見つけます。コーヒーをおごります。以下について説明してもらいます。

• 分析クエリの80%が触れるコアテーブル5〜7個（通常はusers、accounts、subscriptions、events、opportunitiesと、ドメイン固有の1〜2個）
• dbtモデルの場所、各モデルのオーナー、どれが積極的にメンテされどれが放棄されているか
• ウェアハウス内のすべての売上定義のバリエーション（後で戻ってきます、ひどい状態です）
• 直接クエリしてはいけないテーブル（生のイベントファイアホース、コンプライアンスでロックされたテーブル、オンコールを呼び出すもの）

メモを取りましょう。将来の自分が検索できるドキュメントに、きちんとしたメモを。30日目までに、誰にも聞かずに「ARRはどこにあるか」と答えられるようになるべきです。

アドホック依頼の上位5名と1対1で話す

前任BAのキュー（Slackの履歴、Jira、どこかに記録があるはず）から過去90日間の依頼を取り出します。ボリュームで並べます。上位5名が依頼全体の60〜70%を生み出しています。それぞれと30分の時間を取ります。

「どんなレポートが欲しいですか？」という質問はしないでください。それでは14個のダッシュボードのウィッシュリストが返ってきます。本当に聞くべき質問は「このデータで実際にどんな意思決定をしていますか？」です。

上位5名のうち3名は、異なるフレーミングで同じ根本的な質問（「数字は目標に達しているか？」）に答えるために分析を使っていることに気づくでしょう。これは統合のチャンスです。残りの2名は本当に独自の作業をしており、専用のものが必要です。

依頼受付フォームを設定する

NotionのフォームでもDMよりはるかにマシです。フォームには3つのフィールドが必要です。どんな意思決定をしているか、いつまでに必要か、「これで十分」はどんな状態か。3つ目のフィールドは依頼の40%を即座に消去します。依頼者が実際には何が必要かわかっていないことに気づくからです。

4週目に穏やかにフォームを周知します。まだ強制しません。強制力が生まれるのは31日目です。

31日目から60日目：レバレッジの高い1つのものを完成させ、SLAを設定する

2ヶ月目から本当の仕事が始まります。動く権利を得ましたので、使いましょう。

5件以上のアドホック依頼を代替する1つのダッシュボードを選ぶ

依頼者のリサーチを見返します。作れば最も多くのDMを減らせる「ダッシュボードの穴」を見つけます。B2B SaaSで1年目のBAにとって、多くの場合それは以下のいずれかです。

• Sales、CS、Finance間で定義が統一された統合パイプライン・売上ダッシュボード
• ICPでセグメントされた解約率と拡張の表示
• PLGモーションのための製品利用と売上のブリッジ

1つ選んで完成させます。1人のエグゼクティブに1回の会議で使ってもらう。それが目標です。「全社展開」ではありません。実際の意思決定の文脈で、1回使われること。CROが月曜の予測会議で開いたら、2ヶ月目の勝利です。

アドホックSLAを発行する

35日目に、チャンネルに書面で送ります。

アドホック分析SLA

• 24時間以内のトリアージ：返信し、内容を確認し、20分の作業か2日プロジェクトかダッシュボードを作るべきかをお伝えします。
• スコープが決まった4時間以内の作業は72時間以内に納品します。
• それ以上の作業は受付フォームを経由し、週次で優先順位を決めます。
• コンテキストのないDMは受付フォームに誘導します。

最初の10日間は嫌がられます。その後は気に入られます。返ってくる依頼には実際の意思決定が伴い、答えが定着するからです。

削除候補リストの削除を開始する

メモを送ります。2週間の猶予を設けます（「5月14日以降、誰かがオーナーシップを主張しない限りこれらのダッシュボードをアーカイブします」）。2〜3件はオーナーが名乗り出ますが、それで構いません。引き渡しましょう。残りはアーカイブします。ウェアハウスから削除するのではなく、BIツールから非公開にするだけです。いつでも復元できます。

60日目までに12〜20個のアセットを廃止し、BIツールがかなりすっきりした状態になるはずです。

インサイトまでの時間のベースラインを設定する

60日目が終わるまでに、ステークホルダーの依頼が「依頼」から「意思決定に紐づいた回答」になるまでの時間のベースライン測定を確定させます。平均ではなく中央値で追跡します。1週間かかるプロジェクトが1件あると平均が歪み、何もわからなくなります。

3つの測定方法があります。

• 依頼クローズまでの中央値：受付送信から「意思決定を記録」まで（日数）
• データに裏付けられた意思決定：過去30日の経営層の意思決定で分析アウトプットを参照したものの割合（10件サンプリングして確認）
• ダッシュボードvs依頼の比率：アドホック依頼1件あたりのセルフサービス・ダッシュボードのビュー数

1つを選んで今すぐ測定します。数字を書き留めます。90日目に必要になります。

61日目から90日目：指標を担当し、レポートを発表する

3ヶ月目で「新しいBA」ではなく「インサイトまでの時間を担当するアナリスト」になります。その変化が、社内での次のステップを開きます。

インサイトまでの時間を短縮する

60日目に測定しました。今度は動かします。手段は地味です。

• 上位3件の繰り返し質問をダッシュボード化して、依頼でなくなるようにする
• チームがセルフサービスで使えるクエリテンプレートを2〜3個作成する
• 「ちょっと確認」が実はスコープクリープのケースには丁重に押し返す（「これはプロジェクトです、受付に入れましょう」）
• 週に1人のステークホルダーとペアで分析して、スキーマを学んでもらう

3ヶ月目の現実的な目標：依頼クローズまでの中央値を30〜40%短縮するか、ダッシュボードvs依頼の比率をベースラインから50%改善する。1ヶ月目と2ヶ月目を正しくこなしていれば、どちらも達成可能です。

90日間レポートのデッキを作る

85日目に、上司とスキップレベルに向けた7スライドのデッキを作ります。テキストが詰まった文書ではなく、デッキです。スライド構成：

1. 引き継いだもの：ダッシュボード47個、売上の定義14種類、バックログ23件、SLAなし
2. 廃止したもの：閲覧数付きの削除リスト（証拠が重要）
3. 完成させたもの：レバレッジの高いダッシュボード1つ、実際に使っているエグゼクティブの名前
4. SLA：公開日、採用率、受付キューの現状
5. インサイトまでの時間：60日目のベースライン、90日目の現状、差分
6. スキーマ整理の成果：正規化した売上定義（次セクション参照）、その他の統合
7. 次の90日：担当を提案する四半期OKR 1〜2つ

デッキは15分で説明できるようにします。30分かかるなら削ります。

本当に担当する四半期OKRを1〜2つ確定する

会議の終わりまでに、上司が次の四半期で自分が責任を持つ1〜2つのアウトカムに合意する状態にします。機能するOKRの例：

• 「Q3末までに依頼クローズまでの中央値を6日から2日に短縮する」
• 「最も利用されている3つのアドホックレポートをセルフサービスのダッシュボードに移行する」
• 「売上、ARR、ネット維持率の正規化されたメトリクス定義を確立し、すべてのバリエーションを廃止する」

避けたいのは「チームの分析をサポートする」という表現です。それはOKRではなく、職務記述書です。評価時に上司が具体的に擁護できるものが何もありません。

「Lookerに14種類の売上定義がある」という現実

1ヶ月目のどこかで、ウェアハウスに14種類の売上定義があることに気づきます。予約済み、請求済み、回収済み、認識済み（GAAP）、認識済み（内部）、MRR換算、ARR換算、ARR純解約、グロスリテンション、ネットリテンション、ARR（ランプディール込み）、拡張のみ、新規ロゴのみ、そして文字通りrevenue_FINALという名前の列。

1週目にこれを修正することはできません。おそらく最初の四半期中も無理です。しかし開始することはできます。開始することがBAとシニアBAの違いです。

政治的でないPlaybookはこうです。

1. 勝者を決めるのではなく、管理者を選ぶ。 FinanceかRevOpsの肩を持たないこと。双方から1名（プラス自分）に標準委員会になることに同意してもらいます。3人で45分間。
2. 最も争いの多い指標（通常はARRかネット維持率）に対して1つの正規定義を提案する。 SQLを書きます。先四半期に何の数字が出るかを示します。各チームの現在の数字と比較します。
3. 書面で承認を得る。 Slackスレッドで十分です。ポイントは後で誰かが数字に異議を唱えたとき、そこにリンクできることです。
4. dbtで残りを廃止する。 古いモデルを廃止済みとしてマーク、30日間の猶予を設け、その後削除します。他チームのダッシュボードは壊れます。警告を送り、線を守りましょう。
5. 次の四半期に次の指標で繰り返す。 これは12ヶ月かけた整理であり、スプリントではありません。

罠は2ヶ月目に14個の指標を正規化しようとすることです。派閥争いが始まり、負けて、他のすべてに必要な政治的資本を使い果たします。四半期に1指標。ゆっくりと承認を得ながら進める方が、速く進んで元に戻されるよりはるかに優れています。

避けるべき一般的な罠

最初の90日間で新任BAが失敗するパターンをいくつか挙げます。

• すべての依頼にYESと言う。 役に立っているように感じます。実際にはそうではありません。組織に受付フォームを迂回することを教えているのです。3ヶ月目にはSLAが形骸化し、また自動販売機の状態に戻っています。
• 理解する前に作り直す。 前任BAの成果物を丸ごと消して最初からやり直したくなります。やめましょう。半分は見かけ上わからない形で重要な役割を果たしています。まず監査し、次に廃止し、そして新たに作る。
• データエンジニアリングチームを無視する。 彼らは入力データを所有しています。廃止直前のテーブルの上にダッシュボードを作ると、最悪のタイミングでそれを知ることになります。コーヒーをおごりましょう。
• 書面のないSLA。 口頭のSLAはSLAではありません。雰囲気です。雰囲気はQ3の追い込みを生き残れません。
• 指標戦争で肩を持つ。 RevOpsとFinanceが売上について意見が合わないなら、あなたの仕事は標準化の議論を進めることであり、勝者を宣言することではありません。どちらかの肩を持てば、1人の味方と1人の敵を作ります。議論を進めれば、2人の味方を得られます。

90日目に、実現した意思決定で評価される

上司が90日目のレビューで「何件クエリを実行しましたか」と聞いてきたら、間違った上司（またはロールの間違ったフレーミング）がいるということです。そのどちらかを直す必要があります。

正しいフレーミングはこうです。あなたの仕事で何件の意思決定が実現したか、組織はその意思決定にどれだけ早く到達できたか、そして次の四半期も恩恵を受け続ける複利的な資産（ダッシュボード、SLA、正規化された指標）を残したか？

これがBAと自動販売機の違いです。自動販売機はチケットをこなします。BAは会社の自己認識を変えます。90日目はその違いがカレンダーに現れ始める時点です。アドホックなDMが減り、「企画会議に参加してほしい、あなたの見方を聞かせてほしい」という招待が増えます。

その招待が届いたとき、オンボーディングを超えて本当の仕事に入っています。次の90日間を作り上げましょう。

関連ガイド

• ビジネスアナリスト 職務記述書テンプレート
• 溺れないアドホック依頼受付の作り方
• チームをまたいだメトリクス定義の正規化
• インサイトまでの時間：本当に重要なBA指標