はじめに

第1回と第2回では、EUCや神エクセルが短期的には現場を救いながら、長期的には組織に負の遺産を残していった歴史を確認した。
本稿では視点を現在に移し、RPAやノーコード／ローコードといった現代の市民開発プラットフォームの光と影を検討する。

これらは神エクセルの再演であると同時に、規模と依存度の点でより大きなリスクをはらんでいる。次回で生成AIのインパクトを考える上でも、その性質を正しく把握しておく必要がある。

シリーズ全編

光──なぜ受け入れられたのか

即効性

プログラムを書かなくても、GUI操作で簡単な自動化やアプリがすぐに完成する。日次の転記や定型処理をわずか数日で置き換えられる効果は現場にとって極めて大きい。

見える化の説得力

フローチャートや画面設計を目で見て理解できる形にできるため、専門知識を持たない層にも分かりやすい。経営層にとっては「動く絵」として成果が見えることが大きな安心感となり、導入推進の決定要因になることが多い。

市民による第一歩

入力フォームや簡易ワークフローのような限定的な用途であれば、非エンジニアでも自作できる。ここまでは確かに「誰でもできる」を実感でき、組織全体で市民開発の裾野を広げる入口となる。

影（1）──実務に現れる“プロフェッショナルの壁”

表面的には「誰でも扱える」ように見えるが、実務で本格的に利用しようとすると、結局はプログラミングと同質の発想やSE的な設計視点が求められる。

  • 制御構造の必然
    顧客条件ごとに処理を分けるには条件分岐（If/Else）が要る。数百件のデータを扱うには繰り返し（ForEach）が欠かせない。外部システムの応答遅延やエラーに備えるには例外処理（Try/Catch）が必須になる。GUIで配置できる形になっているだけで、本質的にはプログラミングである。

  • データ構造の理解
    JSONや配列を展開し、階層をマッピングし、日付や数値の形式を揃える――こうした作業は業務連携には不可欠だ。単なる表形式の置き換えでは済まず、データ構造を理解できなければ破綻する。

  • システム間連携の複雑性
    API認証の有効期限管理、複数システムを跨ぐ一貫性担保、レート制限の回避など、従来のソフトウェア工学と同じ課題がそのまま持ち込まれる。GUIが隠しているだけで、難易度はむしろ高い。

  • 運用と品質の要件
    監視・ログ収集・テスト環境と本番環境の差分管理・リリース時のロールバックなど、運用面の設計が欠ければすぐに混乱が訪れる。コードで管理できない分、可観測性は低下しやすい。

こうした壁を前に、市民開発者が単独で実務に耐えるシステムを構築・維持するのは難しく、結局は専門技術者に依存せざるを得なくなる。専門部隊のキャパシティ問題は解決していないにもかかわらず、である。

影（2）──ベンダーロックインと移植の困難さ

神エクセルにはまだ救いがあった。そもそも1つのファイルである。表形式データはCSVとして出力でき、関数やマクロはExcelにロックインされてはいるが部分的であっても互換性のある表計算ソフトウェアは存在したし、コードや関数は読み解くことが可能であった。
一方、RPAやノーコード／ローコードの成果物はほとんどがプラットフォーム固有のUIや設定ファイルに閉じ込められることになる。

  • 他社製品への移行は事実上「最初から作り直す」に等しい。
  • SaaSのサービス終了や仕様変更は利用者の制御外であり、蓄積した資産が一夜にして無価値になる可能性がある。
  • PaaS上で構築した場合、そのクラウドのエコシステムに縛られ、他環境への持ち出しは極めて困難である。
  • コードではなくUIでロジックを定義する場合問題個所を検索しにくい、発見しにくい、という問題を引き起こす。
  • ツール設計次第ではあるが部品をダブルクリックしないと中の処理が分からない、等可読性を下げる構造のものも多い。

このように、表計算ファイル単位で完結していた神エクセルと比べても、依存度と負債化のリスクは格段に大きいのである。

影（3）──経営層を惑わす“見える化バイアス”

技術者から見れば「実務に現れる“プロフェッショナルの壁”」に早晩行き着く事は明らかだ。
だが経営層はGUIで描かれたフローや画面を見せられると「これなら誰でも使える」と考えてしまいやすい。

なぜか。経営層にとってシステムは通常ブラックボックスであり、そこに矢印で結ばれた業務プロセスや入力フォームが並ぶと、内部の複雑性を理解した気になってしまうからである。
しかし現実には、その背後で発生するのはプログラムと同じ制御ロジックやエラー処理であり、実務に適用し耐えうる仕組みとするにエンジニアリングの知識が不可欠になる。

この「経営層の安心感」と「技術者の危惧」のギャップが、導入を加速させつつ将来の負債を拡大させる温床となる。

神エクセル2.0の時代へ

こうして整理すると、RPAやノーコード／ローコードは神エクセルと同じパターンをなぞっている。
即効性で現場を救い、見える化で経営層を説得し、やがてブラックボックス化と属人化によって組織に重荷を残す。

ただし決定的に違うのは、その影響範囲である。神エクセルはファイル単位で完結していたが、現代の市民開発はクラウドや基幹業務全体に組み込まれ、組織規模で縛り付ける負債となり得る。
更にExcelより強固なロックイン構造を持っている始末である。
これこそが「神エクセル2.0」とでも呼ぶべき状況を招くであろう。

まとめ

  • RPAやノーコード／ローコードは、即効性と見える化の説得力によって現場と経営層の双方に受け入れられた。
  • しかし実務に耐えるには、制御構造・データ構造・システム連携・運用設計といったソフトウェア工学の知識が不可欠であり、市民開発者だけでは構築・維持できない。
  • プラットフォーム固有のUIは移植を非常に困難にし、ベンダーロックインを強める。
  • 経営層の“見える化バイアス”は、こうしたリスクを過小評価させる。

結局、現代の市民開発は神エクセル以上に強力であると同時に、実は神エクセル以上に危うい。
次回は、この流れに生成AIが加わると何が起こるのかを検討する。

次回：生成AIが市民開発に与える影響4/7