「それ、勝手に作ったの？」
業務改善の話をすると、ときどきこう言われることがある。
Excel VBAで入力を自動化した。
Accessで管理を楽にした。
Power Automateで定型作業を流した。
Pythonで転記や集計をまとめた。
現場ではたしかに助かっている。残業も減る。ミスも減る。手作業で消耗していた人も少し楽になる。
なのに、ある日その仕組みが「シャドーIT」「危険」「管理外」と言われる。
もちろん、言いたいことはわかる。
管理されていないツールにはリスクがある。属人化もする。壊れたときに困る。セキュリティや権限管理の問題もある。
だから、管理側が嫌がるのは自然だ。
ただ、そこで話を終わらせるのは違うと思っている。
なぜなら、現場は最初から好きで“勝手に”作っているわけではないからだ。
作らざるを得なかった。
そこを無視して「危険だからやめろ」だけで終わらせるのは、あまりに雑だ。
この記事では、シャドーITがなぜ生まれるのか、なぜ現場で改善する人ほど報われにくいのか、そして本当に問題視すべきなのは何なのかを、現場目線で書いていく。
- シャドーITとは何か｜“勝手に作った”ではなく“必要に迫られた”仕組み
- シャドーITが危険だと言われる理由｜批判の中身はだいたい正しい
- でも現場は言いたい｜ふざけるな、誰も助けてくれなかった
- シャドーITの一番つらいところ｜評価されず、責任だけが増える
- 属人化が問題だと言うなら、先に“学ぶ文化”を作れ
- 本当に悪いのはシャドーITそのものではない｜原因は“公式ITの遅さ”と“受け皿のなさ”だ
- シャドーITを潰すな。拾い上げて資産にしろ
- 改善文化は、善意だけでは根づかない
- シャドーITを叩く前に考えたいこと
- まとめ｜シャドーITは悪ではない。問題は“放置する組織”にある
- 1. 野良ITとは何か｜それは「勝手に作った」ではなく「必要に迫られた」だ
- 野良ITが「迷惑」「危険」と言われる理由｜批判されるポイントはだいたい正しい
- 3. でも現場は言いたい｜「ふざけるな。誰も助けてくれなかった」
- 4. 評価されず、責任だけが増えていく｜野良ITの一番イヤなところ
- 5.「属人化が問題だ」と言うなら、先に文化を作れ｜教えても誰も学ばない現実
- 6. 潰すな。拾い上げて「資産」にしろ｜野良ITは“症状”で、原因は別にある
- 7. おまけ｜報酬と称賛がない組織に、改善文化は根づかない
- 関連記事
シャドーITとは何か｜“勝手に作った”ではなく“必要に迫られた”仕組み
シャドーITとは、一般に情シスや正式なIT部門が把握・承認していないIT資産やツール利用のことを指す。
個人で作ったExcel VBA、Accessのツール、Power Automateの個人フロー、Pythonスクリプト、独自に契約したSaaSなど、形はさまざまだ。
そして現場で起きていることをもっと生々しく言うなら、こうだ。
待てないから作った。
これが本質だと思う。
申請しても動かない。
相談しても順番待ちになる。
要件を書けと言われても、その要件を整理する時間すらない。
でも、毎日の業務は止まらない。納期も待ってくれない。ミスは許されない。
だから、現場の誰かが自分で作る。
それがシャドーITの出発点だ。
現場感のある言い方をするなら、「野良IT」と呼びたくなるものも多い。
ただし、検索や一般的な文脈では「シャドーIT」のほうが通りやすい。この記事ではその言葉を使うが、言いたいことは同じだ。
それは遊びではなく、現場の悲鳴から生まれた最終手段である。
シャドーITが危険だと言われる理由｜批判の中身はだいたい正しい
ここは先に認めておきたい。
シャドーITが批判される理由は、かなりまともだ。
代表的なのはこのあたりだろう。
1. 属人化する
作った本人しか中身を理解していない。
結果として、その人が異動・退職・休職した瞬間に止まる。
2. 保守不能になる
エラーが出ても誰も直せない。
小さな改善のつもりが、いつのまにか重要業務の一部になっていて、止まると現場が困る。
3. ブラックボックス化する
仕様書もない。
何のために、どの順番で、何をしているのかが見えない。
特にVBAはファイルの中に処理が埋まりやすく、見えにくい。
4. セキュリティや統制が曖昧になる
データの持ち出し、アクセス権、ログ、バックアップ、アカウント管理。
こうした観点が弱いまま運用されることがある。
つまり、管理側が「危ない」と言うのは自然だ。
ここまでは否定しない。
実際、会社として見れば、見えていない仕組みが増えるのは怖い。
何がどこで動いていて、誰が触れて、どのデータを扱っているのかわからない状態は、健全とは言えない。
ただ、問題はその次だ。
でも現場は言いたい｜ふざけるな、誰も助けてくれなかった
現場からすると、シャドーITに対する説教には、どうしても引っかかるものがある。
なぜか。
誰も助けてくれなかったからだ。
本当に困っているとき、公式の仕組みはすぐに来ない。
改善の予算もない。
小さな困りごとは優先度が低いと見なされる。
相談しても「まず要件をまとめてください」で止まる。
でも、現場はその間も回さなければいけない。
毎日同じ転記をして、同じ入力をして、同じ確認をして、同じミスを防ぐために神経をすり減らす。
その非効率が見えている人ほど、我慢できなくなる。
だから作る。
自分が楽をしたいからだけではない。
周りの手間を減らしたい。ミスを減らしたい。残業を減らしたい。
せめて、目の前の仕事を少しでもマシにしたい。
その結果、現場が助かる。
ところが、成果が出たあとで言われる。
「勝手に作るな」
「管理できない」
「危険だからやめろ」
正直、かなり腹が立つ。
最初から仕組みを用意してくれるなら、そもそも自分で作っていない。
“勝手に作るな”と言う前に、じゃあ代わりにどう回すのかを示してほしい。
そこを空白のままにして、リスクだけを理由に現場の工夫を潰すのは、ただの責任逃れに見える。
シャドーITの一番つらいところ｜評価されず、責任だけが増える
シャドーITの何が嫌か。
本当に嫌なのは、作ること自体ではない。
評価されないことだ。
業務改善をした。
時間が減った。
現場が助かった。
ミスも減った。
それでも人事評価に反映されない。
給料も上がらない。
むしろ「勝手にやるな」と注意されることすらある。
それなのに、便利になったあとはこうなる。
「これ、今後も見てもらえる？」
「別部署にも展開できる？」
「仕様変更があったら対応して」
「エラー出たから直して」
ここで一気に地獄になる。
最初は善意の改善だったはずが、いつのまにか無償の保守契約に変わる。
報酬は増えない。評価も増えない。責任だけが増える。
冷静に考えると、かなりおかしい。
業務改善をする人は、組織にとって本来は貴重だ。
現場を理解していて、課題を見つけて、自分の手で形にできる。
こういう人材は、どこの会社でも欲しいはずだ。
なのに現実には、
「助かった」と言われるだけで終わる。
最悪の場合、「危険なことをした人」みたいな扱いすら受ける。
これが続くと、改善する人から先に壊れていく。
属人化が問題だと言うなら、先に“学ぶ文化”を作れ
シャドーIT批判でよく出るのが、「属人化しているのが問題だ」という話だ。
その通りだと思う。
だから作る側も、引き継ごうとする。
説明する。
ドキュメントを書く。
操作方法をまとめる。
後任に教えようとする。
でも、現実にはなかなか継承されない。
なぜか。
理由はかなりシンプルだ。
学ぶ文化がないからだ。
「プログラミングは無理」
「怖いから触りたくない」
「壊したら嫌だ」
「それ、あなたがやった方が早い」
こういう空気があると、誰も触らない。
触らないから、永遠に属人化する。
属人化した結果だけ見て、「ほら危ない」と言われる。
これはさすがに不公平だ。
属人化の原因を、作った個人だけに押しつけるのは違う。
本当に危険なのは、改善を個人の善意に依存しながら、学ぶ文化も継承の仕組みも作らない組織の方だ。
改善を個人の趣味みたいに扱っておいて、問題が起きたら個人の責任にする。
これでは誰も育たないし、何も残らない。
本当に悪いのはシャドーITそのものではない｜原因は“公式ITの遅さ”と“受け皿のなさ”だ
ここがいちばん大事だと思う。
シャドーITにはリスクがある。
それは事実だ。
でも、シャドーITは原因ではなく症状である。
症状が出る組織には、だいたい共通点がある。
- 公式ITが遅い
- 現場の細かい困りごとが拾われない
- 申請フローが重い
- 小さな改善に予算がつかない
- 作れる人だけが勝手に背負わされる
- 改善が評価されない
こういう環境では、現場で仕組みを作れる人が、自衛として動き始める。
それがシャドーITになる。
つまり、シャドーITだけを潰しても、問題は消えない。
また別の場所で、別の誰かが、別の形で同じことを始めるだけだ。
本当にやるべきなのは、「禁止」ではない。
入口を作ることだ。
シャドーITを潰すな。拾い上げて資産にしろ
現場で生まれた改善を、最初から完璧な仕組みにしろとは言わない。
ただ、会社として最低限やるべきことはある。
それは、シャドーITを頭ごなしに潰すのではなく、拾い上げて資産化することだ。
たとえば、最低限これだけでもだいぶ違う。
持ち込み窓口を作る
現場が作ったツールや自動化の仕組みを、情シスや管理部門に相談できる窓口を用意する。
相談したら怒られるのではなく、レビューしてもらえる状態にする。
台帳化して、まず存在を把握する
何がどこで動いているのか。
誰が作ったのか。
何の業務に使っているのか。
どんなデータを扱っているのか。
まず見える化する。
最低限の基準を決める
アクセス権、ログ、データ持ち出し、バックアップ、保管場所。
全部を厳密にやれとは言わない。
ただ、最低ラインがあるだけでも事故はかなり減る。
レビュー支援をする
情シスが全部作り直す必要はない。
でも、危ない部分を指摘したり、残すべき情報を整理したりする支援はできるはずだ。
承認済みの仕組みに昇格させる
一定の基準を満たしたものは、個人管理のまま放置せず、組織の資産として扱う。
そうすれば“野良”である必要がなくなる。
大事なのは、現場の工夫を敵として扱わないことだ。
現場で生まれた改善は、本来かなり価値がある。
課題の理解が深く、実務に直結していて、費用対効果も高いことが多い。
それを全部「危険」で切り捨てるのは、もったいないどころではない。
改善文化は、善意だけでは根づかない
もうひとつ、見落とされがちなことがある。
それは、改善文化は善意だけでは続かないということだ。
業務改善をする人は、最初は使命感や好奇心で動ける。
自分の仕事を楽にしたい。
チームの負担を減らしたい。
無駄をなくしたい。
そういう気持ちはたしかにある。
でも、それだけでは続かない。
なぜなら、改善には時間も労力も責任も伴うからだ。
それなのに、評価も報酬もなければ、いずれ疲れる。
そして疲れた人から順に、黙ってやめる。
だから会社が本気で改善文化を作りたいなら、
「ありがとう」だけでは足りない。
改善を評価項目に入れる
業務改善、自動化、標準化、横展開。
こうした行動を明確に評価対象にする。
小さくても報奨を出す
数万円でもいい。
改善が報われる経験は、思っている以上に効く。
発表の場を作る
良い改善を共有し、個人の中だけで終わらせない。
「それ、うちでも使える」が生まれる場を作る。
保守を個人に押しつけない
一定以上重要になったものは、個人の善意ではなく、業務として扱う。
ここを曖昧にすると、改善者だけが損をする。
仕組みと評価、この両方がそろって初めて、改善文化は根づく。
逆に言えば、ここがない会社では、DXも働き方改革も掛け声だけで終わりやすい。
シャドーITを叩く前に考えたいこと
シャドーITを批判するのは簡単だ。
リスクを挙げれば、いくらでも正論は言える。
でも、その正論の前に考えたいことがある。
その仕組みは、なぜ生まれたのか。
なぜ正式ルートでは解決されなかったのか。
なぜ個人が背負う形になったのか。
なぜ改善した人が報われなかったのか。
ここを見ずに、「危険だから禁止」で終わる組織は弱い。
現場の課題を拾えない。
小さな改善を吸い上げられない。
作れる人にだけ依存する。
そして最後に、その人を危険扱いする。
これでは、改善する人は消えていく。
残るのは、言われたことだけをこなす人と、何も言わずに転職する人だけだ。
それは会社にとっても損だと思う。
まとめ｜シャドーITは悪ではない。問題は“放置する組織”にある
シャドーITにはリスクがある。
属人化もするし、ブラックボックスにもなりやすい。
だから管理が必要なのは、その通りだ。
でも、それだけで終わらせてはいけない。
シャドーITは、現場が好きで始めた遊びではない。
多くの場合、仕組みがないから生まれた。
助けがないから、自分たちで何とかした結果だ。
本当に問題なのは、現場の改善を放置し、頼り、最後に危険扱いする組織の方だと思う。
必要なのは、禁止ではない。
見える化し、拾い上げ、最低限の基準を与え、資産化することだ。
そして何より、改善する人が損をしない仕組みを作ることだ。
改善が評価されない会社では、改善文化は育たない。
改善文化が育たない会社で、DXだけが進むこともない。
シャドーITをなくしたいなら、現場を黙らせるのではなく、
現場の工夫を正式な力に変える仕組みを作るべきだ。
そうなったとき、たぶん“シャドーIT”という言葉自体が、少しずつ不要になっていく。
1. 野良ITとは何か｜それは「勝手に作った」ではなく「必要に迫られた」だ
「野良IT」と呼ばれるものは、情シスや正式なIT部門の管理外で、現場の人間が自分で作ったツールや自動化の仕組みを指すことが多い。
ExcelのVBA、Access、Power Automateの個人フロー、Pythonのスクリプト、個人で契約したSaaS――形は何でもいい。共通点はひとつだ。
「待てないから作った」。
似た言葉に「シャドーIT」がある。こちらは一般に、IT部門が把握・承認していないIT資産やクラウド利用を指し、セキュリティや統制の観点から“リスク”として語られやすい。
一方で「野良IT」は、現場の悲鳴と工夫が混ざった、もっと生活感のある言葉だと思う。
野良ITは遊びではない。
「このままだと仕事が回らない」から生まれた、現場の最終手段だ。
野良ITが「迷惑」「危険」と言われる理由｜批判されるポイントはだいたい正しい
野良ITが叩かれる理由は、正直わかる。だいたいこの4つだ。
- 属人化：作った本人しか触れない
- 保守不能：壊れたら誰も直せない
- ブラックボックス化：仕様も目的も不明になる
- セキュリティ不明：データの扱い・権限・ログが曖昧
特にVBAは、ファイルにロジックが埋まって見えにくく、作り手の癖がそのまま残りやすい。「ブラックボックス化」「属人化」が起きやすい、という指摘はよくある。
だから、管理側が嫌がるのは自然だ。
ここまではいい。
3. でも現場は言いたい｜「ふざけるな。誰も助けてくれなかった」
3. でも現場は言いたい｜「ふざけるな。誰も助けてくれなかった」
問題はここからだ。
現場は最初から“好きで”野良ITをやっていない。
頼れる仕組みがない。改善の予算もない。情シスに頼んでも順番待ち。仕様書を書けと言われても、そもそも書く時間がない。
それでも納期は来る。ミスは許されない。残業は増える。
だから自分で作る。自分だけじゃなく、周りの負担も減らすために。
それなのに、成果が出た途端に言われる。
- 「危ないからやめろ」
- 「勝手に作るな」
- 「管理できない」
……冗談じゃない。
外注すれば数十万〜百万円が飛ぶような改善を、現場がゼロ円でやっていることもある。
“迷惑”で切り捨てるなら、じゃあ代わりに仕組みを用意してくれ。最初から。。
4. 評価されず、責任だけが増えていく｜野良ITの一番イヤなところ
野良ITを作る人間が壊れていくのは、ここだ。
- 作っても評価されない
- むしろ「勝手にやるな」と怒られる
- それでも現場は便利になる
- すると次は「保守も頼む」と言われる
報酬ゼロ、評価ゼロ、責任だけ増える。
これ、冷静に考えて狂っている。
善意で作った改善が、いつのまにか“無償の保守契約”に変わる。
そして一番やばいのは、こういう扱いが組織に根付くと、改善する人が消えることだ。
残るのは「言われたことだけやる人」と「黙って退職する人」だけになる。
5.「属人化が問題だ」と言うなら、先に文化を作れ｜教えても誰も学ばない現実
属人化が問題だと言われる。わかる。だから教える。引き継ぐ。ドキュメントも書く。
それでも継承されないことが多い。
原因はシンプルで、学ぶ文化がないからだ。
- 「プログラミングは無理」
- 「壊しそうで怖い」
- 「それ、あなたがやった方が早い」
この空気があると、誰も触らない。
触らないから、永遠に属人化する。
属人化した結果だけを見て、「ほら危険だ」と言われる。
それは違う。
危険なのは野良ITそのものではなく、改善を“個人の趣味”として放置する組織だ。
6. 潰すな。拾い上げて「資産」にしろ｜野良ITは“症状”で、原因は別にある
野良ITにはリスクがある。これは事実だ。
ただ、野良ITは原因じゃない。症状だ。
症状が出る理由はだいたいこうだ。
- 公式ITが遅い／遠い
- 現場の課題が細かすぎて拾われない
- 改善の予算がない
- 申請フローが重い
- “作れる人”だけが勝手に背負わされる
だから本当にやるべきは「禁止」ではない。
入口を作って、仕組みに取り込むことだ。
たとえば、最低限これだけで世界は変わる。
- **野良ITの“持ち込み窓口”**を作る（現場→情シスへ）
- 棚卸し台帳を作り、存在を可視化する（まず把握）
- 最低限の基準を決める（権限／ログ／データ持ち出し／バックアップ）
- レビュー支援を情シスがやる（全部作れとは言わない）
- “サンクションドIT化”＝承認済みとして昇格させる
シャドーITの文脈でも「把握できない利用はリスクになる」という点は繰り返し言われている。
だからこそ、潰すより先に「見える化」と「受け皿」だ。
7. おまけ｜報酬と称賛がない組織に、改善文化は根づかない
仕組みだけでは足りない。
改善を“得”にしないと、文化は死ぬ。
- 優れた改善には報奨金（数万円〜数十万円でも効く）
- 評価項目に「業務改善・自動化」を入れる
- 改善発表の場をつくり、横展開する
これだけで「改善は報われる」という土壌ができる。
その土壌ができたとき、野良ITという言葉はたぶん消える。
なぜなら、野良である必要がなくなるからだ。
そうしなければ、DXも働き方改革も、いつまでも絵に描いた餅のままだ。
