2024年を迎えました。2000年から早、四半世紀が経過し、いよいよ AI がプログラミングを代行するのか、というテーマが熱く語られる時代の到来です。私の立場からは期待半分、そして Wagby 自体が不要になるのか？という不安もまた半分というところです。
ということで年明け初のブログは生成AIの登場による、ローコード開発ツール不要論について現時点の見解をまとめてみました。
2023年12月「ローコード開発フォーラム2023」の様子
さった12月8日に、私も幹事を勤めるローコード開発コミュニティの年一回のフォーラムで、まさにタイムリーな企画が実施されました。
ローコード開発 vs AI駆動開発 ライブ実装イベント
https://www.kokuchpro.com/event/67b6eeeb65a8f9cadd81966f0cef0491/
いつもなら私自身もプレイヤーとして参戦するところですが、今回は聴講者となって SCSK 様による GitHub Copilot の実演を鑑賞させていただきました。ありがとうございました。
プロンプトへの入力によって、まずテーブル定義 (create ddl) を生成、これをもとに Java / Spring Boot ベースの Web アプリのコードが生成される様子をみせていただきました。テストデータもそれっぽいものが自動で用意されるところも楽しめました。
ということで、生成AIが「ちゃんと動作する」ソースコードを出せるのではないか、という期待は現実のものとなっていることを改めて実感できました。
しかし一方で、次のような感想を持ちました。
- 教科書的なソースコードは確かに生成される。さて複雑な業務ロジックや、UI に関するコード生成を行う場合、プロンプトをどのように書く必要があるのか。
- 生成AIのコード生成はそれなりに時間も手間もかかる。プログラミング不要といっても開発工数がゼロになるわけではない。
- 生成されたコードの妥当性を検証し、組み込むという作業はまだ人間が介在する必要がある。
エンジニアリングに求められるスキルが大きく変わる
一部のエンジニアは、要件をヒアリングするとすぐに手を動かしてコードを書きながら頭の中を整理していきます。最初から正しいコードが書けるわけではなく、書いては修正を繰り返しつつイメージを固めていくタイプです。私もその一人です。
しかし生成AIベースになると、この手法は通用しないでしょう。要件を「日本語で」「丁寧に」「過不足なく説明できる」ことが求められます。生成されたコードをみて説明不足に気づき、さらに説明を追加して…という開発スタイルに変わります。これは案外、難しいだろうと思います。これまでもあった「上流工程をちゃんとやりましょう」という話がいよいよ本質になってきます。
プログラミングはできなくとも、仕様（要件）を理解し、それを生成AIに正しく伝えるスキルが重要です。用語の不統一や、型のあいまいさはもってのほか。仕様の矛盾も認められません。「プログラミング言語」ではなく「日本語」を使いつつも、正確性や厳密性が求められます。立法…に近いスキルかもしれません。
ローコード開発ツール不要論は妥当か
データモデルの情報（データの型、構造、関係性）から土台となるアプリケーションをつくること自体はローコード開発ツール、例えば私たちの Wagby、でも十分に実現できます。同じことを生成AIでもできます。生成AIのメリットは、2024年ならこう書くよね、というコードが出ることです。残念ながらWagbyは互換性重視の観点から、古いコードスタイルです。ただ長期間保守することを考えると、常に同じコードが生成されるのはメリットでもあります。毎回少しずつ生成されるコードが変わる開発環境で、一つのアプリケーションを長期間保守できるのかは、正直なところ、わかりません。プロンプト次第で、コードのスタイルを指示できるかもしれませんが、それはそれで開発者に負担をかけそうです。
もう一つはコストの問題があります。少額とはいえ、生成AIによるコード生成は従量課金です。Wagbyは定額で使えるので、同じようなアプリケーションを開発するなら、定額で済むWagbyをすぐに捨てる理由は、なさそうです。
生成AIとローコード開発の共存
ということで私としては、Wagbyでアプリケーションのベースを起こしつつ、生成AIのパワーを組み込むことで、さらに開発現場を楽にするというストーリーを追いたいところです。少し考えただけでも次のようなテーマが思いつきます。
- Wagbyの設計情報を生成AIに読み込ませ、日本語のドキュメントを用意してもらう。概要の作成や、機能説明などに使えるのではないか。
- マニュアルの自動生成にも使えるかもしれない。
- テストデータの自動生成もよいが、結合テストや、総合テストシナリオの生成もできると、なおよい。
- 仕様の一貫性のなさ、や、仕様不備、に対するアドバイスをしてくれるかもしれない。
- 本丸は「業務処理コードの生成」だが、ここは高望みせず、できる範囲を見定めたい。
気を付けるべきは、生成AIの進化によって、あいまいな日本語から精緻なアプリケーションが生成されるわけではない、ということです。むしろエンジニアに求められるのは論理的一貫性を保ったアプリケーション仕様の策定と維持に関するスキルでしょう。少なくとも、Excelに自由文章で設計書をかいている現場では、そのスキルの向上は難しいと思います。
開発現場にはわかる話ですが、規模の大小を問わず、設計書の維持管理は大変な労力です。ということでWagbyのようなローコード開発ツールの価値は従来のコード生成から、設計書の作成支援にシフトするのではないか、と考えています。
おまけ
今回のタイトルは、はてなブログの新機能「AIタイトルアシスト」につけてもらいました。そのうち文章の添削もしてもらえるようになるのだろうと、これまた期待と不安が...
