Fit to Standard を貫くための意思決定──ギャップを4分類し、誰が決めるかを先に決める

Fit to Standard は思想ではなく、決裁ルールで守られる

キックオフで「今回はFit to Standardで行きます」と宣言したプロジェクトが、Fit&Gap の後半で個別開発リストを積み上げていく。この現象はほぼすべての現場で起きます。

原因は方針の徹底不足ではありません。ギャップが出たときに「誰が」「いつまでに」「何を根拠に」決めるかが決まっていないことです。決め方が用意されていないと、判断は現場との交渉に委ねられ、交渉では常に「困っている側」の主張が通ります。結果として、標準機能で回せるはずの業務まで個別対応が入ります。

したがってFit to Standardの実装とは、設計工程の前に決裁ルールを作る作業です。順序が逆になっているプロジェクトは、方針を何度宣言しても崩れます。

Gartnerが2026年3月23日に公開した Market Guide for Manufacturing Execution Systems（著者：Jake Cunningham、Christian Hestermann）のキーメッセージも、この点に近いところを突いています。AIによる導入障壁の低減よりレガシー刷新が先であること、そして「派手な機能ではなく測定可能な成果に集中せよ」という趣旨です。標準に乗るという判断は、この「測定可能な成果」に集中するための手段であって、目的ではありません。

ギャップを4つに分類する

出てきたギャップを1件ずつ議論すると、必ず時間切れになります。先に分類軸を決め、分類ごとに処理ルールを固定するのが実務的です。分類は次の4つで足ります。

① 規制起点のギャップ。 法令、GMP、顧客監査要求、業界標準で明確に要求されているもの。これは個別対応の対象です。ただし条件があり、根拠となる条文・要求事項番号の添付を必須にします。「監査で見られるから」だけでは通しません。実際にやってみると、この条件だけで規制起点を主張する案件の3〜4割が②〜④に再分類されます。

② 商流起点のギャップ。 取引先が指定する帳票様式、納入指示の形式、ラベルの仕様。自社では変えられません。ただしMES本体を改造するのではなく、外側の変換層で吸収するのが原則です。取引先は変わり、様式も変わります。本体に埋め込むと、取引先が変わるたびに改修が発生します。

③ 慣習起点のギャップ。 「昔からこの帳票でやってきた」「この順番でないと落ち着かない」。ここが最大のボリュームゾーンで、Fit to Standardの成否を決めます。原則として業務側を変える判断をしますが、これは現場に負担を押し付ける判断でもあるため、決裁者は工場長クラスに置きます。プロジェクトマネージャーが単独で押し切る構造にすると、必ず運用段階で反発が出ます。

④ 誤解起点のギャップ。 標準機能で実現できるのに、その存在を知らずに出された要望。ベンダーの説明不足であることも、要望側の確認不足であることもあります。丁寧に再説明すれば消えます。分類が判定できない案件は、いったんこの④に置くのがコツです。証明責任を要望側に残せます。

決裁ルールを表にして、キックオフで配る

分類ができたら、処理ルールを表にして関係者全員に配ります。設計工程が始まってから作ると、既に上がっているギャップに引っ張られて中立性を失います。

期限を切ることが本質です。期限のない決裁は、設計工程の最後まで先送りされ、最後にまとめて「時間がないので全部作る」という決着になります。期限を過ぎた案件は自動的に「対応しない」と扱う、というルールまで含めて事前に合意してください。

標準に合わせる「対価」を先に見積もる

Fit to Standardには必ずコストがあります。それを「ゼロ」と説明してプロジェクトを始めると、現場の信頼を失います。対価は主に3つです。

1. 一時的な生産性の低下。 手順が変わる期間、作業時間は必ず伸びます。経験的には、切替後2〜6週間で元に戻り、その後改善に転じます。この期間の生産計画を平常どおり立てているプロジェクトは、立ち上げ直後に必ず火を噴きます。

2. 帳票の見た目が変わることによる社外説明コスト。 取引先へ提出している帳票のレイアウトが変わる場合、事前説明が必要です。これは②商流に分類して営業部門に処理させます。

3. 一部業務の「作り込み断念」。 標準に乗らない業務は、システム外の手作業として残ります。これを隠さず、「システム化しない業務リスト」として明示的に文書化してください。書かないと、後から「MESに入っていない」というクレームの形で出てきます。何を対象外とするかの考え方はMESのスコープをどう切るかに整理しています。

標準を守った結果として起きる、望ましくないこと

Fit to Standardを推奨する立場で書いていますが、副作用も正確に書いておきます。

自社の競争優位が業務プロセスにある場合、それを平準化してしまう危険があります。独自の工程順、独自の検査基準、独自の段取り方法が競争力の源泉である工場は実在します。この場合、標準に合わせることは競争力を捨てることと同義になりえます。

見分け方は単純で、その業務が顧客に対する差別化として説明可能かを問うことです。「うちの検査は他社より厳しい」が顧客に選ばれる理由になっているなら、それは守るべき差別化であり、①規制と同格に扱ってよい。一方で、「昔からこうしている」しか出てこないなら③慣習です。

もう1つの副作用は、ベンダーへの依存が深まることです。標準機能に業務を寄せるほど、その製品を離れられなくなります。契約時にデータの取り出し条件を確認しておかないと、乗り換え時に実質的な人質になります。この論点はMESのベンダーロックインをどう避けるかで扱っています。

Rockwellの2026年7月28日公開の調査（17カ国1,560名）では、MES購買要件の第1位が「統合性」で44%でした。標準機能に寄せる判断は、この統合性を確保する方向に働きます。個別開発が増えるほど、ERP・PLM・品質・OTとの統合は難しくなるためです。同調査でERP・PLM・品質・OTと完全統合できている企業は23%にとどまっており、Fit to Standardは統合率を上げるための現実的な手段でもあります。

よくある質問

現場から「これは規制で必要だ」と言われたとき、どう検証すればいいですか？

根拠文書の該当箇所を提出してもらうのが唯一の方法です。実務では「監査で指摘されたことがある」という説明が最も多く出てきますが、指摘記録の現物があるかを確認してください。記録がある場合は正当な①規制です。記録がなく、記憶に基づく主張である場合は、品質保証部門に照会して裁定します。この照会プロセス自体を決裁ルールに書いておくと、担当者間の対立になりません。

ベンダーが「その機能は標準で対応できます」と言った内容が、後から追加開発だったことがあります。

提案段階の「対応可能」には、標準機能・設定変更・アドオン開発の3種類が混在します。RFPの回答様式で、機能ごとに S（標準機能）／C（設定で対応）／D（開発が必要） の3値を強制的に選ばせてください。そのうえで、Dが付いた項目については工数と金額の内訳を求めます。この様式にすると、口頭の「対応可能」が使えなくなります。

プロジェクト途中でFit to Standard方針に切り替えることはできますか？

可能ですが、切替時点で既に確定した個別開発は原則そのまま残ります。途中から方針を変える場合は、「これ以降の新規ギャップに適用する」と適用範囲を明示してください。既決分まで遡って見直そうとすると、設計のやり直しが発生してスケジュールが崩壊します。誰がこの決定を下せるのかについてはMES導入プロジェクトの体制を参照してください。