基幹システム刷新は、単に古いシステムを新しいERPに置き換える話ではありません。
営業、生産、品質保証、購買、物流、会計。部門ごとに困りごとは違い、使っている言葉も少しずつ違います。さらにERPだけでなく、MES（製造実行システム）、LIMS（品質管理システム）、CRM、MDM、EDI、BIなど周辺システムまで関係してくると、要件定義は一気に「デジタルトランスフォーメーション」の中核テーマになります。
当社が関わっている製造業の大規模な基幹システム刷新でも、複数システムの同時導入・再構築に加え、マスターやデータ連携、アドオン削減、ベンダーとユーザー部門の合意形成などが複雑に絡み合います。守秘のため固有名詞は伏せますが、現場で起きる悩みはかなり共通しています。
要件がまとまらないのは、現場がわがままだからではない
基幹システム刷新でよくある見方に、「現場が要望を出しすぎるから要件がまとまらない」というものがあります。もちろん、個別最適な要望が増えすぎることはあります。
ただ、現場側だけの問題として見ると、肝心な構造を見落とします。現場は、日々の業務を止めないために、例外処理や手作業を抱えています。Excelで補っている管理表、担当者だけが知っている確認手順、取引先ごとの細かい対応などです。新しいシステムに移るとき、現場はそれらが消えてしまう不安を持ちます。
【現場の事例】長桁の管理コードとシステム制限の衝突
ある製造業のプロジェクトでは、現場が製品ロット番号の各桁に「製造工場」「使用設備」「特定の品質条件」など多くの属性情報を持たせて長桁で管理していました。しかし、新システムの標準機能では入力桁数に制限があり、情報を切り離す必要が生じました。現場は「これまでの管理ができなくなり、誤出荷に繋がる」と強く抵抗しました。これは決して現場のわがままではなく、長年品質を担保してきた現場の防衛本能であり、ビジネスリスクの表現そのものなのです。
PMOがまず見るべきなのは、要望の数ではありません。その背後にある「システム化によって現場が恐れている業務リスク」です。
Fit&Gapで見落とされる、顧客別要件と品質管理の複雑さ
ERP導入ではFit&Gapという言葉がよく使われます。標準機能に合うもの、合わないものを整理する作業です。しかし実務では、Fit&Gapを機能一覧の差分表として扱うだけでは足りません。大事なのは、そのGapが何を意味しているかです。
【現場の事例】「備考欄で対応可能（Fit）」の罠
顧客ごとの「特殊な包装指示」や「特定ロットの引き当て指定」といった取引条件について、ベンダーの機能比較表では「標準の備考欄にテキスト入力すれば対応可能（Fit）」と判定されがちです。しかし、テキスト情報ではシステムによる在庫の自動引き当てや、後工程への作業指示の自動連携ができません。結果として、現場はシステム画面を目視確認しながら手作業で在庫を割り当てるという非効率な「人間系運用」を強いられることになります。
ここで注意したいのは、これらが単なる特殊処理ではないということです。海外顧客、国内の代理店、国内の直接取引先など、BtoBの現場では顧客ごとの要求に丁寧に応えること自体が競争力になっている場合があります。それを「標準に合わないから削る」とだけ見ると、事業の強みまで削ってしまうおそれがあります。
特に品質管理システムが関係する場合、品質判定前の出荷判断や顧客別の追加検査といった品質を守るための業務要件が、ERPの在庫引当や出荷指示のロジックを一気に複雑にします。ERP、MES、LIMS、MDM、EDIの間で、どのデータをどのシステムが正として持ち、どのタイミングで連携するのか。ここを曖昧にしたまま設計を進めると、後工程で「業務が回らない」「データが合わない」という手戻りが起きます。
Fit&Gapの本当の論点は、機能差分ではなく業務リスクです。PMOは、標準機能と現場業務の間に立ち、業務効率、品質、コスト、顧客対応力のトレードオフを一つずつ言語化する必要があります。
標準化は、現場に手作業を押し付けることではない
基幹システム刷新では、アドオンを減らし、できるだけ標準機能に合わせることが重要です。これは間違いありません。アドオンを増やしすぎると、初期費用だけでなく、将来の保守やバージョンアップの負担も大きくなります。
一方で、現場から見ると、ベンダーの言う「Fit to Standard」が、単に「システムがやってくれないので、人が手入力やExcelで二重管理する」ことに見える場合があります。それでは業務改革ではなく、業務負荷の移転です。
また、アドオン開発費を抑える圧力が強い中では、ベンダーは標準機能に寄せようとし、現場は業務が回らなくなることを懸念します。その間で、PMOやコンサルタントは要件を一件ずつ棚卸ししながら、本当にシステムで持つべきもの、業務を変えるべきもの、運用で吸収できるものを見極めていきます。
標準化とは、現場に我慢を求める合言葉ではありません。会社としてどの業務を標準化し、どの顧客要件を競争力として残し、どのリスクを許容するのかを決めることです。この線引きを曖昧にしたまま「標準でお願いします」と言っても、現場の納得は得られません。
PMOの仕事は、部門間の痛みを見える化し、決める場をつくること
要件定義の難しさは、資料をきれいにまとめることだけではありません。むしろ難しいのは、部門間の痛みを見える化し、決めるべき人が決められる状態をつくることです。
責任分界や入力主体をめぐって、営業、生産、品質保証、物流、会計の間で利害がぶつかることがあります。ある部門の要望を残すと、別の部門の入力負荷が増える。アドオンを削ると、現場の運用変更が必要になる。データ連携を自動化すれば便利ですが、例外処理の責任者を決めなければなりません。
こうした論点は、最後の承認会議だけでは決まりません。PMOが日々の設計会議の中で前提のズレを拾い、誰に負荷がかかり、どのリスクを許容し、どの判断を経営に上げるべきかを整理する必要があります。きれいなフレームワークだけでは動かない場面で、根回しやファシリテーションを含めた泥臭い意思決定支援が必要になります。
PMOが先に整えるべきものは、大きく3つです。
- 要件を評価する基準です。法令・品質上必須なもの、顧客対応力として残すもの、標準機能に業務を合わせるもの、運用で吸収するものを分ける軸が必要です。
- 意思決定の階層です。現場担当者間で調整する課題、部門長レイヤーで合意する課題、経営判断が必要な課題を切り分けます。
- データと業務プロセスの全体像です。業務フローだけでなく、マスター、トランザクション、外部連携、レポートまで含めて、どこで何が決まり、どこに影響するのかを追えるようにします。
最近では、こうした情報整理にAIエージェントを組み込む工夫も進んでいます。ClaudeやCodexなどを使い、会議メモ、Fit&Gap資料、課題一覧、業務資料を整理し、論点の抜け漏れや前提のズレを拾う。実際のプロジェクト現場でも、ユーザー企業、コンサルタント、PMOがそれぞれの立場で活用する場面が出てきています。
もっとも、AIエージェントを入れれば要件定義が自動的に進むわけではありません。何をAIに整理させ、何をPMOが判断し、どこを経営に上げるのか。その設計がなければ、情報量が増えるだけで、意思決定はかえって難しくなります。
基幹システム刷新は、ITプロジェクトである前に業務改革です。要件がまとまらないときは、「現場の要望が多すぎる」と見る前に、要件を評価する軸、痛みを見える化する場、トップを巻き込んで決める仕組みが整っているかを確認してみるとよいかもしれません。
次回は、こうしたDXプロジェクトのPMO実務に、AIエージェントをどのように組み込めるのかを整理します。
