ノーコード・ローコード活用の判断：内製をどこまで広げるか
プログラミングの専門知識がなくても業務アプリを作れるノーコード・ローコードツールが広がり、IT部門に頼らず現場が自ら開発する「市民開発」に取り組む企業が増えています。開発の速さやコスト抑制の効果は大きい一方、無秩序に広げれば誰も保守できない「野良アプリ」が乱立します。本記事では、内製をどこまで広げてよいかを判断する4つの軸と、現場の速度を落とさずに統制を効かせる設計のポイントを、公的な調査をふまえて整理します。
なぜいま「市民開発」が注目されるのか
市民開発とは、ITの専門部署ではない業務部門の社員が、ノーコード・ローコードツールを使って自ら業務アプリや自動化のしくみを作り、運用する取り組みを指します。表計算やメールで手作業していた集計・申請・進捗管理などを、現場の担当者自身がアプリ化できる点が特徴です。
背景には、日本企業のDXが「内向き・部分最適」にとどまりがちだという構造的な課題があります。独立行政法人情報処理推進機構（IPA）が2025年6月に公表した「DX動向2025」では、日本企業は個別の業務プロセスの最適化に取り組む割合が高く、米国・ドイツは全社的な最適化に取り組む割合が高いと報告されています。同調査では、DXの成果が「出ている」とする企業が米独では8割を超える一方、日本は6割弱にとどまりました。現場が自ら小さな改善を積み上げられる市民開発は、この停滞を崩す一手として期待されています。
同時に、人材面の制約も無視できません。「DX動向2025」では、DXを推進する人材が「不足している」と感じる日本企業が8割を超えています。IT部門だけで全社のシステム需要をさばききれないという現実が、現場主導の内製を後押ししているのです。
広げすぎた内製が生む「野良アプリ」のリスク
一方で、ガバナンスの枠組みがないまま内製を広げると、「作れる」という長所がそのまま組織の混乱につながります。代表的なリスクは次の3つです。
1. シャドーIT・野良アプリの乱立
IT部門が把握しないところでアプリが増えると、セキュリティ設定が不十分なまま社外のサービスと連携したり、重要なデータが個人の管理下に置かれたりします。ガートナージャパンが2021年2月に実施した調査では、ユーザー部門の回答者の62％が「エンドユーザーが開発したアプリケーションがある」と回答しました。現場で作られたアプリをIT部門が把握しきれていない実態もあわせて指摘されており、作る側と管理する側の認識のズレが、誰も管理していないアプリ群を生みます。
2. 属人化とブラックボックス化
作った担当者が異動・退職すると、仕様が分からず誰も直せないアプリが残ります。これは、経済産業省が2018年の「DXレポート」で警鐘を鳴らしたレガシーシステムのブラックボックス化と同じ構図を、現場レベルで新たに生むことにほかなりません。
3. 品質とデータのばらつき
開発者のスキルによって品質に差が出たり、同じ情報が複数のアプリに分散して整合が取れなくなったりします。全社の意思決定に使うデータが、現場ごとに別の数字を示す状態は避けなければなりません。
内製をどこまで広げるかを決める4つの軸
すべてを現場に任せるか、すべてをIT部門が抱えるかの二択ではありません。アプリごとに次の4つの軸で評価し、広げてよい領域と慎重にすべき領域を分けると判断がぶれにくくなります。
- 影響範囲：使うのは個人か、部署内か、全社・顧客にまで及ぶか。範囲が広いほど統制を強める
- データの機微性と基幹連携：個人情報や会計・基幹システムのデータを扱うほど、IT部門の関与を必須にする
- 保守体制：作った本人以外に引き継げるか。属人化しやすいものほど、ドキュメントと管理台帳を求める
- 変更頻度と要件の固まり具合：要件が頻繁に変わる業務は現場内製が向き、安定した基幹処理は標準化・外部開発が向く
現場に積極的に広げてよい領域
- 個人・少人数で使う集計や通知の自動化など、影響範囲が狭い業務
- 要件が頻繁に変わり、現場でなければ仕様が固まらない業務
- 既存の基幹データを参照するだけで、書き換えを伴わない業務
IT部門の関与を必須にすべき領域
- 全社や社外の顧客が使う、止まると業務に影響するアプリ
- 個人情報・決済・会計など、機微なデータを扱う処理
- 基幹システムへの書き込みや、複数システムをまたぐ連携を伴う処理
内製と外注・標準パッケージの使い分けについては、判断軸をより広く整理した別記事もあわせて参照してください。市民開発は「内製」の一形態であり、その内側でさらに現場とIT部門の線引きを設計する、という位置づけで考えると整理しやすくなります。
速度を落とさずに統制を効かせる進め方
統制というと申請と承認でがんじがらめにする印象がありますが、それでは現場の速さという最大の利点が失われます。影響範囲に応じて審査の重さを変える「段階的なガバナンス」が現実的です。
- 影響範囲で3段階に分ける：個人用の小さな自動化は原則自由、部署内アプリは部門内でのレビュー、全社・顧客影響のアプリはIT部門の審査を必須にする
- 使ってよいツールと禁止事項を定める：利用を認めるツール、連携してよい外部サービス、個人情報の取り扱い方針を明文化する
- 管理台帳を一つ持つ：誰が・何のために・どのデータを使うアプリを作ったかを登録し、作成者が去っても追えるようにする
- 推進役と相談窓口を置く：現場とIT部門をつなぐ担当を決め、作り方の相談とレビューを受けられる体制にする
- 小さく始めて横展開する：一つの部署でルールと成功例を作り、再利用できるテンプレートとして全社に広げる
近年はノーコード・ローコードツールに生成AIの支援機能が組み込まれ、作成のハードルはさらに下がっています。だからこそ、誰が何を作っているかを把握するしくみと、現場・IT部門・経営の役割分担をあらかじめ決めておくことの重要性が増しています。ツールを入れることよりも、広げ方と止め方を先に設計することが、内製を資産に変えるか負債に変えるかの分かれ目になります。
この記事のまとめ
- ノーコード・ローコードによる市民開発は、人材不足と「内向き・部分最適」から脱する一手だが、無秩序に広げると野良アプリ・属人化・品質のばらつきを招く
- 内製をどこまで広げるかは、影響範囲・データの機微性と基幹連携・保守体制・変更頻度の4つの軸でアプリごとに評価する
- 影響範囲が狭く要件が変わりやすい業務は現場に広げ、全社・顧客影響や機微なデータ・基幹連携を伴う処理はIT部門の関与を必須にする
- 統制は一律の承認ではなく、影響範囲で審査の重さを変える段階的ガバナンスと、管理台帳・推進役・ツール方針で設計する
よくある質問
ノーコードとローコードの違いは何ですか？
ノーコードは原則コードを書かずに画面操作だけでアプリを作れるツール、ローコードは最小限のコードで機能を拡張できるツールを指します。現場主体の小規模な自動化はノーコード、ある程度の拡張や連携が必要な業務はローコードが向く傾向があります。
市民開発を始めるとき、最初に決めるべきことは何ですか？
使ってよいツールと禁止事項、そして影響範囲に応じた審査の段階を最初に決めることです。あわせて、作られたアプリを登録する管理台帳と、現場とIT部門をつなぐ相談窓口を用意すると、把握できないアプリの乱立を防げます。
すべての業務を市民開発で内製すべきですか？
いいえ。全社や顧客が使う基幹的なアプリ、個人情報や会計などの機微なデータを扱う処理、基幹システムへの書き込みを伴う処理は、IT部門の関与や外部開発・標準パッケージの活用を検討すべき領域です。影響範囲と変更頻度で向き不向きを見極めます。
自社のDXで、現場主導の内製をどこまで広げるべきか迷われている場合は、組織体制づくりや業務改革のご支援を通じてご一緒に整理します。まずはお気軽にご相談ください。
支援の具体例 → ノアブリッジの導入事例を見る