市民開発とは何か？「全員がアプリを作るDX」が危ない理由

市民開発は、DX推進の現場でかなり魅力的な考え方です。Power Automate、Power Apps、kintone、Excelマクロ、簡易な業務アプリ、自動通知フローなどを、業務をよく知る人が自分たちで作れるようになれば、改善の速度は上がります。

ただし、市民開発を「全員がアプリを作れる状態」とだけ理解すると、かなり危うくなります。ローコードはコードを書く量を減らしますが、業務フローの構造化、データ設計、例外処理、権限管理、保守責任、廃止判断までは肩代わりしてくれません。

大事なのは、全員を開発者にすることではありません。作る人、要件を出す人、使う人、守る人を分け、それぞれが何を判断し、どこで相談し、どこから先は管理対象にするのかを決めることです。

市民開発の中心にあるのは、「業務をよく知っている人が、改善のアイデアを自分たちで形にする」という発想です。たとえば、申請内容を一覧にするPower Apps、承認依頼を自動で送るPower Automate、現場の入力を集約するkintone、定型集計を行うExcelマクロなどが典型です。

背景には、IT人材不足、外注依存の限界、現場改善のスピード要求があります。小さな改善のたびに大きな開発案件として扱っていると、業務側の困りごとはなかなか解消されません。そこで、業務側が一定範囲の改善を自分たちで行えるようにする。

ここまでは、かなり自然です。問題は、その先です。業務で使われるアプリやフローは、作った瞬間から「便利な道具」ではなく「業務の一部」になります。業務の一部になったものには、止まったとき、間違えたとき、担当者が異動したときの扱いが必要です。

ローコードツールの画面では、ボタンを置く、フォームを作る、条件分岐を選ぶ、通知先を指定する、といった操作ができます。コードを何百行も書かなくても、業務アプリや自動化フローを作れる。この点は大きな価値です。

一方で、業務システムに必要な考え方は残ります。どのデータを正とするのか。誰が入力できるのか。承認後に修正できるのか。例外時は誰に通知するのか。フローが止まったら業務は手動で続けられるのか。こうした問いは、ローコードになっても消えません。

「作れる人」を増やすだけでは、ここが抜けやすくなります。ツール操作の研修だけでは、市民開発の土台として足りません。業務を構造化する力、例外を想像する力、保守できる形に整える力が必要です。

このあたりを見ずに「作れる人を増やそう」と進めると、市民開発は便利な改善活動から、管理されない業務システムの増殖へ変わります。

たとえば、誰が作ったかわからないPower Automateフローが、毎朝の通知を支えている。保守者不在のPower Appsが、現場の申請入口になっている。Excelマクロが定例資料の数値を加工しているが、作成者の異動後に誰も中身を追えない。

一つひとつは、善意の改善です。困っている人がいて、詳しい人が助けた。その場では確かに役に立ちます。けれど、業務に組み込まれたあとも、所有者、保守者、権限、変更履歴、廃止判断がないままだと、後から組織が困ります。

これは、業務システムに生えた無断配管に近い状態です。最初は水が流れて助かる。けれど、どこにつながっているか、誰が閉められるか、漏れたらどこを止めるかが分からない。便利さの裏で、監査不能、数値不整合、権限管理の漏れ、業務停止のリスクが積み上がります。

市民開発の運用で重要なのは、「作る人を増やす」よりも、「関わり方を分ける」ことです。業務を知っている人全員が、アプリを作れる必要はありません。一方で、全員が何らかの形で市民開発に関われる状態は作れます。

この整理にすると、「全員がアプリを作る」という言い方の粗さが見えてきます。現場の多くの人に必要なのは、開発スキルそのものではなく、困りごとを言語化する力、使い方を守る力、異常を報告する力です。

逆に、市民開発者層には、操作研修だけでなく、業務フロー、データ、権限、例外、保守の基礎を学ぶ場が必要です。そして、保全・ガバナンス層には、作られたものをすべて抱え込むのではなく、重要度に応じて管理の強さを変える判断が求められます。

市民開発を止めずに安全側へ寄せるなら、最初から重い審査だけを置くよりも、作る前に考える型をそろえるほうが始めやすくなります。

この5つをすべて完璧に書く必要はありません。書けない項目があるなら、そこが相談ポイントです。市民開発では、作成前の会話で不明点を見つけること自体に価値があります。

市民開発を進めると、推進担当者に負荷が集まりがちです。研修をする。質問に答える。作れない人の代わりに作る。エラーを調べる。権限も見る。経営層には導入率や利用者数を示す。現場からは「早く直してほしい」と言われる。

ここで推進担当者が頑張り続けると、短期的には前に進みます。しかし、支援負荷が見積もられていないまま広げると、結局は「詳しい人に聞く」「推進担当が直す」「困ったら個別対応」という形に戻ります。これは、市民開発の属人化です。

必要なのは、推進担当者の根性ではありません。問い合わせの切り分け、テンプレート、作成物の棚卸し、重要度の分類、標準部品、相談窓口、教育範囲、廃止ルールを設計することです。市民開発を広げるなら、支援業務そのものも設計対象になります。

生成AIが普及すると、市民開発の速度はさらに上がります。Power Automateの条件式、Excelマクロ、簡単なスクリプト、業務アプリの画面案などを、AIに相談しながら作れる場面は増えていきます。

これは便利です。ただし、作成者自身が中身を十分に理解していないまま、業務に組み込めてしまう危うさもあります。AIが出した式やフローが、通常時は動く。けれど例外時にどう壊れるか、データがどこへ残るか、誰の権限で実行されるかが見えていない。ここが新しいリスクになります。

生成AI時代の市民開発では、「作れるか」よりも、「壊れ方を想像できるか」「保守できる形に整えられるか」「責任境界を決められるか」が重要になります。つまり、ツールが賢くなるほど、組織側の設計思想が問われます。

市民開発を危ないものとして遠ざける必要はありません。現場の人が、自分たちの困りごとを構造化し、ローコード／ノーコードで改善できるようになることには大きな価値があります。

ただ、その価値を長く使うには、「全員がアプリを作るDX」という言い方から少し離れたほうがよさそうです。全員が同じ開発者になるのではなく、要件を出す人、作る人、使う人、守る人が、それぞれの役割で関われる状態を作る。

市民開発の本当の目的は、管理されない小さなシステムを増やすことではありません。現場改善を、組織として扱える形に変換することです。自由さと安全さを対立させず、改善を見える場所に出し、支えられる形に整える。その設計があって初めて、市民開発はDX推進の力になります。