「Grow All」を合言葉に企業やサービスの成長に向き合うニジボックス。当社のデータマネジメント職はリクルートのさまざまな部門と連携し、データの価値を最大化することでプロダクトの成長を加速させています。

今回はリクルートが展開するオンライン学習サービス『スタディサプリ』の裏側で、大規模かつ複雑なデータと日々格闘するBIエンジニアにインタビュー。数億レコードのデータを扱う現場の難易度、それを乗り越えた先にあるやりがい、キャリアの可能性について語っていただきました。

事業の意思決定を支えるBIエンジニアの役割

──ニジボックスに入社するまでの経緯とデータの世界に惹かれた理由などをお聞かせください。

前職、前々職から一貫してデータ関連のキャリアを歩んできました。もともと、課題を見つけてそれを解決していくプロセスが好きで、データの世界はまさにその連続だと感じています。よく「データは宝の山だ」と言われますよね。膨大な情報の中からビジネスに活用できる価値の高い情報を見つけ出し、事業の役に立つ形に整えるプロセスには宝探しのような面白さがあり、強く惹かれています。

ニジボックスには2024年の10月に入社しました。間もなく1年を迎えようというところです。ただ充実した日々を送っているおかげか、本当にあっという間でしたね。

──現在の具体的な業務内容について教えていただけますか？

リクルートが提供する『スタディサプリ』の事業部でBIエンジニアとして営業部署と密に連携しています。主な業務は営業からの依頼に基づくデータ抽出と、KPIを定点観測するためのモニタリングダッシュボードの構築・運用です。データウェアハウス（DWH）にあるデータをSQLで加工し、Tableauを用いて可視化するところまでを担当しています。

──『スタディサプリ』と一言で言っても扱うデータは多岐にわたりますよね。

おっしゃる通りです。その中でも主に扱っているデータは二つ。一つはサービスを利用する生徒さんの学習データです。そしてもう一つ、営業部署と連携していることから彼らが営業活動を管理しているSalesforceのデータも扱います。つまり、プロダクトの利用実態に関するデータと、ビジネスの最前線である営業活動のデータの両方を掛け合わせてインサイトを導き出す、という役割を担っているわけです。

──チームとしてのミッションはどんなところにあるのでしょうか。
私たちのチームのミッションは、営業部署から依頼されたデータやダッシュボードをQCD（Quality、Cost、Delivery）を高いレベルで担保した上で納品することにあります。特に営業活動はスピードが命。彼らの意思決定の速度を落とさないためにも品質と納期は絶対的な使命として強く意識しています。単にデータを提供するだけでなく、事業の推進力となる品質とスピードを両立させることが、私たちBIエンジニアの存在価値だと考えています。

大規模かつ複雑なデータへの技術的挑戦と壁を乗り越える工夫

──扱うデータの規模感について、エンジニアの観点から教えていただけますか？

正確に数えたわけではありませんが、データ量が非常に多いことは言うまでもありません。たとえば生徒の動画視聴履歴に関するテーブルひとつをとっても数年分のログが蓄積されており、レコード数で言えば億単位に達します。またユーザー数が多く、視聴のたびにログが生成されるためデータ量は増え続ける一方です。視聴履歴関連のデータだけでも莫大なファイルサイズで、しかも無数にあるテーブルの一部に過ぎない、と考えていただくと規模感が伝わるかと思います。

──億単位のレコード、無数のテーブルがもたらす技術的難易度というのはどういった点にあるのでしょうか？

まずパフォーマンスの問題が挙げられます。大量の生データをDWHから直接『Tableau』で読み込んで可視化しようとすると表示が極端に重くなり、実用的な速度で動作しません。そのため私たちのチームではDWHと『Tableau』の間に中間テーブル、いわゆるデータマートを構築しています。あらかじめダッシュボードで必要な集計や計算処理を済ませた軽量なデータセットをデータマートとして用意しておくことで、ユーザーがストレスなく分析できるパフォーマンスを担保します。このデータマートの設計がBIエンジニアの腕の見せ所の一つです。

またデータ抽出の定義も複雑になりがちです。少しでも定義を誤ると大規模なデータの中から誤った結果を導き出してしまい、大きな手戻りが発生します。特にデータの量が多いと抽出後に「数字が合わない」といった事態を引き起こしがちです。そのたびに原因を調査し、バグを特定して修正するという検証作業が発生するため、クエリの正確性には細心の注意を払っています。

──データ種類の多さ、複雑さという観点からはいかがでしょうか？

こちらも非常に難易度の高いポイントだと思います。一つのKPIを算出するために複数の異なるテーブルを参照し、結合することは日常茶飯事です。そのためにはそれぞれのテーブルにどのようなデータが、どのような定義で格納されているかを正確に把握する必要があります。ここができていないとビジネスサイドが求める正しいデータを抽出することができません。データ構造の全体像を把握し、数多くのテーブルの中から適切なものを探し出す能力が常に求められます。

──業務では期ごとにKPIが変わり、その都度ダッシュボードの改修が必要になると伺いました。

営業戦略の変更に伴い、モニタリングすべきKPIの定義も期ごとに変化します。そのたびに私たちはダッシュボードの改修や、時にはゼロからの新規構築を行います。KPIの定義が変わるということは参照すべきデータの種類や、計算ロジック、データマートの構造そのものを見直す必要があるということです。既存のものを修正する場合もあれば、全く新しいデータマートを設計し直すこともあります。

──入社以来、最も困難だったのはどのような案件でしたか？

入社して間もない頃に担当した、主要KPIダッシュボードをゼロから構築した案件ですね。私にとって『Tableau』を本格的に業務で使うのが初めてだったということに加え、データソースとして『Salesforce』との連携が必要な、非常に複雑な要件でした。技術的な挑戦もさることながら、関係各所とのコミュニケーションという面でも難易度が高かったです。

──コミュニケーションの難易度について具体的に教えていただけますか？

最も大きなポイントは、データをシステム構造で捉える私たちと、日々の業務オペレーションの観点から捉える営業担当の方々とでそれぞれ着眼点が異なることでした。こちらとしては『Salesforce』のどのオブジェクトのどの項目が必要なのか、データがどのような形式で入っているのかを正確に把握したい。しかし営業担当の方にとってそれは日常的に意識する部分ではありません。そこで何度も打ち合わせを重ね、実際に『Salesforce』の画面を見せていただきながら「このボタンを押した時に記録されるのはこのデータですね」というように、一つひとつ認識をすり合わせる必要がありました。

彼らの業務フローを深く理解し、それをデータの世界の言葉に翻訳していく。そのプロセスが最も困難であり、同時に取り組みの成否を分ける重要な部分でした。

課題と向き合う面白さと、チームとしての品質追求

──現在の業務について、最大の課題は何だと捉えていますか？

先ほどの話にも通じますが、ビジネスサイドとデータエンジニアサイドの「認識のズレ」をいかに埋めるか、という点に尽きます。これは継続的な課題であり、私たちBIエンジニアが常に直面するものです。

──認識のズレに関する具体的なエピソードがあればお聞かせ願えますか？

よくあるのが、私たちが依頼通りに抽出したデータをお渡しした後に「自分たちが持っているデータと数字が合わない」という問い合わせをいただくケースです。調査してみると、実は営業チームが独自で使っている集計ツールと私たちが参照している全社的なDWHとで、データの定義や集計のタイミングが異なっていることが原因でした。たとえば「受注」という同じ言葉でも、営業チームのツールでは「口頭での合意時点」を指し、DWHでは「契約書への捺印が完了した時点」を指している、といった具合です。

──どちらも間違っているわけではない、という点が難しいですね。

そうなんです、誰も間違ってはいないんです。ただ見ている世界の“定義”が違うだけ。しかもDWHのデータ定義はプロダクト運営サイドが管轄しているため、私たちBIチームが勝手に変更することはできません。

この状況で私たちができるのは両者の定義の違いを正確に理解し、なぜその差分が生まれるのかをビジネスサイドに丁寧に説明することです。いわば、異なる言語を話す人々の間に立つ“翻訳者”としての役割が求められます。ジレンマと向き合い、コミュニケーションを通じて解決に導く力は、この環境だからこそ磨かれるスキルだと感じています。

──これだけ複雑なデータを扱うとなると、アウトプットの品質を担保するチームとしての工夫も重要になってきますね。

おっしゃる通り、品質担保は最優先事項です。そのために私たちのチームではレビュー体制を非常に重視しています。SQLクエリの書き方はメンバーによって癖が出ますし、複雑なロジックになればなるほど一人の人間が最初から最後まで完璧に作業するのは困難です。ミスは起こるものだという前提に立ち、作成者以外の複数人の目で必ずロジックとアウトプットをチェックする体制を敷いています。このピアレビューの文化が、チーム全体の品質を高いレベルで維持する生命線になっています。

──品質向上や業務改善に新しい技術を活用することはありますか？

二つあります。一つはリクルート側で導入を進めている「dbt（data build tool）Test」の活用です。これは、テーブルのデータ品質を自動でテストする仕組みです。たとえば「このカラムにNULLが入ることはあり得ない」「このIDはユニークであるべき」といったルールを定義しておくと、それに違反するデータが入った際に即座に検知できます。これによりデータソース自体の品質を高め、手戻りを減らすことができます。

もう一つは私たちのチームが独自に進めている生成AIの活用です。スポット的なデータ抽出依頼に対して、依頼内容からSQLクエリを自動生成できないか検証しています。これにより定型的な業務を自動化し、より創造的で難易度の高い課題に時間を使えるようにしたいと考えています。

ニジボックスで描く、BIエンジニアとしての成長と未来

──ふだん使われている技術スタックについて、あらためて教えてください。

BIツールは『Tableau』、DWHはBigQuery、SalesforceからBigQueryへのETLには『TROCCO(R)』というSaaSツールを使用しています。作成したSQLクエリなどのコードは『GitHub』でバージョン管理しています。

──前職ではLookerを使われていたそうですが、Tableauとの違いはどんな感じですか？

それぞれに良さがありますが、一言でまとめると「『Looker』は開発者に優しく、『Tableau』はビジネスユーザーに優しい」と感じます。『Looker』はLookMLという言語でデータモデルをコードで管理できるため、Gitでのバージョン管理や変更履歴の追跡が容易。開発者にとっては非常に統制が取りやすいツールです。

一方、『Tableau』はドラッグ＆ドロップの直感的な操作で非常に自由度の高い、表現力豊かなビジュアライゼーションを作成できます。その結果、見る人にとって視認性の高いダッシュボードを作りやすいのが最大の強みですね。ただし、その自由度の高さゆえにしっかりとしたルールを定めないと管理が煩雑になりがちなので、そこは工夫が必要です。

──この環境で働くことでデータエンジニアとしてどのようなスキルが磨かれると思いますか？

まず間違いなく“データに対する深い感覚”が磨かれるでしょう。SQLでのデータ抽出からデータマートの設計、そして『Tableau』でのダッシュボード構築と、データがインサイトに変わるまでの一連の流れに深く関与するためです。データがどのように流れ、どうすればビジネス価値に変換できるのかという感覚は、単にツールが使えるというレベルを遥かに超えたデータ専門家としての本質的な市場価値につながるはずです。

──すでにキャリアを積んできた経験者にとっての魅力は何でしょうか？

未整備な環境を自らの手で改善していくダイナミズムではないでしょうか。私たちの部署はまだ新しく、データ活用の基盤も発展途上です。だからこそ「もっとこうすれば効率化できる」「この課題にはこういうアーキテクチャが有効ではないか」といった提案を形にしていくチャンスに恵まれています。これは、完成された環境では味わえない大きなやりがいです。

加えて育成への関与です。チームには多様なバックグラウンドを持つメンバーがいます。経験豊富な方が自身の知見をチームに還元し、メンバーのスキルアップを支援することでチーム全体のパフォーマンスを底上げしていく。そうした役割に挑戦したい方にとっても最適なフィールドだと思います。

──最後に、ニジボックスに興味を持ちつつあるデータエンジニアの方へ、メッセージをお願いします。

これまでのデータエンジニアとしての経験を通じて「もっと大規模で複雑なデータと格闘したい」「混沌とした状況を整理し、価値を創造することに喜びを感じる」という方にとっては最高の環境です。リクルートのデータマネジメントの専門家から直接学べる機会も豊富にありますし、技術的な挑戦も推奨されています。

まずは自身のスキルをよりレベルの高い課題で磨きあげ、データエンジニアとしての専門性を突き詰めていきたいという方にぜひチャレンジしていただきたいと思います。その上で、本人の志向性次第では、分析スキルを身につけてデータアナリストやビジネスサイドへとキャリアを広げていく道もあると思います。技術の深堀りや、横展開にも適した環境がニジボックスにはあるのではないでしょうか。