データアナリストがよくやる失敗：キャリアを台無しにする7つのミス（と解決策）
Turn this article into takeaways for your work.
Each assistant summarizes the article only for you and suggests best practices for your work.
Slackは忙しい。Lookerには自分の名前のついたダッシュボードが47個ある。マネージャーは1on1で「しっかりやってる」と言う。それでも、Sales VPが来四半期のテリトリー再編を決める会議に、あなたは招待されません。
14ヶ月目のアナリストのパラドックスへようこそ。仕事が溢れるほど有能で、そのどれにも断れるほどシニアではありません。カレンダーを埋めてきた仕事がIC2まで連れてきてくれました。そのどれもシニアには連れて行ってくれません。
80人から8,000人規模の企業でアナリストのパフォーマンスサイクルをレビューしてきました。停滞する人たちはほぼ常に同じ理由で停滞します。スキルの問題ではありません。SQLは学べます。dbtも学べます。Pythonは実際にノートPCを開けば週末で学べます。この記事の落とし穴は習慣であり、習慣はコンセプトを学ぶより難しい。
では、最も大きなダメージを与える7つの落とし穴を紹介します。それぞれに今週から認識できる症状、自己比較のための実数、そして月曜日の朝から始められる解決策があります。
なぜ6〜18ヶ月の時期がキャリアの方向性を決めるのか
見てきたアナリストのパフォーマンスレビューでは、IC2で停滞する人の約73%が6ヶ月から18ヶ月の間に形成されたパターンが原因です。この時期はオンボーディングが終わっても、自分でスコープを設定できる政治的資本をまだ得ていない段階です。最初の6ヶ月は出荷できることを証明します。6〜18ヶ月は、キャリアを通じてどんなアナリストになるかを決めます。
ほとんどの人は決めません。流されます。流されるとは、すべてのSlack通知にYesと言い、誰も開かないダッシュボードを作り、クローズしたチケットで成功を測ることです。2年後には役割が固定されます。24ヶ月目には、境界を設けたチームメンバーがシニアのオファーを受けています。あなたは「次のサイクルで再検討しましょう」と言われています。
この7つの落とし穴が、その「流される」状態を名付けたものです。
落とし穴1：ヘルプデスク化する
症状： 週の60%以上がそれぞれ30分未満のアドホックな依頼に費やされています。6週間前にスコープした深い分析にまだ手をつけていません。
自分のカレンダーで5分で確認できます。Slackを開いて、クエリ結果を送ったメッセージを検索し、解決に30分もかからなかったものを数えてください。典型的な週でその数が25を超えているなら、あなたはデータアナリストではありません。SQLコンシェルジュです。
落とし穴は、ヘルプデスクになることが役に立っているように感じることです。「ありがとう！」の絵文字のたびに小さなドーパミンが出ます。素早いターンアラウンドがレスポンシブに見えます。そしてそのチケットに費やすすべての分は、昇進につながることに費やせない分です。判断力を養うことです。
今週実行する解決策：
トリアージのSLAを設定してチームチャンネルに投稿してください。私のものはこう書いています：
アドホックな依頼：午前11時と午後4時の1日2回まとめて対応しています。本当に手が止まっているものは、
urgentとデッドラインをタグ付けしてください。繰り返し聞かれる質問についてはセルフサービスのダッシュボードをご利用ください：[リンク]。45分以上かかる質問はチケットになり、マネージャーと優先順位付けを行います。
次に、セルフサービスのクエリライブラリを作ってください。最も頻繁に答える10の質問を、ドキュメント付きのダッシュボードまたは保存済みのLooker Exploreとして公開します。2週間でヘルプデスクの量が40〜60%減ります。マネージャーは気づきます。ステークホルダーは1週間文句を言って、それからやめます。
「これは優先順位付けを通じてください」と言う不快感は、検索バーではなくアナリストとして扱われるための代償です。
落とし穴2：要件の承認をスキップする
症状： プロジェクトのリビジョン3回目で、ステークホルダーが「実は、私が本当に意味したのは...」と言いました。金曜日にモデルをやり直して再出荷します。
これはあなたが思っている以上のコストがかかります。私が関わったある中規模企業のアナリクスチームが手戻り率を監査したところ、アナリストの時間の31%がすでに「出荷済み」のプロジェクトに費やされていることがわかりました。10時間のうち3時間が、仕様がSlackスレッドだったために作業をやり直していたのです。
要件の承認をスキップしたのは、求めることが遅くなると感じたからです。ステークホルダーに何が必要かを書き出してもらい、署名して受け入れ基準に合意してもらうことが官僚的に感じられました。だからスキップしました。今は水曜日で、3度目のファネルを再構築しており、Marketing VPは「アナリクスのターンアラウンドに不満を感じている」状態です。
今週実行する解決策：
4時間以上の作業を要するすべてのプロジェクトに一枚紙の要件定義書。テンプレート：
プロジェクト：[名前]
依頼者：[名前 + 役職]
この分析が促す意思決定：[実際の意思決定]
意思決定者：[これに基づいて行動する人]
意思決定のデッドライン：[日付]
受け入れ基準：[「完了」とするために存在しなければならない3〜5の具体的な成果物]
スコープ外：[やらないこと]
ステークホルダーの承認：[名前 + 日付]
メールで送ってください。「承認」を待ってください。それからSQLを書いてください。ステークホルダーが署名しないなら、そのプロジェクトは実在しておらず、開始する必要はありません。
そう、これはプロジェクトの最初の24時間を遅らせます。次の24時間の手戻りをなくします。計算は明白です。
落とし穴3：意思決定を定義する前にダッシュボードを作る
症状： 最新のダッシュボードには14のタイル、3つのフィルター、期間選択がついています。どのアクションをトリガーするか聞かれると、部屋が静まり返ります。
これが最もよく見る悪い習慣で、アナリストが最も強く擁護するものです。「多ければ多いほど良い」というのが本能です。すべての切り口、すべての内訳、すべてのディメンションをユーザーに提供してスライスさせる。結果は、答える質問がないため誰も使えないダッシュボードです。
400人規模のSaaS企業の2024年の内部データ：Lookerインスタンスの287のダッシュボードのうち、41が週に10人以上の閲覧者を持っていました。残りの246はゴーストタウンでした。機能した41すべてが正確に一つの質問に答え、一つのアクションをトリガーしていました。機能しなかった246は「overview」、「exec summary」、「team health」ダッシュボード：成果物として装われた曖昧な名詞でした。
今週実行する解決策：
新しいダッシュボードの前に、4つの質問に書面で答えてください：
- これはどの意思決定を促すか？
- その意思決定を誰がするか？
- どのサイクルで（毎日、毎週、毎四半期）？
- 指標が閾値を超えたとき、どのアクションがとられるか？
4つすべてに答えられないなら、ダッシュボードを作っているのではありません。壁紙を作っています。すべてに一緒に答えられるまで依頼者にプロジェクトを戻してください。
このように作られたダッシュボードには3〜7のタイル、一つの期間、明確な「この数値がXを下回ったらYをする」の吹き出しがあります。特定のことに答えるから使われます。
落とし穴4：Excelエクスポートへの過度の依存
症状： ステークホルダーが引用するすべての「最終数値」が、誰かのデスクトップにある3週間前に更新されたCSVに入っています。
エクスポートボタンはトラステッドなアナリクスの敵です。すべてのエクスポートはデータのフォークです。数値がデータウェアハウスを離れて Q3_pipeline_v4_FINAL_real.xlsx に着地した瞬間、あなたはコントロールを失います。6週間後、CFOはそのファイルを取締役会のデッキで引用し、それは間違っており、間違った数値はあなたに帰属します。
FinanceチームがCSVから19%のパイプラインカバレッジを引用し、ライブのデータウェアハウスの数値は14%だったケースを見たことがあります。CSVはディールがコミットとして再分類される前のものでした。CFOは19%を取締役会に報告しました。2ヶ月後、取締役会はなぜこれほど未達だったのか質問しました。答えは「スプレッドシートが古かった」でしたが、それは取締役会のミーティングで生き残れる答えではありません。
今週実行する解決策：
ガバナンスされたセマンティックレイヤーを構築してください。dbtモデル、定義された指標、Looker、Sigma、Hex、スタックが使うものに公開されたもの。ステークホルダーには読み取り専用のアクセスを。それから、チームチャンネルでこのアナウンスをしてください：
[日付]から、[パイプライン、売上、リテンション、重要な指標]の信頼できる情報源は[ダッシュボードリンク]です。24時間以上前のCSVは照合しません。デッキに数値が必要な場合は、ダッシュボードへのリンクを貼ってください。
一部のステークホルダーはこれに抵抗します。それで構いません。抵抗するCFOは、データウェアハウスがスプレッドシートなら見逃していた数値を最初に捉えたときに感謝するのと同じCFOです。
エクスポートの習慣をなくしてください。守られる評判はあなた自身のものです。
落とし穴5：SQLやdbtにバージョン管理をしない
症状： プロダクションのアトリビューションクエリが3月のSlackスレッドに存在しています。さらに悪いのは、Lookerのタイルに存在していて、3人があなたの知らないうちに編集したことです。
これは認めるには恥ずかしすぎますが、Series Cの企業のアナリクスチームを監査したことがあり、そこではLTV（顧客生涯価値）の計算が、コメントなし、誰がいつ何を変更したかの履歴もなく、Lookerのderivedテーブルに貼り付けられた400行のクエリでした。それを書いたアナリストは2024年に退職しました。誰も自信を持って何かを変更できません。
バージョン管理はエンジニアのためのものだと思っています。違います。他の人が依存している仕事をする人のためのものです。それはあなたです。バージョン管理のないアナリストは、一つの悪いマージか一つの誤った削除で丸一日のインシデントに直面します。
今週実行する解決策：
ソロアナリストであっても、以下を設定してください：
- SQLのgitリポジトリ。
analytics-sqlなどの名前で。 - 複数の人または複数のダッシュボードが使うモデルにはdbt。
- プルリクエストのレビュー。ソロなら、翌朝自分でプルリクエストのレビューをしてください。マージ前に新鮮な目でdiffを読み直してください。
- CIチェック（
dbt test、最低3つ：not null、unique、accepted values）。
最初の月は遅く感じます。2ヶ月目には、営業リーダーのボーナス計算を8%狂わせていたバグをレビューで発見します。それ以降は二度と戻れません。
あなたの会社のシニアアナリストはこれらすべてを持っています。昇進しないIC2はどれも持っていません。それがギャップのほとんどです。
落とし穴6：廃止レビューを無視する
症状： 200以上のダッシュボードを管理しています。実際にアクティブに使用されている12個がどれかを教えることができません。削除できるものもわからないので、すべて維持しており、dbtの変更のたびに200のダウンストリームのタイルに波紋が広がります。
ほとんどのBIチームでのシンプルな監査：過去30日間でユニーク閲覧者数が3人以下のダッシュボード。典型的な中規模企業では、それがインベントリの60〜75%です。コストは保存容量だけではありません。障害です。すべてのリファクタリング、すべての指標の定義変更、すべてのカラムのリネームを、誰も開かないダッシュボードに対してリグレッションテストしなければなりません。
廃止は政治的に見えるから監査を実施しません。あれらのダッシュボードの一つ一つを誰かが作りました。誰かがまだ欲しいかもしれません。だから維持し続け、ゴミが蓄積し、dbtのビルドが遅くなり、新しい指標の出荷時間が2日から2週間になります。
今週実行する解決策：
四半期ごとの廃止レビュー。カレンダーの招待、90分、毎四半期、永遠に繰り返し：
- 使用統計を取得：過去四半期で月間ユニーク閲覧者数が3人未満のダッシュボード。
- オーナーに通知（またはオーナーがいない場合は
@channel）：「このダッシュボードは廃止リストに入っています。まだ必要な場合は[日付]までに返信してください。そうでなければアーカイブされます。」 - アーカイブする（削除しないでください；90日間別のフォルダに移動してから削除）。
- カウントを追跡する。最初の監査でインベントリの20〜30%を廃止することを目標にしてください。それ以下なら積極性が足りません。
ステークホルダーは最初のラウンドで予想より大きく声を上げ、その後のラウンドでは静かになります。3ラウンド目には、チームはスリムになり、dbtのビルドが昼食前に完了します。
落とし穴7：意思決定のインパクトなしに利用定着度を測る
症状： パフォーマンスレビューの文書に「ダッシュボード閲覧数：月間1,200」と「クローズしたチケット：月間47」と書かれています。あなたによってビジネスで何が変わったかについては何も書かれていません。
これが7つの中で最も静かなキャリアキラーです。なぜなら、やっている間は間違いに感じないからです。ページビューが増え、チケットがクローズし、生産的に見えます。そして昇進サイクルが来て、隣のポッドのシニアアナリストがチケット数の半分で昇進します。自己評価にこう書いてあったからです：
「コホート維持率モデルを構築し、カスタマーサクセスチームのリニューアルモーションを方向転換させた。以前のモデルより60日早くリスクのある顧客をフラグアップすることで、Q3に140万ドルのARR維持に貢献した。」
その一文が「ダッシュボード閲覧数：毎月1,200」をすべてのサイクルで打ち負かします。比べ物になりません。
落とし穴は、アクティビティ指標がカウントしやすく、意思決定のインパクトが難しいことです。だから数えやすいものを数え、シニアアナリストは重要なものを数えます。どちらがタイトルを得るか想像がつきます。
今週実行する解決策：
「意思決定ログ」を始めてください。分析ごとに一行、列は：
| 日付 | 分析 | 意思決定者 | 変化した意思決定 | 推定インパクト |
|---|---|---|---|---|
| 2026-04-15 | Q1 SDRテリトリー分析 | Sales VP | 4人のrepをMid-MarketからSMBに再配置 | 3,400万円の追加パイプライン |
| 2026-04-22 | オンボーディングファネルの詳細分析 | Head of CS | オンボーディングのステップ3を廃止 | アクティベーション率+6ポイント |
ほとんどの週は0〜2行追加します。それがポイントです。基準は「この分析によって意思決定が変わった」であり、「数値を送った」ではありません。4列目を埋められないなら、その仕事は何も動かしませんでした。それも有用なシグナルです。そのプロジェクトは間違ったプロジェクトだったかもしれません。
昇進の際、自己評価は自ずと書けます。マネージャーとの会話が「チケットに追いついているか」から「次に価値のある意思決定は何か」に変わります。
これらを2年目に持ち込んだときの複合コスト
これらの一つを選べば摩擦点として感じますが回復できます。3つ以上を2年目に持ち込むと軌道が固まります。評判が形成されます。「オンボーディングの間違ったステップを廃止するよう背中を押したアナリスト」ではなく、「ダッシュボードの人」や「SQLの人」になります。
その評判こそが実際に解消が難しいものです。9〜15ヶ月の昇進遅延は一般的です。シニアの役職は、より少ないコードを出荷してもより多くの意思決定を実行した同僚のものになります。そして最悪の結果は昇進できないことではありません。ヘルプデスク版の役割がその役割であると信じ始め、他のことに手を伸ばすのをやめることです。
良いニュースは、立て直しには1年ではなく1四半期かかるということです。これらのパターンを修正したほとんどのアナリストは、6〜8週間以内に扱われ方の顕著な変化を感じます。ステークホルダーが「この数値を取ってこれますか？」ではなく「どうすべきか？」と聞き始めます。それがゲーム全体です。
30日間のリセット
7つすべてを同時に修正しようとしないでください。何も修正できなくなります。
最も痛かった2つを選んでください。正直に。最も認めたくないものが、おそらく最初に取り組むべきものです。コーチングするアナリストのほとんどが「ヘルプデスク化する」と「意思決定のインパクトなしに利用定着度を測る」を選びます。これらは複合する傾向があります。
そして：
- 第1週： 落とし穴1を選ぶ。解決策を一枚紙の計画として書く。マネージャーに実施することを伝える。
- 第2〜3週： 解決策を実施する。何が変わるかを追跡する：取り戻せた時間、ステークホルダーの反発、出力の質。
- 第4週： 落とし穴2を加える。同じ手順で。
30日目には2つの新しい習慣ができています。90日目にはそれが自動的に感じられます。180日目には過去の自分を振り返って見覚えがないでしょう。
それが仕事です。新しいツールを学ぶことではありません。賢くなることでもありません。ただ流されることを拒否することです。
自己診断チェックリスト
月曜日の朝に実施してください。正直な答えのみ：
- 週の40%未満が30分以下のアドホックな依頼
- 4時間以上のすべてのプロジェクトにSQL作成前に書面で署名された要件定義書がある
- 自分が所有するすべてのダッシュボードが、促す意思決定、意思決定者、サイクルを名前で挙げられる
- ステークホルダーはミーティングでCSVではなくライブのダッシュボードを引用している
- 自分が所有するすべてのSQLまたはdbtモデルがプルリクエスト履歴とともにgitに存在している
- 四半期ごとに廃止監査を実施し、未使用のインベントリの少なくとも20%をアーカイブしている
- 自己評価に名前のついたインパクトを持つ意思決定ログに少なくとも5つのエントリがある
7点満点で採点してください。4未満なら流されています。4〜5は平均的です。6〜7はシニアアナリストとして機能しており、おそらくそれに見合った報酬を受け取るべきです。それは別の週の別の会話です。
関連記事
