データ品質の問題はクレンジングで一度きれいにしても、根本原因を取り除かないと同じ問題が繰り返し発生します。「なぜデータが汚れるのか」という根本原因を構造的に把握することが、持続的なデータ品質改善の出発点です。データ品質が劣化する5つの原因についてはデータ品質が劣化する5つの原因：なぜ放置するほど汚れが蓄積するのかで解説しています。本記事は症状から根本原因を入力・設計・プロセス・ガバナンスの4レベルで構造的に分析するフレームワークに特化しています。
根本原因分析の4レベルフレームワーク
本記事では、データ品質問題の根本原因を「入力レベル」「設計レベル」「プロセスレベル」「ガバナンスレベル」の4つに分類して整理します。これは根本原因を構造的に捉え、対策の方向性を検討するための実務上のフレームワークであり、データ品質の分類方法には複数の考え方があるため、この4分類が唯一の標準というわけではありません。表面的な問題（NULLが多い・重複がある等）に対して、どのレベルが根本原因かを特定することで、適切な対策が決まります。
- 入力レベル：データを入力する人のスキル・ルールの理解不足・入力の手間が問題の源泉。対策は研修・マニュアル・入力フォームの改善
- 設計レベル：フォームの設計・バリデーションの不足・必須項目の設定不備がデータ品質の問題を構造的に生み出している。対策はフォーム設計の見直し・バリデーション追加
- プロセスレベル：業務プロセスの中でデータの確認・承認が抜けている・更新のタイミングがルール化されていない。対策は業務フローの見直し・チェックポイントの追加
- ガバナンスレベル：誰がデータの正確さに責任を持つかが不明確・品質KPIが設定されていない・問題が経営レベルで把握されていない。対策はデータオーナー設置・KPI設定・経営レポートへの組み込み
↑ 着手しやすい傾向 仕組みの見直しが必要になる傾向 ↓
※ 上位のレベルほど常に根本的という意味ではありません。同じ症状でも根本原因の所在は問題によって異なり、入力レベルと決めつけて研修だけ実施すると再発します
根本原因の特定方法：なぜなぜ分析の適用
「なぜなぜ分析（5 Whys）」はデータ品質問題の根本原因特定にも有効です。表面的な問題から「なぜ」を繰り返すことで、4レベルのどこに根本原因があるかを見つけられます。なお、複数の原因が絡む問題では5 Whysだけでは掘り下げる筋道が1本に限られるため、特性要因図（フィッシュボーン図）などを併用して原因候補を洗い出し、それぞれをデータで検証する方法も有効です。
例：「顧客マスタの電話番号のNULL率が30%と高い」という問題に対してなぜなぜ分析を適用すると——Why1「電話番号が入力されていない」→ Why2「電話番号は必須項目になっていない」→ Why3「システム設計時に必須にすると登録しにくいという意見があった」→ Why4「電話番号なしでも業務が回っていたため問題視されなかった」→ Why5「CRM活用のロードマップが曖昧で電話番号が将来必要になることが共有されていなかった（ガバナンスレベルの問題）」
根本原因別の対策マッピング
| 根本原因レベル | 典型的な症状 | 対策の方向性 |
|---|---|---|
| 入力レベル | 担当者によって入力内容がばらつく・入力規則が守られていない | 研修・入力マニュアル整備・入力例の提示 |
| 設計レベル | 自由テキストで何でも入力できる・バリデーションがない | フォーム設計の見直し・選択式への変換・バリデーション追加 |
| プロセスレベル | データ更新のタイミングがルール化されていない・二重入力がある | 業務フロー見直し・承認フロー追加・更新ルールの文書化 |
| ガバナンスレベル | データの誤りを誰も責任を持って修正しない・品質が誰の仕事かわからない | データオーナー設置・品質KPI設定・経営レポートへの組み込み |
根本原因レベル別の対策マッピング
根本原因分析の実施手順：組織的な進め方
根本原因分析を効果的に進めるために、「問題の特定→根本原因の仮説立案→データで検証→対策の設計」という4ステップで進めることをお勧めします。第1ステップでは、データプロファイリング（欠損率・重複率などデータの状態を調査・集計すること）で問題の種類・件数・分布を可視化します。例えば「顧客マスタのうち、電話番号のNULL率が30%・メールアドレスの重複率が8%」という具体的な数値で問題を定義します。
第2ステップでは、なぜなぜ分析を使って根本原因の仮説を立てます。複数の仮説（入力レベル・設計レベル・プロセスレベルなど）を並べ、「どのレベルが最も影響が大きいか」を優先度付けします。第3ステップでは、仮説をデータで検証します。「電話番号NULL率が高いのは特定の入力画面やチャネルから入力されたデータに集中しているか」を集計することで、設計レベルの問題かどうかを確認できます。
第4ステップは対策設計です。根本原因のレベルに対応した対策を選び、「対策の工数・効果・再発防止への貢献度」でプリオリティを付けて実行します。根本原因分析はワーキンググループで実施することを推奨します。業務担当者・IT担当者・データ担当者が参加し、「なぜ」の掘り下げを協議することで、業務的な視点を含んだ正確な根本原因特定ができます。
根本原因を見誤るパターンと対策
根本原因分析でよくある失敗は「見えやすい問題を根本原因と思い込むこと」です。例えば「担当者が入力ルールを守っていない（入力レベルの問題）」という観察から、すぐに「研修で解決できる」と判断してしまうケースです。しかしその背景には「入力フォームが使いにくく、正しい入力に余計な手間がかかる（設計レベルの問題）」や「入力ルールが複数の文書に散らばっており、最新版が誰にも把握されていない（プロセスレベルの問題）」があることも多いです。
2つ目の失敗パターンは「根本原因の分析を省略して対策に直行すること」です。「重複が多いからクレンジングしよう」という判断は正しいですが、「なぜ重複が生まれるのか」を理解せずにクレンジングだけ行うと、半年後に同じ量の重複が蓄積されます。クレンジングは「現状の問題を解消する作業」であり、根本原因の対策は「同じ問題の再発を防ぐ仕組みの整備」です。両者を並行して行うことが重要です。
3つ目の失敗パターンは「特定の担当者を原因として指摘すること」です。「○○さんの入力が雑だから問題が起きている」という個人への帰責は、再発防止につながらず、担当者のモラルも下げます。根本原因分析では「なぜそのような入力が起きる状況になっているか」という仕組みの問題を探ることが重要で、個人ではなくシステム・プロセスを改善対象とします。
どの問題から分析するか：対象の選び方
根本原因分析は手間のかかる作業なので、すべての品質問題に対して実施するのは現実的ではありません。最初に選ぶべきは「繰り返し発生していて、かつ業務が止まる問題」です。一度きりの入力ミスではなく、毎月のように同じ箇所で同じ種類の誤りが出ているものを選びます。繰り返し発生している場合は、個人の不注意だけでなく、入力方法・システム・業務プロセスなどに構造的な原因がないかを確認する手がかりになります。加えて、その問題が起きたときに誰かの業務が実際に止まっているかを確認してください。業務への影響が小さい項目から着手すると、改善の優先度を説明しにくく、関係者の協力を得にくい場合があります。
逆に、分析を後回しにしてよいのは「原因が既に分かっていて、対策の実行だけが残っている問題」です。分析のための分析にならないよう、着手前に「この分析で何が分かれば対策を決められるか」を一文で書いておくと、途中で迷いません。対象を1つに絞って最後までやり切ると、2つ目以降は同じ型で進められるようになります。最初から複数の問題を並行して分析すると、どれも仮説の検証まで到達しないまま止まりがちです。
まとめ
本記事では、データ品質問題の根本原因を「入力・設計・プロセス・ガバナンス」の4レベルに分類して整理しました。なぜなぜ分析を使って根本原因のレベルを特定し、それに対応した対策を取ることで、クレンジングを繰り返す「モグラたたき」から脱却できます。根本原因分析を省略してクレンジングだけ繰り返すのではなく、「問題がなぜ生まれる構造になっているか」を業務担当者・IT担当者が協力して探ることが、持続的なデータ品質改善の第一歩です。クレンジングと根本原因対策を並行して進めることで、現状の問題を解消しながら再発を防ぐ二重の効果が得られ、BI・AI活用に向けたデータ品質の安定的・継続的な維持が実現します。根本原因分析は一度やれば終わりではなく、組織・業務の変化に応じて定期的に見直す習慣を作ることが理想です。データ品質問題の根本原因分析・改善計画の策定支援についてはBFT Insightにご相談ください。
よくある質問
なぜなぜ分析を5回繰り返すと、最後は必ず「経営の問題」になってしまいます。
「なぜ」を機械的に5回繰り返すことが目的ではありません。5 Whysは根本原因に到達するまで掘り下げる手法で、回数は問題によって5回より少ないことも多いこともあります。実務上は「これ以上掘り下げても具体的な対策につながらない」と判断できるところ、つまり自分たちが実行できる対策にたどり着いた時点で区切る方法があります。フォームにバリデーションを追加する、承認ステップを1つ足す、担当を決める——こうした具体的な手が見えた時点で止めて構いません。経営課題まで遡ってしまうのは、途中で「誰が」「どの業務で」という主語を失っているときに起きがちです。各段階で主語を明示すると、実行可能な階層で止まりやすくなります。
根本原因の仮説をデータで検証したいのですが、どう確かめればよいですか。
仮説が正しければ現れるはずの偏りを探します。入力レベルが原因という仮説なら、担当者別・拠点別に誤りの発生率を出します。設計レベルなら、自由入力項目と選択式項目で誤りの差を見ます。プロセスレベルなら、特定の業務フローを通ったレコードに偏りがあるかを確認します。偏りが出なければ仮説が外れているので、別のレベルを疑います。この確認をせずに対策へ進むと、効かない施策に工数を使うことになります。
分析した結果、対策が業務部門の負担増になる場合はどう進めればよいですか。
業務負担が大きく増える対策は、現場で継続的に運用することが難しくなります。入力項目を増やす、確認ステップを足すといった対策を検討する場合は、同時に何かを減らせないかを探してください。たとえば必須項目を1つ増やす代わりに、実際には使われていない項目を廃止する、といった組み合わせです。それが難しい場合は、対策のレベルを変えることも検討します。入力レベルで人に負担をかけるより、設計レベルで選択式にする方が、結果的に負担が軽くなることがあります。