自治体のDXに関わる人たちとXでkintoneについてやりとりしたとき、代表の渥美洋行はローコードツールについてこう書きました。
結局大半のローコードツールはキックオフには良くても、運用になると行き詰まります。よく考えて導入しないと引き継いだ人は地獄です
渥美は中央省庁で24年働き、いまはAA WAVE合同会社の代表社員と行政書士をしながら、自治体のDXの相談を受けています。
このやりとりを、ローコードツールを入れる前に確かめたいことに整理し直したのが、渥美のnoteです。
推進する部署にいて、否定的
きっかけは、ある自治体の情報システム担当の方の投稿でした。DXを推進する部署にいながら、デジタルデトックスについて率直に書いていたのです。
その方が示した一覧には、ひとつの自治体が住民に案内しているオンライン申請の窓口が並んでいました。
マイナポータル、汎用電子申請システム、フォーム作成ツール、ローコードツールに付いた申請フォーム、e-Tax、eLTAX、eMAFF、e-Gov、ねんきんネット。投稿した方は、この乱立を当事者として心配していました。
渥美はその投稿に、kintoneはどうかと尋ね、自分は割と否定的だと書き添えました。否定的なのは、野良アプリが生まれやすいと考えるからです。
返ってきたのは、本人は否定的な立場でも、部署としては推進する立場だという答えでした。やりたいことを実現するにはカスタマイズが前提になり、メンテナンスや引き継ぎが現実的にできるのかが問われる、という話です。
公開してよいものといけないものの区別や、公開の設定を誤ることも怖い、とその方は書いていました。
推進する立場にいながら、本人は否定的。多くの自治体の情報システム担当がいま置かれているのはこの立場ではないか、と渥美は書いています。
一括処理は、ローコードの外にある
テストアカウントで実際に使ってみた方は、過度な期待はしないでほしいと書いていました。
その方は言い換えて、一括処理のようなバッチの形はすべてコードなので、ローコードツールの対象ではないということかもしれない、とも書いていました。
渥美は、この整理を鋭いと評しています。ローコードという考え方がそもそも受け持たない範囲として、問題を置き直しているからです。
問題は個々のツールの出来ではなく、ローコードという枠組みでできることの範囲にあります。導入の前にその限りを知らなければ、疲れ果てるのは現場の職員です。
連携サービスを足すほど、手入れが重くなる
情報システム担当の方は、ひとつの許可の手続をkintoneで電子化するときの構成も書き出していました。
申請の受付、住民が審査状況を見る画面、許可証の作成、メールの送付、許可に伴う料金の徴収と収納管理、許可の更新管理。本体のほかに、いくつもの連携サービスを組み合わせる構成です。
その方は、将来メンテナンスが行き届かなくなる予感しかしない、と書いていました。
この構成では、本体だけで業務が完結しません。連携サービスを一つ足すごとにライセンス料が重なり、バージョンアップのたびに互換性を確かめる手間が要ります。
担当者が異動すれば、なぜその連携が必要なのかを理解する人がいなくなります。
野良Accessと同じことが起きる
議論の論点は、参加した方の次の一言にまとまっていました。便利なように作り込むとあとでメンテナンスに困り、野良Accessが野良アプリになるだけだ、というものです。
かつて多くの組織が「野良Access」の問題を経験しました。Accessは便利で、誰でも業務アプリを作れたのです。
そのため各課でデータベースが作られ、作った人が異動したあと、誰も直せないものが庁内に散らばりました。同じことが、ツールの名前を変えて起きる、という指摘です。
渥美自身も、公務員時代にAccessやExcelのマクロで業務の仕組みを作っていました。異動のときは、後任の人が引き継いでも動かせないので、自分で消しました。
できないことが多いのは、守りにもなる
否定的な声が続くなかで、別の見方を出した方もいました。LoGoフォームは一時的なデータの収集に、kintoneは長く持つデータの管理に使う、というイメージです。
どちらも、プログラミングの知識がなくても画面を作りやすい。細かいことはできなくても、生成AIの使い方を誤ってセキュリティの弱いアプリを量産するよりは、ガードレールになるのではないか、という見方でした。
職員が生成AIに業務アプリのコードを書かせて量産する場合と比べると、ツールの制約の中で「できることだけ」をやるほうが、起きうる問題の上限を見通せます。できないことが多い点は、裏を返せば守りにもなる、と渥美は書いています。
やりとりのなかでは、「kintoneはLoGoフォームの代わりになるか」という問いも出回っていました。一時的にデータを集めることと、長くデータを管理することは、役割が違います。
LoGoフォームとkintoneの役割を分けた見方は、比べる軸がそもそも違うことを示している、と渥美は受け止めました。
この方は、大量の野良Accessの世話をしてきたので警戒心がある、その警戒心が後ろ向きと見られがちだ、とも書いていました。慎重さが抵抗勢力のように扱われる空気も、自治体DXの現場にある厄介な圧力だと渥美は見ています。
生成AIで職員が業務ツールを作る研修で、渥美が参加者と交わしている約束は、コラム「研修の当日、役職者が自分の道具を作った」で紹介しました。
入れる前に確かめたい五つのこと
渥美はいまも、自治体の仕事で「ツールで何をすべきか」という相談を受けます。やりとりで出た論点を、導入の前に確かめることとして並べたのが、次の五つです。
- 1一括で更新する処理が要るか要るなら、その部分はローコードの範囲の外になります。
- 2本体のほかに、いくつの連携サービスを組み合わせるか足すごとにライセンス料が重なり、更新のたびに互換性を確かめる手間が増えて、引き継いだ人が連携の理由を知らないということも起きます。
- 3データを一時的に集めるのか、長く持ち続けるのかフォームで足りるのか、台帳として管理するのかを分ける問いです。
- 4何を公開してよく、何を公開してはいけないか公開の設定を誤ったらどうするかも、あわせて確かめます。
- 5作った人が異動したあと、誰が直すのかやりとり全体を通して出てきた問いです。
どの項目も、作る人と引き継ぐ人と判断する人を決めないと答えられません。
簡単なものには大げさ、複雑なものには足りない
やりとりのなかでは、まずは簡単なものから始めるとしても、それならローコードツールでやる意味はあまりないのでは、という問いも出ました。この問いに、はっきりした答えは出ていません。
簡単なものにはローコードツールは大げさで、複雑なものには足りない。帯に短し襷に長しです。
安易に「導入しましょう」とも「やめましょう」とも言い切れない煮え切らなさを、渥美は現場を知っている人の正直な着地点と書きました。答えが出ないまま終わったこと自体に、誠実さがあるという見方です。
「よく考えて導入しないと引き継いだ人は地獄です」という渥美の投稿と、ガードレールになるのではないかという見方は、矛盾しません。
誰が作り、誰が引き継ぎ、誰が判断するのか。問われているのはkintoneではなく、組織です。
AA WAVEは、自治体の業務手順の見直しと生成AIの活用を支援しています。ツールをどの業務で使うかを、業務プロセスの見直し（BPR）とあわせて検討したいときにご相談ください。
Xでのやりとりの経緯は、渥美のnoteに書いています。
kintoneに「割と否定的」と書いた僕が、自治体のローコード導入の前に確かめたいこと（note）