ストーリーポイントとは？スクラムでの見積もり方とフィボナッチ数列・ベロシティの使い方

ストーリーポイントは、プロダクトバックログアイテムの規模を、時間ではなく他のアイテムとの相対値で表す見積もりの単位です。検索では「スクラムポイント」と入力されることもありますが、スクラムの公式ルールを定めたスクラムガイドにこの用語は出てきません。スクラムのチームが広く使っているだけの、外から持ち込まれた技法です。

本記事では、ストーリーポイントの定義と時間見積もりとの違い、理想日から「ポイント」へ名前が変わった経緯、プランニングポーカーでの決め方、フィボナッチ数列を使う理由、ベロシティで完了時期を見通す計算までを、考案者たちの原文に沿って整理します。スクラムの役割やイベントの全体像はスクラム開発とは？3つの役割・5つのイベントと進め方をスクラムガイド2020で解説で扱っています。

まとめ：ストーリーポイントの要点

数字そのものに意味はなく、同じチームの中で「あのアイテムの2倍くらい」と比べるための目盛りです。目盛りを外へ持ち出して比較や評価に使い始めた時点で、見積もりは予測ではなく交渉に変わります。

ストーリーポイントの定義｜時間ではなく相対的な労力の単位

Mike Cohnの定義と「労力」の中身

ストーリーポイントを広めたMike Cohn氏（著書『Agile Estimating and Planning』2005年、邦訳『アジャイルな見積りと計画づくり』）が運営するMountain Goat Softwareの解説では、ストーリーポイントを「プロダクトバックログアイテムなどを完全に実装するために必要となる総合的な労力の見積もりを表す測定単位」と定義しています。2ポイントのアイテムは1ポイントの2倍の労力で、3ポイントのアイテムの3分の2の労力、という相対関係だけが意味を持ちます。

見落とされやすいのは、Cohn氏が「労力（effort）は時間の問題だ」と書いている点です。そのうえで、労力を決める要素として次の3つを挙げています。

• 作業の量：画面の入力欄が1個か100個か
• 作業の複雑さ：分岐や相互作用がどれだけあるか
• リスクと不確実性：未経験の技術や固まっていない仕様を含むか

日本語の解説では「ストーリーポイントは複雑さを表す」と書かれることがありますが、原典の立場は「複雑さは労力を押し上げる要素の1つであり、ポイントが見積もるのは最終的に労力」です。同氏は入力欄が100個の画面について、複雑さもリスクも1個の画面と変わらないが作業量が多いので、ポイントは大きくすべきだと例示しています（ただし規模の経済があるので100倍にはならない）。複雑さだけで点を付けると、単純だが量の多い作業が過小評価されます。

時間見積もり・人日との違い

時間見積もりは「誰がやるか」に左右されます。同じ機能でも、そのコードを書いた本人なら半日、初めて触る人なら2日かかることは珍しくありません。担当者が決まっていない段階で「何時間か」を合意しようとすると、議論は誰の速さを前提にするかの話にすり替わります。

ストーリーポイントは「このアイテムは基準のアイテムの何倍か」を問うので、担当者の速さを問いません。速い人も遅い人も「ログイン画面の改修より2倍くらい大きい」という比較では一致しやすく、チーム全員で1つの数字に合意できます。Cohn氏も、技能の異なるメンバー同士が見積もりについて話し合い合意できることを、ストーリーポイントの主な価値に挙げています。人時・人日・人月といった絶対単位の換算は工数の単位とは？0.1人月は16時間｜人時・人日・人月の換算早見表と1人月160時間の根拠で整理しています。

契約金額や要員計画のように絶対値が必要な場面では、ストーリーポイントは代わりになりません。ポイントで計画しつつ、発注・契約の場面では人月などの見積もりを別に作るのが現実的です。ボトムアップ・類推・三点見積もりといった絶対値の見積もり手法はボトムアップ見積もりとは？類推・パラメトリック・三点見積りとの違いを比較表と計算例で解説で比較しています。

ストーリーポイントの起源｜理想日から「ポイント」への呼び替え

ストーリーポイントは最初から相対値として設計されたわけではありません。エクストリームプログラミング（XP）の創始者の1人であるRon Jeffries氏が、2019年5月23日の記事「Story Points Revisited」で経緯を書いています。

同氏によれば、XPのストーリーは当初、実装にかかる時間で見積もっていました。まもなく「理想日（Ideal Days）」、つまり邪魔が入らなければペアで何日かかるかという単位に移り、これに「負荷係数（load factor）」を掛けて実際の日数に換算していました。負荷係数はおよそ3で、理想日1日分の作業に実際には3日かかっていたといいます。

問題は、見積もりを「日」と呼んでいたことです。関係者からは「1日分の作業になぜ3日かかるのか」「3週間でなぜ50日分の作業ができないのか」と疑問が出ました。そこで理想日を単に「ポイント」と呼ぶようになり、3ポイントのストーリーは約9日かかる、という運用になった、とJeffries氏は回想しています。

この経緯から分かるのは、ポイントがもともと「時間の単位を、時間と誤読されないように呼び替えたもの」だったことです。Jeffries氏自身は同じ記事で「ストーリーポイントを発明したのは自分かもしれない。もしそうなら、今は申し訳なく思っている」と書き、チーム間の比較や、見積もりと実績の照合に使われる誤用を批判しています（記事の結びでは「少しは申し訳ないが、それほどでもない」と書いています）。

スクラムガイドとの関係｜規定は「開発者が規模を評価する」の1文

スクラムガイド2020年版を日本語版PDF・英語版の両方で全文検索すると、「ストーリーポイント」「ベロシティ」「見積」は日本語版で0回、”story point” “velocity” “estimat” も英語版で0回です。規模について書かれているのは、プロダクトバックログのリファインメントを説明する次の1文だけです。

作業を行う開発者は、その作業規模の評価に責任を持つ。

英語版では “The Developers who will be doing the work are responsible for the sizing.” です。リファインメントは「説明・並び順・サイズなどの詳細を追加するための継続的な活動」とされ、単位や手法の指定はありません。

ベロシティに近い考え方は、スプリントプランニングの節にあります。「開発者が過去の自分たちのパフォーマンス、今回のキャパシティ、および完成の定義の理解を深めていけば、スプリントの予測に自信が持てるようになる」という1文です。進捗の見通しについても「バーンダウン、バーンアップ、累積フローなど、さまざまなプラクティスが存在する」と並べ、「これらの有用性は証明されているが、経験主義の重要性を置き換えるものではない」としています。

ここから導ける線引きは明確です。単位をポイントにするか時間にするか、Tシャツサイズにするかはチームの裁量です。一方で、プロダクトオーナーやマネージャーが規模を決めて開発者に渡す運用は、ガイドの規定から外れます。

ストーリーポイントの決め方｜基準アイテムからプランニングポーカーまで

基準アイテムは完了済みの中程度に2〜3点

相対値なので、最初に「物差し」となるアイテムが要ります。すでに完了していて、チーム全員が中身を思い出せるアイテムを選び、中程度の大きさのものに2や3を割り当てます。最小のアイテムを1にする方法もありますが、中程度のアイテムを基準にすると、大小どちらの方向にも比べやすくなります。

基準は5点用・8点用と複数置いておくと、新しいアイテムを「2点の基準より大きく、5点の基準より小さい」と挟んで判断できます。基準を決めたら途中で変えないこと。変えると過去のベロシティと比べられなくなります。

Webアプリのチームなら、たとえば次のような対応表を作り、見積もりの場に出しておきます（数字は説明用の例で、チームごとに異なります）。

新しいアイテムは表のどれに近いかで決め、どれとも比べられないほど大きければ分割を検討します。

プランニングポーカーの5段階と1〜3ラウンドの目安

プランニングポーカーは、各自が非公開でカードを選び、全員が同時に公開する見積もり方法です。アプリやカードの商品名では「スクラムポーカー」と呼ばれることもあります。Mountain Goat Softwareの手順を要約すると次の流れです。

1. プロダクトオーナーがアイテムを1つ紹介する
2. チームが質問し、完成とみなすために何が満たされるべきかを確認する
3. 各見積もり者が非公開でカードを1枚選び、全員が同時に公開する
4. 数字が割れたら、最高値と最低値を出した人が理由を説明する
5. 新しく出た情報を踏まえて選び直し、十分な共通理解ができたら記録する

同じページは、ラウンドは通常1〜3回で足り、それ以上かかるならアイテムの明確化・分割・プロダクトオーナーの判断が必要なサインだとしています。見積もるのは作業をする人で、プロダクトオーナーは説明役、スクラムマスターは自分も作業をするのでなければ進行役です。

要は第4段階です。3と13が出たとき、間を取って8にしてはいけません。高い数字を出した人は移行作業やセキュリティ審査を想定しているかもしれず、低い数字の人は既存の部品を流用できると知っているかもしれません。平均を取ると、その前提の食い違いが数字に埋もれ、スプリントの途中で想定外として噴き出します。全員が先に個別に見積もってから突き合わせる構造は、デルファイ法とは？名前の由来と手順、合意の判定基準・ワイドバンドデルファイまで解説で扱う合意形成の手法と同じです。

原典のカードは1, 2, 3, 5, 7, 10と無限大

プランニングポーカーを考案したJames Grenning氏の2002年4月の論文「Planning Poker or How to avoid analysis paralysis while release planning」には、印刷して使うカードが添付されています。その値は1, 2, 3, 5, 7, 10日と無限大で、フィボナッチ数列ではありません。単位も「単位のない数、または理想プログラミング日」とされていました。

論文が解決しようとしていたのは、2人が延々と議論して残りのメンバーが置き去りになり、1ストーリーに20分を費やす会議でした。カードを同時に出す方式にした結果、ほとんどのストーリーは1分ほどで見積もれたと書かれています。2週間を超えるストーリーには無限大のカードを出して顧客に分割させる、合意できなければ保留・分割・低いほうの見積もりを採る、という割り切りも原典の時点で入っています。

大量のアイテムはアフィニティ見積もりで先に仕分け

プランニングポーカーは1件ずつ議論するので、数十件のバックログを一度に見積もるには時間がかかります。Mountain Goat Softwareは、大まかな数字だけ必要なアイテムが大量にあるなら、アフィニティ見積もり（アイテムを大きさ順に並べてグループに分ける方法）を最初に使うほうがよいとしています。まず大量のアイテムを素早く仕分け、大きいもの・意見が割れそうなもの・直近で着手するものだけをプランニングポーカーにかける、という併用は、Mountain Goat Softwareも「多くのチームが両方を使う」と紹介しています。

フィボナッチ数列を使う理由｜13の次が20・40・100になるわけ

プランニングポーカーのカードとして広く使われているのは、Mountain Goat Softwareが典型例として示す 0, 1, 2, 3, 5, 8, 13, 20, 40, 100 です。13まではフィボナッチ数列（前の2つの和が次の数）と一致しますが、20・40・100は数列から外れた丸めた値で、「修正フィボナッチ」と呼ばれます。

数字の間隔が大きくなっていく理由は、大きなアイテムほど見積もりの精度が下がるからです。Grenning氏も原典で「見積もりが長くなるほど精度は下がる」と書いています。20と21を区別しても意味がないので、選択肢を粗くして無駄な議論を省きます。6か7かで5分議論するより、5か8かを選ばせたほうが速く、Grenning氏も、細かく刻んでも精度はあまり上がらないだろうと書いています。

実務上は、1つのアイテムがチームのベロシティの大半を占めるほど大きいなら、1スプリントで完成しない危険が高いので、見積もりを確定するより分割してリファインメントに戻すほうが有益です。数字以外のカードも用途があります。「?」は理解が足りず見積もれない、無限大は大きすぎて今は見積もれない、コーヒーカップは休憩が必要、という合図です。

Tシャツサイズは直感的ですが、合計できないのでベロシティを計算できません。初期の仕分けに使い、計画に入る段階で数値に置き換えます。

ベロシティの計算と完了時期の見通し方

ベロシティの計算例

ベロシティは、1スプリントで完成の定義を満たしたアイテムのポイントの合計です。5点・3点・2点のアイテムが完成し、8点のアイテムが途中で終わったなら、ベロシティは10です。途中のアイテムに部分点は付けません。完成の定義を満たさないものはスプリントレビューで提示できず、プロダクトバックログに戻すというのがスクラムガイドの規定で、ベロシティの数え方もそれに合わせます。

完了時期は幅で見通す

直近3スプリントのベロシティが18・22・20で、残りのバックログが合計120ポイントだとします。平均20で割れば6スプリントですが、最小の18なら6.7、最大の22なら5.5です。スプリントの途中では終われないので端数を切り上げ、見通しとしては「6〜7スプリント」と幅で伝えます。1点の数字で約束すると、ベロシティの自然なばらつきだけで「遅延」になります。

この計算が成り立つのは、同じチームが同じ基準で数スプリント見積もり、ベロシティが安定しているときだけです。なお、Jeffries氏はポイントで完了時期を予測すること自体を「せいぜい弱いやり方」と評しています。新しいチームの最初の数スプリントや、メンバーが大きく入れ替わった直後は、ベロシティが乱高下して見通しに使えません。バックログ自体も開発中に増減するので、見通しはスプリントレビューのたびに更新します。契約・要員計画で使う時間見積もりの予実差をどう測り精度を上げるかは見積もり精度とは？予実差の測り方と段階別の目安、精度が上がらない原因と改善手順で扱っています。発注側としてスコープと見積もりの前提をそろえる段階から支援が必要な場合は、要件定義・RFP作成・PMO支援も用意しています。

評価指標・目標値にすると壊れる理由

ベロシティを目標値にすると、同じ作業に付く点数が膨らみます。ベロシティを倍にする最も簡単な方法は、全員がすべての見積もりを2倍にすることだからです。評価に結び付いた見積もりは、もう規模の予測として読めません。

チーム間の比較も成り立ちません。基準アイテムがチームごとに違うので、Aチームの5点とBチームの5点は別の目盛りです。Jeffries氏は前出の記事で、チームの技能も環境も違う以上、同じに見えるストーリーに一方が2、他方が6を付けても比較の材料にならないとし、見積もりの質やベロシティでチームを比べるのは有害だと述べています。進捗を経営層に示す必要があるなら、ポイントの消化量ではなく、完成したインクリメントそのものを見せるほうが誤解がありません。

Jiraでストーリーポイントを使う設定

Jira Cloudのチーム管理対象スペースでは、Atlassianのサポート文書によれば、スペース設定の「機能」で見積もり（Estimation）を有効にし、ストーリーポイントか時間かを選びます。有効にすると作業項目に「Story point estimate」フィールドが追加され、値は数値で小数も入力できます。見積もりの単位を選ばない場合、作業は「作業項目数」で測られます。会社管理対象スペースでは設定の場所が異なり、キーボード操作の案内でもフィールド名は「Story Points」と表記されています。

小数を入力できるからといって、0.5刻みで細かく付け始めると、ポイントが時間の言い換えに戻っていきます。カードの値以外は入れない、とチームで決めておくほうが運用は安定します。Jiraのスペースやエピックの使い分けはJiraの使い方｜スペース作成・エピックの使い分けと「使いにくい」の解消法【2026年10月】で解説しています。

ストーリーポイントを使わない選択｜アイテムを小さく切る運用

ストーリーポイントは必須ではありません。スクラムの資格認定団体Scrum.orgの公式ブログでも、Chris Belknap氏が2019年7月29日の記事「Moving Beyond Velocity」で、ベロシティをストーリーポイントで測る必要も、ストーリーポイント自体を使う必要もないと書いています。見積もりそのものを問い直す「#NoEstimates」の議論は、Woody Zuill氏が2012年12月10日に始めた「No Estimate Programming」の連載をきっかけに広がりました。

Jeffries氏は前出の記事で、ストーリーの見積もりの代わりに「ストーリーの分割（スライシング）」を勧めています。大きなストーリーを価値のある小さな単位に切り、理想的には1日未満、場合によっては2〜3時間で終わる大きさにそろえるという方法です。切り方の目安として、Neil Killick氏から学んだ「受け入れテストが1つで済むまで切る」という方法も紹介しています。大きさがそろえば、ポイントを付けなくても完成したアイテムの数で進み具合が分かります。

ストーリーポイントを使わないほうがよいのは、次のような状況です。

• 経営層や他部署がベロシティでチームを比べる、または目標値を課すことが止められない
• アイテムがすでに1日前後の大きさにそろっていて、ポイントを付けても差がほとんど出ない
• 見積もりの会議がスプリントの中で最も時間を食い、議論の中身が数字の値切り合いになっている

逆に、アイテムの大きさが数時間から数週間までばらつき、プロダクトオーナーが「この機能は高くつくから後回しにする」といった並び順の判断に規模の情報を必要としているなら、ストーリーポイントは役に立ちます。Jeffries氏自身も、チームや会社に大きな価値をもたらしていないなら無駄としてやめればよく、気に入っているなら続ければよい、と結んでいます。ポイントは目的ではなく、計画と並び順の判断に使う道具の1つです。ふりかえりで見積もりのやり方そのものを見直す進め方はレトロスペクティブとは？スクラムでの進め方とふりかえりの材料を自動で集める実装を参照してください。

よくある質問

ストーリーポイントと工数の違いは何ですか？

工数は人時・人日などの絶対的な時間で、誰が担当するかによって変わります。ストーリーポイントは基準アイテムと比べた相対的な労力で、担当者の速さを問いません。そのためポイントはチーム内の計画には使えますが、契約金額の算出やチーム間の比較には使えません。

ストーリーポイントにフィボナッチ数列を使う理由は何ですか？

アイテムが大きくなるほど見積もりの精度が落ちるので、数字の間隔を広げて細かすぎる区別を省くためです。13の先を20・40・100と丸めた修正フィボナッチがよく使われます。なお、プランニングポーカーの原典（2002年）のカードは1, 2, 3, 5, 7, 10と無限大で、フィボナッチ数列は後から広まった選択肢の1つです。

ストーリーポイントはどうやって決まるのですか？

チームで基準となる完了済みアイテムを決め、新しいアイテムがその何倍の労力かを比べて決めます。多くのチームはプランニングポーカーを使い、全員が非公開で選んだカードを同時に公開し、最高値と最低値の理由を聞いてから選び直します。スクラムガイドでは、規模を評価するのは作業をする開発者と定められています。

1ストーリーポイントは何時間ですか？

決まった換算はありません。換算表を作ってしまうと、ポイントは時間の別名になり、担当者によって見積もりが変わる時間見積もりの弱点がそのまま戻ってきます。結果として「このチームは1スプリントで約20ポイント完成させる」というベロシティから間接的に時間との関係が見えるだけです。

ベロシティは他のチームと比較できますか？

できません。基準アイテムがチームごとに違うので、同じ5ポイントでも表す大きさが異なります。比較すると、ベロシティの低いチームが見積もりを大きく付け直すだけで数字が上がり、実際の生産性は何も変わりません。複数チームでポイントの基準をそろえる（正規化する）手法もありますが、Jeffries氏はそれでもチームを比較する罠に陥りやすいと警告しています。

関連記事

• スクラム開発とは？3つの役割・5つのイベントと進め方をスクラムガイド2020で解説
• アジャイル開発とは？スクラムの進め方・ウォーターフォールとの違いをわかりやすく解説
• ウォーターフォールとアジャイル・スクラムの違い｜比較表と使い分け・契約形態の選び方
• ボトムアップ見積もりとは？類推・パラメトリック・三点見積りとの違いを比較表と計算例で解説
• 見積もり精度とは？予実差の測り方と段階別の目安、精度が上がらない原因と改善手順