できることが広がる!「市民開発」の行方

こころみマガジン

この前、話を伺ったのは組織でトップのポジションにおられる方。

自らkintoneでアプリを作っているそうで、「トヨエツみたいでしょ」と茶目っ気たっぷりにおっしゃっていた。

kintoneに代表されるように、非エンジニアでその業務に知見のある人が自らアプリを作ることを「市民開発」という。

「市民開発」自体は、広義の意味においては以前からあるものだが、ここへきてできることが広がっている。

今後、市民開発はどうなるのかを考えていこうと思う。

Excelから始まった市民開発の歴史

市民開発の始まりは1980年代と言われる。そう、PCが登場しはじめた頃のことだ。

それまでは「メインフレーム」と呼ばれる高額なコンピューターでシステムが稼働していた。

メインフレーム全盛期を知る前職の先輩は、「SEは先生のように扱われていたんだよね~」と懐かしそうに言っていた。

私がSEだった時は先生という雰囲気はまるでなく、どちらかといえば「業者」扱いだったので、「そんな時代もあったのね」と思ったものだ。

それだけ、コンピューターが利用者にとって身近になったとも言える。

最初の市民開発は「お手製のデータベース」であったと思う。

Excelの出現により、「表形式」という誰にでもわかりやすい形で情報を管理できるようになった。

2000年代には、いわゆる「基幹システム」が多くの企業に導入された時代だ。

「ダウンサイジング(小型化)」という言葉があったが、メインフレームからより安価なPCサーバーが登場し、価格面でメインフレーム時代のような敷居の高さはなくなった。

しかし、煩雑な作業はいっこうに減らない。

販売管理システム、顧客管理システムなど、システムはさまざまあるが、どのシステムでも処理できない業務というのが発生してしまう。

いずれかのシステムに取りこめればベストだが、取り込むだけで高額な費用と長い期間が必要になる。

そこで業務をする人がExcel自力で作った簡易的なシステムが大流行した。

一連の動作をマクロで「自動化」したり、転記やデータ処理などを効率化するべく「VBA」と呼ばれる簡易的な言語でプログラミングしてExcelで動作させることができるようになった。

「EUC(エンドユーザーコンピューティング」「Excel職人」という言葉が出現したのもこのころだ。

「RPA」で効率化の先の「働きやすさ」を目指す

しかしExcelでは埋められない溝があった。

例えば、外部のWebサイトからデータをダウンロードし、自社のシステムに入力する。

あるシステムにあるデータを別のシステムへ入力する。

これらの作業を人が画面を操作して行うのは、今でもよくあることだ。

煩雑な作業であり、かつ内容によっては「絶対に間違えられない」ものもある。

すると「入力した内容をプリントアウトして、他の人がダブルチェックをする」といった作業もやらなくてはならない。

「絶対に間違えられない作業」は、面倒なだけでなく心理的なプレッシャーものしかかる。

こうした問題を解決するために生まれたのが「RPA」だ。

RPAは人間が行う画面操作や照合をその通りに自動化するというもの。

日本でも2016年ごろから大ブームとなった。

夜中、RPAに大量の作業をやってもらい、朝に社員が確認する形なら、さらなる時短にもつながる。

RPAについては当時、様々な会社に話を聞いた中で印象的だったのが、「業務を改善しようという意識が生まれた」という話だ。

RPAはいままでのオペレーションを自動化するだけなので、業務の改善ではない。

しかし省力化したことで時間が空き、「この業務もRPA化できるのではないか」という議論が活発化したという。

作業の中には、非効率的なものも多く含まれているのが世の常だが、実際に担当している人は「そういうもの」だと思っているから、改善の意識が働かない。

RPAを導入すると、効率性が実感でき、いろいろとアイデアも生まれるということなのだろう。

業務の抜本的な改革を、自らの手で。「ローコード・ノーコードツール」

そして今、花盛りなのが「ローコード・ノーコードツール」だ。

冒頭で話のでたkintoneもこのカテゴリに入る。

ローコード・ノーコードツールはその名の通り、コーディングが必要ない、あるいは簡易的なコーディングでシステム(アプリ)が作れるツールのこと。

私がSE時代は、言語によって担当するエンジニアが分かれていて、誰かの経歴書を見た時「Javaのコーディング経験が3年以上あれば、「一人前にプログラムを組めるな」と判断したものだった。

しかし今や、誰でも簡単にアプリが作れてしまう。

RPAは「オペレーション通り」に自動化するだけだが、ローコード・ノーコードツールは、業務を抜本的に見直した上で、アプリを作ることができる。

愛知県でも、外部コンサルタントに委託してBPRを実施し、その結果、必要とされるアプリを職員の方が作成している。

https://www.soumu.go.jp/main_content/000944774.pdf

ただし簡単にアプリが作れる分、自由度は低い。

自由度を高めようとすると、ゴリゴリとコーディングするか、プラグインを入れて機能を増強するかなのだが、前者は結局できる人が限られてしまうし、後者はお金がかかる。

アプリもどんどん作られるようになるので、管理も大変だ。

次世代「市民開発」の姿

意外に長い歴史がある市民開発だが、この先注目は、やはり生成AIだろう。

以前の記事で「SaaSの死」という言葉を紹介した。

これは今使っているSaaSの機能も、生成AIに言えば作ってくれる時代がもうそこまできているということだ。

市民開発も同じこと。「こんなアプリがほしい」といえば、生成AIがサッと作ってくれる時代になるかもしれない。

ローコード・ノーコードツールで課題になっている「自由度の低さ」や「管理の大変さ」も、AIが全て統制してくれれば言うことはない。

生成AIのこれからのステージは「基幹となる業務プロセス」にどれだけ食い込めるか、に尽きる。

先日AIについて有識者にお話を聞いた時、「AIを使えるようになれば、もっと仕事が楽しくなりますよ」と言っていたのが印象的だった。

AIをどのように使うかを考える仕事が、これから増えてくるのだと思う。