「小さく始める」は範囲の話、「小さく作る」は設計の話
MESのスモールスタートが失敗するとき、原因はほぼ例外なく同じです。範囲を絞る判断と、設計を削る判断が、同じ「小さくする」という言葉で混ざっていることです。
- 小さく始める：対象を1ライン・1工程・1拠点に絞る。扱う範囲を限定する判断
- 小さく作る：マスタ構造を簡略化する、コードを直値で埋める、拡張余地を持たせない。設計の抽象度を下げる判断
前者は推奨されます。後者は、2ライン目に展開した瞬間に全面的な作り直しを招きます。
なぜ混ざるかというと、両方とも初期費用を下げるからです。範囲を半分にすれば費用は下がり、設計を簡略化してもやはり下がります。見積書の上では区別がつきません。しかし、範囲を絞った投資は残高が残るのに対し、設計を削った投資は2回目に消えるという決定的な差があります。
削ってよいもの・削ってはいけないものの4つの境界線
実務では、次の4軸で切り分けます。左列は初回スコープから外してよく、右列は初回から作り込む必要があります。
| 軸 | 初回から外してよい（範囲の話） | 初回から設計すべき（設計の話） |
|---|---|---|
| 対象 | 対象ライン、対象品目、対象拠点、シフト | 品目・工程・設備・作業者の識別子の体系 |
| 機能 | 設備自動収集、APS連携、BI、モバイル対応 | 実績データの粒度（工程単位か、ロット単位か、個体単位か） |
| 連携 | ERP連携の自動化、WMS連携、原価連携 | キー項目の対応表（ERPの製造指図番号とMESのオーダーの関係） |
| 運用 | 24時間対応、多言語、権限の細分化 | 時刻の扱い（誰の時計を正とするか、日跨ぎシフトの日付定義） |
この表の右列は、いずれも後から変えると過去データが全部使えなくなる項目です。逆に左列は、後から足しても既存データに影響しません。この違いが「削ってよいか」の判定基準です。
とくに見落とされやすいのが4行目の時刻の扱いです。夜勤で日付をまたぐ工程を「開始日」で集計するのか「終了日」で集計するのかを決めていないと、1ライン目では誰も気づかず、2ライン目のシフト体系が違った瞬間に集計が合わなくなります。しかも過去分は遡って直せません。マスタ設計についてはMESのマスタ設計で詳しく扱っています。
最初のスコープはどう選ぶか
初回の対象工程は、「一番困っている工程」から選びたくなります。しかし実務上は、次の3条件を満たす工程のほうが成功率が高くなります。
- 不良やトラブルが「ある程度」発生している工程。 まったく問題のない工程を選ぶと効果が測定できません。逆に、慢性的に炎上している工程を選ぶと、MES導入の失敗と工程の問題が切り分けられなくなります。
- 記録の受け手が社内にいる工程。 集めたデータを誰も見ない工程を選ぶと、入力が必ず形骸化します。品質保証部門や生産技術が「そのデータを毎週見る」と明言できる工程を選びます。
- 横展開先が実在する工程。 1ライン目にしか存在しない特殊工程を選ぶと、設計の汎用性が検証できません。「同じ構造の工程が他に2つ以上ある」ことを条件にします。
3つ目の数字が、スモールスタートの本質的な難所を示しています。MES自体は93%の企業が持っているのに、全社展開できているのは28%です。多くの企業が「小さく始めた」まま止まっているということです。Rockwellのバイスプレジデント Anthony Murphy氏は「MESの導入はもはや障壁ではない。障壁は全社スケールだ」と述べています。
2ライン目で必ず起きる3つのこと
初回スコープを無事に立ち上げても、2ライン目で以下は必ず起きます。あらかじめ想定しておくかどうかで、対応コストが桁で変わります。
1つ目：同じ名前の工程が、違う意味で使われていたと判明する。 1ライン目で「検査」と定義した工程が、2ライン目では出荷前の全数検査を指していた、というたぐいです。工程マスタの命名規則に「工程の目的」を含める設計にしておくと軽減できます。
2つ目：「うちのラインは特殊だから」という要望が出る。 ここで個別対応を積み上げると、拠点ごとに別システムになります。標準を守るための意思決定の枠組みが必要で、これはFit to Standard を貫くための意思決定で扱っています。
3つ目：1ライン目の運用ルールが、すでに文書と乖離している。 立ち上げ後3〜6か月で、現場は必ず運用を微調整します。これ自体は健全ですが、2ライン目に展開する際の「標準」がどちらなのかを決めないまま進むと、両方が中途半端に混ざります。横展開の直前に、1ライン目の運用を再ドキュメント化する工程を必ず入れてください。
1ライン目にどの工程を選ぶべきか、設計のどこまでを初回に含めるべきかを、貴社の工程構成に即してご提案します。
よくある質問
PoC（実証）とスモールスタートは何が違いますか？
PoCは「検証して捨てる」前提、スモールスタートは「そのまま育てる」前提です。この違いを曖昧にしたまま始めると、捨てるつもりで作ったものが本番運用に居座ります。PoCなら検証項目と終了条件を先に決め、期間終了時に必ず廃棄判断を行ってください。何を検証すべきかはMESのPoCで検証すべき3項目にまとめています。
予算が限られています。設計を先行させると初期費用が上がりませんか？
上がります。おおむね初回投資の10〜20%程度が、将来の横展開のための設計費として上乗せされます。ただしこれは「2ライン目以降の再構築費用の前払い」であり、拠点が3つ以上ある企業では、ほぼ確実に回収できます。逆に、工場が1つで今後も増やす予定がなく、対象工程も広げないと決まっているなら、設計を絞る判断は合理的です。判断にはMESの導入コストの構造理解が前提になります。
クラウド型のSaaS MESなら、スモールスタートの設計問題は起きませんか？
起きます。SaaSが解決するのはインフラと初期費用の問題であって、マスタ設計とデータ粒度の問題ではありません。SiemensがSMB（中小製造業）向けに提供するOpcenter Xのように、モジュール単位で段階導入できる製品は増えていますが、品目コードの体系や実績の粒度は利用側が決める領域です。導入形態の選択についてはクラウドMESとオンプレミスを参照してください。
