はじめに

第4回では、コード化されなかった資産が将来に残る負の遺産になることを確認した。
ここで改めて問い直したいのは――市民開発は本番システムを作る手段なのか？ という点である。

結論から言えば、市民開発は本番を担う仕組みではない。
その本質は、**利用者目線の要件定義を「動く形」に落とし込む“下書き開発”**である。

この視点を持たずに「市民開発＝誰でもすぐにシステムを作れる魔法のツール」と誤解すると、歴史が繰り返すように再び負の遺産を大量生産することになる。
では“下書き開発”とはどのような意味を持ち、どのように活用すべきなのかを整理してみよう。

シリーズ全編

下書き開発の価値とは何か

市民開発で現場が作るアプリやツールは、しばしば「未完成」あるいは「粗削り」と見なされる。
だがその“粗さ”こそが価値である。

利用者目線の要件が浮き彫りになる

営業部がローコードで作った顧客管理アプリを想像してほしい。
そこには利用者が日々の業務で感じている「こうでなければ不便だ」という直感が反映される。

  • 入力項目の粒度
  • 一覧画面で何を並べたいか
  • ボタン配置や動線の自然さ

これらは単なる「要件定義書」では伝わらない。文章で仕様を説明しても、現場が求めるニュアンスや“業務の肌感覚”はほぼ抜け落ちる。
動くプロトタイプがあればこそ、「これなら使える」「いや実際には不便だ」という反応がリアルに引き出される。

誤認・不足の発見が早い

さらに、動作する下書きがあると、
「ここに検索機能がないと困る」
「承認フローは三段階ではなく二段階にすべきだ」
といった要件の誤認や不足が早期に見つかる。

これまでのシステム開発では「要件定義書を読み込んだ専門家が想像で設計する」ケースが多かった。
そのため完成後に「想定と違う」と現場から不満が噴出し、手戻りが発生することが常態化していた。
市民開発はその不毛な手戻りを削減する強力な武器になりうる。

本番化の落とし穴

しかし、下書きをそのまま本番化してはいけない。
そこには大きな落とし穴が潜んでいる。

  • スケーラビリティ：小規模部署では動くが、全社導入すればすぐに性能が限界を迎える。
  • セキュリティ：アクセス制御やログ管理が甘く、監査や法令遵守に耐えられない。
  • 保守性：属人化が進み、作成者が異動や退職すればブラックボックス化する。

つまり「下書きに価値がある」と「下書きを本番にしてよい」はまったく別物である。
神エクセルが一時的に救世主となり、最終的に負の遺産へ転落したのと同じ構図を繰り返すだけになる。

専門家との役割分担

では市民開発の成果物をどう扱うべきか。答えは明快だ。

  • 市民＝下書きを作る：利用者目線を具体化し、試作品を提示する。
  • 専門家＝清書をする：非機能要件（拡張性・セキュリティ・保守性）を満たした形で再構築する。

この役割分担を徹底することで、両者は互いの強みを最大化できる。
市民は「生の現場感覚」をそのままツールに落とし込む。
専門家は「品質と持続性」を保証する清書を担う。

従来の開発手法が「要件定義書だけを頼りに想像で設計」していたのに対し、下書きが存在すれば最初から解像度の高い議論が可能になる。
これによりシステム開発は効率化され、成果物の品質も向上する。

ガバナンスで守るべきこと

市民開発を健全に活用するには、組織としてのルールが不可欠である。

  • 明確化：「市民開発成果物は試作品にとどめる。利用範囲も限定する」と規定する。
  • 棚卸し：放置されたアプリやRPAを定期的に整理・廃棄するプロセスを設ける。
  • 移行プロセス：有用な下書きは必ずIT部門へ引き渡し、清書を経て本番化する流れを制度化する。

こうしたガバナンスを整えれば、神エクセルのような負の遺産を再生産するリスクを大幅に減らせる。
逆にこのルールがなければ、市民開発は単なる“野良アプリ製造機”となり、組織の技術的負債を増やすだけで終わる。

まとめ

市民開発は「誰でも本番システムを構築できる万能の仕組み」ではない。
だが“下書き”として用いれば、要件定義の誤認や不足を減らし、利用者目線を十分に反映したシステム設計を実現できる。

本番を担うのは専門家、下書きを描くのは市民。
この役割分担を徹底することで、市民開発は負の遺産ではなく、未来の生産性向上の起点となる。

すなわち、市民開発の真の意義は「民主化された要件定義のプロセス」にある。
この理解があって初めて、市民開発は組織にとって持続可能な力になるのである。

次回：視座のズレが負の遺産を量産する6/7