「MESを任されたのに、現場・IT・経営がバラバラで、自分だけ板挟みになっている」。こうした悩みには、技術面の検討に加え、業務の目的・権限・役割をそろえる取り組みが必要です。
たとえば、現場は入力の負担、IT部門は接続や保守、経営層は費用と効果を気にしているかもしれません。部署名だけで本音を決めず、本人に懸念と必要な判断を確認するところから始めます。
この記事では、MESとは何かを踏まえたうえで、社内調整の進め方に絞って解説します。「誰に・何を・どの順番で伝えるか」に重きを置いています。
MES社内調整が詰まる「典型的な失敗パターン」
パターン1:現場を後回しにして経営承認だけ取った
経営承認を得たことと、現場の業務変更や運用条件が確認できたことは別です。入力・確認・異常対応を誰が担うか、既存業務とどうつなぐかを、実装前から現場と確認します。
画面が完成しただけでは、運用が成立するとは判断できません。実際の作業と担当、教育、試行で確認する条件を決めます。
現場への説明や意見聴取が不足すると、変更の理由や業務への影響が伝わらず、協力を得にくくなる可能性があります。経営への初期相談を避けるという意味ではなく、現場の確認も並行して計画します。
パターン2:IT部門を最後に呼んだ
接続・認証・セキュリティ審査、サーバーや通信の予算・調達条件を、要件が固まる前にIT部門と確認します。未確認の制約が後から判明すると、構成や日程の見直しが必要になり得ます。
日程への影響は、必要な審査・作業と未解決事項から見積もります。遅れを一つの部署や相談時期だけの責任にせず、担当と判断期限をそろえます。
パターン3:経営層への数字が「感覚」だった
「作業効率が上がる」「品質が安定する」という案には、対象業務、現状の根拠、改善の仕組み、費用と効果の算定条件を添えます。
数値の根拠が不足する部分は、確定した効果として扱わず、試行や見積もりで確かめる計画を示します。承認の条件と必要な追加資料を決裁者に確認します。
現場・IT・経営の関心事を確認する
関係者の懸念と、誰が何を決めるかを確認します。以下は話し合う項目の例で、すべての部署・担当者が同じ考えを持つと決めるものではありません。
現場オペレーターに確認すること
入力が増えるか、誤入力はどう訂正するか、誰が記録を閲覧するかなど、実際の不安を聞き取ります。説明だけでなく、現場の端末で入力と例外処理を試し、作業への影響を確認します。
今のやり方を維持したい理由が、慣れだけとは限りません。納期、品質、作業負荷、既存設備の制約など、変更しにくい条件を確認してください。
仕事がどう変わるかを、決まった仕様と運用に沿って具体的に伝えます。まだ検証していない入力削減や負担軽減を約束せず、試す方法と結果を共有します。
IT部門に確認すること
接続・認証・データ保管・保守の責任と、審査や予算の手続きを早期に確認します。相談が進まない場合も、経験や感情を推測せず、制約・不足資料・担当範囲を聞き取ります。
「まだ検討段階なので、インフラと運用の要件を一緒に整理したい」と相談する方法があります。社内標準、必要な手続き、判断時期を確認し、ベンダーにも同じ前提を渡します。
経営層が見ているもの
経営層には、費用と効果に加え、顧客要求への対応、リスク、実施体制と、今回は何を判断してほしいかを示します。金額に換算できない効果や未確定事項も分けて説明します。
承認に必要な資料は社内基準と案件によって変わります。他社実績を使う場合も、自社との対象・条件の違いを示し、現場での試行や見積もりで確かめる項目を残します。
生産技術担当者の役割は、この三者の言葉を翻訳しながら橋渡しをすることです。現場の困りごとを数字に変えて経営に届け、IT部門には要件を構造化して渡す。この翻訳こそが調整者としての仕事です。
稟議を通す「投資根拠」の作り方
作業時間の短縮と、実際に減る人件費は分けて考えます。同じ人数で対応できる余力が生まれても、給与支出がそのまま減るわけではありません。残業や外注・増員の回避、追加需要に対応する利益など、収支が変わる条件を確認します。
投資根拠は、工数・品質コスト・要求への対応とリスクの3つに整理できます。金額を足す前に、期間と費目をそろえ、同じ作業・不良・損失の二重計上を除きます。導入・移行・教育と、利用料・保守等の継続費用も比較に含めてください。
試算の土台は現場ヒアリングです。「どの作業に何分かかっているか」「不良はどの程度出ているか」を聞いて回ることから始めましょう。削減効果をより説得力のある数字で示したい場合は、OEEによる設備総合効率の考え方も参考になります。見積依頼書の書き方を参考にすると、ベンダーへの費用確認も同時に進められます。
切り口① 削減工数の評価と、実際の収支
削減工数を人件費相当額で評価する計算例です。支出の削減額とは区別します。
年間の工数評価額(円/年)= 1日当たりの削減工数(時間/日)× 時間単価(円/時間)× 年間稼働日数(日/年)
仮に、日報の記入・転記が1人30分/日、対象10人、時間単価2,500円/時間、年間240日とします。現状は5時間/日で年間300万円相当です。この対象作業を50%減らせれば、削減は1人15分/日、全体で年間600時間、評価額は150万円/年です。50%は説明用の仮定で、自社の測定と試行で確認します。
稟議書には、創出した時間の使い道と、実支出が変わる条件を記載します。増産余力を効果に入れるなら需要・他工程の能力等も確認します。表現を変えるだけで現金効果が生じるわけではありません。
| 項目 | 単位 | 数値例 | 備考 |
|---|---|---|---|
| 削減前の対象工数(1人あたり) | 分/日 | 30分 | 日報記入・転記作業 |
| 対象人数 | 人 | 10人 | 対象ラインの作業員数 |
| 時間単価(時給換算) | 円/時間 | 2,500円 | 社会保険含む実質コスト |
| 年間稼働日数 | 日 | 240日 | 休日・定修除く |
| 工数削減率(仮定) | % | 50% | 測定と試行で確認する仮定 |
| 年間の工数評価額(試算) | 円/年 | 1,500,000円 | (30分÷60)×10人×2,500円×240日×50%=1,500,000円 |
切り口② 品質コストの削減
品質に関わる費用は、予防・検査、不良廃棄や手直し、外部のクレーム対応などに分けて集計します。売上の一定割合をそのまま削減可能額にせず、自社の対象費目と期間、MESで変えられる作業・判断を確認します。品質コストのPAFモデルも参考になります。
以下は、不良がすべて廃棄となる場合の原価相当額の試算例です。手直しの場合は実際の材料・作業等を別に集計します。
年間の廃棄原価相当額の減少(円/年)= 廃棄率 × 月間生産数量(個/月)× 廃棄1個の原価(円/個)× 廃棄率の相対的な改善率 × 12(月/年)
仮に廃棄率0.5%、月産10,000個、廃棄1個の原価10,000円、廃棄率を相対的に30%改善すると、0.5%から0.35%になり、原価相当額の減少は「0.005 × 10,000 × 10,000 × 0.30 × 12 = 180万円/年」です。これは実支出が180万円減る保証ではありません。固定費を含む原価と実際に回避できる材料費・外注費等を分け、切り口①との労務費の重複を除きます。
効果の対象、測定方法、実現する条件、検証時期を示します。想定より効果が小さい場合や運用費が増える場合も試算し、過大な約束を避けてください。
切り口③ 要求への対応とリコールリスク
記録・追跡が必要な範囲は、製品、販売先、適用される法令・規格、顧客との契約を確認して決めます。必要な能力と、それをMESで実装するかは分けて考えます。たとえば食品トレーサビリティの手引きでは、紙の記録を含む手段が整理されています。個別契約で特定システムが指定される場合は、その条件も照合してください。
リコールへの備えは、対象製品・回収範囲・数量と、回収・廃棄・告知等の費用を想定して検討します。記録と追跡が調査・回収範囲の判断を支援しても、事故そのものを必ず防ぐわけではありません。1件の被害額全額をMESの毎年の便益にせず、発生条件・頻度と導入前後の損失差を裏付けられる範囲で扱います。
法令・顧客要求への対応は、収益増とは別の導入目的です。ただし、目的だけで社内のROI試算が免除されるとは決まりません。必要な要求を満たす案の費用と残るリスクを比較し、社内の審査基準と承認者を確認します。
MES導入コストの規模感(読者が稟議に使えるように)
費用は接続・機能・移行・教育と継続費用の対象範囲をそろえて見積もります。工数評価額と現金効果を分け、回収試算には、実際に増減する収支を同じ期間で整理して使います。
- クラウド型:初期設定・接続・移行費と、利用者数・設備数・データ量等に応じる利用料を確認します。
- パッケージ型:ライセンス、設定・追加開発、接続、教育、保守・更新の範囲を見積もります。
- 複数拠点への展開:共通化できる部分と拠点固有の改修を分け、現地試験、教育、運用支援の費用も積み上げます。
方式名や工場規模だけで金額は決まりません。同じ対象・機能・比較期間を指定し、見積条件と除外項目をそろえて比較します。
合計効果と費用は、対象範囲と比較期間をそろえ、二重計上を避けて示します。回収期間を計算する場合は、初期費用、運用費、実現できる効果の前提と変動幅を添え、自社の投資判断基準に照らします。特定の年数なら承認されるとは決めません。
IT部門と早期に役割をそろえる
審査・接続・運用の条件が未確認のまま要件を固定しないよう、相談を計画に入れます。
要件やベンダーを確定する前に、IT部門と確認事項・担当・判断時期を整理します。最初の週に相談するのも一案ですが、社内の手続きと案件に合わせます。
事後確認だけでは、審査・申請・予算確保の時間が足りなくなる可能性があります。必要な日程と依存する作業を先に確認します。
早期相談では、まだ決まっていない条件も示し、設計・保守を誰が担うかを一緒に決めます。
ネットワーク、データ保存、遠隔接続、権限、障害対応と復旧、保守・更新の責任分担を文書にします。下のリストは初期確認用で、完全なセキュリティ設計の代わりではありません。設備導入時のインフラ要件の文書化も参照してください。
IT部門との初期確認チェックリスト
- ネットワーク接続方式(有線LAN/Wi-Fi/OTネットワーク分離の有無)
- データ保存先(クラウド/社内サーバー/ベンダークラウド)の方針確認
- 遠隔接続の必要範囲、許可・認証・ログ・無効化の手順
- セキュリティ審査・ベンダー認定の要否と審査リードタイム
- 既存システム(ERP・PLCなど)との連携インターフェース確認
- 障害時の対応責任分担(ベンダー対応範囲・社内IT対応範囲)
- サーバー・ライセンス追加に伴う予算申請の手続き
- データ・設定のバックアップ、復旧目標と復元試験の担当
- 閲覧・入力・訂正・管理の権限、アカウント発行・停止の責任
- 更新・パッチの影響確認、停止可能時間、承認と問題時の復旧手順
現場へ仕事の変化と利用目的を説明する
機能名に加え、仕事がどう変わるか、どの負担が増減するか、誰に相談できるかを説明します。必要な機能説明も、担当者が使う場面と結びつけます。
以下は文案です。データの利用目的・閲覧範囲・評価利用、訂正方法、入力が減る作業等を関係部門と決め、実際に成立する内容だけを使ってください。未確定の事項は確認中と伝えます。
「監視ツールではないか」という不安に対して:「誰がどれだけ作業したかを管理するためではなく、ラインのボトルネックを見つけるために使います。個人の評価には使いません」と伝える。
「入力が増えるのでは」という不安に対して:「今は紙に書いてから別の場所に転記しているが、それが1回の入力で済むようになります」と具体的に説明する。
「ミスしたデータが残るのでは」という不安に対して:「修正履歴は残りますが、訂正前提の設計なので、入力ミスは普通に直せます。責任追及のためのシステムではありません」と伝える。
全体説明の前に現場リーダーへ相談し、疑問や制約を聞く方法があります。リーダーの理解を全員の合意とみなさず、現場の意見を反映する機会と担当を決めます。
その場で回答できない疑問は、確認事項・担当・回答予定を記録して後日返します。個別の相談と、全員に関わる仕様・運用の決定を分けて共有します。
| 機能・決定だけの説明 | 仕事の変化を伝える例 | ポイント |
|---|---|---|
| 「作業実績をリアルタイムで収集します」 | 「進捗が画面で見えるので、呼びに行く手間がなくなります」 | 自分へのメリットに変換 |
| 「トレーサビリティを確保します」 | 「履歴を調査する手順を決めます。記録の利用目的と閲覧できる人も説明します」 | 不安の先取り |
| 「入力項目を標準化します」 | 「今バラバラな記録用紙を1画面にまとめます。入力の手間は今より減ります」 | 具体的な変化を示す |
| 「稼働率を見える化します」 | 「稼働状況を確認し、現場と原因を調べて割り当ての見直しに使います」 | 監視・圧迫感を与える表現を避ける |
| 「上から導入を決定しました」 | 「現場の皆さんの意見を聞きながら、一緒に使いやすいシステムを作りたいと思っています」 | 意見を反映する方法を示す |
MES導入の社内調整スケジュール|フェーズ別タイムライン
以下は4段階に分けた進め方の例です。月数は計画を考えるための仮置きで、標準所要期間ではありません。社内の予算・審査、対象範囲、関係者の稼働と完了条件に合わせ、並行できる確認は早期に進めます。
フェーズ0:情報収集と課題の言語化(1〜2ヶ月)
まず現場に張りつき、「どの作業に何分かかっているか」を記録します。この段階で六大ロスの分析手法を活用すると、課題を構造的に言語化しやすくなります。IT部門にも「相談」として声をかけ、インフラ要件の初期確認を進めます。ベンダーへの設備導入の全体フローの理解もここで行います。
目標は、「現場の課題」と「解決の方向性」を1枚のA4にまとめることです。最低限、①課題を数字で(○○作業が1人あたり30分/日など)、②MESで変えたいこと1〜2行、③IT部門に確認すべき点の3つが入れば、フェーズ1の経営説明の入口資料として機能します。
フェーズ1:経営への概算提案(1ヶ月)
概算でも、測定値と仮定、効果の幅、不足データと次に検証する時期を示します。根拠がない数値を「最低限保証できる効果」とは説明しません。
方向性の確認と、発注・予算執行の承認は分けます。何を判断してもらう場なのか、どの権限の承認が必要かを明示します。
フェーズ2:関係者との要件合意(2〜3ヶ月)
IT部門とのインフラ要件確認、現場リーダーへの先行説明、ベンダーへの要件ヒアリングを並行して進めます。この段階で「誰が何を決めるか」の役割分担を明確にしておくことが重要です。
稟議書は社内手続きに合わせて作成し、未確定事項の担当と解消期限、正式契約へ進む条件を示します。
フェーズ3:正式承認と実装フェーズ移行(1ヶ月)
必要な承認後に契約・計画・体制を確定します。進捗共有の頻度は案件に合わせ、変更や課題が出たときの判断・連絡方法も決めます。稼働後の活用はMESデータの改善サイクルを参照してください。
| フェーズ | 期間 | 現場 | IT部門 | 経営層 |
|---|---|---|---|---|
| フェーズ0 情報収集 |
1〜2ヶ月 | 現場ヒアリング 作業時間・課題の記録 |
初期相談(早期接触) インフラ要件の初期確認 |
方針・権限の初期確認 |
| フェーズ1 概算提案 |
1ヶ月 | (情報共有のみ) | 概算インフラ要件の整理 ベンダー審査要否の確認 |
方向性の確認説明 仮定・幅のある試算を提示 |
| フェーズ2 要件合意 |
2〜3ヶ月 | 現場リーダーへ先行説明 要件へのフィードバック |
インフラ要件の詳細合意 セキュリティ審査・申請 |
稟議書レビュー 投資対効果の最終確認 |
| フェーズ3 正式承認 |
1ヶ月 | 全員説明会・合意形成 進捗・変更の共有 |
正式申請・環境準備 ベンダー接続テスト |
稟議承認・予算確定 正式契約への移行 |
まとめ:今週中にできる3つのアクション
この記事を読んで「自分の状況に近い」と感じた方は、まず以下の3つを動かしてください。
① IT部門に「相談」として声をかける 要件が固まる前に、IT部門へ確認事項と担当を相談します。現場や経営への初期相談も、判断が必要な時期に合わせて並行します。
② 現場の作業時間を1日だけ記録する まず1日の観察から始める案です。作業の開始・終了、品種、人数、数量と稼働条件を記録します。その日が年間を代表するとは限らないため、年換算には日間変動や対象期間を確認し、必要な追加観察を計画します。
③ 経営層への「方向性確認」を15分だけ予約する 方向性と次の検討範囲を相談する時間を設けます。15分は一例で、必要資料と判断内容に応じて調整してください。
関係者の懸念を聞き、事実・仮定・未確定事項を分けて共有し、判断する人と担当する人をそろえることが調整の基本です。担当者一人で抱えず、必要な協力と権限を確認して進めてください。
参考資料
- HSE:変更時の情報共有・意見聴取:関係者への説明と支援の参考。日本企業の承認手順を定めるものではありません。
- NIST HB 135e2025 6.1:同じ期間の費用・便益と比較対象をそろえる考え方。米国のエネルギー投資向けで、MESの相場や承認基準ではありません。
- 食品トレーサビリティシステム導入の手引き 第2版第2刷(2008年)、5章・7章・資料A:記録手段と運用の参考。現行の法令・顧客要求は対象に応じて別途確認します。
- NIST SP 800-82 Rev.3 3.3.8–3.3.9、6.2.10:OTの障害対応・復旧と遠隔アクセスの参考。