5分で分かるスクラム用語集

みなさんこんにちは。@ryuzeeです。

スクラムは、スクラムガイドで定義されています。したがってスクラムを学習したり実践したりする際には、まずスクラムガイドを読むのが大前提となります。

とはいえ、短時間で人に説明したり、リファレンスが必要になったりすることも多いので、ぼくが使っている用語集を共有します。

更新履歴

2021年11月27日スクラムガイド2020に対応しました。

基本用語

プロダクトオーナー

開発するプロダクトにおける責任者である。そのプロダクトが実現するビジネス価値に対して責任を負う。主な役割としてプロダクトのビジョンを明らかにして周りに伝える、プロダクトバックログのメンテナンス、プロダクトバックログアイテムの並び順の決定、リリース計画の立案、開発者が作成したインクリメントを受け入れるか受け入れないかの判断、ステークホルダーとの調整などがある。実施中のスプリントをキャンセルすることができる唯一の存在である。プロダクトオーナーはスクラムマスターと兼任しないほうがよい。

開発者

実際にプロダクトを開発するメンバーのことを指す。開発者全員を集めると、例えばデータベースの管理、アプリケーションの開発、テストなどプロダクトを作るために必要なことは全てをおこなえる必要があり、このことをクロスファンクショナルと呼ぶ。開発者の仕事のやり方は開発者同士で合意して決めることができる。スクラムにおいては開発者の人数は8人程度まで（プロダクトオーナーとスクラムマスターをあわせて10人程度）とされており、開発者は同じ場所にいるのが望ましい。これ以上の人数で構成される場合はスクラムチームの分割をおこなう。

スクラムマスター

スクラムチームがスクラムの価値を理解しプロセスを正しく実践できることに責任を負う。主な役割として教育、コーチング、チームへの奉仕的な活動、組織への働きかけなどがある。またプロダクトオーナーと開発者が円滑なコミュニケーションできるようにしたり、外部からの妨害からチームを守るよう働きかけたりする責任がある。

スクラムチーム

プロダクトオーナーとスクラムマスターと開発者の集合のこと。

ステークホルダー

プロダクトの利用者やスポンサー、社内の上司や他部門など、プロダクトに対して利害関係を持つ人を指す。スクラムチーム自身もステークホルダーに含まれる。スクラムにおいてはプロダクトの機能や構築の順番などはプロダクトオーナーが最終決定権限を持ち、ステークホルダーは直接開発者に機能の構築や要件の変更を指示することはできない。あくまでプロダクトオーナーに対して伝えることになる。スプリントレビューに参加してプロダクトに対してフィードバックすることは可能であり、良いプロダクトを作る上で、そのフィードバックはとても重要である。

スプリント

1か月以下の固定の期間。この期間内に開発者はプロダクトバックログアイテムを「完成」させ、動作するリリース判断可能なインクリメントを作る。スプリントは1か月以内の短いプロジェクトとも考えることができる。スプリントが終了したら、速やかに新しいスプリントを開始する。

スプリントプランニング

スプリント内での作業を計画するイベント。スプリントプランニングにはトピックが3つある。 1つ目のトピックでは、このスプリントで達成したいスプリントゴールを検討する。 2つ目のトピックでは、スクラムチームはスプリントゴールを達成する上で実現するプロダクトバックログアイテムを、プロダクトバックログの上位から選択する。プロダクトバックログからどれくらいのプロダクトバックログアイテムを実現するかは、開発者のこれまでの作業実績（ベロシティなど）から予測を立て、最終的には開発者が責任を持つ。 3つ目のトピックでは、開発者が中心になって選択したプロダクトバックログアイテムをどう実現するかを検討し（作業レベルまで分解することが多い）、より具体的で詳細な計画を作成する。なお、トピック3で詳細に計画を立てた結果トピック2で取り上げたプロダクトバックログアイテムはやはり実現できないといった判断をすることもある。

スプリントプランニングのタイムボックスは1か月スプリントの場合で8時間。スプリントが短い場合はそれに応じてスプリントプランニングの時間も短縮することが多い。

デイリースクラム

スプリントがスプリントゴールの達成に向けて進んでいるか検査し、何かあれば即座に解決を促すためのイベント。毎日、同じ場所にて、同じ時間から開始し15分以内で終了する。立ったままスクラムボードの前でやることも多い。スプリントゴール達成の可能性を検査し、必要に応じて今後の作業を調整したり、再計画したりする。スプリントゴールを達成するために昨日やったこと、今日やること、困っていることを開発チーム全員が話すこともあるが、このフォーマットは必須ではない（2017年版スクラムガイドでオプションとなり、2020年版スクラムガイドで記述が消えた）。解決に時間がかかるような問題の解決や議論の場ではないので、そのような内容は別の会議を設ける。

スプリントレビュー

スプリントの最後から2番めに実施されるイベント。スプリントで作成したインクリメントをステークホルダーに示しフィードバックを得る。必要があれば今後のスプリントの進め方について話しあい、プロダクトバックログを調整する。スクラムチームはスプリントで完成した作成物だけをデモできる（未完成のものは披露しない）。最大の目的は参加したステークホルダーからフィードバックを得て、それによってプロダクトの価値をさらに向上すべく、今後のプロダクトバックログを見直すことにある。

スプリントレトロスペクティブ

スプリントの最後にスクラムチームの改善のためにおこなうイベント。改善のためにおこなうので実行可能な改善点を出すことが求められ、重要な改善は速やかに行う。どのようなやり方をするのかはスクラムでは決められていない。 KPTというやり方がよく使われるが、やり方はこれ以外にも多数あり、状況に応じて選択するとよい。多数の改善案を出しても一度に変更することは評価を難しくしてしまうため、大きな効果がありそうなことに絞るとよい。

プロダクトバックログリファインメント

プロダクトバックログは常に最新の状態になっていなければいけない。最新の状態とは、必要なプロダクトバックログアイテムが追加されている、不要なプロダクトバックログアイテムが削除されている、適切に並びかえられている、直近で着手しそうな上位のプロダクトバックログアイテムのサイズが見積もられていて、1スプリントで収まるサイズになっており、開発するのに大きな不明点がないといったことである。このような状態を維持するために、スクラムチームは日頃から時間を取って、プロダクトバックログを手入れする。この活動のことをプロダクトバックログリファインメントと言う。この活動はいつ実施するか決められていないが、スプリントの中間くらいの時期にやることが多い。

プロダクトバックログ

プロダクトを作成するにあたってのゴール（プロダクトゴール）とそれを実現するのに必要なことを順番に並べたリスト。リストの上位のものほど早く実現されることになる。一般的にはビジネス価値の高いものが上位に来る傾向にある。直近のスプリントで手を付けるプロダクトバックログアイテムは詳細に記述されており、リストの末尾にいくに従ってあまり詳細ではなくなる。定期的に見直す必要がある。順番の並べ替えについてはプロダクトオーナーが責任を持ち、他の責任によって順番が変えられることはない（変更の提案は可能）。スクラムチームの作業の唯一の情報源になる。

スプリントバックログ

スプリントゴールと、スプリントで実施するプロダクトバックログアイテムと、それを分析し具体的な実行計画に落とし込んだもののセット。タスクに分割することが多いが、そのほかの方法でも構わない。プロダクトバックログでは通常、実装に関する記述をおこなわないが、スプリントバックログの実行計画は開発者がそのスプリントを完成させるために必要な作業であるため具体的に記述するのが一般的である。作業は、最大8時間程度のサイズより小さなサイズに分割することが望ましい。また、理想時間（チームの平均的な能力のメンバーが集中してそれに取り組んだ場合にかかるであろう時間）によって見積もることも多い。

インクリメント

完成の定義を満たしており、リリースしようと思えばリリースできるプロダクトのこと（実際にリリースするかどうかはビジネスの状況などによる）。特定の部品や技術層だけを作り込んでも、利用者に価値がなければ意味がなく、一気通貫で利用者に役立つことが求められる。

完成の定義

プロダクトとして定めた「リリース判断可能なプロダクト」を作成するために満たさなければいけない品質の基準のこと。例えば、ユニットテストがある、カバレッジ80%以上である、統合テストがおこなわれている、リリースノートが書かれている、レビューがおこなわれているなどである。完成の定義は作っているプロダクトによって異なる。開発を進めていく中で完成の定義を拡張していくこともある。

関連用語

以下はスクラムで定義されていないものの関係のある用語です。

スプリントバーンダウンチャート

スプリントの進捗を可視化し課題発見のきっかけにするためのチャート。横軸にスプリント内の日数、縦軸に残り作業の見積り時間の合計を毎日プロットする。毎日決まった時間（デイリースクラム前にやることが多い）に更新する。チャート上には理想線と呼ばれる理想の推移線を引き、この理想線に対して実際の推移がどのようになっているかを比較していくことで開発の進捗が明らかになる。理想線と比較してバーンダウンチャートが収束に向かわない場合はスクラムチームで話しあい早めに解決方法を考える。

スクラムボード

スクラムでプロダクトを開発する際にスクラムチームの道具として用意するボードのこと。プロダクトバックログアイテムやスプリントバックログのタスク、バーンダウンチャート、妨害リストなどを掲載するのが一般的。全員同席しているスクラムチームの場合は壁やホワイトボードを使って作成する。それによって見える化を促進する。特に決められた形式はないのでスクラムチームは自分たちの必要性に応じて掲載するものを増やしたり、レイアウトを変更したりしてよい。

相対見積り

プロダクトバックログアイテムを見積もる際に、具体的な人月や人日で見積もるのではなく、小さめのプロダクトバックログアイテムと比較してそれと比べてどれくらいの大きさなのかという観点で見積もる方法。時間などの物理単位で見積もった場合には、開発者によって見積りが大きく異なったり、見積りの誤りが計画に与える影響が大きくなったりするが、相対的に見積もることでそれらの問題を解決する。

相対見積りのやり方は複数あり、よく使われるのが、ストーリーポイントによる見積りと、Tシャツサイズによる見積りである。ストーリーポイントの場合は、プランニングポーカーと呼ばれるカードを使ってポイントを算出する

開発者全員で見積もるのが一般的である。これは実際に作業をする人たちの見積りがいちばん正確である、という考えによる。そのため、見積りの結果についてはプロダクトオーナーは干渉できない。

受け入れ基準（Acceptance Criteria）

プロダクトオーナーの視点から何を持ってプロダクトバックログアイテムが完成したかを確認するための基準。インクリメントは「完成の定義」と「受け入れ基準」の両方を満たして、はじめて完成となる。ユーザーストーリー形式で要求事項が書かれている場合は、実際のユーザーの操作をシナリオ形式に記述したデモ手順を受け入れ基準にすることもある。

スプリント0

実際のスプリントを開始する前におこなう、開発をスタート可能にするための準備期間のこと。プロダクトバックログの準備、開発環境の準備、スクラムチームの作業場所の準備、完成の定義の作成、技術的な検証などをおこなう。このフェーズではリリース判断可能なプロダクトが作られないため長い時間を取らないことが望ましい。おおよそ第1スプリントの開発をおこなうのに十分になればよい。スクラムの正式なプラクティスやルールではない。

ベロシティ

開発のおおよその速度を表す指標で、1つのスプリント（XPの場合はイテレーション）で「完成」したプロダクトバックログアイテムの見積りポイントの合計値のことである。たとえば、5ポイント、3ポイント、2ポイントのアイテムが完成した場合は、ベロシティは10ポイントになる。

直近2〜3スプリントの平均値を開発の速度として使うケースが多く、改善を進めていくとスクラムチームのベロシティは緩やかに向上していき、その後安定することが多い。

ユーザーストーリー

顧客がソフトウェアで実現したいことを詳細に文章化するのではなく、ソフトウェアを利用する実際のユーザーに何をさせたいかに焦点を当てて簡潔に要求事項を表す書き方である。スクラムで規定された書き方ではないが、採用例が多い。各要求事項で達成したいゴールとプロダクトにもたらす価値の記述に注力することで、適切なタイミングでの開発者とプロダクトオーナーの会話を促す。これにより、文書化に頼りすぎない進め方がし易くなる。

妨害事項リスト（Impediments List）

スクラムを円滑に実施し、プロダクト開発を進める上で、スクラムチームでは解決できない事項のことを妨害事項と呼ぶ。これらを管理した一覧表を妨害事項リストと呼び、スクラムマスターが管理する。スクラムマスターは記載された一覧を並べ替えて、組織への働きかけなどをしながら順番に対応していく。なお、これは必須の作成物ではない。

Scrum of Scrum

複数のスクラムチームでスクラムを実施する場合に、プロダクト全体で解決すべきことがあるかを確認するために実施する。各スクラムチームのデイリースクラム後にスクラムチームの代表やスクラムマスターが集まり、単一のスクラムチームだけでは解決できない課題の有無を確認し、何か問題があればすぐに解決のためのアクションや議論する会議を設定する。また、組織的にスクラムを導入している現場では、各プロダクトで解決できない課題を確認する会議として実施されることもある。

XP（eXtreme Programming）

正式名称はエクストリームプラグラミング。ケント・ベックらによって提唱されているアジャイル開発手法の1つ。開発者が日々おこなうべきプラクティス（実践すべき項目）が多く規定されているのが特徴である。スクラムはプロセスにフォーカスを当てているため、開発者がすべきこととしてXPのプラクティスを組み合わせて実施されることが多い。代表的なプラクティスとしては、ペアプログラミング、テスト駆動開発、継続的インテグレーションなどである。

それでは。