ストーリーで学ぶスクラムガイド入門 〜現役アジャイルコーチによる解説〜

スクラム基礎

はじめに

「スクラムガイドって、なんだか難しそう…」

スクラムガイドを初めて読んだとき、多くの方がそう感じるのではないでしょうか。確かに、経験主義、スクラムの3本柱(透明性・検査・適応)、5つの価値基準など、重要な概念が多く登場します。

しかし、スクラムの本質はシンプルです。この記事では、新人エンジニアのAくんと、現役スクラムマスターのBさんとの対話を通じて、スクラムガイドの重要な概念をストーリー形式でわかりやすく解説していきます。チームの日常的な出来事や具体的な事例を交えながら、スクラムの理論から実践までを学んでいきましょう。

この記事の対象読者

  • スクラムガイドを読んでみたものの、実践的な理解に悩んでいる方
  • スクラムの基本概念を体系的に学びたい方
  • チームでスクラムを導入・改善したいと考えている方

この記事で学べること

  • スクラムの理論的基礎(経験主義・3本柱・5つの価値基準)
  • スクラムの実践要素(3つの役割・5つのイベント・3つの作成物)
  • スクラムガイドの読み方と解釈のポイント
  • 実践的な運用における注意点とコツ

17話からなるストーリーを通じて、スクラムの基礎から応用まで、体系的に理解を深めていきましょう。各話は独立して読むこともできますが、順番に読むことで、より深い理解が得られるように構成されています。

それでは、AくんとBさんの会話を通じて、スクラムガイドの世界を覗いていきましょう。

第一話「スクラムって何だろう?」

(とある IT 企業のオフィス)

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

うんうん。不安かい?

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

お願いします!

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

3つ…ですか?

Bさん
Bさん

うん。こんな感じ

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

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

なるほど…!

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

3本柱…ですか?

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

(笑)まあ、今日はこれだけでも十分だよ。ちょっと整理してみようか?

今日のポイント!

  1. スクラムとは?
    • 複雑な問題に対応するためのシンプルなフレームワーク
    • 3つの基本サイクル:優先順位付け→価値の創造→確認と改善
  2. スクラムの基礎となる考え方
    • 経験主義:実際の経験から学ぶ
    • リーン思考:むだを省いてシンプルに
Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

ありがとうございました!明日が楽しみです!

第二話「スクラムの3本柱って何?」

(翌日のオフィス)

Aくん
Aくん

おはようございます!

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

(笑)よし、じゃあコーヒーを入れながら話そうか

(オフィスのカフェスペースにて)

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

お願いします!

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

そう!この3本柱があるからこそ、スクラムは機能するんだ。ちょっと例え話をしてみようか

(ホワイトボードに絵を描きながら)

Bさん
Bさん

料理を作るところを想像してみて。

  • 透明性:今どんな状態か、あとどれくらいかかりそうかを、キッチンに立ち寄る誰もが分かるようにしておく
  • 検査:お客さんに少し味見してもらう
  • 適応:お客さんの反応を見て味付けを調整する

こんな感じ。これなら自然だと思わない?

Aくん
Aくん

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

Bさん
Bさん

でしょ?スクラムって、実は人間の自然な活動をうまく形にしただけなんだよ

今日のポイント!

  1. スクラムの3本柱
    • 透明性:誰もが状況を理解できるように見える化する
    • 検査:定期的に確認して問題点を見つける
    • 適応:必要に応じて改善・調整する
  2. 3本柱の特徴
    • 3つは相互に関連している
    • 自然な人間の活動をフレームワーク化したもの
    • 変化に対応するための基礎となる
Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

おっ、また新しい話が!

Bさん
Bさん

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

Aくん
Aくん

はい!ありがとうございました!

第三話「スクラムの5つの価値基準」

(数日後のオフィス)

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

全力を尽くす…

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

その通り!ちょっと具体例を出してみようか

(ホワイトボードに書きながら)

Bさん
Bさん

こんなシナリオを考えてみて:

  • チームで難しい機能の開発を約束した(確約)
  • その機能に集中して取り組む(集中)
  • 途中で技術的な壁にぶつかったことを素直に共有する(公開)
  • チームメンバーが互いの意見を尊重しながら解決策を探る(尊敬)
  • 従来とは違うアプローチを試してみる(勇気)

これが理想的な流れ。どう?イメージつく?

Aくん
Aくん

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

Bさん
Bさん

いい質問!完璧にはいかないかもしれない。でも、この5つを意識することで、チームはどんどん良くなっていくんだ

今日のポイント!

  1. スクラムの5つの価値基準
    • 確約:目標達成に向けて全力を尽くす
    • 集中:今の目標に焦点を合わせる
    • 公開:状況や課題を隠さず共有する
    • 尊敬:お互いを専門家として認め合う
    • 勇気:必要な行動を起こす勇気を持つ
  2. 価値基準の特徴
    • 相互に関連している
    • 理想を追求しながら段階的に改善していく
    • チームの成長を支える基盤となる
Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

はい、楽しみにしています!

第四話「スクラムチームの本質」

(翌週のオフィス)

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

基本単位というと?

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

一つの目的…ですか?

Bさん
Bさん

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

Aくん
Aくん

はい!

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

それは、プロダクトオーナーとプロダクトバックログについて説明するときに詳しく話そう。今日は、スクラムチームの基本的な特徴を押さえておこうか

今日のポイント!

  1. スクラムチームの構成
    • スクラムマスター1人、プロダクトオーナー1人、開発者で構成
    • サブチームや階層が存在しない
    • 一つの目的(プロダクトゴール)に集中
  2. スクラムチームの特徴
    • 機能横断型:必要なスキルをチーム全体として保有
    • 自己管理型:作業の計画と実行をチームで決定
    • 10人以下の小規模:効果的なコミュニケーションと生産性のため
  3. スクラムチームの責任
    • プロダクトに関するすべての活動に責任を持つ
    • 持続可能なペースで作業を行う
    • スプリントごとに価値のある有用なインクリメントを作成する
Aくん
Aくん

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

Bさん
Bさん

うん、それぞれの役割には明確な責任があるんだ。また明日、詳しく説明するよ

第五話「スクラムチームの3つの役割」

(午後のオフィス、ホワイトボードの前で)

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

はい!

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

主に4つの責任があるよ:

  1. スプリントの計画を立てる
  2. 品質を確保する
  3. 毎日の計画を必要に応じて調整する
  4. お互いに専門家として責任を持つ
Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

(カフェスペースに移動しながら)

Bさん
Bさん

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

Aくん
Aくん

はい!

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

主に5つの重要な仕事があるよ:

  1. プロダクトゴールを定める
  2. プロダクトバックログのアイテムを作って、明確に伝える
  3. アイテムの優先順位をつける
  4. プロダクトバックログを透明にする
  5. 開発者がプロダクトバックログを理解できるようにする
Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

うん。スクラムマスターの主な仕事は、スクラムがうまく機能するように支援することなんだ。具体的には3つの方向で支援するよ:

  1. スクラムチームを支援する
  2. プロダクトオーナーを支援する
  3. 組織を支援する
Aくん
Aくん

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

Bさん
Bさん

例えばチームの支援だと:

  • 自己管理とチーム作りをサポート
  • チームが価値の高い成果物に集中できるよう手助け
  • 障害物を取り除く
  • スクラムのイベントがうまく進むようにする

…といった感じかな

Aくん
Aくん

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

Bさん
Bさん

(笑)まあ、でもただのお世話係じゃないよ。スクラムマスターは “奉仕型のリーダー” なんだ。チームが最高のパフォーマンスを発揮できるように導くんだよ

今日のポイント!

  1. スクラムチームの3つの役割
    • 開発者:価値のあるインクリメントを作る
    • プロダクトオーナー:プロダクトの価値を最大化する
    • スクラムマスター:スクラムがうまく機能するように支援する
  2. 開発者の特徴
    • 自己管理型
    • スプリントごとに価値を届ける
    • お互いに専門家として責任を持つ
  3. プロダクトオーナーの責任
    • プロダクトゴールの設定
    • プロダクトバックログの管理
    • 価値の最大化
  4. スクラムマスターの役割
    • チーム、PO、組織への支援
    • 奉仕型のリーダーシップ
    • スクラムの実践をガイド
Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

(笑)大丈夫、ひとつずつ理解していけば簡単だよ。また明日ね!

第六話「スクラムの心臓、スプリントとは」

(次の週のオフィス)

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

心臓の鼓動?

Bさん
Bさん

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

Aくん
Aくん

決まった長さ?

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

どんな問題ですか?

Bさん
Bさん

例えば:

  • スプリントゴールが役に立たなくなる可能性がある
  • 複雑さが増してしまう
  • リスクが高まる
Aくん
Aくん

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

Bさん
Bさん

スプリントを短くすると:

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

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

Bさん
Bさん

スプリントの中では、プロダクトゴールを達成するために必要なすべての作業が行われるんだ。具体的には:

  • スプリントプランニング
  • デイリースクラム
  • スプリントレビュー
  • スプリントレトロスペクティブ
Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

ルール?

Bさん
Bさん

うん。スプリント中は:

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

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

その通り!スプリントは、複雑な開発を管理可能な範囲に収める仕組みなんだ。次回は、スプリントの中で行われる最初のイベント、スプリントプランニングについて詳しく見ていこう

今日のポイント!

  1. スプリントの基本
    • スクラムの心臓部分
    • 1か月以内の一定期間
    • アイデアを価値に変える器
  2. スプリントの特徴
    • 一貫性のある期間設定
    • 複雑さとリスクの制御
    • 学習サイクルの確保
  3. スプリントのルール
    • 目標を危険にさらす変更の禁止
    • 品質の維持
    • 必要に応じたリファインメント
    • スコープの再交渉可能性
Aくん
Aくん

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

Bさん
Bさん

うん、スプリントの中で行われる各イベントには、それぞれ重要な目的があるんだ。また明日、詳しく説明するよ

第七話「スプリントプランニングの3つのトピック」

(翌日のオフィス)

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

3つ…ですか?

Bさん
Bさん

うん。

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

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

選択の基準は?

Bさん
Bさん

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

Aくん
Aくん

リファインメントって?

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

8時間!結構長いですね

Bさん
Bさん

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

Aくん
Aくん

スプリントバックログ?

Bさん
Bさん

これは、スプリントゴール、選択したプロダクトバックログアイテム、そして実行計画をまとめたものだね。でも、これについては次回詳しく説明しよう

今日のポイント!

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

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

Bさん
Bさん

その通り。次は、この計画に基づいて実際の開発が始まるんだけど、その中で重要なイベントが “デイリースクラム” というものなんだ

第八話「デイリースクラムの本質」

(翌日のオフィス)

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

え…それだけですか?

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

その表現、いいね!まさにその通り。チームの “心臓の鼓動” とも言えるかもしれないね

今日のポイント!

  1. デイリースクラムの基本
    • 15分のタイムボックス
    • 毎日同じ時間・場所で開催
    • 開発者のためのイベント
  2. デイリースクラムの目的
    • スプリントゴールに向けた進捗の確認
    • 必要に応じた計画の調整
    • コミュニケーションの改善
    • 障害物の特定
    • 迅速な意思決定の促進
  3. デイリースクラムの特徴
    • 形式は開発者が選択可能
    • より詳細な議論は別途実施
    • 一日を通じた頻繁なコミュニケーションの一部
Aくん
Aくん

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

Bさん
Bさん

それは良かった!明日は実際のデイリースクラムに参加してもらおうか。その後で、スプリントレビューについて話そう

第九話「スプリントレビューの真価」

(デイリースクラムの後のカフェスペースで)

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

ワーキングセッション?

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

よく覚えてたね!スプリントレビューでは、スクラムチームとステークホルダーが一緒に、2つのことを確認するんだ:

  1. スプリントで何が達成されたか
  2. 環境で何が変化したか
Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

例えば:

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

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

Bさん
Bさん

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

Aくん
Aくん

4時間!結構長いですね

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

その通り!スプリントレビューは、検査と適応の機会であると同時に、次のスプリントの準備でもあるんだ

今日のポイント!

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

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

Bさん
Bさん

うん。明日は最後のイベント、スプリントレトロスペクティブについて話そうか

第十話「スプリントレトロスペクティブの真髄」

(翌日、静かな会議室で)

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

どんな目的なんですか?

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

スクラムガイドによると、主に5つの観点から検査するんだ:

  1. 個人
  2. 相互作用
  3. プロセス
  4. ツール
  5. 完成の定義
Aくん
Aくん

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

Bさん
Bさん

そう。でも大事なのは、ただ振り返るだけじゃないってことなんだ。スクラムチームは3つのことを話し合うんだよ:

  1. うまくいったこと
  2. どんな問題が発生したか
  3. それらがどう解決されたか(または解決されなかったか)
Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

例えば:

  • コミュニケーションの方法を改善する
  • 開発環境を改善する
  • チーム内のルールを見直す
    といった感じかな
Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

うん。でもね、この時間は投資だと思うんだ。より良いチームになるための投資。だからこそ、スプリントレトロスペクティブはスクラムの重要なイベントとして位置づけられているんだよ

今日のポイント!

  1. スプリントレトロスペクティブの目的
    • 品質と効果を高める方法を計画すること
    • チームの改善点を特定し、実行計画を立てること
  2. 検査の観点
    • 個人
    • 相互作用
    • プロセス
    • ツール
    • 完成の定義
  3. 重要な特徴
    • 単なる振り返りではなく、改善のための具体的な計画を立てる
    • 最も影響の大きな改善を優先する
    • 改善活動を次のスプリントバックログに含めることができる
    • 1ヶ月のスプリントなら最大3時間
Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

はい!楽しみです!

第十一話「プロダクトバックログとプロダクトゴール」

(翌日、ホワイトボードの前で)

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

はい!

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

具体的には?

Bさん
Bさん

例えば:

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

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

いい質問だね!実は、近い将来(通常は次のスプリント)で取り組む項目だけを詳細化すればいいんだ。スクラムガイドでは “1スプリント内でスクラムチームが完成できる項目は、スプリントプランニングのときには選択の準備ができている” って書かれているよ

今日のポイント!

  1. プロダクトバックログの本質
    • 創発的で順番に並べられたプロダクトの改善リスト
    • スクラムチームが行う作業の唯一の情報源
    • 常に進化し更新される
  2. プロダクトゴール
    • プロダクトの将来の状態を表す
    • プロダクトバックログ全体の方向性を示す
    • チームの長期的な目標となる
  3. プロダクトバックログの特徴
    • リファインメントを通じて詳細化される
    • 開発者が作業規模を見積もる
    • 近い将来の項目だけを詳細化する
    • プロダクトゴールを達成するための具体的な “what” を定義する
Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

はい、お願いします!

第十二話「スプリントバックログの3つの要素」

(翌日のオフィス)

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

3つの要素?

Bさん
Bさん

そう。

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

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

その通り!スプリントバックログは、スプリントの中での私たちの羅針盤のようなものなんだよ

今日のポイント!

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

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

Bさん
Bさん

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

Aくん
Aくん

はい!楽しみです!

第十三話「インクリメントと完成の定義」

(翌日、デモ環境の前で)

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

そう。でもね、インクリメントには重要な特徴があるんだ。3つあるよ:

  1. すべてのインクリメントが連携して機能する
  2. 徹底的に検証する必要がある
  3. 価値を提供するには利用可能でなければならない
Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

それはプロダクトの品質基準を示すものなんだ。例えば:

  • すべてのテストが通っている
  • コードレビューが完了している
  • ドキュメントが更新されている
  • セキュリティチェックが完了している
    …といった感じかな
Aくん
Aくん

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

Bさん
Bさん

そう!でも単なるチェックリストじゃないんだ。完成の定義には2つの重要な役割があるんだよ:

  1. 作業が完了してインクリメントの一部となったことの共通認識を作る
  2. 透明性を生み出す
Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

厳格なんですね…

Bさん
Bさん

うん。でもこれには理由があるんだ。品質を維持しながら、価値のあるインクリメントを確実に届けるため。これがスクラムの経験主義を支える重要な要素なんだよ

今日のポイント!

  1. インクリメントの特徴
    • プロダクトゴールに向けた具体的な踏み石
    • すべてのインクリメントが連携して機能
    • 徹底的な検証が必要
    • 利用可能である必要がある
  2. インクリメントの柔軟性
    • スプリント内で複数作成可能
    • スプリント終了前にデリバリー可能
    • スプリントレビューは関門ではない
  3. 完成の定義の役割
    • プロダクトの品質基準を示す
    • 共通認識を作り出す
    • 透明性を生み出す
    • インクリメントの基準となる
Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

はい!お願いします!

第十四話「スクラムの全体像」

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

はい!

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

その通り!そして、スクラムは3つのシンプルなステップを繰り返すんだ:

  1. プロダクトオーナーが作業を優先順位付けする
  2. チームが価値を作り出す
  3. 結果を確認して改善する
Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

(ホワイトボードに図を描きながら)

Bさん
Bさん

そう!見てみて

3つの役割:

  • プロダクトオーナー:価値を最大化する
  • スクラムマスター:スクラムを機能させる
  • 開発者:インクリメントを作る

5つのイベント:

  • スプリント:他のイベントの入れ物
  • スプリントプランニング:計画を立てる
  • デイリースクラム:進捗を確認し調整する
  • スプリントレビュー:成果を検査し適応を決める
  • スプリントレトロスペクティブ:改善方法を計画する

3つの作成物とその確約:

  • プロダクトバックログ → プロダクトゴール
  • スプリントバックログ → スプリントゴール
  • インクリメント → 完成の定義
Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

そう。だからこそ、スクラムは様々な状況で使えるんだ。大事なのは、これらの要素がバラバラじゃなくて、お互いを支え合っているってことなんだよ

今日のポイント!

  1. スクラムの基本構造
    • 理論:経験主義とリーン思考
    • 3本柱:透明性・検査・適応
    • 5つの価値基準:確約・集中・公開・尊敬・勇気
  2. スクラムの実践要素
    • 3つの役割:それぞれが明確な責任を持つ
    • 5つのイベント:検査と適応の機会を提供
    • 3つの作成物:価値と作業を表現する
  3. スクラムの特徴
    • 意図的に不完全なフレームワーク
    • 必要な部分のみを定義
    • すべての要素が相互に関連
Aくん
Aくん

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

Bさん
Bさん

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

Aくん
Aくん

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

Bさん
Bさん

うん、一緒に頑張っていこう!

長いストーリーをお読みいただき、ありがとうございました。AさんとBさんの対話を通じて、スクラムの本質的な部分が少しでも伝わっていれば幸いです。最後に、重要なポイントを簡単にまとめておきましょう。

スクラムの本質

スクラムとは「複雑な問題に対応するための軽量級フレームワーク」です。その本質は以下の3つのシンプルなステップを繰り返すことにあります:

  1. プロダクトオーナーが作業を優先順位付けする
  2. チームが価値を作り出す
  3. 結果を確認して改善する

スクラムを支える考え方

  • 経験主義:やってみて、確認して、改善する
  • リーン思考:むだを省いてシンプルに

この2つの考え方から、透明性・検査・適応という3本柱が生まれ、確約・集中・公開・尊敬・勇気という5つの価値基準によって支えられています。

最後に

スクラムガイドは、意図的に不完全なフレームワークとして設計されています。大切なのは、その本質を理解しながら、チームの状況に合わせて適切に実践していくことです。

この記事が、皆様のスクラム実践の一助となれば幸いです。では、スクラムマスターのBさんの言葉で締めくくりましょう:

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

この記事を書いた人
kawagoi

SM、アジャイルコーチ歴8年
Yahoo6年間→永和SM2年→フリーSM2年
20社コンサル・講演20回以上・著書7冊
教育心理学・スクラムマスター・1on1・リーダーシップ

kawagoiをフォローする
スクラム基礎
kawagoiをフォローする

コメント

タイトルとURLをコピーしました