「データトラブルが繰り返すのに、改善プロジェクトを社内で立ち上げられない」——社内合意からキックオフまでの実務ステップ

同じデータトラブルが繰り返している。それでも改善プロジェクトは立ち上がらない——「誰が主体でやるのか」「どこから始めればよいのか」「どうやって予算をとるのか」という問いに答えが出ないまま、重要課題として認識されつつも着手されない状態が続きます。

データ品質改善は、システム障害のように直ちに対応を迫られるケースばかりではなく、「重要だが後回しになりやすい」課題になりがちです。火事が起きているわけでも、システムが止まっているわけでもない。しかし放置すれば、意思決定の精度低下・BI/AI活用の精度低下・顧客対応ミスという形でコストが積み上がっていく。後回しにされやすいからこそ、プロジェクトとして意図的に立ち上げなければ始まりません。本記事では、データ品質改善を組織で動かすための4ステップを解説します。

なぜデータ品質改善は「なんとなく」で進むのか

担当が決まらない、予算が下りない、スコープが曖昧——データ品質改善が立ち上がらない際によく見られる課題が、この3つです。

「担当が決まらない」問題の背景には、データ品質がIT部門の仕事でも業務部門の仕事でもあるという曖昧さがあります。IT部門は「データを入力するのは業務側の問題」と考え、業務部門は「システムの問題はITが対応すべき」と考える。責任の所在が明確でないと、誰も主体になれません。

「予算が下りない」問題の背景の一つに、改善効果の定量化の難しさがあります。「データ品質が良くなると何が変わるか」を定量的に示せないと、他の投資案件との比較が難しくなります。「スコープが曖昧」という問題は、全社のデータを一度に整備しようとする発想から生まれます。何から始めるかが決まらないと動けません。

Step 1：現状把握——「何が問題か」を定量化する

プロジェクト立ち上げの最初のステップは、現状のデータ品質を定量的に把握することです。「なんとなくデータが悪い」という感覚を数値に変えることが、社内合意形成の出発点になります。

最初の現状把握で確認したい代表的な情報は以下の3点です。①主要データの欠損率——重要なフィールドが何割埋まっているか。②重複件数——顧客・商品・取引先マスタに重複レコードが何件あるか。③KPI定義の不統一——「売上」「顧客数」などの主要指標が部門ごとに異なる定義で使われていないか。この3点を把握することで、問題の規模感や優先順位を検討するための材料が得られます。

この現状把握は社内で実施することもできますが、「自社のデータを客観的に評価する」ことの難しさ（問題に慣れすぎていて気づかない、評価基準がない等）から、外部の診断を活用することも有効です。BFT InsightのQuick診断では約2週間でスコアとレポートを提供しており、プロジェクト立ち上げの材料として使われています。

Step 2：改善スコープと目標の設定——「何を・どこまで直すか」を決める

現状把握が終わったら、最初の改善プロジェクトのスコープを決めます。なお「診断のスコープ（何を測るか）」と「改善のスコープ（何を直すか）」は別の問いです。診断のスコープ定義については診断の前に整理すべきこと——スコープ定義が改善の成否を分けるで詳しく解説しています。ここでは診断が終わった後の「改善着手範囲の絞り込み」に絞ります。

全社のデータを一括で改善しようとするとプロジェクトが動かなくなります。現実的な起点は「業務への影響が大きく、かつ改善が比較的容易」なデータに絞ること。たとえば「顧客マスタの重複除去（3カ月・対象2万件）」「売上KPIの定義統一（営業と経理の2部門・1カ月）」のように、工数と期間をイメージできる粒度に落とします。

目標は「数値で言える状態」で設定します。「データ品質を改善する」ではなく「顧客マスタの重複率を現在の8%から1%以下にする」「欠損率が20%を超えている3項目を5%以下にする」のように、完了の定義を数値で持つことがプロジェクトを終わらせる条件になります。

Step 3：社内合意と体制づくり——「誰がやるか」を決める

スコープと目標が決まったら、社内の合意形成と体制づくりに入ります。ここで必要な合意は2層です。経営層への予算・リソースの承認と、現場（IT部門・業務部門）の協力です。

経営層への提案では、Step 1の現状把握で得た数値を使って「現状の損失」と「改善後の期待効果」を示します。「重複顧客による誤送付が月○件発生しており、対応工数と顧客満足への影響を合わせると年間○○円相当のコストになっている。重複除去プロジェクトに投資することで、3カ月後にこの問題を解消できる」という構成です。

体制として明確にしておきたい役割は3つです。①プロジェクトオーナー——経営層または部門長レベルで、意思決定とリソース調整の権限を持つ人。②データスチュワード——データの内容を知っている業務担当者で、定義の判断や現場調整を担う。③IT担当——システム上のデータ確認・クレンジング処理・スキーマの調査を担当する。この3つの役割を明確にしておくと、意思決定・業務調整・技術対応の責任分担がしやすくなります。

Step 4：キックオフと最初の施策——「見える成果」を早めに出す

体制が整ったら、キックオフミーティングを設定します。ここで共有すべき内容は①現状のデータ品質スコアと主な問題、②プロジェクトのスコープと目標、③スケジュールとマイルストーン、④各自の役割と責任範囲の4点です。

キックオフ後の最初の1カ月で「見える成果」を一つ出すことを目標にすると、プロジェクトの進捗を共有しやすくなります。たとえば重複顧客の一覧を作成して関係者に共有する、欠損率の多いトップ3項目を確認する、売上定義の不統一箇所をリストアップするといった「問題が目に見える」状態を作ることです。データ品質の問題は見えにくいため、最初に「こんなに問題があった」を可視化しておくと、関係者が課題の大きさを共有しやすくなります。

プロジェクトが「立ち消え」になるパターンと防ぎ方

データ品質改善プロジェクトには特有の失速パターンがあります。

• 【スコープの拡大】「ここも直したい」「あそこも整備すべきでは」という声が出て、当初のスコープから外れた作業が増え続けます。スコープ変更は必ずプロジェクトオーナーの判断を経るというルールを最初に決めておきます
• 【担当者の異動・業務繁忙】プロジェクト途中で担当者が変わったり、繁忙期で手が回らなくなったりします。作業を属人化させず、進捗と作業内容を文書化・共有しておくことが引き継ぎをスムーズにします
• 【成果の見えにくさ】数カ月続けても「何が変わったか」が感じられないと、モチベーションが下がります。月次でスコアの変化を数値で共有し、「重複が800件から200件に減った」といった具体的な進捗を関係者に伝え続けることが重要です
• 【完璧主義による停滞】「全データが揃うまで次のフェーズに進まない」という判断が、プロジェクトの足止めになります。「必要な品質水準を満たした時点で動かし、残りは運用しながら改善する」という割り切りが、プロジェクトを前進させます

まとめ

• データ品質改善は「緊急でないが重要」という性質から、意図的にプロジェクト化しなければ始まらない
• 立ち上げの4ステップは「現状把握→スコープ・目標設定→社内合意と体制づくり→キックオフと最初の施策」
• スコープは「影響が大きく・改善しやすい」データに絞り込む
• 目標は数値で定義し、完了の定義を持つ
• 最初の1カ月で「見える成果」を一つ出し、プロジェクトの実感を作る
• 立ち消えを防ぐには、スコープ管理・進捗の可視化・完璧主義の回避が重要