この記事は最近スクラムを勉強し始めた筆者が、飲み込みやすい言葉でスクラムのイメージを身につけられないか？と思い自分なりの解釈や例えを交えてスクラムを話し言葉でまとめたものです。厳密な理解をしたいという方は原文を熟読してください。

原文：https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf
※スクラムガイドの著作権について把握しきれなかったので問題があったら削除いたします。

スクラムガイドの翻訳をした⾓征典さん、荒本実さん、和⽥圭介さん、著者のKen SchwaberとJeff Sutherlandに深く感謝いたします。

スクラムの定義

スクラムとは、ややこしい問題を簡単に飲み込めるようにして「こんな難しい作業はこんな短期間でできない」とか「そもそもなんでこんなことをやるのか？意味はあるのか？？」みたいにならないように、気持ちよく仕事を進められるようになるための方法論（フレームワーク）。
そのためにはスクラムマスター（とプロダクトオーナー）という役職を用意して、下に書いてあるようなやり方で仕事を回す必要がある。

プロダクトオーナーは、やらなきゃいけないことややった方が良いことをプロダクトバックログというTODOリストみたいなところに並べていく。
一緒に仕事してる人たち（スクラムチーム）は、スプリントというみんなで決めた期間（二週間とか三週間）の中でやることを決めて、決めたことをやることでプロダクトの価値を積み上げていく。（この価値を積み上げる行為のことを「作業を価値のインクリメントに変換する」のように言う。インクリメントについての話はまた後でする）
スクラムチームと、スクラムチームの成果を心待ちにしている人たち（お客さんとか上司とか営業の人たちのこと。ステークホルダーとも言う）は、今回のスプリントで得たみんなの成果を都度チェックして次のスプリントをどうしていくかを考えていく。
この１〜３の流れをひたすら繰り返していくのがスクラム。

スクラムと言うのは本来簡単なものだから、気負わずまずはシンプルに試してみるべき。そしてスクラムのやり方で本当にみんなが気持ちよく仕事できてるかを確認するべき。スクラムの方法論は必要最小限のことだけが決められた不完全なもので、それはあえて不完全なものにしている。なぜかというとスクラムを実際にやっている人たちの経験知こそが本当の「スクラム」を作るものだと思っているから。要するにスクラムと言うのはああしなさいこうしなさいみたいな口うるさい指示じゃなくて、あくまでみんなが気持ちよく仕事するためのガイドに過ぎない。

スクラムは上で言った通り単なるガイドで細かい指示ではないので、スクラムの中でいろんなやり方を試すことができる。スクラムはいろんな方法論と組み合わせで使えたり、あるいはスクラムを使っていく中でそれが別に必要なかったみたいなことがわかったりもする。スクラムにはそういう効果もある。

スクラムの理論

スクラムは「経験主義」と「リーン思考」がベースになってる。要するにみんなが仕事していく中でもっとこうしようああした方がいいみたいな感じで知見が生まれて、今みんながこう思っていてプロダクトがこういう状態だから次はこうしよう、みたいな感じで意思決定が進んでいくやり方。その過程では一人一人が無駄なことを省いて、今本当にやらなきゃいけないことはなんだろう？と考えていくことが大切。

スクラムでは事故を起こさずみんなが予想できる範囲内で仕事を進められるように、同じようなことを繰り返して物事をちょっとずつ前に進めていくようなやり方をみんなに勧めている。螺旋階段をぐるぐる回ってちょっとずつ上に進んでいく、みたいな感じで仕事を進めていくイメージ。
スクラムのプロジェクトに参加できるのは、プロジェクトに書かれているタスクをこなすのに必要な能力を全て兼ね備えている人たち。ただし、メンバー一人一人がみんな完璧な能力を持っていなくても、チーム全体として必要なタスクをこなす力があれば一人一人のスキルはでこぼこでも構わない。逆に言うとメンバーが必要に応じて他のメンバーにちゃんと必要なスキルを教えたり、自分で頑張って勉強して必要なスキルを身につけなくちゃいけない。それはメンバーの義務。

スクラムでは、プロジェクトをちゃんと回すために適宜４つのイベントを行う。それらは「スプリント」と言うみんなで決めた期間（これもイベントの一つ）の中で発生する。この４つのイベントはスクラムで一番大切な**「透明性」「検査」「適応」**という概念を実現するためのもの。これらの具体的な意味は下で説明するが、これらを実現できていないイベントはイベントとして成り立たないから注意。

透明性

自分のやっていることは、自分自身と自分のやったことを評価してくれる人がちゃんと理解できないと意味がない。「そもそもなんでこんなことをやっているのか？」とか「この人は今何をしているのか？意味のあることをしているのか？」と言ったような不安とか疑念が自分や他の人に湧いている状態はとてもよくない。なぜなら、そんな状態で仕事を続けたら「こんな意味のないことやめて、もっとこういうことしたい！」と言った発想につながり、チームの成果や価値を否定して、勝手な方向にプロジェクトが走っていくことを意味することになるから。
なのでそういう状態にならないように、自分のやっていることを自分含めたみんながちゃんと理解できるようにすることが大切。

この「透明性」を維持することで、次に書く「検査」ができるようになる。逆に言うと、この「透明性」がないと「検査」をしても意味がない。

検査

自分や他の人が作ったものと、みんなでここまで作ろうと決めたスケジュールとその進み具合はこまめに熱心にチェックしないといけない。こまめに熱心にチェックすることで、予想外の変化とか異常にいち早く気づけるようになる。それをプロジェクトの検査と呼ぶ。
例えば、三ヶ月に一回こまめに健康診断に行く人と、三年に一回しか健康診断に行かない人とで、どっちが健康で長生きしそうかは言うまでもない。人間の癌と同じで、プロジェクトの癌も早期発見が大切。

スクラムでは下で紹介していく「イベント」を定期的に行っていくことでプロジェクトの検査、プロジェクトの定期健康診断を行っている。

この「検査」を行うことで次に紹介する「適応」ができるようになる。逆に言うとこの「適応」を行わないと「検査」をしても意味がないとされている。健康診断をこまめにしてもその後に治療や生活習慣改善をしないんだったら意味がないのと同じ。

適応

自分たちがやっていることがどうも計画通りにいかなくなった時（明らかに工数が足りない、品質が酷すぎるなど）とか、お客さんから「こんなんじゃ使いものになんないんだよな」みたいなことを言われた時は、今やっていることとかメンバーの体制とかを急いで手直しする必要がある。放っておくとどんどん傷が広がるので、気づいた時に急いでプロジェクトの改善方法を模索することが大切。

逆に言うと、メンバーに手直しする権限が与えられていないとか、そもそもメンバー自身に治そうというモチベーションがない、みたいな状況だとしんどい。スクラムは検査によって得た知見をすぐに改善活動に活かしていく姿勢がメンバーみんなに求められる。

スクラムの価値基準

スクラムが成功するかは、**「確約」「集中」「公開」「尊敬」「勇気」**の５つの価値基準を日々の業務で実践できるかどうかにかかっている。

スクラムチームはゴールを達成し、みんなで協力し合うことを確約する。チームメンバーはこのゴールに向かって一歩でも前進できるように、とにかく前を見てスプリント内でやると決めた作業に集中する。チームメンバーとステークホルダーは、自分のやっていることや今抱えている問題を包み隠さずみんなに公開する。（ちょっと言いづらいようなことでも隠し事はNG）そしてメンバーはそれぞれ隣にいるメンバーを独立した個人として尊敬し、また自分もメンバーから尊敬されなくてはいけない。メンバー一人一人は、正しいことをする勇気や困難な問題に立ち向かう勇気を必要とする。「あーあの人にこんなこと指摘するのきついなあ。。」とか「あーこんな難しそうなこと面倒くさいからやりたくないなあ。。」みたいな弱い心を打ち破る勇気が大切。

上で書いた価値基準は、メンバー一人一人がどのようにチームで仕事をしていくべきかを示している。みんなが決めることやみんなでやることは、上で書いた文章に相反するようなやり方で進めていってはいけない。メンバーはスクラムのイベントなどをこなしていく中で、上で書いた文章通りの仕事をするというのは自分にとって具体的にどういうことなのかを、自分自身で自問自答しながら学んでいかなくてはいけない。みんなが上で書いた価値基準を具体的な方法で行えているときにこそ、スクラムで一番大切な概念である**「透明性」「検査」「適応」**が具体的な業務で実践され、みんなが仲良く気持ちよく仕事できるようになる。

スクラムチーム

スクラムは基本的に、「スクラムチーム」という小集団で成り立っている。この集団は「スクラムマスター（1人）」「プロダクトオーナー（1人）」「開発者（複数人）」で成り立っている。このチームには一次受け二次受けみたいな階層構造があるとか、サブチームがある（チームの中に「開発チーム」「テストチーム」みたいな区分がある）みたいなことはない。なぜかというと、スクラムチームというのは一つの目的（プロダクトゴール）を集中して達成できるように組織された専門家集団であるべきだからである。階層があったりサブチームがあったりすると、チームの中で目的がバラバラになって一つの目的にみんなで向かえない。だからそのような形はスクラムチームではNG。

スクラムチームは各スプリントで必要なタスクを全てこなせるようなスキルをチームとして兼ね備えていなくてはいけない。一つの機能を完成して世に出すのが目的だったら、その過程で必要な仕様策定、調査研究、設計、実装、テスト、リリース、保守運用までを横断して一つのチームで行えるようになっていなくてはいけない。
そして、チームは自分たちで自立していなくてはいけない。いつどこで何をどのようにするべきかを、他の誰でもなく、チーム内の話し合いによって決定しなくてはいけない。民主主義でなくてはいけない。上から強い要望があったとしても、ちゃんとみんなで話し合って、みんなが納得した上で進めないといけない。

スクラムチームでは、みんなが直接民主主義で話し合って意思決定できるくらいの小ささと、業務をチーム内だけで完遂できるだけの大きさが両方求められる。普通は10人以下。小さいチームの方がみんな仲良くイキイキと仕事ができるという調査結果もある。スクラムチームがどうしても大きくなってしまう場合は、同じプロダクトを扱う複数のスクラムチームにグループ分けする必要がある。その場合はプロダクトゴールやプロダクトバックログ（さっき説明した、プロダクトに関するTODOリストみたいなやつ。後で詳しく説明する）、そしてプロダクトオーナーをチーム間で共有していく必要がある。

前に書いたように、スクラムチームは仕様策定、調査研究、設計、実装、テスト、リリース、保守運用など、プロダクトを前に進めるために必要な全ての活動をできるようになっていなくてはいけないし、それをすることの責任を持っている。スクラムチームは自分たちのやることを自分たちで決められる権限と決める義務を持った組織である。無理のないペースでスプリントの作業を行っていくことで、一つの目的に集中して邁進できるようになる。

スクラムチームはチームとして、スプリント（みんなで決めた一定の期間の区切り）ごとにプロダクトを前に進められたという具体的な証拠（新しい機能とか目に見える改善など）を作り上げる責任を持っている。そしてスクラムはチームの登場人物である開発者、プロダクトオーナー、スクラムマスターの三役の役割を明確に決めている。

開発者

開発者はスクラムチームの一員で、各スプリントごとにプロダクトを前に進めるためのあらゆる機能（の一部分）を作成することを確約する。
開発者が必要なスキルは作業によって当然異なり幅広くなるが、次の事項に対しては常に責任を持っている。

スプリント内でやることリスト（スプリントバックログ）を作る責任
どうしたら完成なのか？を明確に決めておくことで、品質の高いものを作り込む責任
スプリントのゴールに向けて毎日、やろうとしていることやそのスケジューリングなどの調整（適応）を行う責任
専門家としてのそれぞれが持つ自分の仕事に対する責任

プロダクトオーナー

プロダクトオーナーは、スクラムチームから生み出されるプロダクトの価値を120％以上にすることが使命であり責任。今いるチームの力を最大限に引き出して、今作り得る中で最高のプロダクトを生み出すためにできることをなんでもやるポジション。

プロダクトオーナーは、プロダクトバックログをちゃんと活用していくことへの責任も持っている。例えば

プロダクトのゴールを明確に決めて、それを誤解の余地がないようみんなにしっかりと伝える
プロダクトバックログの中に入れるアイテム（必要なタスク）を過不足なく作成し、それらのタスクについてみんなにしっかりと伝える
プロダクトバックログの中にあるアイテムを優先度順に適切に並び替える
プロダクトバックログの中がメンバーの誰の目にも見えて、かつ理解できるように整理する

というようなことをしないといけない。これらはプロダクトオーナーが直接やってもいいし、他の人に任せてもいい。しかし最終的にはプロダクトオーナーがプロダクトバックログの管理についての責任を持たないといけない。「こんなこと頼んでない！」みたいなことを言うのはルール違反。

プロダクトオーナーをちゃんと機能させるためには、プロダクトに関わる人たち全員がプロダクトオーナーの意思決定をちゃんと尊重しないといけない。「こんな指示に従えない！」みたいなことを言うのはルール違反。プロダクトオーナーの考えはプロダクトバックログの中にあるアイテムやその並び順（優先順）、実際に出来上がってきた成果（新しい機能とか目に見える改善とか）で見える化される。逆に言うとプロダクトオーナーはプロダクトバックログの中にあるアイテムやその並び順で「何を最終的な目的として、今この場で何を一番して欲しいか？」のような自分の意思が伝わるようにちゃんと努力しないといけない。

プロダクトオーナーは1人の生身の人間で、「◯◯委員会」みたいなものではない。組織にはならない。プロダクトオーナーはお客さんとか営業チームの要望をプロダクトバックログの中に詰め込んでも構わない。ただし、もしお客さんや営業チームの側に「先週ああ言ったけどやっぱりこういう風に変更して欲しい！」みたいな想定外の要望が出てきた時は、お客さんや営業チームはプロダクトオーナーにきちんと説明してそれをプロダクトオーナーに納得してもらい、承認を得る、ということが必要になる。お客さんや営業チームが開発者に直接お願いしたりするのはルール違反であり、開発者はそんなことには従わなくて良い。（という話になる）お客さんや営業チームの人は開発者を混乱させたり板挟みにあわせるようなことをしないように心がける必要がある。

スクラムマスター

スクラムマスターは、スクラムガイド（ https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf ）に書かれていることに則ったスクラムが自分のチーム内でちゃんと実現できていることに対しての責任を持つ。より良いスクラムを自分チーム内で実現して、メンバーそれぞれが気持ちよく仕事をできるように、やれることはなんでもやるポジション。スクラムマスターは自分のチームとその組織（スクラムチームを内包している組織である「開発部署」とか「株式会社◯◯」みたいな単位の組織のこと）において、自分のスクラムにおける知識と経験論をみんなに理解してもらえるように説明したり実演したりして、スクラムの輪を広げていかなくてはいけない。

スクラムマスターはスクラムチームが問題なくスクラムができていることに対する責任を持っている。スクラムマスターは自分のチームがスクラムをやっていく中で、そのやり方やコミュニケーションを日々改善していけるように常に気を配ってサポートやアドバイスをしていかなくてはいけない。

スクラムマスターはスクラムチームとその組織（さっき言った「開発部署」とか「株式会社◯◯」のこと）に奉仕する真のリーダー、スクラムの指導者と言う立ち位置になる。スクラムマスターは、自分が取りうる様々な手段でスクラムチームを支援していく。
具体的には、こんな支援をする。

自分たちのやることを自分たちで決めて、プロダクトを前に進めるための能力を全て兼ね備えた横断的なメンバーたちを指導していく。
スクラムチームが決めた「こうなったら完成である」と決めたゴールに向かって躓かずに集中して前に進めるようにメンバーをサポートしていく。
スクラムチームの邪魔をする障害物を事前に排除していけるように働きかける。（他部署の横槍とか苦情がチームの目に入る前に事前に対処したりとか）
全てのスクラムイベントがちゃんと開催され、それが価値のある時間であり、みんなで決めた時間制限（このイベントは２時間で終わらせようみたいに決めたスケジューリング）を守れるように下支えやサポートをする。

スクラムマスターは、自分が取りうる様々な手段でプロダクトオーナーを支援していく。
具体的には、こんな支援をする。

プロダクト（とそれに関わる人）にとって最も望ましいプロダクトのゴールを設定して、プロダクトバックログをどう管理したらメンバーが快適にタスクに邁進できるかについてのアイディアをプロダクトオーナーがひらめける様に協力していく。（プロダクトオーナーの壁打ち役みたいなポジションに近い）
みんなにとってわかりやすいプロダクトバックログがどうして必要なのか？という点をチームのみんなにしっかり理解してもらう。
チームやプロダクトを取り巻く複雑な状況の中で、こういうチームでこういう状況ならこういう計画にすればうまくいくんじゃないか？という様な経験に基づいた提案や支援をプロダクトオーナーに対して行う。
必要に応じて、スクラムチームとステークホルダーのみんなが仲良く信頼しあって協力できるように取り計らう

スクラムマスターは、自分が取りうる様々な手段で組織を支援していく。
具体的には、こんな支援をする。

組織が無理なくスクラムを導入できるようにコーチングしたりメンタリングしたりする。
組織がスクラムを無理なく行えるように、こういう風にやりましょう、こういうことをやった方が良いと思いますよ、という計画立案や助言をする。
他の人やチームがやっている難しそうな作業に対して、経験的にこうしたらうまくいくんじゃない？という様な助言を社員やステークホルダーに説明して、納得してもらって、実際にやってみてもらう。
スクラムチームとステークホルダーが喧嘩したり愚痴りあったりお互いに壁を作ったりしないように仲を取り持っていく。

スクラムイベント

今まで何回か登場していた「スプリント」という単語は、スクラムで行う全てのイベントの入れ物となるイベントであり、みんなで決めたスクラムの周期（二週間とか三週間の作業スパン）のこと。スクラムでは定期的にスクラムイベントと呼ばれるイベント（MTG）を行うことで、スクラム内で開発陣が作成した成果の検査と適応をするための機会を儲けている。人間で言う定期健康診断のようなもの。
これらのイベントは透明性を実現できるための設計になっていて、ルール通りに運用を行わないと検査と適応が正常に行えないため、イベントのルールはしっかりと守る必要がある。スクラムにおけるスクラムイベントをスプリントで定期的に行う習慣を生み出すことで、スクラムのルールにない会議などを行う必要がどんどんなくなっていく。（「ここってなんでこんなんになっちゃってるんだっけ？」「うーん。。ちょっと人集めて確認のMTGしましょうか。。」みたいなことをなくすために、イベントを定期的に行って各自の業務の確認などをしているという感じ）

そのため今から紹介していく全てのイベントは、ややこしい運用やルール外ルールを作らないために同じ時間と場所で機械的に習慣的に行っていくことが大切。細かい例外やルールを増やすとどんどん作業が複雑になってしまうため、望ましくない。

スプリント

スプリントはスクラムを回す上での心臓の鼓動とも言うべきもので、スプリントを定期的に回すことで初めてスクラムが動き出す。スプリント内でみんなが手を動かすことで初めてみんなが思い描いていたアイディアが具体的な価値に変わる。
一貫性を保つために、スプリントは普通一ヶ月以内の決まった長さで行う。（大した理由もなしにスプリントの期間をころころ変えてはいけない）前のスプリントが終わり次第、次のスプリントが開始されるようになっている。

スプリント内のイベントにはスプリントプランニング、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブなどがあって、これらを含む、プロダクトゴールを達成するために必要なすべての作業は、スプリント内で⾏われる。

スプリントには、以下のような基本原則が存在する。

スプリントゴール（みんなで決めた、今回のスプリントではここまで行うと決めたスプリントのゴール）が達成できなくなるような方向転換、変更をスプリント中に行わない。（「このスプリント中にこの（大きめの）機能も入れる」というような危険な判断を軽々にしてはいけない）
品質を低下させない。（「なんか予定とずれそうだからこの辺適当にやって間に合わせよ。。。」みたいな作業の一人判断をしない）
必要があると判断したらリファインメント（プロダクトバックログに入っているアイテム（タスク）に対して、詳細の追加、見積り、優先度順の並び替えをすること）を行う。
学習が進んでみんなの知見が深まり、スコープ（プロジェクトの内容の範囲、何をどこまでやらなくてはいけないか、という範囲）が具体的かつ明確になっていったら、「最初の見積もり甘すぎたな、もうちょっとリソース必要かも」みたいな事態が生じるため、その際は必要に応じてプロダクトオーナーに期間などの計画の一部見直しを交渉をしても良い。（最初に決めたスコープを絶対に守らなくちゃいけない、みたいな発想になると品質が犠牲になったりするから、そういう時はまず一度相談してみると良い）

スプリントを上で書いたようなやり方でちゃんと回すことによって、プロダクトゴールに対するみんなの進捗の検査と適応が少なくとも一ヶ月ごとにちゃんと行われることが保証される。すると、みんなが何をやっていて、プロジェクトがどうなりそうかなどの予測がしやすくなっていく。１スプリントの期間が長すぎると、今回のスプリント内での目標（スプリントゴール）が大雑把かつ把握しづらいものになってしまい、方向がずれるリスクが高まるからオススメできない。逆にスプリントの期間を短くすればPDCAが早く回ることでみんなの知見が深まりやすくなり、かつみんなの作業コストや労力を費やすリスク（労力が無駄に終わるリスクなど）を短い時間枠に収められ、リスクの範囲を狭めることができる。スプリントは程よい短さにするのがオススメ。
スプリントは短いプロジェクトと考えることもできる。

また、進捗の見通しを立てるための便利なツールとして、バーンダウン、バーンアップ、累積フローなど、世の中にはいろいろなツールが存在している。これらが役に立つツールであることはもちろんだが、これらを使えば一人一人の経験則や経験値は必要ないという話にはならない。なぜなら、プロジェクトというのは勉強した理論だけでは通用しない難しい状況がいくらでも起こりうる場所であり、すでに自分が経験して血肉化している知見こそを未来を見据えた意思決定に使用するべきだとスクラムでは考えられているから。
例えば、使っている医療器具は少ないけどこの道３０年のベテランで数百人の患者を治療してきたベテラン医師と、医療器具をたくさん持っているけどまだ学校を出て一年も経っていないような新米医師とで、どちらに自分の身体の手術をお願いしたいかは言うまでもない。プロジェクトというのも人の身体みたいなもので一つ一つみんな違って当たり前だし、道具の性能やお勉強の理論が通用しない難病奇病にかかっているプロジェクトなんていくらでもあるので、道具に振り回されてはいけない。自分の経験と思考で柔軟に立ち向かうことが大切。

また、スプリントを回している中で、知見が溜まったり状況が目まぐるしく変わっていく中で、最初に設定したこのスプリントゴールの意味がなくなった、というようなことが起きる場合もある。（調査を進めていたら作ろうとしていた機能が実は必要なかったことがわかったり、お客さんに「やっぱりこれあんま必要なかったかもしれない」とか言われたりなど）その場合は迷わずそのスプリントを中止して仕切り直すこと。ただ、スプリントを中⽌する権限を持っているのはプロダクトオーナーのみのため、そのような場合はちゃんとプロダクトオーナーを通して正式に中止とする必要がある。

スプリントプランニング

スプリントプランニングというのはスプリントの起点、最初に行うキックオフのことで、具体的には今回のスプリントで行う作業の計画を⽴てることを指している。ここで作られる作業計画はスクラムチームみんなが作り上げるものであり、一人一人が話し合い、お互いに納得した上で作り上げていくことが大切。

スプリントプランニングに参加するプロダクトオーナーは参加者に対して、優先順位が高い（とみんなが思っている）プロダクトバックログアイテムたちと、それらがプロダクトゴールとどういう関係があるのかについて、みんなで話し合う準備ができているかを確認する。（みんなの認識や前提が噛み合っているかの確認を行う、と言うようなイメージ）スクラムチームは、アドバイスをもらうためにチームに加入していない人をこのプランニングに招待しても構わない。

スプリントプランニングは主に次のトピックを話し合う。

トピック 1：このスプリントはなぜ価値があるのか？
- プロダクトオーナーは、今回のスプリントでプロダクトの価値と有⽤性をどのように⾼めることができるかの提案を行う。（今回のスプリントでここまでの機能が完成すれば、目指しているプロダクトゴールにこれくらい前進できるし、その過程の調査で他のやらなきゃいけない作業も明確になるので、今回はここまでの機能を作ることを目指そう！みたいな提案のイメージ）
- 次に、スクラムチーム全体が協⼒して、そのスプリントになぜ価値があるかをステークホルダーに伝えるためのスプリントゴールを設定する。（今回のゴールでここまでの機能を作るから、これだけの利益を今回のスプリントゴールで生み出せますよ、みたいな設定のイメージ。チームみんなでゴールを決めることが大切。また、スプリントゴールは、スプリントプランニングが終わるまでには決めておかないといけないので注意）
トピック 2：このスプリントで何ができるのか？
- 開発者はプロダクトオーナーとの話し合いを通じてプロダクトバックログからアイテムを選択し、今回のスプリントに含める。（ここで初めて、今回のスプリントではこのアイテム（タスク）たちを消化していくことにする、という具体的な決めをしていく。スプリント内でどれだけのことをこなせるかを決めるのは難しい場合も多いが、メンバーが自分たちのパフォーマンスや今回のリソースのキャパシティ、何をもって完成とするのか？ということに対する理解を深めていけば、このスプリントではこれくらいのことができるだろうという自分の予測に自信が持てるようになっていく）
- スクラムチームはプロダクトバックログからアイテムを選択していく段階で、必要があればアイテムの優先順位や細かい仕様決め、細かい見積もりをしても良い。（これを「リファインメント」と呼ぶ。チームのプロダクトバックログ（のアイテムや、今回のスプリント）に対する理解や自信が深まる効果があるので、タスクの全体像や優先順位がよくわからなかったら積極的にやっていくと良い）
トピック 3：選択した作業をどのように成し遂げるのか？
- 開発者は、選択したプロダクトバックログアイテムごとに、これで完成と言える機能（インクリメント）を作成するためにこういう作業が必要だからこれをやっていく、と言う細かい計画を決めていく。これは多くの場合、それぞれのプロダクトバックログアイテムを１日以内に終わる⼩さな作業アイテム（タスク）に分解していくことによって⾏われる。（このアイテムを完遂するために必要な作業はこれとこれで〜。。と洗い出して、細かいタスクにちぎって定義していくイメージ）
- この作業をどのように行うかは、開発者自身が自分で決める裁量を持つ。プロダクトバックログアイテムをどうやって具体的な価値の積み上げに変えていくかの方法は、誰も教えてくれない。

スプリントゴールと、スプリントゴールのために必要なアイテム（タスク）と、それらをどのように行っていくかの計画をまとめてスプリントバックログと呼ぶ。（ここまで話してきたスプリントプランニングを全て完了すると、最後にスプリントバックログと呼べるものが出来上がっている、と言う感じ）
スプリントが一ヶ月の場合、スプリントプランニングの時間（タイムボックス）は最⼤で８時間になる。スプリントの期間が短ければ、スプリントプランニングの時間も短くすることが多い。（単純計算で、スプリントが二週間だったら４時間程度をスプリントプランニングの時間に当てるということ）

デイリースクラム

デイリースクラムは、今からメンバーがやろうとしている（主に今日１日の）作業の確認や調整をしながら、スプリントゴールに対してメンバーの作業がどのように進んでいるかを検査し、必要があればスプリントバックログを適応させるためのイベント。名前の通り、基本は毎日行う。毎日15分、今日の体調を測る健康診断をするみたいな感じ。

デイリースクラムは、スクラムチームの開発者のための毎日15分のイベント。前に書いたように、ややこしい運用やルール外ルールを作らないために、スプリント期間中は毎日同じ時間と場所で機械的に習慣的に行うことが大切。プロダクトオーナーまたはスクラムマスターがスプリントバックログのアイテム消化に協力してくれている場合は開発者として参加する。

スプリントゴールに対してみんなの作業がどのように進んでいるかを検査し、今日１日の作業で何をするべきかの計画をちゃんと立てる、というデイリースクラムの基本ルールさえ守られていれば、どのような形でデイリースクラムを行っても構わない。（みんなが一人一人に報告していく形式にするとか、みんなで話し合う形式にしていくとか、チームに合わせてカスタマイズ可能）自分たちに合ったやり方でデイリースクラムを行うことで、メンバー一人一人の集中や自己管理の力が高まる。

みんなが真剣にデイリースクラムを行うことでメンバーのコミュニケーションが改善され、作業に対する障害が浮き彫りになり、こういう問題が起きた、じゃあどうしようか？ということに対する回答をメンバーがすぐ出せるようになっていく。デイリースクラムをきちんと行うことで、他の余分な会議がどんどん減っていく。

ただし、開発者はデイリースクラムの時だけしか作業の計画を調整したり見直ししたりしてはいけない、ということはない。スプリントの作業の適応や再計画をしたい場合は業務を行なっていく中で常に発生する可能性があり、一度だけの話し合いでは議論が深まりきらないことも少なくないため、開発者はそういったことに対しては臆さずどんどん話し合いをしていくべき。

スプリントレビュー

スプリントレビューとは、スプリントの最後の方（具体的に言うと最後から二番目）に行われるイベントで、今回のスプリントの成果を検査し、今後の適応をどのように行うかを決めていくイベント。今回のスプリントを振り返って、今回はここまでできたでもこれはできなかったじゃあ今後の計画をもう少しこうした方が良いかも、みたいに話し合うイベントのイメージ。
スクラムチームは、関わってくれているステークホルダー（の、特に報告しなくちゃいけない人たち）に自分たちの作業が今回どこまで進んだかという報告をし、プロダクトゴールに対してどれくらい近づいたかの進捗についてを話し合う。また、このスプリントで達成したことは具体的に何かを確認し、自分たちの環境の変化（調査の結果こういうことがわかったとか、お客さんの要望がこんな感じになってきたとか）を報告し合う。この情報をお互いにちゃんと出し合った後で、じゃあ次のスプリントはこんな感じにしていこう、ということを決める。その過程でプロダクトバックログを調整することもある。
そして大切なこととして、スプリントレビューはみんなで知恵や創造を出し合う行為であり、スクラムチームはスプリントレビューをただの報告会にしないようにする。（「〇〇がありました。次は△△したいと思います。終わり」みたいなのはNG）メンバーで知恵を出し合って、今回起きたことの掘り下げと、状況の変化についての考察と、次どうするのがベストなのかをみんなでセッションしていく。

スプリントが一ヶ月だったら、スプリントレビューのタイムボックスは最⼤4時間。スプリントの期間が短ければ、スプリントレビューの時間も短くすることが多い。単純計算でスプリントが二週間だったら２時間程度。

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

スプリントレトロスペクティブとは、スクラムの最後に行われるイベントで、スプリントレビューの内容などを受けた上で、どうやったらもっと良いやり方で業務を行なっていけるかをみんなで考えていくイベント。スプリントレトロスペクティブをもってその回のスクラムは終了する。

スクラムチームは、一人一人の業務のやり方や進め方、みんなのチームワークや進捗具合、使っているツールやそもそも何が完成なのか？（本当にそれが完成で良いのか？）みたいな事柄や疑問に対して、今回のスプリントを題材にして話し合う。（今回のスプリントがどのように進んで行っていたかを検査する）担当しているところが一人一人バラバラな都合上、必然的に検査を行う箇所はそれぞれ異なる。（作業した領域ごとに検査する箇所は当然異なる、ということ）
スクラムチームが作業をしづらくなったような要因（仮説）などがチームから出てきたらどうしてそんなことが起きてしまったんだろう？ということをみんなで考える。（「どうしてここの箇所はこんなに進捗が出なかったんだろう？」「予想外に難しい部分があったのかな？それはどこだろう？」「なんで予想できなかったんだろう？」みたいに探求していくイメージ）スクラムチームは、スプリント中にうまくいったかことは何か、やっていく中でどのような問題が発⽣したか、そしてそれらの問題がどのように解決されたか（または解決できなかったか）について詳細な話し合いを進めていく。

スクラムチームは⾃分たちがもっともっと成果を上げられるために、今、自分たちは何を最も改善すべきか？をこの機会に考えていく。今後に大きな影響を与えるような大きな変更は、影響が広がらないうちになるべく早く行うことが大切。次のスプリントのスプリントバックログに行う変更（のために行う具体的なタスクなど）を追加しても構わない。

スプリントが一ヶ月だったら、スプリントレトロスペクティブのタイムボックスは最⼤３時間。スプリントの期間が短ければ、スプリントレトロスペクティブの時間も短くすることが多い。単純計算でスプリントが二週間だったら１時間半程度。

スクラムの作成物

スクラムによって作られるもの（ここで言う「作られるもの」とは、プロダクトバックログやスプリントバックログにある「アイテム」などのことを主に指している。具体的なプロダクトの機能のことではないから注意）は、スクラムでメンバーが行った作業や価値そのものを具体的に表している。スクラムは、メンバーが作ったアイテムを見ることで、そのプロダクト（やプロダクトを作るための作業）にとって大切な情報がわかりやすく表せるように設計されている。アイテムを検査（チェック）する人は、アイテムを適応（変更とか最適化）する時と同じ情報、目線、前提を常に持っている。（持っていないといけない、とも言える）

スクラムの作成物たちはみんな、透明性と集中を⾼める情報を提供する**確約（コミットメント）**と呼ばれるアイテムを自分たちの中に内包している。
これらがあることによって、今の段階で自分たちの業務はどれくらい進んだのかな？と言う進捗を正確に測定することができる。

**確約（コミットメント）**には以下のものがある。

プロダクトバックログのための「プロダクトゴール」と言う確約
スプリントバックログのための「スプリントゴール」と言う確約
インクリメントのための「完成の定義」と言う確約

これらの**確約（コミットメント）は、スクラムチームとステークホルダーの経験主義とスクラムの価値基準を強化するために存在している。（これらの確約（コミットメント）**があることでみんなの経験知がより早く深く高まり、スクラムの理想をより強く体現しやすくなる、という感じ）

プロダクトバックログ

プロダクトバックログと言うのは、優先度順に並べられたプロダクトの前進のために必要なものの⼀覧（プロダクトのTODOリスト的な感じ）のこと。これは、スクラムチームがやらなくてはいけない作業の唯⼀絶対の情報源となる。逆に言うと、このプロダクトバックログ以外の場所にプロダクトのためにやらなきゃいけないことやその仕様をメモったりしてはいけない。（厳密に言うとメモるくらいはいいが、プロダクトバックログのアイテムにない仕様を他の場所で定義したりしてはいけないということ）

スプリントプランニングのときには、「今回行うスプリントの中では、全部でこれらのプロダクトバックログアイテムの消化を行う！」と言う選択の準備ができている前提になっている。（一度そのスプリントに含んだプロダクトバックログアイテムは予想外の事態が起きない限りスクラムチームがそのスプリント内で全て終わらせられないといけない。欲張らずにチームに最適な数と大きさのアイテムを選ぶこと）スクラムチームは普通、リファインメントの活動を通して、みんなが「今回何をするべきか？できるか？」と言う選択をするのに必要な情報（透明性）を獲得していく。
リファインメントと言うのは、前に書いた、プロダクトバックログに入っているアイテムに対して、詳細の追加、見積り、並び替えをすることであり、アイテムをより小さく詳細にするように努力していく活動。（書いてあることがあやふやで大雑把、みたいなアイテムを細かく具体的に読めば分かるレベルの複数のアイテムに分解していくことが大切）リファインメントは継続的な活動であり、必要に応じて都度丁寧に行っていくことが大切。やらなきゃいけないことややるべきことの具体的な内容は作業領域によって変わる場合も多い。

作業を⾏う開発者は、このタスクはこれぐらいの大きさでこれぐらいの時間がかかりそうだと言う作業規模の評価に責任を持っている。開発者がトレードオフを理解して正しい選択ができるように、プロダクトオーナーが開発者を⽀援（壁打ち役とか高い視座からのアドバイスとか）しても良いことになっている。

プロダクトバックログの確約（コミットメント）：プロダクトゴール

プロダクトゴールは、プロダクトの将来の状態を表している。それがスクラムチームがやるべきことの計画を立てる際の最終目標になる。プロダクトゴールはプロダクトバックログに内包されていると言う前提になっていて、プロダクトバックログの集合によってプロダクトゴールが形作られるようにならないといけない。プロダクトゴールに直接的な関連がないプロダクトバックログのアイテムたちは、プロダクトゴールを達成する「何か（what）」についてのアイテムたちでなくてはいけない（つまり、プロダクトバックログのアイテムたちは、直接的もしくは間接的に必ずプロダクトゴールと関連していなくてはいけない。そのプロダクトのゴールと全く関係がないようなアイテムを入れ込んではいけない）。

プロダクトとは価値を提供する⼿段である。プロダクトは、明確な境界、既知のステークホルダー、明確に定義されたユーザーや顧客を持っている。プロダクトは、サービスや物理的な製品である場合もあれば、より抽象的なものの場合もある。

プロダクトゴールは、スクラムチームの⻑期的な⽬標になるべきもの。もし次の⽬標に移ろうとする場合は、スクラムチームは今目の前にある⽬標を達成（または放棄）してから次の目標に向かわないといけない。（同時に複数の目標を追おうとしてはいけない）

スプリントバックログ

スプリントバックログとは、スプリントでやるべきことのリストのこと。（スプリントのTODOリスト的な感じ。プロダクトバックログが優先度順に並べられたプロダクトの完成に必要なものの⼀覧であるなら、スプリントバックログは優先度順に並べられたスプリントの達成に必要なものの⼀覧である、と言うイメージ）

スプリントバックログは、スプリントゴール（なぜ）、スプリント向けに選択されたいくつかのプロダクトバックログアイテム（何を）、およびインクリメントを届けるための実⾏可能な計画（どのように）で構成されている。

スプリントバックログは開発者による開発者のための計画であるべきで、スプリントバックログには、スプリントゴールを達成するために開発者がスプリントで⾏う作業がリアルタイムに反映される。（あ、これも必要な作業だった。みたいなことがあった場合、スプリントバックログ（のアイテム）にもその作業が反映されなくてはいけない。そのスプリントで工数を使ってやっているが、スプリントバックログには入っていない、というようなことがあってはいけない）みんながスプリントの期間中に業務をしていく中で、より多くのことを学んでいく中で、スプリントバックログの中身は常に更新され続けていく。
また、スプリントバックログはデイリースクラムで進捗を検査できる程度の詳細さが必要。大雑把すぎて15分じゃ何が進んだのか確認しきれない。。みたいなのはNG。

スプリントバックログの確約（コミットメント）：スプリントゴール

スプリントゴールはスプリントの唯⼀の⽬的であり、達成すべき唯⼀のゴール。スプリントゴールは開発者みんなが決めるものであるが、スプリントゴールを達成するために必要となる作業はその期間の中である程度柔軟に変更したりしても構わない。スプリントゴールを設定することで、みんなが集中して一つの目的に向かえるようになり、スクラムチームで⼀致団結した作業が可能になっていく。

スプリントゴールはスプリントプランニングで作成されてスプリントバックログに追加される。開発者がスプリントで作業するときには、このスプリントゴールを常に意識しながら作業していくとこが大切。（業務を進める中で、自分が今していることを続けていくことで本当に理想のゴールに近づけているのか？みたいなところは常に自問自答していかないといけない）もし自分が今している業務が予想と異なることが判明した場合（この業務を続けてもゴールにあんまり寄与しないとか、費用対効果が悪すぎてやり方を変えるべきだと確信した時とか）は、スプリントゴールに影響を与えることがないように、プロダクトオーナーと交渉してスプリントバックログのスコープを調整していく必要がある。（無理を通すのではなくて、対話で落とし所を探るのが大事）

インクリメント

インクリメントとは、プロダクトゴールに向けた具体的な踏み⽯で、これまで自分たちが作ってきた作業が生み出した価値（機能）の合計＋今回のスプリントで完成したプロダクトバックログアイテムの価値（機能）の合計のことを言う。（積み木で塔を作るのがプロダクトゴールだとしたら、自分たちが今積み上げている一つ一つの積み木たち（の合計）がインクリメントみたいなイメージ。だから自分たちが今のスプリントで生み出したインクリメントはこれまでの全てのインクリメントに自動的に追加されることになる）
この前提を踏まえた上で、すべてのインクリメントは連携して機能することが保証されなくてはいけない。（今回やった作業を加えたら既存のこの機能が動かなくなった、みたいなことはあってはいけない）そのため、自分たちが今回生み出したインクリメントを既存のインクリメントに追加しても問題ないかどうかは、徹底的に検証する必要がある。（新しい機能をみんながちゃんと使えるようにリリースの前のテストはしっかりやる、みたいな話）

スプリントでは複数のインクリメントを作成可能していいことになっている。（一回のスプリントで複数の成果を出して構わない、と言うこと）そしてスプリントで達成したインクリメント（をまとめたもの）はスプリントレビューでみんなに余すところなく報告しなくてはいけない。そうすることで、「このチームはこれくらいの時間でこれくらいのものを生み出せる」や「こういうやり方で進めればこういう形でものを出してくれる」といったような外からの知見が深まり、知見が深まることによってさらにより良いやり方を模索できるようになっていく。
ただし、スプリントレビューを通さないと自分たちが作ってきた機能（価値）をリリースしてはいけない、ということはない。スプリントの途中でステークホルダーの人たちに自分たちが作ってきた機能を提供しても別に構わない。

そして、「この機能はこれで完成である」という共通認識をちゃんと満たした形のものを提供できていない状態にある限りにおいては、自分のやっている作業がインクリメント（の一部）であると見なすことはできない。中途半端な機能を途中で勝手に提供したり、それで成果を主張したりしてはいけない。

インクリメントの確約（コミットメント）：完成の定義

ここで「完成の定義」と言っているのは、「プロダクトの品質基準を満たす（このプロダクトに加えても問題ない成果物（追加機能）になっていると言う基準を満たす）インクリメントと言うのは具体的にこれこれこう言うものである」と言うことを⽰した正式なルール（書面）のことを言っている。
つまり、プロダクトバックログアイテム（に書いてある仕様）が開発者の手作業によって具体的な機能として具現化され、それが完成の定義を満たしたときに初めて新たな「インクリメント」が誕⽣することになる、と言うルールをみんなが遵守する必要があるということ。

この「完成の定義」をしっかりと定めておくことで、開発者の作業が完了すればそれが紛れもないインクリメントの⼀部となってくれることを全員が確信できるようになり、それにより透明性が⽣み出されることになる。プロダクトバックログアイテムが完成の定義を満たしていないものになってしまっている場合（明確にバグが出てるとか、書いてある機能が正確に実現できてないとかの場合）、そのアイテムをリリースすることやスプリントレビューで出すということをしてはいけない。
何らかの理由で完成の定義を上手く満たしていないようなものができてしまった場合、なぜそんなことになったのか？と言うことを後で話し合うために、プロダクトバックログに戻しておくことが推奨される。

また、もしも組織内でインクリメントの完成の定義がある程度定まっている、もしくは定められているような場合（会社内で提供されるシステムはレスポンス速度◯◯を満たしていないといけない、みたいなスクラムチームの外に決められているルールがあるみたいな場合）は、すべてのスクラムチームは最低限それに従う必要がある。（スクラムチームも組織の一部なので当然）
組織にそのような定義がない場合は、そのスクラムチームはプロダクトに適した完成の定義を作成していく必要がある。（このプロダクトだったらこれくらいのレスポンス速度は満たしていないと完成とは言い難い、みたいなものを作ってチームの共通認識にしていくことが必要）

そして、開発者はそうやって明文化された完成の定義をしっかりと守っていく必要がある。プロダクトに関わるスクラムチームが複数ある場合は、みんなで共通して参照する完成の定義（つまりみんなのルール）を作成して、開発者は自分の開発者としてのプライドにかけてそれを遵守していく必要がある。

最後に

スクラムは無料のもので、スクラムガイド（ https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf ）で提供されているものになる。
そして、スクラムフレームワークは不変なものである。スクラムの一部だけを導入して回すこともできなくはないが、それはやはり「スクラム」とは呼べないものになってしまう。スクラムガイドに書かれている必須要項を全て満たして初めて「スクラム」になるし、「スクラム」は他の技法や方法論を中に入れて運用を回すことができるようになるものである。