製造業DXで失敗する保全現場のリアル｜故障データとシステム運用の落とし穴

ある日、上からこんなお達しが降ってきます。

「故障データを電子化して、活用できる体制を作れ」

DXの波は、保全現場にも容赦なくやってきます。

ワイの職場も例外ではありませんでした。

データ集めろと言われたら集めるしかないわけです。

故障日報をシステムに入力する運用が始まり、1年、2年と続けていくと、データは数千件規模で蓄積されていきます。

一覧画面を開くと、ズラーっと並ぶ故障記録。

「おお、データ溜まってるな」という安心感。

報告書にも「故障データの電子化完了」と書ける。

DX推進担当のスライドにも「データ蓄積件数○○件超」と載る。

やってる感、すごい。

でも、ここからが地獄の入り口です😇
「集めた」と「使える」はまったくの別問題でして、保全現場でよく見る2つの典型的な失敗パターンを紹介します。

パターン1：故障データが集計に使えない

まず1つ目のパターンです。
故障日報をシステムで入力する運用自体は、ワイの職場でも回っています。

使えている部分はあります。
過去に似た故障が起きたとき、前回どうやって直したかを検索できる。
週明けに出社して、休日の当番中に何があったかを引き継ぎとして確認できる。
この2つだけでも、紙の台帳からは大きく進歩しています。

問題はここからです。

「じゃあこのデータ、年間の故障傾向を出してください」と言われたとき。
「設備ごとの故障回数ランキングを出してください」と言われたとき。
「予算根拠として故障データを集計してください」と言われたとき。

無理ぽｗｗｗｗｗｗ

なぜ無理なのか。
データは入っているのに、集計に使える形になっていないからです。

原因の分析です。

まず、入力項目が統一されていません。
故障の分類が選択肢ではなく、自由記述になっています。
入力する人ごとに書き方がバラバラです。

具体的にどうなるかというと、同じベアリングの異音故障なのに、記録にはこう書かれています。

「軸受異音」
「ベアリング音」
「モーター異音（ベアリング?）」
「うるさい」

全部同じ故障です😇

「うるさい」で故障記録を残す人、正直嫌いじゃないですけど集計は不可能です。
表記揺れの嵐で、Excelのフィルターが何の役にも立ちません。

こうなると、Excelに吐き出して手作業で名寄せする地獄が始まります。
5,000件の名寄せ、やったことある人いますか。
ワイはあります。二度とやりたくないです。

そしてこの名寄せ作業を終えてようやく集計してみると、ある事実に気づきます。
「このデータ、最初から選択肢ベースで集めていれば、10分で出せたのでは？」
その通りです。数日かけた作業の答えが、「最初の設計ミス」です😇

故障データは集めたら使えると思いがちですが、集計に使うためには「集め方」の時点で設計が必要です。
この話は、過去記事の「Excelの故障記録を”分析できる形”に変える」でも詳しく書いています。

データが集計できないと何が起きるか。
・故障傾向を把握できない
・設備更新の優先順位に根拠が出せない
・予算の稟議で「何台壊れましたか」に答えられない。等。

つまり、経営陣に通じる言葉で設備の状況を語れなくなります。

「データはあるのに使えない」は、
「データがない」より始末が悪いです。

パターン2：システムに使われてしまう

2つ目のパターンです。こっちはもっとタチが悪い。

ワイの職場では、予備品管理システムを導入したことがあります。
予備品の在庫管理をデジタル化するという目的でした。

導入前の期待は大きかったです。

「システム化すれば管理が楽になる」
「在庫の見える化ができる」
「発注タイミングも自動化できるかもしれない」

期待に胸を膨らませていざ導入。

現場をシステムに合わせるな！！！！
システムを現場に合わせろ！！！！

すみません、いきなり結論から叫びました。

何が起きたかというと、システムの都合上、現場では管理していない項目まで入力しないと登録できない仕組みになっていました。

使わない管理区分をこじつけて入力する。

現場の分類と合わない選択肢から、無理やり一番近いものを選ぶ。
そもそもシステムが想定している運用フローと、現場の実際の動きが合っていない。

結果どうなったかというと、管理が楽になるどころかシステムに合わせるための追加作業が増えました。

本末転倒もいいところです。
何のためのシステムなんですか！！！！

しかもこの手のシステム、「ここ直してください」と言っても簡単には直りません。ちょっとしたシステム改修でも百万円規模でかかります。
予算を通すだけで半年。通ったとしても改修に数か月。

「ちょっとこの項目を非必須にしてくれ」がなぜ百万円なんですか😇

これ、システムが悪いというより、導入時の設計プロセスに問題があります。

現場がどう使うかを固める前に、システムの仕様が決まってしまった。
業者の提案をベースに要件定義が進み、現場の運用実態が反映されなかった。
「システム化」がゴールになってしまい、「現場が楽になる」がゴールになっていなかった。

導入してから「使いにくい」と気づいても、もう遅いです。
改修費の壁が立ちはだかって、現場が我慢する構図が完成します。

そしてこの「我慢」のコストは、経営からは見えません。

入力に余計にかかっている時間、使いにくいシステムを迂回するために発生するアナログ作業、現場の不満によるモチベーション低下──こういった損失は数字として上がってこないからです。

数百万円の改修費は見えるのに、毎日30分の余計な入力作業が年間でいくらの人件費になるかは、誰も計算しないんですよね😇

なぜこの2パターンが起きるのか、構造的な3つの理由

パターン1（データが使えない）とパターン2（システムに使われる）。
一見違う問題に見えますが、根っこは同じです。構造的な原因は3つあります。

📊 理由1：何のために集めるか・何のためにシステム化するかが決まっていない

目的が「DX推進」「電子化」で止まっています。
「誰が」「いつ」「何の意思決定のために」データを使うのか、具体的な使用場面が定義されていません。
ゴールが「集めること」「システム化すること」になっている時点で、運用は破綻します。
DXのDはデジタルですが、デジタル化自体が目的になった瞬間、現場から見ると仕事が増えただけです😇

📊 理由2：見る人・使う人が決まっていない

データを集める担当は決まっています。

入力ルールもある程度は決まっています。

でも、「そのデータを見て意思決定する人」が誰なのか、決まっていません。
見る人がいないデータは、どれだけ蓄積しても誰の行動も変えません。

これ、保全に限った話ではないと思います。
「データ集めました！」
「で、誰が見るの？」
「…………」

このやり取り、あらゆる部署で再生産されている気がします。

📊 理由3：業者主導・現場不在で設計が決まる

システムの要件定義が業者主導で進みます。
業者は業者の得意なパッケージをベースに提案します。
その後、発注者側がしっかり自分たちの現場用に落とし込めるよう指示を出せないと、現場の運用実態と切り離されたシステムが納品されます。

もちろんこれは業者・メーカーは全く悪くないです。
業者はシステム構築のプロであって、保全現場の運用のプロではありません。
それに様々な顧客ニーズに合わせることを欠かさないので。

そもそも現場のことを一番知っているのは現場の人間なので、現場が仕様策定に関わらないと、どうしてもズレが生じます。

そして改修費だけが積み上がっていく😇

じゃあどうすれば「使えるデータ」「使われるシステム」になるか

ここからは解決策です。
ワイの失敗と、そこからの修正で学んだことをベースに書きます。

⚡ステップ1：まず「使う場面」を1つだけ決める

「とりあえず集める」ではなく、「何の会議で、誰が、どんな判断をするために使うか」を1つだけ決めます。

具体例を挙げます。

・故障件数の多い設備トップ10をランキングで出して、対策の優先順位を決める
・故障頻度と修理費用の推移を根拠資料として出して、更新予算を通す
・故障モード別の発生件数を部位ごとに出して、点検周期を調整する

まずは1つです。
欲張って全部やろうとすると、結局どれも中途半端になります。
1つの使い場面に絞ることで、何を集めるべきかが逆算で決まります。

⚡ステップ2：アウトプット側を先に設計する

使う場面が決まったら、欲しいアウトプットの形を先に作ります。
ここが最重要です。

たとえば、月例会議で故障の多い設備トップ10を出したい場合。
欲しいアウトプットはこうなります。

・設備名（ポンプA、コンベヤB、モーターC…）
・故障件数（月間）
・前月比（増減の傾向）
・主な故障モード（ベアリング異音が3件、電気系が2件…）

この4列が並んだ一覧表が欲しい、とイメージする。
そうすると、入力時に最低限必要な項目が自動的に決まります。

「設備名」「故障日」「故障モード」──この3つを選択肢ベースで入力すれば、上の表は自動集計で出せます。
逆に言えば、この3つが自由記述だと集計のたびに名寄せ地獄が発生します。

先にゴールの表やグラフを紙に書いてください。
A4の紙1枚に、「こういう表が月1回出てきたら判断できる」という完成形を描く。
それが入力フォーマットの設計書になります。

⚡ステップ3：入力フォーマットは「選択肢ベース」で設計する

自由記述は集計の敵です。
設備名、部位、故障モードは、選択肢から選ぶ方式にします。

「軸受異音」「ベアリング摩耗」「電気系短絡」「センサ異常」「制御系エラー」──こういった選択肢をあらかじめ用意して、入力者は選ぶだけにする。
自由記述欄は「備考」として残しますが、集計に使うのは選択肢の項目だけです。

選択肢の数は最初から完璧を目指さなくて大丈夫です。
まず主要な10〜20種類を用意して、その他を設けておく。
「その他」が増えてきたら、選択肢を見直す。
この繰り返しで精度が上がっていきます。

これだけで、名寄せ地獄から解放されます。

⚡ステップ4：システムは現場の運用に合わせる

システムを導入する場合、「現場がどう動いているか」を先に整理します。

業者に丸投げする前に、以下を社内で固めます。

・現場で実際に管理している項目は何か
・現場で管理していない（必要ない）項目は何か
・入力するタイミングはいつか（故障対応直後か、翌日か、週末か）
・入力する人は誰か（対応した本人か、リーダーか、事務担当か）
・出てきたデータを誰が見て、何に使うか

これを整理してから業者と話す。
「このパッケージの機能一覧です」から始まる打ち合わせではなく、「うちの現場ではこう使いたい」から始まる打ち合わせにする。

この順番を間違えると、システムに現場を合わせる構図になります。
ワイが経験した予備品管理システムの失敗は、まさにこの順番が逆だったことが原因です。

というか順番が逆どころか、要求仕様も固まってなかったんですよね。。。

結論です。

・データは「集める前に見る側を作る」
・システムは「導入する前に現場の運用を作る」
・逆算で設計する。

これが原則です。

この事例から持ち帰る教訓3つ

🔧 教訓1：「集める」と「見る」は別の運用設計が必要

データを入力する運用と、データを見て使う運用は、まったく別物です。
入力ルールだけ作って「見る側」の運用を作らなければ、データは蓄積されるだけで腐っていきます。
見る側の運用（誰が・いつ・何の会議で使うか）を先に設計してください。
「集めること」はスタートラインにすぎません。
ゴールは「集めたデータで判断が変わること」です。

🔧 教訓2：データは「見る人」が先、「集める人」は後

見る人が決まっていないデータは、集めた瞬間に価値がゼロになります。
「このデータ、誰が見るんですか」に答えられない時点で、そのデータ収集は止めたほうがいいです。
見る人が決まれば、「何を集めるべきか」は自然に決まります。
経営層やDX推進担当が「データを活用しろ」と言うなら、「誰が見るか」を先に決める。
その問いに答えるのは、号令を出す側の責任でもあります。

🔧 教訓3：システム導入は「業者の言うがまま」が最大の地雷

業者はシステムのプロです。保全現場のプロではありません。
現場の運用設計を内部で固めてから、業者と話してください。
「業者が提案してくれたから」で決めると、現場が苦しむ構図が確定します。
改修費の数百万円は、「導入前の運用整理に1か月かけるコスト」より確実に高くつきます。