データ品質の改善はどう進めるか｜FDEが現場で回す5段階の手順

データ品質の改善はなぜ進まないのか？

データ品質の改善が進まない最大の理由は、品質の悪さが誰の担当でもない共有コストとして放置されるからです。システム障害と違ってアラートが鳴らず、現場が手作業で吸収してしまうため、問題が可視化されないまま年単位で温存されます。Gartnerは、データ品質の低さが組織にもたらす損失を年間平均1,290万ドルと推計していますが、この損失は請求書の形では届きません。届くのは「集計が合わない」「二重に連絡してしまった」という個別の不具合だけです。

FDE（Forward Deployed Engineer）として現場に入ると、この構図は業種を問わず似た形で現れます。ダッシュボードを作る前に、まず元データの欠損と表記ゆれの実態を見に行く——ここを飛ばした施策は、ほぼ例外なく「数字が信用できない」で止まります。

データ品質が悪いと、最初に誰が困るのか？

データ品質の劣化で最初に困るのは現場で、確認と手戻りという見えない残業として現れます。経営層に届くのは「AIの精度が出ない」という結論だけですが、その手前では担当者が毎朝Excelで名寄せをし、営業が顧客に電話して住所を聞き直しています。

この吸収作業は熟練者ほど速く、速いほど問題として報告されません。結果として、属人的な補正が業務フローに埋め込まれ、担当者が異動した瞬間に品質問題が一気に表面化します。改善の起点は、技術的な計測よりも「いま誰が、何分かけて、どのデータを直しているか」を数えることに置くのが現実的だと感じています。

なぜ「あとで直す」が積み上がるのか？

「あとで直す」が積み上がるのは、品質改善だけが締切も担当者も持たない仕事になりがちだからです。新機能には要件とリリース日がありますが、既存データの是正には期日がありません。

さらに、修正の効果が出るのは修正した部署ではなく下流の利用部署です。入力の手間が増える部署と、恩恵を受ける部署が一致しない——この非対称性が、現場の善意だけでは越えられない壁をつくります。だからこそ改善は「頑張って入力する」というお願いではなく、入力の選択肢を減らす、必須項目を絞る、後段で自動補正するといった仕組み側の変更として設計する必要があります。

データ品質は何を測れば改善できるのか？

測るべきは正確性・完全性・一貫性・適時性・一意性・妥当性の6観点と、業務が壊れる境界値です。品質は絶対値ではなく用途に対する相対値なので、「何%なら業務が回るか」を決めない計測は、数字を眺めるだけで終わります。

データ品質を測る6つの観点とは？

6観点はDAMA（Data Management Association）が整理した標準的な分類で、どの業界のデータにも共通して使えます。それぞれ測り方が異なるため、まず自社データを一度この枠に当てはめて棚卸しすると、抜けている観点が見えます。

実務では、正確性の計測が最もコストがかかります。現実と突き合わせる必要があるため、全件ではなくサンプル抽出で誤り率を推定し、他の5観点は全件を機械的に測る——この役割分担が現実的です。

どの指標から着手すべきか？

最初に着手すべきは、業務判断が直接変わる列に絞った完全性と適時性の2指標です。全項目の品質を一律に上げようとすると工数が発散し、どこから効いたのかも分からなくなります。

絞り込みの基準はシンプルで、「この列が空だと業務が止まるか」を担当者に聞くことです。止まる列、迷う列、参考程度の列の3段階に仕分けると、対象は多くの場合10〜20列程度まで落ちます。そのうえで、列ごとに「NULL率5%以下」「更新遅延24時間以内」といった合格ラインを業務側と合意します。目標値の根拠は他社水準ではなく、自社の業務が破綻しない境界に置くのが要点です。

データ品質改善の進め方はどの順序が最短か？

最短は、可視化→合意→上流修正→自動検知→運用移管の5段階を、対象を絞って一巡させる順序です。全社の全データを対象にせず、1つの業務・1つのテーブルで5段階を通し切ると、以降の展開が型として再利用できます。

5段階の全体像は？

5段階は、測る・決める・直す・見張る・渡すという流れで、順序を飛ばすと必ず戻されます。特に多いのが、可視化せずに修正から入り「どれだけ良くなったか」を説明できなくなるパターンです。

期間はデータの規模と関係部署の数で大きく変わるため、あくまで小規模な一巡の目安です。重要なのは各段階の長さではなく、5段階目まで設計に含まれているかどうかです。

各段階で何を「終わった」と判断するか？

終了判定は成果物の有無ではなく、次の段階の担当者が迷わず動けるかで決めます。レポートを作っただけ、基準を書いただけでは前に進みません。

• 可視化の完了条件：対象列ごとの現状値が数値で出ており、悪い順に並んでいる。
• 合意の完了条件：列ごとに合格ラインと責任部署名が埋まり、業務側が承認している。
• 上流修正の完了条件：修正後に取り込んだ新規データで、指標が合格ラインを満たしている。
• 自動検知の完了条件：意図的に不正データを流し、通知が届くことを確認できている。
• 運用移管の完了条件：社内担当が単独でしきい値を変更・再設定できている。

4段階目の「意図的に壊して試す」工程は省略されがちですが、ここを飛ばすと監視が動いていないことに半年後まで気づけません。

どこで止まりやすいか？

止まりやすいのは3段階目の上流修正で、他部署の業務変更を伴うため合意に時間がかかります。技術的には入力必須化やコード値の統一で済む話でも、現場の運用が変わるため調整コストが跳ね上がります。

ここを越えるには、1・2段階目で作った数字が効きます。「この列の欠損で、月に何件の問い合わせと何時間の手戻りが発生しているか」を具体的に示せると、議論が好き嫌いから費用対効果に移ります。逆に数字がないまま入力ルールの追加を提案すると、現場の負担増としてのみ受け取られます。一次的な負担を引き受ける部署に、何が返ってくるのかを先に示す——ここは技術ではなく設計と交渉の仕事です。

データ品質を維持する運用体制はどう作るか？

維持の条件は、データごとに単独のオーナーを決め、壊れを人より先に検知する仕組みを置くことです。改善は一度きりのプロジェクトで終わりますが、品質は放置すれば必ず劣化します。組織変更、システム改修、新しい取引先の追加——劣化のきっかけは日常業務の中に無数にあります。

誰が品質のオーナーになるべきか？

オーナーは、そのデータを最も使う業務部門に置き、IT部門は仕組み側を受け持ちます。IT部門に品質責任を寄せると、値の正しさを判断できないまま形式チェックだけが増えていきます。

この4役はフルタイムの専任である必要はなく、兼務で構いません。重要なのは、1つのデータに対してオーナーが1人に定まっていることです。「関係者全員で品質を守る」という体制は、実質的に誰も守らない体制と同じになりがちです。

壊れを早く知る仕組みは？

検知は、件数・NULL率・鮮度の3つを日次でしきい値監視するだけでも、大半の事故を拾えます。高度な異常検知アルゴリズムを入れる前に、この3点を押さえるほうが費用対効果は高いはずです。

• 件数：前日比・前週同曜日比が一定範囲を外れたら通知（連携停止・二重取込の検知）。
• NULL率：合格ラインを超えたら通知（入力仕様変更・画面改修の副作用の検知）。
• 鮮度：最終更新からの経過時間が閾値を超えたら通知（ジョブ失敗・上流遅延の検知）。

運用で効くのは、通知の出し方です。全件をメールで流すと必ず無視されるため、通知先を担当者個人ではなく業務チームのチャンネルに向け、「何が起きたか」ではなく「今日、誰が何をすべきか」を書く。この一手間があるかどうかで、監視が生き続けるか死ぬかが変わる印象があります。

FDEはデータ品質の改善にどこまで関わるのか？

FDEは、品質の可視化から上流修正の合意形成、検知の実装、内製への引き渡しまでを一貫して担います。SQLを書く人と業務を調整する人が分かれていると、3段階目で必ず止まるためです。Palantirが提唱するOntology（オントロジー）の考え方も、データを業務上の意味と結びつけて扱う点で、品質を業務要件として定義し直す発想と重なります。

FDEが現場で担う範囲は？

FDEの持ち場は、データと業務の境界にある「誰の担当でもない部分」を埋めることです。データ基盤の構築だけでも、業務コンサルティングだけでもありません。

具体的には、現場に入って手作業の補正を観察し、それを指標に翻訳し、修正案を実装し、関係部署に説明して回る——この往復を一人（または小さなチーム）で回します。役割が分かれていれば伝言ゲームで目減りする文脈が、往復できることで保たれます。FDEの職種そのものはFDEとはで整理しています。

なお、FDEが全部を抱え込むのは正解ではありません。パイプラインの運用や基盤の保守は、はじめからIT部門と分担しておかないと、引き渡しのタイミングで渡せるものがなくなります。

内製へどう引き渡すか？

引き渡しでは、ルールそのものより、なぜそのしきい値にしたかの判断基準を渡します。数値だけを渡すと、業務が変わったときに誰も更新できず、監視が形骸化します。

引き渡し時に明文化しておきたいのは、(1) 各しきい値の根拠となった業務上の境界、(2) 逸脱したときの一次対応手順と連絡先、(3) しきい値を見直すタイミング（システム改修時・四半期ごと等）の3点です。ここまで揃えば、社内担当が自分たちで基準を育てていけます。導入から内製化までの段階的な進め方は生成AI導入の進め方で詳しく扱っています。

次に読むべき記事は？

データの意味づけは「Ontology」、成果の測り方は「ROI・KPI」が対応します。品質を業務の意味と結びつけて設計する考え方はPalantir Ontologyとは、改善の効果を数字で示す方法はFDEのROI・KPIの測り方にまとめています。

本記事の5段階は、どれか一つを完璧にやるより、小さい対象で一巡させることに価値があります。まずは自部門で最も使われているテーブル1つを選び、6観点を実測するところから始めるのが、遠回りのようで最短です。

姉妹メディアの関連記事