--- title: "スクラム開発の5つの実践ポイント｜ストーリーポイント見積もりと完成の定義" url: "https://www.issoh.co.jp/column/details/2570/" published: 2024-06-14 updated: 2026-10-12 categories: ["Webシステム"] publisher: "株式会社一創" --- # スクラム開発の5つの実践ポイント｜ストーリーポイント見積もりと完成の定義 スクラム開発でつまずく原因は、役割やイベントの名前を覚えていないことではありません。スプリントを回し始めてから効いてくるのは、ゴールをどう置くか、何をもって「完成」とするか、規模をどう見積もるか、レビューで何を検査するか、そしてチーム独自のルールをどこまで決めるかという5つの運用判断です。 やっかいなのは、この5つのうち見積もりに関する部分がスクラムガイドに書かれていない点です。ストーリーポイントもプランニングポーカーもベロシティも、スクラムの公式ルールではありません。本記事では2020年11月版のスクラムガイド原文で「決まっていること」を確定させたうえで、決まっていない領域をチームがどう埋めるかを整理します。スクラムの役割・イベント・メリットといった全体像は[スクラム開発とは？進め方・役割・メリット・デメリットをわかりやすく解説](/column/details/2336/)で扱っているため、本記事は運用の実務に絞ります。 ## まとめ：スクラム運用でつまずく5つの論点 5つの論点は、スクラムガイドが決めている部分と、チームが自分で決める部分に分かれます。 | 論点 | ガイドの規定 | チームが決める部分 | | ----- | ------------- | ----------- | | ゴール | 2つのゴールが確約 | ゴール文の粒度・検証法 | | 完成の定義 | 未達は提示もリリースも不可 | 標準が無い場合の項目 | | 見積もり | 評価責任は開発者 | 単位・手法・運用 | | レビュー | 最大4時間・最後から2番目 | 参加者の範囲・検査指標 | | ルール | 規定なし | 範囲・見直し頻度 | 規定がある2列目は解釈で揺らさないこと、規定がない3列目はチームで明文化することが要点です。とくに見積もりは、公式ルールだと誤解したまま他チームのやり方を持ち込むと機能しません。 ## スプリントゴールの置き方｜スコープ調整で守るべきもの スクラムガイド2020は、3つの作成物それぞれに「確約（コミットメント）」を対応させています。プロダクトバックログにはプロダクトゴール、スプリントバックログにはスプリントゴール、インクリメントには完成の定義です。それぞれの位置づけは[スクラム開発とは？進め方・役割・メリット・デメリットをわかりやすく解説](/column/details/2336/)の作成物の章にまとめているため、ここでは運用で判断を迫られる2点だけを扱います。 ### スプリント途中でスコープを削る判断 ガイドが確約の主体を名指ししているのはスプリントゴールだけで、「スプリントゴールは開発者が確約するものだが」と明記されています。プロダクトゴールの節には主体の記述がありません。開発者が確約したものである以上、スプリント途中で見込みが外れたときの扱いも決まっています。 原文は「作業が予想と異なることが判明した場合は、スプリントゴールに影響を与えることがないように、プロダクトオーナーと交渉してスプリントバックログのスコープを調整する」としています。スプリントの途中でゴールを書き換えるのは、確約の意味を失わせる運用です。逆に言えば、スコープを削ってもなお達成できるようなゴール文になっているかが、ゴール設定の良し悪しを判定する基準になります。「◯◯機能を実装する」はスコープと不可分なので調整の余地がありませんが、「初回利用者が登録から初回送信までを自力で完了できる状態にする」なら、実装範囲を削りながらでも達成を狙えます。 ### 「ミッション」という用語がスクラムガイドにない事実 スクラム関連の解説では「ゴールとミッションを明確にする」という言い回しをしばしば見かけます。ただし2020年11月版のスクラムガイドを全文検索すると、日本語版の「ミッション」も英語版の “mission” も1回も登場しません。ガイドが定める目標概念はプロダクトゴールとスプリントゴールの2つだけです。 ミッションを語ること自体が誤りというわけではなく、組織の存在意義やプロダクトの意義づけを別途共有するのは有効です。問題は、それをスクラムの規定と混同したまま議論すること。「ミッションを決めましょう」という提案が出たとき、それがプロダクトゴールの言い換えなのか、スクラムの外側にある組織の方針なのかを最初に切り分けておくと、スプリントプランニングで扱うべき議題かどうかがはっきりします。 ## 完成の定義｜インクリメントの品質基準の文章化 完成の定義（Definition of Done）は、ガイドの原文では「プロダクトの品質基準を満たすインクリメントの状態を示した正式な記述である」と定義されています。プロダクトバックログアイテムが完成の定義を満たしたときに、はじめてインクリメントが誕生します。 ### 完成の定義を満たさない作業の扱い 実務で効くのは、未達のときの扱いをガイドが明示している点です。原文は「プロダクトバックログアイテムが完成の定義を満たしていない場合、リリースすることはできない。ましてやスプリントレビューで提示することもできない。そうした場合、あとで検討できるようにプロダクトバックログに戻しておく」としています。 ここまで踏み込んだ規定になっているのは、未完成のものをレビューに出す運用がスクラムの検査機能そのものを壊すからです。「あと少しなので見せてしまおう」を一度許すと、レビューで得られるフィードバックがどの品質水準に対するものか分からなくなります。90%完成という報告をスプリントごとに積み上げても、リリース可能なインクリメントは1つも増えません。未達アイテムはプロダクトバックログへ戻し、次のスプリントで改めて選択し直すのが原則です。 ### 組織標準がある場合とない場合の作り分け 完成の定義を誰が作るかも、ガイドが場合分けしています。組織の標準として完成の定義が存在するなら、すべてのスクラムチームは最低限それに従う必要があります。標準が無い組織では、そのスクラムチームがプロダクトに適した完成の定義を作成する側。1つのプロダクトに複数のスクラムチームが関わる場合は、共通の完成の定義を作成して準拠します。いずれの場合も、開発者は完成の定義に準拠する義務を負います。 「最低限」という表現がポイントで、組織標準はあくまで下限です。チーム側が標準に項目を上乗せするのは規定に沿った運用ですが、標準より緩い定義を独自に採用するのは認められていません。実際に書き出す項目は、コードレビュー完了、自動テストが通っている、対象ブラウザでの動作確認済み、ステージング環境へデプロイ済みといった、検証可能な状態に限定します。「品質が高いこと」「ユーザーが満足すること」のような判定できない項目を入れると、完成の定義が透明性を生むという本来の目的を果たしません。判定に人の解釈が必要な項目を見つけたら、それは完成の定義ではなく受け入れ基準としてアイテム側に書くべき内容です。 ## ストーリーポイント見積もり｜スクラムガイドが規定しない領域 スクラム開発の見積もりというと、ストーリーポイントとプランニングポーカーがほぼ必ず紹介されます。この2つはスクラムの標準的なプラクティスとして広く定着していますが、前提を取り違えたまま導入すると、うまくいかないときに「スクラムのやり方が悪い」と誤診してしまいます。 ### ガイドの規定は「開発者が規模を評価する」の1文だけ 2020年11月版のスクラムガイドを全文検索すると、「ストーリーポイント」「プランニングポーカー」「ベロシティ」は日本語版・英語版のいずれでも登場回数0です。規模に触れているのはプロダクトバックログのリファインメントを説明する箇所の1文で、「作業を行う開発者は、その作業規模の評価に責任を持つ」とあります。英語版の該当文は “The Developers who will be doing the work are responsible for the sizing.” です。加えてリファインメントの説明に、アイテムへ追加する詳細の例として「説明・並び順・サイズ」が挙げられている程度です。 つまりスクラムが決めているのは、規模を評価する責任が開発者にあるという一点だけ。単位を時間にするかポイントにするか、誰が何回投票するか、数列に何を使うかは、すべてチームの裁量です。この線引きを共有しておくと、手法が合わなければ変えてよい、ただし開発者以外が規模を決めるのは逸脱、という判断軸が手に入ります。 ### ストーリーポイントが表す3つの要素 ストーリーポイントを広めた Mike Cohn 氏は、これを「プロダクトバックログアイテムを完全に実装するために必要となる総合的な労力の見積もりを表す測定単位」と定義しています。単純な作業時間ではなく、次の3つが合わさった値です。 - 作業量：やることが多いほどポイントは大きくなる - 複雑さ：試行錯誤や検討を要する作業はポイントを押し上げる - リスクと不確実性：仕様が固まっていない、未経験の技術を使うといった要素もポイントに反映させる 3要素が1つの数値に畳み込まれるため、ポイントは作業時間へ機械的に換算できません。仕様が曖昧なだけで実装量は少ないアイテムに8点が付くこともあり、これは矛盾ではなく設計どおりです。不確実性が下がればポイントも下がるので、リファインメントで仕様を固める作業には見積もりを小さくする効果があります。 ### プランニングポーカーの手順とカードの数列 プランニングポーカーを考案したのは James Grenning 氏で、2002年に米ユタ州American Forkでのことでした。同氏の解説によれば、エクストリームプログラミングの計画ミーティングを進行していたところ、最も経験のある2人が議論を往復させ続け、他のメンバーが置き去りになっていたことが発端です。着想元は1980年代にTeradyneで学んだ「silent grouping」という手法で、各自がまず付箋にアイデアを書き出してから共有・グルーピングする進め方でした。この「先に各自が書く」構造を見積もりに持ち込んだのがプランニングポーカーです。その後2005年に Mike Cohn 氏の『Agile Estimating and Planning』を通じてスクラムのコミュニティへ広まりました。 Mike Cohn 氏が運営する Mountain Goat Software が示す手順は次の9段階です。 1. プロダクトオーナーがプロダクトバックログアイテムを1つ提示する 2. チームが質問して内容を揃える 3. そのアイテムを完成とみなすために何が満たされているべきか、前提を明確にする 4. 各見積もり者が非公開でカードを1枚選ぶ 5. 全員が同時にカードを公開する 6. 見積もりが割れたら、最高値と最低値を出した人が自分の考えを説明する 7. 出てきた新しい情報をチームで議論する 8. もう一度カードを選び直す 9. 共通理解が十分に得られた時点で見積もりを記録する 手順の中心は多数決でも平均値でもなく、最高値と最低値の理由を言語化させる第6段階にあります。数字が割れるのは、アイテムに含まれるリスクや作業範囲の認識が割れている証拠です。平均を取ってしまうとその認識差が数字に埋もれ、スプリント中に想定外として噴き出します。第3段階で完了条件を先に揃えるのも同じ狙いで、完成の定義と接続する部分にあたります。 カードの値は、同社のデッキで 0, 1, 2, 3, 5, 8, 13, 20, 40, 100 が使われます。フィボナッチ数列と説明されることが多いものの、厳密に一致するのは13までで、その先の20・40・100は数列から外れた丸めた値です。大きい側の刻みが粗いのは、規模が大きいアイテムほど見積もりの精度が落ちるためだと説明されています。20以上が出たアイテムは、そのまま見積もるより分割してリファインメントに戻すほうが実務的です。 ### ベロシティを約束や評価指標にしない理由 ベロシティは外部への約束にも、チームや個人の評価指標にも使うべきではありません。 ストーリーポイントは相対値です。基準にするアイテムがチームごとに違う以上、Aチームの5点とBチームの5点は比較できません。チーム間でベロシティを並べて生産性を論じるのは、目盛りの違う定規で長さを比べるのと同じです。同一チーム内であっても、ベロシティを目標値として課した瞬間に、同じ作業へ付ける点数が静かに膨らみます。見積もりが評価に接続されると、見積もりは予測ではなく交渉になるためです。 正しい使い道は、次のスプリントで選択するアイテム量を決める際の参考値と、複数スプリントにわたる傾向の観察に限られます。スプリントゴールが開発者の確約であることを踏まえれば、確約の対象はゴールの達成であってポイントの消化量ではありません。経営層やステークホルダーへ進捗を示す必要がある場合は、ベロシティではなく完成の定義を満たしたインクリメントそのものを提示するほうが、誤解がはるかに少なく済みます。 ## スプリントレビュー｜プレゼンではなくワーキングセッション スプリントレビューは、成果を披露する場ではなく、インクリメントを検査してプロダクトバックログを適応させる場です。ガイドは「スプリントレビューはワーキングセッションであり、スクラムチームはスプリントレビューをプレゼンテーションだけに限定しないようにする」と明記しています。 ### タイムボックスと「最後から2番目」という位置 スプリントが1か月の場合、スプリントレビューのタイムボックスは最大4時間です。スプリントの期間が短ければ、レビューの時間も短くするのが通例です。同じ1か月スプリントを前提としたときのタイムボックスは、スプリントプランニングが最大8時間、スプリントレトロスペクティブが最大3時間、デイリースクラムは期間によらず15分と定められています。 見落とされがちなのが、ガイドがレビューを「スプリントの最後から2番目のイベント」と位置づけている点です。最後ではありません。レビューの後にレトロスペクティブが控えているという順序に意味があり、レビューで得た事実がレトロスペクティブの入力になります。レビューを金曜夕方の最終イベントとして設定してしまうと、この接続が失われます。 ### レトロスペクティブとの切り分け レビューとレトロスペクティブは検査の対象が異なります。レビューが検査するのはインクリメントとプロダクトバックログ、つまり何を作ったかと次に何を作るかです。レトロスペクティブが検査するのは、ガイドの表現では個人・相互作用・プロセス・ツール・完成の定義であり、どう作ったかにあたります。 この切り分けが曖昧だと、レビューの場でステークホルダーを前にして開発プロセスの反省が始まり、本来話すべきプロダクトの方向性が議論されないまま時間切れになります。レビューで進め方の課題が出たときは、その場で結論を出さずレトロスペクティブへ送ると決めておくのが実務的です。逆にレトロスペクティブで完成の定義の見直しが出るのは、ガイドが検査対象に完成の定義を含めている以上、正しい流れです。 ## チームで決めるルール｜スクラムガイド外の運用取り決め スクラムフレームワークは意図的に不完全なものとして設計されており、原文も「スクラムの理論を実現するために必要な部分のみが定義されている」としています。さらに「スクラムの一部だけを導入することも可能だが、それはスクラムとは言えない。すべてを備えたものがスクラムであり、その他の技法・方法論・プラクティスの入れ物として機能するものである」とも述べています。入れ物の中身、つまりチーム独自のルールは自分たちで決める必要があります。 取り決めの対象になりやすいのは、デイリースクラムの進め方、プルリクエストのレビュー担当と応答期限、割り込み依頼の受け口、コミュニケーションツールでの反応期待値といった、ガイドが触れていない日々の摩擦点です。ここでの原則は2つあります。1つは、ガイドの規定を上書きするルールを作らないこと。デイリースクラムを30分にする、完成の定義を組織標準より緩める、といった取り決めはスクラムからの逸脱です。もう1つは、ルールを増やす場ではなく減らす場としてレトロスペクティブを使うことです。 ルールは追加するほど守られなくなります。スクラムの5つの価値基準は確約・集中・公開・尊敬・勇気であり、いずれもルールで強制できる性質のものではありません。縛るべきなのは判断の揺れがコストになる手続き面に限り、態度や姿勢の領域は価値基準の共有に委ねるほうが機能します。チームづくりの具体的な進め方は[スクラムチームの作り方｜強いチームに必要な要素と文化を定着させる手順](/column/details/2336/)で詳しく扱っています。 ## 実践ポイントが効かない場面｜スクラムを見送る判断 ここまでの5つの論点は、スクラムを採用する前提での話です。いくら運用を磨いてもスクラムが噛み合わない状況が3つあります。 最も深刻なのが、完成の定義を満たせるだけの技術的な土台が無い場合です。自動テストもデプロイの自動化も無い状態では、スプリントごとにリリース可能なインクリメントを作るのは現実的ではありません。それでもスクラムを始めると、毎スプリント「今回だけは未完成でもレビューに出そう」という圧力がかかり、完成の定義が数スプリントで形骸化します。前章までに書いた運用の工夫はすべて、完成の定義が守られている前提で成り立つものです。順序としては、スクラムの導入よりエンジニアリング面の整備が先になります。 次に、プロダクトオーナーの役割を担う人が意思決定権限を持っていない場合です。プロダクトバックログの並び順を決められない人がプロダクトオーナーに任命されると、スプリントプランニングのたびに社内の承認待ちが発生し、スプリント期間内に判断が返ってきません。形式は整っているのに何も決まらない状態になります。権限移譲が難しいなら、スクラムの導入より先にそちらを解決すべきです。 最後に、要件が固定されていて変更がほぼ発生しない案件です。スクラムの価値は短い周期で検査と適応を繰り返す点にあるため、ズレが発生しない前提ならイベントの時間は追加コストになります。手法ごとの向き不向きは[ウォーターフォール・アジャイル・スクラムの違い｜3つの開発手法の比較と使い分け](/column/details/1348/)で、アジャイル全体の考え方は[アジャイル開発とは？スクラムの進め方・ウォーターフォールとの違いをわかりやすく解説](/column/details/12850/)で整理しています。 ## よくある質問 ### スクラムポイント（ストーリーポイント）とは何ですか？ プロダクトバックログアイテムの規模を、作業時間ではなく他のアイテムとの相対値で表した数値です。作業量・複雑さ・リスクと不確実性の3つを合わせた総合的な労力を1つの数字にします。スクラムガイド2020には「ストーリーポイント」という用語自体が登場せず、規模の評価責任が開発者にあると定められているだけなので、ポイント制を採用するかどうかはチームの選択です。 ### なぜ時間ではなくポイントで見積もるのですか？ 時間見積もりは担当者の習熟度に左右されるため、誰が担当するか決まっていない段階では合意が取れないからです。たとえば同じ機能でも、経験者なら数時間、初めて触る人なら1日かかることがあります。一方で「このアイテムはあのアイテムの2倍くらいの規模」という相対判断は担当者が変わっても揺れにくく、チーム全員で1つの数字に合意できます。ただしポイントの絶対値に意味は無く、チームをまたいだ比較には使えません。 ### 基準にするアイテムはどう選びますか？ すでに完了していて、チーム全員が内容を具体的に思い出せるアイテムから選びます。小さすぎると大きなアイテムを見積もるときに倍率が跳ね上がって精度が落ちるため、最小サイズではなく中程度のものに2点や3点を割り当てる進め方が扱いやすくなります。基準を決めたら、その値はチームの共通言語になるので途中で変えないこと。メンバーが入れ替わったときは、基準アイテムの内容を新メンバーへ共有する作業が必要です。 ### プランニングポーカーのカードは何を使いますか？ 専用のカードが市販されていますが、トランプや数字を書いた付箋でも代用できます。重要なのはカードそのものではなく、全員が非公開で選び同時に公開するという手順です。これが声の大きい人の意見に引きずられるのを防ぐ仕組みで、考案者の James Grenning 氏が解決しようとした問題そのものにあたります。オンラインの場合は投票結果を一斉表示できるツールを使い、発言順に数字が見えてしまう状態を避けてください。 ### ベロシティはどう計算しますか？ 1スプリントで完成の定義を満たしたアイテムのストーリーポイントを合計します。未完了のアイテムは部分点を付けず0として扱い、次のスプリントへ持ち越します。スクラムガイド2020に「ベロシティ」という用語は登場しないため、これは公式規定ではなく実務上の慣行です。数スプリント分の平均を次回の計画の参考値にする使い方に留め、目標値やチーム間の比較には使わないでください。 ## 関連記事 - [スクラム開発とは？進め方・役割・メリット・デメリットをわかりやすく解説](/column/details/2336/) - [スクラムチームの作り方｜強いチームに必要な要素と文化を定着させる手順](/column/details/2336/) - [ウォーターフォール・アジャイル・スクラムの違い｜3つの開発手法の比較と使い分け](/column/details/1348/) - [アジャイル開発とは？スクラムの進め方・ウォーターフォールとの違いをわかりやすく解説](/column/details/12850/) --- 出典: [スクラム開発の5つの実践ポイント｜ストーリーポイント見積もりと完成の定義]()（株式会社一創）