はじめに
こんにちは、「ITを駆使して顧客企業の価値を創造すること」をミッションとしてエンタープライズ企業のDXを支援しているグロースエクスパートナーズ グループの事業子会社 株式会社GxP で代表取締役副社⻑をしている和田です。
この記事は、グロースエクスパートナーズ Advend Calendar 2024 の3日目の記事です。
今回は、システム開発が生成AI前提になっていく中で、５年後 当社におけるエンジニアの役割がどのように変わっていくのか仮説を考えてみました。
この１年でも、「生成AIの活用により実装工程の生産性が30%向上することを確認した」といった取り組み事例が、各社から発表されました。この先、私たちの役割はどのように変わっていくのでしょうか？
なお、去年のアドベントカレンダーでは、 次期リーダーが育つ場作りへの挑戦（1年間の次期マネージャー育成勉強会の試みの紹介） という記事を書きました。この勉強会は、今年は第３期を開催しています！
生成AIのローコードツール化
仕事でのプログラミングにおいても、まずは ChatGPTに聞いてみる、Visual Studio Code上からGitHub Copilotを使って開発する、というのは、一般的な習慣になったと感じます。
一方で、開発工程全体のうちで実装が占めるのは約1/31と言われており、実装の生産性だけを仮に2倍に向上しても、開発全体の生産性は15%程度 向上するのみとも言えます。
しかし、この先では、生成AIは2-3割の生産性向上ではなく、質的な変化を起こしていくと、誰しもが感じているのではないでしょうか。
たとえば、GitHub Copilot Workspace は、Issueの内容に従って、（コード断片ではなく）一連の実装が生成AIによりなされるツールです。
bolt.newでは、プロンプトで仕様を定義すると、それを実現するアプリケーション全体が自動生成され、「もう少しボタンを大きくして」などとプロンプトでお願いすると、すぐに修正してくれます。
このデモを見て私が最初に思い浮かべたのは、Salesforceを活用した開発に携わったときのことです。Salesforceでは（標準の機能範囲内では）管理画面UIからポチポチと設定することで、簡単に画面を作ることができます。そのため、お客さんと打ち合わせしながら、その場で画面を作ってデモをしてフィードバックをもらうことができます。従来の、決めた仕様を持ち帰って開発してから１週間後？１か月後？に顧客に見せるスクラッチ開発とは、開発プロセスが大きく変わることを感じました。
ローコードツール/ノーコードツールは、ツールのレールに乗って標準機能の範囲内で使う限りは、短期・低コスト・簡単にアプリケーションを開発することができます。一方で、ツールの仕様の制約から逃れることはできず自由度が低いものです。生成AIは、この先、この制約のない、自由度の高いローコードツールのようになっていくと想像します。
今までスプリントプランニングでスプリントバックログを選び、それを２週間後のスプリントレビューでデモをする、という開発プロセスだったものが、プロダクトバックログリファインメント = 実装完了となると、開発プロセスは劇的に変わるでしょう。
有名なフルサイクルエンジニアの図に当てはめると、Designの一部～Deployは生成AIとCICD pipelineによって瞬時に自動でなされるようになり、エンジニアの仕事は、ソフトウェアが現場で価値を発揮するように運用・サポートし、ユーザからフィードバックを得て新たな要件を設計することに集中していくと考えられます。
また、「保守性」という概念も大きく変わると思います。ローコードツールが生成するソースコードは誰もレビューしないように、５年後には生成AIが生成するソースコードも人間がレビューしたり修正しなくなるのではないでしょうか。定義した仕様が実現されていれば中身はブラックボックスでよく、ソフトウェアはより宣言的で使い捨てになり、極論、プロンプトで指示を出すたびに、中身は別のプログラミング言語で一から作り変えられても、気がつかなくなるかもしれません。
その開発プロセスを、自由度の高いマネージドなローコードツールのようなプラットフォーム （仮称）"AI-Driven BizDevOps Platform" のような仕組みがサポートするようになると想像します。
AI-Driven BizDevOps Platform による役割の変化
それでは、５年後にAI-Driven BizDevOps Platform の世界観が実現されていくとすると、私たちの仕事はどのように変わっていくでしょうか？
従来、顧客側にいわゆるビジネスサイドやプロダクトマネジメントや、または情報システム部門のような仕様調整役がいて、開発チームが開発を担ってるケースが多かったと考えます。
今後、この「開発」がほぼ生成AIによってなされるようになるとすると、私たちの仕事は、顧客のビジネス・業務とITとを翻訳するところが一層 重要になる（そこでしか価値を発揮できなくなる）と考えます。
顧客と一緒になって（顧客の内製チームの一員となって）顧客のビジネス・業務をITに落とし込み、それを AI-Driven BizDevOps Platform を使って瞬時に実現し、ソフトウェアが現場で価値を発揮するようにサポートすることが役割になると考えます。
そのときエンジニアの役割は？
AI-Driven BizDevOps Platformの世界観が実現された場合のエンジニアの役割について、書籍『チームトポロジー』で紹介されている「4つの基本的なチームタイプ」に紐づけて考えてみました。
- 顧客専用チーム（Stream-aligned Team）: 85%
- エンジニアの85%は、顧客専用チーム（Stream-aligned Team）として、顧客と対話し、Platformを使って瞬時に実現、ソフトウェアが現場で価値を発揮するまでを泥くさく伴走する役割を担うと考えます
- サービスデザイン・プロダクトマネジメント・カスタマーサクセスの役割の比重が増えるでしょう
- ソフトウェア開発がより宣言的・使い捨てになる中で、クラウド上でRestAPIやWebアプリケーションを効率よく開発するスキルは陳腐化して、要件定義・アーキテクチャ設計・品質保証・データ活用などのスキルがより重要になると考えられます
- Platform Team: 5%
- 5%は、顧客専用チームが利用する AI-Driven BizDevOps Platformを構築・提供する役割を担うと考えます
- Platform Engineeringやセキュリティなどの知見と、どんどん変化・進化していく生成AIをどう組み合わせてどう使うとよいかを研究して、Platformとして提供する役割になるでしょう
- Enabling Team: 5%
- 5%は、顧客専用チームや新規参画者が、AI-Driven BizDevOps Platformを使いこなせるように支援する役割を担うと考えます
- Complicated Subsystem Team: 5%
- 5%は、生成AIでは実現できない専門性の高い技術領域を担当する役割を担うと考えます
- 各種AIモデル自体の開発、顧客の現場でのフィジカルとデジタルの境界（センシング・機器通信など）、組み込み開発、パフォーマンスチューニングなどが主な活躍フィールドになるかもしれません
おわりに
この記事の内容は、あくまでも現時点の「仮説」です。５年後の開発は、現時点の私が想像もしない姿に変わっていて、笑い話になっているかもしれません。
この記事の下書きを社内で見てもらったところ、下記のようなコメントももらいました。
- AIが作ったコードをレビューしない時代になったとき、脆弱性の混入とかに対してはどういう手段が取られるんですかね。セキュリティスキャンが発展していくんでしょうかね
- 実装はいいんだけど、結局、問題なのはデータの取り回し、UXとしての継続性、リグレッションテストなんだよなぁ。あとは生成AIの計算量がどこまで上がるか
いずれにせよ、顧客の事業・業務により直接的にインパクトを及ぼせるようになると考えるとわくわくもします。また、このように当社の仕事が変わっていくことを想像して、顧客への価値提供の方法（当社自身のビジネスモデル）、開発プロセスやエンジニアの役割定義の変革、社内のトレーニングプログラムの整備も進めていきたいと考えています。
５年後とは言わず、１年後にもどうなっているのか楽しみにしたいと思います！
-
ソフトウェア開発分析データ集2022 P.167 「A3.3.8 工程別工数：新規開発」では、新規開発において、基本設計～総合テストのうち製作工程の実績工数（中央値）は31.6%を占めるとされています。 ↩