スクリーンショット_2019-07-08_8

スクラム用語集

アジャイル開発のひとつの手段である、スクラムについての用語をまとめてみました。スクラムには19の要素があると言われています※1。
前提として、スクラムの要素には大きくわけて4つのカテゴリがあります。
原則、役割、セレモニー(イベント)、アーティファクト(造形物)です。19の要素はそれぞれどこかのカテゴリに属します。上記マインドマップをご参照ください。
原則はスクラムチーム内で必ず気にしなければならないことです。
役割はそのまま役割です。
セレモニー(イベント)は、スクラムチーム(ときにはスクラムチーム外からも招待する)で実施する会議・打ち合わせです。
アーティファクト(造形物)は、スクラムのセレモニーにて生み出される物理的・電子的な”モノ”になります。それだけでは成果とは直接結びつかないものもあるため、成果物とは言わず、造形物と記しています。

以下は、スクラムの19の要素になります。

透明性

スクラムの3つある原則の1つ。
プロダクトやスクラムチームの情報が、重複なく管理され、チーム内の誰もがどこをみれば必要な情報が把握できるか瞬時に言えること。
セキュリティ対策にて見えない情報がある場合、その理由をチーム内の誰もが把握し、理解していること。

検査

スクラムの3つある原則の1つ。
プロダクトバックログに仮説とアクセプタンス・クライテリア(受け入れ条件)を表明し、その仮説の成否を検査する。検査の主な方法は、スプリントレビューである。スクラムでは、少なくとも1スプリントに1回必ず検査をする必要がある。

適応

スクラムの3つある原則の1つ。
スクラムは1スプリントに1回必ず検査を実施するが、検査結果、計画やスコープを柔軟に変更していく必要がある。これが適応となる。スプリントレビューの結果、プロダクトバックログリファインメントにてプロダクトバックログが更新され、変化に頻繁に適応していく。

スプリント(Sprint)

スクラムのセレモニー(イベント)の1つ。
スクラムは、スプリントと呼ばれる定まった期間を決め、その期間を繰り返していく。定まった期間は、1週間、2週間、3週間、4週間のいずれかである。1週間スプリントであれば、1週間スプリントを永続して続けていく。4週間スプリントであれば、4週間スプリントを永続して続けていく。

プロダクト・オーナー(Product Owner/PO)

スクラムの役割の1つ。
スクラムチームのROI(投資対効果)に責任を持つ。
プロダクトバックログの優先順位を最終的に決める責任を持つ。
最終的に決めるだけであって、開発チームがプロダクトバックログに口を出していけない訳ではなく、プロダクトバックログはスクラムチーム全員で作っていくものである。ただ、最終的な優先順位の決定権は、プロダクト・オーナーにある。

開発チーム(Team)

スクラムの役割の1つ。
プロダクトバックログ・アイテムをどのように(HOW)に実現するかを決め、実現する責任を持つ。また、プロダクトバックログ・アイテムがそのスプリント内で実現できる大きさを超えている場合は、そのアイテムをプロダクトオーナーに断る責任も持つ。その場合、アイテムを分割したり、他のアイテムを実現していいかプロダクトオーナーと相談する。開発チームの人数は7±2人もしくは3±6人と定められている。どちらにしろ9人を超えてはコミュニケーションパスが多くなり効果的な協働ができないとされている。クラフトマンシップを持ち、常に生産性の向上を気にかけること。

スクラムマスター(Scrum Master/SM)

スクラムの役割の1つ。
スクラムチームのスクラムが適切に運用されていることに責任を持つ。
逆に、プロダクトの成功や失敗には何ら責任を持たない。
「適切に運用されている」とは、透明性・検査・適応が滞りなくスクラムチーム内に浸透していることを指す。スクラムの原則、役割、セレモニー(イベント)、アーティファクト(造形物)が適切にスクラムチームから生み出されていることに責任を持つ。手段として、情報の見える化、スクラムのセレモニー(イベント)を必ず提供すること、必要であればセレモニーのファシリテーションを行う。スクラムチームのプロダクトバックログの管理・更新を支援する。開発チームやプロダクト・オーナーに対して、コーチングやメンタリングを必要であれば提供する。開発チームに対するプロダクト・オーナー以外からの妨害(インペディメント)を阻止する責任もある。

プロダクト・バックログ(Product Backlog)

スクラムのアーティファクトの1つ。
プロダクトのアイディアが一覧化され、優先順位がつけられたもの。個々のアイディアは「プロダクト・バックログ・アイテム(Product Backlog Item)」と呼ばれる。どのプロダクト・バックログ・アイテムを選択し、先へ進めるかについて、スプリントプランニングにてプロダクトオーナーと開発チームは合意をとる。選択されたプロダクト・バックログ・アイテムをどのように実現するか、を開発チームはスプリントプランニングでさらに詳細化する。プロダクトバックログは、プロダクト・バックログ・リファインメントにて、最新化される。プロダクトバックログアイテムには、アクセプタンス・クライテリア(受け入れ条件)の記載があり、スプリントレビューにてそのアイテムの完了・未完了を見極めるためにアイテム毎に記載される。プロダクトバックログの表現の手段として、ユーザーストーリや、プロダクトをユーザがどのように扱うかという視点で全体的な物語化された手法をユーザーストーリーマッピングと言う。スクラムでは厳密に、プロダクトバックログがこうあるべきだというものは明確化しておらず、実現手段については幅をもたせている。明確になっているのは、「プロダクトのアイディアが一覧化され、優先順位がつけられたもの」という一点である。「優先度」ではなく「優先順位」である点は注意。

プロダクト・バックログ・リファインメント(Product Backlog Refinement)

スクラムのセレモニー(イベント)の1つ。
プロダクト・バックログをプロダクトオーナーと開発チームで最新化する。中長期のプロダクトの計画を建て、それをプロダクト・バックログに入れ込む。直近数スプリント分のプロダクト・バックログ・アイテムは、開発チームがすぐに実現を検討できるぐらいに詳細化されていると良い。最新化とは、プロダクト・バックログ・アイテムの追加・削除・更新・分割・統合・優先順位決め・目的の共有である。とくに優先順位が高いアイテムに関して、プロダクトオーナーが勝手に変えてそのまま共有されない、という状態だと開発チームとの間に不信感が生まれる可能性があるので、なるべくこのリファインメントの時間を活用して、周知共有を行う。スクラムをはじめたばかりのチームでは、よくこのリファインメントを忘れがちである。リファインメントを適切に実施していないと「プロダクトの計画がわからない」「プロダクトオーナーが何を考えているのかわからない」などの透明性の欠如につながる。
おおよその目安は、スプリント期間の5〜10%の時間をこのリファインメントに費やす。2週間スプリントなら、4時間は必要(2時間を2回でも構わない)。

アクセプタンス・クライテリア(Acceptance Criteria)(受け入れ条件)

スクラムのアーティファクトの1つ。
プロダクト・バックログ・アイテムの実現をプロダクト・オーナーが受け入れるための条件を記載したもの。機能要求やアイディアを実現する上での制約や環境条件が記載される。BDDの実現手段の1つであるGiven/When/ThenのGivenにあたるものを記載する。Givenは、その機能を実行する前の、実行状態のことである。スプリントレビューでは、開発チームが実現したプロダクト・バックログ・アイテムに関して、この受け入れ条件を満たしているかを確認する。もちろん、スプリントレビューに入る前に確認しても良いし、優秀な開発チームであれば頻繁にプロダクトオーナーとコミュニケーションを取り、不安や懸念があれば確認をしておく。

完了の定義(Definition of Done)

スクラムのアーティファクトの1つ。
プロダクトをリリースできる(カスタマーに届く)ところまでの、今現在わかっているすべての"やるべきこと"を洗い出し、その"やるべきこと"がスプリント内でできる(DONE)のか、できないのか(UNDONE)を明確に定義したもの。スコープは主にテクニカル品質である(非機能品質)。
スプリント内でできるものであれば、それをチームが必ず実行する、実行するときの明確な定義を開発チーム・プロダクトオーナーで共有し、確認しあう。
例えば、ソフトウェア開発でDONEの例であれば、ソースコードがコード管理システムにコミットされていること、静的解析のAランク指摘が0件であること、など。UNDONEの例としては、アプリのストア申請と承認、ヘルプファイルの作成、外部認証期間における認証テストなどがある。開発チーム外が実施する作業が多くでる。
また、スプリント内でできない(UNDONE)が明確になった際には、おおよそそのUNDONEをするために必要な期間、誰がどうやるのかを明確にしておき、スプリントの期間外で実施するのか、UNDONEを潰すためのスプリントを用意するのかをスクラムのスプリントを開始する前に、プロダクトオーナーは開発チームとともに明確にしておかなければならない。そうしないと、開発するプロダクトが、スプリントが終わってから長い期間リリースできない、とうことになりかねない。

スプリント・プランニング(Sprint Planning)

スクラムのセレモニー(イベント)の1つ。
まず、このスプリントでやるべき最優先のスプリントバックログアイテムを開発チームがプロダクトバックログから取得する。優先順位の高いアイテムから、そのアイテムをどのようにスプリント期間内で実現するか開発チーム内で議論する。議論の結果、アイテムをやりきれない可能性も出る。その場合はアイテムを分割して、ここまでならやりきれるということをプロダクト・オーナーと相談する。開発チームはアイテムをタスクとして詳細化し、スプリント・バックログにスプリントの計画を記す。タスクはなるべく細かく詳細化し、スプリント期間内ではあとは実際に手を動かすだけ、というぐらい詳細にやるべきことを詰めることが重要である。目安としては、個々のタスクの見積もり時間が30分〜4時間以内になるくらいが望ましい。スプリント・プランニング自体は非常に時間をかけるべきである。2週間スプリントの場合は、1日〜1日半かかることもある。ソフトウェア開発の場合、このプランニング時に、設計作業まで含めてやってしまうことが多い。

スプリント・バックログ(Sprint Backlog)

スクラムのアーティファクトの1つ。
スプリント・バックログは、スプリント・プランニングにて開発チームが、建てた計画を可視化したものである。開発チームのために必要なものなので、どのようなフォーマットが良いかなど、可視化の手段は開発チームが選択して良い。ただ、熟練したスクラムマスターであれば、デジタルツールではなく、アナログのバックログの利点を多く語れるはずである。開発チームはこのバックログを毎日のデイリースクラムで確認しながら、互いの認識と情報を共有しあう。もし進捗が良くない場合は、開発チームメンバー同士が助け合いながらスプリントを遂行していく。

デイリー・スクラム(Daily Scrum)

スクラムのイベント(セレモニー)の1つ。
毎日決まった時間・場所にて行う、開発チームの同期を取るイベントである。15分以内のタイムボックスを決めて行う。明確なアジェンダは決められていないが、だいたい以下の3点を開発メンバーが報告しあう。
・前回のデイリースクラムから今までやったこと
・これから次回のデイリースクラムまでに自分がやること
・課題や困ったことがあれば
デイリースクラムでは、問題解決のほうへ議論を持っていかず、お互いの情報と認識を同期させることに集中する。もし課題が出てきてそれを議論したくなった場合は、デイリースクラムが終わってから必要なメンバーのみを集めて行うで良い。

スプリント・レトロスペクティブ(Sprint Retrospective)

スクラムのイベント(セレモニー)の1つ。
振り返りとも呼ばれる。
開発チームが、自分たちの働き方や仕事の良し悪しについて議論し、次以降のスプリントに繋がる最低1つのアクションアイテムを出す。このアクションアイテムは、チーム内で閉じるような時間のかからないものもあれば、プロダクト・オーナーと相談し、プロダクト・バックログ・アイテムとしてプロダクト・バックログに追加することもある。よくKPTという手法が用いられることが多いが、KPTに限らず、開発チームで活発な意見交換や議論ができると良い。このレトロスペクティブでは、開発チームが何に対しても何でも言える、いわば心理的安全性が確保されていることが望ましい。

スプリント・レビュー(Sprint Review)

スクラムのイベント(セレモニー)の1つ。
そのスプリントのインクリメントを、プロダクトオーナーと開発チームにて確認するイベントである。目安としては、2週間スプリントだと2時間ほどかける。常にこのスプリントでできたインクリメントを触って、インクリメントに対して議論をする。今回のスプリントのプロダクト・バックログ・アイテムの何ができたか、できなかったのか、受け入れ条件は満たせているかを確認する。このスプリントレビューで出た意見はプロダクト・バックログに反映させることもあるし、させないこともある。次のリファインメントを待たず、その場で反映できると非常に効率的である。
ソフトウェア開発であれば、例えばGUI、ボタンの位置がどうこうなどの細かい指摘がスプリント・レビューに出るということは、プロダクトオーナーと開発チームがスプリント中に密に連携を取れていない証拠である。スプリント・レビューで初めてお披露目にしてまうとこのようなことが起こる。
なるべくスプリントレビューでは、できたインクリメントに対して、このインクリメントを市場にどう適応していくか、などの一段視座の高い議論ができると好ましい。また、プロダクト・オーナーに加えて、ステークホルダーの参加も有効的である。

インクリメント(Potentially Shippable Product Increment)

スクラムのアーティファクトの1つ。
スプリントの成果物のことをスクラムではインクリメントと呼ぶ。
インクリメントはスプリントレビューでレビューをする対象である。必ず最新のインクリメントが動作する状態でなければ、スプリントレビューができない。よって、必ずインクリメントが動く状態にしておくことは開発チームにとって非常に重要なことである。開発チームは、完了の定義を満たし、受け入れ条件をすべて満たすインクリメントができてはじめて、そのスプリントを達成したことになる。

スプリント・ストップ(Sprint Stop)

スクラムのイベント(セレモニー)の1つ。
スプリント中に市場の動向が変わり、選択したプロダクト・バックログ・アイテムを実現することに意味がなくなった場合は、プロダクト・オーナーはスプリントをストップさせることができる。そのスプリントをストップし、すぐリファインメントに入る。スプリントの途中でストップした場合、スプリントの終わりが歪になることがあるので、それを避けるため、スプリントのリズムは保持しつつ、プロダクトバックログリファインメントを行うことが多い。(例えば、1週間スプリントで月曜はじまり金曜終わりだとして、水曜日にスプリントストップがかかったとしても、次のスプリント開始はリズム通り、月曜日にする。残った木・金曜日は、プロダクト・バックログ・リファインメントに企てる、など。)

インペディメント・リスト(Impediment List)

スクラムのアーティファクトの1つ。
インペディメント・リストは、開発チームに対して入る妨害を一覧化して可視化しておくものである。インペディメント・リストのオーナーはスクラムマスターである。スクラムマスターはチームへの妨害を記録し、なるべく妨害を阻止するために働く。これもスクラムマスターが懐にしまっておくものではなく、チームのスプリントバックログやプロダクトバックログの近くに可視化して置かせてもらい、スクラムに関するメンバーに耐えず見ていただくようにすることが重要である。


本当は19の要素以外にも、良く聞く単語を集めてここに載せたかったが、長くなりすぎたので別記事にします。


※1: 認定スクラムトレーナである @ebackyから2015年8月に聞きましたが、2019年6月現在でも19の要素のままのようです。


この記事が気に入ったら、サポートをしてみませんか?気軽にクリエイターを支援できます。

2

Koki Shimizu

【組織・プロセス・プロダクト改善】 アジャイル・スクラムをメインとして、チームによる、より良い仕事の仕方、製品開発、組織活性化、チームビルディングをご支援します! アジャイルコーチ、スクラムマスター、プログラマ Certified Scrum Professional

スクラム

コメントを投稿するには、 ログイン または 会員登録 をする必要があります。