ローコード・ノーコードの広がり
ここ数年、ローコード・ノーコードという言葉を聞く機会が増えた。Power Apps、kintone、Appsheet。プログラミングなしで業務アプリが作れるという触れ込みで、大手企業を中心に導入が進んでいる。
背景にあるのは「市民開発」という考え方で、IT部門ではなく現場の担当者が自分で業務ツールを作る。これ自体は理にかなっている。業務を一番よく知っている人が、自分の手で仕組みを作れるなら、それが最も速い。
ただ、この流れを見ていて一つ面白い矛盾がある。
属人化の扱いが揺れている
DXの文脈では「属人化を解消しましょう」がほぼ定番の提言になっている。特定の人しかできない業務はリスクだから、標準化・マニュアル化しましょう、と。
一方で、市民開発は「現場の個人がツールを作る」ことを推奨している。作った人がいなくなったらどうするのか、という問いに対する答えは、正直あまり見かけない。
これは別にコンサルの言っていることが間違っているわけではない。属人化の解消と市民開発は、対象としているレイヤーが違う。業務プロセスの属人化は確かにリスクだが、ツールを作る能力が特定の人に集中すること自体は、中小企業では避けようがない現実でもある。以前の記事で「属人化のトリアージ」として整理したが、何を標準化して何を属人のまま許容するかは、一律に決められる話ではない。
ローコードが選ばれる合理的な理由
ローコード・ノーコードが大手企業で支持されている理由は、技術的なハードルの低さだけではない。もっと実務的な理由がある。
配布と改修の管理ができる。 ここがExcelとの最大の違いだと思っている。Excelで作った業務ツールは、ファイルをコピーすれば誰でも使える。しかし裏を返せば、配布したファイルを誰かが勝手に改修しても止められない。数式を壊す、マクロを無効にする、構造を変える。こういったことが日常的に起きる。
ローコード・ノーコードのプラットフォームでは、アプリはサーバー上で一元管理される。利用者はアプリを「使う」だけで、中身を触ることはできない。改修できるのは作成者だけ。この構造は、数十人〜数百人規模の組織でツールを展開するときに大きな意味を持つ。
誰が何を使っているかが見える。 IT部門の立場からすると、社内にどんなツールがあり、誰が使っているかを把握できることは重要になる。Excelファイルが各自のPCに散らばっている状態では、この把握がほぼ不可能。ローコード・ノーコードのプラットフォームなら、管理画面からアプリの一覧、利用状況、作成者が確認できる。
権限管理が標準装備されている。 閲覧だけの人、編集できる人、管理者。こうした権限の切り分けがプラットフォーム側で用意されている。Excelファイルに対して同じことをやろうとすると、フォルダのアクセス権やSharePointの設定など、別のレイヤーで対応する必要がある。
こうした特徴は、組織としてのIT統制を求められる環境では合理的な選択になる。大手企業がローコード・ノーコードを採用する背景には、こうした管理面のメリットが大きい。
データの持ち方という視点
ローコードのプラットフォームにデータを預けるということは、そのプラットフォームに依存するということでもある。以前の記事で「データが特定のツールに閉じ込められない状態を維持する」と書いたが、この原則はローコードにも当てはまる。
ただ、これはローコードの欠点というより、トレードオフとして理解したほうがいい。Excelファイルが各自のPCに散らばっている状態は、確かにデータは手元にあるが、統制が取れていない。ローコードのプラットフォームにデータを集約すれば統制は取れるが、プラットフォームへの依存が生まれる。
大手企業がこのトレードオフでプラットフォーム側を選ぶのは、組織規模を考えれば自然なことだと思う。数百人の社員が使うツールのデータが個人のPCに散らばっていたら、それこそ管理不能になる。
中小製造業ではどうか
では中小製造業、特に多品種少量の受注生産をやっている会社ではどうか。
自分の結論としては、ローコード・ノーコードが最適な選択肢になるケースはかなり限られると考えている。
組織の規模が違う。 ローコードの管理面のメリットは、ある程度の人数がいて初めて効いてくる。社員数十人の会社で、ツールを使う人が5〜10人程度なら、Excelファイルの管理で困る場面はそこまで多くない。誰が何を使っているかも、声をかければわかる距離感にある。
業務の変化速度に対する柔軟性。 多品種少量の受注生産では、業務プロセスが頻繁に変わる。ローコード・ノーコードは「用意された部品の組み合わせ」で作るため、プラットフォームが想定していない要件に当たると途端に行き詰まる。Excelなら力技でも何とかなる場面が、ローコードだと「できない」で終わることがある。
コストの問題。 ローコード・ノーコードはユーザー数に応じたライセンス費用がかかる。月額数百円のプランもあるが、業務で本格的に使おうとすると一人あたり数千円は必要になる。中小企業にとってこの固定費は軽くない。Excelは既にライセンスがあるケースがほとんどで、追加コストがかからない。
データの主権。 これは規模に関係なく重要な話で、ローコードのプラットフォームに業務データを預けるということは、そのプラットフォームが値上げしたり、サービスを終了したりしたときに、自社のデータと業務ロジックが人質になるリスクを抱えるということ。中小企業にとって、このリスクは大手以上に重い。代替手段を検討する体力が限られているからこそ、データは自分の手元に置いておきたい。
「管理のしやすさ」と「自由度」のバランス
結局のところ、ローコード・ノーコードとExcel VBAの選択は、組織として何を優先するかの問題になる。
管理のしやすさを優先するなら、ローコード・ノーコード。 配布管理、権限管理、利用状況の把握。組織としてのIT統制が求められる環境では、これらの機能が標準で備わっていることの価値は大きい。
自由度とデータの主権を優先するなら、Excel VBAや内製プログラミング。 業務の変化に柔軟に対応でき、データは自分の手元にある。ただし管理は自分たちでやる必要がある。
中小製造業の場合、組織の規模と業務の特性を考えると、後者のほうが合っていることが多い。Excelの「誰でも触れてしまう」という特性は、裏を返せば「誰でも直せる」「誰でも改善できる」ということでもある。この柔軟さは、多品種少量の受注生産で日々変化する業務に対応するうえで、むしろ強みになる。
管理面の不安があるなら、以前の記事で書いたようにExcelのシート構造を整理し、データシートとUIシートを分離するだけでも、かなりの部分は解消できる。ツールが大きくなって管理が追いつかなくなったら、そのときはローコードではなく、C#やPythonなどの専用言語にステップアップするほうが、長期的にはデータの主権を保ったまま保守性を確保できる。
このシリーズの他の記事：