> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/ja/2026/w16-nocode-rapid-iteration-and-new-engineering-constraints.md).

# W16-nocode、速い反復と新たなエンジニアリング上の制約

先週、HRが金融サービス部門の10周年Vlog企画を公開した。プロジェクト全体を、インターンの罗华煜がnocodeで作ったものだ。先週コードを見て、面白い発見がいくつかあった。

第一に、この種のプロジェクトでno-codeが生産性を数倍、あるいは数十倍にしても驚かない。驚いたのは、作業全体で268ものバージョンが生成されたことだ。AIがソフトウェアの納品を速め続け、将来の本番プロジェクトが今の数倍の速さになることは想像できる。その後に何が起こるかを、このプロジェクトはよく示している。

数年前に同じような抽選企画を作るなら、通常はフロントエンド1人、バックエンド1人で、半月余りを与えられた。1週間以上かけてまずMVPを作り、依頼者が見て意見を出す。開発側が直し、2日ほど後にまた見せても、まだ満足されず、もう一度修正する。最後は時間がなくなり、依頼者が「ひとまずこれで」と言うことが多かった。実際に依頼者が見られる版は3、4個ほどで、改善の道のりはすぐ終点に達した。

nocodeは、要件から実現までの距離を短くする。依頼者がフィードバックを得るのも、新しい考えが生まれるのも速くなる。同じ半月でも、200以上の版を進められる。以前なら起こりえなかった改善が、できるようになる。ここで重要なのは、生産性が上がっても、時間や資源が大きく減るとは限らず、むしろジェヴォンズのパラドックスに近づく可能性があることだ。実現の敷居が下がれば、発想も反復も増える。需要はほぼ無限に近づきうる。消えるのは必ずしも仕事量ではなく、これまでできなかった改善が解放されるのだ。

第二に、コードを読んで、人は普段こういうコードを自発的にはあまり書かないだろうと強く感じた。一通りそろったWebサービスなのに独立したサーバーがなく、フロントエンドがデータベースを直接呼ぶ。ストアドプロシージャは16個ある。典型的なFrontend-only + BaaS構成だ。React + ViteでSPAを作り、独立したバックエンドを置かず、すべてのデータ操作はブラウザーからsupabase-jsで美団の社内配備版Supabaseを直接呼ぶ。下層のデータベースはPostgreSQLである。

業務ロジックは二つに分かれている。簡単な検証と頻度制限はフロントエンドのworksApi.jsに置き、投票、いいね、削除など、並行実行の安全性やデータ整合性に関わる核はPostgreSQLの保存関数にして、supabase.rpc()で起動する。権限制御は主にデータベース層のRLSに頼る。この方法は開発が速く、独立サーバーの保守費も省ける。一方、問題も明確だ。業務ロジックがフロントエンドのJavaScriptとデータベースのPL/pgSQLに散らばり、保守性は今一つになる。管理者一覧のような機微な情報も、クライアントへハードコードせざるをえない。

このプロジェクトの価値は、nocodeならイベントページを速く作れる、と示したことだけではない。AI時代のソフトウェア納品の新たな常態を、具体的に見せている。版は増え、フィードバックは速まり、構造はまず最短の実現経路を選びやすくなる。チームには現実的な生産性向上の機会があると同時に、新しい技術的制約も生まれる。今後、本当に希少になるのは、機能を最初に書くことではなく、極めて速い反復の中でも、構造の境界、保守性、長期の発展余地を守れることかもしれない。