re:Invent 2024: AmazonのAI導入事例 - Q Developerで工数削減
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Unleashing generative AI: Amazon’s journey with Amazon Q Developer (DOP214)
この動画では、AmazonのNext Gen Developer Experience teamのJoseph CudbyとAmazon Software Builder Experience teamのErin Kraemerが、Generative AIをソフトウェアエンジニアリングプロセスに導入する際のベストプラクティスを解説しています。Amazon Q Developerを活用したToilの削減や、Javaアップグレードによる4,500人年分の工数削減、2億6,000万ドルのコスト削減など、具体的な成果が示されています。また、Knowledge Discoveryの分野では、100万件以上の社内開発者からの質問に回答し、45万時間の工数削減を達成。AIツールの導入には認知的な変化が必要で、チーム単位でのアプローチと、既存のワークフローへの組み込みが重要だと説明しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
AIを活用したソフトウェアエンジニアリングの変革：概要と背景
みなさん、こんにちは。DAP 214へようこそ。本日は、お客様との協業を通じて得られた、Generative AIをソフトウェアエンジニアリングプロセスに導入する際のベストプラクティスと学びについてお話しさせていただきます。私はJoseph Cudbyと申します。AmazonのNext Gen Developer Experience teamのPrincipal Go-to-Market Specialistを務めております。私たちは、お客様の組織のソフトウェア開発チームと協力して、彼らの業務の進め方や改善点を理解する部門です。本日は、Amazon Software Builder Experience teamのHead of ProductであるErin Kraemerにも同席いただいています。彼女のチームは、Amazon全体のソフトウェア開発を最適化するという大きな課題に取り組んでいます。まずは私から始めさせていただき、その後Erinにバトンタッチいたします。
それでは、なぜソフトウェアエンジニアリングが変化しているのか、そしてなぜ変革への機運が高まっているのかについて掘り下げていきましょう。行動様式の変化というテーマについて探っていきます。生産性とToilについて考えてみたいと思います。私はこれらを同じコインの表裏のように考えていますが、このプロセスにおいて密接に関連しています。AIをソフトウェア開発プロセスに組み込むための変革をどのように始めるか、見ていきましょう。また、変化の測定についても話し合います。私はこれらのプロダクトやお客様と約2年間関わってきましたが、一貫して見られるのが測定という考え方です。ベースラインを設定し、私たちが何をしているのかを理解することが極めて重要です。この点について時間を割き、Amazon Q Developerのメトリクスの改善点や、それが導入の過程でどのように役立つかについてお話しします。その後、ASBXとAmazonの取り組みについて、Erinにお話しいただきます。
ソフトウェアエンジニアリングの変化と課題
では、ソフトウェアエンジニアリングのプロセスを変革する必要性と圧力は、どこから来ているのでしょうか？ 大きく2つの要因があります。まず1つ目は、お客様との対話で常に感じるトップダウンの圧力です。顧客により多くの価値を提供し、新機能や新製品を届ける必要があると聞きます。また、既存製品についても、採用率やNPSの向上を目指しています。さらに市場からの圧力もあります。お客様は、開発しているソフトウェア製品で競争するよう促され、ある意味強制されているのです。
また、個々の開発チームや革新的な開発者たちからイノベーションが生まれていることも分かっています。彼らはこれらの新しいツールや最新技術を試し、自分たちの業務にどう活用できるか模索しています。場合によっては何十年も続けてきた仕事に、これらの新技術をどう組み込んでワークフローに統合するか考えています。自動化を進め、より大規模に物事を行い、最終的にはToilを削減することを目指しています。また、より大きく複雑な問題や、より高いパフォーマンス要件に挑戦しようとしています。さらに、JavaからRustへの移行のような新しい言語の習得など、スキルの幅を広げることも目指しています。
このように、変革の必要性と変革への意欲という相反する目標があります。しかし、Toilの存在が変革能力に普遍的な影響を与えることも分かっています。つまり、意欲と動機は存在するものの、Toilの存在によって実行能力が影響を受けているのです。 ここで、ソフトウェアエンジニアリングに関するいくつかのメンタルモデルについてお話ししたいと思います。 この数年間、多くのお客様とお話しする中で、いくつかのテーマが浮かび上がってきました。 ある意味で、ソフトウェアエンジニアリングは工場のように感じられます。すべてのコード行が等しく、すべてのプロジェクトが等しいという考え方です。 おそらく、この均質性は、私たちが行っていることを測定する単一の効果的な方法があり、生産性の向上が簡単に計算できることを意味しているのかもしれません。工場で働いた経験がある方なら分かると思いますが、新しいツールを導入すれば物事は速くなり、とても簡単です。
しかし、この会場にいるソフトウェア開発者の方々は、「ちょっと待ってください。そういうものではありません」とおっしゃるでしょう。そこで、DruckerのKnowledge Workモデルをソフトウェアエンジニアリングに当てはめてみると、この問題がより複雑で難しいものになることが分かってきます。ビジネス目的、つまり何を構築しようとしているのか、何を達成しようとしているのか、そのものが何をするのかという観点から見ると、すべてのコード行が同じ価値を持つわけではないということには、おそらく皆さん同意できるでしょう。また、すべてのワークロードやプロジェクトが同じというわけでもありません。50年前のCOBOLメインフレームを保守することと、モバイルアプリを開発することは、まったく異なる性質のものです。
これらを理解、測定、そして作業負荷の期待値という観点から同じように扱うことはできません。この多様性こそが、測定と考え方における柔軟性を必要とします。お客様との会話の中で、メインフレーム、モバイルアプリ、Microservices、そしてMonolithsを持っているという話をよく聞きます。これらは同じものではなく、同じように扱うことはできません。
私たちは開発チームに対して、なぜそのものを作っているのかという文脈を理解する権限を与えるべきです。その価値は何か？誰の役に立つのか？誰に影響を与えるのか？開発しているものがどのような成果をもたらすのか？このような理解と自律性を組み合わせることで、開発チームは賢明な選択を行い、適切な成果を得るための創造的な解決策を生み出すことができます。この後Aaronが話しますが、これはAmazon全体でのソフトウェアエンジニアリングに対する考え方です。私たちは独特な文化の中で、これらの多くを実践しています。
Toilの特徴と生産性向上への影響
では、Toilについて話しましょう。Toilの特徴とは何でしょうか？これらの特徴はSite Reliability Engineering（SRE）の分野から来ています。共通の基盤を持つために、これをソフトウェアエンジニアリングに適用してみましょう。その特徴とは？典型的に手作業です。ソフトウェアエンジニアリングについて考えると、大きく2つのカテゴリーがあります：典型的に手作業のドキュメント作成と、コーディングです。それは繰り返し作業で、何度も何度も行わなければならないものです。Unit Testの生成は繰り返し作業の一つだと多くの人が考えるのではないでしょうか。お客様からは、テストカバレッジを向上させたいが、開発者があまり好まない作業だという声を一貫して聞いています。
これは非常に興味深い点です。Aaronとはこのことについてじっくりと話し合いました。Generative AIによって、以前は自動化できなかったタスクが、今では自動化できるようになっているケースを私たちは目にしています。数年前にはToilとは考えられなかった新しい種類の活動が、今ではToilと見なされるかもしれません。例えば、パッチ適用やアップグレードの大規模なソリューションは、AIの機能が登場するまでは本当に難しい課題でした。これらは通常、割り込み駆動の戦術的なタスクです。ビルドの失敗、パイプラインの失敗、そしてソフトウェア開発における他の要素も、戦術的なものと考えられるでしょう。
限定的な継続価値というのも特徴の一つです。 ログファイルのダンプなどは継続的な価値はありませんが、私たちは日常的にそれを行っています。 ソフトウェア資産の規模が拡大するにつれて、それに比例して増加するものがあります。ドキュメントやテストが増えるだけでなく、メンテナンス作業、モダナイゼーション作業、パッチ適用作業、そしてTechnical Debtも増加していきます。
このようなToilの特徴を理解すると、ソフトウェア開発プロセス全体で生産性を向上させるための様々なレバーが見えてきます。Amazon Q Developerについて話すとき、私たちは本当にToilの削減に焦点を当てています。生産性はToilを取り除くことの副産物なのです。Toilを取り除くことができれば、開発チームはより生産的なことに時間とエネルギーを使うことができます。
Amazon Q Developerによる開発プロセスの改善
では、Amazon Q Developerではそれがどのように実現されるのでしょうか？Toilにどのようにアプローチするのでしょうか？計画とリサーチに関して、 開発者は同僚に質問したり、社内のWikiを調べたり、オンラインで検索したりと、多くの時間を費やしています。そこで、Amazonのサービスを理解し、運用中のインフラストラクチャーを確認し、既存のコードを解析できるAmazon Q Developerを活用して、この計画とリサーチのプロセスをどのように簡素化できるでしょうか？ 適切なコードの生成 - ここで「適切な」という言葉を意図的に使っています。2年前のこれらのツールは、単にコードを生成するだけでした。その後、私たちが学んだのは、コンテキストが重要だということです。取り組んでいるプロジェクトのコンテキストや企業の標準が、適切なコードを生成する上で重要になります。私たちの世界では、それにはカスタマイズも含まれます。社内のコードリポジトリをキュレーションし、それらをAmazon Q Developerに取り込んで、御社のやり方に沿った推奨事項を生成することができます。
Agentへのタスク委譲は重要なコンセプトです。今朝のKeynoteでご覧になった方もいらっしゃると思いますが、今週はAmazon Q DeveloperにおけるAgentの可用性とそのコンセプトへの移行について多く耳にすることになるでしょう。私たちは本当に、Agentにタスクを割り当てることでToilに取り組もうとしています。
具体例を3つ挙げましょう。セキュリティスキャン機能を大幅に改善し、コードレビューの最初の部分を実行できるようになりました。シニア開発チームから差別化されていない重労働とToilを取り除き、AIにそれを任せようとしています。これにより、開発チームや個々の開発者は、自分のコードに対してコードレビューを効果的に実行したり、自分のマシンで実行したりして、コミットする前に、シニア開発者に影響を与え始める前に、それらの問題を修正することができます。
開発者にとってドキュメンテーションは常に課題となっています。ドキュメントは往々にして正確でなかったり、合理的でなかったりします。また、生産性が重視される現代において、新しい開発者が既存のコードベースに慣れるまでにかかる時間は相当なものになることもわかっています。私たちが顧客と話す際によく出てくる「Time to First Commit」という概念があります。これは、開発者がコードベースで実際に有意義な作業を始められるようになるまでにどれくらい時間がかかるかということです。その多くはドキュメントのアクセシビリティと可用性に依存しています。ドキュメンテーションは手作業で行われ、コードベースに比例して増加します。これを踏まえて、私たちは現在、Q Developmentの一部としてドキュメントを生成する機能を提供しています。つまり、IDEの中で作業しながら、Agentを起動してコードベースを分析し、要約を行い、ドキュメントの生成を開始することができるのです。
先ほど申し上げたように、Unit Testの生成は反復的な作業であり、コードベースに比例して増加します。そこで私たちは、Unit Testの生成をより効果的にし、プロセスから単調な作業を取り除き、開発チームに時間を返すための追加的な取り組みを行っています。また、テストカバレッジは、更新の頻度やコードに対して行おうとしている変更のリスクを軽減する方法でもあることがわかっています。カバレッジが10%の場合、80%や90%の場合と比べてリリースのリスクは格段に高くなります。これらはすべてQ Developerの機能であり、特にこれらの大きな単調作業に焦点を当てています。
AIツール導入における行動変化と期待値管理
開発チームとの会話で常に耳にし、また自分自身や同僚の経験からも感じることですが、ソフトウェアエンジニアリングにおけるAIの使用は認知的な転換を必要とします。10年や15年間同じ方法でコードを書いてきた人にとって、これは大きな変化です。この新しいツールセットを提供することで、異なるタイプのインタラクションが生まれます。それを自分に合わせて活用する方法を理解するには時間がかかるでしょう。この行動変化という考え方、そしてそれをどのように促進し、運用し、シンプルにするかという点に何度も立ち返ることになります。なぜなら、これは顧客のジャーニーや、ソフトウェアエンジニアリングにおけるGenerative AIの採用に関する私たち自身の内部的なジャーニーにおいて、最も重要なポイントの1つだからです。
前のスライドで触れた別のAgentで、コードベースの規模に応じたスケーリング - つまり、パッチ適用やメンテナンス、Breaking Changesの概念についてお話ししていませんでした。1年前、私たちはCode Transformationの機能をリリースしました。その時点では、Javaのアップデートをサポートしていました。本日お聞きになったかもしれませんが、.NETから.NET Coreへの移行をサポートするプレビュー版をリリースしました。私たちは、非推奨のランタイムという要素を理解し、AIがそれを加速できるものにしようと努めています。これは特効薬ではありませんが、間違いなくそれらのプロセスを加速する要因となります。
期待値をどのように管理するか？これは、おそらく90%の顧客との会話で出てくるトピックです。ソフトウェア開発の一部としてのこれらのツールの影響に関する期待は何か、そしてそれらの効果がどれくらい早く現れることを経営陣は期待しているのか？ 典型的には、この変化を重要視する社内のExecutive Championは誰なのか、という期待があります。彼らは長期的にこれに関与し続けるのか？時間の経過とともに、持続的な変化を促進することを優先し続けるのか？最初にお見せした変化の理由に立ち返ると、その多くは時間に縛られています。私たちは新しい機能とリリースでより多くのことをより速く行おうとしています。したがって、ここでのトップレベルの期待は、非常に時間ベースのものであることが予想されます - 彼らはそれが迅速に起こることを望み、変化は素早く起こるべきだと考えています。私たちはこの利点に早く到達したいと考えています。しかし、この部屋にいる方々の中で、ダイエットや運動を始めようとした経験のある方なら、持続的な変化には時間がかかることをご存知でしょう。
筋肉を作るのに時間がかかるように、これまでのやり方を忘れて新しいことを学ぶにも時間がかかります。もう一つ重要なのは、得られる成果についての考え方です。工場モデルの考え方に戻ると、測定は簡単なはずですが、実際にはそうではありません。経営陣との間で、成果をどのように特定し報告するか、どのように正当化するかについて、興味深い議論が交わされます。ROIについての話もよく耳にします。これらのツールは比較的安価ですが、それでもコストはかかります。このような適応や行動の変化を実現するためには、期待値の管理が本当に重要だということを理解する必要があります。
どんな集団の中にも、イノベーターと呼ばれる一定の層（全体の15-18%程度）が存在します。彼らは単に「かっこいい」という理由だけでも新しいものを試してみようとする人たちです。新しいテクノロジーを試し、それが自分たちにとってどう機能するのか、何ができるのかを本当に理解したいと考えています。また、私たちが知っているのは、次の60-70%を占める大多数の人々は、これらのツールが価値と実用性を提供する必要があるということです。開発チームの大半は、Amazon Q Developerをどのように活用するかを見出す必要があります。これは行動の変化なのです - つまり、これらのツールを自分のために機能させる方法を見つけることです。
このような場合、私たちが通常推奨するのは、ツールを導入する際には、チーム全体に展開することです。Amazonでは、これらを「Two-pizzaチーム」と呼んでいますが、Podやスクラムチームとも呼ばれています。私たちが発見したのは、あるチームメンバーの経験を他のメンバーと強化し合えるため、自己参照的な方法がより効果的だということです。特定のプロジェクト、リポジトリ、アプリケーションに関する問題解決について、コミュニケーションとコラボレーションを共有しているのです。
ソフトウェアの展開において内部サポートとトレーニングの必要性について話す際、例えば開発者からヘルプデスクにチケットが上がった時に、ヘルプデスクがどう対応するかといった点について触れています。シンプルな運用面での事項が重要です。皆さんもお気づきかもしれませんし、これから数日で気づくと思いますが、これらのツールのイノベーションの速度は非常に速いです。開発チームが今日使用しているツールは、60日後や90日後、あるいは30日後には異なるものになっているかもしれません。そのため、新機能や機能、オプションを理解し、作業の負担を減らし、新しいエージェント型の行動をスケールさせるために、これらのチームを内部で支援する必要があります。
私たちがお客様に推奨し、比較的効果的だと確認されているのは、Community of Practice（実践コミュニティ）やChampionsと呼ばれる考え方です。組織内で、時間を取って意欲的に取り組み、幅広い機能を理解し、組織の枠組みの中で自分たちのプロジェクトにこれらのツールを活用する方法を理解してくれる人材を特定する必要があります。もう一つ、90%の確率で出てくる話題は、これをどのように測定するかということです。期待値があり、経営陣は何らかの測定結果を求めています。このツールに対して何らかの成果を見たいと考えているのです。このようなソフトウェア開発プロセスをどのように測定すればよいのでしょうか。工場のようなものではないと言われたので、より難しいはずですよね。
ソフトウェア開発プロセスの測定と評価
データポイントには大きく2つのカテゴリーがあります。1つ目は、機械生成による定量的なデータです。これについて考えると、時系列データの例として、ビルドにかかる時間、JiraでのPRにかかる時間、要件収集にかかる時間などが挙げられます。これらは通常、機械生成の日時スタンプが付いているため、速度を素早く把握することができます。また、多くのお客様がSonar Cubeなどの品質評価ツールでパイプラインを計測していることも分かっています。時間とともに品質評価を行えるツールが導入されているのです。セキュリティ評価も同様で、パイプライン内のツールで時間の経過とともにセキュリティの傾向を確認できます。
最後のアウトカムについては、収集がやや難しいものの重要です。先ほど「正しいコード」という考え方について触れましたが、作ったものの成果を理解することで、その価値をより把握できます。具体的には、そのFeatureの採用率を見ているのか、そのFeatureから生み出された収益を見ているのか、NPSの上昇を追跡しているのか。信頼性に関してどのようなアウトカムデータを持っているのか。このような情報は通常、収集が難しいものです。私が話をした多くのお客様や開発チームは、このような視点で考えていませんが、ソフトウェアエンジニアリングにAIを実装するという変化を乗り越えようとする中で、このような情報をどのように収集するかを考え始めることは非常に有益です。では、人間が生成する定性的なデータを見てみましょう。
一般的に、お客様は週次やスプリントごとにサーベイを実施しています。これらのサーベイでは、通常1から5や1から10といった範囲で数値を設定し、人間が生成した数値データを収集する質問が複数あり、その傾向を時系列で追跡できます。また、自由記述のフィードバック、つまりなぜそうなったのか、具体的なエピソードやストーリーも非常に価値があります。機械生成されたデータと自由記述のフィードバックから得られるエピソードの両方を見ることで、ツールが適切に機能しているか、ビルド失敗への対応など、他にどのような要望があるのかを理解し始めることができます。
つまり、変化への圧力があり、行動が変化していることを確認しました。 その測定方法を理解する機会も得ました。 今、私たちはベースラインの考え方に到達しています - 現状を把握し、ベースラインを確立する必要があります。お客様には、現在使用しているものを活用することをお勧めします。現在お持ちの測定方法やツールを使用して、ベースラインを設定し、ツールを実装して、 時間の経過とともに傾向を観察していくのです。
フレームワークやこの問題の考え方について、より広い観点で議論する際、私は通常、お客様に2つの点に注目することをお勧めしています。1つ目はDORAメトリクスで、多くの方がご存知だと思います。これは、パイプラインの技術的な実装を確認し、その動作を理解し、相対的な成熟度を把握し、パイプラインプロセス自体の中でToilを特定し、機会を見出すための方法です。SPACEは非常に興味深いフレームワークです。何を測定すべきかを具体的に指示するのではなく、考え方のカテゴリーを提供します：満足度とウェルビーイング、アウトカムとしてのパフォーマンス、アクションとアウトプットのためのアクティビティ、コミュニケーションとコラボレーション、効率性とフローです。これらのフレームワークはいずれも、一朝一夕に実装できるものではなく、ジャーニーを表しています。しかし、最終的な状態がどのようなものになるかを考える上で、素晴らしい方法となります。
この取り組みから学んだベストプラクティスをいくつかご紹介しましょう。まず、文化が極めて重要であることを強調しておきたいと思います。多くの開発チームから「納期やデリバラブルに追われていて、これらを調査したり理解したりする時間がない」という声を聞きます。開発チームに「遊び」の許可を与えるという考え方が非常に重要なのです。ストーリーポイントなど、どのような指標で測るにせよ、短期的なアウトプットの減少を受け入れ、開発チームがこれらのツールを自分たちのワークフローに組み込む方法を見つけ出す機会を与える必要があります。私たちは彼らに行動の変化を求めているのですから、そのための機会を提供しなければなりません。
期待値のマネジメントが重要です。これまでも何度か申し上げましたが、想定されるインパクトやタイミングについて上層部への期待値をマネジメントすることはもちろん、 開発チームに対する期待値のマネジメントも必要です。このようなツールを使用する際は、失敗を受け入れる必要があります。常にうまくいくわけではありませんが、うまくいって価値を生み出し、取り組んでいる課題を解決できたときの結果は驚くべきものとなり得ます。 インセンティブの整合性も重要です。昨日、あるお客様との経営層ミーティングで、開発者にこれらのツールの採用を促すにはどうすればよいかという話をしていました。これは本質的に組織的な変更管理、つまり大規模な組織でどのように新しいものを採用していくかという話です。例えば、年間のMBOの一部として、トレーニング、認定資格、コミュニティ活動、あるいは同僚のトレーニングなどの要素がある場合、Amazon Qのチャンピオンとしての活動をその企業目標に結びつける機会があるのではないでしょうか。既存のツールや行動様式に基づいて開発チームにインセンティブを与えているのに、それを変更するよう求めるのであれば、インセンティブ自体を変更する必要があるかもしれません。イノベーターだけでなく、チーム全体を巻き込む必要があります。
私たちが知っているのは、Scrumチームであれ、 Podであれ、2人チームであれ、チーム全体がツールを使用している場合の方が効果が高いということです。そのため、POCやPOVを実施する際は、個人ではなくチームを選んで取り組むことをお勧めします。
驚くかもしれませんが、開発者は コーディングだけに時間を費やしているわけではありません。調査によって異なりますが、1日1～2時間程度です。つまり、期待値の観点から言えば、開発者が1日8時間コードを書いているという工場的な考え方は、実際の働き方とは異なるのです。 コードを書くことは、ほとんどのチームにとって最大の制約要因ではありません。アイデアを本番環境に展開するまでのプロセスを見ると、コードを書くこと自体が最大の制約ではないかもしれません。DORAの利点は、プロセスを分析する際に、これらの制約やボトルネックを特定できることです。適切なコードの生成を最適化することに加えて、他の領域にも目を向ける機会があるかもしれません。
目標は、正しいソリューションを構築するための適切なコードを書くことです。 組織内ですでに解決策が存在する場合、コードを全く書かないことが最も生産的な結果になると私は考えています。重複を避けることで、ドキュメント作成、テスト、メンテナンス、技術的負債などの下流への影響を生み出さないですみます。これらのツールを検討し、AIをプロセスの一部として組み込む際には、単にコードを生成するだけでなく、より多くの情報を表面化できる他の場所はないでしょうか。 チーム間の協力関係を支援することは非常に重要です。チーム間でどのように協力しているかを把握し、ベストプラクティスを共有することには大きな価値があります。
Amazon Q Developerの使用方法とメトリクスについて、よく寄せられる質問をいくつかご紹介します。 まず「誰がAmazon Q Developerを使用しているかを知るにはどうすればよいか」という質問ですが、これは以前は課題でしたが、Amazon Q ConsoleのLicensingコンソールにアクセスすると、すべてのユーザー、ライセンスのステータス、最終アクティブ日を確認できるようになりました。これにより、特定の期間内にツールを使用した、あるいは使用していないユーザーを簡単に把握できるようになりました。また、ここ数週間で、日次メトリクスも導入しました。これは、誰が使用しているかだけでなく、誰がチャンピオンユーザーなのか、ヘビーユーザーは誰か、成功事例がどこから生まれているのかを知りたいというニーズに応えたものです。Amazon Q Developer Consoleで、ユーザーメトリクスを有効にしてS3バケットを指定すると、毎日終わりにCSVファイルが提供され、各ユーザーが生成したコード行数を確認できます。
Amazon Q Developer Console Dashboardをご覧になった方はお分かりかと思いますが、このダッシュボードについては多くの改善を重ね、実際にここ1週間ほどで新しいバージョンをリリースしました。より多くの情報と集計トレンドを表示できるようになりました。生成行数という概念で標準化を図り、これは様々なモダリティで一貫して使用されます。インラインコード生成、インラインチャット、Chat/Dev、Code Transformのいずれにおいても、生成行数という形で報告されます。また、Agentのアクティビティ、作成されたドキュメント数、作成されたUnit Test数、レビュー数なども確認でき、組織全体の集計トレンドを把握できるようになっています。このデータはすべてCloudWatchやCloudTrailでも利用可能なので、追加のダッシュボードを作成したい場合にも活用できます。
では、このデータを組織の変革支援にどのように活用すればよいのでしょうか？私たちが提供する情報は、確実にこれらのアクションに関するものです。つまり、アクティビティやアウトプットであり、生産性の向上を直接示すものではありません。私たちが提供するデータをSPACEフレームワークに当てはめると、私たちがカバーできない他の4つのカテゴリーがあることに気づくでしょう。つまり、私たちが提供する情報は全体像の一部ではありますが、すべてではないということです。ロールアウトの管理方法、組織内で何が起きているかの把握、チャンピオンユーザーの特定とサポートという観点から見ると、ユーザーライセンスメトリクスとアクティビティ情報により、これらのツールの展開状況と組織全体での採用状況を理解するのに役立ちます。
AmazonにおけるAI導入の実践例：ASBX の取り組み
それでは、Amazonでの経験についてより詳しく説明するために、Erinにバトンを渡したいと思います。ありがとうございます、Joe。皆さんの中で、業務内容に関係なく、AIを実際に使用している方はどのくらいいらっしゃいますか？かなりの数の方がいらっしゃいますね。使用感はいかがですか？良好ですか？素晴らしいですね。もちろん、皆さんはアーリーアダプターですからね。
私はErin Kraemerです。四半世紀近くAmazonでソフトウェア開発に携わってきており、現在はAmazonの社内開発者ツーリングチームのプロダクトヘッドを務めています。本日は、開発者ツールチェーンにAIを導入して得られた知見をお話ししたいと思います。
私にとってAIは新しいものでした。2023年4月頃、私の上級スポンサーの一人から電話があり、「Erin、AI」と言われました。私は「はい」と答えました。彼は再び電話をかけてきて、「Erin、AIを見てみるべきだ」と。そこで私は深く掘り下げることにしました。理解を深めていく中で、AIの持つ特性の一部が、開発者の効率を高めるという私の仕事領域にとって実に興味深いものだと分かってきました。Amazonの開発者のためにAIを評価する際、私は不要な摩擦やToilを取り除き、開発者がフロー状態を達成できるような方法を探しています。
AIの話に入る前に、2022年に私と数人のメンバーがAmazon Software Builder Experience（ASBX）を立ち上げた際の一般的なアプローチについてお話ししましょう。私たちはAmazonの上級幹部チームに提案する機会を得ました。S teamをご存知の方もいるかもしれません - Andy Jassyと彼の直属の部下たちですが、私たちは彼らに対して、開発者エクスペリエンスへの投資、開発者向けのツールやワークフローへの投資、そしてその改善がAmazonのビジネスにとって極めて重要だという主張をする機会を得ました。そして彼らはそれを受け入れてくれました。その後、私はコードのビルドとデプロイメントシステム、チケット発行、ページング、タスク管理システム、運用ツール、ナレッジ共有ツールなど、様々な構成要素を所有する社内の各チームを集めることができました。
この新しい組織を立ち上げた時に手に入れたのは、驚くほど強力なツール群でした。これらは数十年にわたってAmazonの構築と運営を支えてきましたが、成果を重視するマインドセットではなく、ツール重視のマインドセットで作られていました。私たちが最初に注力したことの一つは、成果重視の能力を構築することでした。つまり、私たちにとって本当に重要なこと - Amazonの幅広いビジネスを動かすソフトウェアを構築・維持するBuilder（開発者）の支援 - を測定する方法を見つけることでした。確かに、ソフトウェアの構築、デプロイ、サポートの成功はビジネスへのインプットの測定であることは認識しています。これがどのように効果的なビジネス成果を生み出すかについては、また別の議論になるでしょう。
2022年に開始した時点では、まだ測定の仕組みを構築していなかったものの、すぐに動き出す必要がありました。最初に取り組んだのは、専門家の意見を集めることでした。私は社内の多くの人々と話をし、ツール自体を改善することで追い風を生み出せる機会があることは分かっていました。しかし、私たちが聞き始めたのは、開発者の仕事の妨げとなる向かい風、つまりHeadwindsにもっと大きな機会があるということでした。まずは概算的なデータから始めました - ここでは概数をお話しします。開発者の時間の30%がパッチのアップグレードや必須キャンペーンなどに費やされていました。25%がオンコール運用に費やされていました。正確な数字は持っていませんでしたが、社内の人々と話をする中で、これらの数字は概ね正しい規模感だと感じられ、特にその30%という数字は大きな機会を表していました - 大きなHeadwindであり、多くのToilが存在していたのです。
ASBXを立ち上げた時に認識していたもう一つの重要な点は、Joeも言及していましたが、カルチャーが重要だということです。私たちはAmazonの独特なカルチャーに沿った形で機能する必要がありました。これは、AmazonをAmazonたらしめている重要な要素である、エンドツーエンドの所有権というカルチャーを尊重することを意味していました。また、Amazonの自動化カルチャーを活用できることも意味していました - 自動化が存在しない領域で自動化を構築し始めることができ、それはAmazon内で文化的に受け入れられることでした。さらに、データ駆動のインサイトを活用して変革を推進することもできました。
具体例を後ほどご紹介しますが、私たちが行うすべての取り組みは、外部に対してだけでなく、内部に対しても非常に高いプライバシーとセキュリティの基準を満たす必要がありました。例えば、私はAmazonの従業員データを多く扱っていますが、そのプライバシーとセキュリティの確保は絶対に欠かせません。
私たちが行っている測定について説明しましょう。SPACEフレームワークの中で最初に着手したのは、測定項目をPillarに分類することでした。最初のPillarである「System Health」には、可用性、レイテンシー、コスト効率など、予想される項目が含まれています。これらはAmazonが長年にわたって測定してきた指標です。ツールによってこれらの指標を改善できれば素晴らしいことですが、私が最も注視しているのは、これが失敗を示す指標だということです。ツールやワークフローを変更する際に、これらの指標が悪化し始めたら、システムに何が変化したのかを理解するために立ち止まる必要があります。なぜなら、システムに変更を加える際に、これらの指標に悪影響を与えることは許されないからです。
次は「Delivery Health」です。これは従来のDORAタイプの測定に似ており、Change Lead TimeやDeployment Frequencyなどが含まれます。その中には、Deployment失敗率、Rollback率、Recovery時間なども含まれています。Amazonは過去に多くの時間をDeployment率、失敗率、Rollbackの改善に費やしてきたため、これらの数値は実際にとても良好です。これらも同様に、ツールシステムに変更を加える際の失敗指標として機能します。
また、この指標群には「Underlying Input Measures」と呼ばれるものも含まれています。これらの個別の指標は成果を示すものではありませんが、良い行動を促し、システム内で制御可能な要素を観察する機会を提供するという点で非常に興味深いものです。最初に取り組んだものの1つが、CI/CDパイプラインにおける手動介入の測定です。ASBXで始めた当初、Flaky TestやBuild失敗などの問題により、理論上は完全自動化されているはずのCI/CDパイプラインに開発者が手動で介入しなければならないケースを数えました。その数は驚くほど多かったのです。
これは大きな中断を意味します。開発者が作業を終えて承認を得て、コードをマージし、ビルドとデプロイが進行中で別の作業に移っているときに、パイプラインを再度手動で実行するために中断を強いられるのです。チームとして最初に行ったのは、パイプラインツール内で手動介入の回数を表示することでした。それだけの対応でしたが、適切な場所で適切なタイミングで適切な数値を表示することで、最初の1年で手動介入の回数を33%削減することができました。
多くの測定を行う際には、何を測定するのか、そしてそれがどのような行動を引き起こすのかについて、よく考えることが重要です。測定できる、そして測定すべきものはたくさんありますが、共有すべき指標もあれば、共有すると逆効果な行動を引き起こす可能性のある指標もあります。私たちの3つ目の重要な柱は、Team Healthと呼ばれるものです。これには開発者の幸福度や満足度、認識などが含まれます。Developer Experience teamとして、私たちは、チームの調子が良く、ソフトウェアの開発がスムーズで、システムが健全で安定していれば、全体的に良好だと考えています。これらのどれか一つでもリスクがある場合は、問題があると判断します。
AIをツールチェーンに導入し始めた時、これらが私たちが注目していた指標でした。基礎となる指標も確認していましたが、これらが主にAIが私たちのワークフローやDeveloper Experienceをどのように変えているかを理解するために注視していた項目です。この後は、私たちがAIを導入した具体的な事例とその結果について、いくつかご紹介していきたいと思います。
Amazon Q Developer の具体的な活用事例と成果
多くの方が、私たちのCode Transformationの話を聞いたことがあるでしょう。私たちのチームは、Amazon内でのJavaアップグレードを担当することになりました。
これは、パッチ適用とアップグレードに関する作業の30%がToilだったというASBXの原点に遡ります。2022年、最初に取り組んだことの一つは、パッチ適用とアップグレードの作業からToilを排除するという課題に焦点を当てた、優秀な開発者によるチームを立ち上げることでした。これは意図的な投資の決定であり、そのチームは特に非破壊的な変更の分野で大きな進展を見せました。
私たちが発見したのは、メジャーバージョンのアップグレードのような破壊的な変更に関して、Open RewriteやXMGのような技術では限界があるということでした。これらの技術は広く活用され、非常に価値のあるものですが、変換作業のある段階までしか対応できず、その後は人間の介入が必要になります。私たちの規模では、人間の介入が必要となることによる摩擦が大きな障壁となっていました。さらに、一般的なチームにとって、Javaのアップグレードは必須というよりは「あれば良いもの」と考えられていました。インフラのコスト削減やパッチ適用の改善につながるものの、新しい顧客向け機能と優先順位を比較すると、特に700もの依存関係の変更が必要なアップグレードは、優先順位が下がってしまうことが多かったのです。
このような取り組みは、ローカルレベルでは経済的に見合いませんでしたが、全体として見ると私たちにとって非常に良い結果となりました。進展は見られたものの、最終的に次の一手が分からないという壁にぶつかりました。そんな時、まさに絶妙なタイミングでAIという魔法のような技術が登場したのです。私たちは、Qチームがコード変換機能の開発を始めた時から一緒に歩む機会に恵まれました。私たちは新しい方法でAIを活用する実験を始め、それを社内のツールチェーンに組み込んでいきました。そして、そのイノベーションの一部が現在、パブリックプロダクトに組み込まれています。
私たちは、AIがソフトウェアのアップグレードを支援することに誰も反対しないだろうと考えていました。そして、ツールチェーンへの実装方法により、ほとんどの開発者はAIが関与していることを意識する必要すらありません - 変換ツールは単純に変換を実行するだけです。最初の大きな成功は、このJavaのアップグレードでした。年半ばまでに、社内で推定4,500人年分の開発者の工数を節約し、インフラ全体で約2億6,000万ドルのコスト削減効果があったと見積もっています。個々のチームではこれほどの削減効果は見られませんでしたが、全体としては非常に大きな効果があり、AIによる変換なしではこの障壁を乗り越えることはできなかったでしょう。
人々の受け止め方に関して言えば、私たちはこのツールを中央で実行し、コードベースの大部分をスキャンして、各チームにJavaの変換を実施したというPull Requestを送信できるように構築しました。コードレビューの80%が変更なしで承認されるという指標があったにもかかわらず、中央での実行には大きな摩擦がありました。進めていく中で、アプローチを変更する必要がありました。私たちは自分たちのために構築したCLIを各サービスチームに配布し始め、エンドツーエンドの所有権の原則を思い出しました。チームが自分たちで動作を確認できるようになると、より信頼を得られるようになり、大きな進展が見られました。
これは私たちにとって興味深い学びの経験となりました。多くのことを中央で実行できれば皆が喜ぶだろうと考えていましたが、実際はそうではありませんでした。私たちは非常に高いレベルのレジリエンスを求められており、実際にページャーを持っているのは彼らなので、私たちの作業を見てもらう必要がありました。次に、AIを導入した2番目の主要なユースケース、Knowledge Discoveryについて話しましょう。 今年のStack Overflow開発者調査では、53%の回答者が、情報の場所を知っていても、回答を待つことで作業の流れが中断されると述べており、これはAmazon内部でも同様の状況が見られています。
私たちには膨大な量の社内知識があり、その品質や古さはさまざまです。情報は豊富にありますが、発見が非常に困難です。そこで、私たちは多くの社内ナレッジベースを取り込み、Q Businessと統合しました。今年これまでに100万件以上の社内開発者からの質問に回答し、技術的な質問への回答を見つけて提供するための工数を推定45万時間削減しました。なぜなら、答えを探している時、往々にして他の誰かの作業を中断させることになるからです。
実は私たちは、Q businessが利用可能になる前からこの開発を始めていました。Q1の期間中に、社内向けの独自ソリューションを構築していたのです。品質は私たちにとって重要な要素なので、ツールを切り替える前に必ずチェックを行います。そこでQ businessと自社開発のソリューションのベンチマークを開始したところ、Q businessの方が優れた結果を示したため、Q1で切り替えを行い、それ以降はずっとQ businessを使い続けています。
これらの成果を達成するために、まず高品質なコンテンツをナレッジベースに厳選して取り込むことに注力しました。大量の情報がありましたが、むやみに全てを投入するのではなく、質の高いコンテンツを選別して投入しました。また、関連性を高めるために、できる限り多くのコンテキストを含めてレスポンスの範囲を設定しています。そして、この機能を社内のQ&Aサービスなど、開発者が既に使用しているツールに統合しました。新しい質問が投稿され、AIで適切に回答できると判断される範囲内に既存の回答がない場合は、AIで生成した回答を提供するようにしています。
ポジティブなシグナルに基づくと、レスポンスの正確性は50%以上を達成しています。開発者たちはAIが回答を生成していることを認識していますが、既存の業務フローに組み込まれているため、それを気にする必要はありません。当初は、このシステムをローンチするには非常に高い精度が必要だと考えていましたが、比較的新しい技術であることを踏まえて、思い切って導入することにしました。結果として、50%以上の正確性でも十分に役立つことが分かりました。重要なのは正しい方向性を示すことで、参考文献も併せて提示することで、そこから答えを見つけることができます。Wikipediaのように、まずは概要を把握し、下部の参考文献セクションで詳細な情報を得られるというイメージです。
最後はAmazon Q Developerについてです。私たちは社内の開発者アシスタントとしてAmazon Q Developerを採用しています。 先ほどの2つの例では既存のワークフローにAI機能を組み込むことができましたが、Q Developerは開発者にとってより大きな認知的な変化を必要とします。これについては、まだ journey の始まりだと考えています。この技術は今のところ魔法のようではありませんが、確かな実用性があります。業界全体がこの分野に投資を続けることで、おそらく3〜5年以内には魔法のように感じられるようになり、現在の状態を振り返って「あれは可愛らしかったね」と言うことになるでしょう。
私のチームはQチームと密接に協力しており、今年は多くの改善を目にしてきました。開発者から好評を得ている分野をいくつか紹介します。まず一つ目は、新しいコードベースの理解です。Amazonでは、他のサービスのコードを扱う必要がある場合や、組織再編で新しいプロジェクトを担当することになった場合など、自分が詳しくないコードを扱うことが一般的です。新しいコードベースを理解する必要があるというシナリオは非常に一般的で、この点についてQは好評を得ています。次に、新しいプログラミング言語についてです。Amazonは多言語開発環境で、社内で多くの異なる言語を使用しています。個々のチームが複数の言語を使用することもあり、特定の言語のスキルではなく一般的なエンジニアリングスキルで採用しています。そのため、あまり馴染みのない言語で作業することも珍しくありません。ある開発者から、初めてのRustプロジェクトを始めた際の話を聞きました。通常なら習得に3週間ほどかかるところを
新しい言語の文法を習得してから実際にコーディングができるようになるまでには、通常かなりの時間がかかるものですが、Amazon Qを使うことで、最初の1週間で実際に生産的なコーディングができるようになったと感じられたそうです。これは素晴らしい成果でした。もちろん、Unit testやドキュメントの作成にも重宝しており、特に英語を母国語としない同僚からは非常に好評を得ています。この1年間、開発者たちは同僚にコードを共有する前に、すでにこのツールを使ってコードのプレビューを行っています。
ある開発者から聞いた最も印象的なフィードバックの1つは、Amazon Qは話し返すことのできるRubber Duckのように機能することで、行き詰まりを解消してくれるというものでした。Pragmatic Programmerで紹介されているRubber Duck Debuggingという概念をご存知ない方のために説明すると、デスクに置いたゴム製のアヒルに向かって、行き詰まったコードを1行ずつ説明していくという手法です。この説明のプロセスを通じて、開発者はしばしば問題解決の糸口を見つけることができます。そして今、Amazon Qによって、そのアヒルが実際に会話を返してくれるようになったわけです。
次に進む前に、具体的な成果について気になっているかもしれませんね。初期の測定結果では、これらのツールを使用した場合、システムの健全性に悪影響を与えることなく、変更の速度にポジティブな向上が見られています。私たちのサイエンスチームは素晴らしい仕事をしており、現在多くのピアレビューを行っています。ピアレビューを通過したデータが揃い次第、皆様と共有できることを楽しみにしています。
それでは、開発者の採用に関する重要なベストプラクティスについてお話ししましょう。先ほど述べたように、これはワークフローの変更を伴います。忙しい開発者にツールを投げ渡すだけで、すべてが魔法のようにうまくいくと期待することはできません。Amazonでは、社内の関連コードの例やユースケースを使用したPrompt Engineeringのトレーニングを構築するなど、開発者がこのツールを最大限活用できるようサポートしています。アーリーアドプターはすぐに飛びつくでしょう。そういった人たちは素晴らしい存在です。しかし、実用的な多数派の人々は何年も、場合によっては何十年も使い続けてきた確立されたワークフローを持っており、一歩引いて新しいものを試してみるには、いくらかの支援と励ましが必要になるでしょう。
Joeが言及したように、これが私たちがチーム単位でのアプローチを推奨する理由です。個人それぞれが異なるワークロードを持ち、このツールの使い方も異なってきます。しかし、重要なのはチームとしての健全なコミュニケーションです。次に、あなたのチームの中からRubber Duckのような成功事例を見つける必要があります。アーリーアドプターたちがそれを見つけてくれるでしょうから、彼らの声に耳を傾け、調査を行い、チームと共有するためのプラットフォームを提供することが大切です。最後に、このツールはコードを生成することができますが、それはツールができることの一つに過ぎません。実際、それが最大の価値ではありません。私たちは、賢い人々が自身の仕事から摩擦を取り除くためのツールとしての価値こそが重要だと考えています。
AI活用の今後の展望とベストプラクティス
最後に、この分野で私が期待していることについてお話ししたいと思います。先ほど申し上げたように、私のチームはAmazon Qチームと並行して活動し、必ずしも最初から上手くいくとは限らない、より探索的で実験的な方法でAmazon Qを使用する機会を得ています。最初の大きな取り組みの1つは、実は私の開発チームから出てきたものなのですが、ビルドとマージの失敗への対応でした。AIがこれまでの私たちのボトルネックを解消するのにどのように役立つか、ブレインストーミングをしていた時、コード変換作業から得た知見に基づいて、開発チームはこれが非常に有効だろうという強い確信を持ちました。
社内では毎週多くのビルドとマージの失敗が発生しており、それらを解消できれば喜ばない開発者は一人もいないでしょう。実際、これまで実施してきたあらゆる開発者調査で、マージとビルドを容易にすることが常にトップの要望でした。私たちは継続的に投資を続けていますが、かなりの難題です。しかし、AIはこの分野で大きな変化をもたらす可能性があると考えています。私のチームは約1週間前に、ビルドとマージの失敗の約15%に対応する社内プロトタイプをリリースしました。まだ結果データは受け取っていませんが、その成果が楽しみです。うまくいけば、Amazon Qチームと共有して、すべての人のために実現できることを期待しています。
もちろん、Transformationにも期待しています。先ほど数字をお見せしましたが、正直なところ、Javaが私たちにとってTransformationの最大の機会だとは思っていません。この技術を使い始めて最初の1年でこれだけのことができたことを考えると、これからどこまで進められるか、とても楽しみです。システムの健全性を維持しながら、どこまで大胆なTransformationができるか、しっかりと挑戦していきたいと思います。常に注意を払っていく必要がある部分ですが。
開発者たちから聞こえてくるのは、これらのAIシステムが私たちの特殊なコードや独自のツールを理解してほしいという要望です。私たちは膨大なコードベースを持っており、私が持っているすべてを理解するためにCustomizationをどこまで推し進められるか、とても楽しみです。Code Reviewsは既に良好な初期結果を示していますが、これも興味深いボトルネックの1つだと考えています。近い将来、Code Reviewから人間を完全に排除することはないでしょう。私たちはCode Reviewから大きな価値を得ています。しかし、定型的なCode Reviewを自動化できれば、それは素晴らしいことです。率直に言って、熟練した開発者と同等のレベルでレビューができるAIがあれば、サードパーティのコード取り込み前のチェックなど、多くの可能性が開けてきます。
ドキュメントに関しては、確かに多くのドキュメントを持っていますが、もっと多く、もっと良質なものが必要です。そのため、この分野にも期待しています。そして最後に、Systems Architectureについてですが、これは難しい課題になると思います。複雑なSystems Architectureには多くの暗黙知が含まれています。AIはようやく、経験から学ぶような従来の知識では伝えにくいこの暗黙知の領域に足を踏み入れ始めたところです。しかし、これは非常に価値のある分野だと考えており、この journey に期待しています。
開発システムにAIを導入する際は、必ず成果を測定するようにしてください。コード行数を見ることはもちろんですが、それは活動指標であって、コード自体が成果ではありません。最低限、システムの健全性にどのような影響を与えるかを見てください。System HealthやDelivery Health、Team Healthにプラスの影響があるのか、マイナスの影響があるのかを確認してください。その認識の側面について、もしビジネス成果に紐づけられる仕組みをお持ちでしたら、それも素晴らしいですね。そちらも確認してください。
現在、開発者向けのAIにおけるキラーアプリケーションは、私はToilだと考えています。使いまくって、とことん活用して、できる限り多くのToilをAIに任せてください。本当にそれに適していると思います。先ほど述べたように、Toilを排除することで、ほぼ間違いなく開発チームの集中力と生産性が向上します。できる限り既存のワークフローやツールにこれを組み込んでください。そして、組み込めない場合は、導入には時間とイネーブルメントが必要だということを理解しておいてください。
最後に、「Permission to Play」を与えてください。もし組織のリーダーの立場にある方は、チームにこれらのツールを試す許可を与えてください。私は以前、自分の組織にメールを送って、これを試してみるように勧めました。そのメールを送った後、導入率が上がったのが分かりました。組織のディレクターである同僚たちが私のメールに賛同の意を示すと、さらに導入率が上がりました。チームにこれを試す許可を与えることは本当に重要です。なぜなら、みんな忙しいからです。多くのことを求められている中で、これに時間を使うことが許されているということを伝えることが大切なのです。お時間をいただき、ありがとうございました。re:Inventの残りの時間をお楽しみください。アンケートへのご記入をお忘れなく。カンファレンスでまたお会いできることを楽しみにしています。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion