ノーコードプログラミングへの期待と不安 ─ 私が「ポータブルな技術」を選ぶ理由
Day16の続き：なぜ「枯れた技術」なのか
昨日のDay16で、伴走支援では「枯れた技術」を使うことをお勧めしますと書きました。
今日はその背景として、ノーコード/ローコードへの私の考えを書きます。
ノーコード/ローコードとは
ノーコード/ローコードという言葉をご存知でしょうか。
ノーコード: プログラミングなしでアプリを作れるツール
ローコード: 最小限のコードでアプリを作れるツール
国内市場は2023年度で約800億円、年12%以上の成長率で拡大しています。
ノーコード/ローコードの2つの文脈
ノーコード/ローコードという言葉には、2つの文脈があります。
1. プロ開発者向け（ローコード）
SIerのエンジニアや企業の情報システム部門が使う。
開発スピードを上げるためのツールです。
これはプロの道具であり、使いこなせれば価値があります。
2. 市民開発向け（ノーコード）
「プログラミング不要で業務アプリが作れる」
現場の担当者が自分でアプリを作れる「市民開発」という考え方です。
有名どころの kintone をはじめ、様々なツールが登場しています。
人材不足に悩む中小企業にとって、魅力的な選択肢に見えます。
市民開発、導入を検討していませんか？
中小企業の経営者や情シス担当の方で、市民開発ツールの導入を検討している方もいらっしゃるのではないでしょうか。
「現場が自分でアプリを作れるなら、IT人材不足を解消できるかもしれない」
でも、検討を進めても、なかなか結論が出ない。
導入事例を見ても「本当に自分たちで開発できるのだろうか」と疑問が残り、自社に合うかどうか判断が難しいですよね。
そこで、実装型コンサルタントを名乗る私の考えを書きます。
私がノーコード（市民開発）を積極的に勧めない理由
正直に言います。
私は市民開発向けのノーコードツールを積極的には勧めていません。
理由は3つあります。
1. 実行速度・処理品質の課題
ノーコードツールは、汎用的に作られています。
そのため、特定の業務に最適化されたコードと比べると、実行速度や処理品質に課題が出ることがあります。
小規模なうちは問題になりません。
でも、データ量が増えたり、処理が複雑になると、限界が見えてくることがあります。
2. メンテナンス性の課題
ノーコードで作ったアプリは、ブラックボックスになりやすい。
誰が何のために作ったのか分からない「野良アプリ」が乱立する。
作った人が異動や退職すると、誰もメンテナンスできなくなる。
「野良Excel」が「野良アプリ」に変わっただけ、ということが起きることを懸念しています。
3. スキルがポータブルでない
これが一番大きな理由です。
あるノーコードツールを覚えても、そのスキルは外では使えません。
別のツールに移行したら、また一から学び直しです。
私は各社のプラットフォームごとにスキルがサイロ化してしまうのを懸念しています。
担当者が転職したとき、次の会社で活かせるでしょうか。
会社がツールを乗り換えたとき、学び直しが必要になります。
「ポータブルな技術」という選択
私が勧めるのは、ポータブルな技術 です。
JavaScript、SQL、HTML/CSS、Excel VBA。
これらは特定のプラットフォームに依存しません。
そして、いずれも 20年以上使われ続けている技術 です。
JavaScript（1995年〜）：約30年
SQL（1970年代〜）：約50年
HTML/CSS（1990年代〜）：約30年
Excel VBA（1993年〜）：約30年
20年以上の歴史があるということは、情報が豊富で、相談できる人も多い。
ネット上にも情報が多く、すなわち生成AIの学習対象も豊富です。
これが「枯れた技術」の強みです。
JavaScriptを覚えれば、GASでもNode.jsでもReactでも使える
SQLを覚えれば、どのデータベースでも基本は同じ
どの会社に行っても、どのプロジェクトでも活かせる
Day16で「枯れた技術」と書きました。
もう少し正確に言えば、ポータブルで、情報が豊富な技術 です。
伴走支援との相性
Day16で書いた「伴走支援」と、ポータブルな技術は相性が良いです。
伴走支援のゴールは「社内で回せるようになること」。
社内の担当者にスキルを移転します。
そのとき、ポータブルな技術なら：
担当者が転職しても、次の会社で活かせる
会社としても、汎用スキルを持つ人材を採用しやすい
困ったときに相談できる人が見つかりやすい
特定ツールのスキルより、長期的な価値があります。
ノーコードを否定はしない
誤解のないように補足します。
ノーコード/ローコードが適切な場面もあります。
プロトタイプを素早く作りたいとき、非エンジニアが簡単な自動化をしたいとき。
ただ、「銀の弾丸」ではないということです。
導入前に、メンテナンス性やスキルのポータビリティを考慮する。
その上で選ぶなら、良い選択になり得ます。
まとめ
ノーコード/ローコードの構造的な課題：
実行速度・処理品質
メンテナンス性（野良アプリ化）
スキルのサイロ化
ポジショントークと言われそうですが、やはり私が勧めるのは「ポータブルな技術」。
JavaScript、SQL、HTML/CSS、Excel VBA。いずれも20年以上の歴史がある技術です。
また、少し新しめですが Google Workspace + GASも、世界中で安定して利用されており、ビジネスインフラとしての地位を確立しています。
現在は生成AIによる支援も受けられます。
「枯れた技術」であれば、特定プラットフォームに依存せずにどこでも使えるスキルが身につきます。
自動化などの技術選定に迷ったら、ぜひご相談ください。
