生成AIによるソフトウェア上流作業へのアプローチ
ソフトウェア開発への生成AIの3つのアプローチのうち、最上流への適用について考えます。
はじめに
ソフトウェア開発への生成AIの適用領域は次の3つです:
仕様管理
コーディング
デバッグ
このうちコーディングについては相当の進歩がみられます。まったく新規にコーディングするのはいまでも難しいかもしれません。一定のライブラリに基づいてコーディングする場合には、ライブラリの選択から処理フロー、フローの各ステップ毎にコーディングというように分解して順番に書けば、相当効率よくコーディングは可能になっています。
ビジネスにおいてオープンソースソフトウェアのライブラリを利用できるような場面では有用性が増しています。
デバッグはまだまだ難しいです。人間が膨大な技術的負債を組み込んだ問題ソフトウェアのデバッグは生成AIでは難しいです。このような場合、人間の勝利というべきなのか、そもそもそんなソフトウェアを生み出した人間の敗北と考えるべきなのかは難しいところです。
最上流工程
顧客が課題
実は炎上プロジェクトの多くでは、仕様策定における顧客側に問題がある場合が少なくないです。結局、仕様を決定できるのは顧客だけですし、前提となる条件がかわれば仕様は変えなければなりません。長期的なプロジェクトでは当初の仕様が環境変化、法令変化、技術変化で変更せざるを得なくなることは少なくありません。
このような場合、ソフトウェア開発工程の重要な部分である仕様決定に関わる顧客の振る舞いがソフトウェア開発工程に大きな影響を与えます。
なぜ顧客は合理的に振る舞えないのか
顧客が合理的に振る舞えないことによるソフトウェア開発への悪影響は少なくありません。
大規模なソフトウェアにおいてはそもそも顧客の要求は矛盾しています。コストをさげ、使いやすく、セキュリティを上げ、性能を上げる、などです。これらの要求は相互に逆の方向に働いています。
巨大なSIerの仕事の大きな部分はそもそも矛盾した顧客要求を実現可能な妥協点に近づけることです。
調達部門はコストをさげ納期を短くすることを要求します。情報システム部門は最新のセキュリティ脅威に対応するとともに性能条件を満たすことを要求します。経理部門は最新の税務法令に対応することを要求します。
これらは相互に矛盾をはらんでおり、妥協することが必要です。残念ながら、それぞれの部門にはそれぞれの部門のメンツがあり、社内でこれを調整することは困難です。このため調整は第三者に委ねられることになります。
生成AIによる仕様管理
言語的能力が高い生成AIは仕様の調整とトラッキングに適性が高いです。受注側のシニア・エンジニアに仕様管理を丸投げするのではなく、発注側で適正な仕様管理をし、実現可能な妥協点を時系列で管理し、仕様変更の影響を見積もったり判断したりすることは有益なことです。
生成AIが進化すればいずれにせよ受注側でも生成AIで仕様管理することになりますが、どうせやるなら発注側でやるのが明快で効率がいいです。
むすび
生成AIはコード生成、デバッグ、仕様管理の順にソフトウェア開発のプロセスに適用されていきます。
将来的には仕様管理への適用がソフトウェア開発の生産性向上に最も寄与すると予想します。
この記事が気に入ったらサポートをしてみませんか?