re:Invent 2024: Amazon Q Developerのカスタマイズで開発生産性向上
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Customize Amazon Q Developer to speed up enterprise development (DOP216)
この動画では、Amazon Q Developerの機能とカスタマイズについて詳しく解説しています。開発者の生産性向上を目指すAmazon Q Developerは、コーディングだけでなく、ソフトウェア開発ライフサイクル全体をサポートします。特に注目すべきは、組織固有のコード規約やベストプラクティスに合わせたカスタマイズ機能で、National Australia Bankでは約1000人の開発者が活用し、コード提案の採用率50%、41%の生産性向上を達成しています。また、Amazon社内では約8万人の開発者が利用しており、Prime Videoチームではカスタマイズ導入後にコード提案の受け入れ率が50%まで上昇し、生産性が最大60%向上するなど、具体的な成果が示されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Amazon Q Developerの概要と開発生産性向上への取り組み
DOP 216: 「企業の開発スピードを向上させるAmazon Q Developerのカスタマイズ」にご参加いただき、ありがとうございます。私はJessicaで、Amazon Q Developerのゴートゥーマーケットチームに所属しています。本日は、この数ヶ月間のAmazon Q Developerに関する興味深い特別な取り組みについてお話しいただく、Srini IragavarapuとPaul Roneyをお迎えできることを大変嬉しく思います。
本日のアジェンダですが、まず現在の課題について議論し、その後Sriniからカスタマイズに関する具体的な機能と始め方についてお話しいただきます。また、戦略的なお客様であるNational Australia Bankから、開発チーム内でAmazon Q Developerをどのように活用されているかについての素晴らしい事例をご紹介いただきます。
ここで状況を整理させていただきますと、皆様もこのような統計をご覧になったことがあるかと思います。特にGenerative AIの登場以降、開発者の生産性向上が重要なテーマとなっていることは周知の事実です。しかし、生産性の向上はコードを速く書くことだけではありません。週に1時間未満しかIDEで作業していないという統計があるように、開発者がエラーに遭遇した際の対処法や、問題を理解するためのメトリクスの分析、そして組織やチーム、ビジネスに適したソリューションを見つけ出す方法を考慮する必要があります。私たちが開発の一環として目指しているのは、この方程式を反転させ、開発者により多くの時間を還元し、創造性とイノベーションを可能にすることです。
従来のソフトウェア開発ライフサイクルには改善の余地があることは明らかです。現在のプロセスでは、開発者がコードを書き、デバッグに多大な時間を費やす必要があります。ユニットテストの作成、セキュリティスキャン、組織内で既に解決されている可能性が高い問題の解決など、反復的なタスクに時間を取られ、生産性が妨げられることがよくあります。今日の要求に応えるためには、ソフトウェア開発プロセスを根本的に変更し、より広い組織に開発生産性をもたらすことに注力する必要があります。
これは、多くのお客様や組織にとって、そしてAmazon社内でも、まさに変革の時期です。私たちは、単にIDEでコードを書く個人プレイヤーとしての開発者の生産性だけでなく、開発生産性全体をどのように考えるかについて検討しています。 Amazon Q Developerは、開発体験全体を変革する最初のステップだと考えています。今朝Matt Garmentが発表した、よりエージェント的なワークフローへの移行や、ユニットテスト、ドキュメント作成、その他の機能に関する新しいエージェントの導入など、興味深い発表についてお聞きになった方もいらっしゃるかもしれません。
Amazonの開発アプローチとAmazon Q Developerの進化
振り返ってみると、私たちが最初にAmazon Q Developerをローンチした際、社内のAmazonの開発チームに実験的に使用してもらいました。彼らは、この新しいテクノロジーを活用して生産性を向上させ、開発プロセス全体から単調な作業を排除する方法を理解したいと考えていました。 Amazonにおける開発の特徴について簡単に見ていきましょう。それには、Leadership Principlesの重視、AWSクラウドとポートフォリオ内のすべてのサービスの広範な活用が含まれます。私たちは大規模な分散システムに焦点を当て、実験とイノベーションの文化を奨励しています。つまり、開発者はコスト効率と安全性を維持しながら、システムを素早く構築し、改善していく必要があるのです。
歴史について長々とお話しするつもりはありませんが、2001年当時のAmazonが1つのモノリスと1つのデータベースで構築されており、機能の更新や新商品の追加といった小さな変更でも11時間もかかっていたという話はご存知かと思います。私たちは、各チームの担当範囲を狭めつつ、責任を増やすという形でこれらの異なるパーツを分割するというアイデアを持っていました。ご存知かもしれませんが、これがTwo-pizzaチームというコンセプトです。
このコンセプトは、 チーム内のこれらのパーツを、2枚のピザで食事が足りる程度の小規模なサイズに分割するというものでした。チームはアプリケーションのAPIに沿って編成され、 アプリケーションのエンドツーエンドを担当することになりました。これを私たちはService Oriented Architecture、つまりMicroservicesと呼んでいます。現代では、開発とアプリケーションの運用の両方をチームが担当するDevOpsという言葉が適切でしょう。
当時のAmazonにとって、市場投入までの時間が本当にNorth Star（指標）であり、ビジネスや組織として達成したいことでした。そこで私たちは、まず人に関する決定を行い、次にそれをサポートするための技術的な決定を行いました。これは、Microservicesの開発ライフサイクルという形で具現化されました。年間を通じて複数のリリースサイクルを持つこれらのアプリケーションの運用方法は、他の多くの組織とは大きく異なっていました。
問題は、こんなに頻繁にリリースを行う開発チームをどのようにサポートするか、安全性とセキュリティ、品質をどのように維持するかということでした。Amazon Q Developerを導入する際、私たちはAmazonでの開発の特殊性を維持しながら、どのようにメリットを得られるかを真剣に考えました。開発チームからは、Amazon Q Developerは良いものの、Amazonの独特な開発方法にはまだ十分に適していないという意見がありました。基本的に、2つの課題が浮き彫りになりました。 この AI-powered コーディングと開発支援の文脈で、私たちが話をする機会を得た多くのエンタープライズ企業やスタートアップ企業でも、同様の課題が繰り返し見られています。
課題の1つは、ドメイン固有の知識をどのように考えるかということです。異なる業界、異なる組織、異なるプロジェクトには、それぞれ独自の特定の知識やコーディング規約、ベストプラクティス、ライブラリ、フレームワークがあります。AIアシスタント、つまりコンシェルジュを、テクノロジースタック内のさまざまなサービスと連携するようにカスタマイズすることで、開発者や開発チームのニーズに合わせた、より正確で適切な提案が可能になります。カスタマイズによって、関連性と生産性を向上させ、組織固有のセキュリティやメトリクスの計測方法に悩まされることなく、開発者がコーディングに集中できるようになると考えています。
これらの標準の多くは、パブリック情報で学習された汎用的なパブリックLLMから離れ、組織固有のプライベートリポジトリを参照することで、組織の標準やベストプラクティスを確実に成文化できます。特定のスタイルガイドやコーディング標準、推奨プラクティスを確立するだけでなく、プロジェクト固有の要件についても考慮する必要があります。開発チームのためにAIパワードアシスタンスの体験をどのように進化させるかを考える際、社内のプラクティスとの一貫性を確保したいと考えています。組織だけでなく、特定のビジネスやチームのために用意された特定のライブラリを使用する必要がある場合、オンラインのコーディングコンパニオンやチャット体験からの提案においても、それを強化する必要があります。
Amazon Q Developerのカスタマイズ機能と管理者の役割
Amazonの開発チームと協力して、この新しいテクノロジーを活用しながら、いかにして開発の流れを維持し、煩わしい作業を削減できるかを検討する中で、Amazon Q Developerでその体験を進化させることを考えました。問題設定が終わったところで、Amazon Q Developerについてより具体的にお話しするために、Software Development担当ディレクターのSriniに引き継ぎたいと思います。ありがとう、Jess。始める前に、手を挙げていただきたいのですが、Amazon Q Developerを実際に使用または試したことがある方は何人いらっしゃいますか？使用された方の中で、カスタマイズを試された方は何人いらっしゃいますか？このセッションが終わる頃には、Amazon Q Developerの機能と、私たちがサポートするカスタマイズについて理解していただけると思います。Jessが話したように、Amazon Q Developerはコーディングだけに特化したものではありません。
Amazon Q Developerが進化してできるようになったのは、ソフトウェア開発ライフサイクル全体にわたるさまざまなタスクと問題を解決することです。Amazon Q Developerが重点を置いているのは、構築と運用です。アプリケーションを構築し、設計し、テストを作成し、AWSにデプロイして、実際に運用を開始し、発生する問題をデバッグすることができます。
本日Matt Garmanが基調講演で発表した内容をご存知の方もいらっしゃると思いますが、私たちが発表した運用機能についてお話しします。アラームが発生した場合、Q Developerは Amazon CloudWatch Logs、Cloud Trail、X-Rayを確認し、さらにすべてのAWSリソースに関する知識も持っているため、根本原因を特定し、問題を特定して、提案まで行うことができます。これはAmazon Q Developerバンドルの一部です。もう一つの新機能として、IDE内およびGitLabでテスト、ドキュメント、コードレビューを行うためのQエージェントを発表しました。GitLabとのパートナーシップは本日発表したものです。
Q Developerの考え方について見ていきますと、DevOpsのフェーズ、IDEでの開発フェーズ、そしてAWS Consoleでの管理フェーズがあります。Q Developerはモバイルフォンでも、AWSのドキュメントサイトでも利用できます。現在AWSドキュメントでQと対話すると、実際にはQ Developerが質問に答えています。これらはすべて、AnthropicモデルやMeta、Cohereのモデル、そして私たち独自のモデルなど、様々な大規模言語基盤モデルを持つプラットフォームであるBedrockの上に構築されています。また、BedrockにおけるAmazon独自の基盤モデルNovaに関する新しい発表もありました。私たちはAmazon Q全体を構築するためにBedrockを使用しています。
これらはすべて、パブリックデータセットで学習された大規模言語モデルを使用しています。IDEでQ Developerを使用してコーディングする際、プロジェクトのコンテキストを活用します。リポジトリを開いている状態でQ Developerと会話し、コードベースの説明を求めることができます。単体テストの生成を依頼すると、実際にリポジトリ全体のコードベースを確認してから生成します。同様にドキュメントについても、READMEファイルがある場合はそれを更新し、READMEマークダウンファイルがない場合は新規作成します。
これらは素晴らしい機能ですが、企業や大規模な会社・チームにとって、IDEだけでは十分ではないことにすぐに気づきました。IDEにない場所に存在する知識やプライベートライブラリ、IDEにダウンロードしていないリポジトリのコードなどがあります。そこで、 インラインコード推奨とQチャットの両方について、IDE内での応答をカスタマイズし始めました。カスタマイズにより、IDE以外のコンテキストも活用できるようになります。Amazon Q Developerをカスタマイズすると、すべてのコンテキストを使用し、インラインおよびチャットでのやり取りにおいて、ベストプラクティス、コーディングスタイル、コーディングパターンを提供するための追加知識を活用します。
カスタマイズを始めるにあたって、2つの異なるペルソナが関係します。ConsoleでQ Developerを実際に使用する開発者と、組織全体やチームのカスタマイズ設定を支援する管理者ペルソナです。これには、カスタマイズの作成と再トレーニングが含まれます。コードベースは常に変化し、静的なものではないためです。そのため、カスタマイズの再トレーニングのためにコードを再取り込みする必要があり、どのようなカスタマイズにアクセスしたいユーザーにプロビジョニングするかを決定します。例えば、組織内に複数のビジネスユニットやチームがあり、それぞれが独自のコードベースとベストプラクティスを持っている場合、異なるユーザーを対象とした異なるカスタマイズを作成できます。
組織内の開発者を管理する管理者が、チームのためにこれを設定できます。 カスタマイズの準備方法について、手順を簡単に説明させていただきます。現在、取り込み可能なコードとしてJava、JavaScript、Python、TypeScriptをサポートしています。数週間前には、チャットベースのカスタマイズと、すべてのMarkdownファイルやREADMEファイルを活用する機能の一般提供を発表しました。カスタマイズのために取り込むコードベースにREADMEやMarkdownがある場合、そのコンテキストもコード推奨に活用されます。
管理者が覚えておく必要があるリポジトリサイズの制限があります。コードベースを取り込む際、画像やPNGファイルなど、コード以外のものは無視します。というのも、これらはカスタマイズには使用しないからです。これは私たちが構築した検索システムではありません。対象言語と望むカスタマイズ方法を決定したら、次に管理者が行うべきステップはカスタマイズの作成です。 IDCでセットアップされている場合、管理ポータル（Amazon Q Developerには管理ポータルがあります）にアクセスします。
IDEでAmazon Q Developerにログインして使用する方法は2つあります。1つ目はBuilder IDで、これは誰でも無料で使用できます。Builder IDでログインを作成するだけで、Q Developerを使ってコード推奨を受けたり、同じAgentを使用したりできます。2つ目は多くの企業が採用している方法で、IDC Identity Centerを使用してQ Developer内のユーザーを管理する方法です。管理ポータルには、いくつかの重要な設定があります。1つ目は参照付きのコード提案を含めるかどうか、そして3つ目は暗号化キーです。
参照付きのコード提案を含めるという機能は、AmazonとAWSの全員にとって、Responsible AIの一環として非常に重要です。大規模なパブリックオープンソースデータセットで学習したモデルを使用しているため、モデルが類似したコードを生成した場合、オープンソースリポジトリへの参照を付与します。これは、ライセンスと帰属に関して企業にとって重要です。管理者として、推奨からそのようなコードを完全に除外するか、問題ないと判断した場合は有効にして、開発者がIDEで帰属情報を確認できるようにするかを決定できます。
暗号化に関して、コードを取り込む際、それは常にお客様独自のVPC境界内に存在し、まずAmazon独自のキーで暗号化されます。お客様独自のCustomer Managed Keyを使用して、常に暗号化されるように設定することもできます。これは私たちが推奨するベストプラクティスです。初期設定を決定したら、 GitHub、GitLab、Amazon S3など、さまざまなソースからコードを取り込むことができます。数週間前にコードカスタマイズとチャットカスタマイズを一般提供開始した際、特定のリポジトリを選択できる機能も有効にしました。
開発者視点でのAmazon Q Developerの活用と成果
コードを取り込んでカスタマイズを開始すると、 評価タスクが実行されます。取り込んだコードに基づいて評価を行い、評価用のコードを分離して、評価スコアを提供します。評価スコアは1から10の範囲ですが、10を見たことはありません - それは誰かが完璧なコードを書いたことを意味するからです。内部のカスタマイズでも、やや低いスコアになっています。黄色の範囲は決して悪くありません。内部でカスタマイズを始めた当初、緑の範囲を見ることはなく心配していましたが、黄色の範囲でも非常に良いコード提案が得られることがわかりました。これにより、どのようなコードスコアを期待できるかの指標が得られます。
スコアが低い場合は、より良い結果を得るためにより多くのコードを取り込む必要があります。基本的に、開発者に対して取り込んだコードと同じくらい良いコード提案を生成するように指示することが目的です。つまり、管理者としては、カスタマイズのためにどのようなコードを取り込むべきかを見極める必要があります。ここで、先ほど説明した手順（作成、取り込み、そしてスコアの取得）のビデオを簡単にお見せしましょう。
S3への直接接続があり、さらにCodeStar接続もあります。GitHub、GitLab、BitbucketへはCodeStar接続を使用して接続します。 この例では、まずCodeStarを使用してGitHub接続を確立しています。そして、これらはAWSユーザーとしてAWSでアプリケーションを管理している場合によく見かけるエンティティです。 リソースにタグを付けたり、CloudWatchでログを取得したりできます。これらはすべて演習の一部として提供されているので、管理者は自分の好みに応じてリソースを管理することができます。
これが私が説明していたスコアで、取り込みが行われた後にジョブが開始されます。しばらくするとスコアが表示されますが、カスタマイズはすぐには有効になりません。最大8つのカスタマイズ、つまり8つのアクティブなカスタマイズを得ることができます。カスタマイズを微調整するために何度も作成を続けることができ、更新すると既存のカスタマイズも更新できます。その後、管理者がどのカスタマイズを有効にするかを決定できます。
では反対側の視点から見てみましょう。カスタマイズが作成され有効化された後、誰がこのカスタマイズにアクセスできるのでしょうか？ ここで管理者がユーザーへのプロビジョニングを行います。事業部門ごとに異なるアクセスパターンがあり、異なるユーザーに異なるカスタマイズを割り当てることができます。リソースセットでは、8つのカスタマイズのうち2つのアクティブなカスタマイズを計画することができます。ユーザーが有効化されると、管理者向けのEnterprise Dashboardも提供されます。
ここでは、組織内でAmazon Q Developerがどのように使用されているかを確認することができます。これには2つの方法があります：すべてのデータはCloudWatchで取得でき、そこで独自の洗練されたダッシュボードを作成できます。それに加えて、開発者がAmazon Q Developerを使用してテストを作成した回数、スキャンやコードレビューを通じて問題を発見した回数、どのようなコードの問題が修正されたか、Amazon Q Developerとチャットした回数、どのような応答があったかを実際に表示するUIを提供しています。これらすべてが管理ダッシュボードで管理者として確認できます。また、カスタマイズに基づいてフィルタリングを行い、カスタマイズの有無による受け入れ率を確認することもでき、管理者としてどのユーザーがそれを行っているかも確認できます。
これらはすべて完了した管理タスクです。管理者が開発者にアクセス権を付与するまでには、まだしばらく時間がかかります。これは、AWSがAmazon Q Developerの利用状況を確認し、組織全体でAmazon Q Developerを使用する準備が整った後の話です。ここからが、実際にAmazon Q Developerから価値を引き出す本当のペルソナ、つまり開発者の出番となります。まず、追加のコンテキストを使用するカスタマイズは、チャットとインラインコードの提案の両方で利用可能です。ここで何が起こるのか、簡単にご説明しましょう。 カスタマイズは私たちが選ぶのではありません。開発者として - ここでは管理者ではなく開発者としての皆さんにお話ししていますが - IDEで管理者が特定のカスタマイズを設定した場合、どのようになるかをお話しします。
開発者として、自分がアクセスできるカスタマイズを確認し、使用するカスタマイズを選択することができます。私の場合、チームが有効にしてくれた3つのカスタマイズがあります。1つ目は自分のチームが管理するコードベース、2つ目は自分のチームが管理するコードベースに加えて、作業している別のリポジトリに関連するライブラリ、そして3つ目はAmazonのコードベース全体に基づいています。開発者は、作業しているコードリポジトリやタスク（単体テストの作成やプルーフオブコンセプトの作成など）に応じて、カスタマイズを切り替えます。
最初のコード提案は、タイタニック映画に関する単純なコメントで、デフォルトのカスタマイズなしのケースです。これは大規模言語モデルとAmazon Q Developerが行うのとまったく同じように生成されますが、これは私たちのコーディング標準やライブラリで定義されているプロパティとは異なります。 そこで、私たちは異なる方法で実行したいと考えています。このビデオでは、デフォルトの一般的なAmazon Q Developerではなく、実際のカスタマイズを選択し、同じコメントを提供します。 すると、コードの生成方法が異なることが明確にわかります。なぜなら、カスタマイズに使用されている組織の標準に従っているからです。
Amazonでは、 全社で約8万人の開発者がAmazon Q Developerを使用しています。Prime Videoをはじめとする各チームが、それぞれのユースケースに合わせてAmazon Qをカスタマイズし始めています。インラインコード提案の受け入れ率は、全プロバイダーの中でも業界標準をリードする35〜37%に達しています。しかし、カスタマイズを開始すると、Prime Videoチームの受け入れ率は50%まで上昇します。彼らは、より関連性の高いコードが生成され、書き直しの必要性が減少し、アプリケーションの構築をより迅速に開始できることを実感しています。カスタマイズやコードレビューなどの機能により、Prime Videoのようなチームは、コードの生成や単体テスト生成の多くの手動ステップが削減され、全体的な生産性が最大60%向上することを実感しています。
これは社内のユースケースに過ぎません。さらに興味深いのは、Amazon以外の外部のお客様がAmazon Qやカスタマイズなどの機能を使い始めた場合です。私たちが協力しているパートナーの1つが、National Australian Bankです。NABでのAmazon Q Developerとカスタマイズの具体的な活用方法については、Paulにお話しいただきましょう。
National Australia BankにおけるAmazon Q Developerの導入事例と教訓
ありがとうございます、Srini。皆様、こんにちは。National Australia Bankのクラウド担当エグゼクティブのPaul Roneyです。NABでクラウドとネットワークを担当しています。 NABは160年以上の歴史を持つ金融機関で、オーストラリアの4大銀行の1つです。NABには、オーストラリア、インド、ベトナムに数千人の開発者がいます。NABについて興味深い点として、アプリケーションの84%がクラウド上で稼働していることが挙げられます。私たちは完全にクラウドファーストな企業であり、2017年から2018年にかけて戦略を転換しました。クラウドは、NABの業務や活動の基盤として不可欠な要素となっています。現在84%に達していますが、さらにクラウドの採用を進めています。私たちは開発者体験をさらに向上させ、生産性を高める方法を模索することに強い関心を持っていました。Generative AIがその実現に大きく貢献できると考え、その取り組みを開始しました。本日は、アプローチ、スケーリング方法、成果、そして得られた教訓などについてお話しさせていただきます。
では、どのように始めたのでしょうか？ 最初は35〜40人程度の小規模なユーザーと開発者グループからスタートし、Amazon Qの価値を見極めるためにデータ主導のアプローチを取りました。Sandboxを設置して小規模なProof of Conceptを実施し、私たちが想定していた効果や、開発者体験と組織の生産性への価値について検証を始めました。
その後、本番環境以外に移行し、ユーザー基盤を約70人の開発者に拡大し、Sandbox環境ではなく本番環境以外のコードを使用して、組織における価値提案をさらに定量化し検証しました。この段階で、ビジネスケースやロードマップ、アプローチを改善しました。また、多くのセキュリティ上の考慮事項や管理上の検討事項に対処する必要がありました。DLPなど、組織にとって適切かつ安全な方法で実装するために必要な重要な要素について検討する必要がありました。
その後、本番環境に移行し、約450人の開発者へのスケールアップを開始しました。オーストラリア、インド、ベトナムに数千人の開発者がいる中で、適切なトレーニングが非常に重要だと分かりました。Amazon Qは直感的に使えるツールですが、AWSとのパートナーシップを通じて開発者向けの集中トレーニングを実施することが有益でした。開発者たちは長年特定の方法で作業してきましたが、Amazon Qによってもたらされる変化を実感し、理解することができました。
その後、Amazon Qを使用する開発者を約1000人にまで拡大し、今年後半には2800〜3000人程度まで拡大する予定です。約4ヶ月かけて、450人から1000人のエンジニアへとスケールアップしました。成果について少しお話しすると、開発者へのアンケートでは、87%がAmazon Qを同僚に推薦すると回答し、NPSスコアは高い結果となりました。ご覧の通り、コード提案の50%が開発者に採用され、41%が生産性と効率性の向上に役立っていると回答し、45%が本番環境に送るコードの品質向上に役立っていると回答しました。これは素晴らしい結果です。なぜなら、私たちのお客様や同僚が使用する高品質なコードを目指しているからです。
彼らが見出した価値について触れておく価値があります。多くの開発者が、まず第一に関数をより速く書けることに価値を見出したと言っています。これが製品の価値を最初に実感したポイントでした。また、Unit Testをより速く書けること、ソリューションの構築をサポートしてくれること、よりスマートな提案が得られること、そしてより良いドキュメンテーションが得られることも重要でした。National Australia Bankではプレビュー版を使用していますが、特にフレームワークを使用する領域でカスタマイズ機能を活用しています。クラウド利用率が84%であることから、多くのアプリケーション開発を行っており、NABでアプリケーションやサービスを構築する際に使用するフレームワークが、カスタマイズ機能のプレビューを活用している2つの主要な領域です。それらのアプリケーションやサービスを構築している他の開発者に提供するため、最適なリファレンス実装と最適なリポジトリを探してきました。幅広い利用基盤があり、大規模なグループに影響を与えられる最適なリポジトリとフレームワークを選定するよう努めています。
カスタマイズのプレビューについては、今後さらにグループ全体に展開していくことを楽しみにしています。最後に触れておきたいのは、Code Scanningも活用していることです。これはセキュリティの観点からも役立っており、開発者がコードを書く際にセキュリティについて考えるための視点や手軽な方法を提供してくれています。
ここで、私たちが学んだいくつかの教訓についてお話ししたいと思います。最初の一つは、先ほども触れましたが、開発者に利用可能な機能を十分に理解してもらうための研修が重要だと感じたことです。開発者のリズムと習慣の一部として取り入れ、最初の段階で十分な機会を提供することが非常に重要でした。また、体験の質が非常に重要だということも分かりました。私たちが直面した課題の一つは、ある時期に開発者へのレスポンス時間に遅延が生じたことです。ご存知の通り、開発者は遅延があると興味を失いやすく、利用率が低下してしまいます。そのため、統合ポイントやテクノロジー、遅延、開発者の体験について十分に考慮することが重要です。
次に重要だと考えたのは、スケールを考慮したユースケースです。私たちには様々なユースケースがあります。まだクラウドへの移行を進めている最中で、私のチームはAmazon Qを積極的に活用して移行作業を行っています。移行作業においては様々なことができます。これまでにJava 8からJava 17へのアップグレードなど、コード変換の例もありました。これらのユースケースについて、ワーキンググループを立ち上げることが非常に有効だと分かりました。開発者のグループがAmazon Qのユースケースについて一緒に考えることで、より良い成果が得られるからです。
プレビューカスタマイズで導入したフレームワークを検討するグループもあれば、技術の移行や言語のアップグレード、パッケージのアップグレードを検討するグループもあります。これは既製のアプリケーションも使用しているためです。これらのユースケースについて考えることで、スケールアップが容易になり、トラクションを得ることができ、製品を使用することで素晴らしい成果を得ることができます。今日お話ししたかったのは以上ですが、Amazon Qを使用して、興味を持ち、好奇心を持って取り組んでいただきたいと思います。私たちは、Amazonが今日発表した新機能や、運用面に関する発表、その他の言語に関する発表などを楽しみにしています。
素晴らしいストーリーでしたね。私たちは、コーディングコンパニオンをどのように始めるか、開発体験を本当に変革することから始めました。皆さんには独自の機密情報や、組織固有のプラクティスがあることを私たちは理解しています。そして私たちが実現したいのは、皆さんにAmazon Qを使って自由に試していただくことです。皆さんの組織や顧客に特化したものを、Amazon Qを使って何を構築できるのか、とても楽しみにしています。ご参加いただき、ありがとうございました。また近いうちにお会いできることを楽しみにしています。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion