ビジネスアナリストによくある落とし穴（そして抜け出す方法）
Turn this article into takeaways for your work.
Each assistant summarizes the article only for you and suggests best practices for your work.
先月、あるBAとコーヒーを飲みました。入社14ヶ月、優秀で、仕事が速く、周囲から好かれています。「依頼に溺れている」と話してくれました。四半期に60件以上のチケット、週末が月曜日に侵食され、終わりが見えない状態です。
私は1つだけ質問しました。先四半期、あなたの仕事によって変わった意思決定を1つ挙げてください。
答えられませんでした。1つも。47枚のダッシュボードをリリースし、312件のSlackのピンに答え、シニアエンジニアが頷くようなクエリを書きました。しかし、そのどれかによって意思決定が変わった例を1つも挙げられなかったのです。
このギャップがこの記事のすべてです。また、入社2年目に昇進するBAと、4年目になっても相変わらずアドホック依頼のクエリを書いているBAの違いでもあります。
2年目が分岐点である理由
ほとんどのBAは1年目を純粋な努力で乗り切ります。スキーマを覚え、ダッシュボードを記憶し、実際に何を誰が管理しているかを把握します。何もかも新鮮なので、アウトプットが進歩のように見えます。
2年目は違います。スキーマはもう新鮮ではありません。アウトプットは1年目と同じに見えますが（同じクエリ、同じダッシュボード、同じSlackスレッド）、今や当たり前になっています。努力が可視性に変換されなくなります。仕事が複利で増えるか（自分の仕事が他の人の意思決定から課題を取り除き始める）、停滞するか（ヘルプデスクの高速版になる）、どちらかです。
分岐は静かに起きます。多くの人は間違った道を進んでいることに、評価の季節になるまで気づきません。マネージャーが「素晴らしい仕事をしている、でも戦略的インパクトをもっと見たい」と言うまで。それはマネージャーが、最も丁寧な言葉で、あなたの仕事が何を変えたかわからないと伝えているのです。
停滞への道に進んでしまう7つの落とし穴を挙げます。それぞれに自分の週で確認できる症状、測定できる数字、月曜日から実行できる対処法があります。
落とし穴1: ヘルプデスクになること
症状。 DMがキューのように見えます。「ちょっと聞いていいですか、Xを引っ張れますか？」「お邪魔してすみませんが、YにZは含まれますか？」答えるのが速く、断ることが失礼に感じるから答えます。そして、なぜ戦略的なプロジェクトに手が回らないのか不思議に思います。
数字。 私の経験では、ヘルプデスクになったBAは週に12から18時間をアドホック依頼に費やします。週の4分の1から3分の1が毎週、ほぼ同じ5つの答えしかない質問に消えていきます。
対処法。 個別のピンへの返答をやめます。#analytics-helpチャンネルを作り、すべてのDMを1行で誘導します。「#analytics-helpに投稿して他の人も答えを見られるようにします。」2週間以内に同じ5つの質問が繰り返されているのがわかります。それらに答えるセルフサービスのドキュメントまたはLookerのボードを作り、リンクを張れば、キューが縮まります。
難しいのはチャンネルではありません。VPに「これはセルフサービスであるべき」と、仕事を断っているように聞こえずに言うことです。うまくいく言い回し:「喜んで今回は引っ張ります。次の10回の依頼でブロックされないよう、金曜日までに[チームダッシュボード]に追加しておきます。そうすれば自分で確認できます。」依頼に答えました。同時に仕事を「永遠に自分のキュー」から「一度だけ自分のキュー」に移しました。
落とし穴2: 要件の承認をスキップすること
症状。 ステークホルダーが20分の通話で欲しいものを説明します。頷いてメモを取り、作りに行きます。2週間後に見せると「あ、でも地域別の内訳も必要で」とか「あれ、これは月次ですね。週次が必要でした」と言われます。作り直します。「あとちょっと」。また作り直します。
数字。 作り直しごとに4から12時間かかります。1つのダッシュボードで3回の作り直しサイクルは1週間分の時間であり、ステークホルダーはまだ数字を信頼できるか確信が持てません。
対処法。 クエリを1行も書く前に、3つのセクションからなる1ページの要件ドキュメントを送ります。意思決定（この作業はどんなアクションを可能にするのか、誰が決めるのか）、定義（「リード」「アクティブユーザー」「解約」とは何か、書面で合意）、完了（スケッチ付きで、これがリリースされたときどう見えるか）。3つすべてについて書面での承認を得ます。ステークホルダーが1ページ分読まないなら、それはその依頼が作る価値があるほど重要でないというサインです。
承認ドキュメントは官僚主義ではありません。「ダッシュボードが欲しい」を「毎週月曜日にXを決定するためにYが必要」に変換する強制機能です。スコープクリープの90%はその変換の中で消えます。
落とし穴3: 意思決定を定義する前にダッシュボードを作ること
症状。 ダッシュボードをリリースします。グラフが14枚、フィルターが6つ、すべて色分けされています。ステークホルダーは「すごい、ありがとう」と言います。3週間後に確認すると、2回しか開かれていません。両方ともあなたです。
数字。 ほとんどのBIツールでは、最初の1ヶ月後、中央値のダッシュボードは月に5回未満しか閲覧されません。「お客様が喜んでいた」が「お客様が使っている」と一致しなければ、そのダッシュボードには実際の意思決定が紐付いていません。
対処法。 TableauかLookerを開く前に、スクラッチドキュメントの冒頭に1文書きます。「このダッシュボードは[役職]が[ケイデンス]ごとに[アクション]を決定できるように存在する。」3つのブランクをすべて埋められない場合、ダッシュボードは存在しません。あいまいな何かを作る依頼があるだけです。
テストに合格する例:
- 「このダッシュボードは営業VPが毎週月曜日の朝に今四半期どの2地域に人員を配置するかを決定できるように存在する。」
- 「このダッシュボードはCSリードが毎週火曜日の9時に今週電話すべき5つのアカウントを決定できるように存在する。」
テストに不合格な例:
- 「このダッシュボードはリーダーシップがファネルを可視化できるように存在する。」
- 「これはマーケティングパフォーマンスダッシュボードです。」
意思決定が名指しされていない場合、ダッシュボードは壁紙になります。
落とし穴4: Excelエクスポートへの過度な依存
症状。 ステークホルダーが「いじりたい」のでExcelにデータを引き出します。ピボットテーブルを作ります。VLOOKUPを追加します。ファイルをメールで送ります。2週間後、ステークホルダーはそれをミーティングで共有しますが、数字が間違っています。誰もの「ダウンロード」フォルダーに埋まっているシートの中に入れ子になった方法で間違っているため、再現できません。
数字。 Excelを正確さの源泉として使うと、時間よりも評判を消費します。ボードデッキの1つの間違った数字で、「データパートナー」としての地位を立て直すのに6ヶ月かかります。
対処法。 Excelは一回限りの探索には問題ありません。定期レポートとしては問題です。私が使うルール: 同じExcelファイルを2回送ったなら、3回目はBIツールに置かれなければならず、SQLはどこか同僚が見つけられる場所にコミットされています。
Reworkの生産性ツールやほとんどのBIプラットフォームは、定期的なExcelエクスポートの80%をスケジュールされたレポートに置き換えられます。残りの20%は本物のアドホック分析であり、そこでExcelは真価を発揮します。Excelと戦わないでください。パイプラインとしてのExcelと戦ってください。
落とし穴5: SQLまたはdbtモデルのバージョン管理がないこと
症状。 クエリフォルダーを開くとcustomer_metrics.sql、customer_metrics_v2.sql、customer_metrics_FINAL.sql、customer_metrics_FINAL_USE_THIS.sql、そして不気味なcustomer_metrics_old_DO_NOT_USE.sqlがあります。どれも同じ数字を出しません。先四半期のボードデッキでどれを実行したか覚えていません。
数字。 「なぜあなたの数字と私の数字が合わないのか」の調整に費やされる時間は月に3から5時間になりがちです。リーダーシップミーティングで数字を弁護しなければならないアナリストなら、もっとかかります。
対処法。 SQLをgitに置きます。プライベートリポジトリでも、共有dbtプロジェクトでも、クラウドドライブに同期されたフォルダーでも構いません。バージョン管理し、コミットし、ファイル名をバージョン管理として使うのをやめます。すでにdbtを使っているなら、これは無料です。BIツールのワンオフクエリでバイパスするのをやめるだけです。
ソロBAのための最小限のセットアップ:
ba-queries/
models/
revenue/
monthly_revenue.sql
arr_by_segment.sql
customers/
active_customer_definition.sql
README.md # 各モデルが意味すること、誰が各定義を所有しているか
すべての変更をコミットします。「この数字はどこから来たのか」と聞かれたときにコミットハッシュを参照します。その習慣だけで、「アナリスト」から「ボードミーティングで自分の数字を弁護できるアナリスト」に変わります。この2つは異なる仕事であり、給与も異なります。
落とし穴6: 廃止レビューを無視すること
症状。 Lookerを開きます。ダッシュボードをカウントします。47あります。積極的にメンテナンスしているのは9つです。記憶から3つ名前が出てきます。残りの44はまだ「稼働中」で、毎朝データを引き、カタログでステークホルダーが検索するときに表示されます。
数字。 私が関わったチームでは、ダッシュボードの30から50%が90日間開かれていません。それでもコンピューティングコストをかけ、新入社員を混乱させ、ミーティングで「どれが正しいのか」という瞬間を生み出し続けています。
対処法。 四半期ごとに廃止レビューを実施します。午後一つで完了します。BIツールから使用状況レポートを引き出し、last_viewed_atでソートして、90日以上前のものについて次の3つのうち1つを行います。
- 誰も所有していなければアーカイブする。
- 定期指標の正規版なら昇格する（「コア」フォルダーに移動し、定義をロック）。
- ほぼ同じものが3つあれば統合する。
初めてこれをやると20以上のダッシュボードをアーカイブし、何も悪いことは起きません。それが要点です。カタログが整理され、クエリが速くなり、新入社員があなたに聞かずに正しいダッシュボードを見つけられるようになります。
落とし穴7: 利用状況を測定して意思決定への影響を測定しないこと
症状。 マネージャーがアナリティクス機能の調子を聞きます。「先月、エグゼクティブダッシュボードは1,200ビューありました」と言います。マネージャーは頷いて別の質問をします。
数字。 「1,200ビュー」は、誰が見て、どんなアクションにつながり、どんな成果があったかを聞くまでは印象的です。「わからない、でもグラフは右上がりです」が答えなら、間違ったものを測定しています。
対処法。 使用状況指標から意思決定指標に切り替えます。上位5つのダッシュボードについて、次のことを名指しします。
- ダッシュボードが支援する意思決定（落とし穴3の同じ作業）
- その意思決定のケイデンス（週次、月次、四半期次）
- 先四半期に、そのダッシュボードが判断を変えた1つの例
最後のものがキラーです。ダッシュボードが判断を変えた例を1つも挙げられないなら、そのダッシュボードは装飾です。上位5つで3つか4つ挙げられるなら、あなたはもはやレポート係ではありません。仕事がお金を動かしたアナリストです。
評価の季節が来たとき、「マーケティングリーダーシップチームは私が作ったチャネルアトリビューションダッシュボードに基づいて3月に有料ソーシャルからオーガニックに40万ドルを再配分した」という文章は昇進につながります。「1,200ビュー」はお礼と同じ役職につながります。
根底にあるパターン
7つの落とし穴を読み返すと、すべてが1つの根本を持っています。意思決定ではなくアウトプットに最適化しているのです。
- ヘルプデスク = アウトプット（チケットのクローズ）
- 承認なし = アウトプット（速く作り、間違って作る）
- 意思決定前のダッシュボード = アウトプット（グラフのリリース）
- Excelエクスポート = アウトプット（ファイルのメール送信）
- バージョン管理なし = アウトプット（クエリを書くが、理解しない）
- 廃止なし = アウトプット（カタログが増え、縮まない）
- 影響なしの使用状況 = アウトプット（ビューを測定し、価値を測定しない）
仕事を再定義します。クエリを書き、ダッシュボードをリリースし、チケットをクローズするために給料をもらっているのではありません。ビジネスの意思決定レイテンシーを削減するために給料をもらっています。ミーティングが必要だった意思決定をグラフから判断できるようにします。1週間かかっていた意思決定を1日でできるようにします。
あなたの週のすべての時間がそれに結びついていなければなりません。結びついていなければ、オーバーヘッドです。オーバーヘッドは複利で増えません。
30日間の抜け出しプラン
7つすべてを一度には直せません。代わりにこれを試みてください。
第1週: 出血を止める。
#analytics-helpチャンネルを設置します。すべてのDMをそこに移します。要件承認用の1ページテンプレートを書きます。例外なく次の2つの依頼に使うことを約束します。
第2週: 信頼を取り戻す。 最も多く閲覧されている3つのダッシュボードを選びます。それぞれについて「[役職]が[ケイデンス]ごとに[アクション]を決定できるように存在する」という文章を書きます。埋められない場合、オーナーと20分の会話をスケジュールして確認します。ダッシュボードの説明をその文章で更新します。
第3週: 家を片付ける。 SQLをgitリポジトリに入れます、プライベートでも。上位3つのダッシュボードを動かしているクエリを少なくとも移動します。廃止レビューを実施します。所有するすべてのダッシュボードをリストし、それぞれをアーカイブ/昇格/統合としてマークします。
第4週: 成果を示す。 先四半期を振り返り、「意思決定インパクト」の文章を3つ書きます。本物を。（「Xチームは私がリリースしたZ分析に基づいてYを再配分した」）書けない場合、それは診断です。次の四半期のプランは、本物の3つを作ることです。
金曜日のセルフ監査。 毎週金曜日、ログオフする前に3つの質問を自分に問いかけます。
- 今週の私の仕事はどんな意思決定を変えたか？
- セルフサービスであるべきだったのに受け入れた依頼は何か？
- 来週アーカイブすべきダッシュボードは1つあるか？
3分、3つの質問。質問は変わりません。6ヶ月にわたるあなたの答えが変わります。
まとめ
この記事の冒頭のBA、仕事が変えた意思決定を1つも挙げられなかった彼女は、仕事ができなかったのではありません。仕事ができました。表面的な仕事（チケットをクローズし、ダッシュボードをリリースし、ピンに答える）には優れていました。しかし本当の仕事（ビジネスからの意思決定レイテンシーを取り除く）では水面下でした。
この記事の落とし穴は知性の問題ではありません。注意の問題です。表面的な仕事がその瞬間に生産的に感じられ、本当の仕事が評価の季節まで見えないため、気づかずに落ちていきます。
今週、1つの落とし穴を選んでください。金曜日までに直してください。昇進はもっと多くのことをすることからは来ません。意思決定を変えることをして、それ以外のすべてに（丁寧に、書面で）ノーと言うことから来ます。
関連記事
