misaltag.blogspot.com
🎁 記事を最後まで読んで Amazonギフト券1,000円分が当たるアンケート に回答しよう 📝
世間でデータの利活用やDX（デジタルトランスフォーメーション）の手法が盛んに議論される一方、データの利活用環境やそれを整備するデータ組織・人材について「理想と現実のギャップ」に苦しむ企業は少なくないでしょう。
そうした企業にとって、事業で得られたデータをスピーディーな意思決定につなげたり、そのプロセスを牽引する人材を育成したりすることは、喫緊の課題であるように思います。
データを活用してカスタマー・クライアント双方の「不の解消」を目指すリクルートも例外ではなく、これまでさまざまな課題に直面してきました。そんな中、同社のデータ推進室では2022年、「データに基づく意思決定の実現」を目標に、D3M（Data Driven Decision Making）部を設立。高精度な意思決定を実現すべく、高品質なデータを提供するアナリティクスエンジニアという職種を導入しました。
一般的に、アナリティクスエンジニアが活躍するのはデータエンジニアやデータサイエンティストが兼務しがちなデータマネジメントの領域ですが、それをこのタイミングで新たな職種として確立させる、という思い切った試みの背景にはどのような思想、プロセスがあったのでしょうか。
今回は、D3M部におけるアナリティクスエンジニア育成・採用の背景について、データ推進室の各種専門性向上を目的とした横断組織であるデータテクノロジーユニット長の阿部直之さん、D3M部部長の山邉哲生さん、アナリティクスエンジニアをマネジメントするグループマネージャーの新堀秀和さんに対談いただきました。
※この記事は株式会社リクルートによるSponsoredContentです。
データマネジメントという、データ組織の「縁の下の力持ち」
── 今回の座談会では、この2022年4月にリクルートのデータ組織に新設されたD3M部と、そこで働くアナリティクスエンジニアに焦点を当てて、組織の成り立ちや具体的な業務内容をお聞きしていきます。まず、皆さんの簡単な自己紹介をお願いします。
阿部 前回までの座談会から引き続き、データ組織の専門性向上を担う横断組織の責任者という立ち位置で、D3M部も統括しています。
阿部 直之（あべ・なおゆき）
株式会社リクルート プロダクト統括本部 プロダクト開発統括室 データ推進室
データテクノロジーユニット長
山邉 今回ご紹介させていただくD3M部の部長を務めています。前職でソフトウェアエンジニアとしてWebシステムの開発に従事した後、2015年にリクルートマーケティングパートナーズ（現・リクルート）に中途入社し、『スタディサプリ』のデータ分析基盤開発などを担当してきました。
山邉 哲生（やまべ・てつお）
株式会社リクルート プロダクト統括本部 プロダクト開発統括室 データ推進室
D3M部 部長
新堀 私は2017年に、リクルート住まいカンパニー（現・リクルート）の開発ディレクション組織に中途入社しました。入社して間もなく、データの利活用を推進する目的で、D3M部の前身となる「データマネジメントグループ」の立ち上げに参画しました。これが私にとってデータに関するキャリアの始まりです。2021年の会社統合後は住まい領域やHR領域を担当しています。
新堀 秀和（にいぼり・ひでかず）
株式会社リクルート プロダクト統括本部 プロダクト開発統括室 データ推進室
D3M部 グループマネージャー
── そもそも、今回新設されたD3M部とはどのような役割を担う組織なのでしょうか。
阿部 データを管理する「縁の下の力持ち」です。データエンジニアリングにしろ、データサイエンスにしろ、大前提としてデータがそろっていて、それらが適切に管理されていなければデータの利活用は推進できません。
D3M部の発足前から、そうしたデータマネジメントを専門に取り扱う部署（データマネジメントグループ）は存在したのですが、業務範囲が広過ぎたことで課題も生まれるようになり、役割を再整理する必要に迫られたんです。
── なるほど。例えば、どのような課題に直面したのでしょうか。
新堀 一つ分かりやすい例としては「利用者の少ないBIダッシュボード*1やデータマート*2の大量生産」でしょうか。
リクルートにとってデータの利活用は事業の要ですが、だからこそさまざまなステークホルダーからの「こういうデータや数字が見たい」という依頼がデータマネジメントグループに集中してしまいがちです。そして、その依頼に応える形で大量のダッシュボードやデータマートを高効率的に開発・提供しても、その場では喜ばれるものの、次第に参照されなくなっていく。
組織として、たくさんの依頼や相談を受けること自体は喜ばしいのですが、いつの間にか依頼に応じることを優先し、受けた依頼を自分たちで咀嚼することなくそのまま遂行してしまう、所謂「請け負い気質」になってしまっていたのだと思います。
阿部 そもそも「請け負い気質」になっていた要因として、データマネジメントという言葉から期待される業務内容の認識が各領域で食い違っていたこと、また、この広範な概念のなかで自分たちの業務範囲や提供価値を明確に定義できていなかったことが大きかったように思います。
なので、今回D3M部を組成する上ではデータマネジメントに携わる人の仕事のスタイルを変えようとしました。具体的には、「来た仕事を請け負っていく」プル型から、「我々の仕事はこうで、こういう価値を出す」とアピールしていくプッシュ型に切り替えようとしました。
── たしかに、業務範囲が広いからこそ「請け負い気質」になりやすい側面はあるかもしれませんね。
阿部 明確な定義が存在するデータエンジニアリングやデータサイエンスと違って、データマネジメントの仕事は、「それら以外全部」になりがちです。非常に重要な役割である一方でカバー範囲が幅広く、専門性が定義しづらいんです。
2021年の会社統合から2年の間、いかにしてこの領域の専門性を定義するのか、という議論を続けてきましたが、今回組織の提供価値をD3M（=データに基づく意思決定の実現）と位置づけることで、最終的にデータが活用されているイメージを想起しやすくしました。その営みのなかで、「アナリティクスエンジニア」という一つの役割が見えてきました。
山邉 ただ、今のD3M部が最終形だとは考えていません。今まで定義しきれなかった部分を徐々に整理していますが、D3Mというコンセプトを実現させるためにはアナリティクスエンジニアの職種定義だけではまだまだ足りていないと感じています。
アナリティクスエンジニアとはどんな職種か。「困難を極めた」議論の果てに
── そうしたデータマネジメントの領域や、そこに従事するアナリティクスエンジニアの仕事は必要不可欠だと思う一方、先ほどもおっしゃっていましたが、業務範囲が広いだけに、職種を定義するのが難しそうです。
阿部 正直、職種の議論は困難を極めましたが「世の中の流れに従う」というスタンスではなく、実際に今活躍している社内外の人材や事実をベースに議論しました。例えば、新堀さんというロールモデルがあるなか、そのような人材を育成し彼らに更なる機会を提供するにはどうすれば良いか、など、個別の人や技術、課題に対する解像度を上げながら少しずつ前進していきましたね。
── なるほど。まずは実態ありきで、そこにうまくはまるような枠組みを作っていったという感じでしょうか。
山邉 そうですね。そして、一連の議論のなかで浮かび上がった職務に最もフィットする職種がアナリティクスエンジニアでした。アナリティクスエンジニアは比較的新しい職種です。データエンジニアやデータサイエンティストがこれまで兼務する形で担っていたデータの整理やデータ利活用の環境整備をいかに効率化するか、またいかに効果的にデータを活用するか、という課題意識がもとになって生まれた職種だと理解しています。
ちょうどそこに データの変換を効率化するdbt*3、Dataform*4といったデータマネジメントの関連技術も現れ始めました。
こうした背景があるため、私たちの課題意識やそれに対するアプローチも世界的なトレンドと重なっている感覚があるのですが、一方でアナリティクスエンジニアの専門性や、キャリアパスについてはまだまだ社内で議論を重ねている最中です。エンジニアリングもアナリティクスもビジネススキルもバランス良く求められる職種であるがゆえに、データ組織の内外を含めたさまざまなキャリアパスが考えられると思います。
新堀 私も昔は、エンジニアとしてプロダクトを開発していたこともあり、開発プロセスの整理という観点での取り組みはかなり推進できたように思います。一方で、ビジネスサイドの視点を理解し、時にはこちらから提案をしながら進めることができていなかったために、開発したダッシュボードやデータマートが十分に利用されない状況に陥ったのだ、という反省があります。だからこそ、データ分析者・意思決定者の目線に立った要件定義もアナリティクスエンジニアに必要な素養ではないかと思います。
阿部 今までは、データ組織のなかでもエンジニアリングとビジネスの両サイドにまたがるようなポジションがありませんでした。ただ、一般論として、それぞれのスペシャリティが明確になれば、その間を担うジェネラリティも必然的に必要になってきます。専門性を適切に結びつけることが組織全体のスループットの根源になるので、その部分を担うポジションとして、アナリティクスエンジニアに注目した形です。
「分析にすぐ使える」データを作るための技術
── さて、ここからはアナリティクスエンジニアの具体的な業務内容を深掘りしたいのですが、アナリティクスエンジニアとはそもそもどのようなポジションなのでしょう。
山邉 一般的な定義としては、「ソフトウェアエンジニアリングのベストプラクティスを活用し、“分析にすぐ使える（Analytics readyな）データやその環境”を提供する人」です。
例えば、データエンジニアは事業システムなどからELT（Extract/Load/Transform）のプロセスでデータを抽出して、BigQueryなどで構築したデータウェアハウス*5にデータを保存する仕組みなどを開発します。しかしながら、連携されたデータはそのままでは分析用途に使えないことが多く、適切なモデリングや変換、クレンジング、ビジネスロジックによる処理などが必要です。
── BigQueryのような技術が出てきたことで「SQLを覚えればビジネスの人もデータ分析できる」といった"ものの言い方"を聞くようになりましたが、現実には単に導入しただけではデータの海に溺れてしまうわけですね。
山邉 はい、一つのプロダクトやサービスから得られるデータは多岐に渡りますし、生データは分析用途で設計されていないことがほとんどですので、正しく整えられたデータ環境がなければ正しい分析は行えません。
例えば、「会員数」や「継続率」と一言で言っても、それらを扱う人の視点によって算出式が異なることもよくあります。どのテーブルのどのカラムをどのように結合・変換するか。時にはデータ組織の方からKPIを整理して、事業上運用する際も単一の定義を扱ってもらうよう提案・周知することもあります。
こうして分析者や意思決定者と同じセマンティクスで整理されたデータだけを扱えるようデータマートを整えれば、データの利活用時、生データの取り扱いに困ることはなくなるわけですが、併せてどこにどのようなデータがあるかといったメタ情報をカタログ化したり、データの使い方に関するマニュアルをデータポータルで整備したりすることも重要です。
また、ドキュメント化するだけでなく「データを使える人材を増やす」のも重要な役割の一つと位置づけられていて、実際、講習会を開いて弊社の執行役員にSQLを自ら教えたメンバーもいるほどです（笑）。そこまでして初めて、「分析・意思決定に資するデータ」を提供できたと言えると思います。
── ソフトウェアエンジニアリングのベストプラクティスはどのような文脈で活用するのでしょう。
山邉 データの品質を持続的に管理するため、SQLなどによるデータ変換処理のコード化、Gitなどを使ったバージョン管理、また継続的インテグレーション（CI）によるテストの自動化、定期的なバリデーションの実行、データリネージの生成などさまざまな形で活用します。
例えば、『スタディサプリ』を運営する弊社のまなび領域ではGoogle CloudのDataform（前述）という技術を使い、これまでアドホックに運用されていた変換処理を構造化して管理し、事前テストやデータ間の依存関係の可視化を可能にしました。また、拡張性も向上したので、ビジネスサイドの人たちがデータの変換処理を行い、Githubでのレビューをした上で本番環境にデプロイすることも可能になっています。
D3M部にはデータを使いたいさまざまな部署・人がコンタクトしてきます。先ほども触れた通り大量の依頼や相談が舞い込むなかで、人海戦術で対応するのは現実的ではありませんし、データの提供品質も劣化するほか、結局作ったものが使われなくなったというケースも少なくありません。ですので、利用者側を積極的に巻き込んでいくためにも、こうした技術を導入していくことが重要です。
── 技術を用いて、データの品質を保つためのプロセスを効率化するわけですね。
山邉 はい。加えて、「分析者・意思決定者目線で考える」ことも重要です。「データを利用する側が知りたいこと」を考えることが、その場しのぎのデータをつくるのではなく、本質的なデータモデリングをすることにつながります。ソフトウェアエンジニアリングの手法の導入によってデータのマネジメントコストを減らし、事業理解に注力できる状態を生み出すのが、アナリティクスエンジニアの本質的な価値だと思います。
適切に整理されていないデータは「嘘をつく」
── アナリティクスエンジニアがデータを整理して、ビジネスサイドに提供するまでにどのようなプロセスがあるのでしょうか。
新堀 例えば、意思決定者が「新しいKPIの数値が見たい」と言ったとします。必要なデータが収集され、分析できる状態でデータ基盤に入っていれば、すぐにデータアナリストが分析/集計し、提供できると思います。しかし、実際にはそういった状態にはないことが多いです。
そこで、データ基盤に入っている、関連する生データを見る、あるいは関連しそうなデータの発生源にさかのぼってデータを探索していきます。ただ、やみくもにデータの発生源を探索すれば良いのではなく、データの構造やビジネスロジックを見て、必要なデータにあたりをつけて探索します。その結果「そもそも、求めているデータはなかった」ということもあります。
また、意思決定者が希望するKPIのデータと、実際にデータ基盤から提供しているKPIの定義が乖離している場合も少なくありません。そうした前提を踏まえ、どういうデータを、どうやって加工・集計すれば、事業の意思決定に使えるのかを追求する。リクルートは、そこに投資できているところが凄いなとは思います。
── データを整理するのはとても骨が折れる作業なんですね……。
新堀 そもそも、未整備のデータではすぐに分析はできず、意図的に整備し続けたデータでなくては、事業における継続的な意思決定に使うことはできないと思いますので。
阿部 データってそこに「あるだけ」だと、ただの使えない情報の塊なんです（笑）。整理したり、解釈したりしないと活用できないのですが、整理の仕方がイマイチだと、嘘をついたりもするので……。
だから、データ利活用やDXの文脈では、データを適切なプロセスで整理できる人材が不可欠です。
あと、これまで主に技術の話をしてきましたが、リクルートのアナリティクスエンジニアにとっては「人とコミュニケーションして足りないデータを取りに行く」という作業も大切です。まずデータの所在を知っていそうな人にヒアリングして、そこで「あの人なら知っているんじゃないの？」という情報をもらって、また聞きに行く。社内ではRPG（ロールプレイングゲーム）と呼んでいますが、分析可能なデータを作る上では、そういう泥臭いプロセスも欠かせません。
── いわゆるプロダクト開発メインで携わるエンジニアよりは、コミュニケーション力が問われるのでしょうか。
阿部 アナリティクスエンジニアはエンジニアリングのベストプラクティスを活用する側という観点で、「エンジニアリングオリンピック」のような軸だけを想定してしまうと、上位に行きづらいのは確かです。しかしながら、他部署とのコミュニケーションも発生するデータマネジメントの領域はデータの利活用を進める企業にとって生命線となる非常に重要なものです。だからこそ、その価値に対して適切な専門性を改めて定義し、キャリアパスをきちんと整備していくことが、組織として不可欠だと思っています。
エンジニアサイドとビジネスサイドをつなぐ
── アナリティクスエンジニアには、どのような適性が必要なのでしょうか。
山邉 阿部の話にもありましたが、データエンジニアと同等のエンジニアリングスキルまでは必ずしも必要ありません。分析スキルに関しても同様で、どちらかというとエンジニアリング・データサイエンス・ビジネスという3つの視点をバランス良く備えていることが重要だと考えています。
例えば、ビジネス上の要求や分析要件からメトリクスを解釈し、データでの表現に「翻訳」することが求められます。また、それをSQLなどを使いながらデータマートとして実装していくためのデータモデリングのスキルであったり、開発を推進するための開発プロセスの理解も必要です。あとは、GitやCI/CD（継続的インテグレーション・デリバリー）の利用経験、またdbtやDataformなどのデータマネジメント技術の活用経験があれば、なお良いと思います。
── エンジニア出身者でなくとも、適性はあると言えそうでしょうか。
山邉 「D3M部にはエンジニアもいれば、ビジネスサイドの出身者もいます。技術よりも志向性の方が大事です。データマネジメントは、データ利活用の過程で誰もが一度は直面する課題です。また、データの可視化やレポーティングは事業貢献の観点でも即効性の高い業務ですので、データマネジメントを通して持続的な形で事業課題を解決していきたい方にとって、とてもフィット感のある職種だと思います。
阿部 キーワードは「翻訳」だと思っていて。ジェネラリストとして、エンジニアサイドとビジネスサイドをつなぐような知識をつけて、必要ならなんでも学びます、という気概のある方が向いています。
── ちなみに、アナリティクスエンジニアの日常は、どんなものですか。
新堀 普段、一緒に業務をさせてもらっているのは、プロダクトマネージャーやマーケター、開発者やセキュリティ担当、経営層など非常に広範囲です。おかげさまで、リクルートの社内でも、知人・友人は多い方です（笑）。
そうした人脈のおかげで、事業領域をまたがった形でデータマネジメントのための横断ツールを作れないか、という話で盛り上がったりもしています。データマネジメントというと地味な印象を受けるかもしれませんが、事業としてはリターンがとても大きな仕事だと思っています。
── まさに「つなぐ」という言葉がフィットする仕事ですね。最後に、D3M部の直近の取り組みや目標を教えてください。
阿部 元々「住まい領域」で活躍していた新堀さんに他領域を支援してもらった結果、成果が出たことで、「こういう取り組みを進めることで価値が出る」という解像度が上がりました。このような形で、領域横断的に人を動かし、蓄積された仕組みや知識を横展開することにチャレンジしていきたいですね。
新堀 「D3M部と話をすれば、より早くデータを使った意思決定ができる」、「誰よりもその領域のデータに詳しい人」という状態をつくっていきつつ、データを使った意思決定の阻害要因を少しでも多く取り除けるよう活動していきたいと思っています。
山邉 依頼や相談ドリブンで動くのではなく、「仕掛ける」組織にしていきたいです。dbtをはじめとした技術の導入による効率化もそうですが、これまで提供してきたBIやデータマートなども一つのプロダクトとみなして継続的に改善することでより良いデータエクスペリエンスの実現につなげていきたい。そのためには事業理解を通して利用者目線で要件定義することが重要ですし、その先にしかデータの民主化は存在しないと考えています。
── ありがとうございました。
SUUMOやスタディサプリなどリクルートの各事業におけるアナリティクスエンジニアの取り組みをご紹介するイベントを開催します。
また、10月に開催されるアナリティクスエンジニアのカンファレンスである dbt Coalesce の現地の様子についても少し触れさせていただきますので、データによる意思決定や、それを実現するためのデータマネジメントにご興味ある方はぜひご参加ください！
イベントの詳細はこちら
「リクルートの中でのアナリティクスエンジニアの役割」についてより詳しく知りたい方は、データ推進室の公式ブログ記事へ
ではエンジニアを募集中！
今すぐの転職を考えていなくても、希望職種に関する情報やスカウトを受け取れるキャリア登録の仕組みも用意されています。少しでも興味のある方は👇気軽にクリック！
さまざまな取り組みの裏側やナレッジ、厳選した採用情報もSNSで発信中！
🎁 Amazonギフト券が当たる！ リクルートに関するアンケート 📝
関連記事
旧リクルート各事業会社によるSponsoredContentもあわせてお読みください。
[SponsoredContent] 企画・制作：はてな
取材・構成：星暁雄
撮影：曽我美芽
Adblock test (Why?)
からの記事と詳細 ( ビジネスとエンジニアリングをつなぐ「アナリティクスエンジニア」とは。リクルートが“価値あるデータ整備”のための新たな職種に着目した理由 - はてなニュース )
https://ift.tt/5z3ZXMB
F1のチーフテクニカルオフィサーであるパット・シモンズは、2026年のまったく新しいF1エンジンレギュレーションによって、F1がギアをシフトダウンするのではないかという懸念を軽視した。
