現場DXを止めるな！ただし、基幹システムへの「野良連携」は止めろ 〜情シス統制が問われる〜

すべて完成してから持ち込まれた承認依頼

「もう全部できているので、承認だけお願いします」

ある現場部門から、情シスにそんな連絡が入りました。

A社は、あるパッケージで基幹システムを導入しています。連絡してきたのは、実行力があってすぐに動くことで社内でも有名な部門です。

話を聞くと、その部門では基幹システムへの入力負担が大きいとのこと。そこで、自分たちで「一括入力」する仕組みを作ったというのです。

具体的には、こうです。

自分たちで作った「専用Excel」にデータを入力する。そのExcelから、基幹システムのデータベースへ直接アップロードする。これで、大量の入力作業が一気に片付くというわけです。

「入力チェックはどうするのか」という懸念には、すでに手が打たれていました。

基幹システムの入力画面を通さない代わりに、Excel上でプルダウン選択にして、誤入力を防ぐ仕組みにしている。だからデータ不整合は起きない、と言います。

さらに保守ベンダーにも、更新で不整合が出ないかを（情シスを通さず、勝手に）確認済みで、問題ないとのことでした。

アップロードには、あるRPAツールを使用。派遣エンジニアを雇って、実装もテストも完了している。自動化も済んでおり、技術的にも問題ない。予算も自分たちで確保する。

つまり、情シスの手を一切煩わせることなく、自分たちだけで一括入力の仕組みを作り上げてきたのです。

「情シスとしては何の問題もないはずです。承認してください」
「現場DXを推奨しているんですよね？」
「現場のやる気に、水をささないでほしいんです」

そう念押しされました。
さて、情シスは、このまま「OK」を出してよいのでしょうか？

「開発済み」は承認していい理由にはならない

まず、現場DXの取り組みそのものは、素直に素晴らしいと思います。

入力負担を減らすために、現場が自主的に改善案を考え、自分たちで実行する。この姿勢は、まさに「現場DX」の鏡といえます。

これがもし、現場に閉じたシステムやアプリであれば、止める理由は何もありません。「どんどんやってください」とOKを出していいでしょう。

しかし、本件は「基幹システム」です。

ここを承認してしまうと、次の4つの問題が生じます。

① 基幹システムそのものを壊すリスク

基幹システムは、勝手に更新してよいものではありません。全社で使っているため、万が一、更新ミスでデータ不整合が起きたり、データが壊れたりした場合、「影響」が大きすぎます。

たとえば、画面上では更新できない項目でも、外から直接入れれば、悪用やコーディングミスで更新できてしまうことがあります。それが制御系の項目だったり、重要な判断に使う項目だったり、金額などの数値に関わる項目だったりした場合、「大きな事故」に直結します。

加えて、基幹システム本体のデータ構造や機能を改修するたびに、この外付けの仕組みへの「影響確認」が必要になります。デグレや障害の原因にもなり、「保守性」は確実に悪化していきます。

本来であれば、保守ベンダーに機能追加を依頼し、正式な機能として実装すべきものです。
 

② 裏口になるセキュリティリスク

仮に技術的に問題なく実装できたとしても、運用を誤れば「セキュリティリスク」になります。

基幹システム本体を多要素認証で厳重に管理していても、外付けの仕組みが簡単にアクセスを許してしまえば、そこが「裏口」になります。この仕組みを悪用されると、基幹システムのデータを破壊されたり、ランサムウェアに乗っ取られて暗号化されたりする可能性もあるのです。

正面の鍵をいくら厳重にしても、裏口が開いていては意味がありません。
 

③ 統制と責任が崩れるリスク

ツールで更新するということは、作成者・更新者がすべてツールのアカウント名義になってしまうということです。これでは、個人単位の責任追跡が弱くなり、「内部統制上」の問題になります。

そしてもう一つ。そもそも、開発済み・テスト済みというのは、承認の理由にはなりません。むしろ、情シスへ事前相談なく開発を進めてしまった点が、「変更管理」上の問題なのです。

本来は、開発に着手する前に情シスへ相談し、標準機能や本体改修で代替できないか、外付けが妥当かを判断したうえで決めるべきでした。

さらに怖いのは、前例ができてしまうことです。「基幹システムを更新する仕組みを、現場が自由に作ってよい」という前例を一度認めれば、今後ほかの部署から同じ要望が出たときに、断れなくなります。

こうした「野良連携」が増えるほど、基幹システムは複雑化し、統制が効かなくなっていきます。

「現場DX」と「全社DX」は、明確に分けなければいけません。基幹システムは、明らかに後者です。
 

④ 将来、情シスに跳ね返るリスク

今回の仕組みは、派遣エンジニアに「属人化」しています。ベンダーの法人契約とは違い、個人に依存しているのです。

在任中はよくても、契約が切れた途端、障害が起きても誰も対応できません。将来的にはブラックボックス化し、最後の最後に情シスが保守を押し付けられることになりかねません。

RPAは、ローコード・ノーコードで比較的簡単に作れてしまいます。Excelマクロのように現場に閉じた業務なら、どんどん使えばいい。

しかし、そのRPAもいずれブラックボックス化し、「野良ロボット」が増えていきます。派遣エンジニアに作らせると、この問題はさらに加速します。

つまり、現場は知らず知らずのうちに「時限爆弾」を増やしているともいえます。現場DXの最大の落とし穴が、ここにあります。

もしRPAを使うのなら、現場社員が自力で引き継げる範囲の小さなロボットに留め、マニュアルを残し、その部署だけで保守できる範囲に収めるべきです。

あまりに複雑で専門的な処理や、基幹システムのように全社で使うシステムには、適用すべきではありません。

情シスは、基幹システムの「門番」たれ

では、あるべき姿は何でしょうか。

答えはシンプルです。保守ベンダーに、「Excelの取り込みボタン」を正式な機能として作ってもらうことです。

正規の機能であれば、誰が操作したかも記録に残ります。内部統制上の問題はクリアされ、野良ロボットも防げ、システム統制も維持されます。

あわせて、「変更管理」の運用として、次のルールを設けて徹底します。

「基幹システムへの登録・更新処理は、原則として情シスの事前承認を必須とする」

ここで大事なのは、現場とのハレーションを恐れて、安易に承認してはいけないということです。

システム全体の統制を守るうえで、情シスは基幹システムの「門番」として、毅然と対応すべきです。

一時的には感情的な対立が生まれるかもしれません。しかし、長期で見れば、情シスの信頼性はむしろ増していきます。

逆に、ここで安易に許可してしまえば、経営層からの信頼を失うことになるでしょう。

ブレーキ役ではなく、伴走役として

「2週間でできるそうです」

情シスが保守ベンダーに見積もりを取ったところ、2週間で開発できるとのことでした。

そこで、今回はこう整理しました。

現場が自主的に構築した仕組みのうち、専用Excelにデータを入力するところまでは、そのままOK。一方で、基幹システムへの更新部分はNGとし、情シス管理下で保守ベンダーに開発してもらうことにしたのです。

現場の改善努力を、無下に否定はしません。むしろ褒めるし、推奨する。ただ、基幹システムへの直結だけは、こういう理由で正規ルートに乗せたい。

そのうえで、情シスから現場部門へ、慎重に言葉を尽くして説明しました。説明の場には、現場部門の責任者も出てきて、重苦しい雰囲気で緊張したそうです。しかし、意外なことに抵抗はありませんでした。前向きな雰囲気で、保守ベンダーへの依頼事項の確認の場となったのです。

情シスが単なる「ブレーキ役」と見なされないよう、ハレーションが起きないような仕組みにしないといけません。決まった運用ルールは文書化し、ポータルサイトの「お知らせ」にも掲載しました。

結果として、現場との関係も良好なままです。
「やっぱりプロに作ってもらった方が使いやすいですね！」
と言われ、ひとまず安心しました。

現場DXは、止めてはいけません。

しかし、基幹システムへの「野良連携」だけは、止めなければなりません。この線引きを毅然と引けるかどうかに、情シスの真価が問われます。

貴社のIT部門・情報システム部門は、基幹システムへの安易な連携を、きちんと防げていますでしょうか？