DX（デジタルトランスフォーメーション）の現場では、しばしば
「データを整備してから始めよう」という議論になります。
しかし実際には、データが揃うのを待っていたら、いつまでも前に進めないことがほとんどです。
この「データが揃わない現実」を正面から扱えないと、取り組みは長期化し、
結局は現場で使われない仕組みになりやすくなります。
ここで言う「データが揃わない」とは、単に量が少ないという意味ではありません。
欠けている、矛盾している、粒度が揃っていない、そもそも言語化されていない──
こうした状態が混ざり合っている、ということです。
「データが揃わない」とは具体的にどういう状態か
現場で起きている「データが揃わない」は、主に次のような形で現れます。
1) 欠けている（存在しない、記録されていない）
- 必要な項目が記録されていない
- 担当者の頭の中にしかない
- 口頭で確認したが、文章に残っていない
- 資料はあるが、肝心の判断材料が抜けている
2) 矛盾している（資料と現場が一致しない）
- 仕様書と現場運用がズレている
- 最新版がどれか分からない
- 部署ごとに前提が違い、数字や条件が食い違う
- 更新履歴が追えず、どの判断がいつ変わったか分からない
3) 粒度が揃っていない（細かすぎる／粗すぎるが混在する）
- 詳細なデータはあるが、目的に対して過剰で扱えない
- 全体サマリーしかなく、判断に必要な具体性が足りない
- 同じ項目でも、案件によって記録の粒度が違う
- 入力ルールが曖昧で、比較ができない
4) 言語化されていない（前提が暗黙のまま）
- 「いつものやり方」で進むが、基準が文章化されていない
- 例外対応が多く、ルールとして定義されていない
- 判断理由が説明されず、結果だけが残る
なぜ現場ではデータが揃わないのか
データが揃わないのは、現場が怠けているからではありません。
多くの場合、構造的な理由があります。
1) 業務の優先順位が「記録」より「納品」になっている
現場は、期限や成果物の提出で評価されます。
そのため、データ整備は後回しになりがちです。
特に、判断の過程や理由は「今すぐ成果にならない」ため、残りにくい傾向があります。
2) 現場の情報は、会話・現物・状況に埋まっている
現場には、文章や表に乗らない重要情報があります。
例えば、現物を見たときの違和感、顧客の言外の意図、作業者の経験に基づく注意点などです。
こうした情報は「文章にするコスト」が高く、記録されにくいのが実情です。
3) データ整備の目的が曖昧だと、続かない
「いつか必要になるから集めよう」という状態だと、入力は続きません。
目的が曖昧なデータ収集は、現場にとっては負担だけが増えるためです。
結果として、記録の質も量も揃わなくなります。
4) 部署ごとに言葉と基準が違う
同じ言葉でも部署によって意味が違う、ということが起きます。
それがデータの不一致や矛盾を生み、統合を難しくします。
ここを解決せずにシステム化しても、運用が破綻しやすくなります。
データ不足のまま進めると起きる失敗パターン
1) 入力項目を増やして現場が使わなくなる
データが足りないと、システム側は「入力を増やす」方向に寄りがちです。
しかし入力が重くなるほど、現場は使わなくなります。
結果としてデータはさらに揃わず、悪循環になります。
2) 例外が処理できず、結局は手作業に戻る
現場には例外が必ずあります。
データが揃わない状態で例外処理を設計できないと、
システムは「標準だけ」しか扱えず、結局は手作業の戻りが発生します。
3) 「それっぽい」判断が出ても説明できない
判断材料が欠けたまま結論だけを出すと、説明責任が果たせません。
説明できない判断は合意形成を遅らせ、後工程での修正やトラブルに繋がります。
データを集める前に整えるべきもの
重要なのは、最初から完璧なデータを揃えることではありません。
先に整えるべきは、データを“揃えられる形”です。
- 目的：何の判断のためにデータが必要か
- 項目：必須項目と任意項目の区別
- 粒度：どの程度の細かさなら運用できるか
- 用語：部署間で意味がズレない定義
- 例外：例外は何で、どう扱うか（無理に統一しない領域の明確化）
- 更新：いつ、誰が、何を更新するか
構築人工知能が採る基本姿勢（データ不足を前提に前へ進める）
構築人工知能は、データ不足を「失敗要因」として排除しようとするのではなく、
データ不足の状態でも業務を前へ進められるように設計するという姿勢を取ります。
具体的には、次のような考え方です。
- 不足している情報を明確にする：何が足りないかを“見える化”する
- 不足を質問に変える：次に確認すべきことを具体的な問いとして提示する
- 今ある情報で組み立てる：完璧を待たずに、扱える範囲で前へ進める
- 判断の前提を残す：後から修正できるよう、前提と理由を記録する
ここでは、どの仕組みを使うかよりも、
「判断材料を構造として残す」という考え方が重要です。
実務での進め方（小さく始めて、使いながら揃える）
データ不足を前提に進めるには、最初から全社で統一しようとしないことが重要です。
まずは影響が大きい領域から、小さく始めて確実に揃えていきます。
- 判断が詰まりやすい場面を選ぶ：手戻りが多い、確認が多い、説明が必要な領域
- 必須項目だけ定義する：最小限で回る項目に絞る
- 不足を記録する：欠けていること自体を記録し、次の確認に繋げる
- 次の案件で改善する：運用して初めて“足りない”が具体化する
- 揃える範囲を広げる：成果が出た領域から段階的に拡張する
この進め方であれば、データが揃い切っていなくても業務が止まりにくくなり、
さらに「揃えるべきデータ」が現場で納得のいく形で定義されていきます。
よくある誤解（データが揃えば成功するわけではない）
データが揃えば自動的に成功する、という考えは危険です。
本当に必要なのは、データそのものではなく、
判断の前提と理由が扱える形で揃っていることです。
データが増えても、前提が曖昧であれば、結論は揺れます。
逆に、最小限の情報でも、前提と制約が整理されていれば、
合意形成は進み、改善も可能になります。
「データが揃わない現実」を受け入れた上で、
それでも前に進める設計を持つことが、現実のデジタルトランスフォーメーションの成功確率を上げます。
