ブログ

ryuzeeによるブログ記事。不定期更新

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

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

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

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

更新履歴

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

基本用語

プロダクトオーナー

開発するプロダクトにおける責任者である。そのプロダクトが実現するビジネス価値に対して責任を負う。 主な役割としてプロダクトのビジョンを明らかにして周りに伝える、プロダクトバックログのメンテナンス、プロダクトバックログアイテムの優先順位付け、リリース計画の立案、開発者が作成したインクリメントを受け入れるか受け入れないかの判断、ステークホルダーとの調整などをおこなう。作業自体は委任できるが、最終的な責任はプロダクトオーナーが負う。 実施中のスプリントをキャンセルすることができる唯一の存在である。 スクラムガイドに記載はないものの、プロダクトオーナーはスクラムマスターと兼任しないことが強く推奨される。

開発者

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

スクラムマスター

スクラムチームがスクラムの価値を理解しプロセスを正しく実践できることに責任を負う。 主な役割としてコーチング、ファシリテーション、チームや組織への奉仕的な活動などがある。 またプロダクトオーナーと開発者が円滑なコミュニケーションできるようにしたり、外部からの妨害(例えば割り込みタスクやスプリントで実施するプロダクトバックログアイテムの変更や追加など)からチームを守ったりする責任がある。 スクラムガイドに記載はないものの、スクラムマスターはプロダクトオーナーと兼任しないことが強く推奨される。

スクラムチーム

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

ステークホルダー

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

スプリント

1か月以内の固定の期間。 この期間内に開発者はスプリントゴールを達成し、動作するリリース判断可能なインクリメントを作る。 スプリントは1か月以内の短いプロジェクトとも考えることができる。 スプリントが終了したら、進捗や状況などを正確に把握し、状況に応じた調整をおこなった後、速やかに新しいスプリントを開始する。

スプリントプランニング

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

デイリースクラム

スプリントがスプリントゴールの達成に向けて進んでいるか検査し、何かあれば即座に解決を促すためのミーティング。 毎日、同じ場所にて、同じ時間から開始し15分以内で終了する。立ったままスクラムボードの前でやることも多い。 このまま進めてスプリントゴールが達成できそうかを確認する。 スプリントのゴールを達成するために昨日やったこと、今日やること、困っていることを開発者全員が話すこともあるが、このフォーマットは必須ではない。 解決に時間がかかるような問題の解決や議論の場ではないので、そのような内容は別の会議を設ける。

スプリントレビュー

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

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

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

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

プロダクトバックログアイテムは、スプリントで着手する前までに準備ができた状態になっていなければいけない。 そのため、前のスプリントなどで事前に時間をとって、上位のプロダクトバックログアイテムの中身を見て、疑問点がないかを確認し、見積りを済ませておく。 この活動はいつ実施するか決められていないが、スプリントの中間くらいの時期にやることが多い。

プロダクトバックログ

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

スプリントバックログ

スプリントゴールと、その実現に必要なプロダクトバックログアイテムのサブセットと、実際の作業計画をまとめたもの。

インクリメント

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

完成の定義

プロダクトとして定めた「リリース判断可能なプロダクト」を作成するために実施しなければいけないことの一覧。 例えば、ユニットテストがある、カバレッジ80%以上である、統合テストがおこなわれている、リリースノートが書かれている、レビューがおこなわれているなどである。 完成の定義は作っているプロダクトによって異なる。 完成の定義を満たさないとプロダクトバックログアイテムは完成とならないため、スプリント1を始める前に決める。

関連用語

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

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

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

スクラムボード

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

相対見積り

プロダクトバックログアイテムの見積もる際に、具体的な人月や人日で見積もるのではなく、小さめのプロダクトバックログアイテムと比較してその何倍なのかという観点で見積もる方法。プランニングポーカーと呼ばれるカードを使って開発者全員で見積もる。見積りの結果についてはプロダクトオーナーが干渉することは許されない。 時間などの物理単位で見積もった場合には、メンバーによって見積りが大きく異なることになったり、見積りの誤りが計画に与える影響が大きくなったりするが、相対的に見積もることでそれらの問題を解決する。

受け入れ基準 (Acceptance Criteria)

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

スプリント0

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

ベロシティ

開発の速度を表す指標で、スプリントで「完成」したプロダクトバックログアイテムの見積りポイントの合計値のことである。 スプリントの実施回数が決まっている場合は開発できる機能の合計サイズ=ベロシティ×スプリント数となり、逆に全ての機能を作成する場合は、スケジュール=総見積りポイント数÷ベロシティとなる。 直近2〜3スプリントの平均値を開発速度として使うケースが多く、改善を進めていくと開発者のベロシティは向上していく。

ユーザーストーリー

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

妨害事項リスト(Impediments List)

各ロールの責務が果たせていない場合や、正しくスクラムイベントが実施されていないなどのスクラムで規定されていることができていない事象や改善すべき事項を妨害事項と呼ぶ。これらを管理した一覧表を妨害事項リストと呼び、日々見つかった妨害事項が記載されている。スクラムマスターがこの一覧を管理し、記載された項目に順序を付ける。そして、その順番に基づいて妨害事項を解決していく。 なお、これは必須の作成物ではない。

Scrum of Scrum

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

XP(eXtreme Programming)

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

それでは。