ノーコード開発のガバナンス｜市民開発者のルール設計と野良アプリ防止策

kintone、Power Apps、Bubbleなどのノーコード/ローコードツールの普及により、プログラミング経験のない業務担当者——市民開発者（Citizen Developer） が自らアプリを作る時代が到来した。Gartnerは「2026年までに、企業の新規アプリケーションの70%がノーコード/ローコードで開発される」と予測している。

しかし、ガバナンスなき市民開発は 「野良アプリ」の温床 になる。誰が作ったか分からないアプリ、セキュリティ設定が甘いアプリ、作成者の退職で保守不能になったアプリ——これらはシャドーITと同じリスクを抱える。

本記事では、市民開発のメリットを活かしつつ、リスクを管理するためのガバナンス設計方法を解説する。

---

野良アプリとは何か

野良アプリの定義と実態

野良アプリとは、IT部門の管理下にない、業務担当者が独自に作成したアプリケーションのことだ。

項目	管理されたアプリ	野良アプリ
開発者	IT部門 or 承認済み市民開発者	業務担当者が非公式に作成
管理台帳への登録	あり	なし
セキュリティレビュー	実施済み	未実施
データのバックアップ	定期実施	なし（個人PCに依存）
作成者退職時の引継ぎ	手順あり	誰も内容を把握していない

野良アプリが引き起こす5つのリスク

リスク	具体例
1. セキュリティ	個人情報を含むデータがパスワードなしで共有されている
2. データの整合性	同じ顧客情報が複数アプリに分散し、どれが正しいか不明
3. 保守の断絶	作成者が退職し、アプリの修正も停止もできない
4. コンプライアンス	個人情報保護法に抵触するデータ管理が行われている
5. コストの見えない増加	ノーコードツールのライセンスが部門ごとに乱立

---

ガバナンスフレームワーク：4つの柱

柱1：市民開発者の認定制度

誰でも自由にアプリを作れる状態から、「認定を受けた市民開発者のみが開発できる」 制度に移行する。

レベル	権限	認定条件
Level 1：利用者	既存アプリの利用のみ	なし
Level 2：簡易開発者	個人業務の効率化アプリを作成可能	セキュリティ基礎研修（2時間）を修了
Level 3：部門開発者	部門で共有するアプリを作成可能	Level 2 + ガバナンス研修（4時間）+ IT部門のレビュー合格
Level 4：全社開発者	全社で利用するアプリを作成可能	Level 3 + IT部門との共同開発経験

柱2：アプリ管理台帳

作成されたすべてのアプリを一元管理する台帳を運用する。

管理項目	内容
アプリ名	正式名称と概要
作成者	部署、氏名、連絡先
利用範囲	個人/部門/全社
使用データ	個人情報の有無、機密情報の有無
ツール	kintone/Power Apps等
作成日・最終更新日	放置アプリの検知に使用
バックアップ方法	データのバックアップ手順
引継ぎ先	作成者が異動・退職した場合の後任

柱3：セキュリティ基準

市民開発者が守るべきセキュリティルールを明文化する。

• [ ] 個人情報を含むアプリは必ずIT部門にレビュー依頼する
• [ ] アクセス権限は「必要最小限の原則」で設定する
• [ ] 外部公開（社外からのアクセス）は原則禁止。必要な場合はIT部門の承認を得る
• [ ] テストデータに本番の個人情報を使わない
• [ ] アプリのパスワードを個人の記憶だけに依存しない（パスワードマネージャーを使用）

柱4：ライフサイクル管理

アプリには「作る→使う→見直す→廃止する」のライフサイクルがある。

• 半年ごとの棚卸し：管理台帳のアプリが現在も利用されているか確認
• 3ヶ月以上更新がないアプリ：作成者に利用状況を確認
• 1年以上利用のないアプリ：データをバックアップし廃止

---

導入の3ステップ

ステップ1：現状の野良アプリを棚卸しする（2週間）

• 各部門に「ノーコードツールで作成したアプリはありますか」とヒアリング
• ツールの管理コンソールから作成済みアプリの一覧を取得
• 個人情報を含むアプリを最優先で管理台帳に登録

ステップ2：ガバナンスルールを策定・周知する（2週間）

• 上記の4つの柱をベースにルールを文書化
• 全社メールまたは社内ポータルで周知
• 市民開発者向け研修を実施（2〜4時間）

ステップ3：運用サイクルを回す（継続）

頻度	実施内容
月次	新規作成アプリの台帳登録確認
四半期	セキュリティレビュー（個人情報を扱うアプリ優先）
半年	全アプリの棚卸し（休止・廃止判定）
年次	ガバナンスルールの見直し・更新

---

まとめ

項目	ポイント
市民開発のメリット	IT部門の工数を使わず業務アプリを迅速に作成できる
最大のリスク	野良アプリの乱立（セキュリティ・保守・コスト）
ガバナンスの4つの柱	認定制度、管理台帳、セキュリティ基準、ライフサイクル管理
最初の一歩	現在の野良アプリの棚卸しから始める

市民開発は「禁止」するのではなく「管理」することで、DXの強力な推進力になる。

---

GXO実務追記: レガシー刷新で発注前に確認すべきこと

この記事のテーマは、単なるトレンド紹介ではなく、現行調査、刷新範囲、段階移行、ROI、ベンダー切替リスクを決めるための検討材料です。検索で情報収集している段階でも、発注前に次の観点を整理しておくと、見積もりのブレ、手戻り、ベンダー依存を減らせます。

まず決めるべき3つの論点

論点	確認する内容	未整理のまま進めた場合のリスク
目的	売上拡大、工数削減、リスク低減、顧客体験改善のどれを優先するか	成果指標が曖昧になり、PoCや開発が終わっても投資判断できない
範囲	対象部署、対象業務、対象データ、対象システムをどこまで含めるか	見積もりが膨らむ、または重要な連携が後から漏れる
体制	自社責任者、現場担当、ベンダー、保守運用者をどう置くか	要件確認が遅れ、納期遅延や品質低下につながる

費用・期間・体制の目安

フェーズ	期間目安	主な成果物	GXOが見るポイント
事前診断	1〜2週間	課題整理、現行確認、投資判断メモ	目的と範囲が商談前に整理されているか
要件定義 / 設計	3〜6週間	要件一覧、RFP、概算見積、ロードマップ	見積比較できる粒度になっているか
PoC / MVP	1〜3ヶ月	検証環境、効果測定、リスク評価	本番化判断に必要な数値が取れるか
本番導入	3〜6ヶ月	本番環境、運用設計、教育、改善計画	導入後の運用責任と改善サイクルがあるか

発注前チェックリスト

• [ ] 現行システムの機能、利用部署、データ、外部連携を一覧化したか
• [ ] 保守切れ、属人化、障害頻度、セキュリティリスクを金額換算したか
• [ ] 全面刷新、段階移行、SaaS置換、リホストの比較表を作ったか
• [ ] 移行中に止められない業務と、止めてもよい業務を分けたか
• [ ] 既存ベンダー依存から抜けるためのドキュメント/コード引継ぎ条件を決めたか
• [ ] 稟議で説明する投資回収、リスク低減、保守費削減の根拠を整理したか

参考にすべき一次情報・公的情報

• 経済産業省 DX政策
• IPA デジタルスキル標準・DX関連情報
• デジタル庁 標準ガイドライン群
• NIST Cybersecurity Framework

上記の一次情報は、社内稟議やベンダー比較の根拠として使えます。一方で、公開情報だけでは自社の現行システム、業務フロー、データ状態、予算制約までは判断できません。記事で一般論を把握した後は、自社条件に落とした診断が必要です。

GXOに相談するタイミング

次のいずれかに当てはまる場合は、記事を読み進めるだけでなく、早めに相談した方が安全です。

• 見積もり依頼前に、要件やRFPの粒度を整えたい
• 既存ベンダーの提案が妥当か第三者視点で確認したい
• 補助金、AI、セキュリティ、レガシー刷新が絡み、判断軸が複雑になっている
• 社内稟議で費用対効果、リスク、ロードマップを説明する必要がある
• PoCや診断で終わらせず、本番導入と運用改善まで進めたい

関連記事

• ノーコードプラットフォーム比較2026——主要ツールの選び方
• ノーコードの限界とリプレイス判断——スクラッチ開発への移行基準
• シャドーIT検知・防止ガイド——野良アプリの上位リスク
• iPaaS入門——ノーコード連携ツールの活用
• GXOの導入事例一覧——ガバナンス設計の支援実績

---