データプロダクトとは
データプロダクトとは 「データそのものを価値として提供するプロダクト」 の総称です。
通常のアプリケーションや社内のデータ基盤とは異なり、データそのものがユーザー価値や売上の源泉になる点が最大の特徴です。
データが直接的な価値になるということで、データ職としてはやりがいがある一方で、通常のデータ基盤開発よりも高い品質が求められます。
私が開発しているデータパイプラインも、生成されたデータそのものが価値になり、顧客の業務に直接組み込まれる性質のものでした。
事業の成長に伴って、新しい仕様が次々に追加され、データパイプラインが複雑化した状態で、変更が高頻度化し、インシデントやヒヤリハットが増えてきました。
この状況を打破すべく、社内で 「安定稼働プロジェクト」 を発足しました。
安定稼働プロジェクト
安定稼働プロジェクトのゴールは、
年末までにインシデント・ヒヤリハットの件数を具体的な目標値まで減少させることでした。
しかし、プロジェクトが立ち上がったのは 10 月中旬で年末まで残された時間は、わずか 2 ヵ月半しかありませんでした。ここまでに緊急対応としてできることを実施して、インシデントリスクを大幅に改善しなくてはなりません。
この短期間にデータプロダクトを本質的に安定稼働させるには、データパイプラインの改善だけではなく、End to End で「プロセスそのものの構造」を変える必要があります。
そのために必要なスキルセットは多岐にわたります。
1 人のロールでは到底カバーしきれないため、複数職能が連携するクロスファンクショナルチームを組成しました。
- QA Engineer：テスト体系の再設計
- オペレーションスペシャリスト：運用プロセスの再設計、標準化
- Software Engineer：システム全体の改善、作業やテストの自動化
- BI / Analytics Engineer：データパイプラインの改善、可視化
このチームで、どこが問題があって、どこから対策をすべきかをゼロから見直していきました。
課題把握：生成AIによるインシデントの要因分析により爆弾マップを作成
まず最初に取り組んだのは、過去半年分のインシデントとヒヤリハットの棚卸しです。
社内のポストモーテムドキュメントをインプットとしてサマリーを作成し、
さらに Slack のチャンネルを分析するワークフローを活用して、インシデントやヒヤリハットの概要情報を1つのドキュメントに集約しました。
V 字モデルの活用
集約したインシデント情報を、一般的なウォーターフォール開発で用いられる V 字モデル 上の工程（要件定義から受け入れテストまで）においてどこに問題があったのかをマッピングしました。
- プロジェクトマネジメント：計画・体制・WBS など、全工程を支える横断プロジェクト管理。
- 要求分析：顧客の「本当に解決したい課題」と成功指標を明確化する。
- 要件定義：提供する価値・出力データ・提供方法などの仕様を決める。
- 基本設計：どのプロダクトで何を実施するか、実現手段を具体化する。
- 詳細設計：実装に必要な具体値・ハードコード・集計方式を決め切る。
- コーディング・オペレーション：詳細設計に基づき設定・実装・入稿を正確に反映する。
- 単体テスト：各コンポーネントが単体で正しく動くか確認する。
- 結合テスト：各機能をつなぎ、E2E で正しく動くか検証する。
- システムテスト：全体が仕様通りに動作し、提供要件を満たすか確認する。
- 受け入れテスト：顧客視点で提供物サンプルを検証し、Go / No-Go を判断する。
- 変更管理：追加実装や仕様変更をワークフローで管理する。
- 事後レビュー / 標準化：問題の恒久対策とナレッジを組織に還元する。
V 字モデルでは、設計とテストが 1 対 1 で対応します。
- 基本設計 ↔ 結合テスト
- 詳細設計 ↔ 単体テスト
- 要件定義 ↔ システムテスト
上流で決めたことを、下流で一貫して実装・検証するためのフレームワークです。
今回、弊社は日頃はアジャイルで開発を進めていますが、あえてこの V 字モデルを導入しました。
目的は「全てのテストを網羅的に増やすこと」ではなく、
- どの工程の検証が手薄になっているからインシデントが起きているのか
- 各インシデントの根本原因が V 字モデル上のどこに位置するのか
を整理するための分析フレームワークとして使うためです。
「上流が曖昧なまま進むと、後工程で手戻りが大きくなる」という前提に立ち、早めの仕様確定と丁寧な設計がどの程度できていたのかを、構造的に振り返ることを重視しました。
生成 AI によるインシデント分析
また、このマッピング分析には、生成 AI を活用しました。
- インシデントとその原因を V 字モデル上の各工程にマッピング
- 各フェーズごとにリスクをスコアリング
（プロンプト例：最初にV字モデルの前提をインプットする）
以下の案件がプロセスに問題があるのかを判断したいです。
最も大きな問題だと思われるところに3点、次に大きなプロセスだと思うところに2点、
軽微な影響があるものに1点として、スコアをそれぞれつけてください。
これらを表にしてください。
以下が注意点です
同じスコアを2つのプロセスにつけることはできません。
スコアは半角数字にしてください。
全体として太字は使用しないでください。
この結果を活用して、「爆弾マップ」を作成し、どの工程に負荷とリスクが集中しているのかを一目で把握できるようにしました。
作成した爆弾マップ：V字モデルの各工程に爆弾スコアが表示されています
このマップを見ながら関係者全員で数時間ディスカッションした結果、どこに問題があるのか、どこを重点的に改善すべきかについて、短時間で共通認識を揃えることができました。
そのうえでデータを集計すると、次のような事実が見えてきました。
- 約40% が「追加実装（仕様変更）」と「運用・監視の不足」に起因している
- 主な原因はコーディングの問題ではなく、要件の曖昧さ・認識齟齬・手順の不統一にある
この課題分析を通じて、チーム内および社内での課題認識を揃えることができ、TO-BEとなるプロセスの策定に向けて具体的に議論できる状態になりました。
TO-BE定義：QA エンジニアによるテスト体系の再設計
インシデントリスクの一覧が見えたことで、「各テストプロセスで何を担保すべきか」 を整理し直す必要がありました。
データプロダクトの開発、運用の難しさには、データは ステートフル なのでテストが難しいというのがあります。
通常のWebアプリケーションは基本的にはステートレスで、同じ入力に対して常に同じ出力が期待できます。しかしデータプロダクトは：
- 過去のデータ蓄積状態に依存して結果が変わる
- 外部データソースの状態変化が予測できない
- 時系列での処理順序が結果に影響する
- データの更新タイミングによって同じクエリでも異なる結果になる
つまり「いつ、どの状態で実行するか」によって結果が変わるため、再現可能なテストケースの作成が困難になります。
これらのデータプロダクトの状態依存性という特性に対する銀の弾丸はありません。
仮に100%の精度が担保できなかったとしても、95%のテストを3回行い、インシンデントリスクを0.01%にするようなアプローチを取る必要があります。
これらの特性を踏まえ、QA エンジニアと一緒に、一つ一つの作業を確認し、テストを定義し、テスト体系を次の 4 つに再定義しました。
-
単体テスト
- 個々の処理・テーブルで「仕様通りのデータが出ているか」を確認
- コードレビューも単体テストの一部として位置付け
-
結合テスト
- テーブル間の整合性、漏れ・重複を検証
-
システムテスト
- 「案件設定 × パイプライン全体」が期待仕様どおりに動作しているかを確認
-
平常テスト（ヘルスチェック）
- 変更の有無にかかわらず、稼働中案件を定期的にチェック
これらの頑張って作ったテストリストを
- すぐ運用に組み込む短期のオペレーション
- 徐々に自動化していく開発ロードマップ上のタスク
の 2 つに分類しました。
オペレーションの標準化：オンボの議事録 ≒ 手順書
テストを整える過程で、属人化も散見され、大きなリスクだと分かりました。
原因は「手順書がない」というより、次のような事情です。
- 手順書を作る余裕がない
- 属人メンバーしか説明できない
- 文書化コストが高い
ここでも生成 AI を使い、オンボーディングの会話の議事録そのものを手順書に変えるようにしました。
- 新メンバーへの作業説明を録音
- 音声を文字起こし
- テキストを生成 AI に渡し、手順書・チェックリストを自動生成
- スクショや例外パターンだけ、人が追記
これで「言語化の壁」がかなり下がり、新メンバーでもすぐ同じ手順で作業できる状態に近づけました。
開発ロードマップの策定：生成 AI によるインシデントリスクの再評価
テストとオペレーションの方向性が見えてくると、改善アイデアは増えますが、着手順が問題になります。
そこで、すべての改善タスクをストーリーポイント化したうえで、
生成 AIで既存のインシデントとのマッピングを行いました。上記の開発アイテムが、どの過去のインシデント、ヒアリハットに紐づくのか、そしてその改善幅がわかるようにしました。
このスコアをもとに優先度をつけることで、「どの改善から手を付けるのが妥当か」を客観的に決められるようになり、「安定稼働までの道筋」を具体的なロードマップとして引ける状態になりました。
QA の自動化：仕様 ↔ コード、仕様 ↔ データ
ここまでは主に「課題の分析」に生成 AI を使っていましたが、実際の QA 作業そのもの でも生成 AI を活用し、自動化を進めました。
軸は大きく 2 つです。
- 仕様書とコードが一致しているか
- 仕様書とデータが一致しているか
仕様 ↔ コード：PR 単位での一次チェック
まず効果が大きかったのが、「要件通りに実装されているか」を AI に一次チェックさせる仕組みです。
Pull Request のテンプレートに、
- 要件
- 実装した SQL / 設定
- AI による「差分チェック結果」
を貼り付ける運用にしました。
これにより、
- 要件の読み違い
- 暗黙の前提の取りこぼし
- 細かい条件の抜け漏れ
といった “上流のズレが下流でインシデントになる”構造を、かなり抑えることができました。
仕様 ↔ データ：要件シート × 出力データの自動検証
次に、要件定義と実際の出力データのギャップを自動で検知する仕組みを作りました。
- 要件定義書（要件シート）
- パイプラインの実際の出力データ
この 2 つを突き合わせて、以下の観点をチェックします。
- 期待される出力条件
- フィルタ条件
- 粒度（集計単位）
- 数値の一致
- コードリスト（マスタ）の整合性
これらを BigQuery MCPを活用したエージェントで自動実行することで、
毎週のデータ提供の“安定性”が向上しました。
テスト工程では本来、
- 決まった SQL のひな形を使いつつ
- カラムごとに期待通りの分布やパターンになっているかを手作業で
GROUP BYして確認する
といった、地道で時間のかかる作業が必要になります。
BQMCP ではこのパターンをあらかじめテンプレート化し、
決まったワークフローで検証クエリを自動実行できるようにしました。
その結果、
- 1 週間のうちに、対象案件の「仕様どおりかどうか」のチェックを一通り回せる
- 人手では現実的でなかったカバレッジまでテストできる
という状態に近づけました。
現在はまず 1 案件から適用を始めており、今後 1 ヵ月ほどかけて すべての案件へ展開していくことを検討しています。
システムテストをセンターに据える
さまざまなテストの中でも、
センターに置くべきはシステムテストだと考えています。
-
システムテスト：
「要件が正しい」という前提のもと、パイプライン全体が期待通りに動いているかをフルで確認するもの
-
単体テスト・結合テスト：
その前段階で、できる限り早く問題を潰すための“防波堤”
仕様 ↔ コード、仕様 ↔ データを AI で支えつつ、
最終的なふるまいをシステムテストでしっかり押さえる、という役割分担で設計しました。
まとめ
ここまで見てきたとおり、今回取り組んだのは
- 生成 AI を「分析ツール」として使うこと
- 生成 AI を「QA の一部プロセス」として組み込むこと
- そのうえで、人とプロセスの再設計で土台を整えること
の 3 つをセットで回すことでした。
インシデントは「見えない爆弾」なので、まずは可視化する
インシデントやヒヤリハットは、通常の施策と違って ROI を測りにくく、「何となくテストを増やす」方向に流れがちです。
そこで今回、
- 過去のインシデント・ヒヤリハットを洗い出し
- V 字モデルにマッピングし
- 生成 AI にスコアリングさせる
ことで、どの工程にリスクが集中しているかを可視化しました。
この「爆弾マップ」を起点に対策を検討したことで、
- インシデント抑止効果の高いテストから優先的に導入できた
- ほとんど効果のないテストを増やすことを避けられた
という手応えがありました。
テスト体系とオペレーションを「構造」として設計し直す
- 単体 / 結合 / システム / 平常テストの役割を整理し直す
- 属人化していたオペレーションを「オンボ議事録 → 手順書」のフローで標準化する
といった 「構造の再設計」 を行ったことで、
- どこまでテストされていれば安心と言えるのか
- 誰が入っても同じ品質で運用できるのか
を、以前よりも説明しやすくなりました。
生成 AI はあくまで、その「構造」を支える部品にすぎません。
構造そのものは人間が設計する必要がある、という点は今回強く実感したところです。
生成 AI 時代も「運用」はなくならない
安定稼働プロジェクトに取り組む前は、
「生成 AI があれば単純作業はかなり減るだろう」と、どこかで期待していました。
しかし、品質がシビアなデータプロダクトの開発では、生成 AI を入れても 運用の重要性そのものはほとんど薄れない どころか、むしろ「運用をちゃんと設計しないと危ない」場面が多いと感じました。
- 生成 AI は確率的に動作するため、そのリスクを前提にした設計・管理が必要
- 一度つくった自動化ツールを、その後誰もモニタリングしていなかった……ということも起こり得る
今ある業務が生成AIによって自動化されたとしても、「自動化したシステム」を正しく運用しないと問題は発生し続ける、というよく考えれば当たり前の事実を強く再認識しました。
同じように、データそのものを価値として提供するプロダクトを運用しているチームにとって、今回のプロセスや考え方が、何か一つでもヒントになれば嬉しいです。
Ubieでは、BIチームの採用を強化しています！生成AI活用も全力でやってますので、気になる方はみて見てください！
Discussion