生産管理システム 導入 失敗｜稼働の1年以上前に決まる5つの断層

生産管理システムの導入が失敗したという話は、たいてい稼働後に語られます。現場が使わない、紙が残る、Excelが復活する。しかしこれらは症状であって原因ではありません。JUASの調査データを読むと、QCDの成否はプロジェクトの規模と計画の作り方で相当程度説明でき、その大半は稼働の1年以上前に決まっています。この記事では、稼働ではなく計画の側から、失敗が確定する5つの断層を発注側が操作できる順に並べ直します。

生産管理システムの導入失敗は、稼働日ではなく計画段階で確定している

導入プロジェクトの振り返りは、ほとんどが稼働後に行われます。稼働3か月後に現場をまわると、入力されていない実績画面、印刷して手書きされた作業指示、そして誰かが個人PCで作り直したExcelの生産計画が見つかります。ここから「現場の抵抗が強かった」「教育が足りなかった」という総括が出てきます。

この総括は、観測としては正しく、打ち手としては役に立ちません。現場が使わないという事実は結果であり、なぜ使えない仕様になったのかを説明していないからです。教育を増やしても、そもそも入力する時間が工程に存在しなければ実績は入りません。抵抗をなだめても、マスタが実物と合っていなければ画面は正しい数字を出しません。

実務で追いかけていくと、稼働後に観測される症状は、いずれも稼働の12〜18か月前に置かれた判断に行き着きます。プロジェクトをどの大きさで区切ったか、稼働の合格ラインを誰がどう定義したか、現行業務を誰が言語化したか、マスタと実績の入口を設計に含めたか、そして拠点側に運用を引き取れる人がいたか。このうち上流の4つは、キックオフからせいぜい数か月以内に決まってしまいます。残る運用の引き取りだけは稼働直前まで手を入れられますが、そこに割ける時間は上流の4つの決め方によってすでに決まっています。

そして重要なのは、この5つのうち発注側が着手前に自由に動かせるものは、実は2つしかないという点です。プロジェクトの刻み方と、誰が仕様を書くか。残りの3つは、この2つの決め方に強く従属します。逆に言えば、ベンダー選定の巧拙よりも先に、この2つを自分で決めておくかどうかが分岐点になります。

本稿で扱う5つの断層を先にまとめます。以降の各章は、この表の1行ずつを掘り下げる構成です。

この5つは独立していません。断層2で刻み方を誤ると、断層3で仕様を書く時間が消え、断層4のマスタ整備が後工程に押し出され、断層5の教育期間が最後に削られます。失敗は1か所で起きるのではなく、上流の決定が下流の選択肢を潰していく形で進行します。

データで見る導入失敗｜QCDはプロジェクト規模で決まる

感覚論から始めないために、公開されている調査データを先に置きます。参照するのは、日本情報システム・ユーザー協会（JUAS）が2026年4月に公開した『企業IT動向調査報告書2026』（2025年度調査、回答企業約950〜1,000社）です。国内のユーザー企業を対象に長期の時系列で追っている調査で、システム開発の品質・予算・工期（QCD）の遵守状況が継続的に集計されています。

この調査によると、システム開発のQCD遵守度は過去10年間で概ね下落傾向にあります。そして注目すべきは、その内訳がプロジェクト規模で明確に分かれることです。小規模な案件は比較的良好である一方、500人月以上のプロジェクトでは、品質・予算・工期のいずれについても3〜5割がネガティブな評価となっています。

この一点だけでも、実務上の含意は大きなものになります。「大きく作って一度で終わらせる」ことは、効率の追求ではなくリスクの積み増しだという読み方ができるからです。分割は妥協ではなく、統計的に観測されている数少ない有効な手段です。

海外の調査も同じ方向を指しています。野村総合研究所が紹介しているガートナーの2024年調査では、70%以上のERPパッケージ導入・刷新プロジェクトが、当初のビジネス目標を満たせずに終わっているとされています。ここで注意したいのは、この「失敗」がシステムが動かなかったという意味ではないことです。システムは動いています。動いたうえで、当初掲げた経営上の目標に届いていない。断層1で扱う「目的の断層」は、この数字が示している問題そのものです。

なお同じJUASの調査では、2025年度にIT予算が増加した企業は52.6%、DI値は43.3ポイントで5年連続の上昇、2026年度予測のDIも39.9ポイントとされています。増加理由として挙げられた項目の上位は、既存システムの更新・更改・機能強化が66.3%、円安と人件費・ベンダー費用の高騰が46.6%、クラウドサービスの増加が45.0%です（複数回答のため、いずれもその理由を挙げた企業の割合です）。予算は増えているものの、増額の主な動機は既存システムの維持更新と単価上昇の側にある、という構図が読み取れます。新規の取り組みに使える枠が自動的に広がっているわけではありません。一度失敗したときの再挑戦は、次の予算サイクルまで持ち越されます。

悪化要因の1位は工期＝計画時の考慮不足、予算＝仕様変更の多発、品質＝ベンダーのスキル不足

同じJUASの2025年度調査では、QCDが悪化した要因の1位が、それぞれ次のように整理されています。

この3つの並びは、しばしば語られる二項対立をほとんど無効化します。

第一に、「パッケージにすれば失敗しない」という主張です。工期悪化の1位が計画時の考慮不足、予算悪化の1位が仕様変更の多発であるという事実は、パッケージかスクラッチかという実装方式の選択とは独立しています。パッケージを選んでも、計画時に業務差分の吸収工数を見込んでいなければ工期は遅れますし、稼働直前に「この帳票がないと出荷できない」と判明すれば仕様変更は多発します。実装方式の議論は、この2つを解決しません。

第二に、「大手ベンダーに任せれば安心」という主張です。品質悪化要因の1位がベンダーのスキル不足であり、しかも品質に不満と答えた企業の6割に達しているということは、ベンダー選定が依然として最大の品質リスクだということを意味します。ただしここで実務的に効くのは、会社の規模ではなく、実際にアサインされる担当者がその業種の生産形態を理解しているかどうかです。個別受注生産と繰返生産では、同じ「生産管理システム」という言葉の下にある機能がまるで違います。

第三に、「小さく始めると結局作り直しになる」という主張です。JUASのQCD遵守状況がプロジェクト規模が小さいほど良好である以上、刻むこと自体がリスク低減の主要な手段であるという結論のほうが、データには整合します。作り直しを恐れて一度に全部を作る選択は、500人月以上の帯に自ら移動する行為です。

断層1｜目的の断層 — 稼働そのものが目的化する

野村総合研究所は、ERP導入・刷新プロジェクトの失敗要因を3つに整理しています。ビジョン（北極星）の欠如、現場とマネジメント層の意識ギャップ、そして複数プロジェクト間の統合管理の困難さです。

このうち最初の「北極星の欠如」が、断層1にあたります。プロジェクトが進むにつれて、目的が「経営課題を解決すること」から「予定日に稼働させること」へ静かに置き換わる現象です。

置き換わり方には型があります。キックオフの資料には、たいてい立派な目的が書かれています。リードタイム短縮、在庫圧縮、原価の可視化。ところが要件定義が長引き、テストで不具合が出て、稼働日が近づいてくると、会議の議題は「何が終わっていないか」だけになります。この時点で、当初の目的を持ち出す人はいなくなります。稼働日に全機能が動いた瞬間、プロジェクトは成功として報告されます。ガートナーの調査で70%以上が当初のビジネス目標を満たせていないというのは、この報告と実態の乖離を数字にしたものです。

もう1つの失敗要因である「現場とマネジメント層の意識ギャップ」も、目的の断層から派生します。マネジメント層が語る目的は経営指標であり、現場が受け取るのは入力作業の増加です。この2つを橋渡しする中間の言語がないと、現場にとってのシステム導入は「仕事が増えるイベント」以上の意味を持ちません。

稼働判定を「動いたか」から「何が減ったか」に変える

この断層を塞ぐ方法は1つしかありません。稼働の合格ラインを、機能の動作ではなく業務の変化で定義し、それを企画段階で文書に落としておくことです。

具体的には、稼働から一定期間後に測る指標を、あらかじめ数値と測定方法つきで決めます。重要なのは、指標そのものより「誰がどうやって測るか」を先に決めることです。測定方法が決まっていない指標は、稼働後に必ず測られません。

この表を企画段階で3〜5項目ぶん埋めておくと、プロジェクトの性格が変わります。要件定義で機能追加の要望が出たとき、「その機能はこの目標値のどれに効きますか」という問いが成立するからです。この問いに答えられない要望は、優先度を下げても誰も困りません。断層3で扱う仕様変更の多発は、この問いが用意されていないことに起因する部分がかなりあります。

なお、目標値は控えめに置いて構いません。むしろ、初回フェーズで測れる範囲に絞ることが重要です。全社の在庫金額のような指標は、稼働3か月では動きませんし、システム以外の要因が多すぎて因果が説明できません。測れて、動くことが説明でき、現場が実感できる指標を選びます。

断層2｜規模の断層 — 生産管理システムの導入期間と人月をどう刻むか

生産管理システムの導入期間はどれくらいかかるのか、という質問には、正直に言えば一意の答えがありません。対象範囲、拠点数、生産形態、既存システムの状態で桁が変わるからです。しかし、答えられる問いに言い換えることはできます。「1つのフェーズをどこで切るべきか」です。

JUASのデータが示しているのは、規模とQCDの関係でした。500人月以上で品質・予算・工期のいずれも3〜5割がネガティブ、小規模案件は比較的良好。つまり、導入期間の設計とは、総量を見積もる作業ではなく、リスクの帯から出るように総量を分割する作業です。

1フェーズ50人月・6か月を超えたら分割を疑う

実務的な目安として、当社では1フェーズあたり50人月・6か月を超える計画が出てきたら、まず分割の可否を検討します。これはJUASが示した数値ではなく、現場での運用上の閾値です。根拠は3つあります。

第一に、人が仕様を記憶していられる期間です。要件定義から稼働まで6か月を超えると、初期に決めた仕様の背景を関係者が思い出せなくなります。「なぜこの仕様にしたのか」が失われると、テスト段階で出てくる違和感を仕様変更として処理するしかなくなります。

第二に、業務側の人事異動と生産品目の変化です。半年から1年が経過すると、要件を出した担当者が異動し、対象の製品が終息し、新しいラインが立ち上がります。長いプロジェクトは、動く的を狙い続けることになります。

第三に、意思決定の粒度です。フェーズが大きいほど、途中で「やめる」「変える」という判断が下せなくなります。すでに投じた費用が大きいため、明らかに筋の悪い方向に進んでいても止まりません。小さく刻むことの本質的な価値は、コスト削減ではなく、判断の機会を複数回持てることにあります。

分割の切り口は、機能で切るよりも業務の閉じ方で切ったほうが機能します。

このうち最後の「データで切る」は、失敗経験のある工場で特に有効です。計画系の機能は現場の実績データの精度に依存するため、実績が入らない状態で計画機能を作っても動きません。実績収集と可視化を初回フェーズに置けば、後述する断層4を先に越えたうえで計画系に進むことになります。

分割の設計そのものについては、スモールスタートでのシステム導入で、初回フェーズの範囲の決め方と、次フェーズへの接続の作り方を個別に整理しています。分割は「小さくする」ことではなく、「小さいまま繋がる形にする」ことが難しい部分です。

分割にあたって必ず決めておくべきことが1つあります。フェーズ間で共有するマスタとコード体系です。ここを各フェーズで別々に決めると、統合時に全データを作り直すことになり、分割の利点が消えます。品目コード、工程コード、取引先コード、拠点コードの体系だけは、最初のフェーズの前に全社で確定させておきます。

断層3｜仕様の断層 — 現行業務を誰も説明できない

JUASの調査には、内製化を進めるうえでの課題を尋ねた設問があります（複数回答、n=953）。上位は開発人材の量の不足52.7%、質の不足49.6%、プロジェクトマネジメント人材の不足44.4%と続きますが、実務上より重いのはその次に並ぶ項目です。

現行業務への理解不足が38.2%、ビジネス要件をシステム仕様に落とせないが34.5%、現行システムの仕様がわからないが25.9%。これらは開発力の不足ではありません。自社が今どう仕事をしているのかを説明できない、という状態です。

そして、JUASの調査では約6割の企業がシステム開発の一部または全部を内製化し、内製と外部委託を使い分けようとしているとされ、その内製化の対象はシステム企画・要件定義といった上流工程が中心だとされています。上流を自社に取り戻そうとしているのに、上流に必要な現行業務の理解が欠けている。これが今のユーザー企業の構造です。同じ調査で、IT組織において不足している機能・能力の上位に、IT人材の採用・育成73.9%、データ活用・データマネジメント71.9%、新技術の探索・評価69.5%（n≈946）が挙がっていることも、同じ方向を指しています。

この状態でベンダーに要件定義を丸投げすると、何が起きるか。ベンダーは現行業務を知らないので、標準的な業務フローを前提に設計します。テスト段階になって現場が触ると、「うちはこうやっていない」という指摘が一斉に出ます。これがQCD悪化要因の予算1位、「仕様変更の多発」の実体です。仕様変更は現場のわがままではなく、要件定義の時点で現行業務が文書化されていなかったことの遅延したツケです。

対処は地味です。発注前に、現行業務を発注側の手で書き出しておきます。網羅的な業務フロー図を描く必要はありません。次の4点を、対象業務ごとに1ページで書けば足ります。

4つめは軽視されがちですが、費用に直接効きます。現行帳票をそのまま移植する前提で見積が組まれると、実際には誰も見ていない項目のために工数が積まれます。現行の棚卸しは、機能を増やす作業ではなく、削る根拠を作る作業です。

生産管理システムのカスタマイズとスクラッチ開発の分岐点

現行業務が文書になって初めて、パッケージのカスタマイズで行くか、スクラッチ開発（自作を含む）で行くかという判断ができます。順序が逆になっている案件が非常に多く、製品を選んでから業務差分を数えはじめるため、差分の大きさが判明した時点で予算も期間も動かせなくなっています。

判断は、業務全体ではなく機能領域ごとに行います。1つのシステムの中でも、標準機能でよい領域と、自社固有の作り込みが要る領域は必ず分かれます。

判断の原則は明確です。競争力に直結せず、他社と同じやり方でよい領域は標準機能に寄せます。逆に、自社の強みが宿っている領域と、顧客や当局から様式を指定される領域は、作り込む価値があります。すべてを作り込むと保守できなくなり、すべてを標準に寄せると現場が回らなくなります。

カスタマイズには、費用以外に2つの継続コストが付きます。1つはバージョンアップ時の再検証負荷です。標準機能に手を入れた箇所は、製品側の更新のたびに動作確認が必要になります。もう1つは属人化です。改造仕様が文書化されていないと、担当者の交代とともに誰も触れないブラックボックスになります。カスタマイズを決めるときは、改造仕様書の受領と、改造箇所の一覧を成果物として契約に含めておきます。

製品の比較軸そのものについては、生産管理システムの比較で、生産形態別の適合性と、比較表に載らない評価項目を整理しています。製品選定は断層3の後に来る工程であり、順序を守ることが最も費用対効果の高い意思決定です。

断層4｜データの断層 — 実績が入ってこないシステムは翌月に死ぬ

稼働した生産管理システムが数か月で使われなくなるとき、原因のほとんどはデータです。画面に出ている数字が実物と合っていない、あるいは数字がそもそも入ってこない。この2つのどちらかです。

数字が信用されなくなると、現象は一方向に進みます。まず現場が画面の数字を検算しはじめます。次に、検算のためにExcelで並行管理が始まります。そして最終的に、Excelが正となりシステムは入力するだけの場所になります。この過程は速く、稼働の翌月には始まっていることも珍しくありません。

データの断層は、マスタ側と実績側の2つに分かれます。

マスタの精度は移行前に測る

マスタ移行は、多くのプロジェクトで「データを移す作業」として扱われ、後工程に置かれます。しかし実際には、マスタの精度は現行の運用品質そのものであり、移すだけでは直りません。

移行前に必ず測っておくべきは、次の4つです。測るとは、サンプルを抜いて実物と突き合わせるという意味です。

このうちBOMと標準時間は、所要量計算と負荷計算の前提になります。前提が崩れているまま計画機能を稼働させると、システムが出す計画を誰も信用しなくなり、結局は経験による調整に戻ります。この状態は「システムが使えない」と評価されますが、実際にはマスタが使えないのです。

測った結果が悪ければ、選択肢は2つです。移行前に整備するか、その機能を初回フェーズから外すか。整備には時間がかかるため、断層2の分割設計と一体で判断します。整備が終わらない機能を稼働範囲に残すことが、最も避けたい選択です。

実績側はさらに単純で、入力する人の時間が工程内に確保されているかどうかがすべてです。1日の終わりにまとめて入力する運用は、必ず精度が落ちます。理由は記憶に頼るからです。実績は、作業が終わった場所で、作業の一部として入力される必要があります。

自動取得は理想ですが、全工程で実現できるわけではありません。現実的には、自動取得できる工程は自動化し、それ以外はバーコード読取に寄せ、手入力は例外処理だけに限定する、という組み合わせになります。

もう1点、基幹システムとの連携があります。会計や販売管理と生産管理を繋ぐとき、決めるべきはインターフェースの技術方式よりも先に、どちらが正のデータを持つかです。品目マスタ、取引先マスタ、在庫数量のそれぞれについて、どちらのシステムが正でどちらが写しかを1行ずつ決めます。ここが曖昧なまま連携すると、両側で更新できてしまい、どちらが正しいか誰にも分からない状態になります。連携の周期（リアルタイムか日次か）と、連携が失敗したときの検知方法も、設計時に決めておく項目です。

断層5｜運用の断層 — タイ工場では「定着」が最後の関門になる

ここまでの4つは日本国内でも海外拠点でも共通します。断層5だけは、海外拠点、とりわけ日系製造業のタイ拠点で重みが変わります。

日本本社で設計されたシステムをタイ拠点に展開するとき、暗黙に置かれている前提があります。「操作する人は日本語か英語のマニュアルを読み、業務ルールの背景を理解している」という前提です。この前提が成立している拠点は多くありません。以下は統計ではなく、実務で繰り返し観測される構造です（在タイ日系企業を取り巻く事業環境そのものについては、記事末の参考情報に挙げたジェトロの進出動向調査を参照してください）。

第一に、言語です。画面のラベルとエラーメッセージが日本語または英語のままだと、現地作業者は内容を読めません。読めない画面に対して人がとる行動は決まっており、決められた位置のボタンを決められた順序で押すという位置の暗記になります。この状態では、画面レイアウトが少し変わるだけで再教育が必要になり、例外が起きたときには誰も判断できません。

第二に、教育の対象範囲です。日本では、システムの操作を教えれば済むことが多くあります。理由は、業務ルールの背景が既に共有されているからです。海外拠点では、なぜこの入力が必要なのか、この数字が後工程で何に使われるのかという業務の文脈から説明する必要があります。操作訓練だけを行うと、入力は形式的になり、精度が上がりません。

第三に、人の入れ替わりです。作業者や現場管理者が入れ替わる前提に立つと、運用は個人の習熟ではなく手順書に載っている必要があります。稼働時に整備した手順書が現地語で存在し、更新の担当者が決まっているかどうかで、1年後の運用品質が変わります。

第四に、本社標準と現地最適の線引きです。本社が全社標準として決めたコード体系や帳票様式は守る必要がありますが、現地固有の商流や顧客要求まで本社標準で押し切ると、現場は必ず裏でExcelを作ります。守る範囲と現地に委ねる範囲を、稼働前に明示的に線引きしておきます。実務上、コード体系・マスタ構造・会計連携項目は本社標準、実績入力の方法・現場帳票のレイアウト・言語は現地判断、という切り分けが破綻しにくい形です。

第五に、稼働直後の支援体制です。稼働から1か月は、想定していなかった例外が毎日出てきます。この期間に現地で質問に答えられる人がいないと、現場は自分たちの判断で運用を作りはじめ、それが定着します。後から直すのは、最初から作るより高くつきます。

これらの論点をどう計画に織り込むかは、海外拠点へのシステム導入で、本社主導と現地主導の役割分担、展開順序の決め方とあわせて整理しています。

失敗を避ける導入の流れ｜発注前に決める6つのこと

ここまでの5つの断層を、発注前のアクションに落とすと6項目になります。順序に意味があります。上から順に決めないと、下の項目が決められません。

パッケージソフトの導入支援を外部に依頼する場合でも、この6項目のうち代わりに決めてもらえるものは1つもありません。支援側ができるのは、決めるための材料を揃え、選択肢と影響を示し、文書の形に整えることです。決定そのものは発注側に残ります。

逆に言えば、この6項目が埋まっている状態で見積を取ると、各社の金額の差が読めるようになります。差が出るのは、想定している作業範囲か、アサインされる担当者の経験か、リスクの見込み方のいずれかです。6項目が未定のまま見積を取ると、各社は未決事項を自分で引き受ける前提で積むため、金額は割れ、比較そのものが成立しません。

導入の流れとしては、この6項目を固める期間を、要件定義の前工程として明示的に確保します。ここを「準備」として計画外に置くと、実際にはキックオフ後に並行して行うことになり、断層3で述べた遅延したツケが発生します。

よくある質問（FAQ）

生産管理システムの導入失敗率はどれくらいですか？

生産管理システムに限定した公的な失敗率の統計は、確立したものがありません。近い指標として参照できるのは2つです。1つはJUAS『企業IT動向調査報告書2026』で、システム開発のQCD遵守度は過去10年間で概ね下落傾向にあり、500人月以上のプロジェクトでは品質・予算・工期のいずれも3〜5割がネガティブな評価となっています。もう1つは野村総合研究所が紹介しているガートナーの2024年調査で、70%以上のERPパッケージ導入・刷新プロジェクトが当初のビジネス目標を満たせずに終わっているとされています。この2つから読み取るべきは失敗率の数字そのものではなく、失敗の分布に規模依存性があるという構造です。小規模案件は比較的良好で、大規模になるほどネガティブ評価が増えます。つまり、失敗確率は与えられた条件ではなく、プロジェクトの刻み方によって発注側が動かせる変数だということになります。なお「タイでは何%が失敗する」といった地域限定の統計は存在しないため、そうした数字を見かけた場合は出典を確認してください。

生産管理システムの導入期間はどれくらいかかりますか？

対象範囲、拠点数、生産形態、既存システムの状態によって桁が変わるため、一般的な期間を示すことにはほとんど意味がありません。より実務的な問いは「1つのフェーズをどこで切るか」です。当社では、1フェーズあたり50人月・6か月を超える計画が出てきた時点で分割の可否を検討します。これはJUASが示した数値ではなく運用上の閾値ですが、根拠は3つあります。第一に、6か月を超えると関係者が初期に決めた仕様の背景を思い出せなくなり、テスト段階の違和感が仕様変更として処理されるようになること。第二に、半年から1年で担当者の異動や品目の入れ替わりが起き、動く的を狙い続けることになること。第三に、フェーズが大きいほど途中で止める判断が下せなくなることです。分割の本質的な価値はコスト削減ではなく、判断の機会を複数回持てることにあります。総期間を短くしようとするより、1回の意思決定サイクルを短くするほうが、結果として早く効果が出ます。

パッケージとスクラッチ開発はどちらが失敗しにくいですか？

この問い自体が、失敗の主要因から外れています。JUASの2025年度調査でQCD悪化要因の1位は、工期が「計画時の考慮不足」、予算が「仕様変更の多発」、品質が「ベンダーのスキル不足」（品質に不満と答えた企業の6割）です。この3つはいずれも実装方式の選択とは独立しています。パッケージを選んでも、計画時に業務差分の吸収工数を見込んでいなければ工期は遅れますし、要件が固まる前に開発へ入れば仕様変更は多発します。判断すべきは製品の種別ではなく、機能領域ごとに標準機能へ寄せるか作り込むかの線引きです。競争力に直結せず他社と同じやり方でよい領域は標準に寄せ、自社の強みが宿る領域と顧客や当局から様式を指定される領域は作り込む。この線引きを、現行業務を文書化したうえで機能領域ごとに行います。なお自作（社内でのスクラッチ開発）を選ぶ場合は、JUASが示す内製化の課題、すなわち開発人材の量の不足52.7%、質の不足49.6%、プロジェクトマネジメント人材の不足44.4%が、そのまま自社に当てはまるかどうかを先に確認してください。

生産管理システムのカスタマイズはどこまでやってよいですか？

金額の上限で決めるのではなく、継続コストを引き受けられるかどうかで決めます。カスタマイズには初期費用のほかに2つの継続コストが付きます。1つは製品のバージョンアップ時の再検証負荷で、標準機能に手を入れた箇所は更新のたびに動作確認が必要になります。もう1つは属人化で、改造仕様が文書化されていないと担当者の交代とともに誰も触れないブラックボックスになります。この2つを引き受ける体制がある領域だけが、カスタマイズしてよい領域です。実務的には、顧客指定の帳票やラベル、現場環境に強く依存する実績収集の入口は作り込む価値が出やすく、所要量計算のロジックそのものへの改造は最後の手段とすべき領域です。加えて、カスタマイズを決めた時点で、改造仕様書の受領と改造箇所の一覧を成果物として契約に含めてください。ソースや設計資料を受け取れない契約で作り込んだ機能は、数年後に誰も手を入れられない資産になります。

一度失敗したシステムは作り直すしかないですか？

作り直しが最初の選択肢になることは、実際には多くありません。失敗の症状がどの断層から来ているかで打ち手が変わるためです。現場が使っていない原因がマスタ精度にあるなら、システムを作り替えてもマスタが直らない限り同じ結果になります。この場合はマスタ整備が先です。実績が入ってこない原因が入力の時間と場所にあるなら、入力方式（バーコード読取や設備からの自動取得）の見直しで解決することがあります。目的が定義されていなかったために効果が説明できない状態なら、稼働判定の指標を後から定義し、測るところから始められます。作り直しが必要になるのは、業務そのものが変わってしまい、現行システムのデータ構造では表現できない場合です。判断するには、まず失敗を症状ではなく断層で分類してください。分類の結果、次に手を入れるべき範囲が現行システムの一部で済むことは珍しくありません。既存資産をどこまで残せるかを見極めてから、範囲を小さく切って着手するほうが、全面刷新より確実です。

タイ工場で生産管理システムを導入するとき特に注意すべき点は？

5点あります。第一に、画面とエラーメッセージの言語です。現地作業者が読めない画面に対して人がとる行動は位置の暗記になり、レイアウト変更のたびに再教育が必要になるうえ、例外時に誰も判断できません。第二に、教育の範囲です。日本では操作を教えれば済むことが多いのは業務ルールの背景が共有されているからで、海外拠点では「なぜこの入力が必要か」「この数字が後工程で何に使われるか」から説明する必要があります。第三に、手順書です。人の入れ替わりを前提に、現地語の手順書と、その更新責任者を稼働前に決めておきます。第四に、本社標準と現地最適の線引きです。コード体系・マスタ構造・会計連携項目は本社標準、実績入力の方法・現場帳票のレイアウト・言語は現地判断、という切り分けが実務上は破綻しにくい形です。第五に、稼働直後1か月の支援体制です。この期間に現地で質問に答えられる人がいないと、現場が独自に作った運用がそのまま定着します。なお、これらはタイ拠点で繰り返し観測される実務上の構造であり、地域別の失敗率のような統計として述べているものではありません。

まとめ

生産管理システムの導入失敗は、稼働日に起きるのではなく、稼働の12〜18か月前に確定しています。稼働後に観測される症状、すなわち現場が使わない、紙が残る、Excelが復活するといった事象は、いずれも上流の判断が下流の選択肢を潰した結果です。症状を並べても打ち手にはなりません。

JUAS『企業IT動向調査報告書2026』が示しているのは、QCD遵守度が過去10年で概ね下落傾向にあること、そして500人月以上のプロジェクトでは品質・予算・工期のいずれも3〜5割がネガティブな評価になる一方、小規模案件は比較的良好だということです。QCD悪化要因の1位は、工期が「計画時の考慮不足」、予算が「仕様変更の多発」、品質が「ベンダーのスキル不足」（品質に不満と答えた企業の6割）でした。これらはいずれもパッケージかスクラッチかという実装方式の選択とは独立しており、規模の刻み方と要件定義の作り方に帰着します。野村総合研究所が紹介するガートナーの2024年調査で、70%以上のERPプロジェクトが当初のビジネス目標を満たせずに終わっているという数字も、稼働と成功が別物であることを示しています。

本稿で置いた5つの断層は、目的、規模、仕様、データ、運用です。目的の断層では、稼働判定を「動いたか」から「何が減ったか」へ変え、現状値・目標値・測定方法・測定責任者をセットで書きます。規模の断層では、1フェーズ50人月・6か月を超える計画が出たら分割を疑い、業務プロセス・拠点・品目・データのいずれかで切ります。仕様の断層では、現行業務を発注側の手で書き出します。JUASの内製化課題で現行業務への理解不足38.2%、システム企画力不足34.5%、現行システムの仕様がわからない25.9%が並んでいることは、この作業が外部に委託できないものだということを示しています。データの断層では、品目・BOM・工程・在庫の精度を移行前に実測し、実績入力を工程内の作業として設計します。運用の断層では、拠点側に運用を引き取る人と現地語の手順書、そして稼働直後1か月の支援体制を用意します。

そして、この5つのうち発注側が着手前に自由に動かせるのは、規模の刻み方と、誰が仕様を書くかの2つです。ベンダー選定はその後に来る工程であり、この2つが未決のまま見積を取れば、金額は割れ、比較そのものが成立しません。逆にこの2つが決まっていれば、残りの3つは選択肢が大きく絞られます。失敗を避けるという言い方は正確ではないかもしれません。実際にやっているのは、失敗が確定する前に、判断できる状態を作っておくことです。

どこから手を付けるか決まっていない段階でも構いません。現行の業務フローと、実際に現場で使われている帳票やExcelを見せていただければ、5つの断層のどこが未整備で、初回フェーズをどう切ると判断の機会を確保できるかについて、分割の切り口だけをお出しすることもできます。過去に一度導入がうまくいかなかった、という状態からのご相談も承っています。お問い合わせからお気軽にご連絡ください。

参考情報

• 企業IT動向調査報告書2026（一般社団法人 日本情報システム・ユーザー協会／JUAS、2026年4月）
• 『企業IT動向調査2026』プレスリリース第1弾（JUAS、2026年）
• ERP導入・刷新による経営変革の実現～3つの失敗要因から紐解く成功の要諦（野村総合研究所、2025年8月）
• ERPパッケージ導入・刷新プロジェクトの難しさと処方箋（野村総合研究所 NRI Management Review No.24、2026年1月）
• JUAS、「企業IT動向調査2026」の速報値を発表（i Magazine、2026年2月）
• タイ日系企業進出動向調査 2024年度（ジェトロ、2025年2月）