野良アプリと属人化を防ぐ：ガバナンスの基本ルール｜ノーコードで進める業務改善 第5回

野良アプリが生む4つのリスク

野良アプリをそのままにしておくと、図1のようなリスクが生まれます。

1. 作った人がいなくなると止まる
作った人が異動・退職すると、仕組みの中身を誰も分からなくなります。個人のアカウントで作っていた場合は、アカウントの停止とともに、アプリや自動化そのものが動かなくなることもあります。

2. 個人情報や機密情報の扱いが分からない
顧客の個人情報を扱うアプリが、誰が見られる設定になっているのか、どの外部サービスにデータが送られているのかが、会社として把握できていない状態は危険です。

3. 似たアプリが乱立して、データがばらばらになる
部署ごとに似たような顧客管理のアプリを作ると、同じ顧客の情報が何か所にも分散し、どれが正しいのか分からなくなります。

4. 止まっても気づかれない
第3回で学んだように、自動化はときどき失敗します。管理者がいなければ、失敗が放置され、業務に影響が出てから初めて気づくことになります。

野良アプリを防ぐ7つの基本ルール

ガバナンスというと、厳しい規則や面倒な申請を想像するかもしれません。しかし、ノーコードのガバナンスで大切なのは、最小限のルールを、守りやすい形で決めることです。図2の7つが、その基本です。

ルール1：台帳に登録する
作ったアプリや自動化は、社内の台帳に登録します。台帳には、名前、目的、管理者、利用者、扱うデータ、つながっている道具、作成日と最終更新日を書きます。台帳があれば、「何が、どこで動いているか」を会社として把握できます。表計算1枚から始めてかまいません。

ルール2：管理者を正と副の2人にする
1つの仕組みに、必ず2人の管理者を決めます。1人が不在でも、もう1人が対応できるようにするためです。管理者が異動するときは、引き継ぎを台帳に記録します。

ルール3：名前のつけ方をそろえる
「【部署名】業務名_用途」のように、名前のつけ方を決めておきます。似たアプリが増えても一覧で見分けやすくなり、台帳との照合も簡単になります。

ルール4：会社のアカウントで作る
個人のアカウントや、個人で契約したサービスで業務の仕組みを作らないようにします。会社として契約したサービスの、会社のアカウントで作れば、担当者が替わっても仕組みは残ります。

ルール5：扱ってよいデータの区分を守る
次の節で詳しく説明します。

ルール6：外部サービスとの連携は事前に確認する
ワークフロー自動化で新しい外部サービスとつなぐときは、情報システム部門などに事前に確認します。データがどこに送られ、どう扱われるかを確かめるためです。

ルール7：使わなくなったら廃止の手続きをする
使われなくなったアプリや自動化を放置すると、古い情報が残り続けたり、知らないうちに自動化が動き続けたりします。廃止するときは、データの保管か削除かを決め、台帳に記録します。

データの区分：何を、どの仕組みで扱ってよいか

ルール5の「データの区分」は、ガバナンスの中でも特に大切です。すべてのデータを同じように扱うのではなく、図3のように、データの重要度に応じて、扱える場所や方法を分けます。

区分の数は、最初は図3のような3段階で十分です。大切なのは、作り手が「このデータはどの区分か」を迷わず判断できることです。迷ったときは、より慎重な区分として扱う、と決めておきましょう。

道具によっては、こうしたルールを仕組みとして設定できるものもあります。たとえばMicrosoftのPower Platform（Power AppsやPower Automateなど）では、管理者がつなぎ先のサービス（コネクタ）を「ビジネス」「ビジネス以外」「ブロック」の3つのグループに分けて設定できます。異なるグループのつなぎ先は、1つのアプリや流れの中で一緒に使えず、ブロックしたつなぎ先は使えなくなります。たとえば、社内の文書管理サービスを「ビジネス」、個人向けのメールサービスを「ビジネス以外」にしておけば、社内の文書を個人のメールに送る流れは作れなくなります。

このように、ルールを人の注意だけに頼らず、道具の設定で守れるところは設定で守るのが、安全で現場の負担も少ない方法です。

野良アプリを見つけたら

ルールを始める前から動いている仕組みや、ルールの外で作られた仕組みが見つかることもあります。そのときに大切なのは、作った人を責めないことです。責められると、他の人は作った仕組みを隠すようになり、かえって把握が難しくなります。

見つけた仕組みは、まず台帳に登録し、管理者を決めます。そのうえで、扱っているデータの区分を確かめ、個人情報や機密情報を扱っているのに設定が不十分なものから順に、見られる人の範囲や外部との連携を見直します。使われていないものは、作った人と相談して廃止します。「見つけたら一緒に整える」という姿勢が、作り手が自分から登録してくれる文化につながります。

推進体制：現場の自由と全社の安全を両立する

ルールを決めても、それを支える体制がなければ守られません。ノーコードを全社に広げている会社では、図4のような体制がよく見られます。

• 推進事務局：ルールと台帳を管理し、作り手からの相談に乗り、勉強会や事例の共有会を開きます。少人数でも、担当を決めておくことが大切です。
• 各部署の作り手：業務を知る現場の人が、ルールに沿って仕組みを作ります。社外向けの資料では「市民開発者」と呼ばれることもあります。
• 情報システム部門：セキュリティやデータの扱い、外部サービスとの連携を確認し、道具の設定（データの区分など）を管理します。
• 経営層：ノーコードによる業務改善を後押しし、作り手が改善に時間を使えるよう、業務の一部として認めます。

推進事務局の大切な役割の一つが、作り手どうしをつなぐことです。ある部署で作った便利な仕組みを、別の部署でも使えないかを紹介したり、作り手が集まって悩みを共有する場を設けたりすると、似たアプリの乱立を防ぎながら、良い取り組みが社内に広がっていきます。

よくある誤解：「ルールは最初に全部決めておくべき」

ガバナンスのルールを、最初から完璧に整えようとすると、決めることが多すぎて、ノーコードの取り組みそのものが始まりません。また、厳しすぎるルールは、現場の作り手を遠ざけ、かえって隠れた野良アプリを増やすことになります。

まずは図2の7つのうち、台帳・管理者2人・会社のアカウント・データの区分の4つから始め、仕組みが増えてきたら残りを足していく、という進め方で十分です。

この記事の監修者に相談できます

監修者の田中磨生が代表を務める株式会社Abinで、ご相談をお受けしています。

相談無料ツギノテ編集部に相談する→

アプリの一生を管理する

最後に、1つのアプリや自動化の「一生」を、図5の流れで管理する考え方を紹介します。

特に大切なのが、半年に一度の棚卸しです。台帳に載っているアプリや自動化が、今も使われているか、管理者は替わっていないか、扱うデータは変わっていないかを確認します。棚卸しのときに、使われていないものは廃止し、似たアプリがあれば統合を検討します。社内で使っているクラウドサービス全体の把握には、SaaS管理ツールおすすめ比較で紹介しているような道具も役立ちます。

実務ではこう使う：ガバナンスを始める最初の1か月

ガバナンスの仕組みを、1か月で立ち上げる進め方の例です。

1. 1週目：今ある仕組みを洗い出す。各部署に「ノーコードで作ったアプリや自動化」を聞き、表計算の台帳にまとめる
2. 2週目：台帳の各仕組みに、管理者を正と副で決める。個人のアカウントで作られているものを洗い出す
3. 3週目：データの区分を決め、個人情報を扱う仕組みの設定（見られる人、外部との連携）を確認する
4. 4週目：7つのルールのうち最初の4つを社内に知らせ、相談窓口を開く

すでに多くの仕組みが動いている場合は、まず個人情報を扱っているものから確認するのがおすすめです。こうした体制づくりを外部の支援を受けて進めたい場合は、DXコンサル・DX支援会社おすすめ比較も参考になります。

この回のまとめ

• 野良アプリは、業務を良くしたい前向きな気持ちから生まれる。禁止ではなく、把握と管理の仕組みで防ぐ
• リスクは、作った人がいなくなると止まる・データの扱いが分からない・乱立してデータがばらばら・止まっても気づかれない、の4つ
• 7つの基本ルールは、台帳・管理者2人・名前のつけ方・会社のアカウント・データの区分・外部連携の確認・廃止の手続き
• データは重要度で区分し、道具の設定で守れるところは設定で守る
• 推進事務局・作り手・情報システム部門・経営層で支える。ルールは最初の4つから始め、半年に一度棚卸しする

確認テスト

次回予告

最終回の第6回は「内製か外注か」です。ノーコードで自分たちで作るべきものと、外部の力を借りるべきものをどう見分けるか、外部の支援の種類と上手な頼み方、そして3年間の費用での比べ方を学びます。

参考資料

• Microsoft Learn「Connector classification」（Power Platform のデータポリシー） https://learn.microsoft.com/power-platform/admin/dlp-connector-classification （確認日：2026年11月12日）