市民開発で配るべきは、作る力より置き場所だった

市民開発とは?メリット・デメリットと、シャドーITにしない統制の設計

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

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

「市民開発とは?メリット・デメリットと、シャドーITにしない統制の設計」の全体像をまとめた図解|大学のサークルで、会計を引き継いだことがあります

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

「教科書どおりに、やってみる」を図解したスライド|市民開発の教科書は、希望に満ちています

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

市民開発とは

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

注目される背景

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

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

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

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

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

シャドーIT・EUCとの違い

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

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

市民開発のメリット

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

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

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

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

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

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

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

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

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

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

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

「そのとおりに作って、詰まる」を図解したスライド|ところが、詰まりは数か月遅れてやってきました

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

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

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

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

③ どう気づいたか

「どう気づいたか」を図解したスライド|気づいたきっかけは、共有チャンネルの過去ログを月初に読み返したことです

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

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

④ 原因を1つに特定

「原因を1つに特定」を図解したスライド|原因は、配ったものの中身にありました

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

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

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

「直してみる — 1箇所だけ直す」を図解したスライド|直したのは1箇所、置き場所を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つありました

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

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

市民開発のよくある質問

市民開発とは何ですか?

現場の非エンジニアが、ノーコードツールやAIを使って自分の業務のためのツールを自分で作ることです。Gartnerは市民開発者を「企業のITが公認した開発・実行環境を使って、他者が使う業務アプリケーションを作る人」と定義しており、公認された環境という統制が定義に織り込まれています。

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

作る場所が公認されているかどうかの1点です。作る人の腕や道具の違いではありません。公認された置き場所の外で作られたツールは、悪意がなくても統制の外側で膨らみ、リスクだけが積もっていきます。

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

業務をいちばん分かっている現場が自分で作るため、要件のすれ違いが消え、情報システム部門の開発待ち行列に並ばずに済むことです。生成AIの登場で参入障壁はさらに下がり、日本語で手順を書ける人なら道具を作れるようになりました。

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

3つあります。同じツールを別々の人が重複して作ること、作者の異動で誰も直せなくなること、そして誰が何を作ったのか全体を見られる場所がないことです。原因は作る力だけを配って、作ったものの置き場所を配らないことにあります。

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

ルールを増やすのではなく、「作ったら、ここに置く」という置き場所の1行に絞るのが実務的です。登録する棚を1か所に決めて検索できるようにし、月1回の棚卸しで使われない道具を下ろします。統制を重くしすぎると市民開発の勢いが消えます。

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

配る順序が重要です。最初に置き場所(登録する棚)、次に作る力(ツール・権限)、その次に引き継ぎの型、最後に棚卸しの習慣です。多くの導入は作る力から配って置き場所を後回しにするため、数か月後に野良ツールの群れができます。

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

Gartnerは「2023年までに、大企業の市民開発者は職業開発者の4倍以上になる」と予測していました。生成AIの普及はこの流れをさらに加速しており、作る人が数で職業開発者を圧倒する前提で統制を設計する必要があります。

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

従来のノーコードツールに残っていた「ツールの使い方を覚える」という壁を溶かし、日本語で手順を書けるだけで道具が作れるようになりました。作る力が安くなるほど作られるものは増え、置き場所と統制の設計の重要性が増しています。

You May Also Like
AI機能を“足す”ほどプロダクトは使われなくなる ― 機能の数と価値は比例しない

AI機能を“足す”ほどプロダクトは使われなくなる ― 機能の数と価値は比例しない

競合に追いつこうとAI機能を足したのに、なぜかプロダクトが使われなくなる――その逆説を、実家のテレビのリモコンの話から、足し算ではなく引き算のAIプロダクト開発まで、ゆるっと書きました。AI機能の数と、プロダクトの価値は比例しないのです。
View Post

AIの活用事例|自動化できる業務10種と、公表値だけで読む7社

「他社はどこまでやっているのか」——生成AIの社内導入を任された担当者が、稟議の材料としていちばん最初に集めるのが活用事例です。ところが検索して出てくる事例集の多くは、ツール会社の宣伝か、効果の数字が…
View Post

AIエージェントの活用事例|業務別10種と業界別の使われ方、導入3ステップ

AIエージェントの事例を、各社が公表している数値だけで6件並べました。セールスフォース、モルガン・スタンレー、コモンウェルス銀行、ルーメン、パナソニック コネクト、横浜銀行。置いた工程・人の承認位置・効果の単位・段階という4つの列で比べ、自社の業務がどれに当たるかを引ける対応表にしています。
View Post
プロンプトインジェクション対策6つの方法と、直接・間接の違いをまとめた図解

プロンプトインジェクション対策|6つの方法と直接・間接の違い、AIエージェントのリスク

プロンプトインジェクションとは、AIへの指示文に別の指示を紛れ込ませて、本来の制約を外させる攻撃です。対策としてまず思いつくのは、システムプロンプトに禁止事項を書き足すことです。私たちもそうしました。そして守られませんでした。プロンプトによる禁止は確率的で、ツール層のフックは決定的です。44行のフックで守る側へ移した実装と、パスの正規化や失敗時に閉じる設計まで、そのまま書きます。
View Post