はじめに

この記事は、これからデータアナリストを目指そうとしている人、データアナリストの生態に興味がある人向けに書いています。
そうでない人も社内のデータ部門の人がどんな１日を過ごしているか、あまりご存知でない方が多いのではないでしょうか。
データアナリストという仕事の特性上、会社内でもあまり目立たない存在であることが多いと思いますので、この機会に知っていただければ幸いです。

この記事から得られること

①データアナリストのリアルな1日をざっくり知ることができる
②会社のデータ部門の人達の悩みにちょっとだけ共感できるようになる
③データアナリストの転職を検討していた人、現実を知って思い留まるようになる

なぜこの記事を書くか

私は、30歳手前で非IT業界からデータアナリストに転職しましたが、ぶっちゃけ転職するまでデータアナリストという職業の中身や、どのような1日を過ごすかほとんど未知数でした。

もちろん、ググればデータアナリストのモデルケースとして、「こんな働き方してますよ。１日のスケジュールはこんな感じですよ」みたいな記事は見かけます。
具体的な仕事内容な、どのような気持ちで仕事をしているかが知りたいと思っていた私にとって、モデルケースでは、リアリティに欠けていたため、あまり参考になりませんでした。

そのため、本記事では、もっとリアルなデータアナリストの１日を紹介していきたいたいと思います。

ありがちなデータアナリストのモデルケース

09:00 出社

メールチェック等一日の仕事の準備

09:30 朝礼

朝のミーティングにてタスク確認

10:00 データ分析業務

収集したビックデータをもとに、分析作業を行う。

12:00 休憩

同僚と一緒にオフィス近くの飲食店でランチ

13:00 データ分析業務

引き続きビックデータの分析作業。
分析したデータを、BIツールで可視化。

15:00 IT部門とのミーティング

分析に必要なデータの取得依頼のためのMTG

16:00 企画部門とのミーティング

マーケティングも分からビジネス上の課題をヒアリング。

17:00 定例ミーティング

チーム内での定例MTG。その日の作業の進捗報告や、課題や問題点の共有。

18:00 退社

データ分析作業がひと段落したので、この日の仕事は終了。終了後はチームメンバーと軽く食事。

お手本のような１日です。決して上記のようなモデルケースが実態と違うと言いたいわけではありません。私を似たような1日を過ごしています。

とあるデータアナリストの1日

08:30 通勤

気持ちに余裕がある日は、読書の時間。余裕がない日は音楽を聞きながら出勤
SNSチェックは必要最低限。ここで頭に多くの情報を入れると午前中の仕事の効率が悪くなるほでほどほどに。

09:00 slack通知確認

ビッククエリにデイリーで取り込んでいるテーブルの更新を確認。
毎日テーブル更新の成功or失敗をslack通知される仕組みにして、失敗していたらメンションが飛ぶようにしています。
「今日も異常なし！」
万が一テーブル更新に失敗していた場合、その原因調査から始めるため、1日のスケジューリングが変わるので、ドキドキです。ですので出勤前に確認することを日課にしています。

10:00 SLOダッシュボードの確認

朝一でやる仕事はこれ。
SLOダッシュボードは、ざっくりいうと「会社のサービスの健康状況をBIツールで見える化したもの」です。

自分たちでダッシュボード上に可視化をしたものなので、毎日チェックしています。
たまに、異常値が出ていたりするのでその際は、原因調査します。
今日は、あるサービスの成功率の数値が極端に低く出ていたので、調査をします。

*SLO：自社サービスレベル（サービス品質）に関する目標・評価基準を定めたものです。

11:00 朝会

私のチームは3名のため、いつもの3人で1日のチームのタスク確認をしています。
まずは、ダッシュボードに異常値が出ていな旨を共有。リームリーダーより、現マネージャーに報告することに。
今日の業務内容は、
①ダッシュボードの異常値調査
②分析用データセット作成（今日のメインタスク）
③ミーティング２本

「優先順位の高い①をなる早で仕留めなくちゃ。分析用データセットはクエリをゴリゴリかくやつ」

11:30 ダッシュボードの異常値調査

ダッシュボードの異常値がなぜ発生しているかを調査。SQLでクエリ叩いて調査します。
調査したところ、特定のサービスの特定のversionだけ、数値が0になっている様子。
すぐに該当部門に確認したところ、最近ログデータの仕様変更があったらしい。
原因が特定できたので対応方針をまとめ、マネージャーに報告。
「原因が特定でき、午後には復旧できる目処が立ったので一安心」

12:30　分析用データセット作成に着手

今日のメインタスクであるデータセット作成。
あるサービスの利用状況で集計。
集計項目が20個ほどあるため、ヘビーなタスク。
この集計でミスるとその後の分析に影響するため、慎重に進める。
利用状況の集計と言っても、考えることは多い。
集計はユーザ単位？デバイス単位？

集計の計画を立てたところでお昼休憩。

14:00 お昼

15:00 データ施策立案の打ち合わせ

サービスの利用状況を改善するための、施策をデータチーム内で考える会。
仮説の洗い出しと施策イメージをディスカッション。
・利用状況が芳しくないユーザ層の特定
・利用状況が著しいく低下するタイミングや要因の特定
・改善のための施策の実現可能性や課題、スケジュール間を整理

まとめたものを来週ビジネスサイドへ提案します。

16:00　分析用データセット作成

午前中に集計計画を立てたので、あとはひたすらSQLを書く。
集計ロジックが適切であるか、集計した数値が正しいか、検算方法に考慮漏れがないか等々、集計内容が複雑になればなるほど一つひとつ丁寧に行う必要があります。

18:00　データセットレビュー

チームリーダーにレビューしてもらい、問題なければ集計した利用状況をBIツールを用いてダッシュボードに見える化する予定。
今回は、１箇所、集計ロジックに考慮漏れが見つかったため、その場で修正。
生ログで確認したところ、イレギュラーパターンを考慮できていなかったことが原因でした。
レビューといえども集計屋にとって、正しく集計できていなかった時点でアウトなので、超反省。。。
レストランの料理人がレシピ通りに作れてないのと一緒です。
もし致命的な集計ミスだった場合を料理に例えると、お菓子作りに砂糖を入れるべきところを誤って塩を入れるのと同じレベルだと肝に命じて仕事しています（正直そこまで、できていないですが）。

19:00　業務の進捗をタスク管理ツールを更新。

業務の進捗は、チーム内で共有できるようタスク管理ツールで行なっており、可視化しています。
私のように他業界からきた人間からすると、非常に画期的なシステムなんですよね。
私が3年前まだ教育業界にいた頃、超巨大なホワイトボードで管理していたのが懐かしいです。

19:15 業務終了

まとめ

可能な限り、リアルな1日を書いたつもりですが、いかがでしたでしょうか。
特にこれからデータアナリストを目指そうとしている方にほんの少しでも、参考になれていれば幸いです。