はじめに
基幹システム刷新プロジェクトでは、業務部門とIT部門（情報システム部門）の対立が、プロジェクトを停滞させる大きな要因になることがあります。「IT部門は現場のことをわかっていない」「業務部門はシステムの制約を理解してくれない」——こうした対立構造を防ぐためには、プロジェクト体制そのものの設計に工夫が必要です。
対立が起きやすい構造的な背景
業務部門とIT部門は、そもそも評価される軸が異なります。業務部門は自部門の業務効率や成果で評価され、IT部門はシステムの安定稼働やコスト管理で評価されることが一般的です。この評価軸の違いが、プロジェクトにおける優先順位の違いとして表面化します。業務部門は「自分たちの業務がやりやすくなること」を優先したいのに対し、IT部門は「システム全体の整合性や保守性」を優先したい、という構造的なズレが生まれやすいのです。
このズレを放置したまま進めると、要件定義の段階で「現場の要望」対「システムの制約」という対立構図が固定化し、建設的な議論が難しくなります。
対立を防ぐプロジェクト体制のポイント
① 業務部門とIT部門を「対立する当事者」ではなく「共同の責任者」として体制に組み込む
プロジェクト体制図を作る際、業務部門とIT部門をそれぞれ独立した窓口として配置するのではなく、両部門から共同でプロジェクトオーナーを立てる、あるいは主要な意思決定を両部門の合議で行う体制にすることで、「対立する相手」ではなく「同じプロジェクトの責任者」という関係性を作りやすくなります。「誰が決めるのか」が決まっていないプロジェクトは必ず迷走する｜RACIという考え方で触れたように、誰が実行責任を持ち、誰が最終承認するのかを明確にしておくことが、対立の火種を減らします。
体制図・RACI表のテンプレートは、noteで配布しています。業務部門とIT部門の役割分担を明文化する際の土台として活用いただけます。
② 「翻訳者」の役割を置く
業務部門の言葉とIT部門の言葉は、同じ日本語でも意味する粒度やニュアンスが異なることがあります。両部門の間に立ち、業務要件を技術的な言葉に、技術的な制約を業務的な言葉に「翻訳」できる役割（PMOやブリッジ人材）を置くことで、直接のコミュニケーションで生じる摩擦を減らせます。
③ 対立が起きた際のエスカレーションルートを事前に決めておく
どれだけ体制を整えても、意見の対立が完全になくなるわけではありません。重要なのは、対立が起きた際に誰がどう最終判断を下すのかというエスカレーションルートを、プロジェクト開始前に決めておくことです。これが決まっていないと、対立がそのまま放置され、プロジェクトの停滞につながります。基幹刷新プロジェクトにおける経営層の関わり方で触れた、経営層が最終判断者として機能する体制が、ここで活きてきます。
定例会議の設計も対立防止に影響する
業務部門とIT部門が別々の会議体で報告を上げる体制だと、情報の非対称性が生まれ、対立の温床になります。できる限り、両部門が同じ場で進捗や課題を共有する定例会議を設計し、互いの状況をリアルタイムで把握できるようにしておくことをおすすめします。
まとめ
業務部門とIT部門の対立は、評価軸の違いという構造的な背景から生まれます。両部門を共同の責任者として体制に組み込み、翻訳者の役割を置き、対立時のエスカレーションルートを事前に決めておくことが、対立を防ぎ、建設的にプロジェクトを進めるための体制づくりのポイントです。
執筆者プロフィール：SIer（元請け）とITコンサルファーム（発注側支援）、両方の立場でプロジェクトに従事（通算9年）。要件定義からベンダーマネジメントまで一貫して対応し、基幹システム刷新・DX推進プロジェクトに多数従事。
コメント