2年前、AIが本番用の関数を書き、レガシーモジュールをリファクタリングし、人間が目を通す前にバグを見つけるようになると言われたら、ほとんどのエンジニアリングリーダーは、生産性の奇跡が起きつつあると言ったでしょう。そして狭い意味では、実際にそうなりました。AIコーディングアシスタントは、コードを速く入力することにおいて本当に優れています。
では、じっくり考えてみる価値のある問いです。ソフトウェア開発で最も遅かった部分が劇的に速くなったのに、なぜチームが2倍の速さでリリースしているように感じられないのでしょうか。
コードを書くことは、そもそもボトルネックではなかったからです。ボトルネックは、その周辺のすべてを調整することでした。
誰も自動化しなかった部分
「アイデアがある」から「本番で稼働している」までの間に、実際に何が起きているかを考えてみてください。誰かが作業のスコープを決めます。開発者がそれを書きます。それはレビュー待ちのキューで待たされます。別のキューでQA待ちをします。誰かがドキュメントを書かなければなりませんが、たいていは事後で、たいていは急ぎです。誰かがデプロイメントパイプラインを設定します。誰かがロールアウトを見守ります。これらのステップにはそれぞれ引き継ぎが伴い、引き継ぎのたびにコンテキストが失われ、優先順位が再交渉され、実際のコーディングに4時間しかかからなかったチケットが、人と人の間で4日も待たされることになります。
AIコーディングアシスタントは、その組み立てライン上で最も速い工程をさらに速くしました。他のすべての工程(そしてそれらをつなぐキュー)は、以前とまったく同じように遅く、手作業のまま残されました。だからこそ、「開発者のコーディングが速くなった」ことが、「リリースが速くなった」ことに結びつかないケースがこれほど多いのです。引き継ぎの連鎖の中で1つの工程だけを速くしても、作業は次の工程でより長く待たされるだけです。
「ソフトウェア開発のためのAI」が意味すべきものの再考
これこそが、私たちがAITMを作って解決しようとした問題であり、また別のオートコンプリートツールを作らなかった理由です。
AITMは、ソフトウェア開発ライフサイクル全体(計画、フルスタックのコーディング、自動コードレビュー、エンドツーエンドテスト、ドキュメント作成、CI/CD、クラウドへのデプロイ)を、ひとつのリクエストから管理するAIソフトウェアエンジニアリングプラットフォームです。考え方は言葉にすれば単純ですが、実現するのは本当に困難です。タスクを一度送信すれば、AITMが設計し、コーディングし、テストし、ドキュメント化し、本番環境に出せるソフトウェアとして届けます。 人間が6つの別々のツールと4つの別々のチームの間を手作業で付き添う必要はありません。
これは「この関数をもっと速く書く手伝いをして」という種類の自動化とは別物です。引き継ぎそのものの自動化であり、エンジニアリング生産性ツールがこれまでほとんど手をつけてこなかった領域です。オートコンプリートより自動化が難しく、デモでも見栄えがしないからです。
ひとつのステップだけでなくパイプライン全体を担うと何が変わるか
コードレビュー、テスト、ドキュメント作成、デプロイメントが、別々の手作業のキューではなく、継続的に管理される1つのプロセスの一部になると、いくつかのことが自然に起こります。コードは、残りの作業を誰かが手をつけてくれるのを待つ生のdiffとしてではなく、すでにテストされ、ドキュメント化された状態で届きます。アーキテクチャ上の判断は、スケーリングのインシデントが起きた後に後付けされるのではなく、最初からセキュリティとスケーラビリティを考慮して行われます。そしてリリースサイクルは短縮されます。誰かがより速くタイプしたからではなく、ソフトウェアが列に並んで待つ時間がはるかに短くなったからです。
エンジニアにとって、この変化は一見したよりも重要です。変更をレビューに通し、QAを越え、ドキュメントに反映して世に送り出すための調整のオーバーヘッドに費やす時間が減り、人間の判断が本当に必要な仕事、つまり何を作るか、どうアーキテクチャを組むか、この製品とこのユーザーにとってどのトレードオフが重要か、に使う時間が増えます。AIは、その判断を置き換えようとすべきではありません。判断を働かせる妨げになるものを、すべて取り除くべきです。
本当の競争上の問い
長年、ソフトウェア業界は、個々のエンジニアがコードを1行書く速さで生産性を測ってきました。コードを書くことが高コストな部分だった頃には、それは妥当な代理指標でした。しかし、今はもう違います。ここから先で抜きん出るチームは、エンジニアが最も速くタイプするチームではなく、「アイデアがある」から「稼働していて、テスト済みで、ドキュメント化され、本番で安全に動いている」までの距離を縮めたチームです。
それがAITMの賭けであり、今後数年間のソフトウェア開発におけるAIが実際に向かう変化だと私たちが考えているものです。より賢いオートコンプリートではなく、ライフサイクル全体にわたってエンドツーエンドで成果に責任を持つAIです。
もしあなたのチームも同じ課題を抱えているなら、どのようにお考えか、ぜひお聞かせください。