市民開発が失敗する本当の理由 ーガバナンスとセキュリティは「統制」ではなく「設計思想」の問題
市民開発が失敗する本当の理由 ーガバナンスとセキュリティは「統制」ではなく「設計思想」の問題である
市民開発とDXの現在地
デジタルトランスフォーメーション（DX）が企業経営の重要課題として定着する中、ノーコード／ローコードツールを活用し、現場部門の社員自らが業務アプリケーションを開発する「市民開発（Citizen Development）」への注目が高まっています。市民開発は、現場ニーズを迅速かつ柔軟にシステムへ反映できるだけでなく、企業の競争力そのものを左右する可能性を持っています。
一方で、「思ったほど定着しない」「途中で頓挫した」という声が後を絶たないのも事実です。
本稿では、市民開発が失敗に至る根本原因を、「ガバナンス」と「セキュリティ」という二つの観点から整理します。結論から言えば、市民開発の成否を分けるのはツールやスキルではなく、それを支える設計思想にあります。。
市民開発とは何か
市民開発とは、「Microsoft Power Platform」や「kintone」に代表されるノーコード／ローコードツールを活用し、業務を熟知した現場の社員が自らアプリケーションを開発する取り組みです。
背景には、次のような構造的課題があります。
- DX推進における「現場不在」の弊害
市民開発は、IT部門に集中していた開発権限を現場へと分散させるアプローチとして期待されているのです。
市民開発は「ITの民主化」である──ただし
市民開発はしばしば「ITの民主化」と表現されます。
しかし、民主化とは単なる権限移譲ではありません。歴史を振り返れば、権限だけが移譲され、責任や判断基準、統制の仕組みが設計されなかった民主化が混乱を招いた例は少なくありません。
ITの世界でも同じことが言えます。重要なのは、権限と同時に責任の所在、判断基準、そして全体を導く仕組みが設計されているかどうかです。
EUCが残した「失敗の記憶」
日本国内では実質的に1990年代後半以降に普及したEUC （End-User Computing）は、当時としては画期的な取り組みでした。メインフレーム中心の集権的ITから、現場が自らPCや表計算ソフトを使って業務を効率化する流れは、まさに「ITの分権化」であり、思想的には現在の市民開発と地続きです。
しかしEUCは、多くの企業で「失敗体験」として記憶されています。その原因は、現場主導そのものではなく、次のようなガバナンス不全にありました。
- 全社的な設計原則やデータ定義がなく、システムが乱立・スパゲッティ化した
- 開発・保守の責任主体が曖昧で、属人化・ブラックボックス化が進んだ
- セキュリティや内部統制が後追いとなり、善意に依存した運用になった
- IT部門が統制者としてのみ振る舞い、支援者になれなかった
結果としてEUCは、「自由な現場改善」ではなく「統制不能なシャドーIT」と見なされるようになります。この経験が、「現場に任せると混乱する」という組織的トラウマを生み、市民開発への過剰な警戒心につながっているのです。
市民開発が失速する「３つの理由」
市民開発の成果には企業ごとに大きな差があります。その分かれ目となるのが、次の三点です。
1. スキル・リソース不足
ノーコード／ローコードであっても、業務理解や基本的なITリテラシーは不可欠です。一方で、「自分の業務とは関係ない」「学習する余裕がない」といった心理的ハードルも存在します。
2. 統制型ガバナンスと挑戦文化の衝突
多くの日本企業では、ガバナンスが「価値創出を支える仕組み」ではなく、「リスクを最小化するための統制」として理解されてきました。その結果、形式上は市民開発を推奨しながら、失敗時の責任追及や過度な承認プロセスが残り、現場の挑戦意欲を削いでしまいます。
3. セキュリティが“拒否権”になる
市民開発が頓挫する最大のボトルネックが、セキュリティです。「情報漏洩のリスクが高まる」「非専門家の開発は危険」「監査に耐えられない」といった理由から、セキュリティ部門が“止める側”に回ってしまうケースは少なくありません。
セキュリティは市民開発の敵ではない
無秩序な市民開発が危険であることは事実です。しかし問題は、市民開発そのものではなく、セキュリティをどのように設計しているかにあります。多くの企業で見られる失敗パターンは次の三つです。
- セキュリティを後付けにしてしまう
- セキュリティ部門が拒否権者になっている
- リスクを一律に禁止してしまう
本来、セキュリティの目的は「開発を止めること」ではなく、「安心して挑戦できる環境を提供すること」にあります。ゼロリスクを目指すのではなく、現実的なリスク許容度を定義し、リスクを分類し、仕組みで守る──それが市民開発と両立するセキュリティ設計です。セキュリティとは、市民開発を抑圧するための鎖ではなく、挑戦を支えるためのインフラなのです。
ガバナンスの「そもそも論」
ガバナンスという言葉は、「統制」「監視」「縛り」といったネガティブな響きで語られがちです。しかし、その語源は、古代ギリシャ語の kybernân（舵を取る、操舵する） にあります。これがラテン語 gubernareを経て、現代のgovernへとつながっているのです。つまり本来的には、ガバナンスの意味するところは、「船の進行方向を定め、状況に応じて舵を調整する行為」だといえます。船を縛るのではなく、風や潮流、船体の癖を読みながら、沈まないように、そして目的地に向かうように導く──それがガバナンスの原義なのです。市民開発が失敗するとき、ガバナンスは事後的な規制として導入されがちです。しかしそれは、嵐の最中に船員を縛り上げるようなものです。
本来必要なのは、前段階での舵取り──設計思想としてのガバナンスです。
市民開発を支える文化
市民開発が持続的に機能するためには、「自由」と「統制」を対立概念として捉えないガバナンス設計が不可欠です。その前提となるのが、「問題を可能性として捉える姿勢」です。この考え方は、オープンソース文化やシリコンバレーに影響を与えたエリック・レイモンドの思想にも通じます。
“The world is full of fascinating problems waiting to be solved.”
問題は単なる障害ではなく、学びや価値創出の起点である──こうした姿勢を組織として共有できるかどうかが、市民開発の成否を分けます。日本企業にも、かつてはこの精神が存在しました。サントリー創業者・鳥井信治郎の「やってみなはれ」という言葉に象徴されるように、挑戦を肯定する文化は日本企業の競争力の源泉だったはずです。
市民開発フレンドリーな企業文化を根付かせている企業の一例が、サイボウズです。同社が提供する「kintone」は、市民開発プラットフォームとして広く利用されていますが、その背景には柔軟な働き方や多様性を重視する企業文化があります。
働きがいのある職場環境づくりと、社員の主体性を尊重する姿勢は、市民開発やDX推進と表裏一体の関係にあります。ツール導入と同時に文化への投資を行っている点が、同社の特徴と言えるでしょう。
ツール導入だけではDXは成功しない
19世紀末、清の洋務運動は、西洋技術を取り入れながら思想や制度の変革を伴わなかったことで限界を露呈しました。同様に、思想と文化を伴わないDXは、いずれ形骸化します。市民開発とは、単なる開発手法ではありません。社員一人ひとりが会社の経営課題の解決者となるための、組織変革そのものなのです。
まとめ
市民開発の成否を分けるのは、ツールでも制度でもありません。挑戦を奨励し、学びを評価し、問題解決を楽しむ文化を築けるかどうか──それこそが、DX時代の企業価値を左右します。市民開発は、正しく設計されれば、企業にとって強力な成長基盤となります。その可能性を最大限に引き出すために、いま求められているのは「文化への本気のコミットメント」です。
筆者：W.S.
ITガバナンスおよび市民開発推進を得意領域とするコンサルタント。中堅〜大手企業のIT統制設計・DX推進支援に従事。個人開発者としてJavaScriptおよびFirebaseを用いたWebアプリ開発にも取り組み、開発現場と統治設計の両面からDXを研究している。同志社大学大学院経済学研究科博士後期課程修了単位取得退学。
＼今なら無料！／
【30分DX無料相談 実施中】
「業務を効率化したいけれど、どこから手をつければいいかわからない…」「どのツールが自社に合っているのか、比較検討したい…」
そんな悩みに、経験豊富なDX推進コンサルタントが個別に対応！
→ お申込みはこちら：https://www.qloba.com/forms/10862?_gl=1*1iahbda*_g...
