市民開発とは？メリット・デメリットと統制の設計

大学のサークルで、新人歓迎会の会計を一度やったことがあります。引き継ぎの説明は15分で終わり、渡されたのは歴代の会計が作ったExcelが4本。新歓シーズンには領収書が月100枚を超えるサークルで、5代分の工夫が積もった力作ぞろいでしたが、作った本人はもう卒業していて、数式の意味は誰にも分かりません。結局僕は5本目のExcelを新しく作り、それは次の代でまた読めない遺跡になりました。

前置きはさておき、本題に入ります。市民開発とは、現場の非エンジニアが、ノーコードツールやAIを使って自分の業務のためのツールを自分で作ることです。うちでは、生成AIの業務活用を非開発のメンバーにも全面的に開放していて、僕はその環境づくりに関わってきました。今日は、「作る力」を配ったら会計簿事件がそのまま会社で再演された、という話をしていこうと思います。

① 市民開発とは

市民開発の基本をすでにご存じの方は、② そのとおりに作って、詰まるから読み進められます。

実録全体から読みたい方は、② 現場の事例に置き換えるから読み進められます。

市民開発とは

市民開発とは、情報システム部門やベンダーに頼らず、現場の非エンジニアが自分の業務のためのツールやアプリを自分で作ることです。作る人は市民開発者（シチズンデベロッパー）と呼ばれます。調査会社Gartnerの定義では「企業のITが公認した開発・実行環境を使って、他者が使う業務アプリケーションを作る人」——つまり公認された環境の中で作る、という統制が定義に織り込まれています。この1点があとで効いてくるので、先に置いておきます。

注目される背景

追い風は3つあります。IT人材の不足——開発を頼む先が社内にも市場にも足りず、情報システム部門には開発待ちの行列ができている。DXの内製化——業務を分かっている現場が自分で作るほうが、要件のすれ違いが起きにくい。そして道具の進化——プログラムを書かずに作れる道具が揃い、作る力の値段が下がり続けている。この3つが重なって、市民開発は「一部の得意な人の趣味」から「組織の戦略」へ格上げされました。

ノーコード・ローコード、生成AIとの関係

市民開発を支える道具は3層あります。

• ノーコード — プログラムを一切書かず、画面の操作だけで作る。市民開発の主力
• ローコード — 大枠は部品の組み合わせで作り、細部だけコードを書く。IT部門との共同作業向き
• 生成AI — 「毎回この手順でやっているので、この形に直してほしい」と日本語で書くだけで道具ができる。ツールの使い方を覚えるという最後の壁まで溶かした

道具の敷居が下がるほど作る人が増える——ここまでは良い話です。増えたあとの話は、この記事の後半が本題です。

シャドーIT・EUCとの違い

似た言葉と混同されやすいので、線を引いておきます。

	中身	市民開発との違い
シャドーIT	IT部門の把握の外で使われるツールやシステム	作る場所が公認されているかどうか。公認の外で作れば、腕前に関係なくシャドーITになる
EUC	エンドユーザーコンピューティング。現場が表計算などで自分の道具を作る従来からの営み	考え方は同じ。市民開発はEUCがノーコード・AIで拡張されたものと言える

市民開発のメリット

• 開発スピードの向上 — IT部門の開発待ち行列に並ばず、現場がすぐ作る
• 開発・運用コストの削減 — 外注や専任開発者の工数を使わない
• 要件のすれ違いが減る — 業務を分かっている本人が作るので、「頼んだものと違う」が起きない
• IT部門の負荷軽減 — 小さな改善要望が現場で消化され、IT部門は基盤と統制に集中できる
• ベンダーロックインの回避 — 外部依存が減り、直したいときに自分で直せる
• DX人材の育成とITリテラシーの向上 — 作る経験そのものが教育になる

デメリットと失敗しやすいポイント

• 野良ツールの乱立 — 誰が何を作ったか分からないツールが増殖する
• 品質・セキュリティのばらつき — 個人情報の扱いへの配慮が作る人の意識に依存する
• 属人化 — 作った本人の異動・退職と同時に、誰も直せない道具が止まる
• ツールを配って終わる — 導入説明会だけ開いて、活用が広がらない
• 統制の後付けが効かない — あとからルールを足すと、同じ内容でも取り締まりの顔をして現れる

この一覧は、後半で実際に起きたことの目次でもあります。

成功させるためのポイント

• IT部門と現場の役割分担 — 現場は作る、IT部門は置き場所とセキュリティの土台を持つ
• 小さく始めて広げる — 1部門の定型業務から始め、成功体験を横展開する
• 教育とサポートの体制 — 最初の1本を一緒に作る伴走が、説明会10回に勝る
• 管理の仕組みを先に用意する — 作られたものを登録・検索・引き継ぐ場所。本文で扱う「置き場所」の話

公的統計と調査から見る市民開発の背景

経済産業省の「IT人材需給に関する調査」は、需給の伸びを高位に見積もる条件では2030年にIT人材が約79万人不足する可能性を示しています。IPAの「DX白書2021」では、日本企業の76％がDXを推進する人材の「量」が不足していると回答した一方、米国企業は43％でした。いずれも市民開発だけを測った数字ではありませんが、現場の小規模な改善までIT部門だけで引き受けにくい背景を示します。

また、Gartnerによるローコード利用者や市民開発者の構成比の予測、IDCによる将来のアプリ需要の予測が、市民開発の必要性を説明する際に引かれることがあります。ただし、予測年・対象・定義が異なる数字を同じ実績値のように並べるべきではありません。改善点は、数字を勢いの根拠にせず、出所・対象・予測であることを分けて読むことです。

2018年に経済産業省が公表した「DXレポート」の「2025年の崖」も、既存システムの複雑化と人材不足を経営課題として扱った政策文脈であり、市民開発はその課題への選択肢の一つです。改善点は、政策上の課題と個別ツールの導入効果を直結させず、自社の対象業務に分解して判断することです。

ガイドラインとIT部門レビュー

一般的な統制では、扱ってよいデータ、公開範囲、命名、責任者、テスト、廃止条件を開発ガイドラインにし、本番公開前にIT部門がレビューします。すべてを同じ重さで審査すると現場の速度が落ちるため、個人用の小さな自動化、部署内アプリ、全社や顧客に影響するアプリというように、影響範囲で審査を段階化する方法があります。改善点は、本文の「置き場所の1行」を入口にしつつ、高リスクな用途だけ公開前レビューを追加することです。

代表的な市民開発ツールと用途

代表例には、Microsoft Power Platform、kintone、ServiceNow、OutSystems、Mendix、AppSuiteがあります。Power Platformは業務アプリ、ワークフロー、分析などを組み合わせる製品群で、kintoneやAppSuiteは現場のデータ管理や業務アプリ作成に使われます。ServiceNow、OutSystems、Mendixもローコード開発の選択肢ですが、同じ「市民開発ツール」でも対象業務、開発者像、管理範囲は同一ではありません。改善点は、製品名の一覧から選ばず、作りたい業務と管理責任を先に定めて候補を絞ることです。

セキュリティリスクと具体的な対策

市民開発では、閲覧権限の設定ミスによる情報漏洩、共有アカウントによる責任所在の不明確化、外部サービスとの連携設定を起点とする不正アクセスなどが起こり得ます。対策は、最小権限、個人情報や顧客情報を扱うアプリの申請、利用ログの保存、退職・異動時の権限見直し、定期的な棚卸しです。改善点は、抽象的に「気をつける」と伝えるのではなく、データ区分ごとに使える接続先と公開範囲を決めることです。

教育・研修は説明会だけで終えない

教育には、ハンズオン研修、eラーニング、役割別・習熟度別の研修、勉強会、最初の1本を作る伴走があります。操作方法だけでなく、個人情報、権限、テスト、引き継ぎ、廃止までを一つの開発サイクルとして扱う必要があります。改善点は、一斉説明会の受講数ではなく、安全に公開・引き継ぎできたアプリ数を学習成果として見ることです。

市民開発者になりたい個人は、身近な定型業務を一つ選び、データの入力・処理・出力を書き出し、小さな試作品を作って利用者から確認を受けるところから始められます。改善点は、ツールの機能を広く覚えるより、実務の一工程を最後まで運用する経験を先に積むことです。

公開されている他社事例

公開事例では、日清食品が経理業務のペーパーレス化を進めた例や、経済産業省が行政手続きのためのプラットフォームを内製した例が、市民開発・ローコードの文脈で紹介されています。また、エイトレッドの公開事例では、日進製作所が700名で利用し年間650万円を削減した例、ヤンマー建機が年間1,000時間を削減した例が紹介されています。これらは各社が公表する事例上の数値であり、同じ効果が一般に得られることを示すものではありません。企業の申請承認や台帳管理だけでなく、行政・公共領域でも、利用者に近い側が改善を短い周期で反映する考え方は共通します。ただし、公表事例の期間や効果は対象範囲が異なるため、自社へそのまま当てはめることはできません。改善点は、事例の成果だけでなく、対象業務、利用者数、統制方法、保守担当まで確認することです。

評価制度・表彰・インセンティブ

市民開発を善意の残業にすると、通常業務が忙しい人ほど参加できません。開発や改善に使う時間を正式な業務時間として確保し、評価項目に含め、共有会や表彰で再利用された工夫を可視化する方法があります。一方で、作成本数だけを評価すると不要なアプリが増えます。改善点は、本数ではなく、再利用、削減できた手戻り、引き継ぎ可能性を評価することです。

従業員が自分の不便を直せることは、仕事への関与や学び直しにつながる可能性がありますが、離職率低下までを市民開発だけの効果と断定はできません。改善点は、人事効果をうたう場合も、参加率や継続利用率など追跡できる指標から検証することです。

最初に選ぶ対象業務

最初の対象には、申請・承認フロー、点検チェックリスト、簡易な集計・報告、備品や案件の台帳など、データの入口と出口が明確で、失敗時の影響を限定できる業務が向きます。顧客への請求、法定帳票、基幹システムの更新などは、小さく見えても影響が広いため、プロ開発者やIT部門の関与が必要です。改善点は、「簡単に作れそうか」ではなく、誤作動したときの影響と元に戻せるかで初期案件を選ぶことです。

アプリ構築の実務は、目的と利用者を決め、入力データ、処理ロジック、出力、例外、権限を設計し、試作、テスト、公開、運用、廃止へ進みます。改善点は、画面から作り始めず、誰がどのデータを何の判断に使うのかを先に一枚で示すことです。

エバンジェリストと社内コミュニティ

各部門で相談に乗るエバンジェリスト、質問を蓄積するコミュニティ、成果と失敗を共有する事例発表会があると、IT部門だけに問い合わせが集中しにくくなります。詳しい個人に依存させず、回答や部品を共通の置き場所へ戻す仕組みが必要です。改善点は、スター人材を増やすだけでなく、知見を検索可能な組織資産へ変える役割を明示することです。

ツール選定の基準

ツールは、現場の使いやすさと、IT部門が権限・ログ・環境を管理できることの両方で評価します。既存システムとの連携、ベンダーのサポート、データの持ち出しや移行、利用者が増えた場合のライセンス形態、3〜5年の運用費、想定する効果を並べ、ハンズオンで適合を確かめます。改善点は、初期費用だけでなく、利用拡大、保守、移行まで含む条件で比較することです。

外注は、複雑な設計や短期的な専門人材の確保に向く一方、変更のたびに依頼が必要になったり、仕様が社内から見えにくくなったりすることがあります。市民開発は変更を内製しやすい一方、教育・統制・保守の負担が社内に残ります。改善点は、外注か内製かの二択にせず、共通基盤は専門家、部門固有の小改善は現場という境界を決めることです。

IT部門と推進側の役割

IT部門は、プラットフォーム選定、ID・権限やデータ連携の基盤整備、開発ガードレール、技術支援、公開レビュー、資産台帳を担います。現場側は課題発見、市民開発、利用者確認、日常運用を担い、推進責任者は優先順位と部門間調整、サポーターは研修や問い合わせを支えます。改善点は、IT部門を禁止する監視者にも、すべてを代行する開発者にもせず、境界を設計する伴走者として位置づけることです。

経営層は、市民開発を余暇の活動ではなく企業戦略上の改善活動と位置づけ、時間、予算、責任者、許容リスクを示す必要があります。改善点は、「DXを進める」という号令ではなく、対象業務と意思決定者を明示することです。

導入は、対象と基盤を選ぶ選定期、小規模に試すパイロット期、成功例を横展開する成長期、CoEや棚卸しで運用を安定させる定着期に分けられます。改善点は、全社展開の日付だけを決めず、次の段階へ進む判定条件を置くことです。

開発の民主化とは何か

市民開発は「開発の民主化」とも呼ばれます。専門職だけが持っていた開発手段を現場へ開き、業務を知る人が改善に参加できるようにする考え方です。ただし、民主化は無制限な自由化ではなく、共通の権利とルール、参加を支える教育を一緒に配ることを意味します。改善点は、作成権限の配布だけで達成とせず、公開・再利用・廃止へ参加できる仕組みまで整えることです。

リモートワークの拡大とコロナ禍は、紙や対面を前提にした業務を短期間でデジタル化する必要を強め、市民開発が広がる背景の一つになりました。改善点は、緊急時に作った仕組みを恒久運用へ移す際、責任者、権限、保守期限を改めて設定することです。

② 現場の事例に置き換える

① 教科書どおりに、やってみる

市民開発の教科書は、希望に満ちています。業務をいちばん分かっているのは現場である。現場が自分で作れば、情報システム部門の開発待ち行列は消え、要件のすれ違いも消える。だから「作る力を全員に配れ」。

そのとおりにやりました。生成AIの利用を非開発の全メンバーに開放し、質問や成果を共有するチャンネルを作り、触りたい人が触れる状態にする。この開放はちゃんと動きました。経理も営業も、議事録の要約、文面の下書き、データの整形を自分の手で自動化し始めました。プログラムを書いたことのない人が、「こういう手順で毎回やっているので、この形に直してほしい」と日本語で書くだけで道具ができてしまう。「作れる人」が増える速度は、想像より速かった。従来のノーコードツールには「ツールの使い方を覚える」という最後の壁が残っていましたが、生成AIはその壁ごと溶かしていました。市民開発の参入障壁は、過去のどの道具よりも低くなっていたのです。

ここまでが、市民開発の教科書どおりの整理です。道具を配り、小さく始め、現場が作る。手順として、間違ってはいません。

この記事の後半は、その配布がうまくいった現場で、数か月遅れて何が起きたかの記録です。デメリットの一覧を知識としては知っていたのに、配る順序をひとつ間違えていました。

② そのとおりに作って、詰まる

ところが、詰まりは数か月遅れてやってきました。形は3つあります。

1つ目、重複です。ほぼ同じ議事録要約の仕組みを、別の部署の3人が別々に作っていました。3人とも良いものを作っているのに、良さが合流しません。

2つ目、停止です。ある業務のチェック作業を自動化した力作が、作った本人の担当替えと同時に止まりました。直せる人がいない。まさにサークルの会計簿です。

3つ目、これがいちばん重くて、見えないことです。誰が・何を・どの業務のために作ったのか、全体を見られる場所がどこにもない。うまくいった工夫を横展開しようにも、そもそも何が存在するのかを誰も知りませんでした。個々の道具は間違いなく役に立っているのに、組織として何かが積み上がっている感じがしない。この違和感の正体が、しばらく掴めませんでした。

③ どう気づいたか

気づいたきっかけは、共有チャンネルの過去ログを月初に読み返したことです。3か月分をさかのぼると、同じ質問が形を変えて何度も現れていました。「前に誰かが同じものを作っていた気がするのですが、どこにありますか」。作る力は配れたのに、作ったものが個人のフォルダとチャットの流れの中に沈んでいく。実は、チャンネルを作った時点で共有は済んだつもりでいました。でも、流速の速いチャットは「いま起きていること」を流す場所であって、「積み上がったもの」を探す場所ではない。置き場所としては最悪だったのです。

根が深いと思ったのは、探す場所が無いことに気づくのは、いつも「探した人」だけだという点です。作った本人は困っていないので、この問題はどこにも集計されず、誰の議題にもなりませんでした。

④ 原因を1つに特定

原因は、配ったものの中身にありました。僕たちは「作る力」——ツールと権限と勇気——を配りましたが、「作ったものの置き場所」——登録する場所、探す場所、引き継ぐ場所——を配っていませんでした。

作る力は個人に宿ります。でも、作ったものの価値は共有されて初めて組織のものになります。置き場所の無い市民開発は、優秀な個人商店が乱立した商店街です。にぎやかで、検索できない。しかも放っておくと、この商店街は情報システム部門から見えないシャドーITの群れに育ちます。禁止するほどの悪意はどこにもないのに、統制の外側だけが膨らんでいく。誰も悪くないまま、リスクだけが積もる形です。

⑤ 直してみる — 1箇所だけ直す

直したのは1箇所、置き場所を1つに決めたことです。社内のAI活用基盤に、階層を4つだけ持つ構造を作りました。会社共通の知識（Wiki）、案件ごとの情報（Project）、作った道具（Apps）、個人の設定（User）。誰かが何かを作ったら、道具はAppsに登録し、根拠になった知識はWikiに置く。それだけです。

4つの階層に分けた理由は、置くものの寿命が違うからです。会社共通の知識は年単位で残り、案件の情報は案件と共に終わり、道具は使われる限り生き、個人の設定は本人だけのもの。寿命の違うものを同じ棚に混ぜると、あとで棚卸しをするときに、何を捨ててよいか分からなくなります。

作り方のルールは増やしていません。増やしたのは「作ったら、ここに置く」という1行だけ。市民開発の勢いを削るルールは、置き場所の1行に絞りました。

⑥ あとで知った — すでに名前があった

あとで知りましたが、この設計には先例の定義がありました。調べ物の途中で読んだGartnerの用語集は、市民開発者をこう定義しています。「企業のITが公認した開発・実行環境を使って、他者が使う業務アプリケーションを作る人」。つまり定義の時点で、「公認された環境の中で」という統制が織り込まれているのです。好き勝手に作る人は、定義上シャドーITであって市民開発者ではない。市民開発とシャドーITを分けるのは、作る人の腕でも道具でもなく、作る場所が公認されているかどうか、その1点だけ。作る力の話だと思っていた言葉は、最初から置き場所込みの言葉でした。

規模の予測も先にありました。Gartnerは「2023年までに、大企業の市民開発者は職業開発者の4倍以上になる」と予測していました。4倍の人が作り始めるなら、置き場所の設計は開発ルールより先に要る。ちなみにこの予測が出たのは、生成AIが普及するより前です。予測の的中よりも、「作る人が数で職業開発者を圧倒する」という向きを調査会社が早くから断言していたことのほうが、いま読むと重い。順序まで含めて、新しい理屈は、ひとつも要りませんでした。

⑦ 何が変わったか

置き場所を決めてから、変化は2つありました。1つ目、重複が合流し始めました。作る前にAppsを検索する動きが生まれ、「もうあるなら使う、足りないなら育てる」が選べるようになった。2つ目、引き継ぎが構造になりました。道具が個人のフォルダではなく共通の棚にあるので、担当替えで即死しません。

ただ、代償も3つありました。1つ目、登録の手間です。「作って終わり」に比べれば、置きに行く1歩はやはり面倒で、置かれない道具はいまもゼロにはなりません。登録を義務にして罰を作るか、登録すると得をする仕掛けにするか——うちは後者を選び、棚に置かれた道具だけが改善の相談に乗ってもらえる運用にしています。2つ目、棚の手入れです。使われなくなった道具が棚に残ると探す邪魔になるので、棚卸しが月1回の仕事として増えました。3つ目、置き場所を1つにした瞬間、そこが止まると全員が困る場所になりました。自由の分散から、依存の集中への引っ越しでもあるわけです。

⑧ 現場で使うなら、この順序表

市民開発を始めるとき、配る順序を決めるための表です。

順序	配るもの	中身
1	置き場所	作ったものを登録する棚を1か所。検索できること。
2	作る力	ツール・権限・最初の成功体験。
3	引き継ぎの型	作者が居なくなっても動く条件。説明を1枚つける。
4	棚卸し	月1回、使われていない道具を棚から下ろす。

多くの導入は2から始めて、1を後回しにします。理由は簡単で、2は楽しく、1は地味だからです。導入の説明会は1回で足りますが、棚の習慣づけは数か月かかります。それでも、順序を入れ替えるだけで、半年後の景色は確実に変わります。もうひとつのコツは、4行目までを最初の説明会で一緒に配ってしまうことです。あとから統制だけを追加すると、同じ内容でも取り締まりの顔をして現れるからです。

③ 市民開発の欠陥とAI時代の潮流

⑨ この考え方が効き続ける理由

作る力の値段は、これからも下がり続けます。生成AIの登場で、市民開発の裾野は「Excelが得意な人」から「日本語が書ける人」まで一気に広がりました。作る力が安くなるほど、作られるものは増え、増えるほど置き場所の設計が効きます。希少なのはもう「作れること」ではなく、「作ったものが組織の資産として積み上がる構造」のほうです。とはいえ、統制を先に重くしすぎれば、市民開発のいちばんの燃料である「自分で作れた」という手応えが消えます。だから絞るのです。ルールは置き場所の1行だけ。この釣り合いの取り方は、AIが賢くなり、作る力が10年後にさらに安くなっていても、たぶん変わりません。

余談ですが、あのサークルの会計簿には後日談があります。僕が作った5本目はGoogleスプレッドシートにして、個人のパソコンではなく共有ドライブに置いてきました。数年後の飲み会で後輩に聞いたら、細かい改造を受けながら、まだ現役だそうです。作った僕のことは誰も覚えていませんでしたが、置き場所は覚えられていました。以上です。

欠陥1：現場担当者の業務負荷が増える

市民開発者は本来業務と開発を兼務することが多く、作成だけでなく問い合わせ、改修、引き継ぎまで抱えると、改善活動が個人の残業へ移ります。開発時間を業務時間内に確保し、責任者が優先順位を調整しなければ、熱意のある人ほど消耗します。改善点は、担当者を任命するだけでなく、月に使える時間と代替する通常業務を決めることです。

欠陥2：部分最適が全体のデータ連携を壊す

各部署のアプリが局所的には便利でも、顧客名や商品コードの定義がばらばらなら、全社集計や基幹システムとの連携で作り直しが発生します。重複を見つけるアプリ台帳に加え、共通データ、連携方式、全社アーキテクチャに関わる変更をIT部門が確認する境界が必要です。改善点は、画面や機能の重複だけでなく、同じデータを別定義で持っていないかを棚卸しすることです。

欠陥3：更新されないツールは陳腐化する

生きているアプリも、OS、ブラウザ、API、接続先、組織ルールの変更によって互換性を失います。作者がいなくても更新できるように、所有者、更新履歴、依存先、次回確認日を台帳へ持たせる必要があります。改善点は、使われていないものを廃止する棚卸しに、使われているものの更新確認も加えることです。

欠陥4：AI生成コードは正しそうに見える

生成AIは、存在しない仕様や不適切な処理をもっともらしく出すハルシネーションを起こし得ます。コードを読めない利用者が結果だけで判断すると、計算ミス、権限不備、秘密情報の埋め込みが見逃され、生成過程もブラックボックスになります。改善点は、AIの出力を完成品と扱わず、入力例、期待値、例外、権限を人が検証できる形で残すことです。

欠陥5：利用拡大でライセンスと基盤負荷が変わる

少人数の試作では成立しても、利用者、実行回数、保存データ、外部連携が増えると、ライセンス条件や基盤のスケーラビリティが課題になります。料金や上限は製品と契約で異なるため、試作時点の条件を全社展開へそのまま延長できるとは限りません。改善点は、利用者数と処理量の増加シナリオを置き、段階ごとに契約と構成を再確認することです。

欠陥6：集中した置き場所にはバックアップが要る

置き場所を一つに集約すると、検索と引き継ぎは容易になりますが、その基盤の停止やデータ消失が全員へ波及します。復旧可能なバックアップ、データの書き出し、障害時の代替手順、復旧責任者を定め、事業継続性を確認する必要があります。改善点は、「バックアップがあるか」だけでなく、復元テストで戻せることを確かめることです。

欠陥7：速さを優先するとテストが軽くなる

現場を知る人が作っても、正常系だけの確認では、空欄、重複、桁違い、権限違い、連携失敗によるバグや計算ミスを防げません。影響範囲に応じて、作成者以外の確認、本番前の受け入れテスト、変更後の回帰テストを組み込みます。改善点は、すべてを重い審査にせず、金銭・個人情報・社外利用の有無で必要なテストを段階化することです。

④ ARCの事例

ARCでは、生成AIを非開発メンバーへ開放した結果、議事録の要約、文面の下書き、データ整形などの道具が増えました。その過程で起きた重複、作者の異動による停止、全体像の見えなさに対し、Wiki、Project、Apps、Userの4階層を持つ共通基盤を設け、作った道具をAppsへ登録する運用に変えています。本文②の実録は、この移行で判明した「作る力より先に置き場所を配る」という設計原則を記録したものです。

新規事業で市民開発や生成AIを用いる場合も、試作品を作ることと、検証後に誰が保守し、どの基盤へ載せるかを同時に設計する必要があります。ARCの新規事業コンサルティング（MVP・PoC支援）では、MVP（実用最小限の試作）・PoC（概念実証）の設計から検証、次の実装判断までを支援しています。改善点は、PoCの完成をゴールにせず、本番移行、運用責任、廃止条件を検証項目へ含めることです。

⑤ 一緒に覚えたい概念

開発の民主化

開発の民主化は、専門職に限られていた開発手段を現場へ広げる考え方です。市民開発はその実装形態の一つであり、権限だけでなく教育と統制も参加条件として共有します。改善点は、作れる人数ではなく、安全に公開し再利用できる人数で進展を捉えることです。

CoE（センター・オブ・エクセレンス）

CoEは、複数部門にまたがる知見、標準、教育、ガバナンスを集約する中核組織です。市民開発では、IT部門、現場のエバンジェリスト、セキュリティ、業務責任者をつなぎ、ツール選定、テンプレート、相談窓口、アプリ台帳、レビューを支えます。改善点は、CoEを承認だけの組織にせず、再利用できる部品と成功・失敗事例を現場へ戻すことです。

EUCからRPA、市民開発への系譜

1980〜1990年代にはExcelやAccessなどを使うEUCが広がり、現場の改善を支えた一方、属人化したマクロやデータが残りました。その後、定型操作を自動化するRPAが普及しましたが、対象業務や例外処理を整理しないままロボットが増える「RPA疲れ」も語られました。市民開発は、ノーコード、ローコード、生成AIまで手段を広げた流れにあり、過去の属人化を繰り返さない統制が問われます。改善点は、新しい道具を導入するたびに過去を置き換えるのではなく、既存資産の移行・廃止まで系譜として管理することです。

フュージョンチーム

フュージョンチームは、業務を知る市民開発者と、アーキテクチャ、セキュリティ、複雑な連携を担うプロ開発者が一つの成果へ協働するチームです。簡易な画面や業務ルールは現場、共通基盤や高リスク部分は専門家という分担により、速度と品質を両立させます。改善点は、肩書で作業を分けず、影響範囲と必要な専門性で担当を決めることです。

市民開発という言葉の語源

「市民」は、専門家だけに閉じていたアプリ開発を広く解放する「アプリ開発の市民解放」という比喩です。行政の市民だけを指す言葉ではなく、企業内で業務を担う非IT部門の人も含みます。改善点は、「誰でも自由に作る」という意味に狭めず、公認された環境へ参加する責任も含めて説明することです。

市民開発のよくある質問

市民開発とは何ですか？

エンジニアではない現場の担当者が、ノーコードや生成AIで業務用の道具を自作することです。会社が認めた環境の中で作ることまで含めた言葉です。

市民開発とシャドーITの違いは何ですか？

公認の置き場所の内側で作れば市民開発、外側で作ればシャドーITです。腕前や道具では分かれません。

市民開発のメリットは何ですか？

要件を伝える伝言ゲームが消えること、開発の順番待ちが消えること、道具づくりの単価が下がることの3つです。

市民開発の失敗パターンは何ですか？

重複開発・属人化・全体が見えない、の3つが典型です。どれも「作る力だけ配って棚を配らない」ことから生まれます。

市民開発の統制はどう設計すればよいですか？

規程集ではなく「作ったら登録する棚を1か所」から始めてください。検索できる台帳と月1回の棚卸しがあれば最低限は回ります。

市民開発は何から始めればよいですか？

順序は、①棚（置き場所）→②作る力（ツールと権限）→③引き継ぎの型→④棚卸しの習慣です。②から配ると数か月後に野良ツールが群生します。

市民開発者はどのくらい増えていますか？

Gartnerが職業開発者の4倍超と予測した規模で、生成AI以降はさらに増えています。人数の把握より先に、登録の仕組みを用意してください。

生成AIは市民開発をどう変えましたか？

「ツールの使い方を覚える」最後の壁を無くしました。作れる人が急増するぶん、統制の設計を先に済ませる必要があります。