ブログ

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のプラクティスを組み合わせて実施されることが多い。代表的なプラクティスとしては、ペアプログラミング、テスト駆動開発、継続的インテグレーションなどである。

それでは。

アジャイルコーチングやトレーニングを提供しています

株式会社アトラクタでは、アジャイル開発に取り組むチーム向けのコーチングや、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください。

詳細はこちら
  • スクラム実践者が知るべき97のこと
  • 著者/訳者:Gunther Verheyen / 吉羽龍太郎 原田騎郎 永瀬美穂
  • 出版社:オライリージャパン(2021-03-23)
  • 定価:¥ 2,640
  • スクラムはアジャイル開発のフレームワークですが、その実装は組織やチームのレベルに応じてさまざまです。本書はスクラムの実践において、さまざまな課題に対処してきた実践者が自らの経験や考え方を語るエッセイ集です。日本語書き下ろしコラムを追加で10本収録
  • プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける
  • 著者/訳者:Melissa Perri / 吉羽龍太郎
  • 出版社:オライリージャパン(2020-10-26)
  • 定価:¥ 2,640
  • プロダクト開発を作った機能の数やベロシティなどのアウトプットで計測すると、ビルドトラップと呼ばれる失敗に繋がります。本書ではいかにしてビルドトラップを避けて顧客に価値を届けるかを解説しています。
  • SCRUM BOOT CAMP THE BOOK 【増補改訂版】
  • 著者/訳者:西村直人 永瀬美穂 吉羽龍太郎
  • 出版社:翔泳社(2020-05-20)
  • 定価:¥ 2,640
  • スクラム初心者に向けて基本的な考え方の解説から始まり、プロジェクトでの実際の進め方やよく起こる問題への対応法まで幅広く解説。マンガと文章のセットでスクラムを短期間で理解できます。スクラムの概要を正しく理解したい人、もう一度おさらいしたい人にオススメ。
  • みんなでアジャイル ―変化に対応できる顧客中心組織のつくりかた
  • 著者/訳者:Matt LeMay / 吉羽龍太郎、永瀬美穂、原田騎郎、有野雅士
  • 出版社:オライリージャパン(2020-3-19)
  • 定価:¥ 2,640
  • アジャイルで本当の意味での成果を出すには、開発チームだけでアジャイルに取り組むのではなく、組織全体がアジャイルになる必要があります。本書にはどうやってそれを実現するかのヒントが満載です
  • レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス
  • 著者/訳者:David Scott Bernstein / 吉羽龍太郎、永瀬美穂、原田騎郎、有野雅士
  • 出版社:オライリージャパン( 2019-9-18 )
  • 定価:¥ 3,132
  • レガシーコードになってから慌てるのではなく、日々レガシーコードを作らないようにするにはどうするか。その観点で、主にエクストリームプログラミングに由来する9つのプラクティスとその背後にある原則をわかりやすく説明しています。
  • Effective DevOps ―4本柱による持続可能な組織文化の育て方
  • 著者/訳者:Jennifer Davis、Ryn Daniels / 吉羽 龍太郎、長尾高弘
  • 出版社:オライリージャパン( 2018-3-24 )
  • 定価:¥ 3,888
  • 主にDevOpsの文化的な事柄に着目し、異なるゴールを持つチームが親和性を高め、矛盾する目標のバランスを取りながら最大限の力を発揮する方法を解説します
  • ジョイ・インク 役職も部署もない全員主役のマネジメント
  • 著者/訳者:リチャード・シェリダン / 原田騎郎, 安井力, 吉羽龍太郎, 永瀬美穂, 川口恭伸
  • 出版社:翔泳社( 2016-12-20 )
  • 定価:¥ 1,944
  • 米国で何度も働きやすい職場として表彰を受けているメンローの創業者かつCEOであるリチャード・シェリダン氏が、職場に喜びをもたらす知恵や経営手法、より良い製品の作り方などを惜しみなく紹介しています
  • アジャイルコーチの道具箱 – 見える化の実例集
  • 著者/訳者:Jimmy Janlén / 原田騎郎, 吉羽龍太郎, 川口恭伸, 高江洲睦, 佐藤竜也
  • 出版社:Leanpub( 2016-04-12 )
  • 定価:$14.99
  • この本は、チームの協調とコミュニケーションを改善したり、行動を変えるための見える化の実例を集めたものです。96個(+2)の見える化の方法をそれぞれ1ページでイラストとともに解説しています。アジャイル開発かどうかに関係なくすぐに使えるカタログ集です
  • カンバン仕事術 ―チームではじめる見える化と改善
  • 著者/訳者:原田騎郎 安井力 吉羽龍太郎 角征典 高木正弘
  • 出版社:オライリージャパン( 2016-03-25 )
  • 定価:¥ 2,138
  • チームの仕事や課題を見える化する手法「カンバン」について、その導入から実践までを図とともにわかりやすく解説した書籍。カンバンの原則などの入門的な事柄から、サービスクラス、プロセスの改善など、一歩進んだ応用的な話題までを網羅的に解説します。
  • Software in 30 Days スクラムによるアジャイルな組織変革“成功"ガイド
  • 著者/訳者:Ken Schwaber、Jeff Sutherland著、角征典、吉羽龍太郎、原田騎郎、川口恭伸訳
  • 出版社:アスキー・メディアワークス( 2013-03-08 )
  • 定価:¥ 1,680
  • スクラムの父であるジェフ・サザーランドとケン・シュエイバーによる著者の日本語版。ビジネス層、マネジメント層向けにソフトウェア開発プロセス変革の必要性やアジャイル型開発プロセスの優位性について説明
  • How to Change the World 〜チェンジ・マネジメント3.0〜
  • 著者/訳者:Jurgen Appelo, 前川哲次(翻訳), 川口恭伸(翻訳), 吉羽龍太郎(翻訳)
  • 出版社:達人出版会
  • 定価:500円
  • どうすれば自分たちの組織を変えられるだろう?それには、組織に変革を起こすチェンジ・マネジメントを学習することだ。アジャイルな組織でのマネージャーの役割を説いた『Management 3.0』の著者がコンパクトにまとめた変化のためのガイドブック