データ基盤構築の進め方を5ステップで解説｜FDEが実務で使う設計順序

データ基盤構築の進め方は？全体は何ステップで考えるべき？

データ基盤構築は、要件定義・アーキテクチャ設計・実装・品質運用・内製移管の5ステップで進めます。順番を入れ替えても作業は進みますが、「誰のどの判断を速くするのか」を決めずに層構成や製品選定から入ると、動く基盤はできても使われないまま維持費だけが残ります。

データ基盤は、それ自体が価値を生む資産ではありません。価値が出るのは、在庫の引当、稼働率の把握、需要予測といった具体的な業務判断が、基盤の上で前より速く正確になったときだけです。FDE（Forward Deployed Engineer）が現場に入るときも、最初に確認するのは技術スタックではなく「いま止まっている判断はどれか」です。

5ステップの全体像はどうなっている？

全体像は、ユースケース定義→層構成設計→パイプライン実装→品質・ガバナンス運用→内製移管の順です。各ステップに成果物と終了条件を置き、次に進む前に業務側の合意を取ります。

期間は業務範囲とデータ源の数で大きく変わるため、あくまで着手判断のための目安です。実務では、ステップ3の実装よりステップ1の合意とステップ4の上流調整に時間を取られる案件のほうが多い、という感触があります。

なぜ「全社一括」ではなくユースケース単位で始めるのか？

対象を1ユースケースに絞ると範囲が有限になり、効果検証と次の投資判断が早く回ります。逆に全社のデータを先に集めようとすると、対象部署が増えるほど合意点が減り、着手が遅れます。

全社統合を先に置く進め方の難しさは、技術ではなく意思決定にあります。どの部署のどのマスタを正とするか、コード値の差異をどちらに寄せるか——こうした論点は、具体的な業務判断という基準がないと決着しません。逆に「この判断にはこの項目が必要」という前提があれば、正とするマスタは自然に決まります。1つ通してから隣のユースケースへ広げるほうが、結果的に全社統合にも近づきます。

最初の要件定義とユースケース選定はどう進める？

要件定義は、解く業務判断を1つに絞り、必要な項目・精度・鮮度を業務側と合意する作業です。ここで「あったら便利なデータ」を足し始めると、対象が膨らんで期限内に成果が出なくなります。

現場で使えるかどうかを分けるのは、多くの場合データ量ではなく鮮度の要件です。日次更新で足りる判断と、当日中の反映が必要な判断では、必要な構成もコストも変わります。要件定義の段階で鮮度を数字にしておかないと、設計が終わってから作り直しになります。

ユースケースはどの基準で選ぶ？

選定基準は、判断が止まっている・データが既に存在する・成果を数えられるの3点です。この3つが揃う業務から着手すると、短期間で効果を提示できます。

• 判断が止まっている：担当者が勘や手集計で判断しており、本人が困っていると自覚している業務を選びます。困っていない業務に基盤を作っても使われません。
• データが既に存在する：まだ記録されていないデータが必要な場合、業務オペレーションの変更から始まるため、1件目には重すぎます。
• 成果を数えられる：作業時間、差し戻し件数、リードタイムなど、既に数えられている指標がある業務を優先します。新たに測定を始める必要がある指標は、効果検証が遅れます。

要件定義では何を文書に残す？

残すのは、判断に使う項目定義、合格ラインとなる精度・鮮度、そして対象外の明記です。特に「今回やらないこと」を書いた文書は、後の追加要望を整理する基準になります。

項目定義では、名称ではなく意味を書くことが要点です。「売上」という列名が、受注時点か請求時点か、税込か税抜か、キャンセル分を含むかで、部署ごとに違う数字が出ます。FDEの実務では、この定義のすり合わせを設計前に済ませ、業務モデル層の項目名として固定します。Palantirが提供するFoundryのオントロジー（Palantir公式ドキュメント）のように、業務の概念と関係を明示的にモデル化する仕組みを持つ製品もありますが、製品を使わない場合も同じ定義作業は必要です。

データ基盤のアーキテクチャはどう設計する？層構成の分け方は？

アーキテクチャは、生データ・整備済み・業務モデル・利用の4層に分けて責任を切るのが基本です。層を分ける目的は技術的な整理ではなく、「どこで壊れたか」を切り分けられる状態を作ることです。

層構成の考え方自体は広く共通化しており、bronze/silver/goldと呼ぶメダリオンアーキテクチャや、ODS・DWH・データマートという分類も、粒度は違えど狙いは同じです。呼び方より、各層に持ち主と変更ルールが割り当てられているかが重要になります。

層構成は何層に分ければよい？

4層構成は、生データを不変で残し、整備・業務モデル・利用の各層で責任者を分けます。3層でも足りますが、業務モデル層を省くと部署ごとに定義が分岐します。

生データ層を上書きしない設計は、地味ですが後から最も効きます。変換ロジックの誤りが見つかったとき、生データが残っていれば作り直せますが、加工後しか残っていなければ再取得の交渉から始まります。

技術選定とスケール前提はどう決める？

技術選定は将来構想より、最初のユースケースが期限内に動くかを基準に決めるほうが安全です。扱うデータ量と鮮度要件を先に置き、それを満たす最小構成から始めます。

判断材料としては、(1) 日次バッチで足りるか準リアルタイムが必要か、(2) 既に契約しているクラウドとBIツールは何か、(3) 社内に運用できる人がいる技術か——この3点で多くの選定は収束します。3点目を軽視すると、構築は終わっても内製移管でつまずきます。運用担当が読めない構成は、結局外部依存として固定されるためです。断定はできませんが、最新の構成を採るより、社内にすでにある技術に寄せた案件のほうが定着している印象があります。

データ品質とガバナンスはどう担保する？

品質とガバナンスは、後付けではなく層ごとに検査と権限を埋め込み、通知先まで決めて担保します。構築が終わってから品質を測り始めると、不良の発生源が業務側にあるため手戻りが大きくなります。

品質の担保で誤解されやすいのは、下流のクレンジングで解決できるという前提です。入力画面の制約不足やマスタ運用の属人化が原因である場合、取り込み後に補正しても翌月に同じ不良が再発します。詳しい改善手順は個別の論点になるため、ここでは基盤構築と並走させる範囲に絞ります。

品質は何を測ってどこで止める？

測るのは完全性・正確性・一貫性・適時性・一意性・妥当性の6観点で、層の境界で止めます。層をまたぐ前に検査を置くと、不良データが利用層まで流れません。

実装上は、次の3種類の検査を最低限そろえます。

1. 件数と鮮度の監視：取り込み件数が前日比で大きく外れたとき、最終更新時刻がしきい値を超えたときに通知します。障害の検知として最も費用対効果が高い部分です。
2. 形式の検査：型・桁・コード値・範囲の違反を整備済み層への投入前に止めます。ここを通すと下流の集計が静かに狂います。
3. 業務ルールの検査：受注日が納品日より後、稼働率が100%超など、業務上ありえない組み合わせを業務モデル層で検知します。

そして検知を作ったら、意図的にデータを壊して通知が担当者の手元に届くかを確認します。通知先が未設定のまま放置された監視は、実務上は存在しないのと同じです。

ガバナンスは誰がどこまで持つ？

データの所有は業務部門、検知と基盤維持はIT部門という分担が現実的に機能しやすいです。IT部門だけに寄せると入力ルールを変えられず、形式チェックだけが増えます。

権限設計では、部署単位ではなく業務判断単位で見せる範囲を決めます。個人情報や取引条件を含む項目は、業務モデル層でマスキング済みの列を別に用意し、利用層では原則そちらを参照させる構成が扱いやすいです。AIの活用まで見込む場合は、NISTのAI Risk Management Framework（NIST公式）のようなリスク管理の枠組みを参照し、どのデータをモデルに渡すかの判断基準を先に文書化しておくと、後の審査が軽くなります。

FDEはデータ基盤構築でどう動き、内製化へどう引き継ぐ？

FDEは現場に入って要件からパイプライン実装まで一貫して担い、運用ごと社内へ移します。要件を受け取って作る分業ではなく、業務を見ながら設計を直す往復が前提になる点が違いです。

FDE（Forward Deployed Engineer）はPalantirが確立した職種で、顧客の現場でワークフロー設計から実装・テストまでを自ら手がけます（Palantir公式ブログ）。データ基盤構築は、この働き方が最も噛み合う領域のひとつです。不良データの発生源は現場の入力運用にあり、それを直すには業務側との交渉と実装の両方が必要になるためです。

FDEは何を担う？

FDEが担うのは、業務ヒアリングから層設計・実装・検知の設置までの縦一本の往復です。分業体制との差は、発見した課題をその場で設計に反映できる速さに出ます。

一人で全部を担うという意味ではなく、小さなチームが縦に一貫して責任を持つ体制と理解するほうが実態に近いです。VACAN Technologiesでも、現場に入って課題の発見から実装・定着までを同じ担当が持つ形を基本としています。

内製化への引き継ぎはどう設計する？

引き継ぎは代行・協働・自走の3段階で、社内が単独で変更できた時点を完了とします。手順書の提出は完了条件になりません。

1. 代行：FDE側が実装と運用を担い、判断の理由を記録として残します。何を選ばなかったかも書き残すのが要点です。
2. 協働：社内担当が主担当となり、FDEがレビューに回ります。この段階でしきい値の変更や項目追加を実際にやってもらいます。
3. 自走：社内担当が単独で変更・検証・リリースまで完了できる状態にします。外部は仕様変更の相談など要所のみ関与します。

移管を最初の契約に含めず後から検討すると、移管作業そのものが追加の交渉事項になります。構築の見積り段階で移管ステップを明示し、「社内担当が単独で1件の変更を完了する」という具体的な終了条件まで含めておくほうが、双方にとって扱いやすいです。データ基盤の価値は構築時点ではなく、社内で変更を続けられるかどうかで決まります。

姉妹メディアの関連記事