市民開発（現場の社員がノーコードやローコードのツールで業務アプリや自動化の仕組みを作る取り組み）を成功させるには、「作ってよいもの」と「作る前に相談すべきもの」の線引きを先に決めておくことが最も重要です。すべてを禁止すれば現場の改善の芽を摘み、すべてを自由にすれば、誰も保守できないツールや、情報が漏れる危険のある仕組みが社内に増えていきます。ガバナンスの目的は管理することではなく、現場が安心して作れる範囲を明確にすることにあります。
具体的には、扱うデータの重要度と、ツールを使う人の範囲の二つで作ってよいものを分け、重要度が高いものほど事前の確認と保守の体制を求める形が現実的です。あわせて、使ってよいツール、作ったものの登録、作った人が不在になったときの引き継ぎ、の三つのルールを決めておけば、最低限のガバナンスは機能します。
この記事は、社内で市民開発を広げたいと考えている情報システム部門やDX推進の担当者、現場で作られたツールが増えて管理しきれなくなっていると感じている管理部門の方に向けて書いています。市民開発のメリットとリスク、ガバナンスのルールの決め方、運用の進め方、よくある失敗を順に整理します。
市民開発とは何か、なぜガバナンスが必要か
市民開発は、専門の開発者ではない現場の社員が、自分たちの業務に必要なアプリや自動化を作ることを指します。用語の意味は市民開発（シチズンデベロップメント）で解説しています。ノーコードやローコードのツールが使いやすくなり、表計算ソフトの延長のような感覚で、データの管理画面や申請の仕組み、ツール同士の連携を作れるようになりました。
現場の社員が自分で作れることには、大きな利点があります。業務を一番よく知る人が作るため、使い勝手のよいものができやすく、情報システム部門や外部の開発会社に依頼して待つ時間もかかりません。小さな改善を素早く積み重ねられるのは、市民開発ならではの強みです。
一方で、管理のないまま広がると、次のような問題が起きます。
- 作った人しか仕組みを理解しておらず、異動や退職で誰も直せなくなる
- 顧客情報や個人情報が、許可されていないツールや個人のアカウントに保存される
- 同じ目的のツールが部署ごとに作られ、データがばらばらになる
- ツールの利用料が部署ごとに発生し、全体の費用が把握できない
- 仕組みが止まっても気づかず、業務に影響が出てから発覚する
管理されないまま使われるツールはシャドーITと呼ばれ、市民開発はこの問題と表裏一体の関係にあります。ガバナンスとは、市民開発の利点を生かしながら、こうしたリスクを抑えるためのルールと体制のことです。
ガバナンスの基本方針：重要度で線を引く
ガバナンスのルールを一律に厳しくすると、ちょっとした集計表の自動化にも申請が必要になり、現場は面倒に感じて、結局ルールの外で作るようになります。逆に一律に緩くすると、重要なデータを扱う仕組みも自由に作られてしまいます。
そこで、作るものを「扱うデータの重要度」と「使う人の範囲」で分類し、分類ごとに求めるルールを変えるのが基本の考え方です。
| 区分 | 扱うデータの例 | 使う人の範囲 | 求めるルール |
|---|---|---|---|
| 自由に作ってよい | 公開情報、個人の作業メモ、社内の一般的な情報 | 作った本人やチーム内 | 許可されたツールを使う。登録は任意 |
| 登録して作る | 部署内の業務データ、取引先の会社情報 | 部署内 | 台帳に登録し、副担当を決める |
| 事前に相談して作る | 顧客の個人情報、契約や金額の情報、人事情報 | 部署をまたぐ、社外の人も使う | 情報システム部門の確認、権限設定の確認、保守の体制を決める |
| 市民開発の対象外 | 決済、基幹システムの更新、法令で厳格な管理が求められる情報 | 全社や顧客 | 専門の開発体制で作る |
区分の境目は、会社の業種や扱う情報によって変わります。大切なのは、現場の社員が自分の作ろうとしているものがどの区分に当てはまるかを、迷わず判断できるようにすることです。判断に迷うときの相談窓口も合わせて決めておきます。
ルールを決める手順
ガバナンスのルールは、作り込みすぎると運用されません。次の手順で、最低限のルールから始めて、運用しながら育てていくのがおすすめです。
- 社内ですでに使われているノーコード・ローコードのツール、自動化の仕組み、共有の表計算ファイルを洗い出す。部署ごとに聞き取りを行う。
- 洗い出した仕組みを、扱うデータと使う人の範囲で分類し、リスクの高いものから確認する。
- 使ってよいツールの一覧を決める。会社として契約し、アカウントやデータの保存先を管理できるものを中心に選ぶ。
- 作ってよいものの区分と、区分ごとのルールを決め、一枚程度の簡潔な文書にまとめる。
- 作った仕組みを登録する台帳を用意する。記録する項目は最小限にする。
- 相談の窓口と、事前の確認の流れを決める。確認にかかる期間の目安も示す。
- 現場向けに説明の場を設け、ルールの目的と使い方を伝える。
- 三か月から半年ごとに、台帳とルールを見直す。
手順1で、すでに多くの仕組みが作られていることが分かる場合があります。そのときに、作ったことを責めるのではなく、「台帳に登録すれば引き続き使える」という形で、既存の仕組みを取り込むことが重要です。責められると、現場は仕組みの存在を隠すようになります。
決めておくべき主なルール
使ってよいツール
会社として契約したツールを使うことを原則にします。個人で契約したツールや、無料のツールに業務のデータを保存すると、退職時にデータが残ったり、会社が把握できない場所に情報が流れたりします。ツールを選ぶときは、アカウントを会社で一元管理できるか、権限を細かく設定できるか、操作の記録が残るか、データの保存先がどこか、を確認します。新しいツールを使いたいという要望が出たときの申請の流れも決めておきます。
台帳への登録
作った仕組みを一覧で把握できるようにします。台帳に記録する項目は、仕組みの名前、目的、作った人、副担当、使っているツール、扱うデータの種類、使っている人の範囲、連携しているシステム、最終更新日、程度で十分です。項目が多すぎると登録の手間が増え、登録されなくなります。
権限とデータの扱い
個人情報や顧客の情報を扱う仕組みでは、誰が見られるのか、誰が編集できるのかを設定し、必要以上の人に権限を与えないようにします。社外の人と共有する場合は、共有の範囲と期限を明確にします。個人情報の取り扱いについては、法令の解釈が関わるため、社内の担当部署や専門家に確認したうえで運用してください。
引き継ぎと保守
作った人だけが仕組みを理解している状態を避けるため、登録して作る区分以上の仕組みには、副担当を必ず置きます。仕組みの簡単な説明（何をしているか、どのデータを使うか、止まったときにどうするか）を残してもらいます。作った人が異動や退職をする場合は、引き継ぎを手続きの一部に組み込みます。保守の担当が不在になった仕組みの扱いは自動化の仕組みを誰が保守するか：野良ロボット・野良ツール対策で詳しく扱っています。
廃止のルール
使われなくなった仕組みが残り続けると、台帳が膨らみ、不要なデータが残ります。一定期間使われていない仕組みは、作った人に確認したうえで停止し、データを整理するルールを設けます。
現場を支える体制づくり
ルールを決めるだけでは、市民開発は広がりません。現場が安心して作れるよう、支える体制も合わせて整えます。
相談できる窓口を用意する
作り方が分からない、自分の作ろうとしているものが区分のどれに当たるか分からない、といった疑問に答える窓口を用意します。チャットの専用チャンネルを作り、情報システム部門やDX推進の担当者、ツールに詳しい社員が答える形にすると、気軽に相談できます。
作り方の型を共有する
よく作られる仕組み（申請の受付、データの集計、通知の自動化など）について、作り方の手本を用意しておくと、品質がそろい、保守もしやすくなります。名前の付け方、データの保存場所、エラー時の通知先などの決まりも、手本に含めておきます。
作り手を育てる
各部署にツールに詳しい人を育て、部署内の相談役になってもらいます。社内で勉強会を開いたり、うまく作られた仕組みを紹介したりすると、作り手が増え、ルールも自然に浸透します。
ルールの文書は、作り手が実際に参照する場面を想定して書きます。長い規程の文書ではなく、「作る前に確認する三つのこと」「事前に相談が必要なもの」「困ったときの連絡先」が一目で分かる一枚の案内を用意し、ツールの利用を始めるときの画面や社内の案内ページから見られるようにしておくと、守られやすくなります。
ツールの選定と、作り手に求める品質の目安
ガバナンスのルールと並んで現場が迷いやすいのが、どのツールで作るか、どこまで作り込めばよいか、という点です。会社として使ってよいツールを決めたうえで、用途ごとの使い分けと、区分ごとに求める品質の目安を示しておくと、作り手が判断しやすくなります。
用途ごとのツールの使い分け
市民開発で使われるツールは、大きく分けて、データを管理するアプリを作るもの、ツール同士をつなぐ自動化のもの、表計算ソフトのスクリプトやマクロの三つです。データを入力して一覧で見たい、承認の流れを作りたい、といった用途にはアプリを作るツールが向きます。あるツールで起きたことを別のツールに伝えたい、通知を送りたい、といった用途には自動化のツールが向きます。表計算ファイルの中で完結する集計や整形には、スクリプトやマクロが手軽です。
用途に合わないツールで無理に作ると、仕組みが複雑になり、保守が難しくなります。社内で推奨する組み合わせを示しておくと、作り手が迷わずに済みます。
区分ごとに求める品質の目安
自由に作ってよい区分では、作り手の判断に任せます。登録して作る区分では、名前の付け方の決まりに従うこと、エラーが起きたときに作り手と副担当に通知が届くこと、簡単な説明を残すこと、を求めます。事前に相談して作る区分では、それに加えて、権限の設定の確認、試験用のデータでの動作確認、止まったときの代替手段（手作業での処理の手順）を用意することを求めます。
求める品質を区分ごとに段階的に上げることで、小さな改善は気軽に作れ、重要な仕組みはしっかりと作られる、という状態を目指します。
専門の開発に移す目安
市民開発で作った仕組みが広く使われるようになると、ツールの制約にぶつかることがあります。処理するデータの量が増えて動作が遅くなる、複雑な条件分岐が増えて誰も全体を理解できない、他のシステムとの連携が増えて止まったときの影響が大きい、といった状態です。こうした兆候が見えたら、専門の開発体制で作り直すことを検討する時期です。作り直す場合も、市民開発で作った仕組みは、業務の要件を整理した生きた見本として役立ちます。
架空の例：営業部門で広がった顧客管理の仕組み
ある会社の営業部門で、一人の営業担当がノーコードツールで顧客の商談を管理する仕組みを作ったとします。使いやすいと評判になり、部門全体で使われるようになりました。顧客の担当者名や連絡先、商談の金額も記録されていました。
ところが、その仕組みは作った営業担当の個人のアカウントで作られており、共有の設定も「リンクを知っている人は閲覧可能」になっていました。作った担当者が別の部署に異動することが決まり、引き継ぎの話が出たところで、情報システム部門が初めてこの仕組みの存在を知りました。
情報システム部門は、仕組みを止めるのではなく、会社で契約しているツールのアカウントに移し、閲覧と編集の権限を営業部門の社員に限定しました。副担当として、仕組みに詳しい別の営業担当を決め、台帳に登録しました。この出来事をきっかけに、顧客の情報を扱う仕組みは事前に相談する、というルールが社内に周知されました。
この例のように、問題が見つかったときに仕組みを取り上げるのではなく、安全な形に整えて使い続けられるようにすると、現場はルールに協力的になります。
よくある失敗とその避け方
ルールが厳しすぎて誰も守らない
すべての仕組みに申請と承認を求めると、手続きが面倒になり、現場はルールの外で作るようになります。重要度の低いものは自由に作れるようにし、手続きは重要度の高いものに絞ります。
ルールを作っただけで周知しない
ルールを文書にしても、現場が知らなければ機能しません。説明の場を設ける、相談の窓口を目立つ場所に案内する、新しく入った社員に伝える、といった周知を続けます。
台帳を作ったが更新されない
台帳の項目が多い、登録の手間が大きい、登録しても何も得がない、という状態では更新されません。項目を絞り、登録すると相談の窓口で優先的に支援を受けられる、などの利点を用意します。
市民開発で作るべきでないものまで作ってしまう
決済や基幹システムの更新など、障害が起きたときの影響が大きい仕組みを市民開発で作ると、品質や保守の面で問題が起きます。規模が大きくなった仕組みは、専門の開発体制に移す判断が必要です。移行の判断の目安はノーコードの限界はどこか：スクラッチ開発へ移行する判断基準と手順を参考にしてください。
情報システム部門が門番になる
情報システム部門が承認するだけの役割になると、現場との関係が対立的になります。作り手を支援する役割を担い、安全に作るための手本や相談の場を提供する立場に立つと、協力関係が生まれます。
市民開発ガバナンスのチェックリスト
- 社内で使われているノーコード・ローコードのツールと仕組みを洗い出したか
- 使ってよいツールの一覧を決め、会社で契約・管理しているか
- 扱うデータの重要度と使う人の範囲で、作ってよいものの区分を決めたか
- 市民開発の対象外とするものを明確にしたか
- 台帳の項目を最小限にし、登録の流れを決めたか
- 重要度の高い仕組みに、副担当と簡単な説明書を求めているか
- 個人情報や顧客情報を扱う仕組みの権限設定を確認する流れがあるか
- 相談の窓口と、確認にかかる期間の目安を示しているか
- 異動や退職の手続きに、仕組みの引き継ぎを組み込んでいるか
- 使われなくなった仕組みの廃止のルールがあるか
- 定期的にルールと台帳を見直す時期を決めているか
よくある質問
Q. 市民開発のガバナンスは、誰が担当するべきですか？
情報システム部門が担うことが多いですが、DX推進の担当や管理部門と分担する形も一般的です。ルールと台帳の管理、ツールの契約は情報システム部門、作り手の支援と社内への普及はDX推進の担当、のように役割を分けると進めやすくなります。会社全体のIT利用の方針と合わせて考える場合はITガバナンスの考え方も参考になります。
Q. すでに管理されていない仕組みが多数あります。どこから手を付けるべきですか？
まずは顧客の情報や個人情報、金額の情報を扱っているものを優先して確認します。それらについて、保存先、共有の範囲、作った人が今も在籍しているかを確認し、リスクが高いものから順に整えます。それ以外の仕組みは、台帳への登録を呼びかけながら、時間をかけて把握していきます。
Q. 生成AIを使った仕組みも、市民開発の対象に含めるべきですか？
含めて考えるのがおすすめです。生成AIのサービスに業務のデータを入力する場合、データの取り扱いの条件を確認する必要があります。使ってよいサービスと、入力してよい情報の範囲を、市民開発のルールと合わせて決めておくと、現場が迷わずに活用できます。
Q. 現場が作った仕組みに不具合があった場合、責任は誰が負うのですか？
まずは作った部署が一次的な対応を担う、という原則を決めておくのが一般的です。そのうえで、事前に相談して作る区分の仕組みは、情報システム部門も確認に関わっているため、障害時の連絡先や対応の分担を事前に決めておきます。責任の所在をあいまいにしたままにすると、止まったときに誰も動かない事態になりかねません。区分ごとに、障害時の一次対応者と相談先を台帳に記録しておくと安心です。
Otsumuに相談できること
社内で使われているツールの種類が少なく、情報システム部門やDX推進の担当者がルールの整備と現場の支援に時間を割ける場合は、この記事の手順に沿って自社でガバナンスを整えることは十分可能です。まずは使ってよいツールの一覧と、事前に相談すべきものの線引きを決めるだけでも、リスクは大きく下がります。
一方で、管理されていない仕組みがすでに多数あって全体像がつかめない、市民開発で作られた仕組みが業務の中心になっていて専門の開発体制への移行を検討したい、ルールを整える人手が社内にない、といった場合は、外部の手を借りた方が早く進むことがあります。
Otsumuでは、社内の自動化の仕組みやツールの棚卸しから、ガバナンスのルールづくり、重要な仕組みの作り直しや社内ツール開発への移行までを支援しています。現場の改善の勢いを止めずに、安全に運用できる形に整えることを大切にしています。詳しくは自社サービス運用の自動化コンサルティングのページをご覧ください。
市民開発をこれから広げたい段階でも、すでに広がった仕組みの整理から始めたい段階でも、ご相談いただけます。30分の無料相談からお気軽にご連絡ください。
この記事について
Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。
執筆：Otsumu株式会社 ／ 編集日 2026.10.01