シャドーIT対策を「禁止」の一言で片づけると、現場の困りごとは残り、利用だけが見えにくくなります。必要なのは、Excelマクロ、個人アプリ、Power Automateフロー、Power Appsなどを棚卸しし、業務への入り込み方に応じて扱いを変えることです。
結論：シャドーIT対策は、見えない業務インフラを扱える状態に戻すこと
現場改善を止める話ではなく、業務を守るための棚卸しです。
シャドーITとは、情報システム部門や管理部門が十分に把握しないまま、現場で使われているITツールや仕組みを指します。Excelマクロ、Access、VBA、スプレッドシート、Power Automateのフロー、Power Appsの個人アプリ、kintoneの簡易アプリなどが、代表的な例になります。
これらは、最初から危険なものとして生まれるわけではありません。多くの場合、きっかけは「手入力が多い」「転記がつらい」「標準システムでは細かい業務に合わない」といった現場の困りごとです。小さな改善が業務を支えていることもあります。
問題は、会社が把握しないまま業務の必須部品になり、所有者・仕様・保守者・権限・廃止条件が分からない状態で残ることです。シャドーIT対策の本質は、現場の工夫を摘発することではなく、見えない業務インフラを見える状態に戻し、重要度に応じて管理・移管・廃止・正式化できるようにすることです。
相談：禁止すれば、シャドーITはなくなるのか
禁止で止まるものと、禁止しても残る困りごとは分けて考えます。
シャドーITって聞くと、まず「禁止せんと危ない」と言いたくなるとよ。情報漏えいも、監査不能も、保守不能も怖いけんね。
でも、禁止しただけで現場の困りごとが消えるわけではないのよね。転記が多い、確認が遅い、紙が回らない、標準システムでは入力できない。そこが残る。
代替手段がないまま禁止すると、利用が表から消えるだけで、裏で残ることがあるたい。
だから最初に必要なのは、「やめろ」ではなく「どこで何が使われているかを見せてください」と言える設計だと思うのよ。
シャドーIT対策で難しいのは、現場改善の価値と、管理されない仕組みのリスクが同時に存在することです。現場のExcelマクロが毎日30分の転記を減らしているなら、その改善自体には意味があります。一方で、そのマクロが部署の月次報告を支え、作成者しか直せず、保存場所も変更履歴も分からないなら、業務継続上のリスクになります。
したがって、問いは「使ってよいか、禁止か」だけでは足りません。どの業務で、どの範囲に使われ、止まったときに何が起きるのか。そこまで見て、扱いを変える必要があります。
なぜシャドーITは生まれるのか
多くの場合、始まりは現場の悪意ではなく、業務を回すための工夫です。
標準システムは、会社全体の共通業務を安定して処理するために作られます。しかし、現場には標準システムだけでは吸収しきれない細かな仕事があります。ちょっとした確認リスト、部署独自の集計、承認前の下書き、取引先ごとの補助台帳、紙で残っている点検表などです。
その小さな隙間に、Excelマクロ、スプレッドシート、Power Automate、Power Apps、kintoneなどが入ります。これらは、現場の業務知識を持つ人が短い時間で形にしやすく、改善の初速を上げられます。
問題は、試作品のつもりで作ったものが、いつの間にか業務の本番配管になることたい。
最初は「自分用の便利ファイル」だったのに、隣の人も使い、チームも使い、いつの間にか部署の正規業務みたいになる。
図面に載っていない配管が、気づいたら毎日使われている状態ばい。
比喩としては強いけど、言いたいことは分かるのよ。使われているなら、図面に戻す。つまり、台帳に載せて、点検できる状態にする。
この段階で必要なのは、現場の工夫を否定することではありません。むしろ、業務をよく知る人が見つけた改善の芽を、組織として扱える形に変えることです。シャドーIT対策は、改善を止める統制ではなく、改善を継続可能にする運用設計として考える必要があります。
何が危ないのか：見えていないものは、保守も監査もできない
シャドーITのリスクは、動いている間ほど見えにくくなります。
シャドーITの危うさは、ツールの種類だけで決まりません。小さなExcelファイルでも、部署の報告数値の正本になっていれば重要です。簡単なPower Automateフローでも、顧客連絡や承認通知に使われていれば、止まったときの影響は大きくなります。
| 見えにくいリスク | 起きやすい状態 | 後から困ること |
|---|---|---|
| 所有者不明 | 作成者本人だけが管理している | 異動・退職・長期不在時に誰も判断できない |
| 仕様不明 | 処理内容や前提条件が文書化されていない | 数値の意味や処理結果を説明できない |
| 保守不能 | マクロ、フロー、アプリの構造を他者が読めない | 業務変更に合わせた改修ができない |
| 権限管理不備 | 個人アカウントや共有フォルダ権限に依存している | 不要な閲覧、接続切れ、監査対応の難しさが出る |
| 正本不明 | 同じ目的のファイルやアプリが複数ある | どのデータを信じるべきか分からなくなる |
とくに注意したいのは、「一見動いているから問題が見えない」ことです。シャドーITは、止まるまで危険が目立たないことがあります。日々の作業が流れている間は便利に見えますが、担当者変更、部署再編、権限変更、ファイル移動、列名変更、外部連携変更などをきっかけに、急に保守の難しさが表に出ます。
見える化の考え方：棚卸しは責めるためではなく、守るために行う
申告しやすい入口を作らないと、利用はさらに見えにくくなります。
シャドーIT対策の第一歩は、棚卸しです。どの部署で、誰が、何のために、どのツールを使っているのか。利用者数、業務重要度、扱うデータ、外部連携、停止時影響を確認します。
ただし、棚卸しの空気を間違えると、現場は申告しにくくなります。「見つけたら叱られる」「申告すると取り上げられる」と思われると、便利ツールはさらに隠れます。見える化は摘発ではなく、業務を守るための登録として設計する必要があります。
「申告したら怒られる」だと、誰も出さんとよ。
そうだね。見える化の言い方を間違えると、監視に見えてしまうのよ。
本当は、点検対象に載せることで守れるようにする話たい。
「登録すると相談できる」「重要なら正式管理に移せる」「不要なら安全に廃止できる」。その入口があると、現場も出しやすい。
見える化では、すべてのツールを同じ重さで管理しないことも大切です。個人作業の効率化に留まる低リスクのツールと、部署横断で使われる高リスクのツールでは、必要な管理レベルが違います。
| 分類 | 例 | 必要な扱い |
|---|---|---|
| 低リスク | 個人作業の整形マクロ、個人メモ用の集計ファイル | 最低限の自己管理と保存場所の明確化 |
| 中リスク | チーム内で使うExcel台帳、共有フォルダ上の簡易ツール | 所有者、利用範囲、簡単な説明書、変更履歴 |
| 高リスク | 部署横断のPower Apps、承認通知のPower Automateフロー | レビュー、保守担当、権限管理、停止時対応 |
| 重要管理対象 | 顧客情報、個人情報、品質、安全、会計、監査に関わるツール | 正式管理への移管、責任者承認、定期点検 |
運用ルール：禁止より先に決めること
小さなツールが業務インフラ化したとき、守るための最小単位です。
シャドーIT対策では、最初から重い承認フローを作りすぎると、現場改善の初速が落ちます。一方で、何も決めないまま広がると、重要な業務が見えない仕組みに依存します。必要なのは、重要度に応じて段階的に管理することです。
登録時に確認したい最小項目
- 目的：何の業務を助けるツールか
- 利用範囲：個人、チーム、部署、部署横断のどれか
- 作成者：最初に作った人は誰か
- 所有部署：業務上の責任を持つ部署はどこか
- 保守担当：不具合や変更時に見る人は誰か
- データ：入力元、出力先、正本、保存場所はどこか
- 権限：誰が見てよく、誰が編集できるか
- 停止時影響：止まったときに業務へどの程度影響するか
- 廃止条件：不要になったと判断する条件は何か
ここで大事なのは、登録項目を増やすことではなく、業務の責任境界を見えるようにすることです。誰が作ったかだけでは足りません。誰が使い、誰が守り、誰が正式化・移管・廃止を判断するのかまで置く必要があります。
| 役割 | 担うこと | 曖昧だと起きること |
|---|---|---|
| 作る人 | 現場課題を理解し、簡易ツールやフローを作る | 作成者の頭の中に仕様が閉じる |
| 使う人 | 日常業務で利用し、不具合や改善要望を伝える | 異常に気づいても報告先が分からない |
| 守る人 | 保守、権限、バックアップ、変更管理を見る | 止まったときに復旧できない |
| 判断する人 | 正式化、移管、廃止、代替手段を判断する | 重要度が上がっても管理レベルが変わらない |
落とし穴：見える化を「監視」にしてしまう
正しい目的でも、伝わり方を誤ると現場は防御的になります。
シャドーIT対策でよくある崩れ方は、見える化が監視や摘発として受け取られることです。現場から見ると、自分たちで工夫して業務を回してきたものを、急に「危ないもの」として扱われるように感じる場合があります。
その状態で、利用禁止や申告義務だけを強く出すと、現場は「申告すると面倒になる」と考えます。すると、使われているツールは表に出ず、リスクも把握できません。
見える化の目的は、現場を縛ることじゃなか。業務に入り込んだ仕組みを、点検できる場所に戻すことたい。
そのためには、「登録したら終わり」ではなく、相談できる、正式化できる、廃止できる、引き継げる。そこまで用意したいのよね。
現場改善を安全に育てる仕組み、という言い方のほうが近いばい。
うん。便利なものを消すためではなく、長く安心して使える状態にするためのルールだね。
まとめ：シャドーIT対策は、現場改善とガバナンスをつなぐ設計である
禁止か自由かの二択ではなく、扱える状態へ戻します。
シャドーITは、現場の困りごとと改善意欲から自然に生まれることがあります。だから、存在そのものを一律に悪と見なすと、実態を見誤ります。一方で、管理されないExcelマクロ、個人アプリ、Power Automateフロー、Power Apps、共有フォルダ上の手作りツールが業務に深く入り込めば、属人化、保守不能、権限不備、監査不備、業務停止のリスクになります。
対策の出発点は、禁止ではなく見える化です。どこで何が使われているかを棚卸しし、利用範囲、扱うデータ、停止時影響、所有者、保守者を確認する。そのうえで、重要度に応じて、自己管理、チーム管理、正式管理、廃止、移管へ分けていきます。
生成AIによって、今後は個人がマクロ、スクリプト、簡易アプリ、フローを作るハードルがさらに下がります。作れるものが増えるほど、見える化と運用ルールの重要性は上がります。シャドーIT対策は、現場改善を潰すための統制ではありません。改善を業務の中で安全に育てるための、組織の設計です。