はじめに
「スクラムガイドって、なんだか難しそう…」
スクラムガイドを初めて読んだとき、多くの方がそう感じるのではないでしょうか。確かに、経験主義、スクラムの3本柱(透明性・検査・適応)、5つの価値基準など、重要な概念が多く登場します。
しかし、スクラムの本質はシンプルです。この記事では、新人エンジニアのAくんと、現役スクラムマスターのBさんとの対話を通じて、スクラムガイドの重要な概念をストーリー形式でわかりやすく解説していきます。チームの日常的な出来事や具体的な事例を交えながら、スクラムの理論から実践までを学んでいきましょう。
この記事の対象読者
- スクラムガイドを読んでみたものの、実践的な理解に悩んでいる方
- スクラムの基本概念を体系的に学びたい方
- チームでスクラムを導入・改善したいと考えている方
この記事で学べること
- スクラムの理論的基礎(経験主義・3本柱・5つの価値基準)
- スクラムの実践要素(3つの役割・5つのイベント・3つの作成物)
- スクラムガイドの読み方と解釈のポイント
- 実践的な運用における注意点とコツ
17話からなるストーリーを通じて、スクラムの基礎から応用まで、体系的に理解を深めていきましょう。各話は独立して読むこともできますが、順番に読むことで、より深い理解が得られるように構成されています。
それでは、AくんとBさんの会話を通じて、スクラムガイドの世界を覗いていきましょう。
第一話「スクラムって何だろう?」
(とある IT 企業のオフィス)

はじめまして!本日から配属になりました新人の A です。よろしくお願いします!

やあ、welcome! スクラムマスターの B です。君が噂の新人くんね。プログラミングはだいぶ慣れてきたって聞いてるよ

はい!基本的な開発は任せてもらえるようになってきました。ただ、こちらのチームは “スクラム” という開発手法を使っていると聞いて…

うんうん。不安かい?

正直、なんだか難しそうで…。ネットで調べても、”経験主義” とか “リーン思考” とか、難しい言葉ばかり出てきて…

(笑)大丈夫、みんな最初はそう。じゃあ、今から君と一緒にスクラムガイドを見ていこうか

お願いします!

まずはシンプルに。スクラムって何か知ってる?

えーと…アジャイル開発の一種ですよね?

そうそう。もっと具体的に言うと、『複雑な問題に対応するための軽量級フレームワーク』なんだ

フレームワーク…って、何かの枠組みってことですか?

そう!でもね、普通のフレームワークと違って、すごくシンプルなんだ。要は3つのことをぐるぐる回していくだけ

3つ…ですか?

うん。こんな感じ
- プロダクトオーナーが、やるべき作業を優先順位付けて並べる
- チームが、その作業を価値のある形にする
- みんなで結果を確認して、次に向けて改善する
…これを繰り返すんだ

へぇ、意外とシンプル…なんですね

そうなんだ。ただし、このシンプルな仕組みの背景には、ちゃんとした考え方があるんだよ

あ、それが “経験主義” とか “リーン思考” とかですか?

その通り!ちょっと難しく聞こえるけど、実は当たり前のことなんだ。まず “経験主義” って知ってる?

えーと…経験から学ぶ…とか?

そう!要は “やってみて、確認して、改善する” ってこと。机上の空論じゃなくて、実際の経験から学んでいこうっていう考え方だね

なるほど…!

で、もう一つの “リーン思考” は?

それは…よくわからないです…

簡単に言うと “むだを省いてシンプルに” ってこと。必要なものに集中して、余計なものは省くっていう考え方だよ

あー、なんか身近な感じがしてきました

でしょ?そして、この2つの考え方から、スクラムの重要な3本柱が生まれるんだ

3本柱…ですか?

うん。”透明性” “検査” “適応” って言うんだけど…あ、もう時間だ。この続きは明日にしようか

えー!気になるところで…

(笑)まあ、今日はこれだけでも十分だよ。ちょっと整理してみようか?
今日のポイント!
- スクラムとは?
- 複雑な問題に対応するためのシンプルなフレームワーク
- 3つの基本サイクル:優先順位付け→価値の創造→確認と改善
- スクラムの基礎となる考え方
- 経験主義:実際の経験から学ぶ
- リーン思考:むだを省いてシンプルに

わあ、整理するとすっきりしますね!

でしょ?明日は3本柱について話そう。今日はお疲れ様!

ありがとうございました!明日が楽しみです!
第二話「スクラムの3本柱って何?」
(翌日のオフィス)

おはようございます!

おう、元気だね。昨日の続きを聞きたいんだろう?

はい!その “3本柱” のところが気になって…

(笑)よし、じゃあコーヒーを入れながら話そうか
(オフィスのカフェスペースにて)

昨日は “透明性” “検査” “適応” という3本柱があるって…

そうそう。この3つがスクラムの重要な柱なんだ。まず “透明性” から説明しようか

お願いします!

透明性ってさ、要は “見える化” ってこと。例えば君、前のチームでこんな経験なかった? “このタスク、どのくらい進んでるんだろう…” とか “どこで困ってるのかな…” とか

ありました!週1回の報告会まで状況がわからなくて、結局遅れてたってことが…

そう!それって困るよね。スクラムでは、そういう “見えない” 状態をなくそうとするんだ。作業の進み具合や、直面している問題、次に何をやろうとしているのか…全部見える形にする

なるほど。でも、常に状況を報告するのって大変じゃないですか?

いい質問!確かに最初は手間に感じるかもしれない。でも、これが次の “検査” につながるんだ

検査…進捗確認のことですか?

いや、もっと広い意味だよ。見える化した情報を、みんなで定期的に確認すること。”このやり方で大丈夫?” “もっといいやり方ない?” “予定通り進められそう?” って

あー!だから見える化が大事なんですね。見えないと確認もできない

その通り!そして確認した結果、必要なら変更を加える。それが3つ目の “適応” ってわけ

変更…って、途中で計画変更してもいいんですか?

むしろ、必要なら変えるべきなんだ。世の中どんどん変わっていくでしょ? そんな中で最初の計画に固執するのは危険だよ

でも、お客さんとの約束とか…

重要なポイントだね。だからこそ “透明性” が大事なんだ。変更の理由も、影響も、全部見える形にする。そうすればお客さんとも適切なコミュニケーションが取れるでしょ?

なるほど!3つが繋がってるんですね

そう!この3本柱があるからこそ、スクラムは機能するんだ。ちょっと例え話をしてみようか
(ホワイトボードに絵を描きながら)

料理を作るところを想像してみて。
- 透明性:今どんな状態か、あとどれくらいかかりそうかを、キッチンに立ち寄る誰もが分かるようにしておく
- 検査:お客さんに少し味見してもらう
- 適応:お客さんの反応を見て味付けを調整する
こんな感じ。これなら自然だと思わない?

わぁ、なるほど!急に身近に感じてきました

でしょ?スクラムって、実は人間の自然な活動をうまく形にしただけなんだよ
今日のポイント!
- スクラムの3本柱
- 透明性:誰もが状況を理解できるように見える化する
- 検査:定期的に確認して問題点を見つける
- 適応:必要に応じて改善・調整する
- 3本柱の特徴
- 3つは相互に関連している
- 自然な人間の活動をフレームワーク化したもの
- 変化に対応するための基礎となる

スクラムって、最初は難しそうだと思ったんですが、意外と自然な考え方なんですね

そうなんだ。ただし、これを実践するには “確約” “集中” “公開” “尊敬” “勇気” という5つの価値基準も大切になってくるんだけど…

おっ、また新しい話が!

(笑)その話は次回にしようか。今日はよく理解できたみたいだね

はい!ありがとうございました!
第三話「スクラムの5つの価値基準」
(数日後のオフィス)

Bさん、この間の “5つの価値基準” について、もう少し詳しく教えていただけませんか?

おー、覚えてたんだね。確約、集中、公開、尊敬、勇気の5つだよ

なんだか、かっこいい言葉ばかりですね

(笑)でも、これらは単なるきれい事じゃないんだ。実際の開発現場で本当に必要になる心構えなんだよ

へぇ、具体的にはどんな感じですか?

じゃあ、一つずつ見ていこうか。まず “確約(コミットメント)” 。これはどんな意味だと思う?

えーと、約束を守るってことですか?

惜しい!もう少し広い意味があるんだ。確かに約束を守ることも大事だけど、それ以上に “目標達成に向けて全力を尽くす” という意味が重要なんだ

全力を尽くす…

例えば、チームで “このスプリントでここまでやろう!” って決めたら、その目標に向かって全員で頑張る。でも、ただがむしゃらに頑張るんじゃなくて…

え?がむしゃらじゃダメなんですか?

そう。だから2つ目の “集中” が大切になってくるんだ。今、自分たちが決めた目標に集中する。余計なことに気を取られない

あー!確かに前のチームでは、あれもこれも同時にやろうとして、結局どれも中途半端になってました…

よくある話だよね。それに関連して “公開(オープンネス)” も重要になってくる

公開?なにを公開するんですか?

作業の状況とか、困っていることとか、すべてをオープンにするってこと。”やばい、間に合わない” とか “ここ、よく分からない” とか、隠さないってこと

でも、それって恥ずかしくないですか?特に分からないことを認めるの…

だから4つ目の “尊敬” が大切なんだ。お互いを一人の専門家として認め合い、尊重する。分からないことは恥ずかしいことじゃなく、むしろ成長の機会だって考える

なるほど…でも、正直に話すの、やっぱり怖いです

(笑)そう、だから最後に “勇気” が必要になる。問題を指摘する勇気、助けを求める勇気、新しいことにチャレンジする勇気…

全部つながってるんですね

その通り!ちょっと具体例を出してみようか
(ホワイトボードに書きながら)

こんなシナリオを考えてみて:
- チームで難しい機能の開発を約束した(確約)
- その機能に集中して取り組む(集中)
- 途中で技術的な壁にぶつかったことを素直に共有する(公開)
- チームメンバーが互いの意見を尊重しながら解決策を探る(尊敬)
- 従来とは違うアプローチを試してみる(勇気)
これが理想的な流れ。どう?イメージつく?

はい!なんだか心強いです。でも、これって本当に実現できるんですか?

いい質問!完璧にはいかないかもしれない。でも、この5つを意識することで、チームはどんどん良くなっていくんだ
今日のポイント!
- スクラムの5つの価値基準
- 確約:目標達成に向けて全力を尽くす
- 集中:今の目標に焦点を合わせる
- 公開:状況や課題を隠さず共有する
- 尊敬:お互いを専門家として認め合う
- 勇気:必要な行動を起こす勇気を持つ
- 価値基準の特徴
- 相互に関連している
- 理想を追求しながら段階的に改善していく
- チームの成長を支える基盤となる

なんだか分かってきました。要は、みんなで正直に協力し合って、より良いものを作っていこうってことですよね

その通り!さて、この価値基準を実践するために、スクラムチームはどんな構成になってるか知ってる?

あ、それが気になってました!

じゃあ、それは次回に話そうか

はい、楽しみにしています!
第四話「スクラムチームの本質」
(翌週のオフィス)

Bさん、スクラムチームについて教えていただけますか?

ああ、スクラムの基本単位だね。スクラムガイドには、とても重要なことが書かれているんだ

基本単位というと?

スクラムチームは、スクラムマスター1人、プロダクトオーナー1人、そして開発者たちで構成される小さなチームなんだ。この中にサブチームや階層は存在しないんだよ。スクラムマスターや、プロダクトオーナーは今度説明するよ

階層がない…というのは?

つまり、チーム内に上下関係を作らないということ。その代わり、みんなが一つの目的に集中するんだ

一つの目的…ですか?

そう。スクラムガイドでは “プロダクトゴール” って呼んでるけど、これは今後じっくり説明するね。今日はまず、スクラムチームの重要な特徴を見ていこう

はい!

スクラムチームには、2つの重要な特徴があるんだ。”機能横断型” と “自己管理型” という特徴だよ

むずかしそうな言葉ですね…

まず機能横断型について説明するね。これは、各スプリントで価値を生み出すために必要なスキルを、チーム全体として持っているということなんだ

スプリントって何ですか?

あ、それも後で詳しく説明するね。今は “一定期間” とだけ覚えておいてください。で、もう一つの特徴が “自己管理型” 。これは、誰が何を、いつ、どのように行うかを、チーム内で決定できるということ

それって、完全に自由にやっていいってことですか?

いや、そうじゃないんだ。スクラムチームには明確な責任があるんだよ。例えば、ステークホルダーとのコラボレーション、検証、保守、運用、実験、研究開発など、プロダクトに関して必要となるすべての活動に責任を持つんだ

結構、広い範囲の責任なんですね

そう。だからこそ、チームの規模も重要になってくる。スクラムガイドでは、通常10人以下とされているんだ

なぜ10人以下なんですか?

敏捷性を維持するための “十分な小ささ” と、スプリント内で重要な作業を完了するための “十分な大きさ” のバランスなんだ。一般的に、小さなチームのほうがコミュニケーションがうまくいき、生産性も高いことがわかっているんだよ

でも、大きなプロダクトの場合は?

その場合は、同じプロダクトゴールとプロダクトバックログ、そしてプロダクトオーナーを共有する、複数のスクラムチームを作ることになるね

なるほど…でも、共有するって、どういうことですか?

それは、プロダクトオーナーとプロダクトバックログについて説明するときに詳しく話そう。今日は、スクラムチームの基本的な特徴を押さえておこうか
今日のポイント!
- スクラムチームの構成
- スクラムマスター1人、プロダクトオーナー1人、開発者で構成
- サブチームや階層が存在しない
- 一つの目的(プロダクトゴール)に集中
- スクラムチームの特徴
- 機能横断型:必要なスキルをチーム全体として保有
- 自己管理型:作業の計画と実行をチームで決定
- 10人以下の小規模:効果的なコミュニケーションと生産性のため
- スクラムチームの責任
- プロダクトに関するすべての活動に責任を持つ
- 持続可能なペースで作業を行う
- スプリントごとに価値のある有用なインクリメントを作成する

スクラムチームの基本が分かってきました。次は具体的な役割について詳しく知りたいです

うん、それぞれの役割には明確な責任があるんだ。また明日、詳しく説明するよ
第五話「スクラムチームの3つの役割」
(午後のオフィス、ホワイトボードの前で)

Bさん、前回の話でスクラムチームには色々な役割があるって話してましたが、その説明ってしてもらえますか?…

ああ、スクラムチームには3つの役割があるんだ。プロダクトオーナー、スクラムマスター、そして開発者だよ

えっ、たった3つですか?

そう。シンプルでしょ?でも、それぞれにとても重要な責任があるんだ。まずは開発者から説明しようか

はい!

開発者は、スプリントごとに “インクリメント” って呼ばれる価値のあるものを作り出すことに責任を持つんだ

インクリメントって何ですか?

簡単に言うと、”使える状態の成果物” かな。後で詳しく説明するけど、今は “価値のある動くもの” って考えておいて

なるほど。それで、開発者は具体的に何をするんですか?

主に4つの責任があるよ:
- スプリントの計画を立てる
- 品質を確保する
- 毎日の計画を必要に応じて調整する
- お互いに専門家として責任を持つ

へぇ…でも誰が開発者を管理するんですか?

(笑)それがスクラムの面白いところ。開発者たちは自己管理型なんだ。つまり、自分たちで決めて、自分たちで責任を持つ

自分たちで決める…結構大変そうですね

確かに最初は大変かもしれない。でも、次に説明するプロダクトオーナーやスクラムマスターがサポートするんだ」
(カフェスペースに移動しながら)

じゃあ次は、プロダクトオーナーについて説明しようか

はい!

プロダクトオーナーは、シンプルに言うと “プロダクトの価値を最大化する” ことが最大の責任なんだ

価値を最大化…具体的には?

主に5つの重要な仕事があるよ:
- プロダクトゴールを定める
- プロダクトバックログのアイテムを作って、明確に伝える
- アイテムの優先順位をつける
- プロダクトバックログを透明にする
- 開発者がプロダクトバックログを理解できるようにする

プロダクトバックログって何ですか?

簡単に言うと “やることリスト” かな。でもこれも後で詳しく説明するね。大事なのは、このリストの管理は全部プロダクトオーナーの責任だってこと

なるほど。じゃあ最後は…スクラムマスターですね

そう。実は僕がそれなんだけどね(笑)

そういえば、そんな話を聞いたような気がします

うん。スクラムマスターの主な仕事は、スクラムがうまく機能するように支援することなんだ。具体的には3つの方向で支援するよ:
- スクラムチームを支援する
- プロダクトオーナーを支援する
- 組織を支援する

支援って、どんな感じですか?

例えばチームの支援だと:
- 自己管理とチーム作りをサポート
- チームが価値の高い成果物に集中できるよう手助け
- 障害物を取り除く
- スクラムのイベントがうまく進むようにする
…といった感じかな

なんだか、チームのお世話係みたいですね

(笑)まあ、でもただのお世話係じゃないよ。スクラムマスターは “奉仕型のリーダー” なんだ。チームが最高のパフォーマンスを発揮できるように導くんだよ
今日のポイント!
- スクラムチームの3つの役割
- 開発者:価値のあるインクリメントを作る
- プロダクトオーナー:プロダクトの価値を最大化する
- スクラムマスター:スクラムがうまく機能するように支援する
- 開発者の特徴
- 自己管理型
- スプリントごとに価値を届ける
- お互いに専門家として責任を持つ
- プロダクトオーナーの責任
- プロダクトゴールの設定
- プロダクトバックログの管理
- 価値の最大化
- スクラムマスターの役割
- チーム、PO、組織への支援
- 奉仕型のリーダーシップ
- スクラムの実践をガイド

なるほど…3つの役割がそれぞれ違う視点で協力し合うんですね

その通り!じゃあ次回からは、スクラムイベントについて説明しようか

スクラムイベント…?また新しい言葉が出てきました(笑)

(笑)大丈夫、ひとつずつ理解していけば簡単だよ。また明日ね!
第六話「スクラムの心臓、スプリントとは」
(次の週のオフィス)

Bさん、この間からずっと気になっていたんですが…スプリントって何ですか?

ああ、スクラムの中で最も重要なものの一つだね。スクラムガイドでは “心臓の鼓動” って表現されているんだ

心臓の鼓動?

そう。スプリントの中で、アイデアが価値に変わっていくんだ。まず大事なのは、スプリントには決まった長さがあるってこと

決まった長さ?

スクラムガイドでは “1か月以内の決まった長さ” って書かれているんだ。そして、前のスプリントが終わったら、すぐに次のスプリントが始まる

なぜ1か月以内なんですか?

一貫性を保ちながら、複雑さとリスクを抑えるためなんだ。期間が長すぎると、いくつかの問題が出てくるんだよ

どんな問題ですか?

例えば:
- スプリントゴールが役に立たなくなる可能性がある
- 複雑さが増してしまう
- リスクが高まる

逆に短くするメリットは?

スプリントを短くすると:
- より多くの学習サイクルを生み出せる
- コストや労力のリスクを短い時間枠に収められる
というメリットがあるんだ

なるほど。で、スプリントの中では何をするんですか?

スプリントの中では、プロダクトゴールを達成するために必要なすべての作業が行われるんだ。具体的には:
- スプリントプランニング
- デイリースクラム
- スプリントレビュー
- スプリントレトロスペクティブ

うわ、また新しい言葉が…

大丈夫、これらは順番に説明していくよ。でも、その前にスプリントの重要なルールを押さえておこう

ルール?

うん。スプリント中は:
- スプリントゴールの達成を危険にさらすような変更はしない
- 品質を低下させない
- プロダクトバックログを必要に応じてリファインメントする
- 学習が進むにつれて、プロダクトオーナーとスコープの再交渉ができる

変更はダメだけど、スコープの再交渉はできる…?

そう。スプリントは短いプロジェクトみたいなものだけど、完全に固定的というわけじゃないんだ。学びながら適応していく余地を残しているんだよ

でも、スプリントの途中で何か大きな変更が必要になったら?

いい質問だね。実は、スプリントを中止できる場合があるんだ。ただし、それはスプリントゴールが意味をなさなくなった場合だけ。そして、中止できるのはプロダクトオーナーだけなんだ

なんだか、ルールはシンプルだけど、奥が深そうですね

その通り!スプリントは、複雑な開発を管理可能な範囲に収める仕組みなんだ。次回は、スプリントの中で行われる最初のイベント、スプリントプランニングについて詳しく見ていこう
今日のポイント!
- スプリントの基本
- スクラムの心臓部分
- 1か月以内の一定期間
- アイデアを価値に変える器
- スプリントの特徴
- 一貫性のある期間設定
- 複雑さとリスクの制御
- 学習サイクルの確保
- スプリントのルール
- 目標を危険にさらす変更の禁止
- 品質の維持
- 必要に応じたリファインメント
- スコープの再交渉可能性

スプリントの基本が分かってきました。次はその中身について詳しく知りたいです

うん、スプリントの中で行われる各イベントには、それぞれ重要な目的があるんだ。また明日、詳しく説明するよ
第七話「スプリントプランニングの3つのトピック」
(翌日のオフィス)

Bさん、今日はスプリントプランニングについて教えていただけるんでしょうか?

そうだね。スプリントプランニングは、スプリントの起点となる重要なイベントなんだ

どんなことを計画するんですか?

スクラムガイドでは、3つのトピックについて話し合うことになってるんだ

3つ…ですか?

うん。
- このスプリントはなぜ価値があるのか?
- このスプリントで何ができるのか?
- 選択した作業をどのように成し遂げるのか?

ふむふむ、1つ目の “なぜ価値があるのか” というのは、どういうことでしょうか?

これはとても重要なトピックなんだ。プロダクトオーナーが、プロダクトの価値と有用性を今回のスプリントでどのように高めることができるかを提案する

プロダクトオーナーが提案…

そう。そして、スクラムチーム全体で協力して “スプリントゴール” を定義するんだ。このスプリントゴールは、スプリントプランニングの終了までに確定する必要がある

スプリントゴールって、具体的な機能とかそういうことですか?

いや、もっと大きな目的のことだね。具体的な “What(何を作るか)” は2つ目のトピックで決めていくんだ

なるほど。じゃあ2つ目のトピックについて教えてください

2つ目は “このスプリントで何ができるのか” の具体的な検討だね。開発者たちが、プロダクトオーナーと話し合いながら、プロダクトバックログからアイテムを選択していく

選択の基準は?

開発者たちの過去のパフォーマンス、今回のキャパシティ、そして完成の定義への理解度などを考慮するんだ。この過程で、プロダクトバックログアイテムのリファインメントをすることもある

リファインメントって?

詳細を詰めていくことだね。それによって、チームの理解と自信が高まっていく。でも、それはまた別の機会に詳しく説明するよ

はい。で、3つ目のトピックは?

“選択した作業をどのように成し遂げるのか” の計画だね。これは開発者たちの専門分野なんだ

開発者だけで決めるんですか?

そう。どうやって完成の定義を満たすインクリメントを作るか、それは開発者たちの裁量なんだ。多くの場合、選択したプロダクトバックログアイテムを1日以内の小さな作業に分解していく

なるほど。ところで、このプランニング、結構時間がかかりそうですね?

スクラムガイドでは、1か月のスプリントの場合、最大8時間と定められているよ。もちろん、スプリントが短ければプランニングの時間も短くなる

8時間!結構長いですね

うん。でも、この時間をかけて計画をしっかり立てることで、スプリント中の混乱を減らせるんだ。計画の結果として “スプリントバックログ” が作られる

スプリントバックログ?

これは、スプリントゴール、選択したプロダクトバックログアイテム、そして実行計画をまとめたものだね。でも、これについては次回詳しく説明しよう
今日のポイント!
- スプリントプランニングの3つのトピック
- なぜ:このスプリントの価値を定義(スプリントゴール)
- 何を:プロダクトバックログアイテムの選択
- どのように:実行計画の作成
- 各トピックの特徴
- トピック1:プロダクトオーナーが提案し、チームで目的を定義
- トピック2:開発者とプロダクトオーナーで内容を決定
- トピック3:開発者が実行方法を計画
- 重要なポイント
- 1か月のスプリントなら最大8時間
- スプリントゴールは必ず確定させる
- 結果としてスプリントバックログが作られる

3つのトピックがあることで、目的も内容も方法も、しっかり計画できるんですね

その通り。次は、この計画に基づいて実際の開発が始まるんだけど、その中で重要なイベントが “デイリースクラム” というものなんだ
第八話「デイリースクラムの本質」
(翌日のオフィス)

Bさん、昨日からずっと気になってるんですが…デイリースクラムって毎日ミーティングするんですよね?それって大変じゃないですか?

(笑)みんな最初はそう思うんだよ。でも、実は15分だけなんだ

15分!?そんな短い時間で何ができるんですか?

デイリースクラムの目的は2つだけなんだ。スプリントゴールに向かって進んでいるか確認することと、必要なら計画を調整すること

え…それだけですか?

そう、シンプルでしょ?スクラムガイドでは、複雑さを減らすために、毎日同じ時間・同じ場所で開催することを推奨しているんだ

毎日同じ時間…なるほど、習慣化するってことですね

その通り!ちなみに、デイリースクラムに参加するのは基本的に開発者たちなんだよ

へぇ…具体的にはどんなことを話し合うんですか?

それが面白いところで、スクラムガイドでは特定の形式を強制していないんだ。開発者たちが、スプリントゴールの進捗に焦点を当てて、これからの1日の実行可能な計画を作れれば、どんな方法でもいいんだよ

え?でも、知人のチームでは必ず3つの質問に答えないといけないって…

ああ、”昨日やったこと” “今日やること” “困っていること” っていう3つの質問だよね。確かによく使われる形式だけど、スクラムガイドでは必須とはしていないんだ。大事なのは、コミュニケーションを改善して、障害物を特定し、迅速な意思決定ができることなんだよ

なるほど…でも15分で終わるんですか?

いい質問だね。実は、デイリースクラムは “きっかけ” なんだ。もし詳細な議論が必要な場合は、デイリースクラムの後で必要なメンバーだけで話し合えばいいんだよ

あー!だから15分で十分なんですね

そう!それに、開発者たちは一日中コミュニケーションを取っているんだ。デイリースクラムは唯一の打ち合わせの機会じゃないんだよ

じゃあ、デイリースクラムは…朝の “同期” みたいなものですか?

その表現、いいね!まさにその通り。チームの “心臓の鼓動” とも言えるかもしれないね
今日のポイント!
- デイリースクラムの基本
- 15分のタイムボックス
- 毎日同じ時間・場所で開催
- 開発者のためのイベント
- デイリースクラムの目的
- スプリントゴールに向けた進捗の確認
- 必要に応じた計画の調整
- コミュニケーションの改善
- 障害物の特定
- 迅速な意思決定の促進
- デイリースクラムの特徴
- 形式は開発者が選択可能
- より詳細な議論は別途実施
- 一日を通じた頻繁なコミュニケーションの一部

デイリースクラム、思っていたより理にかなってますね。明日から参加するのが楽しみになってきました

それは良かった!明日は実際のデイリースクラムに参加してもらおうか。その後で、スプリントレビューについて話そう
第九話「スプリントレビューの真価」
(デイリースクラムの後のカフェスペースで)

Bさん、今のデイリースクラム、すごくスムーズでしたね

うん、みんな慣れてきてるからね。さて、今日はスプリントレビューについて話そうか

スプリントレビュー…成果物の発表会みたいなものですか?

よくある誤解なんだけど、スプリントレビューは単なる発表会じゃないんだ。スクラムガイドでは、はっきりと “ワーキングセッション” って書かれているよ

ワーキングセッション?

そう。スプリントレビューの目的は2つあって、スプリントの成果を検査することと、今後の適応を決めることなんだ

検査と適応…スクラムの3本柱の話が出てきましたね

よく覚えてたね!スプリントレビューでは、スクラムチームとステークホルダーが一緒に、2つのことを確認するんだ:
- スプリントで何が達成されたか
- 環境で何が変化したか

環境の変化って、例えばどんなものですか?

例えば、市場の変化や新しい技術の登場、競合他社の動き、お客さんのニーズの変化なんかだね

なるほど…じゃあデモだけじゃないんですね

その通り!実はスクラムガイドでは、プレゼンテーションだけに限定しないように、って明確に書かれているんだ

へぇ…でも、どんなことをするんですか?

例えば:
- インクリメントを実際に触ってもらう
- フィードバックを集める
- 市場の変化について話し合う
- 次に何をすべきか一緒に考える
…といった感じかな

結構たくさんやることがありますね。時間はどれくらいかかるんですか?

1ヶ月のスプリントなら最大4時間だよ。もちろん、スプリントが短ければレビューの時間も短くなる

4時間!結構長いですね

でも、この時間が本当に大切なんだ。なぜかわかる?

えーと…みんなで確認して、次の計画を立てるから…?

そう!でも、もっと重要なことがあるんだ。スプリントレビューは、プロダクトバックログを調整するチャンスでもあるんだよ

プロダクトバックログの調整?

うん。レビューで得た学びを基に、次にやるべきことを見直すんだ。これこそが、スプリントレビューを単なる発表会じゃなく、ワーキングセッションとして位置づけている理由なんだよ

なるほど…その後にスプリントプランニングがあるから、タイミング的にも理にかなってますね

その通り!スプリントレビューは、検査と適応の機会であると同時に、次のスプリントの準備でもあるんだ
今日のポイント!
- スプリントレビューの本質
- 単なる発表会ではなくワーキングセッション
- スプリントの成果の検査
- 今後の適応の決定
- スプリントレビューの内容
- 達成したことの確認
- 環境変化の共有
- インクリメントの検査
- 次のステップの検討
- プロダクトバックログの調整
- スプリントレビューの特徴
- スクラムチームとステークホルダーが参加
- 1ヶ月のスプリントなら最大4時間
- プレゼンテーションだけに限定しない
- 次のスプリントに向けた準備の機会

スプリントレビュー、奥が深いんですね

うん。明日は最後のイベント、スプリントレトロスペクティブについて話そうか
第十話「スプリントレトロスペクティブの真髄」
(翌日、静かな会議室で)

Bさん、今日はスプリントレトロスペクティブの話ですよね?

そう。スプリントの最後を締めくくる大切なイベントなんだ

レトロスペクティブって、振り返りってことですよね?

うん。でも単なる振り返りじゃないんだ。スクラムガイドでは、はっきりと目的が書かれているよ

どんな目的なんですか?

“品質と効果を高める方法を計画すること” なんだ

へぇ…具体的にはどんなことを話し合うんですか?

スクラムガイドによると、主に5つの観点から検査するんだ:
- 個人
- 相互作用
- プロセス
- ツール
- 完成の定義

結構広い範囲を見るんですね

そう。でも大事なのは、ただ振り返るだけじゃないってことなんだ。スクラムチームは3つのことを話し合うんだよ:
- うまくいったこと
- どんな問題が発生したか
- それらがどう解決されたか(または解決されなかったか)

問題点を洗い出す、みたいな?

それも大事だけど、もっと重要なのは、その先なんだ。チームの効果を改善するために最も役立つ変更を特定する必要があるんだよ

変更…具体的にはどんな感じですか?

例えば:
- コミュニケーションの方法を改善する
- 開発環境を改善する
- チーム内のルールを見直す
といった感じかな

なるほど。でも、見つかった改善点はいつ実施するんですか?

いい質問だね!スクラムガイドでは、最も影響の大きな改善は “できるだけ早く” 対処すると書かれているんだ。場合によっては、次のスプリントのスプリントバックログに追加することもできるよ

スプリントバックログに追加…つまり、改善活動も正式な作業として認められるんですね!

その通り!改善活動は “やれたらいいな” じゃなくて、チームの重要な仕事の一部なんだ

時間はどれくらいかかるんですか?

1ヶ月のスプリントなら最大3時間だよ。ただし、これもスプリントの長さに応じて調整するんだ

3時間か…結構しっかり時間を取りますね

うん。でもね、この時間は投資だと思うんだ。より良いチームになるための投資。だからこそ、スプリントレトロスペクティブはスクラムの重要なイベントとして位置づけられているんだよ
今日のポイント!
- スプリントレトロスペクティブの目的
- 品質と効果を高める方法を計画すること
- チームの改善点を特定し、実行計画を立てること
- 検査の観点
- 個人
- 相互作用
- プロセス
- ツール
- 完成の定義
- 重要な特徴
- 単なる振り返りではなく、改善のための具体的な計画を立てる
- 最も影響の大きな改善を優先する
- 改善活動を次のスプリントバックログに含めることができる
- 1ヶ月のスプリントなら最大3時間

レトロスペクティブって、チームをより良くするための大切な機会なんですね

そうなんだ。次は、スクラムの作成物について詳しく見ていこうか

はい!楽しみです!
第十一話「プロダクトバックログとプロダクトゴール」
(翌日、ホワイトボードの前で)

Bさん、今日はスクラムの作成物について教えてくれるんでしたよね?

そうだよ。スクラムには3つの重要な作成物があるんだ。プロダクトバックログ、スプリントバックログ、そしてインクリメントだよ

作成物…文書みたいなものですか?

単なる文書じゃないんだ。スクラムガイドでは “作業や価値を表すもの” として定義されているんだよ。今日はまず、プロダクトバックログから見ていこうか

はい!

プロダクトバックログって、どんなものだと思う?

えーと…やることリスト、ですか?

そうだね!もう少し正確に言うと “プロダクトの改善に必要なものを順番に並べた一覧” なんだ。大事なのは、これが “創発的” だってことなんだよ

創発的…ってどういう意味ですか?

新しい気づきや学びによって、どんどん内容が変化していくってことだね。固定的じゃないんだ

あ、だからプロダクトバックログは常に更新されていくんですね

その通り!それに、プロダクトバックログには重要な “確約” があるんだ。それが “プロダクトゴール” というものなんだよ

プロダクトゴール?それは何ですか?

プロダクトの将来の状態を表すものなんだ。言わば、チームが目指すべき目標だね

具体的には?

例えば:
- “業界No.1の使いやすさを実現する”
- “ユーザーの作業時間を半分にする”
- “新しい市場を開拓する”
といった感じかな

へぇ、結構大きな目標なんですね

そう。そして、プロダクトバックログの他の項目は、このゴールを達成するための “何か(what)” を定義するものなんだ

プロダクトバックログの項目って、どんな感じになるんですか?

それがね、スクラムチームが “リファインメント” って呼ばれる活動を通じて、徐々に詳細を詰めていくんだ。説明、並び順、サイズなどの詳細を追加していくんだよ

誰が詳細を決めるんですか?

作業の規模を見積もるのは開発者の責任なんだ。でも、プロダクトオーナーが開発者を支援して、トレードオフを理解できるようにすることもあるよ

なるほど…でも、すべての項目を細かく詳細化する必要があるんですか?

いい質問だね!実は、近い将来(通常は次のスプリント)で取り組む項目だけを詳細化すればいいんだ。スクラムガイドでは “1スプリント内でスクラムチームが完成できる項目は、スプリントプランニングのときには選択の準備ができている” って書かれているよ
今日のポイント!
- プロダクトバックログの本質
- 創発的で順番に並べられたプロダクトの改善リスト
- スクラムチームが行う作業の唯一の情報源
- 常に進化し更新される
- プロダクトゴール
- プロダクトの将来の状態を表す
- プロダクトバックログ全体の方向性を示す
- チームの長期的な目標となる
- プロダクトバックログの特徴
- リファインメントを通じて詳細化される
- 開発者が作業規模を見積もる
- 近い将来の項目だけを詳細化する
- プロダクトゴールを達成するための具体的な “what” を定義する

プロダクトバックログって、ただのTODOリストじゃなくて、もっと生きているものなんですね

その表現、すごくいいね!次は、スプリントバックログについて話そうか

はい、お願いします!
第十二話「スプリントバックログの3つの要素」
(翌日のオフィス)

Bさん、今日はスプリントバックログについて教えていただけるんでしたよね

そうだよ。スプリントバックログって、どんなものだと思う?

えーと、スプリントでやることリスト…ですか?

うーん、それだけじゃないんだ。スクラムガイドによると、スプリントバックログは3つの要素で構成されているんだよ

3つの要素?

そう。
- スプリントゴール(なぜ)
- 選択されたプロダクトバックログアイテム(何を)
- インクリメントを届けるための実行可能な計画(どのように)
…この3つなんだ

おっ、”なぜ・何を・どのように” ですね!

よく気づいたね!これらは先日話したスプリントプランニングの3つのトピックと対応しているんだ

なるほど…でも、スプリントバックログは誰が作るんですか?

スプリントバックログは “開発者による、開発者のための計画” なんだ。スクラムガイドではそう明確に書かれているよ

開発者のための…じゃあプロダクトオーナーは関係ないんですか?

プロダクトオーナーは “何を” の部分で関わるけど、”どのように” の部分は開発者が決めるんだ。それに、大事なのは、スプリントバックログが固定的じゃないってことなんだよ

え?変更していいんですか?

うん。スプリントバックログには、スプリントゴールを達成するために開発者が行う作業が “リアルタイムに反映される” んだ。より多くのことを学ぶにつれて、スプリントの期間を通して更新されていくよ

でも、計画が変わるってことは、最初の計画があまり意味ないってことですか?

(笑)いい質問だね。実は、スプリントバックログには重要な “確約” があるんだ。それが “スプリントゴール” というものなんだよ

あ、さっきの3つの要素の1つ目ですね

その通り!スプリントゴールは、開発者が確約する唯一の目的なんだ。でも、それを達成するために必要な作業については柔軟性があるんだよ

つまり…目的は変えないけど、やり方は柔軟に変えていい、ということですか?

そう!それに、スプリントバックログには、デイリースクラムで進捗を検査できる程度の詳細さが必要なんだ

あ、だからデイリースクラムでスプリントバックログを見ながら話し合うんですね

その通り!スプリントバックログは、スプリントの中での私たちの羅針盤のようなものなんだよ
今日のポイント!
- スプリントバックログの3つの要素
- スプリントゴール(なぜ)
- 選択されたプロダクトバックログアイテム(何を)
- インクリメントを届けるための実行可能な計画(どのように)
- スプリントバックログの特徴
- 開発者による、開発者のための計画
- リアルタイムに更新される
- デイリースクラムで検査できる詳細さが必要
- スプリントゴールの役割
- スプリントの唯一の目的
- 開発者が確約するもの
- 作業の柔軟性を保ちながら一貫性を提供する

スプリントバックログって、チームの協力と自律性を支える道具なんですね

その通り!次は最後の作成物、インクリメントについて話そうか

はい!楽しみです!
第十三話「インクリメントと完成の定義」
(翌日、デモ環境の前で)

Bさん、今日は最後の作成物、インクリメントについて教えていただけるんですよね?

そうだよ。インクリメントって、どんなものだと想像する?

えーと、作ったものの増分…ですか?

その通り!スクラムガイドでは “プロダクトゴールに向けた具体的な踏み石” って表現されているんだ

踏み石…一歩一歩進んでいく、というイメージですか?

そう。でもね、インクリメントには重要な特徴があるんだ。3つあるよ:
- すべてのインクリメントが連携して機能する
- 徹底的に検証する必要がある
- 価値を提供するには利用可能でなければならない

連携して機能するって…?

例えば、新しい機能を追加したとき、それが既存の機能と正しく協調して動作する必要があるってことだね

なるほど。でも、インクリメントはスプリントの最後にしか作れないんですか?

いい質問だね!実はスクラムガイドには、スプリントの中で複数のインクリメントを作成できるって書かれているんだ

え?スプリントの途中でもいいんですか?

うん。それどころか、スプリント終了前にステークホルダーにデリバリーすることもできるんだよ。スプリントレビューは、価値をリリースするための関門じゃないんだ

へぇ…でも、どこまでできたら “インクリメント” って呼べるんですか?

それを定めるのが “完成の定義” というものなんだ。これはインクリメントの “確約” とも呼ばれているよ

完成の定義…具体的にはどんなものですか?

それはプロダクトの品質基準を示すものなんだ。例えば:
- すべてのテストが通っている
- コードレビューが完了している
- ドキュメントが更新されている
- セキュリティチェックが完了している
…といった感じかな

チェックリストみたいなものですね

そう!でも単なるチェックリストじゃないんだ。完成の定義には2つの重要な役割があるんだよ:
- 作業が完了してインクリメントの一部となったことの共通認識を作る
- 透明性を生み出す

透明性…またスクラムの3本柱が出てきましたね

よく気づいたね!完成の定義を満たしていないプロダクトバックログアイテムは、リリースすることはできないし、スプリントレビューで提示することもできないんだ

厳格なんですね…

うん。でもこれには理由があるんだ。品質を維持しながら、価値のあるインクリメントを確実に届けるため。これがスクラムの経験主義を支える重要な要素なんだよ
今日のポイント!
- インクリメントの特徴
- プロダクトゴールに向けた具体的な踏み石
- すべてのインクリメントが連携して機能
- 徹底的な検証が必要
- 利用可能である必要がある
- インクリメントの柔軟性
- スプリント内で複数作成可能
- スプリント終了前にデリバリー可能
- スプリントレビューは関門ではない
- 完成の定義の役割
- プロダクトの品質基準を示す
- 共通認識を作り出す
- 透明性を生み出す
- インクリメントの基準となる

インクリメントって、価値を届けるための具体的な形なんですね

その通り!さて、これでスクラムの主要な要素はすべて見てきたけど、最後にスクラム全体を振り返ってみようか

はい!お願いします!
第十四話「スクラムの全体像」

(週末、静かなカフェにて)

Bさん、この2週間、本当にたくさんのことを学ばせていただきました

うん、よく頑張ったね。今日は、これまで学んだことを整理してみようか

はい!

まず、スクラムの定義を覚えてる?

えーと…”複雑な問題に対応するための軽量級フレームワーク” …でしたっけ?

その通り!そして、スクラムは3つのシンプルなステップを繰り返すんだ:
- プロダクトオーナーが作業を優先順位付けする
- チームが価値を作り出す
- 結果を確認して改善する

あ、最初に教えていただいたシンプルな3ステップですね!

うん。これを支えているのが “経験主義” と “リーン思考” という2つの考え方だよね

はい!経験主義は “やってみて、確認して、改善する” で、リーン思考は “むだを省いてシンプルに” ということでしたね

よく覚えてる!そして、この考え方を実現するための3本柱が?

透明性、検査、適応です!

素晴らしい!これらを実践するために、5つの価値基準があったよね?

確約、集中、公開、尊敬、勇気…ですよね。チームの行動指針みたいなものです

その通り!そして、これらを実現する具体的な形が、3つの役割と5つのイベント、そして3つの作成物なんだ

ああ、全部つながってるんですね!
(ホワイトボードに図を描きながら)

そう!見てみて
3つの役割:
- プロダクトオーナー:価値を最大化する
- スクラムマスター:スクラムを機能させる
- 開発者:インクリメントを作る
5つのイベント:
- スプリント:他のイベントの入れ物
- スプリントプランニング:計画を立てる
- デイリースクラム:進捗を確認し調整する
- スプリントレビュー:成果を検査し適応を決める
- スプリントレトロスペクティブ:改善方法を計画する
3つの作成物とその確約:
- プロダクトバックログ → プロダクトゴール
- スプリントバックログ → スプリントゴール
- インクリメント → 完成の定義

これらが全部連携して、価値を生み出していくんだ

へぇ…図にすると、すごくクリアですね。でも、なんでこんなにきちんと定義されているんですか?

それは、スクラムガイドに書かれているんだ。”スクラムフレームワークは意図的に不完全” なんだけど、”スクラムの理論を実現するために必要な部分のみが定義されている” んだよ

不完全…でも必要な部分は定義されている…

そう。だからこそ、スクラムは様々な状況で使えるんだ。大事なのは、これらの要素がバラバラじゃなくて、お互いを支え合っているってことなんだよ
今日のポイント!
- スクラムの基本構造
- 理論:経験主義とリーン思考
- 3本柱:透明性・検査・適応
- 5つの価値基準:確約・集中・公開・尊敬・勇気
- スクラムの実践要素
- 3つの役割:それぞれが明確な責任を持つ
- 5つのイベント:検査と適応の機会を提供
- 3つの作成物:価値と作業を表現する
- スクラムの特徴
- 意図的に不完全なフレームワーク
- 必要な部分のみを定義
- すべての要素が相互に関連

Bさん、スクラムって最初は難しそうだと思ったんですが、考え方はすごくシンプルなんですね

そうなんだ。複雑な問題に対応するための、シンプルな枠組み…それがスクラムの本質なんだよ

ありがとうございました!これからチームの一員として、スクラムの実践に貢献していきたいと思います!

うん、一緒に頑張っていこう!
長いストーリーをお読みいただき、ありがとうございました。AさんとBさんの対話を通じて、スクラムの本質的な部分が少しでも伝わっていれば幸いです。最後に、重要なポイントを簡単にまとめておきましょう。
スクラムの本質
スクラムとは「複雑な問題に対応するための軽量級フレームワーク」です。その本質は以下の3つのシンプルなステップを繰り返すことにあります:
- プロダクトオーナーが作業を優先順位付けする
- チームが価値を作り出す
- 結果を確認して改善する
スクラムを支える考え方
- 経験主義:やってみて、確認して、改善する
- リーン思考:むだを省いてシンプルに
この2つの考え方から、透明性・検査・適応という3本柱が生まれ、確約・集中・公開・尊敬・勇気という5つの価値基準によって支えられています。
最後に
スクラムガイドは、意図的に不完全なフレームワークとして設計されています。大切なのは、その本質を理解しながら、チームの状況に合わせて適切に実践していくことです。
この記事が、皆様のスクラム実践の一助となれば幸いです。では、スクラムマスターのBさんの言葉で締めくくりましょう:
「複雑な問題に対応するための、シンプルな枠組み…それがスクラムの本質なんだよ」
コメント