生成AI時代の市民開発を、情シスはどう支えるべきか ――禁止ではなく、管理できる開発基盤へ

生成AIやローコード／ノーコードツールの普及により、業務アプリケーションの開発は、従来のようにエンジニアだけが担うものではなくなりつつあります。

現場の担当者が、自然言語で作りたいものを説明し、AIの支援を受けながら業務ツールやワークフローを試作する。こうした動きは、今後さらに広がっていくと考えられます。

一方で、情報システム部門やDX推進部門にとっては、歓迎すべき面ばかりではありません。

現場が独自にツールを作ることで、誰がどのデータにアクセスしているのか分からなくなる。似たようなツールが部門ごとに増える。AIが生成した処理内容を十分に検証しないまま、実務で使われる。こうした懸念は非常に現実的です。

しかし、だからといって現場主導の開発を全面的に止めることは、必ずしも現実的ではありません。むしろ重要なのは、現場の開発意欲を禁止することではなく、安全に活かせる仕組みを用意することです。

生成AI時代の市民開発において、情報システム部門に求められる役割は、「作らせない」ことではなく、「安全に作れる状態を設計する」ことへ移りつつあります。

市民開発が広がる背景

市民開発が注目される背景には、生成AIの進化だけでなく、企業が抱える構造的な課題があります。

多くの企業では、業務改善や社内ツール開発のニーズが増え続けています。一方で、情報システム部門や開発部門のリソースには限りがあります。

現場から見ると、日々の業務には小さな不便が数多く存在します。案件や申請状況を確認するために複数のファイルを開く。顧客対応履歴をメールやチャットから探す。Excelで集計した結果を別のシステムに転記する。承認状況を確認するために担当者へ個別に連絡する。

一つひとつは大きなシステム開発案件には見えないかもしれません。しかし、現場にとっては日々の負担になっている業務です。

例えば、次のような業務は、市民開発の対象として検討されやすい領域です。

• 案件や申請状況の管理

• 在庫・発注・出荷情報の確認

• 顧客対応履歴の整理

• 複数システムにまたがるデータ確認

• Excelで行っている集計や承認作業

• 社内向けの簡易ダッシュボード作成

これらは、基幹システムを大きく作り替えるほどではないものの、現場の業務効率に直結します。

これまでは、こうした小さな業務改善がIT部門の開発待ちになり、優先順位の都合で後回しになることも少なくありませんでした。その結果、Excel、スプレッドシート、メール、手作業による暫定運用が長く続くことがあります。

生成AIやローコード開発の普及により、こうした改善を現場主導で進められる可能性は高まっています。

問題は「現場が作ること」ではなく「見えないまま使われること」

市民開発に対する懸念の多くは、現場がツールを作ること自体ではなく、それが情シスの管理外で進むことにあります。

部門ごとに異なるツールが作られ、誰が管理しているのか分からない。どのデータに接続しているのか分からない。退職者が作ったツールがそのまま残り、仕様を理解している人がいない。

このような状態になると、市民開発は業務改善ではなく、シャドーITや技術負債につながってしまいます。

特に生成AIを使った開発では、作成スピードが上がる一方で、レビューやテスト、権限管理、データの取り扱いが後回しになるリスクがあります。画面や処理の雛形を短時間で作れるようになるほど、作ったものを誰が確認し、どの範囲で使ってよいのかを明確にする必要があります。

つまり、企業にとって必要なのは、市民開発を止めることではありません。

必要なのは、誰がアプリを作成・編集できるのか、誰がそのアプリを利用できるのか、どのデータベースやSaaS、APIに接続しているのか、本番環境と検証環境が分かれているのか、変更履歴や操作ログを追跡できるのかを把握できる状態にすることです。

また、重要な業務や機密性の高いデータに関わるアプリについては、適切な承認やレビューを挟む必要があります。

市民開発に必要なのは、自由放任ではなく、ガードレールです。

情シスの役割は「門番」から「支援者」へ

従来、情報システム部門は、システム導入や開発に対する“門番”としての役割を担うことが多くありました。

もちろん、セキュリティやコンプライアンスの観点から、一定の制御は不可欠です。業務データや顧客情報を扱う以上、誰でも自由にアプリを作り、自由にデータへ接続できる状態は望ましくありません。

一方で、ビジネス部門の変化スピードが高まる中で、すべての業務改善を情シスが直接開発・管理するモデルには限界があります。

これからの情シスに求められるのは、現場の開発を一律に止めることではなく、安全な開発基盤を用意し、現場がその上で改善を進められるようにすることです。

低リスクな業務改善は現場がスピーディーに進める。一方で、高リスクなデータ連携や本番運用は、情シスがレビュー・管理する。接続先や権限、環境、監査ログはプラットフォーム側で統制する。

このように役割分担を設計することで、スピードとガバナンスを両立しやすくなります。

情シスがすべての画面やツールを個別に作るのではなく、現場が安全に改善できる基盤を整える。市民開発が広がる時代には、この役割転換が重要になります。

現場主導の業務改善を安全に進めるためのユースケースや、Retoolを活用した内製化の進め方をまとめた資料をご用意しています。
市民開発とガバナンスの両立に関心のある方は、資料請求ページをご覧ください。

問い合わせ

Retoolで実現できる「現場開発」と「統制」の両立

Retoolは、社内業務アプリや管理画面、ワークフロー、AIを活用した業務ツールを短期間で構築できる開発プラットフォームです。

一方で、Retoolは単に早く作れるだけのツールではありません。企業での利用を前提に、ユーザーやグループごとの権限管理、アプリ単位・リソース単位でのアクセス制御、データベースやSaaS、APIへの接続管理、開発・検証・本番などの環境分離、監査ログ、SSO、Git連携など、統制に必要な機能を備えています。

これにより、現場が必要な業務アプリを素早く作りながら、情シスは接続先、権限、運用ルールを管理できます。

例えば、現場担当者は画面や業務フローを作成し、情シスはデータ接続や権限、リリースルールを管理する。あるいは、現場が試作したアプリを情シスが確認し、本番利用に必要な設定を整えたうえで公開する。

このような分担により、現場のスピードを活かしながら、企業として必要な統制を維持できます。

特に生成AIを活用する場合、AIが生成したアプリやワークフローをそのまま本番業務に使うのではなく、誰が確認するのか、どのデータに接続するのか、どこまで自動実行してよいのかを設計する必要があります。

Retoolのような開発基盤を使うことで、AIを活用した業務改善を、情シスが管理できる形で進めやすくなります。

市民開発を成功させるための3つの考え方

市民開発を安全に進めるためには、ツールの導入だけでは不十分です。重要なのは、どの業務を誰が作り、どの範囲で使い、どのように管理するのかを設計することです。

1. すべてを同じルールで縛らない

簡単な部門内ツールと、顧客情報や基幹データを扱うアプリでは、必要な管理レベルが異なります。

例えば、部門内のタスク一覧や簡易的な確認画面であれば、現場が素早く作り、改善していくことが有効な場合があります。一方で、顧客データ、売上データ、人事情報、基幹システムに接続するアプリでは、情シスによるレビューや権限設計が必要になります。

すべてのアプリを同じルールで縛ると、現場の改善スピードが落ちます。反対に、すべてを自由にすると、リスクが高まります。

重要なのは、リスクに応じて管理レベルを分けることです。

2. 接続先と権限をプラットフォーム側で管理する

市民開発で特に問題になりやすいのは、データアクセスです。

誰でも自由にデータベースやSaaSに接続できる状態では、情報漏えいや過剰権限のリスクが高まります。特に生成AIを活用する場合、AIがどのデータを参照し、どの処理を実行できるのかを明確にする必要があります。

そのため、現場がアプリを作る場合でも、接続先や認証情報は情シスが管理できる仕組みが必要です。

アプリを作る自由度と、データアクセスの統制は分けて考えるべきです。現場には業務改善のスピードを持たせつつ、重要なデータや接続情報はプラットフォーム側で管理する。この設計が、市民開発を安全に進めるうえで重要になります。

3. 作った後の運用まで見える化する

市民開発は、作って終わりではありません。

誰が保守するのか。変更時に誰が確認するのか。利用状況や操作履歴を確認できるのか。利用されなくなったアプリをどう整理するのか。こうした運用面まで見える化する必要があります。

特に、現場主導で作られたアプリは、担当者の異動や退職によって管理者が不明になることがあります。最初は便利だったツールが、数年後には誰も仕様を把握していないブラックボックスになることもあります。

市民開発を継続可能な仕組みにするには、作成者、利用者、接続先、変更履歴、利用状況を把握できる状態にしておくことが重要です。

市民開発は、情シスの負担を減らす可能性もある

市民開発というと、情シスにとって管理対象が増えるものとして捉えられがちです。

確かに、統制のない市民開発はリスクになります。しかし、適切な基盤とルールを用意できれば、市民開発は情シスの負担を減らす可能性もあります。

現場が自分たちで改善できる領域を増やせば、情シスがすべての小さな改善要望を個別に受ける必要はなくなります。情シスは、より重要な基盤設計、データ接続、セキュリティ、全社横断の標準化に集中しやすくなります。

また、現場が試作したものをもとに、情シスが本番化の観点で整えるという進め方も可能です。最初から要件定義に時間をかけるのではなく、実際に動くものを見ながら改善することで、現場と情シスの認識ズレも減らしやすくなります。

市民開発は、情シスを不要にするものではありません。むしろ、情シスがより重要な役割に集中するための仕組みとして設計することが重要です。

生成AI時代に求められるガードレール

生成AIによって、市民開発のスピードはさらに上がります。

これまでであれば、画面作成やロジック実装に一定の知識が必要でした。しかし今後は、自然言語で指示するだけで、アプリやワークフローのたたき台を作れる場面が増えていきます。

この変化は、業務改善にとって大きな可能性があります。一方で、作成スピードが上がるほど、ガードレールの重要性も増します。

具体的には、AIが生成した処理を誰が確認するのか、どの範囲まで自動実行してよいのか、どのデータを参照してよいのか、エラーが起きたときにどう戻すのか、操作ログをどう残すのかを設計する必要があります。

生成AI時代の市民開発では、現場に任せる範囲と、情シスが管理する範囲をあらかじめ整理しておくことが重要です。

禁止するのではなく、見える化する。

止めるのではなく、安全に使える範囲を決める。

個別対応するのではなく、共通の基盤とルールで支える。

この考え方が、市民開発を継続的な業務改善につなげるうえで重要になります。

Retoolでガードレールを設計する

こうしたガードレールを実務に落とし込むうえで、Retoolのような開発基盤を活用する意義があります。

Retoolでは、現場が業務アプリやワークフローを作成しやすい一方で、情シスはデータ接続、権限、環境分離、監査ログ、SSO、Git連携などを通じて、企業として必要な統制を維持できます。

たとえば、現場担当者が画面や業務フローの改善に関わり、情シスが接続先データ、利用権限、本番反映のルールを管理する。あるいは、現場が試作したアプリを、情シスがセキュリティや運用の観点から確認したうえで本番利用につなげる。こうした分担が可能になります。

特に生成AIを活用する場合、アプリやワークフローの作成スピードはさらに高まります。そのため、AIがどのデータに接続するのか、誰が利用できるのか、どこで人の確認を挟むのかを、個別の判断に任せず、共通の基盤上で管理できることが重要です。

Retoolは、現場の改善スピードを活かしながら、情シスが管理できる形で市民開発を進めるための選択肢になります。自由に作らせるのでも、すべてを禁止するのでもなく、ガードレールのある環境で業務アプリの内製化を進める。この設計が、生成AI時代の市民開発には求められます。

まとめ：市民開発は「禁止」ではなく「安全に活かす」段階へ

生成AIの普及により、現場主導の開発は今後さらに広がっていくと考えられます。

この流れを完全に止めることは難しく、また必ずしも得策ではありません。

重要なのは、現場が勝手に作る状態を放置することではなく、情シスが安全な基盤とルールを用意し、現場の力を活かせる状態をつくることです。

スピードとガバナンスは、必ずしも対立するものではありません。

適切なプラットフォームと運用設計があれば、現場の改善スピードを高めながら、企業として必要な統制を維持することができます。

Retoolは、そのための選択肢の一つです。

現場の業務改善を止めずに、情シスが管理できる形で進めたい。そのような企業にとって、市民開発を安全に支える開発基盤の整備は、今後ますます重要になるでしょう。

現場主導の業務改善を進めるうえでは、どの業務を現場に任せ、どの領域を情シスが管理するのかを整理することが重要です。

Retoolのユースケースや導入事例をまとめた資料をご用意しています。
市民開発とガバナンスを両立しながら、業務アプリの内製化を進めたい方は、ぜひ資料をご覧ください。

問い合わせ