🤖 machine learning

Agile Story-Point Estimation: Is RAG a Better Way to Go?

本研究は、アジャイル開発における手動のストーリーポイント見積もりを RAG（検索拡張生成）で自動化できるか検討したが、既存のベースラインモデルをいくつかのケースで上回ったものの、プロジェクト規模や埋め込みモデルの違いによる統計的に有意な性能差は見られなかったため、さらなる精度向上に向けた研究が必要であると結論付けています。

原著者： Lamyea Maha, Tajmilur Rahman, Chanchal Roy

公開日 2026-04-07

📖 1 分で読めます☕ さくっと読める

CC BY 4.0

原著者： Lamyea Maha, Tajmilur Rahman, Chanchal Roy

原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 ✨ これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。免責事項の全文を読む

🍳 1. 背景：なぜ「見積もり」は難しいのか？

ソフトウェア開発では、新しい機能を作る前に「これを作るのにどれくらい時間がかかるか？」をチームで話し合います。これを**「スプリント計画」**と呼びます。

今のやり方（プランニング・ポーカー）：
チーム全員が、カードを使って「1 時間かかるかな？」「10 時間かかるかな？」と推測します。
- メリット： 経験豊富な人たちの知恵がまとまる。
- デメリット： 会議に時間がかかる。また、「偉い人が言ったからそれに合わせる」といったバイアス（偏見）が入ったり、若手社員が意見を言いにくくなったりする問題があります。
今回の研究の目的：
「この面倒な会議を、AI にやってもらえないか？」という試みです。AI が過去のデータを見て、「これと似たような作業は過去に何時間かかった？」と教えてくれる仕組みを作ろうとしたのです。

🔍 2. 使った技術：RAG（レグ）とは？

この研究で使ったのは**「RAG（Retrieval-Augmented Generation）」**という技術です。

RAG の仕組み（例え話）：
想像してみてください。新しい料理（タスク）を作ろうとしたとき、AI が**「過去のレシピ帳（データベース）」をひっくり返して、「これと似た料理のレシピ」**を 3 つほど見つけてきます。
そして、AI はその「過去のレシピ」を見て、「あ、これなら 30 分くらいでできそうだな」と推測して、新しい料理の完成時間を答えます。
- 検索役（Retriever）： 過去のレシピ帳から、似たようなものを探す人。
- 生成役（Generator）： 見つかったレシピを見て、答えを言う人（今回は「Llama-3.2-3B」という AI）。

🧪 3. 実験：どんなことを調べたの？

研究者たちは、23 個のオープンソースプロジェクト（GitHub などの公開されたプロジェクト）のデータを使って、以下の 4 つのことをテストしました。

検索の仕方は重要？
過去のレシピを「2 つ」見せるのと「4 つ」見せるのと、どちらが正解に近い答えが出るか？（検索する数：top_k）
プロジェクトの大きさは関係ある？
小さなプロジェクト（レシピ帳が薄い）と、巨大なプロジェクト（レシピ帳が分厚い）で、AI の性能は変わるか？
検索の「道具」は重要？
似たものを探すための「検索エンジン（埋め込みモデル）」を 2 種類（BAAI と SBERT）変えて、どちらが上手に探すか？
既存の AI 手法より優れている？
昔からある他の AI 手法（機械学習など）と比べて、RAG の方が正解に近い答えを出せるか？

📊 4. 結果：AI は人間に勝てた？

残念ながら、「AI が人間を完全に凌駕して、劇的に正確な答えを出した」という結果にはなりませんでした。

発見されたこと：
- プロジェクトの大きさ： 小さなプロジェクトでも、大きなプロジェクトでも、AI の性能に大きな差はありませんでした。
- 検索の道具： 2 種類の検索エンジンを使っても、結果に大きな差はありませんでした。
- 他の AI との比較： RAG は、いくつかのプロジェクトでは他の AI より良い結果を出しましたが、「統計的に見て、他の方法より明らかに優れている」とは言えませんでした。
なぜそうなったのか？
見積もりという作業は、単に数字を計算するだけでなく、「この作業は実は難しそうだな」という人間の直感や文脈が重要だからかもしれません。AI が過去のデータ（レシピ）をただ見せるだけでは、人間が持つ「経験のニュアンス」まで完全に再現するのは難しいようです。

💡 5. 結論と今後の展望：じゃあ、意味なかったの？

いいえ、意味は十分にあります！

AI は「助手」として優秀：
AI が「過去の似たような作業はこれです」と教えてくれるのは、人間が会議で話し合う際の**「強力なサポート」**になります。
- 「あ、これと似たやつ、過去に 5 時間かかったね」という事実を AI が提示すれば、人間はより公平に、偏りなく議論を進められます。
- 会議の時間を短縮したり、若手社員が「過去の事例」を参考にしやすくなったりするメリットはあります。
今後の課題：
- データの汚れ（ノイズ）をきれいに掃除する。
- 特定のプロジェクトに特化して AI をもっと勉強させる（微調整）。
- 企業内のデータなど、よりリアルな現場で試す。

🎯 まとめ

この論文は、**「AI に見積もりを丸投げするのはまだ早すぎるが、AI を『過去の事例を探す優秀なアシスタント』として使えば、チームの会議をより良くできる」**という示唆を与えてくれました。

完全な自動化ではなく、**「人間と AI のタッグ」**で、よりスムーズな開発を目指そうという提案なのです。

論文サマリー：アジャイル・ストーリーポイント推定における RAG の有効性検証

1. 研究の背景と問題定義

アジャイル開発におけるスプリント計画セッションでは、タスクの工数を「ストーリーポイント（Story Point: SP）」で推定する「Planning Poker」という手法が広く用いられています。しかし、このプロセスには以下の課題があります。

時間的コスト: 各タスクの推定に 5〜10 分を要し、大規模プロジェクトでは数ヶ月を要する可能性があります。
人的バイアス: 経験豊富なメンバーの意見や会議内の権力構造が推定結果に影響し、コスト超過やリソースの非効率な利用を招く恐れがあります。
既存の自動化手法の限界: 従来の機械学習手法（TF-IDF や Deep-SE など）は、文脈の解釈や推定の透明性（解釈可能性）において課題を抱えています。

本研究は、これらの課題を解決するため、検索拡張生成（Retrieval-Augmented Generation: RAG） を活用してストーリーポイントを自動推定する手法を提案し、その有効性を検証することを目的としています。

2. 提案手法（RAG アプローチ）

本研究では、開発者が Planning Poker で類似タスクを参照して推定を行うプロセスを模倣する RAG ベースのシステムを構築しました。システムは以下の 2 つの主要コンポーネントで構成されます。

2.1 リtriever（検索モジュール）

目的: 入力された新しいタスク（タイトルと説明）に対して、過去のプロジェクト履歴から最も類似したタスクを検索します。
埋め込みモデル: 2 つの異なる埋め込みモデルを比較検証しました。
1. BAAI: bge-large-en-v1.5
2. SBERT: all-mpnet-base-v2
検索プロセス: 入力タスクとトレーニングデータの埋め込みベクトル間のコサイン類似度を計算し、上位 $k$ 個（ $top\_k$ ）の類似タスクを抽出します。

2.2 Generator（生成モジュール）

モデル: Llama-3.2-3B-Instruct を使用。
プロンプトエンジニアリング: 検索された類似タスク（タイトル、説明、実際の SP）と新しいタスクをコンテキストとして提示し、フィボナッチ数列（0, 1, 2, 3, 5, 8...）に基づいた数値を出力するように指示します。
特徴: 開発者が過去の事例を参照して推定する「Planning Poker」の思考プロセスを模倣し、推定根拠の透明性を確保します。

3. 実験設計

データセット: Tawosi らが提供するオープンソースプロジェクトのデータセット（23 プロジェクト、31,960 タスク）を使用。
データ前処理: SP 変更後のタスクの除外、未解決タスクの除外、フィボナッチ数列外の SP の除外など、厳格なフィルタリングを実施。
プロジェクトの分類: タスク数に基づき「小規模（≤500）」「中規模（501-2000）」「大規模（>2000）」の 3 グループに分類。
評価指標: 平均絶対誤差（MAE）と中央値絶対誤差（MdAE）。
ベースライン手法との比較: 既存の 4 手法（TF-IDF, Deep-SE, LHC-SE, LHCtc-SE）と比較。
統計的検定: 仮説検証のために、Wilcoxon 符号付き順位和検定（ペア比較）および Kruskal-Wallis 検定（グループ間比較）を使用。

4. 主要な結果と知見

RQ1: 検索パラメータ（top_k, temperature）の影響

結果: 最適なパラメータ設定はプロジェクトの規模や使用した埋め込みモデルによって異なりました（例：BAAI では小・中規模で top_k=2 が最適、大規模では top_k=4 が最適など）。
結論: 単一の最適設定は存在せず、プロジェクトの規模に応じて調整が必要ですが、パラメータの違いが統計的に有意な性能差を生むとは限りませんでした。

RQ2: プロジェクト規模による性能差

結果: プロジェクト規模（小・中・大）による MAE の平均値には差が見られましたが、Kruskal-Wallis 検定により統計的に有意な差は確認されませんでした（BAAI: p=0.83, SBERT: p=0.75）。
結論: RAG アプローチの性能はプロジェクト規模に依存せず、どの規模でも同様の精度を発揮します。

RQ3: 埋め込みモデルの選択

結果: BAAI と SBERT の 2 つのモデル間での MAE 比較において、統計的に有意な差は認められませんでした（Wilcoxon 検定、p=0.16）。
結論: 使用した 2 つの埋め込みモデルのいずれを選んでも、ストーリーポイント推定の精度に大きな影響はありません。

RQ4: 既存手法との比較

結果: 個別のプロジェクトでは RAG モデルがベースライン手法を上回るケースがありましたが、全体としての統計的検定（Wilcoxon 検定）では、RAG がベースライン手法よりも有意に低い MAE を達成したとは結論付けられませんでした。
結論: 数値的な推定精度において、RAG は既存手法と同等の性能を示しましたが、決定的な優位性は証明されませんでした。

5. 結論と意義

主要な発見: RAG ベースのアプローチは、Planning Poker のプロセスを模倣し、推定の根拠（類似タスク）を提示することで解釈可能性と透明性を提供します。しかし、純粋な数値推定精度（MAE）においては、既存の機械学習手法やベースライン手法に対して統計的に有意な向上をもたらすことはできませんでした。
実用的価値: 完全な自動化というよりは、開発者が推定を行う際の意思決定支援ツール（Decision Support Tool） として有用です。類似タスクを提示することで、チームの議論を促進し、バイアスを軽減する可能性があります。
今後の課題:
- タスク記述のノイズ除去や、より制御された環境（産業用プロジェクトなど）でのデータ収集。
- プロジェクト固有のデータによる生成モデルのファインチューニング。
- より多様な埋め込みモデルの検討。

6. 総括

本研究は、RAG をアジャイルのストーリーポイント推定に応用した初の体系的な実証研究の一つです。その結果、RAG は「推定プロセスの透明化」という点で大きな価値を持つものの、現状の技術では「数値精度の飛躍的向上」には至っていないことが示されました。今後は、人間の判断を完全に排除するのではなく、RAG を開発者の推定を支援するツールとして統合するアプローチが重要であると結論付けています。