スクラムは、スクラムガイドで定義されています。したがってスクラムを学習したり実践したりする際には、まずスクラムガイドを読むのが大前提となります。とはいえ、短時間で人に説明したり、リファレンスが必要になったりすることも多いので、弊社で使っている用語集を共有します。

基本用語

プロダクトオーナー

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

開発者

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

スクラムマスター

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

スクラムチーム

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

ステークホルダー

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

スプリント

1か月以下のタイムボックス。この期間内に開発チームは要求事項を「完成」させ、動作するリリース判断可能なインクリメントを作る。 スプリントは1か月以内の短いプロジェクトとも考えることができる。 スプリントが終了したら、進捗や状況などを正確に把握し、状況に応じた調整をおこなった後、速やかに新しいスプリントを開始する。

スプリントプランニング

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

デイリースクラム

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

スプリントレビュー

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

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

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

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

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

プロダクトバックログ

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

スプリントバックログ

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

リリース判断可能なインクリメント

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

関連用語

完成の定義

プロダクトとして定めた「リリース判断可能なプロダクト」を作成するために実施しなければいけないことの一覧。例えば、ユニットテストがある、カバレッジ80%以上である、統合テストがおこなわれている、リリースノートが書かれている、レビューがおこなわれているなどである。プロダクトバックログ項目の完成の定義、スプリントの完成の定義、リリースの完成の定義など、複数に分割することもある。完成の定義は作っているプロダクトによって異なる。開発を進めていく中で完了の定義を縮小することは許容されない。

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

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

スクラムボード

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

相対見積り

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

受け入れ基準 （Acceptance Criteria）

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

ベロシティ

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

ユーザーストーリー

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

妨害事項リスト（Impediments List）

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

Scrum of Scrum

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

XP（eXtreme Programming）

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

それでは。