失敗は「動かなかった」ではなく「効かなかった」形で現れる
MES導入プロジェクトが技術的に破綻して稼働しないケースは、実は多くありません。多いのは、稼働はしたが効果が出ていない状態です。
- 入力は行われているが、そのデータを使う業務がない
- 警告は出るが、現場は無視して作業を続けている
- 帳票は出るが、経理は別途Excelで原価を計算している
- 稼働3か月後から、「その他」の不良コードが全体の6割を占めている
この状態は稟議上「稼働済み」と扱われるため、失敗として認識されないまま保守費が払い続けられます。欧米の調査でも同じ構図が数字に出ています。
導入率93%に対して完全統合23%、そして43%が自らデータを活用できていないと答えています。「動いているが効いていない」は例外ではなく多数派です。以下、その状態に至る7つの経路を分解します。
失敗パターン1〜4：人と組織の側で決まるもの
パターン1：目的が「DX推進」で止まっている
構想書に書かれた目的が「製造DXの推進」「見える化の実現」で終わっているケースです。目的が数値化されていないため、要件定義でスコープを判断する基準がなく、要求が出てきた順に積み上がります。
兆候：要件定義の会議で「それも必要ですね」が繰り返され、除外の判断が一度も行われない。 分岐点：構想策定の出口。 そのとき取るべき判断：構想書に、達成基準を数値と期限で書く。「特定ロットの使用先を要求受領から30分以内に全数特定できる（2027年3月まで）」のように、測定方法まで含めて書きます。書けない項目は、まだ要件になっていません。
パターン2：プロジェクトオーナーが業務変更を決められない立場にいる
オーナーが情報システム部門に置かれると、システムの仕様は決められても、現場の作業手順を変える決定はできません。結果として「現場のやり方は変えずに、システムを現場に合わせる」方向に流れます。
兆候：現場から出た要望が、業務側で棄却されずにそのまま要件になる。 分岐点：構想策定の出口。 そのとき取るべき判断：オーナーを製造部門側に置き、「作業手順の変更を承認する権限」を明文化する。情シスは実装の責任を持ちますが、業務変更の決定者にはなれません。
パターン3：現場の入力工数を見積もっていない
MESの導入によって、それまで存在しなかった入力作業が発生します。1工程あたり5秒でも、1日500工程なら約42分／日です。この時間を稟議に入れていないと、稼働後に「聞いていない」という反発が起き、入力精度が落ちます。
兆候：稟議書の効果欄に工数削減しか書かれておらず、工数増加の欄がない。 分岐点：PoCまたはテスト計画の出口。 そのとき取るべき判断：PoCの測定項目に「1工程あたりの入力所要時間」を入れ、実測する。自動収集に置き換えられる項目と、人が入力する項目を線引きし、増加分を稟議に明記します。
パターン4：教育を「操作研修」として設計している
画面の操作は覚えても、なぜその入力が必要なのかが共有されていないと、稼働3か月後から入力の質が落ちます。停止理由が「その他」に集中する現象は、ほぼこの原因です。
兆候：教育資料が画面のスクリーンショット中心で、データの行き先が説明されていない。 分岐点：PoCまたはテスト計画の出口。 そのとき取るべき判断：教育を「新しい業務手順の合意」として設計する。各入力項目について、誰がそのデータを何に使うのかを1行で説明できるようにします。定着のための設計はMESを現場に定着させるチェンジマネジメントで扱います。
失敗パターン5〜7：設計と技術の側で決まるもの
パターン5：現行業務をそのまま写して作り込む
現行の帳票・画面・手順をそのまま再現する方向で設計すると、追加開発が増え、バージョンアップのたびに再検証が必要になります。3年後、バージョンアップができない状態で塩漬けになるのが典型的な帰結です。
兆候：RFPに現行業務の詳細手順書を添付している。機能要件への回答で「追加開発」の比率が3割を超えている。 分岐点：要件定義の出口。 そのとき取るべき判断：Fit to Standardを方針として明文化し、標準機能から外れる要件は「例外申請」として個別に承認する運用にする。承認者を経営層に置くと、例外は自然に減ります。方針の立て方はFit to Standard を貫くための意思決定で扱います。
パターン6：マスタ整備を構築フェーズに置いている
品目・工程・設備・作業者のマスタは、既存システムから機械的に移せることがほとんどありません。品目コードが事業部ごとに違う、工程名が現場ごとに違う、設備台帳が最新でない。これらは構築フェーズで発覚すると、2〜3か月の遅延に直結します。
兆候：プロジェクト計画上、マスタ整備の開始が構築フェーズになっている。 分岐点：要件定義の出口。 そのとき取るべき判断：要件定義と並行してマスタ整備に着手し、要件定義の出口条件に「マスタ設計方針の確定」を含める。品目コードの統一方針だけは、プロジェクト開始時点で経営判断として決めてください。
パターン7：データの出口を設計していない
収集したデータの行き先が「必要になったら見る」の場合、投資は回収されません。原価計算、ERPの在庫更新、品質会議の定例資料、顧客への提出物──具体的な出口に接続されていないデータは、収集コストだけが残ります。
兆候：要件定義書に、MESが出力するデータの受け手（システム名・業務名・利用頻度）が書かれていない。 分岐点：PoCまたはテスト計画の出口。 そのとき取るべき判断：出力データごとに受け手を1つ特定し、受け手側の担当者に「この粒度・この頻度で受け取れるか」を確認する。受け手が特定できないデータ項目は、収集対象から外します。
前述のRockwell調査で43%が「データを活用できていない」と答えているのは、この工程が抜けた結果です。関連して、AVEVAがAVEVA World 2026（2026年5月20日）で引用したGartnerの予測では、「2026年までに、AI-readyなデータがないためAIプロジェクトの60%が放棄される」とされています。データの出口設計は、AI活用を検討する段階になるとさらに強く効いてきます。
7つのパターンは、3つの分岐点に収束する
7パターンを時系列に並べ直すと、分岐点は3か所しかありません。
分岐点を通過するときのチェックは、いずれも1〜2時間の会議で終わる内容です。費用がかかるのは対策ではなく、通過を確認しないまま先に進むことです。
すでに稼働してしまった場合に、まだ取れる手
分岐点を通過できないまま稼働に至ったプロジェクトでも、回復できる範囲はあります。効果が大きい順に3つです。
1. 出口を1つ作る（パターン7への対処）。 最も費用対効果が高い手です。既存の会議体を1つ選び、そこで使う定例資料をMESのデータから自動生成させます。データが使われる場が1つできると、入力の質は自然に上がります。逆に、入力の督促を強化しても質は上がりません。
2. 不良コード・停止理由コードを再設計する（パターン4への対処）。 「その他」が過半を占めている場合、原因はほぼ確実にコード体系の設計にあります。現場が15秒以内に迷わず選べる粒度に作り直し、選択肢を階層化します。ただしコード体系の変更は過去データとの連続性を壊すため、変更時期と旧コードの読み替え表を必ず残してください。
3. 追加開発の棚卸をする（パターン5への対処）。 稼働後1年程度で、追加開発した機能の利用状況を計測します。使われていない機能を廃止すると、バージョンアップ時の再検証対象が減り、保守費の構造が改善します。廃止の判断は、利用ログという事実に基づいて行ってください。「念のため残す」を積み重ねると、5年後にバージョンアップ不能な状態になります。
これらはいずれも、新規プロジェクトを立ち上げずに実施できます。「作り直す」判断を検討する前に、この3つを試す価値があります。導入前の段階で効果の成立条件を点検する方法はMES導入のメリットとデメリットにまとめています。
よくある質問
失敗プロジェクトは、途中で止めるべきですか？
分岐点Bまでであれば、止めるコストは相対的に小さく済みます。要件定義の出口で「やらないこと」を決められず、追加開発の見込みが3割を超える場合は、一度止めて範囲を絞り直すほうが総額は下がります。構築フェーズに入ってからの中止は、設計成果物とマスタが残るだけで実質的な損失が大きくなるため、範囲を縮小して稼働まで持っていき、稼働後に見直すほうが現実的です。判断は「もう投じた費用」ではなく「これから必要な費用と得られる効果」で行ってください。
現場が入力してくれません。どうすればよいですか？
督促と罰則では解決しません。確認すべきことが3つあります。第一に、その入力データを使っている業務が実在するか。第二に、入力にかかる時間が現場の作業時間の中で確保されているか。第三に、入力結果が現場に返ってきているか（自分たちのラインの実績が見えるか）。3つのいずれかが欠けている場合、その入力項目は仕組みとして成立していません。項目を減らすか、自動収集に置き換えるかの判断が必要です。
ベンダーの選定を誤ったことが原因の失敗はありますか？
あります。ただし本稿で挙げた7パターンのうち、ベンダー起因で説明できるのはパターン5（作り込み）の一部だけです。製品の適合性が低かった場合でも、それが表面化するのは分岐点Bで標準機能への適合率を確認しなかったためです。選定段階で機能要件への回答を「標準／設定／追加開発／実現不可」の4区分で取得していれば、契約前に判別できます。RFPでの確認方法はMES導入のRFP作成にまとめています。
