ストーリーポイントは「人間がやる当てずっぽう」だった。アジャイル開発の一次見積もりはAIの仕事にする

Last updated at 2026-07-29Posted at 2026-07-29

この記事の結論

ストーリーポイントは客観的な測定値ではなく、不完全な情報とチームの経験から導く主観的な相対推定
過去事例の検索、相対比較、仮採点、根拠整理、不確実性の検出はAIへ移管できる
人間は、AIが取得できない文脈を補い、認識差を解消し、最終的なサイジングに責任を持つ

はじめに

アジャイル開発では、プロダクトバックログ項目の規模を表すためにストーリーポイントが広く使われています。

ただし、ストーリーポイントは作業時間やコード量のように客観的に測定できる数値ではありません。チームが過去の経験、類似案件、作業量、複雑性、リスク、不確実性を材料にして決める、主観的な相対推定です。

言い換えると、ストーリーポイントは構造化された当てずっぽうです。

多くのチームでは、複数のDevelopersがPlanning Pokerなどを使い、すべてのチケットについて一次見積もりから議論してきました。しかし、過去のチケット、Pull Request、確定済みストーリーポイント、コードベース、テスト、障害記録をAIが参照できるようになった現在、全員が毎回ゼロから一次見積もりを行う必要はあるのでしょうか。

本稿の提案は、AIに最終決定を丸投げすることではありません。

全員がゼロから数字を考えるプロセスをやめ、AIが一次見積もりを作り、人間は不確実な案件だけを議論する。

本稿における「当てずっぽう」の定義

「当てずっぽう」という言葉には「根拠のない適当な数字」という印象がありますが、本稿ではその意味で使っていません。本稿での当てずっぽうは、次のような推定を指します。

客観的な計算式では答えを確定できないため、不完全な情報、過去の経験、類似案件、技術的リスク、不確実性を材料にして行う推定

ストーリーポイントには、次のような普遍的な計算式は存在しません。

変更ファイル数
×
変更コード行数
×
テストケース数
=
ストーリーポイント

同じチケットであっても、次の条件が違えばポイントは変わります。

条件	ポイントが変わる理由
コードベース	共通部品の有無や技術的負債が異なる
テスト環境	自動テストの整備状況が異なる
Definition of Done	完了に必要な作業範囲が異なる
チームの経験	対象技術やドメインへの習熟度が異なる
外部依存	他チームや外部システムとの調整量が異なる
運用要件	リリース、監視、移行、互換性対応が異なる

ストーリーポイントは、誰が計測しても同じ値になる物理量ではありません。チーム固有の判断基準によって決まる相対的な推定値です。

専門的に表現すると「プロジェクト固有・チーム固有の主観的な相対推定」ですが、本稿ではより実態に近い言葉として「構造化された当てずっぽう」と呼びます。

『アジャイルサムライ』も見積もりを guess として扱っている

「見積もりは推測である」という考え方は、AI時代になって突然生まれたものではありません。

Jonathan Rasmussonによる『The Agile Samurai』では、見積もりを扱う章に次のタイトルが付いています。

Estimation: The Fine Art of Guessing

出版社のPragmatic Bookshelfは、この章の抜粋をPDFで公式公開しています。

The Agile Samurai — Estimation: The Fine Art of Guessing

この章では、初期の高水準な見積もりを bad guesses と表現し、最初の見積もりを過度に信頼しないことが説明されています。そのうえで提示されているのが次の方法です。

方法	目的
ストーリーを相対比較する	絶対時間を正確に当てようとしない
ポイント制を使う	作業規模を共通の尺度で扱う
実際のベロシティを計測する	推測ではなく実績を計画に反映する
継続的に計画を修正する	初期見積もりを固定的な約束にしない

アジャイルの見積もりは、未来を正確に言い当てる技術ではありません。推定が外れることを前提に、相対比較と実績データによって計画を更新する仕組みです。

ストーリーポイントは当てずっぽうを排除する道具ではなく、不確実な推定をチーム内で比較・更新しやすい形に変換する仕組みです。

ストーリーポイントは何を表しているのか

Mike Cohnは、ストーリーポイントを、プロダクトバックログ項目を完了するために必要な労力の相対的な見積もりとして説明しています。

Agile Estimating: How Teams Estimate with Story Points — Mountain Goat Software

ストーリーポイントに影響する要素は主に4つです。

要素	具体例
作業量	実装、テスト、調査、レビューの量
複雑性	状態管理、条件分岐、複数システム連携
リスク	既存機能への影響、障害発生可能性
不確実性	仕様未確定、技術検証不足、外部依存

ここで重要なのは、ストーリーポイントが「何日かかるか」を直接表すものではない点です。

たとえば、過去に完了した基準ストーリーが3ポイントだったとします。

基準ストーリー:

既存APIの項目を画面に1つ追加する
→ 3ポイント

新しいストーリーにAPI変更、キャッシュ更新、後方互換性確認が追加される場合、基準ストーリーより大きいと判断します。

新規ストーリー:

画面に項目を追加する
+
APIの変更
+
キャッシュの更新
+
旧バージョンとの後方互換性確認

→ 5ポイントまたは8ポイント

これは絶対的な測定ではなく、過去案件との比較です。そして、大量の過去案件から類似事例を探し、差分を整理する処理は、AIが得意とする領域です。

Scrumはストーリーポイントを必須にしていない

Scrumとストーリーポイントは分けて考える必要があります。

The Scrum Guide 2020 は、ストーリーポイントの使用を必須としていません。規定しているのは、Product Backlog Itemにサイズを付ける責任です。

The Developers who will be doing the work are responsible for the sizing.

実際に作業を行うDevelopersが、サイジングに責任を持ちます。Scrum.orgも、ストーリーポイントはScrumの必須要素ではないと説明しています。

Myth 9: Story Points are Required in Scrum — Scrum.org

AIを導入する場合も、責任分担は変わりません。

処理	担当
過去案件の検索	AI
類似案件との比較	AI
ポイント候補の生成	AI
根拠と不確実性の整理	AI
暗黙知や組織事情の補足	人間
AIの前提確認	人間
スコープの最終確認	Developers
最終的なサイジング	Developers

AIが一次見積もりを生成しても、Scrum Guideと矛盾しません。AIはサイジングのための支援手段であり、最終責任はDevelopersに残るからです。

ここは明確に分けます。

一次見積もりの生成
≠
最終的なサイジング責任

見積もりで価値があるのは、数字だけではない

Planning Pokerでは、複数のメンバーがそれぞれポイントを提示します。3、5、8のように近い値で揃うこともあれば、3と13のように大きく割れることもあります。

Aさん:
既存APIを利用できるので3ポイント

Bさん:
旧バージョンとの互換性対応が必要なので8ポイント

Cさん:
データ移行の有無が不明なので13ポイント

このとき本当に価値があるのは、最終的に8ポイントへ決まったことではありません。次の認識差が発見されたことに価値があります。

旧バージョン対応の認識が揃っていない

データ移行の要否が確定していない

完了条件が共有されていない

Scrum.orgも、見積もりは会話と共通理解を支援するためのものであり、確定的な約束ではなく予測だと説明しています。

Agile Estimation Isn't Broken. But the Thinking Might Be. — Scrum.org

AIを導入しても、認識合わせまで削除してはいけません。

削減すべき作業は、すべてのチケットについて全員が毎回ゼロから数字を考える工程です。残すべき会話は、不確実性、前提条件、技術リスク、スコープについて認識差がある案件の議論です。

AIの役割は会話をなくすことではなく、人間が会話すべき案件と論点を事前に選別することです。

なぜ一次見積もりをAIへ任せられるのか

ストーリーポイントの一次見積もりは、複数の小さな処理で構成されています。

一次見積もりに含まれる処理	AIとの相性
過去の類似チケットを探す	高い
過去のポイントを比較する	高い
変更対象を列挙する	高い
実装・テスト範囲を整理する	高い
依存関係を抽出する	比較的高い
仕様の不足を指摘する	比較的高い
仮ポイントを提示する	条件付きで可能
チームの暗黙知を理解する	低い
組織間の政治的事情を判断する	低い
最終責任を負う	不可能

AIは最終決定者には向いていません。一方で、判断材料の検索、比較、整理には向いています。

AIは全件を一次分析する。
人間は例外と不確実性を判断する。

AIによるストーリーポイント推定の研究

AIや機械学習によるストーリーポイント推定は、すでに複数の研究で検証されています。ただし、現時点で「AIが常に人間より正確である」と証明されたわけではありません。

研究から読み取れるのは次の範囲です。

AIによる一次見積もりは有望である
プロジェクト固有の過去事例を与えると改善する
人間を完全に排除する方式には限界がある

2024年：与える過去事例によって精度が変わる

J.P. Morgan AI Researchの研究では、GPT-4に与える過去事例の数と組み合わせを最適化し、ストーリーポイントを推定しています。

Search-based Optimisation of LLM Learning Shots for Story Point Estimation

3つのデータセットを使った予備実験では、過去事例を適切に選択することで、ゼロショットと比較した平均絶対誤差が平均59.34%改善したと報告されています。

読み取るべき点は、単にAIへチケットを渡せばよいわけではないことです。

精度を左右するもの:

どの過去事例を選ぶか

何件の過去事例を与えるか

ポイント尺度全体をカバーできているか

一次見積もりAIを作る場合は、無関係な過去案件を大量に渡すのではなく、比較基準として有効な案件を選ぶ必要があります。

この研究は予備的な結果であり、対象プロジェクトやモデル数が限定されています。59.34%という数値を、そのままあらゆるプロジェクトへ一般化することはできません。

2025年：絶対値より比較判断を使う

2025年の研究では、16プロジェクト、23,313件の人間による見積もりデータを使い、比較学習によるストーリーポイント推定を検証しています。

Efficient Story Point Estimation With Comparative Learning

この方式では、人間に直接「何ポイントですか」と聞く代わりに、2つの項目を比較してもらいます。

タスクAとタスクBでは、
どちらの方が大きな労力を必要とするか

比較結果を使い、プロジェクト固有の推定モデルを構築します。ストーリーポイントの本質である相対比較と一致する考え方です。

新しいチケットについて、最初から5ポイントや8ポイントを直接当てさせるのではなく、次の順序で判断させます。

このタスクは3ポイントの基準案件より大きいか
        ↓
5ポイントの基準案件と同程度か
        ↓
8ポイントの基準案件より小さいか
        ↓
ポイント候補を決める

AIに直接数字を出させるより、過去案件との大小関係を先に説明させる方が、根拠を確認しやすくなります。

2026年：少数のプロジェクト固有事例で推定が改善

2026年の研究では、4種類のLLMを16のソフトウェアプロジェクトで評価しています。

Story Point Estimation Using Large Language Models

学習データを与えないゼロショットでも、プロジェクトデータの80%で学習した比較対象の教師あり深層学習モデルを上回る結果が報告されています。さらに、プロジェクト固有の過去事例を5件与えるFew-shotによって、推定性能とランキング性能が改善しました。

特に、頻出するポイントだけを与えるより、ポイント尺度全体をカバーする多様な事例を与える方が有効だったとされています。

悪い例:

3ポイントの事例
3ポイントの事例
3ポイントの事例
5ポイントの事例
5ポイントの事例

良い例:

1ポイントの代表案件
3ポイントの代表案件
5ポイントの代表案件
8ポイントの代表案件
13ポイントの代表案件

この論文はプレプリントです。対象は16プロジェクトと4種類のLLMに限定されており、プロンプト設計による結果変動も研究上の制約として記載されています。確立された業界標準ではなく、AIによる一次見積もりの有望性を示す研究として扱う必要があります。

2026年：RAGは意思決定支援として有望

2026年のICPCで発表された研究では、23のオープンソースプロジェクトを対象に、RAGを使ったストーリーポイント推定が検証されています。

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

RAGを使う方式では、新しいタスクに類似する過去タスクを検索し、そのタスクと過去のポイントをLLMへ渡します。

新規チケット
    ↓
類似する過去チケットを検索
    ↓
過去チケットと確定ポイントをLLMへ入力
    ↓
一次見積もりを生成

人間がPlanning Pokerで過去案件を思い出しながら比較する方法に近い考え方です。

研究では、一部のプロジェクトで既存手法を上回りましたが、既存手法に対する統計的に有意な優位性は確認されませんでした。また、人間の判断を完全に除外すると性能が制限される可能性を指摘しています。一方で、類似する過去案件を提示し、Developersの意思決定を支援する用途には有効だと結論づけています。

本稿の提案と一致する部分です。

AIを最終決定者にするのではない。
AIを、類似案件と判断材料を提示する一次見積もり担当にする。

AIへ任せるのは「数字を出すこと」だけではない

AIに単一のポイントだけを出させる設計は不十分です。

見積もり: 5ポイント

これだけでは、次の点が分かりません。

なぜ5ポイントなのか

何と比較したのか

どの前提に依存しているのか

何が不明なのか

どの条件で8ポイントへ増えるのか

AIが出すべきなのは、ポイントだけではなく判断材料です。

出力項目	目的
ポイント候補	一次見積もりの提示
推定範囲	不確実性の可視化
信頼度	人間による確認要否の判断
類似案件	根拠の検証
増加要因	大きくなる条件の確認
減少要因	小さくなる条件の確認
前提条件	推定が成立する条件の確認
未確認事項	人間が調査すべき論点
議論要否	Refinementで扱うかの選別

AIの仕事は、ポイントを当てることだけではありません。見積もりの根拠と不確実性を構造化し、人間が議論すべき案件を選別することです。

AI時代の見積もりプロセス

従来のプロセスは次のようなものでした。

AI導入後は、次の形へ変更できます。

人間を完全に外すわけではありません。人間の作業を、全件の初期推定から例外案件の判断へ移します。

Step 1：チーム固有の基準ストーリーを準備する

AIに一般論だけで見積もらせると、チーム固有のポイント尺度とずれます。最初に、すでに完了している代表的なストーリーを選びます。

ポイント	基準ストーリーの例
1	文言修正と既存テストの更新だけで完了した案件
3	既存APIを利用した小規模なUI変更
5	UI、キャッシュ、回帰テストの変更を含む案件
8	データ移行、後方互換性、複数コンポーネント変更を含む案件
13	技術方式が未確定で、分割や事前調査が必要だった案件

基準ストーリーは、抽象的な説明だけでは不十分です。可能であれば次の情報を紐づけます。

Issue

Pull Request

変更されたファイル

テスト内容

設計資料

確定したストーリーポイント

実装時に発生した想定外作業

小さいポイントの事例だけを大量に与えるのではなく、ポイント尺度全体をカバーします。

Step 2：AIが参照する情報を整備する

最低限、次の情報が必要です。

情報	用途
新規チケットのタイトルと説明	見積もり対象の把握
受け入れ条件	完了範囲の確認
Definition of Done	テスト・レビュー・運用作業の確認
関連コード	技術的な変更範囲の分析
過去の類似チケット	相対比較
確定済みポイント	チーム固有尺度の較正
Pull Request	実際の変更内容の把握
テストコード	回帰範囲の確認
技術的負債	追加作業やリスクの把握
外部依存	他システムや他チームとの調整確認
障害記録	過去に発生したリスクの確認

チケット本文だけで判断させると、情報不足をAIが推測で補う危険があります。情報が不足している場合は、無理に数字を出さず「見積もり不能」と回答できるようにします。

Step 3：AIに一次見積もりを生成させる

以下は、汎用的に使えるプロンプトです。

あなたは、アジャイル開発チームのストーリーポイント一次見積もり担当です。

目的は、最終的なストーリーポイントを決定することではありません。

プロジェクト固有の過去事例と比較し、Developersが確認するための
一次見積もり、判断根拠、不確実性、未確認事項を提示してください。

## 見積もりルール

- 使用できるポイントは 1、2、3、5、8、13 とする
- 絶対時間ではなく、提示された基準ストーリーとの相対比較で判断する
- 作業量、複雑性、リスク、不確実性を考慮する
- 個人の能力や担当者個人の作業速度はポイントへ含めない
- 一般的な知識より、プロジェクト固有の過去事例を優先する
- 根拠が確認できない内容を推測しない
- 情報不足の場合は「見積もり不能」とする
- 類似案件を根拠として使用する場合は、必ずIssue IDを記載する
- 単一の数字だけでなく、推定範囲と信頼度も提示する
- 最終的なサイジングはDevelopersが行うものとして扱う

## 評価観点

1. 実装範囲
2. 変更対象コンポーネント数
3. 既存コードへの影響
4. API・データベース・キャッシュへの影響
5. データ移行の有無
6. 後方互換性
7. テスト範囲
8. 外部システムへの依存
9. 仕様の曖昧さ
10. 技術的な未知要素
11. セキュリティ・認証・決済への影響
12. リリース・運用・監視への影響

## 出力形式

### 一次見積もり

推定ストーリーポイント:
推定範囲:
信頼度: 高 / 中 / 低 / 見積もり不能

### 比較した過去案件

| Issue ID | ポイント | 類似点 | 相違点 |
|---|---:|---|---|

### 判断理由

### ポイントを増加させる要因

### ポイントを減少させる要因

### 成立条件・前提

### 未確認事項

### Developersによる議論

必要 / 不要

### 議論が必要な理由

AIによる出力例

以下は架空の例です。

対象チケット

書籍詳細画面に「配信状態」を追加する。

APIには配信状態の項目が既に存在する。
画面表示とローカルキャッシュへの保存が必要。
旧バージョンのキャッシュが端末に存在する可能性がある。

AIの出力

### 一次見積もり

推定ストーリーポイント: 5
推定範囲: 3〜8
信頼度: 中

### 比較した過去案件

| Issue ID | ポイント | 類似点 | 相違点 |
|---|---:|---|---|
| APP-102 | 3 | 既存API項目の画面追加 | キャッシュ変更なし |
| APP-184 | 5 | UI・キャッシュ・テスト変更 | 後方互換性対応なし |
| APP-211 | 8 | キャッシュ移行と互換性対応 | API仕様変更も含む |

### 判断理由

UI追加だけであれば、APP-102と同程度の3ポイントです。

今回はローカルキャッシュへの保存と、
旧バージョンのキャッシュとの互換性確認が必要なため、
APP-184と同程度の5ポイントを一次見積もりとしました。

### ポイントを増加させる要因

旧キャッシュのマイグレーション処理が必要な場合は、
APP-211に近づくため8ポイントとなる可能性があります。

### ポイントを減少させる要因

旧キャッシュを破棄でき、
新しい値を再取得する仕様で問題ない場合は3ポイントへ下がります。

### 成立条件・前提

- APIの配信状態項目は既に利用可能である
- 表示仕様は確定している
- 新しい分析イベントの追加は不要である

### 未確認事項

- 旧キャッシュを保持したまま移行する必要があるか
- オフライン状態での表示要件があるか
- 既存ユーザーへの回帰テスト範囲はどこまでか

### Developersによる議論

必要

### 議論が必要な理由

キャッシュ移行の要否によって、
3〜8ポイントの範囲でサイズが変わるため。

この出力があれば、人間はゼロから「3か5か8か」を考える必要がありません。確認すべき論点がキャッシュ移行とオフライン要件であることも分かります。

AIの数字が人間を誘導する危険

AIの一次見積もりには新しい問題もあります。AIが最初に「3ポイント」と表示すると、人間がその数字に引っ張られます。

これはアンカリングと呼ばれる認知バイアスです。ソフトウェア開発者を対象とした実験でも、最初に提示された数値がその後の工数見積もりへ影響することが確認されています。

An Experimental Evaluation of a De-biasing Intervention for Professional Software Developers

そのため、AIの出力では最初にポイントだけを強調するべきではありません。推奨される確認順は次のとおりです。

1. 類似案件

2. 前提条件

3. 未確認事項

4. 増加要因と減少要因

5. 推定範囲

6. ポイント候補

高リスク案件については、人間がAIのポイントを見る前に、独立した見積もりを記録する方法もあります。

人間の独立見積もり
        +
AIの一次見積もり
        ↓
差が大きい場合だけ議論

AIを導入しても認知バイアスは消えません。人間同士のアンカリングが、AIから人間へのアンカリングへ変わるだけの可能性があります。

人間による議論が必要な条件

すべてのチケットをPlanning Pokerへ回す必要はありません。次の条件に該当した場合だけ、人間による議論を必須にします。

条件	理由
AIの信頼度が低い	類似案件または入力情報が不足している
推定範囲が広い	前提によってサイズが大きく変わる
8ポイント以上	分割や事前調査が必要な可能性がある
外部システムへ依存する	チーム内だけで完結しない
データ移行がある	障害時の影響が大きい
セキュリティ・認証・決済に関係する	技術・事業リスクが高い
AIと担当者の見積もり差が大きい	暗黙知または認識差がある
類似案件が見つからない	プロジェクト内の比較基準がない
仕様に矛盾がある	サイジング可能な状態ではない
Definition of Doneが不明確	完了範囲を確定できない

低リスクで基準事例との対応が明確な案件は、短い確認だけで確定します。高リスク案件については、従来どおりDevelopersが議論し、必要であればスパイクやチケット分割を行います。

導入効果を何で評価するか

AIが「実際の作業時間を正確に当てたか」だけで評価するのは適切ではありません。ストーリーポイントは時間そのものではなく、チーム内の相対尺度だからです。

導入時には、次の指標を記録します。

指標	確認する内容
Refinement時間	見積もり会議の時間が減ったか
AI見積もり採用率	人間が変更せず採用した割合
最終ポイントとの差	AIとDevelopersの判断差
要議論率	全件のうち議論が必要だった割合
不明点の事前発見率	実装前に依存関係や仕様不足を発見できたか
Sprint持ち越し率	実行可能性の判断が改善したか
サイズ別Cycle Time	相対的な大小関係が実績と整合しているか
見積もり不能率	情報不足のチケットを検出できたか
見積もり変更理由	AIが見落とした情報を分析できるか

見るべきなのはAI見積もりの正解率だけではありません。

人間の時間を削減しながら、実装前に不確実性を発見できたか

AI一次見積もりを導入する際の失敗パターン

AIへチケットのタイトルだけを渡す

タイトルだけでは、テスト、移行、互換性、運用まで判断できません。説明、受け入れ条件、関連コード、過去案件を含める必要があります。

プロジェクト固有の基準を与えない

ストーリーポイントはチーム固有です。一般的なAIの感覚で5ポイントと判断しても、そのチームの5ポイントとは一致しません。

単一の数字だけを出させる

根拠や不確実性を表示しないと、AIの数字を検証できません。人間が数字へアンカリングされやすくもなります。

AIの出力を自動確定する

AIはチームの暗黙知や組織事情を完全には取得できません。最終的なサイジング責任はDevelopersに残します。

過去のポイントを無条件に正解として扱う

過去の人間による見積もりにも、認識不足やバイアスが含まれます。基準案件は定期的に見直し、現在のDefinition of Doneや技術環境と一致しているか確認します。

チーム間で同じモデルを共有する

別チームの8ポイントは、自チームの8ポイントと同じとは限りません。モデルや検索対象は、原則としてチームまたはプロジェクト単位で較正します。

よくある反論

「見積もりの価値は会話にある。AIへ任せるべきではない」

見積もりにおける会話には価値があります。ただし、すべての案件について、全員が最初から数字を考える必要はありません。

AIが事前に論点を整理し、見積もりが割れそうな案件だけを人間が議論する方が、会話の密度は高まります。削減するのは会話ではなく、機械的な検索と比較作業です。

「AIはチームの暗黙知を理解できない」

そのとおりです。だからこそ最終決定をAIへ任せません。AIが不足している文脈を明らかにし、人間が補足する設計にします。

AIへ入力できない暗黙知が見つかること自体、ドキュメントやチケットの改善材料になります。

「AIはハルシネーションを起こす」

類似案件のIssue ID、Pull Request、変更ファイルなど、検証可能な根拠を必須にします。根拠が存在しない場合は、見積もり不能と回答させます。

AIが自由に理由を創作できる設計にしてはいけません。

「Scrum GuideではDevelopersがサイジングする」

最終的なサイジングはDevelopersが行います。AIは、IDE、静的解析、テストツールと同じく、Developersが判断するために利用する道具です。一次案の生成と、最終的な責任は分けて考えます。

「そもそもストーリーポイントが不要ではないか」

ストーリーポイントを使用しないチームもあります。Throughput、Cycle Time、Monte Carlo Simulationなど、実績データから確率的に予測する方法もあります。

本稿は、すべてのチームにストーリーポイントを推奨するものではありません。すでにストーリーポイントを使用しているチームが、AIによって運用コストを下げる方法を扱っています。

一次見積もりはAIの仕事にする

ストーリーポイントは、客観的に測定できる真実の数字ではありません。人間が、過去の経験、類似案件、作業量、複雑性、リスク、不確実性を材料にして行う相対的な推定です。

その中には、AIが得意とする処理が大量に含まれています。

過去チケットを探す

類似案件を比較する

変更範囲を整理する

依存関係を抽出する

不明点を列挙する

ポイント候補を提示する

判断根拠を文章化する

これらを毎回、人間全員がゼロから行う合理性は低下しています。

一方で、AIには取得できない情報もあります。

チーム固有の暗黙知

組織間の調整事情

仕様書に書かれていない運用

実際のコードの劣化状況

ステークホルダーとの合意

チームが受け入れられるリスク

AI時代の役割分担は次の形になります。

従来	AI時代
人間が全件を一次見積もりする	AIが全件を一次分析する
全員が数字をゼロから考える	AIがポイント候補と根拠を出す
すべての案件を会議で扱う	低信頼・高リスク案件だけ議論する
数字を決めることが中心	前提と不確実性の確認が中心
過去案件を人間の記憶から探す	AIが履歴から類似案件を検索する
人間が推定と最終判断を行う	AIが一次推定し、人間が責任を持つ

「一次見積もりはAIの仕事」という主張は、AIの方が常に正しいという意味ではありません。

AIが全件を処理し、人間が例外と不確実性へ集中する方が、専門家の時間を合理的に使える

という意味です。

まとめ

ストーリーポイントは、客観的な測定値ではありません。チーム固有の経験と不完全な情報をもとにした、主観的な相対推定です。

『アジャイルサムライ』も、初期見積もりが推測であることを前提に、相対比較と実績による継続的な更新を提案しています。

近年は、LLM、比較学習、Few-shot、RAGを使ったストーリーポイント推定の研究が進んでいます。これらの研究は、AIによる一次見積もりが有望であり、プロジェクト固有の過去事例を与えることで改善する可能性を示しています。一方で、人間を完全に排除した自動見積もりが、常に既存手法を上回るとは示されていません。

現時点で合理的な結論は次のとおりです。

ストーリーポイントは、人間が行ってきた構造化された当てずっぽうである。

一次見積もりの生成、過去事例との比較、根拠整理、不確実性検出はAIの仕事にする。

人間は、AIが理解できない文脈を補い、認識差を解消し、最終的なサイジングに責任を持つ。

AI時代に見直すべきなのは、ストーリーポイントそのものだけではありません。

人間全員が、すべての案件について、毎回ゼロから数字を考える必要があるのか。 見直すべきなのは、この前提です。

参考資料

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up