こんにちは、IVRyでデータエンジニアとして働いている松田健司（@ken_3ba）です。趣味はビリヤードで、プロの試合にも出るぐらい割とガチでやっています。
ビリヤードが盛んな国はどこかご存知でしょうか。アメリカやヨーロッパが盛んなイメージかと思いますが、実はフィリピンや台湾といったアジアでも人気で、世界ランキング上位に複数います。日本にも世界で戦うスタープレイヤーの大井直幸プロがいて、応援しています！
画像出典: SE11トーナメント | ビリヤードキューズ
ビリヤードの話はこのへんにして、本題に入ります。
TL;DR
- ゼロからデータ基盤を作って踏んだ3つの失敗談（スナップショット設計／パイプライン連結／リアルタイム要件）を共有します
- ヒアリングは伝聞ではなく、データエンジニア自身がクライアントに出向くことで基盤の品質は大きく変わる
- 共通する根本原因は「要件定義の徹底不足」で、技術選定よりも先にデータ品質・鮮度・履歴要件をお客さんと合意することが最重要
はじめに
機械学習・プロダクト開発・マネジメントを経て、ぐるっと回ってデータエンジニアに行き着いたキャリアです。計画していたわけではなく、データを使っているのが楽しくて気づいたら流れ着いた、という感じです。
大学院では機械学習のモデル開発、新卒ではバックエンドエンジニア、その後ベンチャーでソフトウェアエンジニアやスクラムマスター、エンジニアリングマネージャーとしてデータプロダクトやデータ基盤チームの立ち上げ、と渡り歩いてきて、今はIVRyでデータエンジニアとして社内のデータ基盤やお客さんとのデータ連携をやっています。
エンジニア歴は12年ぐらいですが、そのうちデータエンジニアとしての経験は5年ぐらい。はじめてデータ基盤をゼロから構築・運用してみて、設計時には気づけなかった落とし穴をたくさん踏んできました。きれいな設計論はネットに溢れていますが、実際に痛い目に遭った失敗のほうが学びが大きいと感じています。本記事ではそれを共有します。
前提：使う側から、作る側に回った
新卒時代はバックエンドエンジニアとして、検索ログを大規模処理するHadoopパイプラインを書いていました。当時はできているデータ基盤を「使う側」で、データ基盤とはこういうものだと当たり前のように思っていました。
その後ベンチャーに移り、データ基盤をゼロから自分で「作る側」に回りました。すると、それまで当たり前だと思っていたものが、いざ作る側になると想像以上にハマりどころが多くて、何度も痛い目を見ました。
本記事で紹介する失敗談は、この「ゼロから基盤を作っていた頃」の経験を中心に共有します。
失敗1: スナップショット設計で履歴が遡れず、データが欠損した
「その時点の最新データを取得して、集計してBIで統計量を出したい」という要件がありました。そこでDBのスナップショットを取り、ETLで加工してデータを作る設計で開発しました。
普段は問題なく動いていたのですが、ある日システムのアップデートがうまくいかず、休日の深夜にバッチが失敗。検知が遅れて翌朝に再実行したところ、ソース側のテーブルが値を頻繁に上書きする仕様だったため、すでに値が変わっており、前日時点のデータが二度と取れなくなりました。結果、前日分が欠損したままお客さんに返すことになり、迷惑をかけてしまいました。
しかも後から、お客さんにとっては「ログが1件でもズレるのは大きな問題」だということが判明し、期待値に合った品質で提供できていませんでした。
教訓
データ品質の要件を最初に聞く
そもそもお客さんにデータ品質の要件を適切に聞けていなかったのが本質的な問題でした。アクセスログのデータは稀に欠損が発生してしまうもので、1件単位の正確性が求められるなら、当時のOLAPの処理ではそもそも不可能だったように思います。OLTP寄りの設計にするべきでした。
それ以降、ヒアリングでは「どれくらいのデータ品質が必要か」をあらかじめ確認するようにしています。欠損だけでなく、鮮度の話や、過去の履歴データを参照するユースケースがあるかどうかも一緒に聞くようにしています。
スナップショットだけで設計せず、再集計できる状態にしておく
設計面でも、データソースの保持の仕方によってはスナップショットだけで取ると障害発生時に後から再集計できない、ということを理解できていませんでした。あとで復旧できるよう、CDCや履歴データをdata lake層に入れて再集計できる状態にしておくべきだった、というのが学びです。それ以来、スナップショットで集計する設計を選ぶときは**「履歴が後から必要にならないか」**を常に気にするようになりました。
失敗2: 社内向けの分析データを、そのままお客様向けに流用してしまった
もともと社内の分析用途でデータ基盤を運用していて、社内向けにデータ提供をしていました。ある時、別のプロジェクトで「このデータを使ってお客さんにも提供したい」というニーズが出てきました。社内向けのパイプラインは大体20分ぐらいで終わっていたので、その完了を見越して、後続にお客さん向けのパイプラインを組みました。
- パイプラインA（社内向け）: 毎時5分に起動
- パイプラインB（お客さん向け）: 毎時50分に起動（Aが終わっている前提）
しかし、Aが遅延・失敗した瞬間に、Bが不完全なデータを処理し始めます。成功したように見えて、実は壊れたデータ。それが下流に流れ続け、検知も困難なまま、お客さんに届いてしまうパターンに陥りました。
加えて、Aはそこまで品質を担保していなかったので、もともと遅延やデータ欠損もそれなりにありました。そこにいきなりサービスレベルが乗ったような形になり、運用負荷も一気に上がりました。
教訓
タイムスケジュールでパイプラインを連結しない
勘の良い方は「ワークフロー管理ツールを使えばいいのでは？」と思われたかもしれません。まさにそのとおりで、タイムスケジュールによる処理連結は絶対にやってはいけません。代わりに、以下のいずれかの方式をワークフロー管理ツールで組みます。
- トリガー式: 前段の完了を検知して後続を起動
- ファイル検知式: 所定の場所にファイルが置かれたら起動
最初の起動だけはスケジュールでよいですが、その先は必ず前工程の完了をトリガーにします。複数のデータソースを参照する場合はファイル検知式を使います。こうした方式にしておくと、データリネージュで依存関係が可視化できるというメリットもあります。
スケジュールが数珠つなぎになっているパイプラインは絶対に実装しないようにしていて、見つけたら即リファクタリング対象です。
社内向けと顧客向けは、別プロダクトとして分けて設計する
タイムスケジュール連結はあくまで失敗の引き金で、より本質的な問題は別にありました。お客さんに納期を約束していたので突貫工事で対応してしまい、社内分析用の日次バッチの上に「リアルタイムでデータが欲しい」という要望をラップアップで継ぎ足したのが、そもそもの原因だったと思っています。
社内のデータ基盤とお客さんへのデータ提供のパイプラインは、要件もサービスレベルも大きく違います。コストは2倍になりますが、データやパイプラインは分けた方が良い、というのが学びでした。
これは後から知ったのですが、Martin FowlerのData Meshの原則でも同じような考え方が言及されていました。
画像出典: Martin Fowler, "Data Mesh Principles and Logical Architecture"
Analytical data provided by the domains must be treated as a product, and the consumers of that data should be treated as customers.
出典: Martin Fowler, "Data Mesh Principles and Logical Architecture"
この視点に立てば、社内向けと顧客向けはそもそも別のプロダクトであって、無理に同じパイプラインに乗せてはいけなかった、ということに気づきました。それ以降は、社内向けのデータパイプラインと、社外にプロダクトとして提供するデータパイプラインについて、どこまでを共通化してどこから分離するかを慎重に考えるよう心がけています。
失敗3: リアルタイム要件を鵜呑みにした
あるお客さんから「データをすぐ見て反応したいから、リアルタイムでデータが欲しい」という要望をいただきました。当時の自分はそれを深く考えずに鵜呑みにしてしまい、なんとか応えようとリアルタイムの実装を頑張って作り込みました。
実装はやり切ったのですが、運用に入ってみるとコストも運用負荷もとても高い。お客さんもはじめのうちは喜んで使ってくれていたものの、しばらくすると「とくにリアルタイム性は必要ない」とお客さん自身が気づき始め、最終的には1日1回しか見ない運用に落ち着いてしまいました。結局、自分が作ったのは完全なオーバーエンジニアリングで、コストと運用負荷だけが嵩むROIの悪いシステムだった、ということです。
しかも、失敗1でも触れたとおり、リアルタイム化するとデータ品質はどうしても落ちます。お客さんが本当に重視していたのはデータの正確性だったのに、自分が提供したのは「欠損リスクのあるリアルタイム性」で、価値の方向性がそもそもズレていたわけです。
教訓
「リアルタイムで欲しい」は深掘りしてユースケースを聞き、データ品質レベルを合意する
「リアルタイムで欲しい」は、もっとも警戒すべきフレーズのひとつだと思っています。鮮度について聞くと、ほぼ毎回「なるはやで」という言葉が出てくるのですが、それを鵜呑みにせず、「どういう理由でリアルタイム処理が必要なのか」というユースケースを必ず詳細にヒアリングするようにしています。
そして、ヒアリングと合わせて、リアルタイム化すると欠損のリスクが上がることや、インフラ・実装・運用のコストが上がることも必ず説明します。そのうえで、許容できるデータ品質レベルをお客さんと明確に合意するようにしています。
このやりとりをすると、結果的にOLTPで実装したり別の手段に切り替えたりすることがよくあります。経験上、本当にリアルタイム性が必要だったケースはほとんどない、というのが実感です。
まとめ
まだまだたくさん失敗していますが、今でも鮮明に覚えている3つの失敗についてお話ししました。共通しているのは、要件定義を徹底できていなかったこと。これが根本的な問題だったと感じています。
お客さんのニーズや業務プロセスの解像度を高めて理解し、それをきちんと要件に落とし込んでいくこと。これが原点であり、すべてにおいて最重要事項だと思っています。そしてそれを、プロダクトマネージャーや営業さんから伝聞で聞くのではなく、データエンジニア自身が直接クライアント先に出向いて伺うようにしています。このひと手間で基盤の品質はまるで変わります。IVRyでは商談に同席する機会が当たり前で、契約前からお客さんと直接お話しできる素晴らしい環境です。この観点については、IVRyの森谷さんも記事にまとめてくださっているので、よければ合わせて読んでみてください。
これからのデータエンジニアに求められるもの
これからのデータエンジニアには、従来のパイプライン設計に加えて新しい観点も求められはじめています。下記の記事では、Agentic AI時代のデータエンジニアリングとして、コンテキストエンジニアリングや、顧客と現場で要件と仮説を一緒に詰める動き方の重要性が語られています。
IVRyのデータチームは、この2つをそのまま実践できる環境だと思っています。お客さんの商談同席は当たり前ですし、LLMやエージェントに渡すコンテキストの設計もこれからどんどん深めていけるフェーズです。技術的にも、dbtやApache Iceberg、ストリーミング、エージェント連携まわりなど新しいトレンドが次々に出てきていて、キャッチアップが追いつかないくらい楽しい領域でもあります。
「ベンチャーで基盤をゼロから作るなんて……」と感じる方もいるかもしれません。でも本記事のとおり、自分で作って運用してみると、本や聞いた話だけでは絶対に得られない学びが本当にたくさんあります。痛い目を見るたびにエンジニアとしての筋肉がついていく感覚があり、私自身、毎日とても楽しんでいます。
そんな環境で一緒に働きたい方は、Data Product Orchestrator（Agentic Transformation Lead） や データエンジニア（リードクラス）を募集しています。お客さんから直接話を聞いて、自分の手で実装し、その反応が生のフィードバックとして返ってくる。このサイクルがとにかく楽しくて、まさにエンジニア冥利に尽きる日々を過ごしています！
IVRyではキャリア登録やカジュアル面談の機会をご用意しています。ご興味のある方はぜひ以下よりお申し込みください。
Discussion