「MESを任されたのに、現場・IT・経営がバラバラで、自分だけ板挟みになっている」。こうした悩みには、技術面の検討に加え、業務の目的・権限・役割をそろえる取り組みが必要です。

たとえば、現場は入力の負担、IT部門は接続や保守、経営層は費用と効果を気にしているかもしれません。部署名だけで本音を決めず、本人に懸念と必要な判断を確認するところから始めます。

この記事では、MESとは何かを踏まえたうえで、社内調整の進め方に絞って解説します。「誰に・何を・どの順番で伝えるか」に重きを置いています。


MES社内調整が詰まる「典型的な失敗パターン」

社内調整で確認したい3つの失敗パターン
パターン1
現場を後回し
経営承認に加え、現場の担当・操作・教育・試行条件を確認
パターン2
IT部門を最後に呼んだ
要件確定前に審査・接続・予算・必要日程を確認
パターン3
根拠が「感覚」だった
費用・効果の根拠と未確定事項、必要な判断を明示

パターン1:現場を後回しにして経営承認だけ取った

経営承認を得たことと、現場の業務変更や運用条件が確認できたことは別です。入力・確認・異常対応を誰が担うか、既存業務とどうつなぐかを、実装前から現場と確認します。

画面が完成しただけでは、運用が成立するとは判断できません。実際の作業と担当、教育、試行で確認する条件を決めます。

現場への説明や意見聴取が不足すると、変更の理由や業務への影響が伝わらず、協力を得にくくなる可能性があります。経営への初期相談を避けるという意味ではなく、現場の確認も並行して計画します。

パターン2:IT部門を最後に呼んだ

接続・認証・セキュリティ審査、サーバーや通信の予算・調達条件を、要件が固まる前にIT部門と確認します。未確認の制約が後から判明すると、構成や日程の見直しが必要になり得ます。

日程への影響は、必要な審査・作業と未解決事項から見積もります。遅れを一つの部署や相談時期だけの責任にせず、担当と判断期限をそろえます。

パターン3:経営層への数字が「感覚」だった

「作業効率が上がる」「品質が安定する」という案には、対象業務、現状の根拠、改善の仕組み、費用と効果の算定条件を添えます。

数値の根拠が不足する部分は、確定した効果として扱わず、試行や見積もりで確かめる計画を示します。承認の条件と必要な追加資料を決裁者に確認します。


現場・IT・経営の関心事を確認する

関係者の懸念と、誰が何を決めるかを確認します。以下は話し合う項目の例で、すべての部署・担当者が同じ考えを持つと決めるものではありません。

現場オペレーターに確認すること

入力が増えるか、誤入力はどう訂正するか、誰が記録を閲覧するかなど、実際の不安を聞き取ります。説明だけでなく、現場の端末で入力と例外処理を試し、作業への影響を確認します。

今のやり方を維持したい理由が、慣れだけとは限りません。納期、品質、作業負荷、既存設備の制約など、変更しにくい条件を確認してください。

仕事がどう変わるかを、決まった仕様と運用に沿って具体的に伝えます。まだ検証していない入力削減や負担軽減を約束せず、試す方法と結果を共有します。

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分は一例で、必要資料と判断内容に応じて調整してください。

関係者の懸念を聞き、事実・仮定・未確定事項を分けて共有し、判断する人と担当する人をそろえることが調整の基本です。担当者一人で抱えず、必要な協力と権限を確認して進めてください。

参考資料