LayerX エンジニアブログ

LayerX の エンジニアブログです。

LayerXのデータ基盤の未来を語るために、最初の1ヶ月でやった3つのこと

この記事は、LayerX Tech Advent Calendar 2025 の 19日目の記事です。

tech.layerx.co.jp

おはようございます、こんにちは。そして、こんばんは。バクラク事業部 BizOps部 データグループへ25年11月に入社した さえない( @saeeeeru )です。 命名理由が気になる方は、カジュアル面談で話しましょう。

jobs.layerx.co.jp

今回は、入社してから1ヶ月で「LayerXのデータ基盤の未来を語るためにやったこと」を、整理したいと思います。

TL;DR

  • LayerXのデータグループがBizOps部にいるのは「事業成果に直結するデータ基盤を作る」という意思表明
  • 入社1ヶ月でやったこと: ①愚直な情報収集 ②Quick Winで信頼貯金 ③事業構造の理解
  • 「誰のための、何のためのデータか」を問い続ける環境で働いています

データグループは何しにBizOps部へ?

「データグループがBizOps部にいるの?」

入社前に自分が抱いていた、正直な感想です。データ基盤といえばプラットフォームエンジニアリングやインフラ部門に置くのが一般的だと思っていました。 実際に今年の春頃までは、プラットフォームエンジニアリング部に所属していたとのことでした。入社して1ヶ月経った今、ようやくBizOps部にいる意図がクリアに見えてきた気がします。

BizOps部がそもそも何をしているのか

LayerXのBizOps部は、2022年頃に立ち上がった組織で、ざっくり言うと「事業戦略とオペレーションをつなぐ役割」を担っています。

立ち上げの背景には、急成長するバクラク事業特有の課題*1がありました:

  • 社内プロセス・システムが複雑化し、管理・対応工数が爆発
  • リソースがサイロ化して、横の連携が取りづらくなった
  • 複数部門に跨るイシューの「誰がオーナーなの問題」が頻発

LayerXは後発でプロダクトを市場に投入しているため、先行企業を追いかける立場です。そのため、創業時から複数プロダクトを意図的に提供するコンパウンド戦略をとっています。 複数プロダクトを高効率なオペレーションで顧客へ提供するために、BizOpsが存在しています。

なぜデータ基盤がBizOpsの中にあるのか

BizOps部には、以下の役割が内包されています*2

BizOps部の役割

また、BizOps部は今年に入って「AIの業務組み込み」に注力しています。たとえば、下記のような事例が出てきています。

note.com

LayerXの事業を非連続に成長させるには、組織の拡大に耐えうるファクトベースな意思決定を前提としつつ、業務の隙間にAIエージェントを入り込ませることで、圧倒的な効率性を実現する必要があると考えています。 また、そのモメンタムを最大限に加速させるのがデータグループの役割であると理解しています。

データグループのテックリード 兼 Snowflakeのエキスパート である @civitaspo さん の言葉を借りるならば、データグループがBizOps部にいるのは、 「事業成果に直結するデータ基盤を作る*3という意思表明でもあります。

New Joinerとして入ってきた自分にとって、この組織設計はかなり新鮮でした。データエンジニアがビジネスの最前線にいる。 それが当たり前の環境で働けることに、とてもワクワクしております。「データ基盤の進化」こそが、AI時代の企業の競争力を決定づけると思っています。

Youは何しにLayerXへ?

あらためての自己紹介になりますが、こんにちは。「カッコいいおっさんになりたい」31歳の熊本出身の九州男児、さえないです。

さえない経歴

LayerXで成し遂げたいこと

みんながBe Animalであるために、Fact Baseをバリ楽にしたい*4

常に事業へ向き合ってきた経験とアナリティクスエンジニアリングの知見を活かして、 地元・熊本の地下水のように、澄んでしなやかなデータ基盤に進化させたいと考えています。

澄んでしなやかなデータ基盤に

データの流れを、熊本の地下水のように自然で、人もAIエージェントも当たり前に美味しく使える状態にすること。それが自分のミッションです。

本題「LayerXのデータ基盤の未来を語るために、最初の1ヶ月でやった3つのこと」

入社して1ヶ月、自分が取り組んできたことを振り返ると、3つのアプローチに整理できます。

1. AIに任せず、愚直に情報を集める

入社して最初にやったことは、自分の手で情報を集めることでした。 Bet AIに反する行動には見えますが、中長期のBet AIのためには必要なステップでした。

Notionを中心に、Slack、Google スライド、週次定例の録画など、LayerXには情報がオープンに蓄積されています。 AI時代のいまなら「MCPを使って、Claude Codeに要約させよう!」と考えるところですが、最初の1ヶ月は意図的にそれを避けました。

AIが要約した情報は効率的ですが、文脈や温度感が落ちるため、読んでいても目が滑ることが多くあります。 入社直後こそ、非効率でも生の情報に触れることが大事だと考えていました。 自分の目で読むことで「この会社がどこに向かっているのか」が体感として入ってきます。

2. Quick Win で信頼貯金を貯める

情報収集と並行して、「手を動かせるタスク」にも着手しました。 それは、データアプリを簡単に構築できるSnowflakeの機能であるStreamlit in Snowflake*5 の CI/CD 環境構築です。 また、12月にPublic PreviewとなったSiS Container Runtime*6の検証・移行も実施し、 Warehouseベースの実行環境からContainerベースへ切り替えることでコンピュートコストの削減を実現しました。

これにより、以下のメリットを享受できました :

  • コードを書くことで、チームの開発スタイルがわかる
  • インフラ整備を通じて、データ基盤の全体像が頭に入る
  • 「目に見える成果」で信頼を貯める
  • データユーザに広く存在を認知してもらう

3. データモデリングのまえに、事業構造を理解する

アナリティクスエンジニアの主な仕事は、アジャイルなデータモデリングや、データ構造とビジネス上の概念とを繋ぐ中間層であるSemantic Layerの設計・実装です。 これまで 爆速なエンジニアリング に仕事人としての喜びを感じていた自分でしたが、今回は意図的に後回しにしました。

なぜなら、「誰のための、何のためのデータモデルなのか」が見えていなかったから です。

THE MODEL(マーケティング → インサイドセールス → フィールドセールス → カスタマーサクセス)の各部署には、それぞれのKPIと課題があります。 人員拡大フェーズにおいて、何が痛みになっているのか。その解像度なしにモデルを作っても、「使われないデータ」が生まれるだけです。

そこでまず取り組んだのは、事業構造とKPIの整理 です。各部署がどんな指標を追い、その奥でどんな人がどんな意思決定をしているのか。 月報やダッシュボードを読み解きながら、データの「ユーザー」を解像度高く理解することに時間を使いました。

次に、事業目標からバックキャストしたときに生じる課題の言語化 です。 LayerXが登りたい山から逆算すると、現状のデータ基盤には何が足りないのか。人員拡大フェーズで顕在化しうる問題は何か。 自分なりの仮説をドキュメントに落としていきました。

そして、データ基盤の「現状」と「これから」の言語化 です。 データマネジメントの各領域で現状をアセスメントし、「何ができていて、何が足りないか」を問題としてリストアップ。 その上で、AI-Readyなデータ基盤に進化するために、チームとして何を優先すべきかを整理しました。

これらのドキュメントは、まだ自分の中で咀嚼している段階ですが、この過程がチームでの議論の土台になると考えています。

おわりに

LayerXのデータグループは、技術の枠に閉じません。 BizOps部という事業の最前線にいるからこそ、「誰のための、何のためのデータか」を常に問い続けられる。 この環境で、熊本の地下水のように澄んでしなやかなデータ基盤を作り上げることが自分の決意です。

「BizOps部でAI-Readyなデータ基盤を作る」という挑戦に興味を持った方、ぜひお話ししましょう。 アナリティクスエンジニアのカジュアル面談はこちらから 👇

jobs.layerx.co.jp