Scrum.orgは最近、COOであるEric Naiburg氏によるAI as a Scrum Team Member と題した記事を掲載した。Naiburg氏は、スクラムマスター、プロダクトオーナー、開発者にとっての生産効率の利点を説明した上で、読者にAIが「チームメンバー」としてスクラムチームに「シームレスに統合されていることを想像する」よう呼びかけた。Thoughtworks社のAIアシストソフトウェアデリバリーのグローバルリードであるBirgitta Böckeler氏も最近、「Exploring Generative AI」と題した記事を発表し、エンジニアリングシナリオにおけるLLM（大規模言語モデル）の使用を含む実験に関する洞察を共有した。同実験においては、LLM（大規模言語モデル）がソフトウェアデリバリーチームに相乗効果をもたらしている可能性がある。
Naiburg氏は、AIツールとペアプログラミング共同開発者のそれぞれの役割を比較した。彼は、LLM統合から分析ツールにわたってAIの定義を使う場合、どうAIを使えばスクラムチームの重要な役割における認知負荷が軽減できるかを述べた。彼はスクラムマスターの役割について議論し、AIはチームファシリテーション、チームパフォーマンス、フローの最適化について助言できるアシスタントとして活用できると説明した。Naiburg氏は、セレモニーでのエンゲージメントを高める手引きとして、LLMを用いる例を挙げた。
AIは、会議のさまざまなファシリテーション手法を提案できます。例えば、スプリントレトロスペクティブでスクラムチームのメンバーとの間に難しさを感じる場合は、AIに 「スプリントレトロスペクティブに対するスクラムチームの意欲に問題があります。何かアイデアはありますか？」と質問するだけで済みます。
Naiburg氏は、開発者によるストーリーの分解と理解に役立つチーム内アシスタントとして活用できると述べた。さらに彼は、プロトタイピング、テスト、コード生成、コードレビュー、テストデータの合成を簡素化するためにAIを使うことの利点を強調した。
Böckeler氏は、開発者というペルソナに焦点を当て、LLMを使ってオープンソースプロジェクトに参加し、 レガシーソフトウェアプロジェクトに反するストーリーを提供する実験について説明した。AIツールの性能と限界を理解するために、彼女はLLMを使ってオープンソースプロジェクトBhamniのバックログにあるチケットに取り組んだ。Böckeler氏は、チケットやコードベースを理解し、プロジェクトのコンテキスト境界を理解するためにLLMを使用したことについて記している。
Böckeler氏の主なツールは、 RAG（検索拡張生成）を使ったLLMで構成されており、Bhamniのwikiの内容に基づいた洞察を提供するものだった。彼女はLLMにユーザーストーリーを含むプロンプトを提供し、そこで言及された「Bhamniとヘルスケア用語を説明する」よう求めた。とBöckeler氏は述べている。
次のチケットのBahmniと医療用語について説明してください...。"と大まかな質問をしました。「少し冗長で繰り返しの多い回答でしたが、全体的には役に立ちました。チケットの全体を捉えて、もう一度説明してくれました。また、関連する機能が 「Bahmni HIPプラグインモジュールで実行される」ということも書いてあり、関連するコードがどこにあるのかを知る手がかりになりました。
TitanML社の共同設立者/CEOであるMeryem Arik氏は、6月の InfoQ Podcastに登壇した際、"リサーチ・アシスタント"としてRAGを実行するLLMの使用について、"エンタープライズ向けの101として我々の目にするもっとも一般的なユースケース"であると述べた。Böckeler氏が「WikiのRAGボット」だと表現した以外はRAGの実装を直接は取り上げなかった一方で、Arik氏は、様々なオープンモデルを使用したカスタムソリューションから得られるプライバシーとドメイン特化における利点について幅広く語った。彼女は次のように語った。
もしあなたが最先端のRAGアプリを作ろうとしているのなら、すべてに最適なモデルはOpenAIだと思うかもしれません。しかし、実際はそうではありません。最先端のRAGアプリを作るのであれば、ベストな生成モデルははOpenAIです。しかし、ベストな埋め込みモデル、ベストな再ランクモデル、ベストなテーブルパーサー、ベストな画像パーサー、これらはすべてオープンソースです。
コードを理解し、 自身の変更点に的を絞るために、Böckeler氏は、コード生成と理解に使われる2つのツール、BloopとGithubCopilotに「JIRAチケットのテキストを取り込ませた」と書いている。彼女は両方のツールに、「この機能に関連するコードを見つける」のを手伝うよう頼んだ。どちらのモデルからも同じような一連のポインタが得られた。彼女は「100％正確なわけではない」と表現したが、「全体的な方向性としては有用」だった。自律型コードジェネレータの可能性を探る中で、 Böckeler氏は、フレームワーク間でテスト移植を行うLLMベースのAIエージェント構築に向け、Autogenを使用した実験をした。彼女は、次のように説明している。
ここでいうエージェントとは、大規模言語モデルを使用するアプリケーションのことで、単にモデルの応答をユーザーに表示するだけでなく、LLMの指示に基づいて自律的に行動します。
Böckeler氏は、彼女のエージェントが 「少なくとも一度は」うまくいったと報告したが、「うまくいったときより、失敗の方が多かった。」という。InfoQは最近、Upwork Research Instituteによる物議を醸す調査について報告した。回答者の39％が "AIが生成したコンテンツのレビューやモデレートにより多くの時間を費やしている "と述べており、AIツールが生産性を低下させるというサンプリング対象者の認識を指摘している。Naiburg氏は、チームがAIツールの成果物だけでなく、意義に目を向け続ける必要性を訴えている。
注意点がひとつあります。こうしたツールを使うと、「もの」の量が増える可能性があります。例えば、一部のソフトウェア開発ボットは、コードの行数を増やしすぎたり、無関係なコードを追加したりするという不満が寄せられています。AIに 、ストーリーのリファインメントをさせたり、テストを構築させたり、あるいは会議の議事録を作成させたりする場合も同様です。結局のところ、情報量がこれらのツールの提供する価値の邪魔になる可能性があります。
Autotgenを用いた実験について、Böckeler氏は、こうしたテクノロジーには「特定の問題空間」におけるさらなる利用価値があると呼びかけ、次のように語っている。
私たちの投げかけるあらゆる種類のコーディングの問題を解決するという期待に、これらのエージェントが応えられるようになるには、まだまだ道のりは遠いです。しかし、エージェントが誤解を招くような宣伝文句で謳われるとおりの包括的な問題解決ツールではないのだと一思いに片づけるのではなく、エージェントが私たちを助けてくれる具体的な問題空間とは何かを考える価値はあると思います。