振り子の回帰【第2回】 - なぜ今、プロコードが戻ってきたのか

開発の世界では、数年おきに「もうコードを書かなくていい」という話が出てくる。

画面で部品を選び、条件をつなぎ、ワークフローを組む。プログラミングを知らなくても、自分たちで業務ツールを作れる。ローコード、ノーコードという言葉には、たしかに明るさがあった。

それは単なる流行語でもなかった。小さな申請フォーム、社内の確認フロー、簡単なデータ入力画面。そういうものを短い時間で立ち上げるには、ローコードはいまでも強い。

だが、業務システムはデモ画面の中だけで生きているわけではない。

本番の現場には、古いExcelが残っている。部署ごとに言葉が違う。例外データが混ざっている。似たような帳票が、少しずつ違う形で残っている。

そして、動き始めてから必ず出てくる。

「ここだけ少し変えたい」

この「少し」が、案外いちばん重い。

枠の中では速い。枠の外では遅くなる。

ローコードは、用意された枠の中では速い。画面を作る。項目を置く。条件をつなぐ。通知を飛ばす。標準機能の範囲なら、かなり短い時間で形になる。

けれど、標準から一歩外れた瞬間に、急に窮屈になる。

最初はそれでも回る。だが、次の改修でその約束を思い出せない。担当者が変わる。仕様書には残っていない。なぜこの分岐があるのか、誰も説明できなくなる。

気づけば、コードを書かないために、コードを書くより複雑なことをしている。

問題は、ローコードが悪いということではない。道具の枠に、業務のほうを合わせ始めることだ。

この差は、初回リリースではあまり目立たない。むしろ最初は、ローコードのほうが気持ちよく進むことも多い。

けれど、半年後、一年後、二年後に効いてくる。項目を足す。例外を拾う。別システムとつなぐ。昔のデータを移す。新しい担当者に引き継ぐ。

そのたびに、どこまで自分たちで触れるのかが問われる。

コードを書かないことが、目的になっていないか。

いつの間にか、目的がすり替わることがある。

本来の目的は、業務を楽にすることだったはずだ。速く作ること、直しやすくすること、間違いを減らすこと、必要なデータを残すことだったはずだ。

ところが、途中から「コードを書かずに作ること」そのものが目的になってしまう。

コードを書かないために、複雑な設定を積む。コードを書かないために、無理な運用ルールを作る。コードを書かないために、手作業を残す。

それでは、道具を使っているのか、道具に使われているのか分からない。

ノーコード、ローコードという考え方は、入り口を広げた。その功績は大きい。だが、入り口が広がったことと、最後までその道具だけで行くべきかどうかは別の話である。

AIは、プロコードの前提を変えた。

かつてプロコードの弱点は、工数だった。

書ける人が限られる。時間がかかる。細かな修正にも専門家の手が必要になる。仕様が変われば、またコードを書き直す。テストも必要になる。

だから、ローコードは魅力的だった。多少の制約があっても、早く作れることには大きな価値があった。

ところが、生成AIがその前提を動かした。

要件を言葉にし、AIに初稿を書かせ、人間が読んで直す。TypeScript、Python、PHP、SQL。汎用的な言語ほど、AIはよく知っている。

画面の雛形、APIの呼び出し、バリデーション、データ変換、テストのたたき台。以前なら手で積み上げていた部分が、かなり速く形になる。

もちろん、AIが出したコードをそのまま信用してよいわけではない。むしろ、読める人間の価値は上がる。

だが、初稿を書く重さは明らかに下がった。ならば、無理に独自ツールの枠へ押し込めるより、コードとして残して、人間が握るほうが自然な場面が増える。

AIと相性がいいのは、意外にも「普通のコード」だった。

AIにとって扱いやすいのは、広く読まれ、広く書かれ、文脈が外に開かれているものだ。

TypeScript、Python、PHP、SQL。こうした言語は、世界中に例がある。書き方も、失敗例も、設計パターンも、説明も多い。

一方で、ローコードツールの独自画面や独自設定は、外から見えにくい。画面を開かなければ分からない。設定値の意味が、ツールの中に閉じている。

AIに質問することはできる。だが、実際の設定画面、実際の分岐、実際のデータの流れまで含めて扱うには、まだ見えない部分が多い。

テキストで書かれたコードは違う。貼れる。読める。比較できる。差分が見える。レビューできる。直した理由を残せる。

AI時代になって、古く見えたはずのテキストコードが、むしろ最も扱いやすいインターフェースとして戻ってきた。

コードは、後から直すための言語でもある。

コードの価値は、書けることだけではない。

読めること。検索できること。差分を追えること。テストできること。壊れた理由を説明できること。別の場所へ持っていけること。

Gitで履歴が残る。レビューができる。自動テストを組める。デプロイの手順を整えられる。小さな修正を、小さな修正のまま扱える。

長く使うものほど、この差は大きくなる。

画面の見た目では分からない。初回リリース時にも、あまり目立たない。けれど、二度目、三度目の変更で効いてくる。

あとから直せる形で残す。それが、プロコードの強さだ。

ベンダーロックインは、気づいたときには深い。

ローコードやノーコードの便利さは、プラットフォームの中にある。

部品が用意されている。認証がある。データ連携がある。権限管理がある。ワークフローがある。最初からそろっているから、早く作れる。

だが、そろっているということは、その世界のルールに乗るということでもある。

料金体系が変わる。使いたい機能が上位プランに移る。制限に当たる。別の環境へ移したくても、設定やデータ構造がそのままでは持ち出せない。

気づいたときには、業務の都合よりも、ツールの都合を優先している。

もちろん、すべてを自前で持つ必要はない。クラウドも、SaaSも、ローコードも、使えばいい。

ただし、どこを預け、どこを自分たちの制御下に残すのか。その線引きは、これまで以上に重要になる。

プロコード回帰は、懐古ではない。

プロコード回帰という言葉だけを見ると、昔に戻るように聞こえる。

だが、実際にはそうではない。昔のように、すべてを人間が一行ずつ書く時代へ戻るわけではない。

横にはAIがいる。雛形はAIが出す。単純な処理もAIが書く。調査の入口も、テストのたたき台も、以前よりずっと速く作れる。

人間が握るべきものは、全部を書くことではない。

どこを任せるか。どこを直すか。どこを標準化するか。どこだけは自分たちの制御下に置くか。

プロコードへの回帰は、コードそのものへの回帰ではなく、制御を取り戻す動きなのだと思う。

エンジニアの仕事も変わる。

AIがコードを書くなら、エンジニアはいらなくなるのか。

そう単純にはならない。

むしろ、書かれたコードを読める人、設計の良し悪しを判断できる人、あとから困る場所を先に見つけられる人の価値は上がる。

AIは、たたき台を出す。だが、たたき台を製品にするには、判断がいる。削る力がいる。業務の順番を知っている必要がある。運用で破綻する箇所を見抜く必要がある。

つまり、エンジニアの仕事は「手を動かすこと」から、「構造を決めること」へ寄っていく。

そのとき、コードを読めないままでは厳しい。AIが出したものを評価できない。どこが危ないのか、どこが後で詰まるのか、判断できない。

コードを書く力は、単に実装するための力ではなくなる。AI時代には、AIが出したものを見極めるための力にもなる。

道具を選ぶ基準が変わる。

早く試すなら、ローコードは強い。小さく始めるなら、十分に役立つ。使いどころを間違えなければ、これほど便利な道具もない。

けれど、長く使うもの。業務の癖に深く入り込むもの。例外処理や既存データとの接続が多いもの。将来の変更が見えているもの。

そういう領域では、コードで残すほうが後から楽になる場面がある。

道具は、流行で選ぶものではない。あとから何度直すことになるかで選ぶものだ。

振り子は戻ってきた。ただし、同じ場所に戻ったわけではない。

いま戻ってきた先には、昔の孤独な開発者はいない。AIを横に置き、業務を見て、コードを読み、必要な場所だけ深く触る設計者がいる。

その判断ができる人にとって、コードはまた、いちばん自由な道具になりつつある。