はじめに
前にも書いたが、「アナリティクスエンジニア」を採用するのは難しい。そもそもアナリティクスエンジニアの知名度が低いし、スキルを持っている人が採用市場に少ない。
しかしニーズはある。以下のようなケースでは、アナリティクスエンジニアはかなりほしい人材だ。
会社全体でデータ分析に対するニーズが高い場合
- 例えば、競争環境の激しいマーケットを相手にしている状況など
- この場合、データに対する需要をアナリスト単体では満たすことができなくなるため、ダッシュボードを利用して分析環境をスケールさせるのが常套手段になる
- この段階でテーブル設計・パイプライン設計が行われるため、アナリティクスエンジニアの出番となる
定常的なデータ分析が求められている場合
- 日時でKPIを見る場合など、分析がパターン化できそうな場合
- アドホックにやるのが面倒になってきたタイミングでテーブル設計・パイプライン設計が行われるため、アナリティクスエンジニアの出番となる
しかしニーズのわりに供給が足りていない。解決策をどうするかというと、パターンは2つある。
- データエンジニアを採用し、アナリティクスエンジニアを兼務してもらう
- データアナリストを採用し、アナリティクスエンジニアに育成する
1については別の話なので一度置いておきたい。2について、自分は今まで小規模なチームでアナリティクスエンジニアの育成に一枚くらい噛んでいたので、いくつか知見がたまってきた。その知見を共有したいと思う。対象読者としては、今はデータアナリストをやっているが、アナリティクスエンジニアに興味が出ている方を想定している。
そもそも「アナリティクスエンジニア」って何？
「これからアナリティクスエンジニアになろう！」ということなので、まずはアナリティクスエンジニアリングを確立したdbtのコラムを参照しながら、どのような仕事なのかをはっきりさせていこう。次に実際の求人票を参考にした架空の求人票を見ながら、イメージを膨らませよう。
What is analytics engineering?
dbtはアナリティクスエンジニアリングをやるうえでかなり便利なツールで、ざっくりいうと、「"dbtの記法"で書かれたコードをデータウェアハウスが実行可能なコードに変換し、データウェアハウスに命令をしてくれる」ツールである。ほかにもいろいろな機能は存在しているので、詳しくはほかの方が書いてくれたブログを読んでほしい。
そんなdbtはアナリティクスエンジニアリングの草分け的な存在であり、「アナリティクスエンジニア」の概念を確立した存在ともいえる。dbtがなくてもアナリティクスエンジニアリングはできるが、あるのとないのとでは話が違う。
上記コラムにおいて、dbtは「アナリティクスエンジニア」について以下のように説明している。
Analytics engineers provide clean data sets to end users, modeling data in a way that empowers end users to answer their own questions. While a data analyst spends their time analyzing data, an analytics engineer spends their time transforming, testing, deploying, and documenting data. Analytics engineers apply software engineering best practices like version control and continuous integration to the analytics code base.
(日本語訳) アナリティクスエンジニアは、エンドユーザーにクリーンなデータセットを提供し、エンドユーザーが自らの疑問に答えられるようにデータをモデリングする。データアナリストがデータの分析に時間を費やすのに対し、アナリティクスエンジニアはデータの変換、テスト、デプロイ、ドキュメンテーションに時間を費やす。アナリティクスエンジニアは、バージョン管理や継続的インテグレーションといったソフトウェアエンジニアリングのベストプラクティスをアナリティクスのコードベースに適用する。
これだけだとわかりづらいと思うので、普段どのような問題について取り組んでいるのかについても見てみよう。
On the surface, you can often spot an analytics engineer by the set of technologies they are using (dbt, Snowflake/BigQuery/Redshift, Stitch/Fivetran). But deeper down, you’ll notice they are fascinated by solving a different class of problems than the other members of the data team. Analytics engineers care about problems like:
- Is it possible to build a single table that allows us to answer this entire set of business questions?
- What is clearest possible naming convention for tables in our warehouse?
- What if I could be notified of a problem in the data before a business user finds a broken chart in Looker?
- What do analysts or other business users need to understand about this table to be able to quickly use it?
- How can I improve the quality of my data as its produced, rather than cleaning it downstream?
(日本語訳) 表面的には、アナリティクス・エンジニアは使用している一連のテクノロジー（dbt、Snowflake/BigQuery/Redshift、Stitch/Fivetran）で見分けられることが多い。しかし、もっと深く掘り下げると、彼らがデータチームの他のメンバーとは異なる種類の問題を解決することに魅了されていることに気づくだろう。アナリティクス・エンジニアは、次のような問題に関心がある：
詳細は上記ブログを読んでほしいが、まとめると、アナリティクスエンジニアとは
- データ利用者の課題解決の寄与するテーブルを作成したり、修正したり
- データの品質を高めたり
- データの変換を最適化したり
するお仕事だ。
求人票を見てみる
もう少し話を具体的に分かりやすくしたい。様々な会社が出している「アナリティクスエンジニア」の求人票を集め、業務内容の共通項目をくくりだしてみたら以下のようになった。
- 社内データユーザーのリテラシー向上
- KPI設計
- ログ設計
- BI（ダッシュボード）の設計・開発・運用
- データマートの構築・改善
- データウェアハウスの設計と運用
- データパイプラインの運用
- データ品質の維持と向上
- CI/CDによる仕組みの構築
会社によってばらつきはあるが、ざっくりまとめるとこんな感じになると思う。BIをデータパイプラインの一部とみなした場合、「データパイプラインの現状を把握し、理想形を意識したうえで、変更を加える」+αがアナリティクスエンジニアの仕事になる。
データアナリストからアナリティクスエンジニアになる際のスキルギャップ
データアナリストからアナリティクスエンジニアになろうとする場合、乗り越えなくてはいけない溝がある。アナリティクスエンジニアの仕事はパイプラインに変更をくわえる仕事がメインになるわけだが、アナリストをやっていた方はHowの部分で躓きがちなので、自分が経験した中/聞かれたことがある中でつまづきがちなポイントを整理しておきたい。
変更フローがわからない
「SQLに修正を加えるべきなのはわかりました。それはそれとして、結局どうやってSQLを修正すればいいんですか？」という問いである。コードを変更して本番環境に反映するまでの一連の流れを抑えるようにしよう。
例えばうちの会社の場合、既存のSQLに修正を加える場合は以下のような流れになる。
git pull origin mainをして最新のリモートレポジトリをローカルレポジトリに反映- mainブランチからブランチを切り、その中で変更を加える
- ローカル上でテストして、問題なければ
git commit - ブランチをリモートにプッシュし、プルリクエストを作成する。レビューしてもらい、レビュワーはapproveしてmainブランチにマージするか、変更をリクエストする
上記の流れはGitHub-Flowといって、開発フローの方では単純な方だが、環境によってはもっと複雑な場合もある。まずは単純なコメントの修正などで慣れつつ、徐々に難易度を上げて慣れていくのが得策だ。コマンド操作に慣れる目的もある（後述）*1。
ちなみに、GitHub-flowなどの開発フローのことは「ブランチ戦略」といい、以下の記事にあるうちのどれか一つではあると思う。Gitの操作やコマンド操作に慣れつつ、自分のチームの環境がどれにあたるのか探してみよう。
コマンド操作がわからない
例えばdbtを利用しているパイプラインに対して変更を加える場合、UNIX系の基本コマンドに加えて、git や dbtのコマンドの操作方法がよくわからないと聞かれることが多い。もともとコマンド操作を行う習慣がない場合、これらのコマンドを習得するまでには時間がかかる。
対処法としては、いきなりgitやdbtのコマンドを教えるのではなく、まずはUNIX系の基本的なコマンドを練習して「コマンドで操作をする」ことに慣れ、次にgit、その次にdbtのコマンドを学習するのが良いと思う。UNIX系の基本コマンドであれば学習教材も充実しているので、コマンド操作の基礎を覚えてもらうにはぴったりだと思う。ここで学んだ基礎をもとに、gitやdbtのコマンド操作を覚えておこう。GUIを使うよりコマンドを操作した方がわかりやすい。
UNIX系シェルコマンドについては、Interactiveに練習できる環境があったりするので、使ってみると便利である。とりあえずcdやls, pwdなどの基本的なコマンド操作を理解しよう。覚える必要はないので、「こういう風に使うんだ、ふ～ん」程度に理解できれば十分だと思う。使う必要があるときに調べて思い出せるようにしておこう。
gitについては、使えるようになるべきコマンドは先述した「ブランチ戦略」によって違う。add, commit, push などの基本コマンドはどのフローでも使うが、ブランチ戦略がgit-flowの場合はcherry-pickを使ったりする。基本コマンドを確実に使えるようになりつつ、コンフリクト発生時のトラブルシュートを地道にやって基本を覚えていこう。チュートリアルとしては「サルでもわかるGit入門」がお勧めである。
基礎ができてきたら、ターミナルの環境を見やすくしてみるのもお勧めである。
contradiction29.hatenablog.com
エディタの使い方がわからない
例えばVSCodeにはデバッグ実行機能があり、これを使うと作業効率が上がる。エディタを使いこなすと作業効率が大きく上がるので、エディタの効率的な使い方は身体に叩き込もう。例えば以下のような項目である。
特にdbtにはdbt power userという拡張機能があり、開発生産性を大きく引き上げてくれる。「エディタを使いこなす」ことは生産性に直結するので、機能をフルに使いこなせるようになろう。
dbtの使い方がわからない
dbtは機能が豊富なので、逆に何から学べばよいのかわからないこともある。そういうときは、いったんチュートリアルを最初から最後までこなしてみるのが良いと思う。以下のチュートリアルがおすすめ。
様々な機能が紹介されているが、とりあえず以下の項目だけ理解して、後は必要に応じて試しながら習得していく、でいいと思う。
dbt runコマンドについて--selectオプションを用いたモデル指定の方法ref記法についてsouce記法についてprofiles.yml,dbt_project.ymlの記法について
snapshotなどいろいろあるが、いったん的を絞って教えて、慣れてきたら使ってみよう、くらいの温度感で大丈夫ではある。
データウェアハウス特有の性質がわからない
データウェアハウスとして何を使っているかで変わるが、「パーティショニング」や「プルーニング」の概念は共通してあるので、抑えておくのがお勧めです。
- DWHの性質を理解していると、そもそも「何ができるのか」の部分がクリアになる
- 何ができるか知っていると、ユーザーのニーズに応えられる可能性が高くなる
- 権限制御の特性、コンピューティングリソースのアロケート方法などは理解しているといいかもしれない
リモートレポジトリの操作方法がわからない
いろいろあるが、ひとまず「SSH鍵の登録方法」と「レビュー時の操作方法」だけできるようになろう。
SSH鍵の登録方法
- SSH鍵を登録していないと、リモートレポジトリからクローンしたりすることができない
レビュー時の操作方法 docs.github.com
(高度) CI/CDがわからない
- プルリクエストをOpenしたときやmainブランチにマージしたときなど、どのような動作をするのかを決めていることが多い
- この部分が理解できていると、開発の効率化やレビューの簡易化などを実現することができる
- GitHub Actionsなど、実現手段はいろいろなので、詳しくはエンジニアに聞いてほしい
おわりに
- 「こういうのもあるよ」とかあったらDMでこっそり教えてください。お待ちしています。
