ジェネレーティブAIがソフトウェア配信を支援する方法

レイチェル・レイコック

約 2 か月前、私は Thoughtworks の CTO になりました。それ以前は、Thoughtworks でモダナイゼーション プラットフォームとクラウド サービスを率いていましたが、デジタル トランスフォーメーションの基盤は、システム内にすでに存在するソフトウェアをモダナイズすることです。経営陣は私にこう言いました。「君はもうすぐ Thoughtworks の CTO になる。頑張ってくれ。今後 10 年、20 年で最も破壊的なテクノロジーが君の前に現れるだろう。それに注意を払う必要がある」。私はこの業界に 20 年間携わっており、メタバース、ブロックチェーン、モバイル テクノロジーなど、いくつかのテクノロジーが誇大宣伝サイクルのピークに達するのを何度も見てきました。それらは本当に多くのことを変えます。

しかし、私にとって今回違うのは、AI が Thoughtworks のビジネス モデルにどれほど破壊的な影響を与えるかということです。当社はテクノロジーを通じてお客様の問題を解決します。Thoughtworks が優れている秘訣は、ソフトウェアの提供方法です。私たちが使用する原則、私たちが使用する方法、そして継続的デリバリーとマイクロサービスに関する書籍はすべて、ソフトウェア構築に対する私たちのアプローチから生まれたものです。したがって、テクノロジーが登場して「コードを書くだけで済むので、もう人間は必要ない」と言われたら、CTO である私は油断せず、顧客へのソフトウェアの提供方法やアドバイスに影響を与えるテクノロジー戦略を迅速に策定する必要があります。

ソフトウェアはコーディングがすべてではない

世界中のあらゆるコンサルティング会社、あらゆるソフトウェア開発会社は、互いに競争しているため、この分野を専門とする何百人もの人材を雇用しています。誰もがコーディング部分について話しているのがすぐに分かりました。しかし、私は、待ってください、何かがおかしいと思いました。ソフトウェアの提供は、コーディングだけに留まりません。

何年もの間、私は、人々がコードについて考えるとき、ソフトウェアの構築はコンピューターの前に座って IDE でコードを書くことだと考えており、それがすべてであるように思われる、と言ってきました。このため、Thoughtworks では長年にわたり、ペアプログラミングを含むエクストリーム プログラミング手法を採用してきました。長年にわたり、当社の顧客は「同じコードを書くのになぜ 2 人の開発者にお金を払わなければならないのか」と尋ねてきました。高いですよ。私たちは多くの説明をしなければなりませんでしたが、この作品にはデザインの要素があるため、それは実に大きな誤解でした。 2 人の頭脳が同時にコードを開発することで、提案された設計は最終的に、欠陥が少なくコストが低い、より高品質のコードを実現します。

技術の急速な変化によりソフトウェアの再構築が必要

しかし、本当の問題は、コーディングがすべての作業ではないということです。ソフトウェアは常に変化しています。先ほども申し上げたとおり、私はプラットフォームとクラウド サービスの近代化を担当していました。世界のソフトウェアのうち、クラウド上で実行されているのは 20% 以下だと思います。結局のところ、その多くは長い間存在しており、移行するのは簡単ではありません。ソフトウェアを単純に書き直すことはできないため、近代化には非常にコストがかかります。

結局のところ、コードを書くよりも読むことのほうがずっと多いのです。約 20 年前、大学を卒業して最初に就いた仕事は、システム アナリストと呼ばれていました。彼らはそれを卒業生と呼んでいますが、仕事の本質はバグや欠陥を修正することであり、それがコードベースを理解する方法だと考えられています。しかし、私が学んだのは、正しいコード記述方法や優れたコーディング スタイルよりも、間違ったコード記述方法や悪いコーディング スタイルの方がはるかに多いということです。これにより、保守が容易で、コードに制約されることなく将来もビジネスを成長させ続けることができるような優れたコードを書く方法に興味を持つようになりました。ソフトウェアを構築するには、どれだけ速く構築できるかということだけではなく、最初から正しく構築することが重要です。私たちは皆、「技術的負債」という言葉を聞いたことがあると思いますが、技術的負債が増えるほど、ソフトウェアを変更するのが難しくなります。

それで私たちは何をすべきでしょうか?私たちはそれを再建しました。組織内で再構築されたシステムはいくつありますか?それは多いですよね？そうでなければ、世界中で何千人もの技術コンサルタントや開発者がソフトウェアを絶えず再構築したり書き直したりすることはなかったでしょう。これは、元々の記述が不十分であったり、クラウドに移行できないテクノロジー スタックを使用して記述されていたりすることが原因である場合があります。しかし、ビジネスが変化し、新しい製品や新しいソフトウェアが必要になる場合もあります。テクノロジーは私たちの足元で常に変化しています。

私たちは建築分野から用語を借用してきました。私の兄は本物の建物を建てる本物の建築家です。建築において決定を下すとき、それを正しく行えば、何世紀にもわたってその建築物を維持できます。ソフトウェアはまったく異なり、常に変化する分野です。なぜなら、コードを絶えず再構築しており、成功はコードの状態、最初に書かれたときの品質、そして変化するビジネス環境によって決まるからです。

Thoughtworks をフォローしている人なら誰でも、私たちが 10 年以上にわたってテクノロジー レーダーをまとめてきたことをご存知でしょう。レーダーの比喩は、私たちが重点を置くべきテクノロジー、プラットフォーム、テクニック、ツールを体現しています。これは、社内組織化の目的で元 CTO が作成したもので、従業員数が増えるにつれてすべての変更を追跡することが困難になったため、彼女はすべての変更を把握できるように技術諮問委員会を立ち上げました。

6 か月ごとに新しいテクノロジー、新しいプラットフォーム、新しい手法が登場していることに気づくでしょう。実際、最後のテクノロジーレーダーは先週開始され、通常は約 1 か月後にリリースされます。現在、大規模な言語モデルと生成 AI に基づくツールが多数存在するため、それらを個別に評価する必要がありました。一つ一つ評価するのではなく、全体を総合して相対的に評価する必要もあります。それはすでにクレイジーな分野のようなものですが、私たちが扱っている複雑さは信じられないほどです。

ジェネレーティブAIが新たなコーディングパートナーに

コードを書くよりも読むことに戻り、ペアプログラミングと、なぜこれらの方法を使用するのかを考えてみましょう。

ジャン・バルティックです。彼女は最初のプログラマーの一人でした。ご存知ないかもしれませんが、プログラミングの歴史において、初期のプログラマーのほとんどは実は女性でした。彼女によると、常にペアでコーディングを行うのは、そうすることで互いのデザインをレビューし、批判し合い、より多くのアイデアを得ることができると分かったからだという。それが生成型 AI の最もエキサイティングな点の 1 つだと思います。なぜなら、生成型 AI ではそれができるからです。

ソフトウェア エンジニアリングの実践は非常に重要なので、コードを書くときはそれをパートナーとして考える必要があります。協力したり、コードレビューを行ったり、設計に時間を費やさずに、ただ書き直したり、バグを修正し続けたりすると、さらに問題が発生することになります。

私たちは大手顧客数社を調査し、当社と社内ソフトウェア開発者およびベンダーを比較しました。その結果、製品をより早くリリースできる一方で、欠陥、バグ、問題、作業の重複が多く発生していることがわかりました。

そのため、開発プロセスの早い段階でデザインのアイデアを慎重に検討する必要があります。最終的に、展開フェーズに到達したときに、問題がまったくないか、問題が少なく、継続的に展開できれば、コストが低くなるからです。開発サイクル全体を総合的に見る必要があります。コードを書くだけでは不十分だからです。私が言っているのは何も新しいことではありません。こうしたことは長い間存在しており、業界全体が常にソフトウェアを再構築しているだけです。

したがって、生成 AI がコードをより速く記述するのにどのように役立つかを考えるだけでは、非常に範囲が狭くなります。配信サイクル全体について考え、生成 AI をその配信サイクル全体にどのように組み込むことができるかを検討する必要があります。このようにして、実際に動作する高品質のソフトウェアが手に入ります。そうしないと、わずかな利益しか得られません。

ジェネレーティブAIはソフトウェアプロセスの改善に役立ちます

Github の調査によると、人々が実際に座ってコードを書く時間は、毎日の仕事の約 26 ～ 27% に過ぎないことがわかりました。したがって、ソフトウェアの開発はそれ以上のものであることがわかります。

生成 AI について私たちが学んだもう 1 つの興味深い点は、生成 AI によってソフトウェアの開発やコードの削除などの多くの反復タスクを高速化できるようになったにもかかわらず、そのメリットが実際に得られるのは中級エンジニア以上のレベルだけであるということです。結局のところ、それは Google ではないので、答えは得られません。これまでに行われたことのモデルを提供するだけです。上級エンジニアでない場合は、入手した情報が正しいか間違っているかを判断できず、開発プロセスが遅くなります。選択肢やアイデアが多すぎて、どれが正しいのかわかりません。

したがって、生成 AI をソフトウェアの構築にどのように適用するかを考えるとき、重要なのは開発者の作業を高速化することではなく、プロセス全体を改善することです。生成 AI はソフトウェア開発ライフサイクルにおいて多くの助けとなるため、多くの機会が生まれます。次に簡単に紹介させていただきます。

私たちが持っている大きな言語モデルは絶えず変化しており、現在何がうまくいっているのかはわかりません。簡単なパターンマッチングから始めましょう。 「計算をしてください」のような自然言語を入力でき、コードを生成でき、反復的なタスクを非常にうまく実行します。前にも言ったように、すでに経験のある人にとっては素晴らしい仲間です。

なぜなら、私はモダナイゼーションの分野で働いてきたのですが、モダナイゼーションにおける大きな問題の 1 つは、メインフレームに誰も真剣に取り組んでいないことです。メインフレーム システムを最新化しようとしたが、コストが高すぎるために諦めた人はどれくらいいるでしょうか?人々は通常、それを書き直すか、単にラッパーで囲むだけです。

そこで私たちはいくつかの実験を始めようとしています。生成 AI が自然言語をコードに変換し、コードを自然言語に変換できれば、この問題を解決できるかもしれないからです。昨夜、IBM がこれを実現できると主張するものをリリースしたと聞きましたが、これはまだ始まりに過ぎず、非常に興味深いことだと思っています。生成 AI は、スターウォーズのメタファーを使用してコードを解釈するなど、非常に奇妙なことも実行できるため、それを楽しむこともできます。

20 年前なら、あなたは Java エンジニアか C# エンジニアだったかもしれません。しかし、今は状況が違います。特に私たちの業界のコンサルタントとしては、Ruby や Python のさまざまな概念を学ぶ必要があり、IDE 内でコンテキストを提供できる必要があります。曖昧になった事柄を思い出すのに役立つ Copilot を使用します。生成 AI を使用する前は、Google にアクセスして自分で答えを検索する必要がありました。例外メッセージがある場合、ジュニア開発者はそれを Google に入力し、次に Stack Overflow で答えを探し、最後に最も人気のある回答を選択します。ここでの利点は、最も人気のある回答を選択した場合、それが単に良い回答である可能性もありますが、Copilot のようなツールを使用すると、コンテキスト付きの回答を取得できるため、ワークフローを高速化できることです。

ソフトウェアの配信を遅らせる要因の 1 つは、ウォーターフォール アプローチ、つまりフェーズ間の引き継ぎに関する不満です。ステージ間で物事を常に受け​​渡し、誰かが要件やアイデアを思いつき、それがコード化され、テストされ、デプロイされ、そして、ああ、問題が発生したので、すべてをロールバックしましょう、ということになります。しかし、問題は 2 年後に発生する可能性があります。初期のプログラマーは組織に 2 年しか在籍していないため、退職してしまうのです。したがって、あなたが初心者プログラマーで、この問題を見ると、何が起こっているのか、そしてそれをどのように修正するのかを理解するのに、3 倍から 4 倍の時間がかかるかもしれません。しかし、アイデア創出、ユーザーのニーズ、テスト、展開といったフィードバック ループをより早く作成できればできるほど、やり直しを減らして目標をより早く達成できるようになります。

したがって、ソフトウェア開発ライフサイクルのさまざまな部分と、それらの部分の一部で生成 AI が果たすことができるさまざまな役割、実行できること、使用できるツールについて考え始めることができます。これは、驚くべきことであり、恐ろしく、そして同時に刺激的なことのように聞こえます。

私たちは優れたソフトウェアとコードの構築と作成に重点を置いてきました。生成 AI を使用した場合でも、優れたメソッドとメソッド名が必要ですが、AI がドキュメントを生成してくれます。 2 週間離れてから戻ってきたときに、コード ベースに何が変わったかを想像してください。 AI に、過去 190 回のコミットにおけるコードベースのすべての変更の概要を尋ねると、AI が調査と発見に役立ちます。

ソフトウェアのアーキテクチャと設計における難しさの 1 つは、セキュリティの問題、アクセシビリティの問題、パフォーマンスの問題など、すべての機能横断的な問題を考慮することです。ジェネレーティブ AI は、経験豊富なソフトウェア アーキテクトであれば、考慮して注意を払うべき問題が約 10 個あることを教えてくれます。そのうち 8 つは現在の状況では無関係ですが、残りの 2 つは重要であることがわかります。しかし、経験豊富なソフトウェア アーキテクトでない場合、これらの 10 個の問題のそれぞれに対処するためにコードを変更すると、変更や使用が困難なソフトウェアになってしまいます。だからこそ、人々の専門知識は依然として非常に重要であるということを私は言及したのです。

実際、テクノロジーリーダーとしての私の懸念の 1 つは、従業員の専門知識をどのように育成するかということです。 AIが登場する前、誰かのコードを初めて読んだとき、一体何が起こっているのだろうと思ったものです。このコードを書いたとき、この人は何か狂った幻覚剤を飲んでいたのでしょうか?生成 AI を使用すると、このようなことが起こる可能性が低くなり、何を行ったかが通知されます。実装にはいくつかのオプションが提供されますが、それらのオプションについて判断を下す経験と専門知識がなければ、より悪いソフトウェアが作成される可能性が高くなります。これが私の予測の 1 つです。このテクノロジが、より優れたソフトウェアの作成にどのように役立つかを実際に確認する前に、まずはさらに多くの悪いソフトウェアが生成されることになります。

さまざまな AI テクノロジーとそれらがソフトウェア ライフサイクルに与える影響を評価し始めた当初、すべてが現代のソフトウェアの基本原則に帰着することがわかりました。現代のソフトウェアを実際に構築したことがある人なら誰でも、現代のソフトウェアはプロセスがすべてであることを知っています。システムから無駄を取り除き、開発チームとデリバリーチームをフロー状態にして、最高品質の製品をできるだけ早く顧客に提供できるようにすることが重要です。

Amazon の新 CEO アンディ・ジャシー氏は、ソフトウェア開発ライフサイクルに多くの無駄があることに気づき、エンジニアリング効率開発者エクスペリエンス グループを創設しました。生成 AI は、情報の検索などの無駄を削減するのに役立ちます。繰り返しになりますが、AI は認知上の摩擦を軽減するのにも役立ちます。開発者のエクスペリエンスの摩擦を軽減しますか?多分。運用モデルにおける摩擦を軽減できますか?おそらくそうではないでしょう。つまり、生成 AI の実現にはまだまだ長い道のりが残っています。

しかし、生成 AI はプロセスの多くの障壁を取り除くことができるため、将来のエンジニアを優秀なエンジニアに育てる方法を考えるなど、ソフトウェア開発ライフサイクル全体に目を向ける必要があります。なぜなら、ほとんどの人間が困難なことから学ぶことで成長するというのは、人間としての残念な真実の一つだからです。私たちの両親は厳しい教訓を学び、それから私たちにそれを教えようとしました。しかし、私はあなたの言うことを聞かず、自分自身でこの厳しい教訓を学びたかったのです。困難なことから学ぶというのは、ほとんど人間の本性です。では、難しいことを学ぶ機会がない状態で、どうすれば優秀なエンジニアを育成できるのでしょうか?

ですから、それは私たちが対処しなければならない問題になるでしょう。先ほど申し上げたように、生成型 AI が解決できる問題はたくさんありますが、解決できない問題もいくつかあります。リーダーである私たちは、それらの問題に重点を置き、無駄を省いて人々が効率的かつ効果的に役割を果たせるように、リーン原則をどのように活用するかについて考える必要があります。

生成 AI は開発者に取って代わるでしょうか?

生成 AI は開発者に取って代わるでしょうか?近い将来そうなるとは思いません。長年クライアントと仕事をしてきた経験から、製品の需要は決して減ることはなく、常に大きくなっていることを学びました。私たちはもっと多くのことを望み、もっと多くのことを達成する必要があり、テクノロジーの状況は常に変化しており、私たちは常に変化しようと努めています。これがその理由です。

では、チームの効率を 20 ～ 30 パーセント、あるいは将来的には 50 パーセント向上させることができれば、人員が 20 パーセント、30 パーセント、あるいは 50 パーセントも削減されることになるのでしょうか?いいえ、システムにソフトウェアの 20%、30%、または 50% のみを追加する可能性があります。そして、厳密にレビューされておらず、出力を確認するエンジニアがいない場合は、ソフトウェアはさらに悪いものになる可能性が高くなります。その結果、レガシー コードが増え、混乱が生じる可能性があります。

これは私の個人的な予測ですが、短期的には、より多くの課題と複雑さが生じる可能性がありますが、私たちはその課題に立ち向かい、状況を改善する方法を見つけなければなりません。

リーン原則を使用するのが本当に正しいアプローチだと思います。もちろん、リスクについても警告しました。しかし、特にソフトウェア配信ライフサイクルにおいては、リスクは幻想であることが多いのです。ですから、両方の側面から考える必要があります。最後に、AI によって多くの反復的なタスクが排除されるため、コードをより速く記述できるようになると申し上げたいと思います。これは本当に素晴らしいことです。しかし、ライフサイクル全体について考え、それがコーディングだけでなく、実際に高品質のソフトウェアを高速で生産することにどのような影響を与えるかを考慮する必要があります。これらのエンジニアリングの実践はより重要です。

しかし、待ってください。将来もソフトウェアは必要になるのでしょうか?

将来もソフトウェアは必要でしょうか?

これは私が考えていることです。なぜなら、リーダーとして、私たちがシステムに組み込むソフトウェア、特に社内のビジネス ソフトウェアが、本当に私たちの質問を提示して答え、新しい情報を追加し、その後も提示して質問に答え続けるためだけにあるのかどうかを考える必要があるからです。新しいソフトウェアはどれくらい必要ですか?わからない。もちろん、これは来年か再来年の話題になるかもしれません。

しかし、短期的には、おそらくさらに多くのソフトウェアを作成することになるでしょう。だからこそ、取り残されないようにしながらも、思慮深く取り組むことが大切だと思います。組織内のすべてのソフトウェア エンジニアがすでに生成 AI を使用していることは間違いありません。また、知的財産権の侵害がすでに起こっていることも保証できます。したがって、ソフトウェアのライフサイクル全体を理解し、これらの問題を管理する方法を知ることは、今後数年間、すべてのテクノロジーリーダーにとって非常に重要になります。