データアナリストからアナリティクスエンジニアへのすゝめ
こんにちは。おきゆき (@okiyuki99) です。最近はアナリティクスエンジニア：データアナリスト = 80：20でやっています。数年前まではデータアナリスト・データサイエンティスト成分が多めだったのですが、逆転してきました。
アナリティクスエンジニアというポジションは昨年くらいから急激に見るようになったと思いますが、この記事ではデータアナリストのネクストキャリアとして、アナリティクスエンジニアはいいぞ！という話をします。
ちなみに、dbtの開発者ブログのこの内容にインスパイアされて、自分なりの考えを書いてみようと思いました。
アナリティクスエンジニアとは
あらためてアナリティクスエンジニアについて簡単におさらい。dbtのアナリティクスエンジニアリングガイドに書かれているアナリティクスエンジニアの役割を意訳すると以下のように書いています。
データを使って解きたい問いを持つエンドユーザが分析に多くの時間を費やせるように、アナリティクスエンジニアはデータの変換・テスト・ドキュメンテーションを行い、クリーンなデータセットを提供する
バージョン管理や継続的インテグレーションなどのソフトウェアエンジニアリングのベストプラクティスを分析コードにも適用する
データアナリストが上記のような業務を担当する企業も多いと思いますが、データアナリストの役割は以前と比べると区分され、アナリティクスエンジニアという名称が生まれています。
現職のUbieのアナリティクスエンジニアもdbtのガイドどおりクリーンなデータセットを提供するという役割を担います。特に、Nがとても少ない対象を扱うため、高品質なデータパイプラインを組み立て、精緻なデータを作ることが求められます。また、組織としてデータの利活用は活発な会社です。現職のエンジニアや事業開発メンバーもSQLを書き、BIツールやスプレッドシートでダッシュボードを作成し、定期的にモニタリングし、アクションを打つといったデータの利活用は一定進んでいます。そのため、
クリーンで品質の高いデータを社内に提供することでレバレッジが効く
データの利活用時のハマりどころを無くすことで、1段レベルの高い適切なデータ利活用が進む
というように、アナリティクスエンジニアの役割がとても重要なフェーズです。データを用いてビジネスを展開している他の企業においても、アナリティクスエンジニアのニーズは常にあると思います。
データアナリストの特性
では、データアナリストのネクストキャリアとして、アナリティクスエンジニアはいいぞ！と自分がなぜ思ってるかというと、単純にデータアナリストが普段考えてることって、アナリティクスエンジニアの業務にそのまま活きること多いよねと感じるからです。それらについて以下で説明します。
●要らないデータを知っている
データをむやみにたくさん作るのは、認知負荷を増大させ、メンテナンスを難しくさせ、データの適切な利活用を逆にブロックすることになり得ます。そのため、最小コストで最大限のリターンを得たいという考えのもと、必要なだけのデータを提供することが重要です。
「そのデータ新規で必要です？その目的なら、すでに提供しているデータを使って○○分析したら得たいもの得られません？」
「このメトリクスAは、このテーブルからロジックXで作ったメトリクスBを可視化してみたら、メトリクスAと相関してそうですし、同じ解釈ができると思うので、メトリクスAのデータマートを作る必要なさそうでは？」
「過去の経緯で、このログ落としてもらってたのですが、別の仕組みで落ちるようになったので、このログ不要になりました。なので、システム上からもログ消してください。データマートからも削除します」
といった利用者の得たいものから逆算して別のHowも提案し、不要なデータ作成のインベストを抑え、必要なデータだけにフォーカスする動きはデータアナリストの得意とするところだと思います。
●将来の分析を見通している
組織としてデータの利活用が浸透すると、新しい分析要件もどんどん出てきます。それを見越してデータパイプラインの改修コストを減らし、元々の分析要件には無かったけど、後からかゆいところに手が届くデータマートを初手から構想できるのも、データアナリストの得意とするところだと思います。
「あるイベントAを行ったユーザに限定して、メトリクスXを見たいといった分析は前回の施策結果を踏まえると想定されるので、任意のイベントで簡単にデータを絞れるようなカラムを残しておこう」
「今R&Dチームが開発中の関連する病名表示機能に新機能がリリースされる。その機能の利用有無でレポーティングの出し分けはオプションで提供しそう。今後そういった新機能リリースは継続的に発生しそうなので、それを上流のデータマートAにカラム追加するようにすれば、下流のデータマートBを改修するコストを減らせそう」
このような将来に渡るビジネスの成長と共にデータの利活用シーンも大きく変化することを見越しながら、寿命の長いデータパイプラインをいかに作るか？という観点は強く専門性がいるところです。また、考えるのが非常に楽しいところでもあります。
●組織で1番のデータ利用者である
データアナリストはおそらく組織で1番のデータ利用者であると思います。これまで自身の分析で叩いた数千を超えるクエリ経験により、利用者視点でハマるポイントを想像でき、そのようなテーブルが生まれないような設計、またドキュメンテーションでケアする動きが自然とできると思います。
「このテーブルにSQL書くとき、この条件をいれるの普通に忘れそう。なので、不要になるようにしておこう」
「どのカラムでユニークキーになるか、明示的にしておかないと利用者が混乱しそう。このカラムの組み合わせでユニークだと文書化しておこう」
「このテーブル利用時に割合の計算はほぼ100%するだろうから、先に集計しておこう。分母が0になりエラーがでるとBizメンバーが困惑するから、safe_divide しておいて、0除算対策もしておこう」
逆も然りでアナリティクスエンジニアからデータアナリストへ
これから数年でアナリティクスエンジニアとして働く方はさらに増えると想像しますが、そこからはネクストキャリアとしてデータアナリストとして初めて働きますという逆パターンも増えることを期待します。データ分析によりインパクトの大きいプロダクトの改善提案・実行は、データ利活用の大通りですし、ネクストキャリアとしてどんどん出てきてほしいと自分は思います。さらに、事業のフェーズや自身のwillに沿って、データアナリスト⇔アナリティクスエンジニアは循環していくのかなと想像します。
そんな妄想をしたところで、本記事はおわりたいと思います。ではまた！
余談
ちょうどこの記事を書いているときに、Modern Data Stack Radioでアナリティクスエンジニアの話が上がっていて参考になりました。「レポートファクトリーにならないように一段深いデータが届くような仕組みづくり」「ビジネス成長を見据えた逆算したアーキテクチャ設計」はまさに専門性必要だよねと深くうなずいて楽しく聞かせて頂きました。
この記事が気に入ったらサポートをしてみませんか？