2023年上半期は、私の周辺でも生成AIの話題でもちきりでした。遅くなりましたが、このテーマについて私の現時点の見解を文章化します。
生成AIはローコード／ノーコードエンジニアにどのような影響を与えるのか
生成AIが、業務アプリケーション開発についての設計知識を十分に蓄積した状態 = 理想的な状態、にあると仮定します。（このブログを書いている2023年6月時点よりも、さらに賢くなった状態を想定しています。）
ある目的を実現する業務アプリケーションを構築しようとしているエンジニアは、AIと対話を重ねることで、どういう機能やデータが必要かを早い段階で整理できることが容易になると期待できます。いわゆる要件洗い出しと分析、そして定義といった上流工程の分野を支援するという活用です。
これまでは既存システムまたは類似システムを調査しつつ、専門書を読んだり、現場担当者に尋ねるなどを重ねて、仕様を整理していました。この作業自体がなくなるわけではありませんが、より効率的に進められるようになるはずです。つまり、ある業務（分野、ドメイン）について学ぶための学習コストが短縮できるという効果を期待できます。
加えて、既存システムのソースコードやドキュメントを付加情報としてAIに与えることで、仕様漏れなどのチェックも強化できそうです。
ただ、これらはエンジニアの代わりに生成AIが業務設計を担う、ということではありません。よりわかりやすくいうと、全くの素人がいきなり素晴らしいシステムを手にいれることはできません。そうではなく、もともとシステム開発に素養をもつエンジニアが、自身の生産性をさらに高めるためにAIをツールとして使う、ということです。
生成AIがプログラムを開発できる、という話題もありますが、AIに対して適切な問い合わせを投げかけるということ自体、ある程度の素養が求められます。さらに生成されたプログラムを実際のアプリケーションに取り込むためには、そのプログラムを理解する必要もあります。この理解には、適切な修正を含めるという文脈もあるため、決して生成AIにすべて丸投げするわけにはいきません。
もしかすると生成AIがエンジニアの仕事を奪うというイメージをお持ちの方もいるかもしれません。しかし実際は、基本を習得したレベルのエンジニアが、さらに自身の生産性を高めるためのツールが手に入ったと考えるのが妥当でしょう。一方、基本スキルに満たないエンジニアは生成AIとの対話そのものが難しく、結果としてうまく活用できないということになりかねません。
補足すると「（生成AIとの）対話」という言葉は、対人間のコミュニケーションスキルとは違います。複雑なものを適切な粒度に分割し、論理的に整理し、それを再度組み上げるという、多くのエンジニアが日々行なっていることを（生成AIに対して）「言語化」するというスキルを指します。
生成AIは、ローコード開発にとって脅威なのか、あるいは味方なのか
私が漠然とイメージしているシステム像について、これをあいまいな表現として口頭で伝えるだけで、その要求を適切に解釈、さらに足りないところを補完し、望ましい仕様にまとめてもらえることができるでしょうか。これまでは無茶な話と一蹴されていたかもしれませんが、生成AIと対話を重ねることで、それが実現できる可能性がでてきました。
さてローコード開発は、これまで上流工程、特に要件の定義については対象外としていました。（私の知らないだけで対象としていた製品もあるかもしれません。ただ、その場合もおそらく自由文章で記述された要件定義をデータとして管理しているということであり、要件定義という作業自体は人間が主体的に行うことが前提となっているはずです。）
つまり要件定義は人間の仕事でした。システムを必要とする現場が、それをコードとして表現できるスキルをもったエンジニアとの対話を通して、要求を要件として具体化していく、という工程があります。その成果がローコード開発の「入口」になっていました。
この分野に生成AIが加わることで、要件定義の工程も非エンジニアだけで実現できるようになることが期待できます。誤解ないように説明すると、生成AIをツールとして活用し、現場の要件定義能力を高めるということです。生成AIがあるべき要件を提案することもあるでしょう。しかし生成AIが要件を定義するのではありません。それは現時点では不可能という前提付きではなく、そもそも不可能、と考えています。（私が何を欲しているか、をAIが察知する可能性は日々、高まっています。しかしそれを受け入れるかどうかは別の問題です。AIの提案を何もかも受け入れてしまうだけの社会は、文明の衰退につながってしまうと危惧します。）
生成AIのメリットの一つはコストです。要件定義を整理する上流工程のエンジニアの単価に比べると安価にみえます。しかし仮にコストが変わらないとなったとしても、もう一つのメリットがあります。それは常に隣にいるパートナーとして存在していることです。ちょっとした思いつきをその場ですぐに相談できる関係性、は楽でしょうね。そしてなんといっても、何度でもやり直すことができます。対人間だと感情的に抵抗されるような局面でも、生成AIは文句ひとつなしで、リセットして再検討するのです。これはストレスがなくなります。
このようにして整理された要件を「入力」として、ローコード開発の工程に流すことができます。さらに、この要件が、あるローコード開発ツールの特性をうまく加味したものになっていれば、さらに開発生産性を高めることに直結するでしょう。（ローコード開発といっても、そのツールが想定していないカスタマイズ開発のボリュームが増えれば生産性は下がってしまうことはよく知られた事実です。）
つまり生成AIはローコード開発にとってかわるものではなく、上流工程の段階から活用することで、さらにシステム開発の生産性を高めることができる「味方」になる、と考えています。
加えて、できあがったシステムへのテストデータの自動生成や、回帰テストシナリオ作成にも、生成AIは活用できると思います。生成AIはシステム開発全体をとおして、エンジニアを代替するのではなく、エンジニアを支援する優秀なコーチ役として機能するというのが私のイメージです。
...では上流工程で活躍していたエンジニアは、生成AIによって職を奪われる？ いえ、私の文脈からは、より少ないエンジニア + 生成AIという混成チームとしてお客様に貢献できるようになるはずです。私自身、一貫しているのは、大量のエンジニアを投入した大規模システム開発ということ自体がなくなり、少人数のエンジニアでも大規模システム開発できるようになるというストーリーを支持していることです。これまで、その実現のためにローコード開発が必要と主張してきましたが、さらに生成AIの活用も、そのストーリーをより補強するための有効な手立てになると考えています。
最後に、デメリットはないのでしょうか。注意点として、生成AIの出力を受け入れた責任は自分にある、ということを自覚する必要があります。外注に出したわけではないので、こんなはずではなかったと生成AIを訴えることはできません。そういう視点からも、生成AIは自分自身を高めるコーチ役として側においた上で、現場が自分たちで内製開発を推進していく、というのが私の解釈です。
