DX推進室と情シスの役割分担は?導入したツールの運用で困らない決め方

「全社で使えるようになりました」とDX推進室が発表した翌週、情シスの窓口に「ログインできません」が届き始める。情シスは、そのツールの名前を発表で初めて知りました。DX推進室にも、早く成果を見せたい事情があります。

この記事では、DX推進室(DX推進部など、名前は会社ごとに違います)と情シスがすれ違う場面を、公開されている声と調査から整理します。後半には、役割分担の表、最初の打ち合わせで決めること、受け渡し票を付けました。

DX推進室と情シス、すれ違うのはどこ?

DXを「攻めのIT」、情シスを「守りのIT」と呼ぶことがあります。攻めも守りも会社に要る仕事で、どちらかが悪いわけではありません。

DXを進める場面のずれを、業務改善を支援するコンサルタントのnote(隼人、2026年1月27日)は短く書いています。現場は「楽になりたい」、情シスは「止めたくない」。

公開されている声を読んで整理すると(公開されている声10件、編集部)、すれ違いは次の3つの場面に集まります。

あるある1: 「DXは企画、情シスは保守」で分けたら、運用が宙に浮いた

企画と保守で分けると、間にある仕事がこぼれます。問い合わせの受け付け、権限の変更、ちょっとした改修、使われなくなったものの片づけです。kintone(サイボウズの、業務アプリを作るサービス)の管理者の方は、現場にアプリ作りを開放したときのことを、こう書いています。

管理者の異動や退職で引き継ぎがされず、放置されたアプリの改修依頼がシステム部門に舞い込む日々。仕様を一から解読する羽目になり、「これなら最初から自分が作った方が早いのでは…？」と疲れ果て、一度は市民開発を諦めていたのです。

この方は、研修を受けた人にだけ作る権限を渡す、使われていないアプリの棚卸しと削除の条件を決める、などの仕掛けを整えて、もう一度開放しています。

心配しているのは、情シスだけではありません。これから市民開発(業務部門の人が自分でアプリや自動化を作ること)の支援に関わる筆者は、こんな場面を例に挙げています。Power Automateは、マイクロソフトの、作業を自動化するサービスです。

「このPower Automate、誰が作ったの？」

「○○さんです」

「○○さん、もう異動してるよ……」

「エラーになっているんですけど、誰も中身が分かりません」

同じ筆者は、作ったアプリやフローの保守を誰が担うのかを、組織として考えることの1つに挙げています。情シスの立場のnote(くろひつじ、2023年12月2日)にも、「でもそのツール、誰がメンテナンスするのでしょう」という問いがあります。DXを進める側と情シスが、同じところを心配しているわけです。

あるある2: 決まってから届く「進捗してしまった案件」

2つ目は、順番です。DXに携わる筆者は、DXと情シスが同じ組織にいた経験から、こう書いています。

DXと情シスのマネジャー陣が良好なコミュニケーションを取っていると、DX施策の実現も早いですし、早期にセキュリティリスクを織り込むなど多角的な観点で物事を進められます。情シスから見ても、進捗してしまった案件をいきなり突きつけられるより、様々な準備ができてスムーズでしょう。

この筆者は記事の後半で、攻めと守りは大事にするものが違うので、組織を分ける考え方にも理があると両論を並べています。組織の形より、早い段階で話せるかどうかが分かれ目だと読めます。

あるある3: 誰が決めるのか曖昧。DX推進室も困っている

3つ目は、決める人です。ここは、DX推進室の側も苦しんでいます。IT部門で働いたあと、いまはDX推進室に勤める筆者は、DX担当者がぶつかる壁の1つに「権限の壁」を挙げています。

「現場で調整してね」と任されたものの、決定権がなく、全てが上長確認待ち……。

同じ記事には、「DXはIT部門がやればいい」と丸投げされる、という壁も出てきます。情シスの立場のnote(keita、2024年6月25日)は逆に、新しく作った「DX推進室」的な部門に、社内でDXを丸投げするパターンを挙げています。変わるのは現場の業務なので、誰かに任せきりにはできない、という指摘です。

DX推進室と情シスは、どちらも丸投げを受ける側にいるわけです。決める人が決まると、動きは早くなります。

法人のDX推進部で開発を担う筆者(Zenn・ひーさん、2026年4月2日)は、部署が正式にできて「これ勝手に作っていいの？」という迷いが消えたそうです。承認も早くなったと書いています。

調査でも、部門の協調と成果はつながっている

IPAの「DX動向2026」(2026年7月30日公開)は、国内企業1,799社への調査(2026年4〜6月、IPAの呼び方では2025年度調査)の結果です。DXに取り組む企業で、経営者・IT部門・業務部門の協調ができているかを、成果の有無で比べると次のとおりでした。

IPAは、部門間の協調とDXの成果の創出が強く関係しているとしています。協調すれば成果が出る、という因果まではこの数字だけでは言えません。

JUAS(日本情報システム・ユーザー協会)の「企業IT動向調査報告書2026」は、IT部門長が回答した957社の調査です(2026年4月公開)。「DX推進体制が不明確」という課題への施策には、専任の部署づくりなどが挙がっています。IT部門と事業部門の責任を明確にするため、「事業がDX推進の主体でありITは支援」という役割分担を全社のルールにした企業もあったと書かれています。

役割分担の表(編集部の整理)

製造業の情シスマネージャーのnote(まさ、2024年3月17日)は、イベントで聞いたサッカーのたとえを紹介しています。ユーザー部門がフォワード、情シスがディフェンダー、間で試合を組み立てるデジタル推進の人材がミッドフィルダーです。DX推進室をこの真ん中に置くと、分担を考えやすくなります。

次の表は、公開されている声と調査をもとにした、編集部の整理です。会社の規模や体制で変わるので、案として使ってください。

最初の打ち合わせで決める7つのこと

新しい施策の最初の打ち合わせに、情シスを1人呼びます。30分ほどで、次の7つを確かめます。

6は、先ほどのイベントの報告が参考になります。ある製造業の会社は、ノーコードの開発に次のようなルールを設けていると紹介されています。

• 仕様書を残す
• 作った当初は試行の扱いにする
• 運用が続けられて初めて本運用に上げる
• 品質の責任は部門側が持つ

3と4は、DX推進を担う筆者のブログ(dai365のお部屋、2025年12月19日)にも出てきます。市民開発を増やそうと言うだけでは「ガバナンスが爆発します」として、最小の規約を5つ挙げています。データの分類、保存先、権限、誰が何のために作ったかの記録、相談窓口で、分類と権限には「ガチガチにしないこと」と添えています。

7の費用の分け方は、SaaSの請求書とカード払いは誰が管理する?も参考になります。

受け渡し票のひな形と言い方の例

試行から本運用に上げるときは、DX推進室から情シスへ、次の票で引き継ぎます。情シスは、足りない欄だけを聞き返します。

【DX施策の受け渡し票】
施策名:
目的(何がどう変わるか):
業務の持ち主(部門・責任者):
決める人(本運用・変更・やめる):
DX推進室の担当 / 情シスの担当:
使うツールと契約(プラン・費用・更新日):
扱うデータと連携先(個人情報・機密の有無、つなぐサービス):
ログインの方法(会社のアカウント・多要素認証):
管理者(2人以上・氏名):
問い合わせの窓口(一次 / 二次):
改修の受け付けと担当、仕様のメモの置き場所:
本運用の開始日、棚卸しの時期、やめる条件:

アカウントの一覧と棚卸しの記録には、次の台帳がそのまま使えます。

言い方の例も挙げます。

今日からできること

1. いま動いている施策とツールを、DX推進室と情シスで一覧にする。業務の持ち主、窓口、改修の担当、更新日の空欄に印を付ける
2. 役割分担の表を自社の言葉に直し、両方の部長と業務部門の代表に見てもらってから社内に出す
3. 次の新しい施策から、最初の打ち合わせに情シスを1人呼び、7つのことをその場で確かめる
4. 受け渡し票を共有の場所に置き、本運用に上げる前にDX推進室と情シスで一緒に埋める
5. 年1回、作ったアプリと自動化の棚卸しを一緒にやる日を決める

現場からのツールの要望の受け方は、「このツール使いたい」にどう答える?にまとめています。

DX推進室は変える力を、情シスは続ける力を持っています。どちらか一方だけでは、新しい仕組みは会社に根づきません。運用の持ち主を最初に決めておくと、「聞いていません」が「最初から一緒に決めました」に近づきます。