🔧
DataOps Night #6 イベントレポート
公開
2025-02-06
更新
2025-02-26
文章量
約3418字
株式会社ヤードの代表で、Yardの開発者です。 データプロダクトの受託開発や技術顧問・アドバイザーもお受けしております。 #データ利活用 #DevOps #個人開発
はじめに
2025年2月4日、株式会社ナウキャスト主催の勉強会「DataOps Night #6」が開催されました。
本イベントは、「運用も含めてデータを用いて価値を出すために奮闘するエンジニアが集まり、知見を共有する」ことを目的とした会で、今回は3社（株式会社ナウキャスト、株式会社estie、株式会社アイスタイル）が登壇し、それぞれの現場におけるデータプロダクトやデータ基盤開発・運用の実践例が紹介されました。
昨今、データ活用が企業競争力の鍵となる一方で、「garbage in, garbage out」 という言葉が示すように、データの品質が低いままでは正しい分析や価値創出は困難になります。
本勉強会では、そうしたデータ品質を支える仕組みや組織、そして各社が実践するDataOpsの取り組みが紹介され、盛りだくさんの内容となりました。
1. マルチデータプロダクト開発・運用に耐えるためのデータ組織・アーキテクチャの遷移（ナウキャスト）
最初に登壇したのは、オルタナティブデータを活用したデータプラットフォームを提供する株式会社ナウキャストのmuguruma さん（@mt_musyu）。
同社では「データそのものをプロダクト」として扱うビジネス上、膨大なデータソースを収集し、様々な顧客企業にデータを提供しています。
スピード感ある開発と高品質な運用を両立するため、組織体制やデータ基盤のアーキテクチャをどのように変遷させてきたかが紹介されました。
- データ組織の変遷
- 創業当初は、データソースごとに個別チームを組成し、各チームが独立してクレンジングや分析を担当。
- その後、さまざまなデータを組み合わせるニーズが高まり、共通基盤（プラットフォームチーム）を置いてチームAPIやdbtの導入を進める「データメッシュ的アーキテクチャ」に移行。
- セルフサービスプラットフォームの充実
- プラットフォームチームがテンプレートやテスト・監視の仕組みを提供することで、各プロダクトチームが自律的に開発を進めやすくする。
- コスト管理ツールの導入（例：SELECTなど）により、SQLクエリを発行するチームごとの実行コストを可視化。
- 今後の展望
- データコントラクトの導入を検討し、データのスキーマや定義をより明示的に共有することで、データ連携の変更をよりスムーズに行う。
- データのマスタ化（例：法人番号をキーとした法人データベースの整備など）を進め、複数データソースを横断的に活用しやすい仕組みを作る。
「泥臭い取り組みを楽しみながら、全体最適をどう実現するか」が重要と強調されていました。
2. 自動と手動の両輪で開発するデータクレンジング（estie）
2番目に登壇したのは、商業用不動産のデジタルインフラを展開する株式会社estie のRyosuke Linさん（@Ryosuke839）。
オフィスや住宅など、さまざまなデータパートナーから集める物件情報のクレンジング手法が紹介されました。
- 多様なデータソースと大規模データ
- 商業用不動産データは、ポータルサイトや仲介会社など、パートナーごとに仕様や更新頻度、カバレッジエリアが異なる。
- オフィス規模なら数万・数十万件、住宅になると何百万件と膨大。手動では全て対応できない。
- 自動 + 手動のハイブリッド
- 自動名寄せ: Python製の名寄せサービスを内製し、住所・建物名・回数などの特徴量を元に、同一物件を自動的に識別・統合する。
- 手動名寄せ: 重要データや曖昧に判定されたデータは、社内用に作成したストリームリットダッシュボードを使って、人間の目で修正。
- フルリフレッシュとインクリメンタルを組み合わせたスノーフレイク + dbt パイプラインで運用し、「既存の手入力データは壊さず」に再計算できるようテーブル構造を分離する。
estieでは、「大量データを自動でカバーしながら、残りを人手で正しく修正する」仕組み作りが重要とのこと。
特に商業用不動産のように曖昧さや入力ミスが多い領域では、人間が入るプロセスをどう整備するかがカギになるそうです。
3. データ基盤の成長を加速させる：アイスタイルにおける挑戦と教訓（アイスタイル）
3番目に登壇したのは、コスメの口コミサイト「@cosme」を運営する株式会社アイスタイルのtsudash0さん（@tendon0）。
アイスタイルでは、全社的なデータ基盤をGoogle Cloud上で刷新中。
構築〜運用の中で起きた課題と、その振り返りが共有されました。
- 既存データ基盤の課題
- オンプレミス環境でスケールが難しい
- データの検索性やモデルの再利用性が低い
- 品質担保の仕組み不足による誤配信のリスク
- 新データ基盤のアーキテクチャ
- OSSのツールを積極活用し、Kubernetes上にAirbyte（ETL）やPrefect（オーケストレーション）を導入。
- 当初は各OSSの安定度や運用ノウハウの不足からトラブル多発。とりわけPrefectがしばしばクラッシュするなど課題があった。
- 現在はサーバーとワーカーを分離して分散実行を安定化。必要に応じてマネージドサービスや別ツール（ハイタッチなど）を併用する。
- プロジェクト推進上の教訓
- 「技術中心になりすぎないこと」が大切。ユーザー（事業側）との連携を意識した要件調整・優先順位づけが重要。
- 「既存システムの複雑性を過小評価しない」こと。オンプレからクラウドへの大量データ移行や、データ利用部門とのすり合わせが想定以上に大変だった。
- 機能を“盛りすぎる”と開発に時間がかかり、ユーザーへの提供が遅れるリスクがある。まずは最優先でリプレースすべき箇所に注力する姿勢が必要。
組織再編で「データ基盤側 + 事業側」が連携するプロジェクト体制が整いつつあり、今後は「データ活用を主体的に行う分散的モデル」を目指しているそうです。
QA & トークセッション
質疑応答では、データ基盤のコスト管理やプラットフォームチームの在り方、データガバナンスの推進方法など、各社共通の悩みや工夫が議論されました。
- コスト管理
- Snowflake利用コストを抑えるため、クエリ単位の実行状況を可視化してチームへ共有し、チューニングや無駄の削減を促す事例が紹介。
- OSS製品を組み合わせる場合も、結局は運用コストと開発コストとのトレードオフが生じる。
- プラットフォームチーム vs 分散化
- 各社とも開発スピードとガバナンスの両立が大きなテーマ。プラットフォームチームが最初に最低限の仕組みを整え、徐々に拡充していく進め方が有効との声があった。
- 組織再編などにより、ビジネスサイドが巻き込まれないと、新基盤の要件調整や運用方針が形骸化するリスクもある。
まとめ
「DataOps Night #6」では、ビジネスの本丸としてデータを扱う3社が、いかにデータ品質と運用体制を整えているかを具体的に共有してくれました。それぞれ異なる背景・アーキテクチャを持ちつつも、
- 共通基盤（プラットフォーム）と分散型組織の両立
- 自動化 vs 人手による補正（ハイブリッド運用）
- コスト管理、ガバナンス、実利用部門との連携
といった共通テーマが見られ、リアルな実践知が詰まった会となりました。
データプロダクトが増え、データソースも広がっていく中で「どれだけ高い品質を効率よく保てるか」は企業にとってますます重要になります。今回紹介された取り組みや教訓は、多くのデータエンジニアやデータ活用部署にとって大いに参考になるはずです。
DataOps Nightは今後も定期的に開催されるとのことなので、引き続き情報共有の場として注目していきたいと思います。
