今回の未来予想図はあくまでも私個人の想像です。生成AIの登場により私がふわふわと思っていたことを言語化してみただけの内容となります。なので、いろいろな意見があるかと思いますが、こんな未来を創造する人がいるんだくらいの感じで読んでもらえればと思います。
また、生成AIの未来についてがテーマなので、本記事の作成には生成AIによるサポートを受けています。
はじめに
ソフトウェア開発は日々進化し続ける技術の中心にあり、私たちの生活やビジネスに不可欠な要素となっています。特に近年、ChatGPTをはじめとする生成AIの登場により世の中は大きな変革を迎えようとしています。生成AIは自然言語処理や画像生成、データ分析など、幅広い分野で利用され始めています。生成AIの登場により従来の手法では実現が難しいタスクの自動化/効率化だけでなく、新たな価値の創出も可能となりました。また新たなモデルの研究開発により、生成AIの精度や生成される内容も高度化し続けています。
IT分野でも生成AIは大いに活用されており、コードの自動生成、バグの予測と修正、ユーザーインターフェースの設計支援などを行うソリューションが開発されています。代表的な生成AIソリューションとしてGitHub Copilotが挙げられます。下記リンクの動画は5月に開催された「Java on Azure Day 2024」の収録動画です。56分からの「GitHub Copilot × Visual Studio Code で始めるJavaアプリ開発」ではAPI開発のデモを行っており、要件定義から製造、テストまでをGitHub Copilotの力を借りて実施しています。
デモ動画のように生成AIを利用することで開発者の作業効率は飛躍的に向上し、より創造的で価値の高い作業に集中できるようなることが期待されます。数年後には生成AIを利用した開発スタイルが一般化し、開発プロセスそのものが大きく変わると予想されます。
ソフトウェア開発ライフサイクル
ソフトウェア開発の未来像を示す前に、まずはソフトウェア開発ライフサイクル (SDLC: Software Development Life Cycle/Systems Development Life Cycle) について考えます。SDLCはソフトウェアの企画から破棄までの全工程を体系的にまとめたものです。主に「企画/要件定義」「開発」「運用/保守」「破棄」の4つのフェーズで構成されます。
SDLCにはウォーターフォールモデル、アジャイルモデル、スパイラルモデルなど複数のモデルが存在します。各モデルは異なるアプローチを取りますが、基本的な流れに大きな違いはないと私は考えます。下図はウォーターフォールモデル、アジャイルモデルの比較となります。
ウォーターフォールモデルは各フェーズを順次進める線形的なアプローチを取りますが、保守フェーズでの機能改修や新規機能の追加開発が行われます。そのため、半ば強引かもしれませんがウォーターフォールモデルとアジャイルモデルでは開発対象の規模や期間などが異なるだけで基本的なフローに差はありません。（開発後、運用のみで機能追加や改修を一切行わないという場合はその限りではありませんが。）
生成AIの登場により、ソフトウェア開発の方法や効率が劇的に変わることは確実ですが、SDLC自体の基本的なフレームワークが大きく変わることはないと考えています。AIがコードの自動生成やテストの自動化を手助けすることで、各フェーズの期間が短縮/効率化されますが、「企画/要件定義」「開発」「運用/保守」そして最終的な「破棄」といった基本プロセスは変わらず必要であるためです。
本記事ではこのソフトウェア開発ライフサイクルの大枠は変化しないものとして未来のソフトウェア開発像を想像しました。
未来のソフトウェア開発像
全体像
下図が想像する未来のソフトウェア開発像となります。
「企画」「開発」「運用」の3フェーズごとに異なるAIが開発をサポートします。
各フェーズの詳細については以降の「企画フェーズ」「開発フェーズ」「運用フェーズ」にて解説します。
一気通貫で一つのAIがサポートしない理由は人の判断を挟む必要があるためです。総務省が公開しているAI利用活用ガイドラインのAI利活用原則では人間の判断の介在について記載しています。AIの出力内容について、必要かつ可能な場合にはその出力をどのように利用するのかは人が判断すべきという内容です。AIの暴走を防ぐためにも「人間の判断の介在」については今後も変わらない原則であると考えるためこのような構成としました。
企画フェーズ
企画フェーズでは企画AIが要件定義書を自然言語で出力します。
企画AIの役割は以下のとおりです。
- 外部（インターネットかそれに準ずるもの）から最新動向などを入力として学習する
- 人からの要望を入力として受け付け、要件定義書を出力する
- 運用AIが出力した改善提案レポートを入力として受け付け、改善に関する要件定義書を出力する
未来ではインターネットに変わる情報収集源が生まれる可能性があるため、インターネット等と記載しています。生成AIではこれら外部情報と人からの要望や改善レポートを掛け合わせることでシステムとして開発すべきものを要件定義書として出力します。
AIが出力した要件定義書は人が内容を確認します。確認した内容に不備や別の要望があれば、出力した要件定義書と追加要望を入力し要件定義書を再作成します。このサイクルを回すことで要件定義書を完成させ、次に解説する開発AIの入力とします。
開発フェーズ
開発フェーズでは要件定義書を元にソフトウェアを製造/テスト/実環境へのデプロイを実行します。
開発AIの役割は以下のとおりです。
- 要件定義書を入力としてプログラムを生成し、プログラムの仕様書を出力する
- プログラムに対してテストを実行しその結果をレポートとして出力する
- UAT環境にアプリケーションをデプロイする
- プログラムの改善要望を入力とし、UAT環境にデプロイされたプログラムを改修しプログラム仕様書を出力する
- 人による承認後、本番環境にアプリケーションをデプロイする
- 運用AIが出力したバグ改善仕様書入力とし、機能改善したプログラムや仕様書を出力する
開発AIでも生成したプログラムに対して人による確認を行い、改修要望があればプロンプトで改修要望を入力として与えます。このサイクルを繰り返すことでソフトウェアを開発します。
プログラム生成は現在の生成AIのような高級言語のコード生成ではなくアセンブリ言語のように機械が読み取れる形式(機械語)になると想像しています。また、プログラム生成で機械語を生成することからテストにおいては、現在の単体テストのようなものはなくなります。システムテストのように要件定義書に対するテストを実行し、その結果をレポートとして出力すると想像します。しかし、それだけでは本当に期待したプログラムが開発できているかわかりません。そのため、UAT環境を利用して人の手と目による動作確認を行います。動作確認で不満点があれば開発AIに対してプロンプトで改善要望を入力します。開発AIはすでに生成したプログラムに対して改善要望を取り込んだプログラムを再生成し、テストを実行します。このサイクルを繰り返すことでソフトウェアを開発します。そして期待通りのソフトウェアであることが確認できた後、人の承認を得て本番環境にデプロイします。
現在、コードの自動生成する場合はデグレードなどが気になるため、コードレベルでの差分確認やデグレードテストを実施します。生成AIを利用したプログラム生成でもデグレードはとても重要な観点となります。しかし、私の考えでは開発AIは過去に生成したプログラムやテストレポート結果を記憶するため、デグレードの観点を考慮したプログラム生成やテスト実行をするようになるのではと想像しています。
運用フェーズ
運用フェーズでは環境で動作するソフトウェアの状態監視/運用作業を担当します。
運用AIの役割は以下のとおりです。
- ソフトウェアの状態監視/障害発生時の自動リカバリ/スケーリング等の運用制御
- 定期的なデータのバックアップ/障害時のデータ復旧
- 運用レポート(アクセス数/障害発生数/各種リソース利用状況等)の定期的な出力
- 運用状況から次のアクションに向けた改善提案レポートの出力
運用AIの役割については現在の運用と大きく差がないように思えます。実際に「ソフトウェアの状態監視/障害発生時の自動リカバリ/スケーリング等の運用制御」について既に実現している部分もあります。ただし、現在よりも高度な判断を下せるように進化するため障害発生時にも人による対処はなくなり、すべて運用AIが対処します。プログラムのバグに起因するトラブルが発生した場合はバグ改善レポートを出力します。このバグ改善レポートを開発AIへの入力としプログラムを再生成させることでバグを取り除きます。
現在ではログやメトリクスなどの情報はPrometheusやDataDogなどに集約し、監視ソリューションを利用することで一定の条件に達した場合のアラート発報や自動スケーリングなどを行います。私の未来像では運用AIが直接ログやメトリクスを監視します。そのため、ログ収集基盤といったソフトウェアは不要になります。また定期的にDBからデータをバックアップを実行することで、障害発生時には自動でデータ復旧を行います。既存のシステムを刷新した場合、システムの移行が必要となります。その場合はこの機能を利用してデータ移行を実現します。
最も特徴的な異なる点は「改善提案レポートの出力」であると考えています。日々の運用状況から現在稼働するシステムをどのように改善すべきかをレポートととして出力します。この改善レポートを企画AIの入力とすることでシステムの改善を自動化します。
未来像について
本記事の未来像ですが約30年後(2050年頃)に実現するのではと想像しています。2050年頃と想像した背景には2045年にシンギュラリティ（技術的特異点）に到達すると考えられているためです。しかし技術の進歩スピードは人の想像を超えることが多々あります。そのため、30年後ではなく10年後や20年後にはこのような世界が訪れるかもしれません。もしくは私の想像が外れ、30年後も今と同じようなスタイルで開発している可能性もあります。未来がどうなるかは「神のみぞ知る」ですが、どのような結果になろうともAIやそれに関する技術がより発展していくことは間違いありません。
現時点ではシステム開発における工程ごとに生成AIを利用し、工程ごとの出力成果物を人が確認します。そのため、生成AIを利用した開発でもソフトウェア開発プロセスが大きく変わることはありません。しかし私の考える未来では、要件定義書から設計・プログラム生成・テストまでを一気通貫で実施します。そのため、設計や実装テストといった工程が不要となります。複数の工程を一気通貫で実施するためには、抽象的なドキュメントから機能仕様の出力や要件に合致したアーキテクチャの選択といった高度な推論・導出能力や出力精度が求められます。未来において生成AIはより高度化・高精度化すると考えられます。2045年にそのようなAIが誕生した場合、私が考える未来像の実現性が高まると考えています。
私の考える未来像では2～3人いれば、大規模なシステムでも数時間～数日で開発できると考えています。また、開発AIが生成するのは機械語でありブラックボックス化されることから、開発者がエンジニアである必要はありません。まさに今は流行っている非エンジニア向けのローコードプラットフォームの未来系といったところでしょうか。そのため、未来ではソフトウェアエンジニアという職種はなくなるか、研究者などごく一部の人に限られる領域の職種になるのではと考えています。エンジニアにとって面白くない世界だと思います。
私が現役である間にソフトウェアエンジニアの仕事がなくなることはないと予想（期待）していますが、予想が想像よりも早い段階で的中した場合は身の振り方を考え直す必要があるかもしれません。