re:Invent 2024: GitLabとAWSがAmazon QとDuoで開発者の生産性向上
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - GitLab Duo with Amazon Q: AI-driven DevSecOps for your SDLC (DOP204)
この動画では、AWS と GitLab の新しいパートナーシップにより実現する Amazon Q と GitLab Duo の連携について解説しています。開発者の54%が14以上のツールを使用している現状に対し、Software Development Life Cycle 全体を通じて AI エージェントを活用することで開発者の生産性を向上させる取り組みを紹介しています。Amazon Q Developer Agent による機能開発支援、コードレビュー、メンテナンス作業の効率化など、具体的なデモを交えながら、開発者が創造的な作業により多くの時間を費やせるようになる未来像を示しています。また、人類の進化における知識と知恵の民主化の次に来る「分析の民主化」という観点から、AI による開発支援の意義についても言及しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
GitLab DuoとAmazon Qの連携：ソフトウェア開発ライフサイクルへのAI適用
おはようございます。昨日の発表に基づいてすべてのセッションのタイトルが変更されましたので、皆さんが意図したセッションに参加されているといいのですが。正しいセッションにいらっしゃる方は手を挙げていただけますか？ 素晴らしいですね。それでは始めましょう。本日は、昨日のキーノートで発表された、GitLab DuoとAmazon Qのパートナーシップと連携についての続きをお話しします。ソフトウェア開発ライフサイクル全体へのAIの適用についてお話ししていきます。
私はRory Richardsonです。AWSに約12年在籍しており、この間に素晴らしい変化を目の当たりにしてきましたが、生成AIが技術とイノベーションに与える影響ほど、ゲームチェンジングな変化はありませんでした。本日は私のパートナーのEmilioも参加しています。自己紹介をお願いできますか？
皆さん、お集まりいただきありがとうございます。GitLabのVP of Developer Relations StrategyのEmilio Salvadorです。Roryとはかなり前から一緒に仕事をしており、実は以前AWSで一緒に働いていました。本日皆さんと一緒に、私たちが取り組んできた素晴らしい成果を共有できることを大変嬉しく思います。皆さん、こんにちは。私はQ Developerのgo to marketをリードしています。この18ヶ月は本当にあっという間でした。本日はここにいられて嬉しく思います。
生成AIがもたらす開発者の生産性向上
それでは始めましょう。最初のスライドでは、共通認識を持つために少し前置きをさせていただきますが、正しいセッションに参加されている方々には、あまり詳しい説明は必要ないかもしれませんので、手短にしたいと思います。2022年11月にChatGPTがローンチされた時、私はそれを無視した一人でした。友達は必要なかったし、俳句を書く必要もなかった。理解できなかったんです。なぜこれを気にする必要があるのか疑問に思いました。
新しい技術に出会うたびに、私は息子に意見を聞くようにしています。子供に聞くと、本当に正直な答えが返ってくるからです。そこで2023年2月頃、息子に「ChatGPTを使って宿題をやってみない？」と聞いてみました。自然言語インターフェースを使って、彼が何をするのか、どのように関わっていくのかを見てみたかったのです。息子の宿題を見た後、私たちが何をすべきなのかが突然理解できました。
私の息子は文章を書くのが苦手なんです。それは母親譲りかもしれません。彼から返ってきた文章は、この子が今まで書いたどんな文章よりも創造的で複雑なものでした。確かに文法的には正しく、段落も意味が通っていましたが、それが興味深いポイントではありませんでした。興味深かったのは、その複雑さと、物語の中での思考の完成度でした。私は突然気づいたのです。意図から始めて抽象化のレイヤーを強化できれば、あなたが望むものから作りたいものへのインターフェースを、まったく新しいダイナミックな方法で実現できるということを。
これは先日の息子の写真です。彼が私のところに来て「ママ、ブリーフケースをもらえない？」と言ったんです。私はすぐに「ついに私の子らしいことを」と思いましたが、違いました。彼はラップトップを作りたかったのです。彼はハードウェア好きの子で、近所の人のためにずっとコンピューターを組み立ててきました。そのため、彼の部屋にはたくさんの予備部品がありました。これが彼が作ったラップトップです。ファンに注目してください - 特に役に立ちませんが、これが彼の初めてのラップトップでした。私の息子はクラウドを使うことも、コーディングを学ぶことも拒否していますが、少なくともLinuxはインストールします。彼は14歳です。
開発者の視点から見ると、AWSでは常にお客様を起点に考えて後ろ向きに進めていくので、開発者に何が一番好きかを聞いてみました。ほとんどの開発者はドキュメント作成が大好きです。実際、コードが古ければ古いほど、ドキュメントは良くなります。Unit testも - いくらあっても足りません。セキュリティレビューやプロジェクトの最後になって書き直しが必要だと気づくこと - 最高です。誰だって他人のごちゃごちゃを片付けたいので、古いコードのメンテナンスも大好きです。
私は東テキサス出身で、兄はシェルドンのような人でした。私が兄にデバッグや何かの構築を手伝ってほしいと頼むたびに、妹を手伝えることにとても興奮していました。そのため、開発者が非開発者と話をして物事を説明する機会があると、彼らはそれを楽しんでいます。
明らかに、Software Development Life Cycle（SDLC）全体を通して多くの摩擦があります。今日ここにいる方で開発者の方はどれくらいいますか？素晴らしい。たくさんの面倒な作業がありますよね。私たちが発見したのは、Generative AIとこれらのツールの適用が、その面倒な作業の一部を取り除くのに役立つということです。GitLabが最近行った調査では、開発者の54%が毎日SDLCで14以上のツールを使用していることがわかりました。これは多いですね - 学ぶことも、統合することも、面倒な作業もたくさんあります。 もし私たちが未来を創造し、イノベーションとテクノロジーへのアクセスを民主化し加速させたいのであれば、まずはこの面倒な作業から始める必要があります。
開発者が思われているほどIDEで時間を費やしていないことが分かっているため、生産性を向上させる余地は十分にあります。Gartnerによると、開発者が新規コードを書くためにIDEを使用する時間は1日1時間未満、つまり週に4〜5時間程度だということです。私たちは2023年4月に、当時CodeWhisperとして知られていたものをローンチしました。しかし、開発者の生産性に関する議論を本当に変えるためには、開発全体の生産性に取り組む必要があることにすぐに気づきました。コード生成から始めたのは、それが基盤となったからです。なぜなら、Amazon Qを活用して生成AIをプログラミング言語に適用したとき - プログラミング言語は形容詞のない非常に規則的なものだったため - 指数関数的な結果が得られることが分かったからです。
問題は、そこで止まってしまうと、週4〜5時間の生産性にしか影響を与えられないということです。残りの35時間はどうするのでしょうか？昨日のKeynoteでの発表でご覧いただいたように、私たちはAmazon Q Developerの適用範囲をソフトウェア開発ライフサイクル全体の他の側面にも拡大しています。そのためには、開発者が実際に作業している場所で支援する必要があります。Matt Garmanが基調講演で発表した3つのエージェント - ドキュメンテーション/ドック/テストとレビュー - は、開発者がゾーンに留まり、コード作成における差別化されていない重労働をエージェントに任せることを可能にする自律型エージェントです。
開発者が作業している場所で支援するという点について、IDEでの作業も可能ですが、実際に成果を上げるために必要な他のツールもあります。IDEにプラグインを組み込むところから始めましたが、これからはAmazon QがAWSでの作業体験全体にわたって遍在することになります。私たちはGitLabと協力してAmazon Qを統合し、より良い相乗効果を生み出そうとしています。これにより、お客様や開発者がスケールでイノベーションを起こし、チームがより良いコードを提供できるようになります。
2023年に分かった特に興味深いことの1つは、McKinseyがコード生成の測定方法について述べたことです - それは受け入れ率、つまり開発者が「はい、このコードは本当に良いので使用します」と言う回数で測るというものでした。しかし、これは単にその瞬間だけの話なので、全体像を語っているとは言えません。先ほど申し上げたように、残りの35時間についてはどうするのでしょうか？そこで、これらのツールの効果を測定する他の方法を検討し始めました。例えば、コードが少なくなれば素晴らしいと考えました。
また、コードレビューの回数を減らせないか、あるいはコードレビューを行う際に単体テストがすでに完了していて、セキュリティの脆弱性が少なくなっているという状態を実現できないかということも検討しました。Amazon Qに関するこれらの発表をご覧いただく中で、私たちは他のツールとの統合が必要だということを十分理解しています。それこそが、Emilioと私がAmazon QとGitLabの連携に取り組み始めた理由なのです。
GitLabとAmazon Qの統合：DevSecOpsプラットフォームの進化
おはようございます、皆さん。私たちはしばらく一緒に仕事をしてきましたが、開発者は誰もが複数のツールを使用しているという現状があります。私たちのアプローチは、これに対して少し異なる方向性を持っています。私たちは開発者に、ソフトウェア開発ライフサイクル全体を管理するエンド・ツー・エンドのプラットフォームを提供しています。プランニングの最初の段階から、アプリケーションのデプロイまで、全てをカバーしています。これには当然、多くのメリットがあります。GitLabに入社する前の私の日常では、リポジトリ用、ユニットテスト用、品質管理用、コントロール用、モニタリング用など、数十個の異なるツールを使用していました。
私たちの価値提案は、市場でも最も包括的なDevSecOpsプラットフォームを持っているという事実に基づいています。実際、この分野では私たちがリーダーの立場にいます。このプラットフォームは、ソフトウェア開発ライフサイクル全体を通じて開発者をサポートします。あるツールから別のツールに切り替える時間を費やす必要がありません。最後に、アプリケーションを最初から開発して、一発で全てが上手くいったのはいつですか？アプリケーションをデプロイした時に問題を見つけませんでしたか？パフォーマンスの問題だと分かりましたか？そして突然、何が起きたのかを理解しようとして迷宮入りし、そのうちの1つのツールがアップグレードされて、インターフェースが機能しなくなったりしませんでしたか？
私たちは物事を動かすことだけに、驚くほどの時間を費やしています。振り返ってみると、1日のコーディング時間はたった1時間で、時にはその1時間さえも、本当に重要なことに使われていません。他人のコードを理解しようとしてリファクタリングや書き直しをしているだけです。私たちが本当に信じているのは、AIの力はIDEでの適用だけではなく、アプリケーションがデプロイされる時だけのものでもないということです。AIとエージェントの真の力は、ソフトウェア開発ライフサイクル全体を通じて使用される時に、開発者の体験を本当の意味で変革するのです。
この協業が私たち一人一人にもたらすものは、ただ一つの考えに基づいています：私たちが最も好きなこと、つまり実際の問題のコーディングに時間を費やし、創造性を発揮してビジネス上の問題に対するソリューションを見つけることに、私たちの時間と知性と脳力を使えるようにすることです。AIは、ソフトウェア開発ライフサイクルの各ステップでツールがどのように役立つかを考えた時にのみ意味を持ちます。何かを計画する瞬間から、アプリケーションのコーディングを始め、セキュリティについて考え、テストについて考える時まで、これら異なるステップ全体で何が起きているかを完全に理解しているエージェントが必要なのです。
途中の全てのタスクに対して20人のアシスタントを配置することを想像してみてください。それらの間の関連付けをするだけでも、自分で作業するよりも多くの時間がかかってしまうでしょう。私たちは、単に反応的なものから、バックグラウンドで動作して新しい体験を生み出し、時間を節約できるプロアクティブなものへと移行しています。これこそが私たちが目指していることです - 時間を節約し、ソフトウェア開発を加速させ、人々に考える時間を与えること。これは私の場合、最も恋しく感じることの一つです。私たちは超多忙で、走り続けています。時には何のために走っているのかさえ忘れてしまいます。一歩下がって、目の前の問題を見つめ直し、正直に言って創造的な方法でそれらの問題を解決する時間が必要なのです。
これは私たちが長い間一緒に取り組んできたものです。 昨日発表したのは、プレビュー版です。これは journey の始まりに過ぎません。今日から皆さん一人一人がテストできる、ソフトウェア開発の方法を変革する新しいAgentのセットをご用意しています。
これは、Dedicated版とSelf-Managed版のどちらを使用しているAWSやGitLabのお客様でもご利用いただけます。なぜこれが皆さん一人一人にとって重要なのでしょうか？ まだGAではないものを試す時間をなぜ使うのか、と思われるかもしれません。それは、この先に何が来るのかを垣間見ることができるからです。Agentがどのようにしてソフトウェア開発を加速させ、アイデアをコードに変換し、プロジェクトの立ち上げを支援できるのかを体験できます。
また、GitLabの強みを今お使いの環境にもたらします。プラットフォームにすでに組み込まれている当たり前の機能である、Security、Quality、Complianceなどです。これらは多くのビジネスにとって重要な要素ですが、時として忘れがちです。これらをプロセスの一部として組み込みたい、ただ動いて、そこにあってほしいと思うはずです。そしてそれらが確実に実行されるよう支援してくれるAgentが必要なのです。そして最後に、最も重要なのは、開発者の作業環境を尊重しているということです。これらの機能をいつ、どこで活用するかは、皆さんが選択できます。
IDEを多用する開発者もいます - Visual Studio Code、JetBrains、あるいは私たちのWeb インターフェースを使用できます。Web IDEも使えます。ここでの目標は、皆さん一人一人に最適な環境を見つけ、私たちが提供する新しいツールの恩恵を最大限に受けられるようにすることです。これはjourneyです。これは始まりに過ぎません。これはAgentのプレビューであり、さらに多くの機能が追加される予定です。ぜひご期待ください。
Amazon Q Developer Agentのデモ：機能開発からコードレビューまで
そして、両方のエンジニアリングチームが協力して取り組んできた素晴らしい成果と、新機能の価値をどのように活用できるかをお見せする時間を設けたいと思います。ありがとうございます、Emilio。私の冒頭の説明でも触れましたが、この18ヶ月は瞬く間に過ぎましたが、非常に有意義な期間でもありました。長い時間を経て、ようやく開発者の日常生活を実際に見つめ直す機会を得ることができました。では、DevOps ワークフローとAmazon Q自律型AIエージェントを統合したソリューションのデモに移らせていただきます。
さて、その前に、Roryが言及したDevOps調査での経験について触れないわけにはいきません。個人開発者の54%が14以上のツールを使用しているという結果が出ています。ちょっと想像してみてください。SMSのための携帯電話、通話用の別の携帯電話、LinkedInのためのもう1台、そしてコードをプッシュするためのさらに別の端末。これは現実的ではありませんよね。開発者の選択であり、それぞれのツールが特定の価値を提供しているため、これらのツールが重要であることは十分理解できます。しかし、これは顧客環境におけるソフトウェア開発の実装において、非常に微妙な問題として現れてきます。
そして、個人開発者がこのような複雑さを生み出すわけですが、これが開発チーム全体に広がると、さらに複雑になります。そこには協力が必要で、複数の人が関わり、ベストプラクティスがあります。私たちのプレゼン資料では直線的なプロセスとして示されるSDLCの、そのすべてのあいまいさがそこにあります。クリエイティブな資料では円形のプロセスとして描かれることもありますが、そこにはループの中のループがあり、Inner Loopがあり、Outer Loopがあり、さらにInner Loopの中にもループがあります。これこそが、私たちが再発明し、再構築しようとしているものなのです。
そして、これらのループの中で2つのことが起こります。1つは開発者がクリエイティブな作業をすることです。私たちはナレッジワーカーですから、認めましょう。しかし同時に、同じ日の中で、私たちは開発の組立ライン作業員としても働いており、そこには単調な作業があります。幸いなことに、Generative AIやAIエージェントによって、その単調な作業を取り除くことができます。これが生産性向上の1つの側面です。生産性向上のもう1つの側面は、開発者として、1日中常に最も創造的な状態ではないということです。私たちはそれをFlow Stateと呼んでいます。そのFlow Stateでは、アイデアが頭からコードへ、キーボードへと魔法のように流れ込み、そこで賞を獲得し、認められるのです。では、その創造性をどのように解き放つのか。それは単調な作業を取り除き、クリエイティブなFlow Stateでの時間を延ばすことで実現できます。このコンテキストを念頭に置いておいてください。
では、最初のデモに移りましょう。機能開発のためのAmazon Q Developer Agentをご紹介します。これは今年初めに主にIDE体験として発表したものです。複数ファイルの機能構築、バグ修正、ユニットテストの作成、あるいはそのすべてを行うために設計されています。IDEは確かにそれを行える場所の1つですが、これを現在の開発ワークフローに組み込むとどうなるでしょうか？
開発チームがIssue管理システムで生活し、呼吸しているような世界を想像してみてください。そこで、お互いが何をしているのかを確認できるのです。これは単純なNext.jsのWebアプリケーションです。あなたは開発者として、サインアップフォームを追加するタスクを任されました。ちょっと5-10秒かけて、あなたならどうするか想像してみてください。私なら、まずワークフローについて考えるでしょう。Webアプリケーションに入って、プロジェクトを見て、コードを理解します。Issueを作成し、サインアップフォームのロジックについて考え始めます。ロジックには、ユーザー名とパスワードが必要で、既存ユーザーやパスワードの強度要件などのシナリオを考慮し、メインのホームページにどうリンクさせるかを検討します。
GitLabでは、Issue（課題）を作成し、最初の5-10秒で考えたことをすべて含めます。というのも、そのAgentに何をする必要があるのかを伝えなければならないからです。 そして、Issueの中で「/Q developer agent」というコマンドを実行すると、作業が開始されます。 処理が進むにつれて、生成AIがオープンソースに帰属するコードを作成した場合、そのコードの帰属情報が提供されます。 バリデーションやドキュメントが追加されていく様子をご覧ください。ファイルとページが作成され、そのコードがプロジェクトに統合されているのがわかります。プロジェクトのコンテキストとIssueのコンテキストを一度に取り込んでいるんです。
誰かがログ機能の追加を依頼してきたとします。 同じ場所で要件とコンテキストを追加し、再度Q developer agentを呼び出します。 つまり、Q developerを活用してどのように作業を進めるかを5-10秒考えるだけでよいのです。Issueの作成からマージ、リリースまで、自分が何をしたのか、同僚が何をしたのかが正確にわかります。すべてのコンテキストとトレーサビリティが、Issue管理システムの一箇所に集約されているのです。
お客様や開発者の中には、アプリケーション全体を自分で作れるのかと質問される方もいます。実際のところ、理論的には可能ですが、そのためには非常に複雑なプロンプトが必要になります。使用するツールに対する学習曲線と親和性が重要になってきます。ですので、Public Previewの製品を自由に試していただいて構いません。ちなみに、このAgentは世界最先端のものです。SWE benchのリーダーボードを見ていただければ、昨日の時点で、Q software development agentが検証済みリーダーボードでトップに位置していることがわかります。
では、コードレビューについて話しましょう。会場の皆さんにお聞きしたいのですが、コードレビューのプロセスは改善や効率化が可能だと思われる方は手を挙げてください。手を挙げた方々は、きっとコードレビューが大好きなんだと思います。コードレビューの重要性は誰もが理解していますし、なくなることはありませんが、より効率的に、より短時間で行うことは可能です。
コードレビューでは、2つか3つの相反する優先事項があります。まず、機能面、セキュリティ面、品質面から高品質なコードを確保したいという点です。レビュアーとして、組織のベストプラクティスやパターンを強調し、実装する責任があります。誰かがコードをチェックインしてコーヒーを飲みに行っても、ピアレビュアーが翌日まで見ないかもしれず、サプライチェーンの観点から見ると、これは付加価値のない時間となってしまいます。
先日、コードレビュー用の自律型エージェントを発表しました。このエージェントは品質の問題やセキュリティの脆弱性を検査し、最初のレビュアーとして機能します。個々の開発者にとって2つの明確なメリットがあります。若手開発者が間違いを犯した時、レビューで他人に指摘されたくないものです。このレビュアーは、他の人が見る前に、些細な詳細や軽微な問題をすべて取り除いてくれます。これはセキュリティのLeft Shiftと同様ですが、今回は品質の側面も加わっています。 GitLabのワークフローの文脈では、これは本当にプロセスを加速させます。
Merge Requestがあると、Amazon Qレビューエージェントが自動的に呼び出され、プロジェクトやIssueのコンテキストを含めてコードの分析を開始します。すぐに通過してしまいますが、Unit Testが不足しているという重大度の高い問題を特定しました。また、SQLステートメントを読み取り、SQL injectionの攻撃に対して脆弱な文字列連結を使用していることを検出しました。Stack Overflowで検索したり同僚に相談したりして40～50分を無駄にする代わりに、レビュアーが自動的に問題を特定し、代わりに修正することもできます。
これは単なる個人向けの機能ではありません。チーム全体がIssueのコンテキストにアクセスでき、何が起きているかを確認できるマルチプレイヤーのシナリオとして考えてください。開発者が長いコーヒーブレイクを取っている間に、別のチームメンバーが同じスペースからエージェントを呼び出して修正を実装できます。コードレビュアーの視点からすると、レビューを始める前にエージェントを実行して軽微な問題をフィルタリングし、コードの質の高い機能面に集中できます。これにより、小さなフィードバックループがなくなります。
次に、メンテナンスの成熟度モデルについて説明しましょう。以前、サプライチェーンの分野にいた時、予知保全や予防保全といった概念は60～70年前から存在していました。これらの概念はソフトウェア開発にも存在しますが、私たちはそれを意識していないことが多いのです。開発者は通常、Java 8からJava 17へのアップグレードのようなメンテナンス作業を好みません。創造的な仕事ではなく、単に必要なメンテナンスなのです。そのため、今年初めにAmazon Q Agent for Transformationをリリースしました。
Amazonの社内や顧客との間で大きな成功を収めていますが、幅広いフィードバックも得ています。変換ワークロードを並行して実行できるか、パイプラインに統合できるか、まず順序立てた計画を確認できるかという質問がありました。200万行のJavaモノリスを3時間かけて変換している間、何が起きているのかを知りたがりました。人間が常にループの中に残るため、変更の詳細なレポートやコードのレビュー機能を求めました。このコンテキストから、これは一つのアプローチですが、マルチプレイヤーの体験では実際にはもっと多くのものが必要だと認識しました。GitLabは一つの場所として機能しますが、マルチプレイヤーの体験では、DevOpsワークフローの中に位置づけた方が適切です。
メンテナンスの成熟度モデルの観点から、予測的メンテナンスや予防的メンテナンスではなく、継続的なメンテナンスについて考え始めましょう。今や継続的な管理の時代に入っています。完全にそこまで到達できているでしょうか？まだまだですが、これは刺激的な始まりなのです。
それでは、デモをご覧いただきましょう。 ここにJavaのレポートのプロジェクトがあります。Issuesの中で、Q Transformation Agentを起動します。IssueからすぐにGitLab内のネイティブ機能としてのAmazon Qがパイプラインを開始し、プランの作成を始め、各ステップを示してくれます。 そして最後に、Pull RequestまたはMerge Requestを作成します。その中身を見ると、すべてのパッケージの詳細が記載されています。 これは単にプログラミング言語AからBへの変換や、同じ言語の新しいバージョンへの更新だけでなく、依存関係やフレームワーク、その他のすべての要素も更新します。
更新された項目、更新の必要がなかった項目、完全に非推奨となった項目の一覧が表示されます。そして最終的に、プランを承認すると、パイプラインを通して実行されます。私が意図的に失敗したRunを1つ用意したのには理由があります。実際の運用でもこういったことは起こりえますし、これは問題設定の方法と、変更管理の本質的な側面に関係しているのです。
さて、私たちはテストに関する3つのユースケースも発表しました。ご指摘の通り、これは始まりに過ぎませんが、古いバージョンのJavaアプリケーションに新機能を追加しようとする実際のシナリオで、これら3つのユースケースを想像してみてください。同じIssue内でQ Transformsから始めて、反復し、ある地点まで到達したら、ソフトウェア開発機能を呼び出します。すべてのコンテキストを提供すると、プロジェクトとIssueのコンテキストを把握し、パイプラインで実行され、最終的にレビュープロセスに到達します。私たちは7、8個の異なるワークフローを、トレーサビリティとログを含む1つのワークフローにまとめただけです。7年後に誰かがそのBrownfieldコードを見ても、実際に何が起こったかを理解していなくても、エンドツーエンドのトレーサビリティを確認できるのです。
Generative AIの未来：知識の民主化から分析の民主化へ
素晴らしいですね。今日お話ししている多くのことは、私が開発者を続けなかった理由でもあります - 新しい問題解決方法を設計することほどクリエイティブではないと感じていたタスクです。正直なところ、私がコードを学んでいた時にこれらのツールが利用できていれば、今でも開発者として働いていたかもしれません。なぜなら、私たちの足かせとなり、歯車に砂を噛ませるような多くの作業が解消されるからです。
ここで視点を変えて、Generative AIの応用がどこに向かっているのか、もう少し哲学的な話をしたいと思います。これから話す内容は、このプレゼンテーションの中で最もテクニカルな部分になりますので、しばらくお付き合いください。人類の進化、特にこの100年の進化を考えると、私たちは互いに価値を見出すものや、情報の民主化の方法を根本的に変えてきました。これまでのところ、これらのテクノロジーが人々を完全に置き換えることはありませんでした。なぜなら、私たちが行う最も人間らしい、最も創造的な活動を再現することができなかったからです。しかし、定型的なタスクの処理については、大きな進歩を遂げてきました。
最初はデータがありました。データは存在していましたが、共有することができませんでした。そこで、情報を共有するために文字体系を作り出しました。文字体系ができた後、私たちは書かれたものをすべて集めて図書館を作り始め、同じテーマについて異なる視点から読むことができるようになりました。そしてそこから知恵が生まれました。私の経験では、ここ10年ほど、非識字率に関する寄付を求められたことはありません。知識は、ほぼ完全に民主化されたと言えるでしょう。
さらに、物事を暗記することは、もはや子どもたちの教育方法としては重要視されていません。実際、お子さんの携帯電話番号を言える人は、ここにいる方々の中でもほとんどいないのではないでしょうか。でも、自分が子どもの頃の電話番号は覚えているはずです。機械的な暗記は、もはや私たちが互いに、またはプロセスにおいて価値を見出すものではありません。そして正直なところ、それは知恵とも言えません。Wikipediaや学術論文にアクセスできる今、私は1週間もあれば様々な分野の専門家になることができます。世界中の情報を読むことで知恵を得ることができるのです。
では、知識と知恵が民主化された今、次は何でしょうか？それは分析です。分析を民主化することは非常に難しい課題です。私はAmazonに長く在籍していますが、続けている理由は、ある一つの問題を少しずつ解決するテクノロジーに取り組み続けているからです。Amazonに入社して最初の年、私は実存的な危機に直面し、それを一つの文、一つの問題提起にまとめました：「Poughkeepsieの8歳の子どもが、左利きの人々の中での乳がん発症傾向を分析できるようにするにはどうすればよいか？」
非常に具体的な問題に聞こえるかもしれませんが、この質問に含まれる技術的な要素は、12年前には存在していませんでした。データベースとの関わり方の民主化は、この期間で根本的に変化しました - NoSQLデータベース、オープンソースデータベース、マネージドデータベースなど。これらはすべてここ10年で台頭してきました。多様なデータセット間でのアイデンティティとプライバシーの管理が可能になったのも最近のことです。しかし、過去18ヶ月で、私は「8歳の子ども」という部分にたどり着きました。なぜなら、その子どもはサーバーを管理する必要がないからです。Serverlessテクノロジーがあり、その子どもは目的から結果に至るまでのプロセスさえ理解できれば、プログラミング言語を知る必要すらないのです。
次に来るのは分析の民主化です。その後には、おそらく統合化が来るでしょう。統合化とは、例えば流体力学の専門家が脳外科手術を行えるようになるということです。つまり、ある分野での深い専門知識を別の文脈に応用できるようになるということです。誰にでも、新しい分野やドメインを簡単に習得できる友人がいるものです。私たちはそういう方向に向かっています。実際、今では面接でもそういった点を重視しています。私たちは知識や知恵だけを考えているわけではありません。
これらのテクノロジーの応用と人々の採用方法について考えるとき、Ali も言及していましたが、組織の行動変化、つまり私たちがこれまでやってきたことと今後やっていくことの間にある人間的な変化があります。私たちの観察では、これらのアシスタントの統合を採用している人々は、若く、キャリアの初期段階にある傾向があり、彼らの生産性が大幅に向上していることがわかっています。Matt Garmanは最大80%という数字を挙げましたが、この数字は常に変動しています。というのも、ツールの活用方法についてより良い採用事例やフィードバックが得られているからです。さらに、リクエスターに代わってタスクを完了する自律性と主体性を持つエージェントモデルへと積極的に移行しています。
息子の話に戻りますが、私は4歳の頃から彼にコーディングを教えようとしてきました。Code Monkeysを使っていました - みなさんご存知だと思いますが、サルにバナナを取らせるゲームで、250のレッスンを通してPythonを学べるものです。息子は今14歳ですが、この10年は取り戻せません。彼が就職市場に出る頃には、Pythonの役割はどうなっているでしょうか？シンタックスの重要性はどうなっているでしょうか？私たちは開発者を「作成者」から「オーケストレーター」へと移行させています。これは、私が非常に孤立した方法でコードを学んだ時とは大きく異なります。「マルチプレイヤー」という言葉を使いますが、これはオブジェクト指向モデルを採用したからではなく、リアルタイムで協力し合い、人間が本当に得意とすることに人間の力を活用できるようになるということです。
GitLab Duo with Amazon Qの評価と実験の勧め
これが未来です。私の超オタク的な面に付き合っていただき、ありがとうございます。これは私の人生で経験した中で最も興味深いマイルストーンだと感じています。私たちがテクノロジーとどのように関わり、自分の人生では不可能だと思っていたスケールでイノベーションを民主化しているのです。そこで、GitLab Duo with Amazon Qを評価することをお勧めします。これは今日、GitLab branchでプレビューとして利用可能です。Qファミリーへようこそ。光栄です。ちなみに、私のGitLabピンバッジが欲しいですね。このQRコードを使用できますが、GitLabサイトにアクセスして今すぐ始めることもできます。Amazon Qの評価とGitLabの使用開始は非常に簡単です。
実験を始めることをお勧めします。以前の私なら、遊びではなく結果にのみ対価を支払っていましたが、今はそうではありません。私のチーム内では、実験し、遊び、より良い協力方法について新しいアイデアを考え出すよう求めています。ご清聴ありがとうございました。 ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion