はじめに
この記事は、これからデータアナリストやデータサイエンティストとして特に事業会社のデータ部門で働きたいと思っている方向けに書いています。
また、そうでない人も社内のデータ部門の人がどのような１日を過ごしているか、あまりご存知でない方が多いのではないでしょうか。
いわゆるデータ部門は、仕事の特性上会社内でもあまり目立たない存在であることが多いと思いますので、この機会に知っていただければ幸いです。
この記事から得られること
①データ分析を生業にしている人のリアルな1日を知ることができる
②会社のデータ部門の人達の悩みにちょっとだけ共感できるようになる
なぜこの記事を書くか
私は、30歳手前で非IT業界からデータアナリストに転身しましたが、転職するまでデータ扱う仕事について具体的な業務や日々のルーティンについては、あまり詳しく知りませんでした。
もちろんググれば、データアナリストのモデルケースとして、「こんな働き方してますよ。１日のスケジュールはこんな感じですよ」みたいな記事は見かけます。
私は「具体的な仕事内容やその人がどのような気持ちで仕事をしているか」を知りたかったのですが、モデルケースはリアリティに欠けていたため、あまり参考になりませんでした。
ならば、現役のデータアナリストがガチでリアルな日常を綴れば、多少なりとも誰かの役に立つのではという考えに至った次第です。
では、早速読み進めて行きましょう！
そもそもデータアナリストとは？
データアナリストは、データの処理や現状分析などのフェーズを専門に行っている職業です。 集めたビッグデータを分析し、ユーザーの行動や規則性、将来的なニーズなどを見つけ出します。 その後、仮説を立てて問題解決の手段を提案したり、提供しているサービス改善などに役立てることがデータアナリスト主な仕事です。
また、データ活用の価値を全社に認識してもらいデータドリブンな文化を作ることもデータ部門の役割といえます。
実務としては、ひたすら集計する日もあれば、ひたすらダッシュボードを作成する日もあれば、機械学習モデリングするときもあります。
では、実際にどんな1日を過ごしているか？
とあるデータアナリストの1日を紹介したいと思います。
とあるデータアナリストの1日
08:30 通勤
気持ちに余裕がある日は、読書の時間。余裕がない日は音楽を聞きながら出勤。
SNSチェックは必要最低限。ここで頭に多くの情報を入れると午前中の仕事の効率が悪くなるのでほどほどに。
09:00 slack通知確認
BigQueryに日毎で取り込んでいるテーブルの更新を確認。
毎日テーブル更新の成功or失敗をslack通知される仕組みにして、失敗していたらメンションが飛ぶようにしています。
「今日も異常なし！」
万が一テーブル更新に失敗していた場合、その原因調査を直ちに行います。その際は1日のスケジューリングが変わるので、ドキドキです。ですので出勤前に確認することを日課にしています。
10:00 SLOダッシュボードの確認
朝一でやる仕事はこれ。sloダッシュボードの確認です。
SLOとはサービス提供者がユーザーに対して実際にサービスを提供することができる根拠・目標値のことを指します。
今日は、あるサービスの成功率の数値が極端に低く出ていたので調査することになりました。
「なんか今日は成功率めちゃ低いぞ、なんでや？？！」
*SLO：自社サービスレベル（サービス品質）に関する目標・評価基準を定めたものです。
11:00 朝会
私のチームは3名のため、いつもの3人で1日のチームのタスク確認をしています。
まずは、ダッシュボードに異常値が出ていた旨を共有。チームリーダーより、現マネージャーに報告することに。
さて、今日の業務内容は、
①ダッシュボードの異常値調査
②分析用データセット作成（今日のメインタスク）
③施策立案のブレスト会
「優先順位の高い①をなる早で仕留めなくちゃ。分析用データセット作成はクエリをゴリゴリ書くやつだから、午後がっつりやろう。」
11:30 ダッシュボードの異常値調査
ダッシュボードの異常値がなぜ発生しているかを調査。ひたすらクエリ叩いて調査します。
30分程調査した結果、特定のサービスの特定のversionだけ、数値が0になっていることが判明。
すぐに該当部門に確認したところ、最近ログデータの仕様変更があったとのこと。
原因が特定できたので対応方針をまとめ、マネージャーに報告。
「原因が特定でき、午後には復旧できる目処が立ったので一安心」
もし、このようなメンテナンスをせず、誤った数字が出ている状態を放置していたりすると、ダッシュボードの信頼が失われ、徐々に社内のメンバーが見てくれなくなる恐れがあります。ですので、ダッシュボードの保守、運用面にも気を配る必要があります。
12:30 分析用データセット作成に着手
今日のメインタスクであるデータセット作成。
今回作成する分析用データセットは、あるサービスの利用状況を集計し、改善のために役立てます。
作業内容はひたすらBigQueryからSQL集計だけですが、集計項目が20個ほどあるため、とてもヘビーなタスク。
そして、この集計でミスるとその後の分析に影響するため、慎重に進める。
利用状況の集計と言っても、考えることは多い。
利用の定義は何？集計はユーザ単位？デバイス単位？期間は？途中でリセットした場合はどうする？
一つひとつ丁寧に確認し、集計の計画を立てたところでお昼休憩。
14:00 お昼
15:00 データ施策立案の打ち合わせ
サービスの利用状況を改善するための、施策をデータチーム内で考える会。
仮説の洗い出しと施策イメージをディスカッション。
・利用状況が芳しくないユーザ層の特定
・利用状況が著しいく低下するタイミングや要因の特定
・改善のための施策の実現可能性や課題、スケジュール間を整理
まとめたものを来週ビジネスサイドへ提案します。
16:00 分析用データセット作成
午前中に集計計画を立てたので、あとはひたすらSQLを書く。
集計ロジックが適切であるか、集計した数値が正しいか、検算方法に考慮漏れがないか等々、集計内容が複雑になればなるほど一つひとつ丁寧に行う必要があります。
18:00 データセットレビュー
チームリーダーにレビューしてもらい、問題なければ集計した利用状況をBIツールを用いてダッシュボードに見える化する予定。
今回は、１箇所、集計ロジックに考慮漏れが見つかったため、その場で修正。
生ログで確認したところ、イレギュラーパターンを考慮できていなかったことが原因でした。
レビューといえども集計屋にとって、正しく集計できていなかった時点でアウトなので、超反省。。。
レストランの料理人がレシピ通りに作れてないのと一緒です。
もし致命的な集計ミスだった場合を料理に例えると、お菓子作りに砂糖を入れるべきところを誤って塩を入れるのと同じレベルだと肝に命じて仕事しています（正直そこまで、できていないですが）。
19:00 業務の進捗をタスク管理ツールを更新。
業務の進捗は、チーム内で共有できるようタスク管理ツールで行なっており、可視化しています。
私のように他業界からきた人間からすると、非常に画期的なシステムなんですよね。
私が3年前まだ教育業界にいた頃、超巨大なホワイトボードで管理していたのが懐かしいです。
19:15 業務終了
明日は、今日作成したデータセットをもとにpython、pandasでゴリゴリ分析する予定。
まとめ
このようにある1日を切り取ると目の前の作業に追われることが多いのですが、私の場合データ部門が会社から求められることは、
①データを活用して、価値を生み出すこと
②データドリブンな文化を醸成すること
だと思っています。
そこに楽しさを見出すイメージが持てた方は、データ部門でやりがいを持って働くことができるのではないでしょうか。
以上、これからデータアナリストを目指そうとしている方にほんの少しでも、参考になれていれば幸いです。