ストーリーポイントとは？見積もり方法とベロシティ活用、形骸化を防ぐ実践ポイントを解説

ストーリーポイントを導入しているにもかかわらず、「次の一手が決められない」という状況は少なくありません。背景にあるのは、進捗・工数・課題が分断され、見積もりや実績のデータが日々の判断に結び付いていないことです。

本記事では、ストーリーポイントの基本的な定義や時間見積もりとの違い、見積もり手順、実践例、実務での活かし方、よくある誤解までを整理します。その上で、ベロシティや残ポイントをどう読み取り、次のスプリントの調整や意思決定につなげるかを解説します。

ストーリーポイントの基本

本章では、ストーリーポイントの定義、時間ベースの見積もりとの違い、導入によって得られるメリットを整理します。アジャイル開発で見積もりの精度とチーム内の共通認識を高める考え方として、基本から整理します。

ストーリーポイントの定義

ストーリーポイントとは、アジャイル開発において、開発タスクの大きさをチームで相対的に見積もるための単位です。ここでいう大きさは、単なる作業時間ではありません。作業に必要な量や難しさ、要件の曖昧さなどを含めて評価する点が特長です。

ストーリーポイントを決める際は、主に次の3つの要素を総合的に判断します。

このように、ストーリーポイントは「このタスクは、あのタスクより大きいか小さいか」という相対比較で決めます。担当者ごとの得意不得意や作業速度に引っ張られにくく、チームとして一貫した基準で見積もりやすくなる点が特長です。

アジャイル開発の詳しい内容は、下記の記事をご参照ください。

合わせて読みたい

アジャイル開発とは？特徴や手法・実施の流れについて詳しく解説

アジャイル開発は、仕様に対する柔軟性とスピード感をあわせ持つ開発手法。DX化が進む近年において需要は高まっており、導入する企業が増加傾向です。この記事ではアジャ.....

時間ベースの見積もりとの違い

従来の時間ベースの見積もりは、人日や時間数で工数を見積もる方法です。直感的でわかりやすい一方で、担当者の経験やスキルに左右されやすい側面があります。同じタスクでも、熟練者が担当する場合と経験の浅いメンバーが担当する場合では、完了までにかかる時間が大きく変わるためです。

一方、ストーリーポイントは、個人の作業時間ではなく、タスクの大きさをチームで相対的に評価する手法です。担当者による差に左右されにくく、見積もり基準を揃えやすくなります。

この違いにより、ストーリーポイントは、短期的な作業時間の予測よりも、スプリント全体の計画やチームの継続的な改善に適した見積もり方法と言えます。

ストーリーポイントを用いるメリット

ストーリーポイントを導入する主なメリットは、見積もりの精度を高めやすくなること、チーム内で共通認識を作りやすいこと、個人に過度な負荷をかけにくいことの3点です。

ストーリーポイントの見積もり手順

本章では、ストーリーポイントを実務で運用するための基本手順を6つのステップで解説します。

チームの基準を作る（アンカーストーリー設定）

最初に行うのは、チーム内で見積もりの基準を揃えることです。そのために設定するのが「アンカーストーリー」です。アンカーストーリーとは、チーム全員が内容を理解しており、規模感を共有しやすい代表的なタスクを指します。

例えば、「仕様が比較的明確で、実装範囲も小さいこのタスクを3ポイントとする」と決めておくと、以後の見積もりでは、その基準と比べながら相対的に判断しやすくなります。基準が曖昧なまま見積もりをはじめると、同じタスクでもメンバーごとに評価がぶれやすくなるため、最初に共通の物差しを持つことが重要です。

ストーリーポイントマトリクスを定義する

アンカーストーリーを決めた後は、各ポイントがどの程度の複雑さや不確実性を表すのか、チーム内で目安を定義します。これがストーリーポイントマトリクスです。

マトリクスを用意しておくと、見積もりが個人の感覚だけに依存しにくくなり、判断基準を揃えやすくなります。特に、見積もりに慣れていないチームでは、共通の目安を文章や表で明確にしておくことが有効です。

必要に応じて、ここに「作業量」や「想定される確認項目数」なども補足すると、より実務に即した基準として運用しやすくなります。

フィボナッチ数列を基準値として採用する

ストーリーポイントの見積もりでは、一般的に「1、2、3、5、8、13、21…」といったフィボナッチ数列が使われます。これは、タスクが大きくなるほど不確実性も高まり、細かく正確に見積もることが難しくなるためです。

小さなタスクでは、3ポイントと5ポイントの違いを比較しやすい一方で、大きなタスクになるほど、細かな差を厳密に議論しても実務上の意味は薄くなります。例えば、40ポイントと43ポイントの違いを細かく詰めるよりも、「かなり大きい作業である」と捉えて分割や再整理を検討したほうが現実的です。

このように、フィボナッチ数列を使うことで、見積もりを必要以上に細かくしすぎず、実用的な粒度で意思決定しやすくなります。

プランニングポーカーで合意形成する

見積もりを実施する際によく使われるのが、プランニングポーカーです。これは、各メンバーが個別にポイントを選び、同時に公開することで、先入観に左右されにくい見積もりを行う手法です。

進め方は、次の流れが基本となります。

• 対象タスクの内容や前提条件をチーム全員で確認する
• 各メンバーが見積もりポイントを選ぶ
• 選んだポイントを同時に公開する
• 差が出た理由を確認し、議論の上で合意する

見積もり結果が割れた場合は、誰かが間違っていることではありません。多くの場合、タスクの理解や前提条件に認識差がある状態を示しています。プランニングポーカーの価値は、ポイントを決めることだけではなく、その認識差を早い段階で見つけて解消できる点にあります。

スプリント完了後にベロシティを測定する

見積もりを実務に活かすには、スプリント完了後にベロシティを確認することが欠かせません。ベロシティとは、1スプリントの中で完了したストーリーポイントの合計値であり、チームが一定期間でどの程度の作業を安定して完了できるかを把握するための指標です。

例えば、あるスプリントで3ポイント、5ポイント、8ポイントのタスクを完了した場合、そのスプリントのベロシティは16になります。これを継続的に記録していくことで、チームの実力値や変動傾向を把握しやすくなります。

ベロシティについては、以下の記事で詳しく解説していますので、あわせてご覧ください。

合わせて読みたい

ベロシティとは？アジャイル開発における活用法とイテレーション・プロジェクト管理のポイントを徹底解説

ベロシティを次回スプリント計画に活用する

計測したベロシティは、次回のスプリント計画を現実的に組むための判断材料になります。例えば、平均ベロシティが30のチームが、次のスプリントで50ポイント分の作業を取り込もうとしている場合、計画が過大である可能性が高いと判断できるでしょう。

このとき、ベロシティは「頑張ればできるはず」といった感覚的な判断を抑え、スコープを見直すための客観的な根拠になります。逆に、計画中のポイントが平均ベロシティを大きく下回っている場合は、追加で取り込める作業がないか検討する余地もあります。

このように、ベロシティは単なる結果の記録ではなく、次の計画精度を高めるための指標として使うことが重要です。ストーリーポイントは、見積もって終わりではなく、実績を基に改善を続けることではじめて効果を発揮します。

ストーリーポイント見積もりの実践例

考え方を理解したら、次は実際の見積もりの流れを確認しましょう。本章では、Webアプリ開発を例に、ポイントの付け方から調整の進め方、陥りやすい失敗パターンまでを解説します。

Webアプリ開発におけるポイント割り当て例

ECサイトの機能開発を例に解説します。アンカーストーリーは「利用規約ページの作成」を2ポイントとします。

アンカーストーリーを起点に「それより大きいか、小さいか」で比較することで、チーム内の判断基準を揃えやすくなります。

見積もりが割れた場合の調整プロセス

プランニングポーカーでは、見積もり結果が大きく割れることも珍しくありません。その場合は、次の流れで調整を進めます。

見積もりの差は、認識のズレや前提条件の理解不足を示すサインでもあります。差が出た理由を丁寧に確認することで、見積もりの精度だけでなく、チーム内の共通認識も高めやすくなります。

実践で起きやすい失敗パターン

運用がうまくいかない場合は、いくつかの共通した失敗パターンがあります。あらかじめ把握しておくことで、運用時のトラブルを防ぎやすくなります。

ストーリーポイントを実務で活かす方法

本章では、ストーリーポイントを実務で活用するためのポイントを解説します。

ベロシティから完了時期を予測する

プロジェクト全体のストーリーポイント総量と、チームの平均ベロシティがわかれば、完了までのおおよその期間を予測できます。例えば、以下のような状況を考えます。

この場合、120ポイント ÷ 20ポイント/スプリント = 6スプリントが必要だと見込めます。1スプリントが2週間であれば、6スプリント × 2週間 = 12週間となるため、約3カ月で完了するという見通しを立てられます。

13ポイント以上が多い場合の見直し

バックログに13ポイント以上の大きなタスクが多い場合は、計画上のリスクが高まっているサインです。大きなタスクには、次のような問題が伴いやすくなります。

• 不確実性が高く、見積もり精度が下がりやすい
• 1スプリント内で完了できず、進捗を把握しにくい
• 手戻りが発生した際の影響範囲が大きくなりやすい

13ポイント以上のタスクは、可能であれば8ポイント以下の単位に分割することを検討しましょう。分割することで見積もりの精度を高めやすくなり、スプリント単位での進捗管理もしやすくなります。

追加タスク発生時の調整方法

プロジェクトの途中では、仕様変更や緊急対応の追加を完全に避けることはできません。その場合は、次の観点で対応方針を判断します。

チームのキャパシティには限りがあります。何かを追加する場合は、何を外すかも同時に考えることが、計画の健全性を保つ上で重要です。

未知技術を含むタスクの扱い方

新しいライブラリの導入や事前調査が必要なタスクは、不確実性が高く、最初から正確に見積もることが難しい傾向があります。このような場合は、スパイクと呼ばれる調査専用のタスクを設定します。

＜スパイクの進め方＞

1. 調査や技術検証に充てるタスクを、スパイクとして切り出す
2. スパイク自体にもポイントを割り当てる（例：調査工数として3ポイント）
3. スパイクの結果を踏まえて、本来の開発タスクをあらためて見積もる

不確実性を抱えたまま開発タスクを見積もると、後から大きな計画修正が必要になる恐れがあります。スパイクを挟むことで、前提条件を整理した上で着手しやすくなります。

ストーリーポイントのよくある誤解

本章では、ストーリーポイント運用で現場がつまずきやすい代表的な誤解を整理します。誤った使い方を避けることで、見積もりの形骸化を防ぎ、チームで継続的に活用しやすくなります。

ポイントは時間に換算できるという誤解

「1ポイント＝2時間」のように時間へ置き換える考え方は、ストーリーポイントの目的と合いません。ポイントは作業時間ではなく、タスクの大きさを相対的に捉えるための指標です。時間換算を固定すると、結局は従来の工数見積もりに戻り、個人差によるプレッシャーや見積もりのズレも再び生じやすくなります。

他チームと比較できるという誤解

ベロシティは、各チームが独自の基準で見積もった結果に基づくため、他チームと単純比較はできません。Aチームの30ポイントとBチームの20ポイントが、同じ大きさを示すとは限らないためです。加えて、経験値や技術的負債、業務の複雑さといった前提条件も異なります。ベロシティは、他チームとの優劣比較ではなく、自チームの改善を追うための指標として使う必要があります。

個人評価に使えるという誤解

ストーリーポイントを個人評価に使うと、運用はすぐにゆがみます。高い評価を得るためにポイントを大きく見積もったり、難しいタスクを避けたりする行動が起きやすくなるためです。ストーリーポイントは、あくまでチーム全体で合意した見積もりであり、個人の能力や成果を測るための指標ではないと明確にしておく必要があります。

ストーリーポイントを実務の判断にどう活かすか

ストーリーポイントとベロシティは、記録するだけでは十分ではありません。日々の数値を読み取り、「次に何を調整すべきか」を判断する材料として活用してこそ、実務で機能します。

残ポイントとベロシティから、今調整が必要かを考える

スプリントの中間時点で、残りのストーリーポイントと平均ベロシティを比較すると、計画が無理なく進んでいるかを早めに判断できます。

スプリント終了後に問題へ気付くのでは遅くなりがちです。中間時点で兆候を捉えることが、手遅れになる前の調整につながります。

1ポイントあたりの工数から、負荷が増えていないかを見る

「1ポイントあたりの実績工数」を継続的に確認すると、表面化しにくい負荷の変化を把握できます。例えば、これまで平均「1ポイント＝4時間」だったチームが、最近は「1ポイント＝6時間」になっている場合、何らかの問題が起きている可能性があるでしょう。

考えられる原因としては、次のようなものがあります。

• 技術的負債の蓄積による開発効率の低下
• 問い合わせ対応など、見積もりに含めていない作業の増加
• チームメンバーのコンディション低下

こうした変化を把握できれば、原因を深掘りし、具体的な改善策につなげやすくなります。

バグ比率から、品質を優先すべきかを考える

スプリントで消化した総ポイントのうち、バグ修正に費やしたポイントの割合を「バグ比率」として確認します。

納期を優先して開発を進めた結果、後からバグ対応に追われ、実質的な開発速度が落ちる悪循環は現場で起こりがちです。バグ比率を定期的に確認することで、その兆候を早めに捉えやすくなります。

ストーリーポイントが実務の判断に結びつかない理由

本章では、ストーリーポイントを導入していても、実際の判断に活かせない理由を整理します。数値そのものではなく、見方や運用の仕方に課題があると、見積もりは記録で止まり、意思決定につながりにくくなります。

数値が会議の場でしか確認されない

ストーリーポイントやベロシティが会議の場でしか確認されないと、数値は報告用の情報に留まります。日々の業務と切り離された状態では、今の計画が順調か、調整が必要かをその場で判断できません。数値は特定の場だけで見るのではなく、チームが日常的に確認できる状態にしておくことが重要です。

ベロシティを継続的に見ていない

ベロシティは、単発で確認しても判断材料としては不十分です。複数スプリントにわたる推移を見てはじめて、生産性が安定しているのか、落ちているのか、改善しているのかを捉えられます。継続的に記録と観察を行うことで、傾向が見え、次回以降の計画精度を高めやすくなります。

ポイントと工数が分断している

ストーリーポイントは時間そのものではありませんが、実績工数と完全に切り離すと、見積もりと現実のズレに気付きにくくなります。例えば、5ポイントのタスクに想定以上の時間がかかった場合は、不確実性や前提条件に問題があった可能性があるでしょう。ポイントと実績をあわせて見ることが、次の改善につながります。

複数案件を横断して見ていない

複数案件を並行して進めるチームでは、個別案件だけを見ても全体の負荷は把握できません。A案件が順調でも、B案件で遅れが出ていれば、チーム全体では余力が失われている可能性があります。案件横断で総ポイントや負荷状況を確認できないと、偏りやボトルネックへの対応が遅れやすくなります。

形骸化を防ぎ、判断を1スプリント早めるなら「Lychee Redmine」で可視化を自動化する

本章では、ストーリーポイントを記録で終わらせず、判断に活かすための管理基盤としてLychee Redmineをご紹介します。手作業で分断しがちな可視化を自動化することで、調整判断を早めやすくなります。

残ポイントをリアルタイムで確認できる

Lychee Redmineのカンバンやバックログでは、スプリント全体の総ポイントと完了済みポイントを自動で集計できます。残ポイントをリアルタイムで確認できるため、終盤まで待たずに遅れの兆候を察知しやすくなります。早い段階で調整判断しやすい点も強みです。

ベロシティ推移を履歴で確認できる

Lychee Redmineでは、過去のスプリント実績を基にベロシティの推移を継続的に確認できます。直近の実績や平均値を画面上で把握できるため、別ツールへ転記して管理する手間もかかりません。数値の変化を履歴で追えることで、感覚ではなく実績を基に次の計画を調整しやすくなります。

ポイントと工数を同じチケットで管理できる

Lychee Redmineでは、一つのチケットにストーリーポイントと予定工数・実績工数をあわせて記録できます。同じ画面で確認できるため、「1ポイントあたりにどれだけ工数がかかったか」も把握しやすくなります。ポイントと工数を分けて管理した場合に見えにくい負荷変動も、早い段階で察知しやすいのが特長です。

横断ガントチャートで負荷を把握できる

複数プロジェクトを兼務する現場では、個別案件ごとの管理だけでは全体の負荷を把握しきれません。Lychee Redmineの横断ガントチャートを使えば、組織全体のタスクやメンバーごとの負荷状況を一画面で確認できます。作業の偏りや案件間の競合を早めに見つけやすくなり、再配分の判断もしやすくなります。

ガントチャート×WBS×課題管理が連動する

Lychee Redmineの強みは、ガントチャート、WBS、課題管理を一体で運用できる点です。見積もったタスクが全体工程のどこに位置するかを把握しながら進められるため、判断材料が分断されにくくなります。課題発生時も、スケジュールや工数への影響を同じ基盤で確認できます。

ストーリーポイントに関するよくある質問（FAQ）

本章では、ストーリーポイントの導入や運用に関して、現場でよく挙がる質問と回答を整理しました。

ストーリーポイントは小規模チームでも導入すべきですか？

2〜3人の小規模チームでも、導入する価値は十分にあります。タスクの大きさを相対的に捉え、認識を揃えるプロセスは、チーム規模にかかわらず有効です。少人数でも見積もり基準を共有しておくことで、計画や優先順位の判断を揃えやすくなります。

時間見積もりと併用しても問題ないですか？

チーム内の計画にはストーリーポイントを使い、顧客や上司への説明には時間の目安を補足する使い分けは有効です。ただし、「1ポイント＝X時間」のような固定換算ルールを設けると、ストーリーポイント本来のメリットが失われやすくなるため、避ける必要があります。

ウォーターフォール型開発では使えない？

厳密なウォーターフォール型開発では、時間ベースの見積もりが一般的です。ただし、要件定義や設計段階など、不確実性が高い工程では、部分的にストーリーポイントの考え方を取り入れる余地があります。開発手法に応じて、使いどころを見極めることが重要です。

ベロシティが安定しないのはなぜですか？

主な要因としては、メンバーの入れ替わり、タスク粒度のばらつき、割り込み作業の多さ、稼働率の変動などが挙げられます。ベロシティはすぐに安定するとは限らず、通常は3〜4スプリントほどかけて傾向を見ていく必要があります。原因を確認しながら継続的に改善することが大切です。

管理ツールなしで運用できますか？

Googleスプレッドシートなどを使って運用することは可能です。ただし、プロジェクトが複雑になるほど、手動での集計や更新は負担が大きくなります。ベロシティの集計や複数案件の横断管理まで見据えるなら、Lychee Redmineのような専用ツールを活用する価値があります。

ストーリーポイントは見積もりだけで終わらせない

ストーリーポイントは、見積もりを付けて終わりにするものではありません。残ポイントやベロシティの推移を継続的に確認し、次のスプリントで何を調整すべきかを判断する材料として活用してこそ意味があります。数値を日々の判断につなげることで、ストーリーポイントは、はじめて実務で機能します。

Lychee Redmineでは、残ポイントのリアルタイム集計、ベロシティ推移の可視化、ポイントと工数の一元管理まで、ストーリーポイント運用に必要な情報を同じ基盤で確認可能です。まずは30日間の無料トライアルで、実務で使える管理の流れを確認してみてください。