LASSIC Media らしくメディア
市民開発を統制するガバナンスの作り方
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- 市民開発は現場部門の業務改善スピードを高める一方、統制を欠くとシャドーIT化・野良アプリの乱立を招きます。
- 権限・データ・命名規則という3つの統制軸を最初に定めるかどうかが、後の運用負荷を大きく左右します。
- 情シスが禁止する側ではなく支援する側に回り、CoE（センター・オブ・エクセレンス）機能を持つことで、推進と統制の両立に近づきます。
目次
市民開発とガバナンスが同時に語られる理由
市民開発（シチズンデベロップメント）とは、情報システム部門ではなく現場部門の担当者が、ローコード・ノーコードツールを使って自ら業務アプリやワークフローを開発する取り組みを指します。プログラミングの専門知識を持たない従業員でも、画面上の部品を組み合わせるだけで申請フォームや承認フローを作れる点が特徴です。
市民開発が広がる背景には、慢性的なIT人材不足があります。経済産業省「IT人材需給に関する調査」（みずほ情報総研受託、2019年）は、需要の伸びが高いシナリオで2030年に約79万人規模のIT人材が不足すると推計しました*1。情シス部門だけで全社のアプリ開発要望をさばき切れない状況が、現場主導の開発に期待が集まる一因になっています。
一方で、現場が自由にアプリを作れる状態を放置すると、情シスの把握しないシステムが社内に増える事態を招きかねません。IPA（情報処理推進機構）は、ローコード・ノーコードツールの利便性の裏にあるセキュリティリスクを抑えて活用するためのベストプラクティスを、8か条を中心にまとめて公表しています*2。市民開発とガバナンスが常にセットで語られるのは、この推進と統制のバランスを取る必要があるためです。
ここでいうガバナンスとは、開発を禁止する仕組みではありません。誰が・どの範囲で・どのようなルールのもとでアプリを作ってよいかを事前に定め、逸脱を早期に把握できる体制を指します。ルールを明文化しないまま市民開発を広げると、便利さが後になってリスクへと転じかねないでしょう。
統制を欠いた市民開発が招くシャドーIT・野良アプリ
市民開発の統制を怠ると、まず起こりやすいのがシャドーIT化です。情シス部門の許可や把握を経ずに、現場が個別にツールを契約・利用する状態を指します。ローコードツールは導入のハードルが低いため、部門ごとに異なるツールが並行して使われる事態が生じやすくなります。
作った本人しか分からない「野良アプリ」の属人化リスク
次に多いのが、作成者の異動・退職後に誰も仕様を把握できなくなる「野良アプリ」の発生です。エンドユーザーによる開発では、属人化・ブラックボックス化が課題として指摘されており*3、作成者しか触れないアプリが業務の基幹に組み込まれてしまうと、変更や停止の判断すら難しくなります。担当者が不在の間に不具合が起きれば、業務そのものが止まりかねません。
個人情報・機密データの持ち出しにつながる権限設定ミス
ローコードツールは外部との連携やデータ共有も簡単に設定できる分、権限設定を誤ると意図しない範囲まで情報が公開される恐れがあります。顧客情報や人事データを扱うアプリを非専門の担当者が単独で構築すると、アクセス権限の絞り込みが不十分なまま公開される事態が起こりえます。IPAのガイドが適切な活用のための実践項目を整理しているのも、こうした設定ミスが起こりやすいという実務上の課題認識が背景にあります*2。
品質のばらつきが引き起こす業務トラブル
専門部隊が関与しないまま作られたアプリは、入力チェックやエラー処理の作り込みにばらつきが出やすくなります。品質のばらつきは、エンドユーザー開発における代表的な課題の一つとして挙げられています*3。小規模な業務効率化ツールのつもりが、気づけば複数部門の意思決定に使われる基幹的な存在になっているケースも珍しくありません。統制のないまま利用範囲が広がると、後になって品質面の手戻りが大きくなりやすい点に注意が必要です。
権限・データ・セキュリティ — 統制すべき3つの軸
市民開発のガバナンスを設計する際は、権限・データ・セキュリティという3つの軸を最初に整理する進め方が実務的です。この3つを個別に議論すると論点が拡散しやすいため、まとめて検討する方が効率的です。
権限：誰がどこまで作ってよいかを役割ごとに定義する
まず、誰がどの範囲のアプリを作成・公開できるかを役割ごとに定義します。個人の業務効率化ツールと、複数部門が使う共有アプリとでは、求められる承認プロセスの重さが異なるはずです。作成権限・公開権限・データ接続権限を分けて設計すると、リスクの高い操作だけを承認制にできます。
データ：接続先と保存範囲に線を引く
次に、市民開発アプリが接続してよいデータソースの範囲を定めます。基幹システムの本番データへの直接接続や、個人情報を含むデータベースへのアクセスは、情シスの承認を必須にするなど段階を設ける必要があります。データの持ち出し経路を限定することが、情報漏えいの入口を狭めることに直結します。
セキュリティ：認証・監査ログの標準を統一する
最後に、認証方式やアクセスログの記録方法を全社で統一します。ツールごとに認証基準がばらばらだと、インシデント発生時に原因の特定が遅れかねません。IPAのガイドが適切な活用のための実践項目を整理しているように*2、公開されたベストプラクティスを土台に、自社の業務特性に合わせたルールへ落とし込む進め方が現実的です。
この3軸を統制せずに市民開発を許可すると、アプリの数が増えるほど後から手を付けられるリスクの範囲も広がっていきます。最初の設計段階で線引きを済ませておくことが、結果的に運用の負荷を抑える近道になるでしょう。
命名規則と開発標準を全社共通の言語にする
権限・データ・セキュリティの統制と並行して、命名規則と開発標準を整えることも欠かせません。ルールがないまま開発が進むと、後から棚卸しや監査をする際に対象を把握すること自体が難しくなります。
アプリ名・接続先を一目で識別できる命名規則
アプリ名に部門名・用途・作成年度を含める、業務システムに接続するアプリには専用の接尾辞を付けるなど、名称から用途と管理責任者が推測できる規則を定めます。命名規則がないと、似た名前のアプリが乱立し、どれが現在使われているか判別できなくなりがちです。
全社アプリ台帳による可視化
作成されたアプリを一元的に登録する台帳を用意し、作成者・部門・接続データ・公開範囲を記録します。台帳がなければ、情シスは自社にどれだけの市民開発アプリが存在するかを正確に把握できません。台帳への登録を、アプリ公開の必須条件として運用フローに組み込む方法が有効です。
開発標準テンプレートで品質のばらつきを抑える
入力フォームのエラー処理・承認フローの分岐・データ検証など、頻出するパターンをテンプレート化して提供すると、非専門の担当者でも一定水準の品質を保ちやすくなります。ゼロから設計させるのではなく、承認済みのテンプレートを土台に作らせる方が、統制と開発速度の両立につながります。
情シスとCoEが担う役割 — 禁止でなく併走する統制
市民開発のガバナンスを機能させるには、情シス部門が「禁止する側」ではなく「支援する側」に回る発想の転換が必要です。現場の開発意欲を単純に抑え込むと、統制の目が届かない場所で開発が続く結果になりかねません。
この役割を担う機能として、CoE（センター・オブ・エクセレンス。特定分野の知見を組織横断で集約し、標準化と支援を行う機能）の設置が有効な選択肢の一つです。CoEは開発のモニタリング、社内ルールの整備、現場からの相談対応を組織横断で担い、開発環境を整える役割が期待されています。禁止ではなく伴走という関わり方が、市民開発を統制しながら広げる土台になります。
情シスは「監視」ではなく「相談窓口」を用意する
現場が困ったときに相談できる窓口を用意しておくと、無理な自己流の実装を避けられます。相談窓口がない状態では、担当者が自らの判断だけで権限設定を進め、結果的に統制外のアプリが増える悪循環に陥りやすくなります。
承認プロセスは重すぎず軽すぎずに設計する
承認フローを厳格にしすぎると、現場は正規の手続きを避けてシャドーIT化する誘因が強まります。逆に承認を形骸化させると、統制自体が意味を失います。影響範囲の大きさに応じて承認の重さを変える段階的な設計が、両者のバランスを取る現実的な方法です。
内製と外部支援の線引きを決めておく
ガバナンスの枠組み自体をゼロから作るには、他社の事例を知る知見とプロジェクト管理の経験が求められます。自社に知見を蓄積したい領域は内製で担い、初回の枠組み設計や高度な権限設計は外部の支援を借りるという役割分担も、現実的な進め方の一つです。なお、開発者そのものの人材不足を外部委託で補う進め方は別の論点であり、本稿はあくまで統制の仕組みづくりに焦点を当てています。
教育とモニタリングでガバナンスを定着させる
ルールを作っただけでは、市民開発のガバナンスは定着しません。現場が趣旨を理解し、日常的に運用が回る仕組みが必要です。
市民開発者向けの基礎教育を用意する
アプリを作成する現場担当者に対して、権限設定の基本・データ取り扱いの注意点・命名規則の使い方を学べる教育機会を設けます。ルールを配布するだけでは実務に反映されにくいため、実際の操作画面を使った実践的な研修が効果的です。
定期的な棚卸しでアプリの利用実態を確認する
台帳に登録されたアプリを定期的に棚卸しし、利用実態のないアプリや、作成者が退職・異動したアプリを洗い出します。棚卸しを怠ると、台帳と実態が乖離し、監査時に統制が機能していないと判断されかねません。
インシデント事例を組織の学びに変える
権限設定のミスやデータ漏えいの兆候が見つかった場合、個人の責任追及にとどめず、再発防止のためのルール改定につなげます。デジタルガバナンス・コード3.0は、DX経営に求められる視点の一つとして「As is-To beギャップの定量把握・見直し」を挙げており*4、市民開発の統制状況についても定期的な見直しの対象に含める発想が有効です。
この一連の教育・棚卸し・見直しのサイクルを、年次あるいは半期ごとの定例業務として組み込むことが、ガバナンスを一過性の取り組みで終わらせないための実務上のポイントです。ここまでの権限設計・命名規則・役割分担を実際に回す担当者には、業務知識だけでなくITガバナンスの基礎知識と一定の運用工数が求められます。自社での立ち上げが難しい場合は、外部の支援を組み合わせて負荷を分散する選択肢も検討に値するでしょう。
まとめ：市民開発ガバナンスを機能させる3つの判断軸
本稿では、市民開発を統制するガバナンスの作り方を整理しました。要点を3つに集約すると次の通りです。第一に、統制を欠いた市民開発はシャドーIT化・野良アプリの属人化・品質のばらつきを招くため、推進と統制を同時に設計する必要があります。第二に、権限・データ・セキュリティという3つの軸と、命名規則・開発標準の整備が統制の土台になります。第三に、情シスが禁止でなく支援の役割を担い、CoE機能や教育・棚卸しのサイクルを組み込むことで、ガバナンスを一過性で終わらせずに定着させられます。
よくある質問
市民開発の統制はどの部署が主導するべきですか。
情報システム部門が主導しつつ、現場部門の代表者を巻き込んで設計するのが実務的です。情シスだけでルールを作ると現場の実態に合わず形骸化しやすいため、CoEのような組織横断の場で双方の意見を反映させる進め方が有効です。
すでに乱立している野良アプリはどう対処すればよいですか。
まず全社アプリ台帳を作成し、既存アプリの棚卸しから着手します。利用実態・作成者・接続データを確認したうえで、継続利用するアプリは台帳登録とルール適用の対象にし、利用のないアプリは廃止を検討する進め方が現実的です。
市民開発を全面的に禁止するのは有効な対策になりますか。
全面禁止は現場の効率化ニーズを抑え込むだけで、統制の目が届かない場所で開発が続くおそれがあります。禁止よりも、権限・データ・命名規則のルールを整え、相談できる窓口を用意して統制の効いた環境を作る方が実効性の高い対応です。
ローコード人材の不足自体はどう補えばよいですか。
人材そのものの確保は、社内育成と外部の専門知見の活用を組み合わせて検討する論点であり、本稿で扱うガバナンス設計とは別の課題です。ガバナンスの枠組みが整っていることを前提に、開発を担う人材の確保方針をあわせて検討する進め方が望ましいでしょう。
ガバナンスのルールはどのくらいの頻度で見直すべきですか。
年次または半期ごとの定例レビューを設けるのが目安です。アプリの棚卸し結果やインシデントの有無を踏まえてルールを更新し、事業環境やツールの機能変化に合わせて統制の内容を柔軟に見直す運用が求められます。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：経済産業省「IT人材需給に関する調査」（みずほ情報総研株式会社受託、2019年）
- *2 出典：独立行政法人情報処理推進機構（IPA）「ローコード・ノーコードツール セキュリティビギナーズガイド」https://www.ipa.go.jp/jinzai/ics/core_human_resource/final_project/2025/dx_security_measures_committee.html（2025年）
- *3 出典：独立行政法人情報処理推進機構（IPA）「DX白書2023」https://www.ipa.go.jp/publish/wp-dx/gmcbt8000000botk-att/000108041.pdf（2023年）
- *4 出典：経済産業省「デジタルガバナンス・コード3.0～DX経営による企業価値向上に向けて～」https://www.meti.go.jp/press/2024/09/20240919001/20240919001.html（2024年）
