体制図より先に「決裁の粒度」を書く
MESプロジェクトの体制検討は、たいてい組織図に名前を並べるところから始まります。しかし実際にプロジェクトを止めるのは、人がいないことではなく、目の前の論点を誰が単独で決めてよいのかが不明なことです。
要件定義の期間中、決定が必要な論点は数百件出ます。そのうち経営判断が必要なものは10件に満たず、残りは「工程Aの実績入力を工程完了時にするか作業開始時にするか」といった業務レベルの選択です。これを毎回持ち帰って部門長の承認を取っていると、要件定義は確実に予定の2倍かかります。
したがって最初に文書化すべきは体制図ではなく、次の3行です。
- 業務ルールの変更を伴わない設計判断は、業務側リーダーが単独で決定する
- 業務ルールの変更を伴う判断は、部門横断の定例会で決定する（持ち帰りは1回まで）
- 費用・スケジュール・スコープに影響する判断のみ、ステアリングコミッティに上げる
この3行を、キックオフの資料の最初のページに置いてください。体制図はそのあとで構いません。
5つの役割と、それぞれが持つ決定権
MES導入に最低限必要な役割は5つです。人数ではなく役割の話であり、企業規模によっては1人が2つを兼ねます（兼ねてはいけない組み合わせは後述します）。
| 役割 | 主な責任 | 単独で決めてよいこと | 決めてはいけないこと |
|---|---|---|---|
| エグゼクティブスポンサー | 投資判断、部門間の利害調整 | 予算、スコープの増減、リリース可否 | 画面や帳票の仕様 |
| プロジェクトマネージャー | 進捗、課題、ベンダー管理 | 課題の優先順位、会議体の運営 | 業務ルールの変更 |
| 業務側リーダー（生産管理・品質） | 業務要件の確定 | ルール変更を伴わない設計判断 | 予算・スケジュールの変更 |
| IT側リーダー | 基盤、連携、セキュリティ、非機能 | 技術方式の選択 | 現場運用の可否判断 |
| 現場キーパーソン（各ライン） | 実運用の検証、現場への展開 | 現場手順の細部 | 全社標準の変更 |
この表で重要なのは右の2列です。「決めてはいけないこと」を明示していない体制は、必ずどこかで越権と手戻りを起こします。典型的なのは、IT側リーダーが良かれと思って現場の入力タイミングを決めてしまい、稼働後に「その順番では作業できない」と現場から拒否されるケースです。
兼務してはいけない2つの組み合わせ
人員に余裕のない企業では兼務が前提になります。兼務そのものは問題ありませんが、次の2つだけは避けてください。
① プロジェクトマネージャーと業務側リーダーの兼務。 この2つは利害が対立します。PMは納期を守る責任を負い、業務側リーダーは業務が回る要件を通す責任を負います。同一人物が兼ねると、納期が迫った局面で必ず要件が削られ、その判断が誰にも見えないまま進みます。稼働後に「そんな仕様だとは聞いていない」が起きる典型的な経路です。
② IT側リーダーとベンダー側SEの実質的な兼務。 自社に技術者がおらず、ベンダーのSEが技術判断を全部引き受けている状態を指します。この構成では、見積の妥当性を誰も検証できません。ベンダーが不誠実だという話ではなく、発注側に判断材料が残らないという構造の問題です。最低でも、連携方式とデータ保持方針だけは自社で判断できる人を置いてください。
工数はどこに、どれだけ必要か
体制を組むときに最も見誤られるのが、業務側の工数です。ベンダー費用の見積は精緻に作られる一方、自社側の投入工数は「通常業務のかたわらで」と扱われがちで、これが要件定義の遅延に直結します。
目安として、要件定義から稼働までの期間中に必要な自社側の関与は次のようになります（サオスの導入支援経験にもとづく目安であり、公表された統計ではありません）。
- 業務側リーダー：専任に近い関与。少なくとも業務時間の5割
- IT側リーダー：業務時間の3〜5割
- 現場キーパーソン：通常期は1割、テスト期と移行期は5割以上
- プロジェクトマネージャー：規模により3割〜専任
この工数を確保できないなら、スコープを削るのが正しい対応です。MESのスコープをどう切るかで扱うとおり、体制の制約はスコープの制約として扱わなければ、どこかで品質に転嫁されます。
稼働後の体制を、稼働前に決めておく
プロジェクト体制は稼働で解散しますが、MESは稼働してからのほうが長く生きます。カットオーバー前に、次の3点を文書で決めておいてください。
- マスタの登録・変更を誰が承認するか。 品目や工程の追加は日常的に発生します。ここを決めずに稼働すると、現場が自由にマスタを増やし、半年でコード体系が崩れます
- 不具合と改善要望を切り分ける窓口は誰か。 稼働直後は両者が混ざって上がってきます。切り分けができないと、ベンダーへの問い合わせが「全部が不具合扱い」になり、保守契約の枠を超えます
- バージョンアップの判断を誰がするか。 3年に1度は必ず来ます。MESのバージョンアップ戦略を見据えて、担当を空席にしないでください
プロジェクトの成果物として「稼働後の運用体制表」を納品物リストに入れておくと、この3点は自然に決まります。逆に納品物にしないと、まず決まりません。
よくある質問
情報システム部門がない中小企業でも、この体制は必要ですか？
役割は必要ですが、人数は圧縮できます。実務上は、経営者がスポンサー、生産管理の責任者が業務側リーダー兼PM、現場のキーパーソン2名、という4人体制が最小構成です。欠けやすいのはIT側リーダーですが、ここは無理に社内で埋めず、ベンダーとは別の第三者に技術レビューだけを依頼する方法があります。判断材料が社内に残ることが目的なので、常駐は不要です。
ベンダー選定の前に体制を作るべきですか、選定後でよいですか？
選定の前です。理由は2つあります。第一に、RFPを書くには業務側の要件を確定させる必要があり、それを決める人が決まっていなければRFPが書けません。第二に、ベンダーは提案時に必ず「貴社側の推進体制」を前提条件として置きます。この前提が空欄のまま契約すると、遅延の責任分界が曖昧になります。
現場が非協力的で、キーパーソンを出してもらえません。
それはプロジェクトの問題ではなく、投資判断が現場に説明されていない状態です。MESは現場の入力負荷を確実に増やす局面があり、その見返りが説明されていなければ協力は得られません。体制を作る前に、チェンジマネジメントの観点で「誰の何が楽になるのか」を工程単位で言語化してください。それができないうちに人を出させても、形だけの参加に終わります。
