「野良システム」とは何か——社員が作ったツールが会社のリスクになる前に

野良システムとは何か

「野良システム」とは、情報システム部門（情シス）の管理外で、現場の社員が独自に作った・導入したシステムやツールの総称です。誰かが正式に決めて作ったものではなく、いつの間にか業務に組み込まれている。だから「野良」と呼ばれます。

具体的には、次のようなものです。

• 受発注の集計を自動化しているExcelマクロ
• 顧客リストを管理しているAccessのデータベース
• kintoneやNotionで組んだ案件管理アプリ
• スプレッドシートにGAS（Google Apps Script）を組み合わせた自動通知

どれも珍しいものではありません。従業員10〜100名規模の会社であれば、探せばまず見つかります。

そして近年、この仲間に新しい顔ぶれが急速に加わっています。社員が生成AIに書かせたツールです。以前なら「プログラミングができる人」にしか作れなかったものが、日本語で指示すれば数十分で動くものが出てくるようになりました。Pythonのスクリプト、Excelマクロ、簡単なWebアプリ。作れる人の裾野が一気に広がったぶん、野良システムが生まれる速度も上がっています。

なぜ野良システムは生まれるのか

まず、はっきりさせておきたいことがあります。野良システムを作った社員は、会社を良くしようとした人です。

現場には、今日困っている業務があります。毎月の締めで何時間もかかる転記作業、二重入力、手作業の集計。それを解消したいと思ったとき、正規のルート——外注する、情シスに依頼する——は、時間もお金もかかります。見積もりを取り、予算を通し、要件を伝え、待つ。小さな困りごとのために、そこまでの手間をかけるのは現実的ではありません。

だから、手の届く道具で自分で解決する。Excelを開き、マクロを組む。kintoneでアプリを作る。今なら生成AIに頼む。それは怠慢でも越権でもなく、目の前の業務を何とかしようとした結果です。

つまり野良システムは、個人の問題ではなく構造の問題です。「正規ルートが遠すぎる」という構造がある限り、誰かがやめても別の誰かが作ります。ここを取り違えて犯人探しを始めると、この後の対処がすべてうまくいかなくなります。

何がリスクなのか

作った人の意図は善意でも、管理外にあること自体がリスクを生みます。ここでは事実として4点を挙げます。

属人化：作った人しか直せない

仕様書もコメントもなく、作った本人の頭の中にしか構造がない。その人が異動・退職した瞬間、誰も触れないツールが残ります。「Excelマクロの引き継ぎ」が問題になるのは、たいていこの局面です。動いてはいるが、直せない。修正しようとして壊すのが怖いので、誰も手を出さない。社内ツールの属人化は、作った人が優秀であるほど深刻になります。

セキュリティ：認証・権限・データの所在が管理外になる

誰がアクセスできるのか、どこにデータが保存されているのか、退職者のアカウントは止まっているのか。正規システムなら当たり前に決まっていることが、野良システムでは決まっていません。個人のGoogleアカウントで動いているスプレッドシート、生成AIのチャット欄に貼り付けた顧客リスト。悪意がなくても、データは会社の管理外に出ていきます。

データの分断：どちらが正しいか分からなくなる

正規システムにも入力し、野良システムにも入力する。二重管理が始まると、いずれ数字が合わなくなります。そのとき「どちらが正しいのか」を判断できる人がいない。集計のたびに突き合わせが発生し、効率化のために作ったはずのツールが、逆に手間を生みます。

「動いているから」問題：試作がいつの間にか基幹業務を載せている

最初は「とりあえず自分用に」作ったものが、便利なので隣の人も使い始め、部署全体が使うようになり、気づけば止まると業務が止まるものになっている。作った本人にも「これが基幹システムだ」という自覚がないまま、会社の重要業務が試作品の上で動いている状態です。

生成AI製のツールについて、一つ付け加えます。作成速度が速いということは、この4点が起きる速度も速いということです。以前なら「マクロを組める人」がボトルネックになって自然に数が抑えられていましたが、今はその制約がありません。動くものはできた。しかし、事故を起こさずに動き続けるものかどうかは別の話です。この差は、作った本人には見えにくいものです。

どうすればよいか

最初に言い切っておきます。「野良システムを禁止する」は最悪手です。

禁止しても、業務の困りごとは消えません。消えるのは、ツールの存在が見えていた状態です。社員は隠れて使い続け、会社はどこに何があるかを把握する手段を失います。リスクは減らず、見えなくなるだけです。

現実的な手順は、次の3ステップです。

ステップ1：棚卸し——責めない前提を宣言してから申告してもらう

まず「作ったことを責めない。むしろ、業務を回すために作ってくれたことに感謝している」と明言してください。これがないと申告は集まりません。そのうえで、「今、業務で使っている自作・独自導入のツールを教えてほしい」と現場に聞きます。聞くのは次の4つで十分です。

• ツールの名前（呼び名）
• 何の業務に使っているか
• 誰が作ったか
• 誰が使っているか

完璧なリストを目指す必要はありません。まず出てきたものから始めます。

ステップ2：仕分け——「止まると業務が止まるもの」を特定する

集まったリストを、業務への重要度で分けます。基準はシンプルに、「このツールが明日動かなくなったら、業務は止まるか」。止まるものが「重要」、不便になるだけなら「普通」、なくても困らないなら「参考」。もう一つ、「顧客情報や個人情報を扱っているか」も見てください。この2軸で見ると、本当に手を打つべきものは全体のごく一部に絞られます。

ステップ3：重要なものだけ、設計を確認して引き継げる状態にする

「重要」に分類されたものだけ、専門家の目を入れます。全部を作り直す必要はありません。確認するのは、データの保存場所と権限、止まったときの復旧手順、作った本人以外が直せる状態になっているか——この程度です。多くの場合、作り直すのではなく、簡単な説明書を残す、保存先を会社管理のアカウントに移す、といった小さな手当てで足ります。本当に作り直すべきものは、その確認の中で自然に見えてきます。

そして、「普通」「参考」に分類したものは、放っておいて構いません。全部を正規化しようとすると、棚卸しそのものが続かなくなります。完璧主義は続きません。重要なものだけ押さえて、あとは半年に一度リストを更新する。それで十分です。

現場で見た野良システム

当社が実際に見た例を、特定されない範囲で二つ挙げます。どちらも生成AIで作られたもので、作った人はそれぞれの業務を前に進めようとしていました。

一つ目は、営業チームが自分たちの営業管理のためにSFA（営業支援ツール）を生成AIで開発し、運用していたケースです。動いてはいましたが、認証機能がついていませんでした。つまり、URLを知っていれば誰でも開ける状態で、営業情報がインターネット上に公開されていたことになります。

二つ目は、自社の勤怠管理ツール（タイムカード）を生成AIで開発していたケースです。こちらは認証機能がついていて、IDとパスワードを知らない限りログインはできませんでした。ただ、ログイン画面が検索エンジンにインデックスされていました。社内向けのはずのツールが、検索すれば見つかる場所に置かれていたわけです。

どちらも、機能としては要望どおりに動いていました。作った本人から見れば「完成している」ものです。認証がない、検索エンジンに載っている——こうしたことは、動作確認では見つかりません。設計とセキュリティに関する知識がある人が見て、初めて分かる種類の問題です。生成AIで作れるものが増えたいま、この「動作確認では見つからない穴」こそが、専門家の目を入れるべき箇所です。