市民開発を全社展開する前に決めること｜運用・権限・引き継ぎのチェックリスト【2026年9月版】

株式会社AIworker

2026年9月14日 12:28

「現場でアプリを作れる人は増えた。でも、その人が異動したら誰が直すのか」

市民開発が広がると、こんな悩みが出てきます。

最初は本人だけが使う小さなツールだったのに、いつの間にか部署の月次業務に組み込まれている。作った本人へ質問と修正依頼が集まり、休むと業務が止まる。接続しているデータや権限を、管理部門が把握していないこともあります。

問題は、市民開発そのものではありません。個人の工夫を複数人で使う仕組みへ広げるときに、運用を追加していないことです。

全社展開の前に、業務の責任者、変更する人、利用条件、テスト、問い合わせ先、引き継ぎ、終了方法を決めます。全部を重い審査にする必要はありません。利用範囲と、止まったときの影響に合わせて確認を増やします。

この記事では、DX推進、情報システム、市民開発の育成担当者に向けて、展開前に確認する項目と判断シートを紹介します。

この記事の要点

✅ アプリを作った人と、業務で使う責任を持つ人を分け、変更・障害・廃止の判断者を決めます
✅ 個人利用、部門共有、複数部門での利用に応じて、台帳・テスト・権限・運用の確認を増やします
✅ 研修の成果物には試作品だけでなく、テスト記録、利用手順、引き継ぎ方法を含めます

市民開発とは、現場の業務知識を開発へ生かす取り組み

この記事では市民開発を、専門の開発部門ではない社員が、ローコードやノーコードなどを使い、業務用のアプリや自動化を作る取り組みとして扱います。

ローコードは、すべてをプログラムで書かず、画面操作や用意された部品を使って開発する方法です。ノーコードも似た考え方ですが、よりコードを書かずに作ることを指します。両者の境界は製品によって異なるため、ここではまとめて扱います。

市民開発の強みは、現場の困りごとを知る人が改善へ参加できることです。修正をすべて情報システム部門へ依頼するより、試行を速く進められる場合があります。

一方、利用者と接続先が増えるほど、個人の便利ツールでは済まなくなります。

AIworkerが1,000件を超える商談データを分析した傾向では、市民開発やノーコードに関する話題が5.3%で確認されています。これは市場全体の導入率やアンケートの回答率ではなく、企業との商談で関連する言及があった割合です。

相談で問われるのは、作り方だけではありません。誰が維持するのか、社内データへどこまで接続してよいのか、現場で作ったものをどこから専門開発へ渡すのか。全社へ広げる段階では、この線引きが必要になります。

Microsoftの公式ガイダンスが示していること

MicrosoftのPower Platform導入ガイダンスでは、大規模な導入に必要なものとして、明確な方針、役割と責任、データへのアクセス、環境管理、開発・テスト・展開の基準などを挙げています。

運営方法も、中央の専任チームが管理する形だけではありません。各部門へ管理を任せる分散型と、共通ルールは中央、日々の運用は部門が担うハイブリッド型も示されています。

また、作成者だけでなく、環境を管理する担当者にも役割別の研修が必要だとしています。作る人と管理する人では、学ぶ内容が違うためです。

この記事の確認項目は、この公式ガイダンスを参考にしながら、製品を問わず使えるようAIworkerが整理したものです。Microsoftが定めた認定基準ではありません。実際の権限や環境構成は、使用する製品と社内規程に合わせて管理者が確認してください。

個人の便利ツールから、共有する仕組みへ

同じアプリでも、自分だけが使う段階と、複数部門が日常業務で使う段階では、問題が起きたときの影響が違います。

これは、人数だけで決まる承認基準ではありません。

個人利用でも、顧客の個人情報や重要な経営データを扱うなら、厳しい確認が必要です。反対に、公開情報を使った社内イベントの案内ツールで、止まってもすぐ手作業へ戻せるなら、軽い運用で始められるでしょう。

見るのは、利用人数、扱う情報、外部への接続、誤りの影響、元へ戻しやすいかです。

作成者と業務責任者を分けて書く

作成者は、アプリや自動化を作り、技術的な変更を行う人です。業務責任者は、その仕組みをどこで使うか、どの変更を認めるか、いつ停止するかを決める人です。

同じ人が兼ねることはできます。ただし、役割は分けて記録してください。

業務責任者がいないまま利用者だけが増えると、作成者が業務上の判断まで背負うことになります。「この項目をなくしてよいですか」「過去データも一括更新してよいですか」と聞かれても、作成者だけでは決められません。

少なくとも、次の役割を決めます。

小さな会社で6人を置く必要はありません。1人が複数の役割を兼ねても構いません。ただ、誰が何を決めるのかは書き分けます。

最初に作るのは、アプリの一覧

全社展開を考える前に、すでに何が作られているかを確認します。

アプリ名だけの一覧では不十分です。最低限、次を記録します。

何の業務で使うものか
業務責任者と作成者は誰か
誰が使っているか
どのデータや外部サービスへ接続しているか
本番、テスト、個人試行のどれか
問い合わせ先と代替手順
最終更新日と次回確認日
継続中、見直し中、廃止予定のどれか

ここで、所有者がいないアプリや、誰も用途を説明できない自動化が見つかることがあります。いきなり削除せず、利用状況と接続先を確認してください。止めると別の業務へ影響する可能性があるからです。

反対に、利用者が誰もおらず、接続もなく、責任者も決まらないものは、残し続ける理由を見直します。棚卸しは、管理対象を増やす作業ではありません。維持するものを選ぶ作業でもあります。

展開前に使う6項目の確認シート

次の表を「確認済み・未決定・該当なし」で記録します。未決定には、担当者と決める期限も入れてください。

共有フォルダへ手順書を置いただけでは、引き継ぎは終わっていません。別の担当者が実際にその手順を読み、起動、通常操作、エラー時の確認までできるかを試します。

説明用の架空例として、毎月の集計を自動化する仕組みを考えてみましょう。

正しい入力ファイルで1回成功しても、毎月使えるとは限りません。入力ファイルがない、列名が変わった、同じデータが二重に入った、接続先へログインできない場合も試します。失敗したときに処理が途中で止まり、誤った集計結果を配布しないことも確認します。

市民開発の運用と権限を、自社の製品や体制に合わせて整理したい方はAIworkerへご相談ください。

▶️ サービス資料のダウンロード（資料請求）

市民開発研修のゴールに「作った後」を含める

研修の発表会でアプリが動くと、完成したように見えます。

しかし、講師が用意したデータで、作成者本人が操作できたことと、部署で使い続けられることは別です。実務への移行を目指すなら、試作品に加えて次の成果物を残します。

利用目的と対象業務
利用者と必要な権限
入力、処理、出力の説明
正常時と失敗時のテスト記録
日常の操作手順
問い合わせ先と代替手順
使用している接続先や部品
変更履歴と次回の確認日

初学者に大規模な設計書を求める必要はありません。まずは、本人以外が使うために必要な情報を1枚へまとめます。

さらに、別の受講者が手順書だけを見て操作する演習を入れると効果的です。「このフォルダは全員知っている」「この列は毎月同じ名前」といった、作成者しか知らない前提が見つかります。

研修の修了条件も、「アプリを完成させた」だけにしません。別の人が使える、失敗時の動きを確認した、業務責任者が受け入れたところまで分けて評価します。

全社で統一する部分と、現場へ任せる部分を分ける

すべての変更を中央の管理部門が行うと、依頼が集中して市民開発の速さが失われます。一方、各部署が接続先や権限まで自由に決めると、会社全体の状況を把握できません。

Microsoftの公式ガイダンスにも、中央集約型、分散型、それらを組み合わせるハイブリッド型が示されています。実務では、共通ルールと現場判断の境界を決めることが重要です。

兼務中心の企業では、最初から複雑な申請制度を作らなくても構いません。まず、利用中の仕組み、業務責任者、作成者、接続先の一覧をそろえます。そのうえで、止まったときの影響が大きいものから確認します。

AIを組み込む場合に追加する確認

市民開発ツールへ生成AIやAIエージェントを組み込むと、同じ入力でも出力が変わることがあります。また、AIがメール送信やデータ更新まで行う場合、誤りの影響も広がります。

通常の確認に加えて、次を決めます。

AIへ入力してよい情報
参照する社内データとアクセス権
回答の正しさを確かめるテスト
根拠がない場合や判断できない場合の動き
AIが実行できる操作と、人の承認が必要な操作
使用するモデルや指示を変えたときの再テスト
出力、エラー、費用の確認方法

特に、AIが「読む」ことと「更新する」ことを同じ権限にしないよう注意してください。最初は検索、要約、下書きに限定し、人が確認してから実行する方法があります。

詳しい考え方は、生成AI・AIエージェントの権限設計で解説しています。

市民開発だけに任せないほうがよい場面

次のような仕組みは、早い段階から情報システム部門、セキュリティ担当、専門の開発者を交えます。

止まると売上、顧客対応、法令対応へ大きく影響する
個人情報や重要な機密情報を広く扱う
複数の外部システムへ書き込みを行う
決済、契約、削除、権限変更を自動化する
高い可用性や短時間での復旧が求められる
作成者以外が仕組みを説明できない

これは、市民開発を中止するという意味ではありません。

現場が業務要件を整理して試作品を作り、専門担当が設計、品質、セキュリティ、運用を補う分担もできます。作れるかどうかだけではなく、責任を持って維持できるかで範囲を決めます。

作成者の異動が迫っている場合は、新規展開より引き継ぎが先です。目的、接続先、権限、担当、代替手順が分からないまま、利用者を増やしてはいけません。

全社展開の判断チェックリスト

業務の目的と利用範囲を説明できるか
作成者とは別に、業務責任者を決めたか
利用者、データ、外部接続を台帳へ記録したか
入力・閲覧・更新・削除の権限を分けたか
正常時だけでなく、空欄・重複・接続失敗を試したか
問い合わせ先と障害時の代替手順があるか
変更を依頼・承認・記録する方法があるか
別の担当者が手順どおり操作できたか
作成者が不在でも、停止と復旧ができるか
使わなくなったときの接続解除とデータ処理を決めたか
AIを使う場合、出力の評価と人の承認を設計したか
管理部門へ相談する条件を現場へ伝えたか

未決定が残っていること自体が問題なのではありません。誰がいつ決めるのかがないまま、利用者を増やすことが問題です。

よくある質問（FAQ）

Q. 市民開発に情報システム部門は必要ですか？

製品の環境、データ、権限、外部接続について、社内で管理責任を持つ人との協力が必要です。専任の情報システム部門がない場合も、その役割を誰が担うかを決めます。

Q. すべてのアプリに同じ審査が必要ですか？

必要ありません。利用者、扱う情報、外部接続、停止時の影響、元へ戻しやすいかで確認の深さを変えます。ただし、誰が使い、誰が責任を持つかは小さなアプリでも記録します。

Q. 作った本人に運用も任せてよいですか？

兼務はできます。ただし、業務上の変更を本人だけで決めないこと、不在時の窓口と引き継ぎ先を用意することが大切です。運用時間も正式な担当業務として確保します。

Q. 全社展開の前に、最初に確認することは何ですか？

すでに使われているアプリの一覧と、業務責任者を確認します。何が動いているか分からないまま、新しい申請制度だけを作っても管理できません。

Q. 研修で作ったアプリを、すぐ実務で使えますか？

演習で動いたことだけでは判断できません。自社の環境とデータでのテスト、業務責任者による受け入れ、必要な管理手続きを経てから移行します。

Q. 作成者が異動するときは、何を引き継ぎますか？

操作手順だけでなく、利用目的、利用者、接続先、権限、変更履歴、テスト、問い合わせ、復旧、廃止方法を渡します。後任者が実際に操作とエラー対応を試してください。

Q. 使われていないアプリは削除してよいですか？

利用者、接続先、他の仕組みからの参照を確認してから判断します。止めても影響がないことを確かめ、必要なデータや記録を扱ったうえで廃止します。

Q. 全社管理を厳しくすると、市民開発が進まなくなりませんか？

すべてを同じ審査へ通すと遅くなります。低リスクの試行は簡易に始められるようにし、機密情報、外部接続、複数部門への展開など、影響が大きくなる条件で確認を増やします。

作れる人を増やすだけでなく、使い続けられる状態を作る

市民開発の全社展開で必要なのは、作成者を増やすことだけではありません。

何が動いているか分かる。業務の責任者がいる。変更と問い合わせの相手が決まっている。担当者が替わっても続けられる。使わなくなったら安全に終えられる。

こうした状態があって、現場の工夫を会社の仕組みへ広げられます。

AIworkerでは、市民開発や生成AI研修の設計だけでなく、対象業務の棚卸し、アプリ台帳、権限、テスト、運用、引き継ぎまでを支援しています。市民開発で続ける範囲と、専門開発へ移す範囲が決まっていない段階から一緒に整理できます。