先日2025年10月08日(水)、データ整備に関するオフラインイベント『第1回 データ整備を前向きに考える会』に参加してきました。
この回は「ブログ枠」で参加申し込みしていたので参加報告としてブログを書き残しておこうと思います。
合わせて当日のX投稿まとめも作成致しました。レポートと共にご覧頂けますと幸いです。
イベント概要
開催会場は株式会社ブレインパッドさん@六本木。
イベントレポート
Talk1. データ整備の「やり方」はどうなっていくか
-
登壇者：しんゆう氏
-
登壇資料：
- データ整備の仕事はなくならないがやり方は変わる
- 現在を基準として今後2-3年で実現しそうなことを中心にお話。時間の都合上特に気になっている事に絞ってお話します
- データ整備とは
- データが集約されてから分析に使われるまでの間の一連の仕事の総称
- 具体的には「抽出」「整理」「品質管理」「記録」の4つの仕事から構成
- データ整備の定義 - データ整備とデータマネジメント
- データ整備の全体的な動向
- AIやツールの影響で簡単にできることは増えるが、データ整備は調整やコミュニケーションが多いため恩恵は少ない
- 抽出の「やり方」のこれから
- 新しいデータを探す作業は、かなり楽になっていく
- SQLやダッシュボードによる抽出は、自然言語によってどんどん簡単になっていく
- 自然言語で問い合わせれば、AIがパッとデータを探してくれる機会が増える
- この結果、特定のBIツールを使えることの優位性は減っていくと考えられる。ただし、AIはアクセスできる範囲のデータしか探せない
- アクセスできないデータや、そもそも存在しないデータを探しに行くことが、むしろ仕事の中心となる
- ダッシュボード作成も、文字入力だけで実現することが近く可能になるかもしれない
- BI操作の自然言語化が進んでも、細かい調整やレイアウトの調整は残る可能性がある
- 整理の「やり方」のこれから
- SQLを書く技術よりも、「正しいことを決める力」が重要になる
- AIが作成したSQLの結果が正しいか、間違いがないかを確認する重要性が高まる
- データ処理能力の向上により、データマートは減少していくだろう
- データマートの作成が減ると管理する手間が減るが、AIでデータ検索が容易になれば、データマートがたくさんあっても困らない可能性もある
- データの民主化が進むことで、不適切な利用によるデータ混乱への対応が必要になる
- 混乱が起きた後では対応が困難なため、早い段階からのデータ介入が標準になっていく
- 品質管理の「やり方」のこれから
- 品質管理の自動化は進むものの、限界がありそう
- 将来的には、利用状況を自動で調べ、チェックすべきデータに優先順位を付けてサジェスチョンする機能は実現する可能性がある
- データの重要度の判定はAI側では難しく、自動判定は限定的に
- 何をどれくらいの品質で保つかという「品質レベルの決定」は、直近で効率化や自動化のイメージが湧かない
- 記録の「やり方」のこれから
- メタデータは、現状の「あれば嬉しい」状態から、「ないと話にならない」状態へと変化
- 民主化によりデータ利用者が増えると、都度の問い合わせでは間に合わなくなり、「使う前に書かれていないといけない」という流れになる
- AIによる検索が容易になるため、形式にこだわるよりも「とにかく書いとけ」が推奨されるようになる
- AIに問い合わせる際に検索してもらえるよう、テキストに起こすなどの事前の「メタデータの整理」は必要
- 文脈が必要なデータ（例：売上の欠損の理由）の判定は完全には自動化できない
- 需要が増す中で「気づいた人が書く」のではなく、「組織として書く」活動へと移行せざるを得ない
- データ整備担当者は、自ら書くことから、他者に書いてもらう「データマネジメント」へ軸足を移すことになるだろう
Talk2. スタートアップにおけるこれからの「データ整備」
-
登壇者：ウィル氏(コミューン株式会社/データチームマネージャー)
-
登壇資料：
- 自己紹介&企業紹介
- はじめに
- スタートアップでの5年間中、約4年間は泥臭いデータ整備に時間を費やしていたが、最近は分析エージェントの活用により「光が見えてきた感」が出てきた
- 分析エージェントの活用と課題
- 分析エージェント：Community Sage - チャット形式の分析エージェント
- SQLコード表示機能やグラフ作成サブエージェントなどの機能を持つ
- データ整備は分析エージェントに対する制度改善に最も注力されており、これは「Human in the loop」による改善が重要
- 利用状況：1日約10件の問い合わせ、完全な成功率は20%から50%程度
- 改善活動：エージェントが生成するSQLの間違いに対応するモデリングの工夫や、KPIの定義を集計するためのメトリクス辞書の整備、曖昧な要望への聞き返しなど
- データチームへの個別の問い合わせを分析エージェントに流すことで、より多くの人にエージェントを使ってもらう工夫をしている
- 分析エージェント：Community Sage - チャット形式の分析エージェント
- ダッシュボードとAIアプリの棲み分け
- 顧客向けのアウトプット提供において、AIアプリとダッシュボードの開発の棲み分けを意識
- 王道パターン(抽象的で普遍的な分析)はダッシュボードで提供、個別の集計条件が必要な分析(キャンペーンなど)はAIエージェントに任せるという判断。この棲み分けにより、メンテナンスの複雑化やLLMのAPI費用高騰を防ぐ
- BI as Code(BIAC)の取り組み
- ダッシュボード管理と運用をコードベースで行うBI as Code(BIAC)を徐々に進めている
- 使用しているBIツールSortSpotのTML言語を使い、オブジェクトをコードベースで管理制御している
- BIACにより、ヘルプドキュメントの作成や、BIツール上でユーザーが独自に記述した計算式の抽出・チェックなどが可能になっている
- 未来のイメージと目標
- 将来、データ分析エージェントを育成できるシニアな人材が1〜2名いれば、どんなスタートアップでもデータ活用が可能な世界が来ることをイメージしている
- これは、最小の人数でデータ活用を可能にし、データチームの解散を防ぐことにつながる
- 今後の目標は、暗黙知を共有知に徹底して変えるデータ整備に集中し、最小人数でのデータ活用を実現するベストプラクティスをまとめること
- 単純な作業を標準化することで、データ人材ではなく一般的な事務職の雇用を生むくらいの標準化を目指したいという野望がある
Talk3. 綺麗なデータマートは福利を生む - 自分のためにもデータ整備を -
-
登壇者：浅野 純季氏(株式会社ブレインパッド/データサイエンティスト)
-
登壇資料：
- 自己紹介&企業紹介
- はじめに
- テーマは「きれいなデータマートを作ろう、自分のためにもデータ整備を」
- 生成AIやデータマネジメントといったマクロな話ではなく、実務に即したミクロな話に焦点を当てている
- 最近のデータサイエンスプロジェクトは、一過性の分析ではなく、運用に載せることや継続的な価値を出すことが前提
- データ整備は「データが集約されてから分析に使われるまで」の一連の仕事のうち、データサイエンティストがメインで関わる"データマートの周辺(下流)"に焦点を当てている
- データ整備を前向きに進める最大の動機は、きれいなデータマートを作ることの恩恵を自分自身が最も受けるため
- 現代の開発では書き捨てのコードは少なく、POCで使ったコードをそのまま運用に乗せざるを得ないことが多いため、未来の自分が第三者としてコードを読む機会に備える必要がある
- 作業を楽にするため、初めからプロセス（コード）をきれいに作ることで、成果物であるデータマートもきれいになる
- テーマは「きれいなデータマートを作ろう、自分のためにもデータ整備を」
- データマート作成の具体的なTips：SQL/BigQuery
- クエリを小さく分ける：クエリが2000〜3000行になると読むのが困難になるため、細かく分けた方が良い
- ドメイン/役割ごとに分ける：売上ログ、会員マスター、商品IDなど、それぞれのドメインで一旦加工するSQLを書き、その後でひたすらLEFT JOINするSQLを分ける
- 抽出条件を分離：返品やキャンセルなどの抽出条件（WHERE句）は、後の工程に分離して書くことで、条件変更時の対応が容易になる
- SQLでも関数や変数を使う：Pythonのように、SQLでもDRY原則（Don't Repeat Yourself）を適用し、ユーザー定義関数（UDF）を使って同じ処理や長いCASE文をまとめ、見通しを良くする
- コードの冒頭に構造の説明を書く：コードが最初のドキュメントであるとの認識に立ち、ファイル名だけでは不足する情報（日本語での説明、順序関係/暗黙の依存関係）を記載する
- コード上でメタデータを活用：BigQueryなどのスキーマ設定やDescription（説明）機能を利用し、テーブルやカラムの説明をGUI上でも確認できるようにする
- きれいなデータマートのメリット
- 再利用性が向上し、実質的な中間テーブルやデータウェアハウスとして昇格させることが可能に
- メンテナンスが容易になり、継続的に使える基盤となる
- テストが書きやすくなり、品質を保つ仕組みが働くようになる
- データ整備担当者が離れても、うまく回る仕組みを作ることが可能となる
- まとめ
- 本内容はSQLやBigQueryに限定して紹介したが、Pythonなどにも通じる考え方でもある
- データ整備の恩恵を受けるのは、データサイエンティストや分析系の仕事をしている人たち
Talk4. LLM時代にデータエンジニアの役割はどう変わるか？
-
登壇者：宮﨑 一輝氏(stable株式会社 代表取締役 & データエンジニア)
-
登壇資料：
- 自己紹介&企業紹介
- データエンジニアのこれまでの役割
- 体制による様々な「型」
- 依頼型：データチームが各事業部のデータ集計依頼に応える体制
- 派遣型：データチームのメンバーが各事業部の内部に深く入り込み、分析を行う体制
- 教育型：データ分析スキルを事業部側の非データ人材に教える事で依頼を投げずとも自律的に分析が回るようにする体制
- 増員型：人数がボトルネック型であればこれ。ただこれが出来たら苦労はしない
- 依頼型/派遣型どちらを選ぶにしてもデータチームの人数や生産性がボトルネックになり、会社にデータ活用を浸透させるハードルは高い
- 上記紹介した方はいずれも何らかの課題を抱えておりデータ活用を推進するハードルとなっていた
- 体制による様々な「型」
- LLM時代にどう変化するか？
- データエンジニアリング界隈はAI全盛
- AIが得意なところは「そこそこな品質のものをいつでも高速に返す」点
- AIによるデータの民主化で前述課題が解決するのでは
- AIエージェント活用がうまくいくことでデータチームのリソースに余裕ができ事業部側も高速かつコンテキストを含んだ分析結果を得られるかも
- AIエージェントに丸投げして解決...という訳にはいかない。品質的な問題が起きることは自明
- データモデリングの重要性
- データチームはAIエージェントのメンテナンスをしていれば良いのか？
- AIエージェントが参照するデータ基盤を整備する、というところはデータエンジニアの仕事として残る
- AIが使いやすいデータ基盤＝テーブルやカラムの説明などのメタデータが充実している＝ディメンショナルモデリング
- 適切なデータモデリングで表現しておくことで解釈の余地が入りにくく、AIエージェントにとって使いやすいデータとなる
- しっかりとしたデータモデリングがベースにあることで結果が安定するのでは
- まとめ
- これまで：依頼型や派遣型がメインでデータ人材がボトルネックになりがちであった
- これから：AIエージェントに分析を任せることで上記課題が改善するのでは。データエンジニアはデータモデリングを頑張ろう
まとめ
以上、オフラインイベント『第1回 データ整備を前向きに考える会』の参加・視聴レポートでした。様々な角度切り口で『データ整備』に関するお話を伺った形となりましたが、いずれの内容も『効果的・効率的にデータを活用していくためには前段のデータ整備が必要不可欠である』という変わらぬ根底のテーマがあることが改めて浮き彫りとなるものでした。一朝一夕に出来るものでは、改善出来るものでは無いからこそ、地道に少しずつでも積み重ねていかなければならないところではあると思うので私自身も出来るところを見つけていって少しずつ前進・積み上げていこうと思った次第でした。
設定によりコメント欄が無効化されています