こんにちは、データテクノロジーユニット D3M 部の @beniyama こと山邉と申します。

D3M とは Data Driven Decision Making の略で、下記の組織概要にありますように『データマネジメントを通して経営資源としてのデータの価値を引き出し、意思決定の速度と精度を最大化する』ための組織になります。

具体的には、経営の意思決定やプロダクト戦略の策定など、様々なデータ利活用に対するデータ環境の要件を整理し、それを満たすための BI ダッシュボードやデータマートの構築など各種モニタリング基盤の整備などを行っています。

この度、データを活用した意思決定やプロダクト開発のスピードを加速させるべく、D3M 部において『アナリティクスエンジニア』の募集を新たに始めたので紹介させていただきます。

アナリティクスエンジニアとは

DevelopersIO 2021 のクラスメソッド様の発表 を読んでいただければそれで終わってしまうのですが、あえて３行で書くと下記になります。

• 分析にすぐ使えるクリーンなデータ環境を提供するために
• ソフトウェアの開発手法を活用して生産性の高いデータ管理を実現する
• データアナリストとデータエンジニアの架け橋となる存在

上記の図にもある通り、D3M 部もまさにデータサイエンス部とデータエンジニアリング部と居を共にしており、事業価値の高い、信頼性のあるデータをいかに提供していくか？ということに日々向き合っています。

アナリティクスエンジニアリングの重要性

データの活用フェーズが進み、データの種類や利用用途が増え続ける中で、いわゆる『データの民主化』を進めていくと下記のような問題に当たるのは必然です。

• データ項目の意味や定義（スキーマや取りうる値、どこ由来のものなのか etc）がわからない
• ビジネスロジックの定義が乱立し、『有料会員数』や『継続率』のような重要 KPI でも抽出する人や経路によって値が変わってしまう
• 適切なデータの抽象化やデータアクセスガイドラインの整備が行われておらず、コピペで作られた（けどちょっとだけ違う）作成意図が不明で保守不可能な SQL やテーブルが量産される
• 属人的なワークフローが増えていき、データの品質担保（不正な集計、異常値や欠損値への対処、ジョブの実行順序保証 etc）が十分に行えない

などなど…

データ基盤開発の延長線でルールが整備されることもあれば、活用側であるデータ分析の中で中間テーブルやレポーティングジョブなどが作られていくこともあると思います。

しかしながら、下記のような事由から データに関する技術的負債もまた気を緩めればすぐに生まれてしまう もので、持続的に、体系立てた形でガバナンスをかけていくことはなかなか難しいです。

• プロダクトの成長に伴って増え続けるワークフローやデータソースに対して、（開発側組織と適切に連携を取りつつ）継続的・定常的に品質管理を行わなければいけない
• 事業企画や営業、マーケティング部門などデータ利活用のステークホルダーは至る所にいるので、様々な業務要件に対する全方位対応を迫られることが多い
• 依頼ベースでのデータ抽出や分析・レポーティングではオーバーヘッドが大きいため、意思決定者が自身で試行錯誤を行えるような環境を志向する必要がある

そこで、データ量や種類、ステークホルダーの多さ、求められる提供品質・速度の高さといったこれらの課題に対して、ソフトウェア開発のプラクティス導入を主軸としたアプローチで取り組むのがアナリティクスエンジニアです。

具体的には CI/CD による自動化やテストの導入、データ処理コードのモジュール化というようなデータマネジメントの効率化を図っていきますが、一方でドキュメントの整備や SQL を始めとしたデータ活用のためのトレーニングも担当します。BI ダッシュボードやデータマートも『事業価値を生むための一つの社内プロダクト』として捉え、その利活用を最大限に高める役割である、とも言えると思います。

テクニカルな手法が脚光を浴びがちではありますが、社内ユーザーも巻き込んで組織全体におけるデータ利用の在り方をリファクタリングしていくということがアナリティクスエンジニアリングであり、今後のモダンなデータ組織には欠かせない存在であると言われる所以ではないでしょうか。

期待役割とその魅力、将来性

アナリティクスエンジニアへの期待は多岐に渡りますが、主な成果物となる BI ダッシュボードやデータマートを軸に捉えるとわかりやすいと思います。

• 信頼性の高いデータの提供 : ビジネスロジックによる変換処理の前であれば、マスタデータの一意性や、欠損していないログ、適切な同期タイミングなど、まずデータソースのレベルで SLA (Service level agreement) を満たせるかが重要になります。また、ビジネスロジック適用後のセマンティックレイヤでは、意味の一意性・一貫性（同じ指標に対して複数の定義が存在しないこと）の保証が重要です。そのため、KPI などの指標定義をステークホルダーと議論しながら要件定義に落とし、さらにそれの使用を徹底させていくような役割も期待されます。
• 継続的・持続的な開発手法の導入 : データの信頼性を継続的に維持するためには、定期的なモニタリングに加えて CI/CD による自動テストの導入も不可欠です。また、データ処理の拡張性を担保するには DRY (Don’t repeat yourself) 原則に則った形で適切な単位のモジュールに分解され、構造的・かつ可読性高いコード管理を実施する必要もあります。GitHub などを活用したバージョン管理や、プルリクエストを通したレビュー・デプロイ戦略も有効です。
• 利活用向上のための継続的な改善 : BI ダッシュボードやデータマートは開発したら終わり、となりがちですが、実際に意思決定やプロダクトとしての事業価値を創出しなければ意味がありません。そのため、一般的なプロダクトと同じように利用状況をモニタリングしながら使われない機能（ダッシュボードやデータマートなど）や離脱してしまったユーザーについての要因分析を定期的に行い、課題への対処を実施します。社内向けではありますが、いわゆるカスタマーサクセスの一環としてドキュメントの拡充や、ユーザーに向けた勉強会の実施などを行います。

『分析にすぐ使えるデータ』を提供するためには、自身が提供するデータがどのように使われるか？を理解する利用者目線が必要ですし、また DevOps の Ops にかかるコストを抑えながら継続的な改善を実現するためにはモダンな開発手法の導入が必要になります。

さらには、モニタリングや振り返りを通しながらプロダクトグロース（= データによる事業貢献）を成し遂げていく、というとてつもなくやりがいがあり、かつ重要性が高い役割です。

アナリティクスエンジニアはまだ生まれたての職種ということもあり、業界全体でも明確なキャリアラダーを置いているところは少ないです（ 参考 ）。

リクルートにおいても、現在必要とされる専門性や、他職種との接点も含めたキャリアパスを絶賛整備中ですが、データビジネス・データサイエンス・データエンジニアリングをバランスよく扱うポジションということもあり、柔軟な選択肢を持てると考えています。

業務ドメインとしてもデータマネジメントそのものを体現する役割ですので、DMBOK に代表されるデータマネジメント知識を専門性として持ちつつ、エンジニアリング手法を活用した BI / データマートのモノ作り、またビジネス観点での価値提供を実践していける人材は、この先ますます市場価値が上がっていくのではないでしょうか。

おわりに

クラウド技術の進化に伴って ETL (Extract / Transform / Load) から ELT (Extract / Load / Transform) にシフトしていき、データ基盤ユーザーがより柔軟にそれぞれの分析を行うことができるようになってきた一方で、分析の自由度を保証しつつも適切なガバナンスをかけることの難しさが顕在化してきたように思います。

Transform が最後のステップに来てユーザーにも開かれつつある中、dbt や Dataform といったデータ変換処理技術と、そこで活躍するアナリティクスエンジニアに注目が集まるのは必然とも言えます。

リクルートにおけるデータの利活用は全事業領域で着々と進んでいますが、データの信頼性が担保されなければ、データ分析にせよ、レコメンドエンジンなどのプロダクト機能にせよ、あらゆるデータ利活用は実現しえません。現在、リクルートの未来を一緒に切り拓いていただける アナリティクスエンジニアを積極採用中 ですので、ご興味のある方は カジュアル面談 からでも、是非気軽にご連絡をいただければと思います！