データエンジニアに「このデータを使えるようにしてほしい」「BI用のデータパイプラインを作ってほしい」と依頼したのに、何度もヒアリングが発生して作業が進まない——こうした状況はビジネス担当者とデータエンジニアの間で情報が揃っていないことが原因であることが多いです。本記事では、依頼する側が事前に整えておくべき情報と、手戻りを減らすための進め方を解説します。なお依頼先は、社内の情報システム部門でも、専任のデータエンジニアでも、外部のベンダーでも、必要な準備は変わりません。本記事では総称して「データエンジニア」と書きます。
データエンジニアが最初に必要とする5つの情報
データエンジニアに作業を依頼する際、次の5つの情報が最初から揃っていると、認識のずれを減らし、要件確認や手戻りを抑えやすくなります。
- ①何を達成したいか（ゴールの定義）：「売上をダッシュボードで見たい」ではなく「どのような集計粒度（日次・拠点別・SKU別等）で・誰が・何の意思決定に使うか」まで定義します。あわせて、どのくらいの頻度で更新されていればよいか、どの程度の遅れまで許容できるか、といった受け入れの条件も決めておくと、完成の判断がぶれません
- ②使いたいデータのソース一覧：どのシステム・DBから何のデータを使うか。システム名・テーブル名・データの鮮度（リアルタイム・日次バッチ等）を整理します。テーブル名まで分からなければ、分かる範囲で書いて残りは一緒に確認すれば構いません。あわせて、データの閲覧・取得に必要な権限と、個人情報や機密情報の取り扱いの制約も分かる範囲で整理してください。技術的にデータが存在することと、実際に使える状態にあることは別です
- ③データの業務ロジック：「売上とは何か（返品控除後か・消費税込みか）」「有効顧客の定義は何か」など、集計に必要なビジネスロジックを文書化します。これがないとエンジニアが独自に解釈して間違ったデータが生成されます
- ④データ品質の既知の問題：ソースデータにどんな品質問題があるか（NULL多い・重複がある・値が信頼できない時期がある等）を事前に伝えます
- ⑤優先度とスケジュール：全部を一度に作るのは難しいため、最重要な機能から順に優先順位をつけ、期限があれば伝えます
ビジネスロジックを文書化する：データ定義書の作り方
「売上」「顧客数」「在庫」といった指標の定義が曖昧なまま進めると、BI上の数字が部門によって違う・エンジニアの実装とビジネスの理解が食い違うという問題が生じます。シンプルなデータ定義書（用語集）を事前に作ることが、最も効果的な手戻り防止策です。
- 定義書に含める項目：指標名・定義の説明・計算式（あれば）・含むもの・含まないもの・どのシステムのどのフィールドから算出するか
- ExcelまたはNotionで作る：ツールは何でも構いません。データエンジニアとビジネス担当者が参照できる場所に置き、意見相違があったときに定義書を見て解決できる状態にします
- 定義の合意を取る：作成した定義書を関係部門と事前に確認し、合意を取ります。ただし全員がすべての定義を承認する必要はありません。指標の重要度と影響範囲に応じて、誰が承認するかを決めておくほうが現実的です。エンジニアと一緒に確認すると、実装上の疑問点も同時に解決できます
データ品質の問題を事前に伝える重要性
ソースデータの品質問題を事前にデータエンジニアに伝えることは、パイプライン設計の品質と安定性に直結します。「このカラムはNULLが多い」「この期間のデータは信頼性が低い」「この項目は2020年以降に記録形式が変わった」といった情報がないと、エンジニアはデータの問題を後から発見してパイプラインを作り直すことになります。
- 既知の品質問題リストを作る：「フィールド名・問題の種類・影響期間・対処の有無」を一覧化した簡単なリストで十分です。あわせて「この項目は欠損が何%までなら許容する」といった基準も決めておくと、除外するのか補正するのか警告を出すのか、処理の設計につながります
- エラー処理の設計に活用：品質問題が事前にわかっていれば、エンジニアがパイプラインにエラー処理・除外ロジック・アラートを設計できます
協業中の情報共有：手戻りを減らすコミュニケーション設計
データエンジニアとの協業では、依頼後の進め方も手戻りの量を左右します。特に重要なのは「中間成果物のレビューのタイミングを決める」ことです。パイプラインの完成形を待ってからレビューすると、方向性のズレが大きくなります。「データ定義書の合意→サンプルデータの確認→テスト環境でのダッシュボード確認→本番リリース」という段階ごとのレビューを設計すると、ずれを早く見つけられます。なおサンプルデータの確認では、見た目をなぞるだけでは足りません。件数や集計値が元データと一致するか、返品・取消・重複が定義どおりに扱われているか、欠損値や異常値が想定どおりに処理されているか、対象期間が要件を満たしているか——この4点を見てください。
▼
※ 各段階で確認しておくと、ずれを早く見つけられ、やり直しの範囲を抑えやすくなります
依頼後に仕様が変わることは避けられませんが、「変更の発生した理由・変更箇所・優先度への影響」を明示的に伝えることで、エンジニアが工数を見直しやすくなります。「ちょっと追加で」という形の非公式な依頼の積み重ねは、エンジニアの工数を圧迫し関係性を悪化させます。変更依頼は都度、明示的なコミュニケーションで行う習慣が、長期的な協業関係を維持します。
ビジネス担当者がデータエンジニアリングの基礎を知るメリット
依頼する側がデータエンジニアリングの基礎（ETL・データウェアハウス・バッチ処理・APIといった概念）を最低限知っていると、依頼の伝え方が変わります。たとえば「このデータはリアルタイムで見たい」という要望が技術的にどの程度の負担になるか見当がつけば、「リアルタイムでなく日次更新でよいか」という代替案を自分から出せます。
技術の詳細まで学ぶ必要はありません。「データがどこからどう流れて画面に出ているか」のイメージを持つだけでも、依頼の仕方とトレードオフの話し合い方は変わります。依頼先に「データの流れの説明会」を一度開いてもらう、といった形でも足ります。互いの前提を知らないまま進めることが、認識のずれを生みます。
よくある質問
指標の定義を決めようとすると部門間で意見が割れて、先に進みません。
一つの正解に統一しようとすると止まります。割れる原因は、部門ごとに見たいものが違うためで、どちらかが間違っているわけではないことが多いためです。部門ごとに目的や会計上の基準が違う場合は、無理に一本化せず「営業向けの売上」「経理向けの売上」のように名前を分けて併存させます。ただし名前を分けるだけでは足りません。指標名・計算式・対象期間・利用目的、そして誰がその指標の責任者かまで書き分けてください。たとえば営業向けは受注額、経理向けは会計上の計上額を見ているなら、集計の基準そのものが違います。一方で全社共通で使う指標については、共通の定義を設けることを検討してください。
自社データの品質問題を事前に伝えろと言われても、何が問題かを把握できていません。
網羅する必要はありません。まず依頼対象のデータについて、欠けている項目はないか、同じ対象が重複していないか、過去に入力ルールが変わった時期はないか、の3点を確認してください。現場に「このデータで困ったことはあるか」と聞くと、だいたい把握している人がいます。把握しきれない場合は「未確認」と伝えるだけでも意味があります。問題がないと誤解されるより、分かっていないと分かっているほうが設計に反映できます。ただし未確認のまま放置はしないでください。必要に応じて、値の分布をざっと集計する、一部を抜き出して目視するといった形で、後から確認する段取りまで決めておきます。
外部ベンダーに委託する場合も、同じ準備が必要ですか？
必要です。むしろ外部委託のほうが重要になります。社内であれば業務の前提を補って解釈してもらえますが、外部にはその前提がありません。加えて外部委託では、前提条件・責任範囲・成果物・受け入れ条件を明示しておくことが特に重要です。この5点を整理しておくとその土台になり、見積もりの比較もしやすくなります。要件が曖昧なまま出した見積もりは、どの会社のものも比較できない内容になりがちです。
まとめ
依頼する前に整えておくのは「ゴールの定義・ソース一覧・ビジネスロジック・既知の品質問題・優先度」の5点です。なかでもビジネスロジックを書き出したデータ定義書は、手戻りを減らす効果が大きい割に、作る負担が小さい作業です。依頼内容そのものだけでなく、確認のタイミングもあわせて決めてください。定義書の合意、サンプルデータの確認、テスト環境での確認、という段階を踏んでおけば、ズレが見つかっても戻る先が一つ前で済みます。この5点の整理は、外部のベンダーに委託する場合にも、委託範囲と責任を明確にするうえで役立ちます。データ整備・BI構築の要件整理や依頼の進め方についてはBFT Insightにご相談ください。