市民開発とは？ツール・課題と野良アプリを防ぐルールを解説

市民開発とは、IT部門のエンジニアではない現場の担当者が、ノーコード・ローコードツールなどを使って業務アプリを自ら作る取り組みです。

「ツールを配れば現場が自走する」と考えられがちですが、重要なのはどの業務まで現場に任せ、どのルールで管理するかを先に決めることです。この記事では、プロ開発との違い、ツールの種類、向く業務・向かない業務、野良アプリを防ぐルール、進め方を解説します。

⇒ 自社の担当者で作り、自分たちで改善し続けたい方へ。AI駆動セルフ開発ツール「S-MASE」の詳細を見る

市民開発とは？

市民開発とは、業務を担う現場の担当者が、自分たちの業務に使うアプリや仕組みを自ら作り、改善していく取り組みです。英語では「Citizen Development」と呼ばれ、プログラミングを専門としない人でも開発に参加できる、という意味が込められています。

身近なたとえでいえば、表計算ソフトで部署の集計表を作り、使いながら直していく作業の延長線上にあります。違いは、作るものが表から、入力画面・承認の流れ・データベースを備えた「アプリ」に広がった点です。

市民開発者（シチズンデベロッパー）とは

市民開発者とは、市民開発の担い手となる現場の担当者のことで、「シチズンデベロッパー」とも呼ばれます。営業事務、経理、総務、製造現場の管理者など、業務の内容と困りごとを一番よく知る人が想定されています。

言い換えとしては「現場主導の開発」「業務部門による内製開発」などの表現も使われます。いずれも、IT部門や外部の開発会社に頼む前に、まず現場が自分で形にするという点が共通しています。

外注・プロ開発との違い

市民開発と、IT部門のエンジニアによるプロ開発、外部の開発会社への外注は、誰が作るかだけでなく、作る対象と品質の責任の持ち方が異なります。

比べる点	市民開発	プロ開発（IT部門）	外注（開発会社）
作る人	業務を担う現場の担当者	社内のエンジニア	外部のエンジニア
主な対象	部門内の業務アプリ、申請・集計の仕組み	全社の業務システム、基幹システムとの連携	大規模なシステム、社外向けのサービス
完成までの速さ	速い（現場の判断ですぐに直せる）	中程度（社内の優先順位に左右される）	要件定義・契約を含めて長くなりやすい
品質・保守の責任	作った部門（ルールで補う必要がある）	IT部門	契約で定めた範囲を開発会社が負う
主な道具	ノーコード・ローコードツール	プログラミング言語、開発基盤	プログラミング言語、開発基盤

外注は大きなシステムを作れる一方、仕様や設計の情報が社内に残らないと、外部の会社に頼り続ける状態になりやすい点に注意が必要です。この状態については「ベンダーロックインとは？原因・リスクと抜け出し方をわかりやすく解説」で解説しています。

ノーコード・ローコードとの関係

ノーコード・ローコードは市民開発の「道具」で、市民開発は道具を使って現場が作る「取り組み」です。ノーコードはプログラムを書かずに画面の操作で作る方法、ローコードは少しのプログラムを加えて作る方法を指します。

そのため、ツールを導入しただけでは市民開発は根付きません。誰が作り、誰が確認し、作ったものを誰が持ち続けるかまで決めて、はじめて取り組みとして回り始めます。

市民開発が注目される背景

市民開発が注目される理由は、IT部門だけでは現場の改善要望に応えきれない状況が広がっていることにあります。

内製化を担う人材が足りない

IPA（独立行政法人情報処理推進機構）の「DX動向2024」では、システム開発の内製化を「進めている」と回答した企業に課題を尋ねたところ、「人材の確保や育成が難しい」が87.4%と突出していました（次いで「新しい技術への対応が難しい」39.4%、「開発量の増減への対応が難しい」36.4%）。調査は2024年2月〜5月に実施され、同年6月27日に公表されています。

開発を社内に取り込もうとしても、エンジニアをすぐに増やすことは難しいのが実情です。そこで、業務を知る現場の担当者にも作り手になってもらう選択肢として、市民開発が検討されるようになりました。ただし、市民開発はエンジニアの代わりではなく、エンジニアが担うべき開発に集中するための役割分担と捉えるほうが実態に合います。

小さな改善がIT部門の順番待ちになる

現場の「この申請を紙からなくしたい」「この集計を自動にしたい」という要望は、一つひとつは小さくても数が多くあります。IT部門は全社のシステムや障害対応を優先せざるを得ず、小さな要望は後回しになりがちです。

市民開発は、このような小さな改善を現場の手で進め、IT部門の負担を減らす狙いもあります。要望を出してから形になるまでの時間が短くなるため、業務の変化に合わせて仕組みを直しやすくなる点も利点です。

市民開発ツールの種類

背景が見えると、次に気になるのは何で作るかです。市民開発ツールは、作れるものの範囲によっておおむね4つの種類に分けられます。

種類	作れるものの例	製品の例	向く用途
ワークフロー・申請型	申請・承認の流れ、電子フォーム	ワークフローシステム各種	紙やメールで回している申請の電子化
データベース・業務アプリ型	案件管理、顧客リスト、日報	kintone	部門内の情報の共有と集計
ローコード開発基盤	複数の部門で使う業務アプリ、他システムとの連携	Power Apps、Mendix	IT部門と現場が一緒に作る業務アプリ
生成AIでアプリを作るツール	指示文から作る画面や簡単なツール	各社のAIアプリ作成機能	試作や個人・小さなチームの業務の効率化

ワークフロー・申請型

申請・承認の流れを画面上で組み立てるタイプです。経費精算や稟議など、すでに決まった手順がある業務を電子化するところから始めやすく、市民開発の入り口として選ばれることがあります。業務の電子化に使えるツール全般は「DX化に役立つツール15選！特徴や導入する際のポイントを徹底解説！」で紹介しています。

データベース・業務アプリ型

表計算ソフトのように項目を並べて、案件管理や日報などのアプリを作るタイプです。サイボウズの「kintone」がよく知られています。部門内の情報を1か所に集め、一覧や集計を誰でも見られるようにする用途に向いています。

ローコード開発基盤

Microsoftの「Power Apps」やSiemensの「Mendix」のように、画面の操作に加えてプログラムや他システムとの連携も扱える基盤です。作れるものの幅が広い分、環境や権限の管理を含めて、IT部門が関わりながら使うことが多くなります。

生成AIでアプリを作るツール

指示文（プロンプト）を入力すると、画面や簡単な処理をAIが作るツールも増えています。試作が短時間でできる反面、作られたものの中身を作った本人も把握しにくく、管理されないアプリが増えやすい点に注意が必要です。AIを使った開発全体の考え方は「AI駆動開発とは？従来開発との違い・やり方・注意点をわかりやすく解説」をご覧ください。

市民開発に向く業務・向かない業務

ツールで作れる範囲が広がるほど、問題になるのは「どこまで現場に任せてよいか」です。判断の軸は、そのアプリを誰が使うか（部門内か、全社か、社外の顧客か）と、扱うデータの重さ（個人情報・機密情報を含むか）の2つです。

向く：部門内で使う定型業務・データ管理

部門内の申請、日報、案件や在庫の管理表など、使う人が限られ、業務の手順が決まっているものは市民開発に向いています。止まっても業務を手作業に戻せる程度の影響で済むため、現場で作りながら直していけます。

IT部門と一緒に作る：部門をまたぐ業務・重いデータを扱う業務

複数の部門が使う業務や、顧客の個人情報・人事情報などを扱う業務は、現場だけで作り切らないほうが安全です。画面や項目は現場が考え、データの置き場所と権限の設計はIT部門が確認する、という分担にすると、速さと安全性を両立しやすくなります。

向かない：基幹システムと、社外の顧客が使うサービス

会計や生産管理などの基幹システムは、止まったときの影響が大きく、市民開発の対象にはなりにくい領域です。また、社外の顧客が使うサービスや新規事業は、会員登録、決済、問い合わせ対応、利用者が増えたときの負荷など、社内の業務アプリとは別の要件が求められます。この領域の作り方は、後半の「顧客向けサービスや新規事業を事業部門で作るには」で取り上げます。

市民開発の課題とよくある失敗

任せる範囲を決めずに始めると、市民開発は思わぬ形でつまずきます。課題の多くは、作ることより「作ったあと」の管理から生まれます。

野良アプリが増える

野良アプリとは、IT部門や管理者が把握していないところで作られ、使われ続けている業務アプリのことです。なお、Web上で「野良アプリ」と検索すると、スマートフォンで公式ストアを通さずに入れるアプリの意味で使われている例も多く見つかります。この記事では、社内で管理されていない業務アプリの意味で扱います。

野良アプリは、誰がどのデータを扱っているのかが見えなくなる点が問題です。退職者のアカウントが残ったまま、顧客情報を含むアプリが社外から見られる設定になっていた、といった事態は、存在を把握していなければ気づくこともできません。

作った人しか直せない

市民開発で作られたアプリは、作った本人の頭の中にしか設計の意図がないことがあります。担当者が異動や退職をすると、誰も直せないまま使われ続けるか、業務ごと止まってしまいます。この「属人化」は、野良アプリと並んで起きやすい失敗です。

品質とセキュリティの責任があいまいになる

プロ開発であれば、テストや権限の設計はIT部門や開発会社の仕事です。一方、市民開発では作った部門が責任を持つことになりますが、その範囲が決まっていないと、誰も確認しないまま公開されることがあります。

ツールを入れただけで定着しない

ツールのアカウントを配っても、作り方を学ぶ時間や相談先がなければ、一部の詳しい人しか使わずに終わります。反対に、使う人が増えすぎて管理が追いつかなくなる例もあり、どちらの場合も、始める前に体制を決めていなかったことが原因です。

野良アプリを防ぐセキュリティ・ガバナンスのルール

課題の多くは、ツールの機能ではなくルールで防げます。市民開発のガバナンス（統制）は、現場の自由を奪うためではなく、安心して作り続けられる範囲を示すために設けるものです。

作ってよい範囲と扱ってよいデータを決める

最初に決めるのは、前の章で見た「向く・向かない」の線引きを、社内のルールとして文書にすることです。あわせて、扱ってよいデータを「一般」「社外秘」「個人情報」などに分け、現場だけで扱ってよいのはどこまでかを示します。線引きがあれば、現場は迷わずに作り始められます。

環境を分け、つないでよいサービスを決める

試しに作る場所と、実際の業務で使う場所（本番）を分けておくと、作りかけのアプリが業務データに触れることを防げます。Microsoftの公式ドキュメントでも、Power Platformの環境を「すべてのリソースのコンテナー」と位置づけ、開発・テスト・運用など目的に応じた使い分けを挙げています（Microsoft Learn「Power Platform におけるセキュリティとガバナンスに関する考慮事項」、2026年5月4日更新）。

同じドキュメントでは、データ ポリシー（DLP）によって、業務データを扱う接続先と、それ以外の接続先を分けて扱うことも示されています。たとえば、社内のデータベースと個人向けのクラウドサービスを同じアプリでつなげないようにする、といった設定です。ツールが違っても「作る場所を分ける」「データの出口を決める」という考え方はそのまま使えます。

アプリごとに管理者を決めて棚卸しする

アプリを公開するときは、作った人とは別に「管理者」を登録し、異動や退職のときに引き継ぐ決まりにします。そのうえで、半年に1回などの周期で、どのアプリが誰に使われているかを一覧にして確かめます。この棚卸しが、野良アプリを生まないための基本になります。

公開前に確認し、使わないアプリは廃止する

部門をまたいで使うアプリや、重いデータを扱うアプリは、公開前にIT部門が権限と公開範囲を確認する手順を設けます。また、一定期間使われていないアプリは持ち主に確認したうえで止める、という廃止のルールも決めておきます。作る手順だけでなく、終わらせる手順まで決めておくことがポイントです。

IT部門と事業部門の役割を分ける

IT部門は、ツールの選定、環境と権限の管理、ルールづくり、相談窓口を担います。事業部門は、業務に合わせたアプリづくりと日々の改善、管理者としての責任を担います。IT部門が「止める係」ではなく「支える係」として関わると、現場は相談しながら作れるようになります。

市民開発の進め方5ステップ

ルールの全体像が見えたら、あとは小さく始めて広げていきます。最初から全社に広げず、1つの部門・1つの業務で成功例を作ってから横に展開するのが基本です。

対象の業務を選ぶ

最初の題材は、部門内で完結し、手作業の手間がはっきりしている業務が向いています。効果が見えやすいため、周りの部門にも広げやすくなります。

ルールとツールを決める

前の章のルールを、まずは最小限の形で決めます。ツールは、すでに社内で契約しているものがあれば、その中から選ぶと管理の手間を増やさずに済みます。

小さく作って使ってみる

最初から完璧を目指さず、必要な項目と画面だけで作り、実際の業務で使いながら直します。IT部門の相談窓口を用意しておくと、つまずいたときに止まらずに進められます。

確認して公開する

部門内での利用が安定したら、管理者を登録し、必要に応じてIT部門の確認を経て正式に公開します。このとき、使い方の簡単なメモを残しておくと、属人化を防げます。

横に広げて棚卸しする

成功例を社内で共有し、ほかの部門へ広げます。作り手が増えるほどアプリの数も増えるため、棚卸しの周期と担当を決めて、定期的に一覧を見直します。

顧客向けサービスや新規事業を事業部門で作るには

市民開発で作れるのは、主に社内の業務アプリまでです。社外の顧客が使うサービスや新規事業には、会員管理・決済・マッチングなど、社内向けのツールでは作りにくい機能と、利用者が増えても止まらない作りが求められます。

外部に頼む・ツールを選ぶ

事業部門の発案でサービスを作る場合の選択肢は、大きく分けて、開発会社に外注する方法、社内のエンジニアが作る方法、サービスづくりの型を備えたツールを使う方法があります。どの方法でも、何を作るかを決め、進み具合を確かめる役割は事業部門に残します。外部の会社との進め方は「ベンダーコントロールとは？丸投げにしない進め方と発注側の役割を解説」をご覧ください。

ツールを使う方法の1つが、カスタメディアプラットフォームです。AI駆動セルフ開発ツール「S-MASE」は、900件以上の構築実績から生まれたプラットフォームの型を使い、プロンプトからインフラ・データベース・画面を自動生成できます。お客様自身が開発を進め、カスタメディアが伴走する方式のため、事業部門が主体となってMVPでの検証を繰り返しながら、本開発へつなげられます。

導入事例：菅公学生服「UNINOWA（ゆにのわ）」

IT部門ではない部署の発案から、顧客向けのサービスを立ち上げた例です。カスタメディアの導入事例では、菅公学生服株式会社が、同じ学校の保護者同士で制服・体操服を売り買いできるサービス「UNINOWA（ゆにのわ）」を構築しました。

構想は、ブランディング室のメンバーの発案から始まり、広報担当とWeb担当を中心にチームが作られました。学校ごとに区切られた「クローズドな環境」という独自の要件を、柔軟にシステムへ落とし込める点と、MVPとして必要な機能を実装できるパッケージ、営業担当による伴走支援が、カスタメディアを選んだ理由として挙げられています。

事例ページの掲載時点で、UNINOWAは100校で導入されています。詳しくは「菅公学生服株式会社 / UNINOWA（ゆにのわ）」をご覧ください。

よくある質問

まとめ｜市民開発は「任せる範囲」と「管理のルール」から始める

市民開発とは、現場の担当者がノーコード・ローコードツールなどで業務アプリを自ら作る取り組みです。内製化の人材が足りないなか、IT部門の負担を減らし、現場の改善を速く回す手段として注目されています。

一方で、管理されない野良アプリや属人化が起きやすいのも事実です。部門内の業務は現場に任せ、重いデータはIT部門と一緒に、社外の顧客が使うサービスは別の作り方で、という線引きと、管理者・棚卸し・廃止のルールを先に決めることが、市民開発を長く続ける近道です。

顧客向けのサービスづくりを相談したい方へ

カスタメディアでは、事業部門が主体となって、マッチング・EC・コミュニティなどの顧客向けサービスや新規事業を立ち上げたい企業に向けて、企画の整理からMVPでの検証、本開発、リリース後のグロースまでのご相談を承っています。AI駆動セルフ開発ツール「S-MASE」を使い、お客様自身が開発を進めながら、カスタメディアが伴走する進め方をご紹介します。

⇒ 自社の担当者で作り、自分たちで改善し続けたい方へ。AI駆動セルフ開発ツール「S-MASE」の詳細を見る