現場で「データがあるのに話が進まない」瞬間は珍しくない。資料の数値を見て全員が頷いたはずなのに、翌週には同じ議題が“最初から”再議論されている。その原因を辿ると、数字そのものではなく、数字の意味(定義・単位・測定条件・温度・治具・統計条件・版)が共有されていないことが多い。前提条件（認識）が異なる状態では、正しい結論に到達できない。結果として、手戻り、過剰品質、過剰在庫、顧客対応の遅延といった形でコストが増大する。
製造業でDXが進まない理由
近年、企業・業界・社会のあらゆる場面でDXの重要性が叫ばれている一方、実装は思うように進まない。理由は技術やツールだけではない。多くの組織では、
- レガシーデータをどう紐づけて使うかが整理されないままシステム構築に着手してしまう
- データの定義・条件・版・責任といった前提(データリテラシー)が設計要件として扱われにくい
- 現場では「当面の負荷増」を嫌い、入力や手順変更が後回しになりやすい
という三つのボトルネックが重なっている。結果として、データはあるのに「活用できる形」にならず、改善が継続しない。
このボトルネックの理解の手助けとして、以下の２つのシーンを見てほしい。
データリテラシー不足による失敗例
シーン①：電子デバイス業界編(モデル×測定条件×温度×ロット)
開発担当：「このMOSFET、低損失で、データシートのRds(on)もバッチリだ！」
検証担当：「シミュレーションモデルでも見たわ。SPICEのスイッチング損失、かなり小さい。波形も綺麗だったね」
品質担当：「ちょっと待ってほしい。『どのモデル』で見たの？ベンダ提供モデルか、自前で手直しした版か。モデルの版が違えば、同じ部品でも別物だよ」
開発担当：「えっと……社内共有フォルダにあったやつだ。たぶん最新版！」
品質担当：「『たぶん』が一番危険だよ！。測定条件は揃っている？Vgs、Id、パルス幅、配線、ゲート抵抗、熱条件……どれが違っても損失は変わるよ」
検証担当：「あと温度よ。25℃のRds(on)と、125℃や150℃のRds(on)は条件次第で大きく異なるから、データシートの脚注を読まないと比較できないわね」
品質担当：「それに、量産はロットでばらつくから、代表値(Typ)で勝っても、最大値(Max)で負ければ現場が混乱するよ！」
開発担当：「…俺は『良さそう』で突っ走るところだったぜ」
検証担当：「『数値』じゃなくて『数値が成立する前提』を揃えないと、結論だけが先走るのよね」
品質担当：「うん。前提の統一こそ、意思決定の第一条件だよ」
シーン②：自動車業界編(仕様版×ソフト版×治具校正×ASIL相当)
開発担当：「このECU、要求どおり応答10msだ！グラフも出たし、合格でいいだろ！」
検証担当：「その『要求』って、どの仕様書の版？Rev.AとRev.Cで条件が変わっていること、よくあるわ。まずそこを固定しないと」
品質担当：「そのとおり。さらに言えば、ソフトの版はどれ？ビルド番号が違えば、同じ10msでも中身が違う」
開発担当：「いや、手元の試験機で動いたんだって！」
品質担当：「治具の校正(キャリブレーション)は有効？校正期限が切れた治具の数値で合否を決めたら、後で全部ひっくり返るよ」
検証担当：「測定ログのサンプリング周期も要確認ね。周期が粗いと、10msに見えても実は取りこぼしている可能性があるわ」
品質担当：「それに、ASIL相当の観点が抜けていない？安全要求レベルが上がるほど、条件の網羅性、トレーサビリティ、再現性が要る。『たまたま動いた』は通用しない」
開発担当：「つまり……仕様の版、ソフトの版、治具の校正、そして安全要求。全部が揃って初めて合格って言えるのか」
検証担当：「そう。『同じ言葉で別のもの』を見ている状態を潰すのが、データリテラシーの仕事よ」
品質担当：「うん。版と前提を揃えずに走れば、設計は必ずやり直しだよ」
これらの事例のポイントは、『誰も嘘はついていないのに、前提がズレるだけで意思決定が失敗すること』である。
データリテラシーの定義（4つの能力）
二つの小話が示すのは単純である。DXの議論はツールや基盤の話になりがちだが、土台は人の“基礎体力”である。そこで本連載では、データリテラシーを次の4能力として定義する。
- Read(読む)：単位・条件・脚注・定義・前提を外さない力
- Work(扱う)：収集を設計し、品質を保ち、更新できる形にする力
- Interpret(解釈する)：相関と因果、ばらつき、不確かさを扱い、誤読を避ける力
- Communicate(伝える)：再現できる形で受け渡し、組織知として残す力
ここまでが「現場の戦闘力」である。
DX推進のボトルネック
加えて、DX推進の現実では階層ごとにボトルネックが違う。現場は入力負荷と目的不明に疲弊し、管理職は比較不能な指標に翻弄され、経営は投資判断できる言葉に翻訳できず意思決定が遅れる。データリテラシーは個人の素養ではなく、組織能力そのものなのである。
さらに、部署をまたぐと用語や粒度がズレ、業界をまたぐとデータシート記述の揺れが自動化を止める。これは個人の努力だけでは限界がある。
DMBOK(Data Management Body of Knowledge：データガバナンス)で「データは資産」と捉え、REBOK(Requirements Engineering Body Of Knowledge：要求・合意)で「何を満たすべきか」を揃え、PLM(Product Lifecycle Management：製品ライフサイクル管理)で「変更を統制」する必要がある。
しかし、それでもなお決定的に効くのがCM(Configuration Management：構成管理)である。どの版のデータと、どの条件と、どのモデル・ツール・前処理が“セット”として成立しているかを固定(ベースライン化)できなければ、再現も監査もできない。前提が固定されないまま共有だけ進めても、連携は単に「つながっているだけ」で終わってしまう。
本連載の全体地図(全12回)
本連載では、DXが進みにくい背景の一つとして「データリテラシー不足」がどのように手戻りや意思決定遅延を生むのかを解説し、本連載の狙いと全体像を示した。第1〜12回については、以下内容について解説していく予定である。
| 第1回 | Read① |
データシートは「読めばわかる」とは限らない
～単位・条件・脚注・定義を外すと比較が破綻する～
|
|---|---|---|
| 第2回 | Read② |
数値の前に、データの正体を見抜く
～生データ/加工/推定、粒度、欠損、誤差など「生い立ち」を読む～
|
| 第3回 | Work① |
現場のデータ収集は作業ではなく設計である
～目的→項目→粒度→頻度→責任→保管→更新を設計する～
|
| 第4回 | Work② |
データ品質の敵は忙しさと善意である
～省略・丸め・後回しが後工程を燃やす構造を解剖する～
|
| 第5回 | Interpret① |
グラフは嘘をつかないが、人は誤読する
～相関と因果、軸の罠、平均の罠、見える化の落とし穴～
|
| 第6回 | Interpret② |
不確かさを扱える組織が、DXに強い
～確度・仮説・ばらつきの共有が意思決定を速くする～
|
| 第7回 | Communicate① |
伝えるとは「再現できる形で渡すこと」
～定義・条件・前処理・版・責任者・履歴の最小セット～
|
| 第8回 | Communicate② |
データ受け渡しの仕様書を作る
～「データ契約(Data Contract)」的に、入力/出力・品質・更新・責任・検証を1枚にする ～
(現場が嫌がる“仕事が増える”を、テンプレ化で最小化する回。第11回CMにもつながる)
|
| 第9回 | 組織間連携 |
組織間連携：部署の壁は「用語辞書」と「粒度」で壊せる
～用語の揺れと粒度ズレを揃えるだけで連携コストが激減～
|
| 第10回 | 業界間連携① |
データシート記述のバラバラがDXを止める
～最小共通項を揃えないと自動化できない、を構造で示す～
|
| 第11回 | 業界間連携② |
データスペース以前の必須条件(ID×メタデータ×責任×CM)
|
| 第12回 | DX推進総括 |
現場・管理職・経営のボトルネックをほどく
～TOC(Theory of Constraints：制約理論)で制約を特定し、90日アクションへ落とし込み～
|
本連載の問いは一つである。そのデータで、誰もが、同じ結論に到達できるか？」この問いに迷いなく答えられる状態を目指していく。
あなたの職場で今交わされている「その数字」は、条件・定義・版まで揃った「同じ世界の数字」だっただろうか？直近の業務を一つ思い出して確認してみてほしい。
