開発におけるストーリーポイント — 概要、評価スケールと応用

ストーリーポイントとは？

ストーリーポイントは、スクラムやその他のアジャイル手法で使用されるタスクの複雑さの指標です。チームは各タスクを時間ではなく、相対的な単位で評価します：「このタスクは基準の2倍複雑です。」このアプローチは、開発者間の速度の違いを平準化し、複雑さに焦点を当てます。

用語の起源

ストーリーポイントの概念は、2000年代初頭にスクラムの普及とともに生まれました。この方法を最初に記述した一人は、エクストリームプログラミング（XP）の一環としてロン・ジェフリーズでした。アイデアは、常に不正確な「人時」での見積もりから、チームが協力して決定する相対的な複雑さへと移行することでした。現在、ストーリーポイントはアジャイルチームの業界標準です。

ストーリーポイントで考慮される要素

ストーリーポイントで見積もる際、チームは3つの要素を考慮します：作業量（コード、画面、ロジックの量）、複雑さ（技術的課題、新しい技術）、不確実性（不明確な要件、リスク）。1ストーリーポイントは「リスクのない単純なタスク」を意味し、8は「不確実性の高い複雑なタスク」を意味する場合があります。

ストーリーポイントのスケール：選び方

ストーリーポイントのスケールの選択は、見積もりの精度と計画の利便性に影響します。最も人気のあるスケールはフィボナッチ数列ですが、代替案もあります。

なぜフィボナッチ？スケールの心理学

フィボナッチ数列は偶然選ばれたわけではありません。1と2の差は最小限（50%）ですが、13と21の差は顕著（62%）です。これは現実を反映しています：小さなタスクはより正確に見積もられ、大きなタスクはより大きな分散で見積もられます。タスクが21ストーリーポイントと見積もられた場合、チームは理解します：「どれだけ時間がかかるかわからないが、確実に13よりは多い。」フィボナッチスケールは誤った正確さを防ぎます。

基準タスク — スケールの基礎

スケールを機能させるために、チームは基準に合意します：「タスクXは1ストーリーポイントです。」通常、シンプルでよく知られたタスクが基準として選ばれます：「画面にテキストフィールドを追加する」や「タイポのバグを修正する。」他のすべてのタスクは基準に対して相対的に見積もられます。基準がなければ、ストーリーポイントは意味を失います — 各人が単位を異なるように理解します。

チームのベロシティと予測

ベロシティは、チームが1スプリントで完了するストーリーポイントの平均数です。これはプロジェクトのスケジュールを予測するための重要な指標です。

ベロシティの計算方法

ベロシティは完了したタスクに基づいて計算されます：チームが完了できたすべてのタスク（完了の定義を満たしたもの）のストーリーポイントが合計されます。未完了のタスクはカウントされません。正確性のために、過去3〜5スプリントの平均が取られます。例えば、チームが過去4スプリントで20、22、18、24ストーリーポイントを完了した場合、ベロシティ = 21ス‌ポです。

ベロシティによる予測

ベロシティとバックログの総量をストーリーポイントで把握することで、リリースまでのスプリント数を予測できます。例えば、バックログに210ストーリーポイントがあり、ベロシティが21の場合、10スプリントかかります。これは大まかな予測であり、作業が進むにつれて精緻化されます。重要：ベロシティは平均であり、コミットメントではありません。平均ではなく下限（18ス‌ポ）に基づいて計画してください。

ベロシティを上げる方法

ベロシティは命令で上げることはできません — それはプロセスの健全性の症状です。持続可能なベロシティの成長は以下を通じて達成されます：技術的負債の削減、コードレビュープロセスの改善、コンテキストスイッチの削減、テストとCI/CDの自動化。重要：異なるチームのベロシティは比較できません — 各チームがストーリーポイントを独自の方法で定義します。

ストーリーポイント vs 時間：何をいつ使うか

ストーリーポイントと時間には異なる目的があり、それらの選択は状況によって異なります。経験豊富なチームは、異なるタスクに対して両方のアプローチを使用します。

ストーリーポイントがより効果的な場合

ストーリーポイントはスプリント計画に不可欠です：誰がタスクを行うかに依存しません。ジュニアは1日に2ス‌ポ、シニアは4ス‌ポこなすかもしれませんが、タスクの見積もりは両方とも2ス‌ポのままです。ストーリーポイントは、開発者を比較せずにチームの生産性を追跡することを可能にします。これにより、政治的な圧力が軽減され、チームの雰囲気が改善されます。

時間が必要な場合

時間は外部のコミットメントに必要です：契約、予算、クライアントへの報告。クライアントは「8ストーリーポイント」ではなく「3週間」を知りたがります。ストーリーポイントを時間に変換するには、過去の変換率を使用します：チームは1ス‌ポが約4時間の作業に相当することを知っています。変換は透明でデータに基づいたものであるべきで、推測に基づくべきではありません。

組み合わせアプローチ

多くのチームは組み合わせアプローチを使用します：タスクはスプリント計画のためにストーリーポイントで見積もられ、その後マネージャーが外部報告のために時間/日に変換します。2つのシステムを1つのプロセスで混在させないことが重要です：ストーリーポイントで見積もりベロシティから時間を導き出すか、直接時間で見積もるかのどちらかです。

ストーリーポイントを使う際のよくある間違い

ストーリーポイントの導入は、相対的な見積もりの利点を無効にする間違いを伴うことがよくあります。以下は最も一般的なものです。

ストーリーポイントを時間に結びつける

最も一般的な間違い — チームが合意します：「1ス‌ポ = 4時間。」この場合、ストーリーポイントは意味を失い、別の名前の時間に変わります。ストーリーポイントは相対的であるべきで、時間に縛られるべきではありません。タスクAがタスクBの2倍複雑な場合、それがどれだけの時間がかかるかに関係なく、2ス‌ポを取得します。

事後評価

タスクが完了した後に見積もられる場合 — それは見積もりではなく、記録です。ストーリーポイントは作業開始前、最大の不確実性の時点で割り当てられるべきです。事後評価はベロシティを歪め、計画に利益をもたらしません。さらに、誤った正確さの感覚を生み出します。

チーム間のベロシティ比較

チームAとチームBのベロシティを比較することは意味のない練習です。各チームは基準とスケールを異なる方法で定義します。あるチームにとって1ス‌ポは1時間の単純なタスクですが、別のチームにとっては1日のタスクです。比較できるのは、時間の経過に伴う同じチームのベロシティだけです：それが成長しているか減少しているか。

一貫性のないスケール

同じ複雑さの異なるタスクが異なるストーリーポイントを受け取り、より複雑なタスクがより少ないポイントを受け取る場合、スケールは崩壊します。チームは定期的にスケールを調整する必要があります：3〜6スプリントごとに、見積もりが実際の複雑さとどの程度一致していたかを振り返ってレビューします。これにより、見積もりの一貫性が向上します。