IT部門・情シスの拡大期に起きる「運用課 vs DX推進課」の対立構造をどう乗り越えるか？

対立する2つの課

「新システムの運用は引き受けられません」
「なぜもっと協力的に動いてくれないんですか」

ある企業で、情シス部長が頭を抱えていました。

その情シスは、大きく2つの課に分かれています。「システム運用課」と「DX推進課」です。

システム運用課は、ヘルプデスク、インフラ管理、現行システム運用を主に担当しています。日々の問い合わせが多く、システムトラブルが発生すれば対応が最優先となるため、慢性的に残業が多くなっています。

一方、DX推進課は、新システム導入のプロジェクト活動を行っています。プロジェクトには波があるため忙しい時期もありますが、比較的タスクをコントロールしやすく、定時で帰る人も多い状況です。

この2つの課の課長同士が、激しく対立していました。

DX推進課長は、システム運用課に対してこう不満を持っています。
「毎日の残業は、ダラダラと仕事をして生産性が悪いからでは？」
「ヘルプデスクで雑談しているのをよく見る。もっと人数を減らせるはず」
「新システムを導入し、運用を引き継ごうとしたら多忙を理由に拒否される」

対するシステム運用課長は、こう反発します。
「ヘルプデスクだけでも大変なのに、PCやスマホのデバイス管理からセキュリティ強化、現行システム運用まで手一杯だ」
「導入経緯も知らず、バグだらけのシステムを押し付けられても困る。仕様に詳しいDX推進課が運用まで見るのが効率的ではないか」
「新システム導入は華々しくて加点評価されるのに、我々はトラブルが起きるたびに減点される。不公平だ」

情シス部長は、他部署からローテーションで配属されてきたばかりで、情シスの状況を詳しく把握していません。しかし、両者の言い分は痛いほどよくわかります。

新システムが増える以上、どちらかに運用負担が積み上がっていきます。また、プロジェクトが得意なメンバーもいれば、定型的なルーティンを好むメンバーもいます。それぞれの特性に応じてタスクを割り当てないと、もったいないとも感じています。

これは、情シス拡大の過渡期で避けては通れない「あるある構造」です。

この対立構造に対して、どのように整理し、対策していけばよいのでしょうか？

原因は感情論ではなく「構造」にある

まず、現状を客観的に整理してみます。

業務量で見ると、システム運用課はシステムが増えるほど累積で増えていきます。一方のDX推進課は、プロジェクトが完了すれば一区切りつきます。

感情面で見ると、システム運用課は「押し付けられている」と感じ、DX推進課は「非協力的に見える」と感じています。

つまり、DX推進課が新しいシステムを増やすほど、システム運用課の恒常業務が積み上がる「負の構造」になっているのです。このままでは、運用課は防衛的になり、DX推進課は「抵抗勢力」と見なし、部門内の対立が深まるばかりです。

ここで情シス部長が最初にやるべきことは、どちらかの課長を叱ることではありません。

「事実ベース」で現状を把握することです。

両課のタスクを棚卸しし、一覧化して各工数を把握します。ここで重要なのは「残業が多い＝非効率」と決めつけないこと。一方で「忙しい＝すべて正当化される」とも考えないことです。

新システムは誰が引き継ぐ？

では、新システムの運用は、DX推進課から運用課に引き継ぐべきなのでしょうか？

本番稼働直後は、品質が不安定でトラブルも多発し、迅速な対応が要求されます。そのため、システムに最も精通した導入担当者、つまりDX推進課が対応するべきです。

しかし、この運用をDX推進課に永続化させると危険です。
理由は3つあります。

① 属人化
その人しか仕様や経緯を知らない状態になります。

② 新規プロジェクトの阻害
過去のシステムの面倒を見るほど、新しいDX案件に使える時間が減っていきます。

③ 導入するほど仕事が増える構造
自ら保守負担を増やすことになるため、DX推進課が新しい取り組みに消極的になってしまいます。

したがって、DX推進課による運用は、本番稼働後の「一定期間だけ」に限定します。その後の「一次窓口」は運用課に移すのが現実的です。

ただし、一次窓口は運用課だとしても、その後、実際に誰が担当するかは、別の話です。実際の対応をすべてをDX推進課に戻せば意味がなくなり、すべて運用課にすれば運用課がパンクします。「ゼロイチ」の議論にするから、どちらも非現実的となるのです。

ここは、システムやアプリの性質によって担当を分散させるべきです。

例えば、以下のようなイメージです。
・基幹系システム：業務部門（主管ユーザー部門）＋保守ベンダー
・全社共通システム（ワークフロー等）：システム運用課
・インフラ/セキュリティ系システム：システム運用課
・AI/データ活用基盤：DX推進課
・RPA/ノーコードアプリ：業務部門＋DX推進課

こうすることで、一次窓口であるシステム運用課に全負担を押し付けずに、適正な負担分散となります。

情シスを強くする「4つの仕組み化」

その上で、もっと根源的な問題も考えていく必要があります。情シスの仕組み化として、具体的には以下の4つの対応が効果的です。

① システム運用課のプロジェクト参画

これまでプロジェクト要員はDX推進課だけでしたが、「非機能要件チーム」として運用課にも要件定義から参画してもらいます。そうすることで、運用を考慮したシステム導入となります。「全く知らないシステムを押し付けられた」という抵抗感を和らげる効果もあります。

② システム引き継ぎ基準をつくる

本番稼働後、すぐには引き継ぎません。バグが収束し、安定化してから引き継ぎます。マニュアル類がきちんと整備され、運用方法が明確になっていることを前提とします。
加えて、一定運用期間でFAQを作るまではDX推進課の責任とします。運用課の拒否を単なるわがままと見るのではなく、「受け入れ基準を満たしていないものは受け入れない」という健全な統制に変えていくのです。

③ 運用・保守ベンダーへ委託

どのシステムも、基本的には保守契約を締結しています。そのベンダーに調査や障害対応を依頼して、負荷分散を図ります。その上で、ベンダー窓口は、インフラ寄りなら運用課、業務寄りならDX推進課またはユーザー部門等と明確にします。特に複雑な基幹システムにおいて、保守ベンダーは心強いパートナーとなります。

④ ヘルプデスクの定量化と対応人数の適正化

ヘルプデスクの人数が多い、さらに足りないという主張には、客観的に疑問が残ります。まずは問い合わせをチケット化し、内容・時間・件数を記録すること。対応履歴を可視化した上で、本当に足りないのか、生産性は妥当なのかを判断します。

システム運用課は「何でも引き取る部署」ではありません。DX推進課も「作って終わりの部署」ではありません。

業務システムには、導入・安定化・定常運用・改善のライフサイクルごとに責任者を置くべきです。これら多面的な対応を仕組み化していくことで、情シスは強くなっていきます。

対立から協調へ

「対立構造をなくしたかったんです」

後日、情シス部長は振り返りました。

情シスでは毎週「部会」を行っていますが、それとは別で、情シス部長は両課長を含めた3名で毎週「定例会」をやることに決めました。部長がいる前で両課長がコミュニケーションをとる場を定期的に設けたのです。

最初は刺々しい関係でしたが、腹を割って意見を出し合ったところ、徐々に関係性が良くなっていきました。情シス部長がいない場でも、自然に連携するようになります。上記の情シス施策を部長から説明し、両者とも納得してくれました。

その結果、「情シス全体が明るく前向きになった」と情シス部長は言います。

情シスは、少人数のときには属人化するのは仕方ないです。限られたリソース環境では、属人化こそがもっとも効率的で、合理的な側面があります。

しかし、社内のシステム化やDXが進み、情シスの「拡大期」に入ったら、情シスの「構造」そのものを変えていく必要があります。

貴社の新システムにおける引き継ぎは、うまくいっていますでしょうか？