13
15

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

データアナリスト3年目が語る「教科書に載ってない」現場のリアル

13
Posted at

はじめに

データアナリスト歴3年の中で、失敗も成功もしてきました。
その中で得たナレッジを共有したいと思います。

一般論とはちょっと違う 「現場ではこうじゃないか?」 系を集めたつもりです。
逆の意見もあると思うので、あくまで一例として参考にしてもらえればと思います。

この記事は技術的なハウツーではなく、データアナリストとしての働き方や考え方にフォーカスした内容です。

ビジネス側は細かい数値などどうでもいい

アナリスト的には、自分が出している数字に責任があるので、数字の整合性や統計的に正しい集計なのかをすごく気にします。

しかし、実際にそれを見るビジネス側にとって、そんなことはどうでもいいのです。

結局のところ その分析から何が新しく言えるのか、どうアクションにつながるのか がとても重要なので、そこを意識して分析のストーリーを作ることが大事だと思います。

実際に今まで100個近くレポートを作ってきましたが、細部まで見ている人はほとんどいない印象です。逆にアナリスト側で分析した結果のインサイトまでしっかり提供した場合には、感謝された経験が多いですね。

数字の正確性が不要という意味ではありません。正確であることは大前提として、その上で「So What?(だから何?)」まで踏み込むことが重要ということです。

高度な分析はほぼ使わない

機械学習や統計学を勉強して、ベイズ統計の細かい手法や機械学習の裏の数学ロジックなどを実際の実務で使うことはほぼありません。

なぜならビジネス側が理解できないからです。

理解できないということは、分析の結果をビジネス側が受け入れられないということなので、結局分析の結果が活用されません。そうすると分析しても意味がないので、結局高度な分析は使わないのです。

回帰分析や重回帰分析ですら、ビジネス側が理解できないことが多いです。

もちろん、推薦システムや需要予測など機械学習が必要不可欠な領域はあります。ここで言いたいのは「日々のビジネス分析において」という文脈での話です。

SQLは大体これだけ覚えればいい

SQLは以下の構文さえ覚えれば、大体の分析はできます。

構文 用途
SELECT 取得するカラムの指定
FROM 対象テーブルの指定
WHERE 条件でのフィルタリング
GROUP BY 集計のグルーピング
ORDER BY 結果の並び替え
JOIN テーブルの結合
CASE WHEN 条件分岐
WITH(CTE) サブクエリの整理・可読性向上

これらの構文を組み合わせることで、複雑な分析も可能になります。

逆に、過度にネストしたサブクエリや馴染みのないSQL関数を多用すると、同じチームの人もクエリを読めなくなるので避けるべきです。可読性はチーム開発において非常に大切ですね。

現場によってパフォーマンスの高いクエリの書き方(パーティションの活用、EXPLAINでの実行計画確認など)があるので、それは所属するチームのベストプラクティスに従いましょう。

ドメイン知識は超重要

AIが発達して、コードを書くことやダッシュボードを作ることなどは飛躍的に簡単になっています。

そんな中で 「どんな分析をしたらいいのかを考える力」 がとても重要視されています。これは一般的にドメイン知識と言われるもので、つまりAIに指示する前段階の社内知識や業界知識が重要なのです。

ドメイン知識はSQLのようにすぐ覚えられるものではなく、経験量がものを言います。そんな中でも効率的に身につける方法として、人に会うこと が重要だと思っています。

具体的には以下のようなアプローチです。

  • 業界イベントへの参加: 自分の業界(例: 小売業界)のマーケティングイベントに足を運ぶ
  • 先進企業の勉強会: LINEヤフーのような先進的な企業が開催している勉強会に参加し、同じ業界の人を見つけて話を聞く
  • 社内の営業との対話: 実際にフロントで顧客と対話している営業と話す時間を増やす

業界ニュースも効果的ですが、企業がプレスリリースを出すためにポジショントークをしている場合もあるので、鵜呑みにせず批判的に読むことも大切です。

越境せよ

データというのはいろんな部門の中心ハブになっています。

image.png

実際にデータを使う営業部門やマーケティング部門、Webのアプリケーションログを扱う開発部門、データを整備するデータエンジニア、MLエンジニアなど、様々な職種と密接につながっているのがポイントです。

これによって自分の役割を拡張することが容易にできます。

  • 普段分析しているテーブルが使いにくければ、データエンジニアと連携 してテーブル整備を進める
  • KPIの観測に必要なログ仕様があれば、アプリケーションエンジニアと連携 して実装を依頼する

このように、ただSQLを書いているだけではなくて、いろんな部署と連携しながら仕事をしていくことで自分の経験値も増えていきます。

たとえAIエージェントが分析を全て自律的にできるような世界線になったとしても(データアナリストという職種がなくなったとしても)、他の領域で戦っていくことができるので、キャリア的にも非常に強いと思っています。

まとめ

データアナリスト3年の経験から得た5つの気づきをまとめました。

image.png

この記事が、これからデータアナリストとして働く方や、キャリアに悩んでいる方の参考になれば嬉しいです。

13
15
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
13
15

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?