Scrum A to Z：スクラム導入講習 (日本語)

日本一凝縮されたスクラム研修ビデオを作ってみました。スクラムの全てをカバーしつつ、なんと2時間切りです。2020年版スクラムガイド準拠。

講義スライドダウンロード: PDF

修了クイズ: 30問

学習ガイド

この講義は、通常2~3日で行うスクラム研修の理論と実践知識の部分のみを2時間弱のビデオ講義にまとめたものです。
もし通常のスクラム研修に参加できる機会があるようでしたら、そちらを推奨します。じっくりと時間をかけて知識を吸収し、実践練習の機会もありますので、学習の内容としてはそちらの方が良いでしょう。
しかし、時間的制約や、コストの問題等で参加できない場合は、次善策としてこちらのビデオ講習を活用ください。スクラムをやるにはセットアップが必要です。それにはスクラムチーム員の実践前トレーニングも含まれます。何らかの事情で通常のスクラム研修を受けられない方でも、スクラムをはじめる前に正しい知識で実践に臨めるように、このビデオ講義を用意しました。ご活用ください。
また、スクラムに興味のある方、これからスクラム研修を受けるのでその前に予習をしておきたい方、スクラムをすでに実践しているがあらためて体系的にスクラム理論を復習したい方、デザイン思考やその他アジャイルフレームワークを使っている方がスクラムについても学んでみたい場合等も、自由に学習に活用ください。
通常2~3日かけて教える内容を極端に凝縮した講義です。2時間弱のこのビデオを一回見れば十分な属性の学びではありません。
推奨する学習方法として、講義本文でも推奨している準備学習としてのスクラムガイドの通読を活用する方法を紹介します。はじめてスクラムガイドを読んだ際は、スクラムの独自用語が多く誰しも内容を完全に理解できないと思います。この Scrum A to Z 講習は、スクラムガイドを詳細に解読しています。講習後、再度スクラムガイドを読んでみて、どれだけスクラムの理解が深まったか自己検証してみてください。学び足りなかった部分が多少出てくるかと思います。必要に応じて、この講習で復習ください。検証と適応、今回の学び方法も早速アジャイルで行きましょう。
修了時に30問のクイズを用意しています。学びの確認に利用ください：修了クイズ
では、がんばってください。応援しています！

講義録

スクラム導入講習へようこそ。こんにちは、アジャイル組織開発、チーフコーチの吉田です。
スクラムをやるならば、Scrum A to Z、最初から最後までスクラムのルールに則ってやりましょう。
意図的にスクラムの一部要素のみを使って、独自のアジャイル開発体制を組むことは可能です。ただし、その時点ですでにスクラムとは呼べなくなりますので注意しましょう。
一方で、あまり意識せずにスクラムの要素を端折ってスクラムを実践しようとすると、なにかとうまくいきません。「なんちゃってスクラム」のトラップに陥いらないためには、スクラムを正しくやることが大切です。スクラムの全要素を理解してから、スクラムの実践に入りましょう。
では、始めましょう。

スクラムの学習に入る前に、二つほど準備をお願いしたいと思います。

まず、私の「Agile 101 (アジャイル基礎講座)」をまだ受講されたいない方は、先にそちらを受けてください。こちらにオンラインであげておいてありますので、ご参照ください。
アジャイルは、英語で言う「complex adaptive problems」つまり、世の中の複雑かつ流動的な課題に解決を見出していくアプローチの総称です。スクラムはそのアジャイルの実践フレームワークのひとつです。
複雑な課題に対応するためにスクラムを使うので、スクラムはそもそもマニュアル通りに実行するタイプのメソッドではありません。スクラムを単なるプロセスメカニズムとして使用すると、大して成果も出ず、無駄骨の努力になってしまうのはそのためです。
スクラムにその真価を発揮させるためには、必ずまず「なぜアジャイル？」から学び、考えるところからはじめてください。そうすると、次の大事な質問「なぜスクラム？」を考えることができ、有意義な答えが見つかるとスクラム実践に対して良いスタートが切れるでしょう。

次に、スクラムガイドを一旦通読ください。
Scrum.org よりスクラムマスター等の資格を取得する意向の方は、試験が英語なので英語版のスクラムガイドを習熟する必要があります。日本語訳版もありますので、そちらを参考にしながら英語版オリジナルのスクラムガイドを通読ください。
資格取得の予定のない方は、日本語版のスクラムガイドを通読するだけで結構です。

ご参考までに、英語版、日本語版のスクラムガイドで使用されるスクラム用語の英日対比をこちらにまとめておきますので今後の参照にご使用ください。

スクラムの理論と実践についてお話しします。
スクラムは「lightweight framework (軽量級フレームワーク)」とスクラムガイドでは表現されていますが、ひとつひとつのフレームワーク要素が繰り返し検証プロセスを得て吟味され組み込まれたものであり、要素のひとつでも端折られるともはやスクラムとは呼べなくなる性格のものです。そのため、スクラム実践に入る前に、その全体と個々要素を総合的に学ぶ必要があります。本スクラム導入講座は、スクラムを正しく実践するための前提条件としての理論的学びという位置づけです。
もちろん実践あってこその理論です。スクラムの理論はあくまでもフレームワーク、実践を通してスクラムをより良いチームワークに、プロダクト開発に活用して経験を積んでこそ価値があります。
実際にこれよりスクラムをチームとして実践する予定があり、本講座がまさしくそのための導入研修であれば万端です。
一方で、まだスクラムを実践する予定がない場合はぜひその機会を早々に見つけてください。
すでに自身が所属するチームがあり、対象となるプロダクト・サービス開発機会が考えられ、かつ組織の体制が可能にする場合は、ぜひチームにスクラムを試みることを提案してみてください。
さもなくば、スクラムに興味のあるチームを見つけてください。スタートアップの友人にアプローチし、自身がスクラムマスターやコーチの立場で関わることを提案にそのチームのひとつにスクラムを実践することを検討してもらうのも良いでしょう。機会はたくさんあります。

準備OKでしょうか？では、スクラムの理論、学んで行きましょう。

まずスクラムの定義から。「スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、人々、チーム、組織が価値を生み出すための軽量級フレームワークである。」
この定義文にはスクラムの意図が凝縮されています。
「複雑な問題に対応する適応型のソリューション」、そもそもアジャイルをやる理由ですね。
「人々、チーム、組織」、そう、スクラムはコラボレーションありきのフレームワークです。
そして、「価値を生み出す」こと、スクラムの目標です。逆に言うと価値を生み出さないことは避ける、この辺りにリーンの精神がすでに垣間見えますね。
そして、スクラムを「フレームワーク」ととらえ、メソッドと呼ばないのは意図的です。メソッドはステップバイステップで実行する性格のものであり、スクラムはそのタイプのツールではありません。さらに、「軽量級」のフレームワークであると称しているところに、機動性とユーザーの自由な使用方法に期待を寄せています。
スクラムガイドではさらに、「スクラムはシンプルである」こと、「スクラムフレームワークは意図的に不完全なものであり、スクラムの理論を実現するために必要な部分のみが定義されている」と記述しています。スクラムの実践では、”Scrum AND”、スクラムと共に、というコンセプトがあります。これは、スクラムと共に、例えばリーンやデザイン思考などスクラム以外の様々なプロセスやツールを組み合わせて使うことを積極的に推奨するコンセプトです。
「スクラムのルールは詳細な指⽰を提供するものではなく、実践者の関係性や相互作⽤をガイドするものである。」こちらの記述は先ほど述べた、スクラムがステップバイステップのメソッドではなく、チームワークのコラボレーションガイドであることの説明ですね。
「スクラムは「経験主義」と「リーン思考」に基づいている。経験主義では、知識は経験から⽣まれ、意思決定は観察に基づく。リーン思考では、ムダを省き、本質に集中する。」経験主義とは、一般的に「Evidenced-Based Management (エビデンスベースドマネジメント)」と呼ばれる、観察やデータからのエビデンス、つまり証拠や根拠に基づいて物事の判断や意思決定をするビジネス習慣を指します。リーンは、トヨタ生産方式などで日本では馴染み深いコンセプトですので説明は省きます。

簡単に言えば、と、スクラムガイドではスクラムとは、を次のように説明しています。
「スクラムとは次の環境を促進するためにスクラムマスターを必要とするものである。プロダクトオーナーは、複雑な問題に対応するための作業をプロダクトバックログに並べる。スクラムチームは、スプリントで選択した作業を価値のインクリメントに変える。スクラムチームとステークホルダーは、結果を検査して、次のスプリントに向けて調整する。繰り返す。」
簡単に、というわりにはわかりにくいですね。解説しましょう。
後述しますが、スクラムチームにはスクラムマスターとプロダクトオーナーという二人のリーダーが付きます。
スクラムマスターは、チームの開発環境を整え、円滑なチームワークを促進するリーダーです。
プロダクトオーナーは、チームがなにを開発するか命題を持ってくるリーダーです。その開発目標、命題は、そもそもアジャイルをやる性質のものですので、ここでは「複雑な問題」と表現しています。
プロダクトバックログとはチームの開発作業予定を共有する、いわゆるカンバンボードです。プロダクトオーナーは、プロダクトバックログを活用してチームと開発作業を進めます。
スクラムでは、期間を決めた短期のサイクルで開発を「回して」行きます。このサイクルをスプリントと呼びます。コンセプトは、ウォーターフォール開発のように比較的長期の開発期間において最初から最後まで開発するのではなく、スプリントを回して、こまめに少しずつ成果を重ねて行くやり方です。インクリメントとは直訳では「差分」で、このこまめに出して行く成果のことです。
スプリント周期の最後には、スプリントレビューと呼ばれるステークホルダーなどを招いての成果共有会を開催します。スプリントレビューでの参加者からのフィードバックを反映して、次のスプリントの準備をして繰り返して行く、これがスクラムのリズムです。

スクラムの要素をカテゴライズしてこのようにまとめました。
これよりこれらをひとつずつ深堀りして学んで行きましょう。
すでにお話しした通りスクラムはライトウェイトフレームワークで、スクラムガイドはスクラムの必要最低限の骨子のみを記述しています。実践のスクラムはコラボレーションと経験主義に基づいており、それを反映してスクラム実践者のコミュニティー活動は活発で、実務的な知識や知恵をインターネット上で共有して参りました。私のこの Scrum A to Z もそのコミュニティー活動への貢献の一環です。
これから共有する学びはこのスクラム実践者コミュニティーから生成されたものです。英語がソースの記述を日本語訳しましたが、翻訳がなかなか難しかったものも多々ありましたので、適時解説を加えて行きたいと思います。

最初はスクラムのスピリット、スクラムの三つの柱、そして五つの価値基準です。
スクラムのやり方を学ぶ前に、まずスクラムの精神に時間を割くのは意図的です。
かなり長い説明になりますが、それは多くのチームがはまってしまう、プロセスだけのスクラムの罠に陥らないでほしいためです。どうぞ、じっくりお付き合いください。
では、まずスクラムの「柱」三要素、「透明性」、「検査」、「適応」を見ていきましょう。

スクラムの「経験主義」の三本柱は、「透明性」、「検査」、「適応」です。
経験主義 (empiricism) は、事実に基づき、経験に基づき、証拠に基づいて作業することを意味します。進捗は、架空の計画ではなく現実の観察に基づいて、仕事を進めて行きましょう。
複雑な課題に取り組むとき、次の一手はそのひとつ前のステップに取り掛かっているときにようやく見えてくるものです。この現象を「emergence」、事象の創発性と呼びます。
透明性 (transparency)は、創発的 (emergent) なプロセスや作業を可視化することを意味します。
検査 (inspection)。スクラムの作成物と合意されたゴールに向けた進捗状況は、「頻繁かつ熱⼼に」検査されなければなりません。検査は適応を可能にします。適応がなければ、検査は無意味と見なされます。スクラムのイベントは変化を促すように設計されています。
適応 (adaptation)。適応とは、検査の結果に基づいて継続的にプロセスや作業を調整する能力のことです。スクラムチームは検査によって新しいことを学んだ瞬間に適応することが期待されています。ここで大事になってくるのが、チームの自律ですね。スクラムチームに権限が与えられていないときや、⾃⼰管理されていないときは、チームの適応能力が大幅に低下します。
まとめると、何が起きているかみんな見えている状態が透明性、必要に応じてアプローチや方向性をどんどん調整していいですよ、というのが適応、そしてうまく適応するには細やかな検査が必要ですよ、ということです。

次にスクラムの「価値基準」五要素、「集中」、「公開」、「勇気」、「確約」、「尊敬」を見ていきましょう。
これら五つの価値はどれも人生訓的に当たり前なことばかりで、ついつい読み飛ばしてしまいそうです。スクラムガイドでこれらをあえて表記しているのは理由があります。深堀りして学んで行きましょう。

スクラムの価値基準とフォーカス(集中) がないといけない第一の理由、それはフォーカスの価値を意識しないでスクラムを実践すると、機械的にただ手順を踏んでいるだけのスクラムになってしまう可能性があるためです。
スクラムの各要素と集中、フォーカスの価値の関係を詳しく見ていきましょう。
まず、少しずつインクリメントを出して積み重ねていくことの重要性：少なくとも毎スプリントの終わりまでに「完成」したインクリメントを出すことに、フォーカスします。
スクラムのイベントと作成物：スクラムのイベントと作成物は、開発の進捗と新たに出現した情報の検査にフォーカスすることを助けてくれます。
スプリントゴール：チームが何をデリバリーするかを明確にするため、スプリントゴールにフォーカスします。
プロダクトバックログ：プロダクトバックログは順序付けられたリストであり、次にやらなければいけない最も重要なことにフォーカスすることを助けてくれます。
スクラムの各イベントに時間制限がついているのはなぜでしょう？：タイムボックス化されたイベントは緊急感を作り、各イベントの目的にフォーカスすることを助けてくれます。
経験主義 (empiricism) とコラボレーション：フォーカスの価値は、経験主義と協力的なチームワークを促進します。スクラムチーム員がお互い協力してプロダクトバックログアイテムを一緒に取り組むと、個別に仕事をするより効果的な場合が多々あります。
成果を出して行くことの共同責任：毎スプリントで価値のある有用なインクリメントを出して行く責任はスクラムチーム全員が負います。この共同責任は、個人のパフォーマンスよりも、全体的な成果を優先させることにフォーカスさせてくれます。
プロダクトゴール：プロダクトゴールを持つことは、チームの進むべき方向性を明確にし、チームとしての毎日の判断、決定事項に考慮すべき正しい情報にフォーカスさせてくれます。
最後の二つは取捨選択と、不確実性に直面した時という、チームとして難しい局面に立った時に、このフォーカスの価値がどう手助けしてくれるかの考えです。
優先事項が競合するとき、集中の価値、フォーカスはチームが今何が最も重要かを決定するのに役立ちます。
将来が不確実なとき、行動を先送りし、分析を続けたくなる傾向があります。フォーカスはチームが不確実性を受け入れ、今現在知っている情報に集中し、小さな一歩を踏み出すのに役立ちます。

続けて、公開、オープンさというスクラムの価値についてみていきましょう。
「作業や課題をオープンにすると、開発の進捗状況の透明性を生み出すのに役立ちます。透明性無き検査と適応の試みは自ずと欠陥があるので、透明性の確保は重要です。」スクラムは「inspect and adapt」、検査と適応の繰り返しサイクルの活動です。その検査と適応が閉ざされたループだと、果たしてその活動が正しいかどうかどうやってチェックすることができるでしょうか？開発をオープンにするのはこのあたりに理由があります。
「オープンな環境は協力的なチームワークを促進します。それは垣根なくチームメンバーが相互に助けを求めたり、提供したりすることを可能にします。」自分の仕事だけやれれば確かに楽ですよね。でも、スクラムはコラボレーションのフレームワークです。スクラムをはじめてやる方は、この極端なまでにオープンなチームワークのやり方に良く戸惑います。でも、慣れれば本当に楽しいですよ、スクラムのチームワークは。
多彩な意見の出るチームはチームの意思決定が難しそうなイメージがありますが、実はそうでもないです。「オープンなコミュニケーションが実現できているチームでは、チームメンバーが自分の視点を共有し、仲間からしっかりと聞く耳を持たれ理解と共感を得られると、意見の異なるチーム員もチームの決定を支援できるようになります。」自分の意見と、チームの決定尊重、この二律背反を実現できるようになります。
「オープンな取り組みは経験主義を促進します。現在の仮説が有効でないことが判明したとき、オープンにそれが認められれば、適応して戦術やアプローチを柔軟に変えることができます。」経験主義、エビデンスベースマネージメントですね。人間は元来思い込みで動く性質があり、また時にはプライドが邪魔して仕事上の方針転換、方向転換がなかなかできないことが多々あります。有史以来人類はこれでどれだけ損してきたんでしょうね。みんなオープンにアジャイルをやれれば世の中もっと良くなると思いますが、なかなか大変です。
「スプリントが最長1ヶ月までに期間が制限されている理由は、開発中に新しい情報が出現した際、必要に応じて開発の方向性を変えることができるオープンさを促進させるためです。」スプリントは期間が決まっていて、終わりにスプリントレビューが必ずあるので、仕組み上開発の状況を定期的にオープンにせざるを得ません。結果、検査と適応の機会が比較的短い期間で定期的に訪れます。
「スプリントゴールはスプリント期間中に変更してはいけないルールです。一方で、スプリントゴールを達成するためのアプローチや作業は、開発者がスプリント中の作業で新たに学んだことに適応してオープンに調整、変更することが可能です。」スプリントゴールは変えてはいけないけれど、その達成方法はどんどん変えて行っていいですよ、というこの仕組み、なかなか賢いですよね。のちほどスクラムイベント、スプリントのところで詳しく見ていきましょう。
「透明性のあるプロダクトバックログは、ステークホルダーに現在開発を計画していること(及び計画していないこと)、そして次に予定していることをオープンに共有していることを示します。」そうなんです、バックログは実はコミュニケーションツールなんですね。これもあとで詳しく見ていきましょう。
「スプリントレビューは、ステークホルダーとオープンに進捗を共有し、フィードバックを通してコラボレーションを進める場です。」ウォーターフォールでも定例の進捗報告会はあるでしょう。従って、定期的にレビューミーティングがあるだけでは足りません。レビューミーティングのやり方にも工夫が必要です。この辺りにもスクラムはなかなか賢い仕組みを用意しています。
最後にスプリントレトロスペクティブでスプリントは終了します。このレトロは本当に大事なイベントで、スクラムのチームワークがどんどん良くなれるかはレトロにかかっていると言っても過言ではありません。「スプリントレトロスペクティブは、チーム員間の交流、コミュニケーション、相互作用及びチームワークのプロセスやツールについて、互いにオープンにフィードバックし、振り返り、チームの働き方の継続的なカイゼンを図る場です。」

スクラムの価値基準、次は勇気です。
「すべてのスクラムイベントは、検査と適応の機会です。方向修正や方針転換が必要な時は、勇気を持って、取り組みましょう。「何を」作るか (what)、「どうやって」作るか (how)、それぞれ私たちはその方向性を変えることができます。」
「スプリントのタイムボックスは、失敗の影響をスプリントの期間の範囲内に限定します。これにより、新しいことを試み、実験し、学ぶ勇気が与えられます。」スクラムは失敗ありきです。多くのアジャイルチームをコーチして参りましたが、本格的に正面からリスクを意識して挑戦的に開発に取り組めるチームはマイノリティーです。それだけ、私達はリスクを回避する傾向が強いです。実験の大きさをひとつのスプリント内のサイズに収めれば結果はすぐにわかりますし、仮にうまくいかなくても損失は予測内で限定的です。スクラムのスプリントはリスクマネジメントの仕組みです。ぜひ勇気をもって活用ください。
「プロダクトオーナーは製品の価値を最大化する責任がありますので、低価値の機能の開発に対して「ノー」と言う勇気を示すことができます。」後述しますが、プロダクトオーナーには何を作るかの最終権限があります。それは何を作らないかの判断も含まれます。あれも欲しい、これも欲しい、という顧客のリクエスト、急ぎでこれも、というステークホルダーの指示ともとれるメッセージ、それがプロダクトゴールに対して価値の無いもの、低いものだった場合は、ぜひ勇気を持って拒否権を発動しましょう。
「プレッシャーの中で進捗について透明性を保つには勇気が必要です。」作業が予想より時間がかかってる、実験が思ったような結果を出していない、などはなかなか正直に言いづらいですよね。透明性のために、勇気を持ってシェアするのがベストです。これも後述しますが、スクラムには開発者の障害物に対する積極的なヘルプの仕組みがあります。スクラムマスターの存在です。
「ステークホルダーに未完成の作業を見せないには勇気が必要です。」これは、なかなか面白いですね。透明性のために、未完成のものでも進捗を報告した方が良さそうな気がしますが、ここでは「完成の定義 (Definition of Done)」を優先させます。のちほど説明します。
「助けを求めたり、何かのやり方がわからないことを認めるには勇気が必要です。」後述するデイリースタンドアップで、スクラムマスターはチームに何か障害物がある方、ヘルプが必要な方はいませんか、と聞いたりします。困ったことがあったらスクラムマスターの促しがなくてもぜひ勇気を持ってチームメートにサポートを求めてください。
「チームへのコミットメントを果たさない人に対して、それを指摘し責任を果たすように求めることには勇気が必要です。」他人に注意をするのは誰でも嫌なものですよね。でも、スクラムでは成果に対する全体責任がある以上、チームへのコミットメントを果たさない人に対して注意するのも、責任です。勇気を持って会話してください。
「チームメンバーに異論を唱え、生産的な議論に取り組むには勇気が必要です。」チームダイナミックスとは面白いもので、チームの会話の発言量を計測するとだいたいいつも多く発言する人が固定化される傾向があります。もしあなたがチームの中の「静かな人」のくくりの方に入りがちでしたら、ぜひ勇気を出して発言量を増やしていってください。スクラムはフラットです。あなたの意見は他の方たちと同じウェイトを持ちます。
「顧客が欲しくないものを作ってしまったことに気付いてしまうかもしれません。仮定が間違っていたことを認め、方向を変えるには勇気が必要です。」これは本当に難しい。開発がだいぶ進んで、今更後戻りできないよ、と、とりあえずもうできているからローンチしちゃえ、となってしまうかもしれません。いやー、がんばったけれど売れませんでした、で済ませるか、プロダクトマーケットフィットのずれに気付いた時点で改めて顧客のニーズに則した方向に再度開発をトライするか、本当に勇気が必要です。
同様に「これまでに作ったことのないものを作ろうとすることには勇気が必要です。」これも本当にチャレンジングです。「特にうまくいくかどうかわからない、失敗するかもしれないことをわかりつつやってみる時は、なおさら勇気が必要なものです。」

では、コミットメントについて見ていきましょう。
「スクラムの価値基準で求めるコミットメントは、仕事を納期までに間に合わせる属性のコミットメントではありません。」経営層はアジャイルを誤解して、ただのスピードアップ、効率化手段としてチームに実践を求めることがあります。勇気を持って、アジャイルは、スクラムはそのためにやるのではありませんよ、と誤解を解く努力もコミットメントです。不確実性のある複雑な問題に取り組むためにスクラムをやります。確実に納期を守る、確実性のある属性の仕事にはスクラムではない他の仕事の仕方が適しています。
「私たちはチームの成功にコミットします。」チームの、というところがポイントですね。
「私たちはスクラムをスクラムガイドに基づいて完全に、忠実に実行することにコミットし、簡単な部分を一部だけ選んで実行することを避けます。」一番最初に申し上げた通り、スクラムの一部でも端折るともはやスクラムではありません。スクラムと呼ぶならば、Scrum A to Z、最初から最後までスクラムガイドに則って実践しましょう。
繰り返しになりますが、スクラムだけがアジャイルの実践方法ではありません。今回のスクラム学習を通して学んだ様々のプロセス、ツールを選択して自チームの実情に合わせて独自のアジャイルアプローチを作って試してみるのも、私はありだと思いますし、サポートします。ただ、その場合は、そのチームワークをスクラムとは呼ばないようにしましょう。それがスクラム実践者へのリスペクトです。スクラムをやりたいならば、スクラムと呼びたいならば、最初から最後までスクラムで行きましょう。
「私たちは継続的な改善 (continuous improvement) にコミットし、実験や観察を通じて得られたデータ (empirical data) や新たに出現した情報に基づいて、調整や方向転換を行う勇気を持ちます。」リーンの改善精神と、経験主義、エビデンスベースマネジメントへのコミットメントですね。
「プロダクト開発の複雑さ (complexity) をすべて予測したり制御したりすることはできませんが、フィードバックと学びに基づいて行動を起こし、取り組み方を調整することにコミットできます。」検査と適応、「inspect and adapt」へのコミットメントです。
「私たちは価値 (value) を提供することにコミットします。」逆に言うと、価値の無い物は作らない、というコミットメントでもあります。これはリーンの「無駄」の排除の精神と一緒です。
「プロダクトオーナーは、すべてのステークホルダーの期待に応えることは目標にせず、開発しているプロダクトの価値を最適最大化するための最良の決定を下していくコミットメントを第一にします。」スタートアップのファウンダーが自らプロダクトオーナー役を担うといったケースもありますが、たいていの場合プロダクトオーナーは組織の中でミドルマネージャー的な立場から来ることが多いかと思います。ミドルマネージャーは職務能力として上長はもちろん、その他にたくさんいるステークホルダーの期待に応えてなにかと調整するスキルを持っています。この「調整スキル」はもちろんスクラムのプロダクトオーナーになっても活きますが、時として障害にもなります。ぜひ意識してください：プロダクトオーナーとしてのあなたの役割はステークホルダーをみんなハッピーにすることではありません。最高のプロダクトを作ることが使命です。
「開発者は、「完成の定義 (Definition of Done)」を満たしたもののみをインクリメントとすることにコミットし、例えもうすぐできそうなものでも「完成 (Done)」していないものはデリバーしません。」ひとつ前の「勇気」のところでも「ステークホルダーに未完成の作業を見せないには勇気が必要です。」と述べましたが、同じですね。肝心なのはこの「完成の定義 (Definition of Done)」で、これはクォリティーコントロール、作業の品質管理のためであると同時に、不確実性のあるチャレンジだからこそできるところでは曖昧さを排除して確実性を増す努力をするという、アジャイルの知恵でもあります。
「スクラムマスターは、スクラムフレームワークを守ることでコミットメントを示します。」スクラムと呼ぶ以上は忠実にスクラムをやりましょう。スクラムマスターはその番人ですね。
「プロダクトバックログへのコミットメントは、透明性へのコミットメントです。」「スプリントバックログへのコミットメントは、進捗の透明性へのコミットメントです。」プロダクトバックログ、スプリントバックログの関係性はあとで詳しく学びますが、要は前者がマスターリスト、後者がその一部抜粋で直近次にやる優先事項、という位置づけです。すべての仕事はこの大小ふたつのバックログで管理し、バックログに載っていない仕事はしない、というのがこのバックログの透明性へのコミットメントです。
「デイリースクラムへのコミットメントは、開発者同士がお互いへのコミットメントを示せる機会です。」デイリースクラムは毎日定時定型で開発者が集まることが義務づけられているスクラムのイベントです。これは、スクラムが「デイリー」で、つまり毎日チームワークをすることが前提になっているところから来ています。逆に言うと、毎日チームワークができないのであれば、スクラム以外のアジャイルアプローチを使うべきでしょう。
「スプリントレトロスペクティブへのコミットメントは、チームとしての継続的な改善へのコミットメントです。」「公開 (オープン)」の価値のところでも述べたことの繰り返しですね。スプリントの最後をしっかりとレトロで〆てぜひどんどんチームワークを強化して行ってください。

スクラムの価値基準五つ目、尊敬、リスペクトです。
「人々が潜在的に機知にに富み、クリエイティブで協力して複雑な問題を解決する能力があることを尊重して、私たちは自律型、自己管理型チームに権限を与え、サポートします。」
「人々のモチベーションの拠り所が自主性 (autonomy)、熟達 (mastery)、目的 (purpose) にあることを尊重すると、人々を引き付け、個々の総和以上に素晴らしいことができるチームが生まれる環境を作り出すことができます。」
「すべての意見や視点を尊重することで、誰もが聞く耳を持たれ理解と共感を得られたと感じることができます。そうすると、仮に自分の意見と最終的には異なっても、チーム員全員がチームの決定を支持できるようになります。」「オープン」の価値で述べたことの繰り返しです。自分の意見と、チームの決定尊重、この二律背反を実現できるようになります。
「「スクラムチームは機能横断型 (cross-functional) で、各スプリントで価値を生み出すために必要なすべてのスキルを備えている。」スクラムガイドのこの記述はチーム員全員の経験、スキル、アイデアを尊重し、学びと成長を促します。」スクラムチームには必要なすべてのスキルが備わっている、なかなか挑戦的な記述ですね。これは、最初からなんでも知っている、できることを前提にしているわけではなく、「学び」も重要なスキルととらえて、必要に応じて足りないものはどんどん取り込んで対応して行くことをチーム員に期待していることを表しています。
「スプリントバックログの所有者は開発者です。開発者がスプリントでどれだけの作業ができるか、そしてその作業をどのように行うかを決定することを尊重します。」開発者の自律をサポートする記述です。プロダクトオーナーも、スクラムマスターも、ステークホルダーも、開発者に何をどうやるか指示できません。あくまで、開発者の自主を尊重します。
ちなみにプロダクトバックログの所有者はプロダクトオーナーです。これもプロダクトオーナーの自律へのリスペクトです。
「完成の定義を満たす製品のインクリメントのみをスプリントレビューでレビューすることで、真の進捗の透明性をもたらします。これは、ステークホルダーに対する尊重を示しています。」すでに二度ほど出ている、未完成のものは出さない、見せない、の規律ですね。これがなぜステークホルダーに対する尊重かというと、あやふやな情報を共有することは実はステークホルダーのためにならないという考えに基づきます。
「プロダクトオーナーは、ステークホルダーからの意見を求め、協力し、進捗や目標成果に対し現実的な期待を設定します。これもステークホルダーに対する尊重の一例です。」ステークホルダーマネジメントのちょうど良い塩梅を探るのは、すべてのプロダクトオーナーの普遍的なチャレンジです。後ほど詳しく見ていきましょう。
「スクラムマスターのフォーカスは、スクラムチームの健康状態とスクラムが効果的に使えているかにあります。スクラムマスターが、関係者の学び、ファシリテーション、およびコーチングに特化した役割であることは、チームと人々の成長力に対する期待と尊重を示しています。」スクラムマスターは教育者的役割が期待されている記述ですね。
「スクラムの価値提供に対するフォーカスは、低価値の機能や使用されないかもしれないものに開発費用をかけないことで、組織に対するリスペクトを示しています。スプリントの終わりに使用可能なインクリメントを持つことは、価値を実現するためにさらに投資を強制しないことで、組織に対する尊重を示しています。これにより、組織は投資決定の柔軟性を持つことができます。」最後は組織に対するリスペクトについてです。原文の翻訳がなかなか難しかった部分ですが、要はバリューにフォーカスして無駄なものを作らないのは、組織に投資原資と次の一手に対する柔軟性を残し、組織へのリスペクトを表していますよ、ということです。

お待たせしました。ようやくスクラムのやり方の学びにたどりつきました。
スクラムチーム内の三つの役割、五つのスクラムイベント、三つのスクラム作成物を学んでいきましょう。

「スクラムチームは、1人のプロダクトオーナー、1人のスクラムマスター、開発者で構成されています。スクラムチームは通常10人以下で構成され、サブチームや階層はありません。スクラムチームは機能横断的 (cross-functional) であり、メンバーは各スプリントで価値を生み出すために必要なすべてのスキルを持っています。また、スクラムチームは自己管理し、誰が何をいつどのようにするかを外部の影響を受けずスクラムチーム内で決定します。スクラムチーム全体が毎スプリントで価値のある有用なインクリメントを作成する責任があります。」スクラムチームには三つの役割しかありません。プロダクトオーナー、スクラムマスター、そして開発者です。最大で10名までです。それ以上大きくなってしまうとチームワークの効率が落ちます。ちなみにプロダクトオーナーとスクラムマスターは、それぞれ開発者にもなることができます。
なお、スクラムチーム内には上下関係はありません。プロダクトオーナー、スクラムマスターはマネージャーでも上司でもありません。全員フラットです。
「開発者はスクラムチームのメンバーであり、各スプリントで利用可能なインクリメントのあらゆる側面を、完成の定義 (Definition of Done) に従って品質を確保して作成する責任を持ちます。」プロダクトオーナーの実現して欲しいものを解釈して、開発するのが開発者です。
「プロダクトオーナーは、スクラムチームから生み出されるプロダクトの価値を最大化することの結果に責任を持ちます。」プロダクトオーナーは開発者に実現して欲しいプロダクトの開発を委ねますが、出来上がったプロダクトが価値あるものか、そしてその価値を最大化させることに、最終責任を持ちます。
「スクラムマスターは、スクラムガイドで定義されたスクラムを確⽴させることの結果に責任を持つ。スクラムマスターは、スクラムチームと組織において、スクラムの理論とプラクティスを全員に理解してもらえるよう⽀援することで、その責任を果たす。」
スクラムマスターの位置づけはこのボートのビジュアルで説明するとわかりやすいですね。ボートはスクラムチームそのもので、それにはプロダクトオーナーと開発者とスクラムマスターが乗っています。ボートを漕ぐ力役は開発者、舵取り役はプロダクトオーナー、そしてスクラムマスターは開発者とプロダクトオーナーにスクラム流のボートの漕ぎ方を必要に応じて指導し、ファシリテートします。ビジュアルには太鼓のようなものが見えますが、チームがリズム良く開発できるように時には音頭をとります。
ちなみにスクラムでは、これらの役割がフルタイムである必要性があるか、パートタイムで良いかなどは指定していません。これは意図的です。チームに任せますよ、ということです。

スクラムチームになぜこの三つの役割が必要なのでしょうか？
もし開発者がいなければ、漕ぎ手がいないのでボートはそもそも港を出られません。
もしプロダクトオーナーがいなければ、舵取り役がいないのでボートは迷走するでしょう。
もしスクラムマスターがいなければ、チームに障害が発生した時、いともたやすく座礁するでしょう。
この三役がそろってスクラムチームは完全です。無事ゴールにたどり着ける可能性が高まるでしょう。

スクラムガイドでの開発者の定義です。
「開発者はスクラムチームの⼀員です。各スプリントにおいて、利⽤可能なインクリメントのあらゆる側⾯を作成することを確約します。」復唱になりますが、スクラムではプロダクトを一気に開発するのでは、スプリントごとに少しずつ積み上げるようにプロダクトを作って行くイメージです。この少しずつがインクリメントで、何をどれだけどういう風に作るか、これが「あらゆる側面」の部分ですね、開発者は自律的に決めて作業することができます。
「開発者が必要とする特定のスキルは、幅広く、作業の領域によって異なります。」スクラムチームは機能横断型 (cross-functional) であり、チームの開発者は様々なスキルを持ち寄ります。
「ただし、開発者は常に次の結果に責任を持ちます。」開発者全員が共同に持つ責任ですね。
「スプリントの計画（スプリントバックログ）を作成する。」
「完成の定義を忠実に守ることにより品質を作り込む。」
「スプリントゴールに向けて毎⽇計画を適応させる。」
「専⾨家としてお互いに責任を持つ。」

開発者達の成長、進化の過程のビジュアルです。
組織心理学にタックマンモデルというのがあります。チームは、フォーム、ストーム、ノーム、パフォームというステージを経て形成されるというモデルです。実際にスクラムでもこのパターンが見られ、スクラムマスターは、チームがこのプロセスを効果的に進めるのを助けます。
初めて組成されたスクラムチームは最初はただのグループからスタートし、お互いのことに慣れ、スクラムフレームワークを通じて一緒の働き方を模索します。このフェーズはストーム、混沌とするのが普通で、一時的に生産性が低下します。俗にJカーブ効果と呼ばれる現象ですね。
スクラムのプロセスを信じてこの混沌期を乗り越えると、チームはようやくノーム、落ち着きます。これがベースラインで、ここまで来るのに普通は数スプリントかかりますので忍耐強く頑張りましょう。
さて、ここからいよいよ勝負です。そのまま落ち着いたチームでいるのか、お互い強い信頼関係で結ばれたファミリーのようなチームに成長できるか、楽しみなところです。
最終的には、ウルフパック、オオカミの群れとか特殊エリート部隊などと比喩される高パフォーマンスチームにまで昇り詰めれれば最高です。

スクラムガイドでのプロダクトオーナーの定義です。
「プロダクトオーナーは、スクラムチームから⽣み出されるプロダクトの価値を最大化することの結果に責任を持ちます。」突き詰めると、プロダクトオーナーのフォーカスはとにかく良いプロダクトを作ること、正確に言うと、とにかく良いプロダクトをスクラムチームに作ってもらうこと、です。
「組織・スクラムチーム・個人によって、その方法はさまプロダクトオーナーは、スクラムチームからざまです。」プロダクトオーナーとしての行動、振る舞いに特定の決まりはありません。プロダクトの価値を最大化する、という目標に向かって自由なスタイルで取り組みましょう。
「プロダクトオーナーは、効果的なプロダクトバックログ管理にも責任を持ちます。たとえば、
プロダクトゴールを策定し、明示的に伝える。
プロダクトバックログアイテムを作成し、明確に伝える。
プロダクトバックログアイテムを並び替える。
プロダクトバックログに透明性があり、見える化され、理解されるようにする。」
プロダクトバックログは、プロダクトオーナーのキーツールです。プロダクトオーナーのビジョン、実現したいこと、優先したいこと、すべてプロダクトバックログに常にキャプチャーされていないといけません。プロダクトバックログにすべての情報を集中させることにより、プロダクトオーナーはスクラムチーム内外と透明性を持ってコミュニケーションができます。
「上記の作業は、プロダクトオーナーが行うこともできるが、他の人に委任することもできます。いずれの場合も、最終的な責任はプロダクトオーナーが持ちます。」プロダクトバックログの所有者はプロダクトオーナーでその管理もプロダクトオーナーの責任です。だからといって、プロダクトバックログをプロダクトオーナー以外触れないわけではまったくありません。実践としては、開発者がプロダクトの「何を」「どうやって」作るか一番情報を持っていますので、プロダクトバックログのアップデートに積極的に関わってもらうのが普通です。
「プロダクトオーナーをうまく機能させるには、組織全体でプロダクトオーナーの決定を尊重しなければなりません。」これは特にステークホルダーへの強いメッセージです。この後に来る「プロダクトオーナーは1人の人間であり、委員会ではありません。」と、「ステークホルダーがプロダクトバックログを変更したいときは、プロダクトオーナーを説得する必要があります。」の部分においても、プロダクトの「何を」作るかはプロダクトオーナーの絶対権限であることをスクラムガイドは強く記述しています。
「これらの決定は、プロダクトバックログの内容や並び順、およびスプリントレビューでの検査可能なインクリメントによって見える化されます。」再びコミュニケーションの透明性についてですね。
「プロダクトオーナーは、多くのステークホルダーのニーズをプロダクトバックログで表している場合があります。」プロダクトオーナーは、複数のステークホルダーと対話し、それぞれのニーズを聞き取って何を優先的に開発するか調整を図っているかもしれません。ここに一人の強引なステークホルダーが勝手にプロダクトバックログをいじったらどうなるでしょう？当然他のステークホルダーは影響を受けますよね。こういったこともあるので、「組織全体でプロダクトオーナーの決定を尊重しなければなりません。」となっているわけです。

プロダクトオーナーの成長、進化の過程のビジュアルです。
プロダクトオーナーが、書記 (scribe) のように消極的な立場でいたり、代理人 (proxy) のようにただ単にステークホルダーからの伝言役に留まったりすると、スクラムはうまく機能しません。
少なくも、ビジネス代表者 (business representative) として、顧客やステークホルダーのニーズをしっかりと汲み取って開発者に伝えることができる立場からスタートしましょう。
さらにスクラムチームがより自由に開発できるような環境を提供したり、使い道に比較的自由度のある開発予算を確保したりするスポンサーような立場にプロダクトオーナーがなれると素晴らしいです。
最終的にはプロダクトオーナーがミニCEO、あるいは起業家 (entrepreneur) のように、ステークホルダーから開発の権限を限りなくすべて委譲してもらえるような強い立場にまで昇り詰められれば理想です。

スクラムガイドでのスクラムマスターの定義です。
「スクラムマスターは、スクラムガイドで定義されたスクラムを確⽴させることの結果に責任を持つ。スクラムマスターは、スクラムチームと組織において、スクラムの理論とプラクティスを全員に理解してもらえるよう⽀援することで、その責任を果たす。」
「スクラムマスターは、スクラムチームの有効性に責任を持つ。スクラムマスターは、スクラムチームがスクラムフレームワーク内でプラクティスを改善できるようにすることで、その責任を果たす。」
「スクラムマスターは、スクラムチームと、より⼤きな組織に奉仕する真のリーダーである。」スクラムガイド内ではこの「リーダー」という表現はスクラムマスターのところで一回しか出てきませんが、実践としてはプロダクトオーナーも同様にリーダーと捉えられています。肝心なのはこの「奉仕」という言葉で、いわゆるマネージャーや、指令を出す上役といったリーダーではなく、スクラムマスター、プロダクトオーナーはそれぞれ「サーバントリーダー (servant leader)」と認識されています。
「スクラムマスターは、さまざまな形で、スクラムチーム、プロダクトオーナー、組織を支援します。」スクラムマスターは当然チーム内の開発者とプロダクトオーナーを支援しますが、ここで大事なのは組織も支援する役割があることです。

スクラムチームへの支援は：

「⾃⼰管理型で機能横断型のチームメンバーをコーチする。」
「スクラムチームが完成の定義を満たす価値の⾼いインクリメントの作成に集中できるよう⽀援する。」
「スクラムチームの進捗を妨げる障害物を排除するように働きかける。」
「すべてのスクラムイベントが開催され、ポジティブで⽣産的であり、タイムボックスの制限が守られるようにする。」ことです。
プロダクトオーナへの支援は：
「効果的なプロダクトゴールの定義とプロダクトバックログ管理の⽅法を探すことを⽀援する。」
「明確で簡潔なプロダクトバックログアイテムの必要性についてスクラムチームに理解してもらう。」
「複雑な環境での経験的なプロダクト計画の策定を⽀援する。」
「必要に応じてステークホルダーとのコラボレーションを促進する。」ことです。
組織への支援は：
「組織へのスクラムの導⼊を指導・トレーニング・コーチする。」
「組織においてスクラムの実施⽅法を計画・助⾔する。」
「複雑な作業に対する経験的アプローチを社員やステークホルダーに理解・実施してもらう。」
「ステークホルダーとスクラムチームの間の障壁を取り除く。」ことです。

スクラムマスターの成長、進化の過程のビジュアルです。
はじめてのスクラムマスターはスクラムイベントやスクラムの作成物についていくだけでも大変！最初は事務員 (clerk) のような仕事ぶりにスクラムマスター自身もどかしい思いをするでしょう。
スクラムマスターにだんだん慣れてくると、スクラムチーム員がスクラムのルールをフォローしないことに気づくことが増えてきて、指導力を発揮するようになってくるかもしれません。ここで、手取り足取り正しい行動を細かく指導するだけだと人形遣い (puppet master)、スクラムの精神をリマインドして、集中、公開、勇気、確約、尊敬のバリューに基づいてチーム員に行動の修正を促すまとめ役 (organizer) にステップアップします。
スクラムマスターの経験を積んでいくと、コーチ的立場に役割が少しずつ変わっていき、チームの自己管理力の向上に伴い気が付いたらまとめ役である必要がなくなっているかもしれません。それは、とてもいいことです。
さらにシニアなスクラムマスターになってくると、他のスクラムマスターや、プロダクトオーナー、さらにステークホルダーに対してアドバイザー的な立場でサポートをする機会が増えてくるでしょう。
ベテランになり、エキスパート的な立場になってくると、組織内の様々なチームを指導するより大きなサポートを提供するアジャイルコーチとしての役割が期待されるかもしれません。

次はスクラムの5つのイベント、スプリント、スプリントプランニング、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブです。

実はスプリントそのものもスクラムのイベントです。スクラムガイドのイベントについての最初の記述です：「スプリントは他のすべてのイベントの⼊れ物です。」
続けて「スクラムにおけるそれぞれのイベントは、スクラムの作成物の検査と適応をするための公式の機会です。これらのイベントは必要な透明性を実現するために明確に設計されています。規定通りにイベントを運⽤しなければ、検査と適応の機会が失われます。スクラムにおけるイベントは、規則性を⽣み、スクラムで定義されていない会議の必要性を最⼩限に抑えるために⽤いられます。」
「すべてのイベントは、複雑さを低減するために、同じ時間と場所で開催されることが望ましいです。」
アジャイルはフレキシブルで臨機応変さが売り、というイメージですよね。なのになんでスクラムはこんなにルールでがんじがらめなんでしょう？そう、スクラムはものすごく規律を求められます。
世の多くのクリエーター、アーティストは偏屈なまでのルーチンを保って生きていたケースがたくさんあります。複雑な、今までにないものを作るのに集中したいから、日々の行動はシンプルに、複雑さを取り除いた生き方をしたい、真意はこんなところでしょう。
ルールはあるとしても、それでもスクラムはライトウェイトフレームワークです。スクラムの規律は、最後に最高のプロダクトを実現するためのトレードオフと思えば納得しやすいのではないでしょうか？

スクラムイベントの一つ目、スプリント。
「スプリントはスクラムにおける⼼臓の⿎動であり、スプリントにおいてアイデアが価値に変わります。」スプリントのリズムと、スプリントが価値創造活動の場であることの記述ですね。
「⼀貫性を保つため、スプリントは 1 か⽉以内の決まった⻑さとします。前のスプリントが終わり次第、新しいスプリントが始まります。」スプリントは最長1か月と決まっていて、3か月のスプリントとかになるともはやスクラムではありません。実践としては、1週間から1ヶ月の間でスクラムチームが協議の上スプリント期間を決めます。経験則では2週間のスプリントを採用するチームが多いですね。また、スプリントの期間は「決まった長さ」です。今回は10日、次は15日、そのあとは1週間ごとで回して行こう、というのはスクラムではありません。また、スプリントお疲れ様でした、では1週間休んでまた適当に集まりましょう、というのもスクラムでは無しです。スクラムのスプリントは終わったらすぐに次がはじまる、連続です。
「スプリントプランニング、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブを含む、プロダクトゴールを達成するために必要なすべての作業は、スプリント内で⾏われます。」スクラムの仕事はすべてスプリント内でやりましょうね、ということです。
「スプリントでは、スプリントゴールの達成を危険にさらすような変更はしない。品質を低下させない。」スプリントの至上命題はスプリントゴールの達成ですよ、でも達成すればなんでもいいわけではないので、良い仕事をしましょうね、ということです。
「プロダクトバックログを必要に応じてリファインメントする。学習が進むにつれてスコープが明確化され、プロダクトオーナーとの再交渉が必要になる場合がある。」プロダクトバックログのリファインメントはスプリント中のスクラムチームのタスクに入れて大丈夫です。また、リファインメートを通してプロダクト開発の内容や方法に変更や調整も当然出てくるので、プロダクトオーナーさん、開発者からそういう進言が来ることの心構えをしておいてくださいね、ということです。
「スプリントによって、プロダクトゴールに対する進捗の検査と適応が少なくとも 1 か⽉ごとに確実になり、予測可能性が⾼まります。スプリントの期間が⻑すぎると、スプリントゴールが役に⽴たなくなり、複雑さが増し、リスクが⾼まる可能性があります。スプリントの期間を短くすれば、より多くの学習サイクルを⽣み出し、コストや労⼒のリスクを短い時間枠に収めることができます。スプリントは短いプロジェクトと考えることもできます。」なぜ、短周期のスプリントが良いのか、という説明です。
「進捗の⾒通しを⽴てるために、バーンダウン、バーンアップ、累積フローなど、さまざまなプラクティスが存在します。これらの有⽤性は証明されているが、経験主義の重要性を置き換えるものではありません。複雑な環境下では、何が起きるかわかりません。すでに発⽣したことだけが、将来を⾒据えた意思決定に使⽤できます。」のちほど、スクラム実践知識のところでバーンダウンなどのプラクティスに触れます。一方で、メソッドの罠にはまるとツールやプロセスに一生懸命になりすぎて肝心の中身がおろそかになることが往々にしてあります。経験主義はその中身への集中のリマインダーです。
また、憶測、期待値による意思決定ではなくて、データ、エビデンスの重用も、経験主義です。
最後、「スプリントゴールがもはや役に⽴たなくなった場合、スプリントは中⽌されることになるでしょう。プロダクトオーナーだけがスプリントを中⽌する権限を持ちます。」、大事なポイントです。スプリントはよっぽどのことがなければ止めてはいけません。そのよっぽどのことというのが、スプリントゴールが意味をなさなくなった時、さらにそれを判断できるのはプロダクトオーナーだけ、と要件はかなり厳しめです。

続けて、スプリントプランニング。「スプリントプランニングはスプリントの起点であり、ここではスプリントで実⾏する作業の計画を⽴てます。結果としてできる計画は、スクラムチーム全体の共同作業によって作成されます。プロダクトオーナーは参加者に対して、最も重要なプロダクトバックログアイテムと、それらとプロダクトゴールとの関連性について話し合う準備ができているかを確認します。スクラムチームは、アドバイスをもらうためにチーム以外の⼈をスプリントプランニングに招待してもよいです。」スプリントプランニングには、スクラムチーム全員の参加が必須です。一方で、必要に応じて外部の人も入れて良いことになっています。
「スプリントプランニングは次のトピックに対応します：トピック 1：プロダクトオーナーは、プロダクトの価値と有⽤性を今回のスプリントでどのように⾼めることができるかを提案します。次に、スクラムチーム全体が協⼒して、そのスプリントになぜ価値があるかをステークホルダーに伝えるスプリントゴールを定義します。スプリントゴールは、スプリントプランニングの終了までに確定する必要があります。」流れとしては、プロダクトオーナーがまず壇上に上がり、開発者に「このスプリントでは私はこれが欲しい、なぜならば…」と提案します。それを受け取って、スクラムチーム全員で、プロダクトオーナーの願いを実現するスプリントゴールをドラフトします。このドラフトのゴールはスプリントプランニングをしている間にいろいろ適応して変化するかもしれませんので、スプリントゴールの確定、固定はスプリントプランニングの終わりまでにすればOKです。
「トピック 2：このスプリントで何ができるのか？開発者は、プロダクトオーナーとの話し合いを通じて、プロダクトバックログからアイテムを選択し、今回のスプリントに含めます。スクラムチームは、このプロセスの中でプロダクトバックログアイテムのリファインメントをする場合があります。それによって、チームの理解と⾃信が⾼まります。」次に、スプリントゴールを達成するために必要な作業は何か、プロダクトバックログからプロダクトバックログアイテムを選んで引っ張ってきて、スプリントバックログに落とし込みます。ここで大事なのがプロダクトバックログがリファイン、整理されていることです。スプリントプランニング中にリファインメントをやってもいいですが、ベストプラクティスはスプリント中に定期的に更新作業をして、スプリントプランニングに入る前にプロダクトバックログがすでに最新の状態でリファインされていることが理想です。
「スプリント内でどれくらい完了できるかを選択するのは難しいかもしれません。しかしながら、開発者が過去の⾃分たちのパフォーマンス、今回のキャパシティ、および完成の定義の理解を深めていけば、スプリントの予測に⾃信が持てるようになります。」後ほどスクラム実践知識でカバーする、プロダクトバックログアイテムの見積もり、エスティメーションについての記述です。あとで詳しく説明します。
「トピック 3：選択した作業をどのように成し遂げるのか？開発者は、選択したプロダクトバックログアイテムごとに、完成の定義を満たすインクリメントを作成するために必要な作業を計画します。これは多くの場合、プロダクトバックログアイテムを 1 ⽇以内の⼩さな作業アイテムに分解することによって⾏われます。これをどのように⾏うかは、開発者だけの裁量とします。」プロダクトオーナーは開発者にこういうものを作って欲しいとリクエストできますが、どうやって作るかは指図せず、開発者の裁量に任せなければなりません。
「プロダクトバックログアイテムを価値のインクリメントに変換する⽅法は誰も教えてくれません。」これはスクラムガイドの日本語訳が原文をうまく翻訳できていないところですね。「No one else tells them how to turn Product Backlog items into Increments of value.」Them というのは前文の文脈から開発者のことです。「誰も開発者にプロダクトバックログアイテムを価値のあるインクリメントに変える方法を指図してはいけません。」の方が正しい訳に近いでしょう。
「スプリントゴール、スプリント向けに選択したプロダクトバックログアイテム、およびそれらを提供するための計画をまとめてスプリントバックログと呼びます。」スプリントバックログにはスプリントゴールも含まれていますので、忘れずに。
「スプリントが 1 か⽉の場合、スプリントプランニングのタイムボックスは最⼤で 8 時間です。スプリントの期間が短ければ、スプリントプランニングの時間も短くすることが多いです。」スクラム実践者コミュニティーでは、2週間スプリントではスプリントプランニングは最大4時間、1週間スプリントでは最大2時間、がコンセンサスです。

デイリースクラムについては、のちほどスクラム実践知識のところであらためて触れます。
ここではスクラムガイド上の定義をさらっと見ていきましょう。
「デイリースクラムの⽬的は、計画された今後の作業を調整しながら、スプリントゴールに対する進捗を検査し、必要に応じてスプリントバックログを適応させることです。」
「デイリースクラムは、スクラムチームの開発者のための 15 分のイベントです。複雑さを低減するために、スプリント期間中は毎⽇、同じ時間・場所で開催します。プロダクトオーナーまたはスクラムマスターがスプリントバックログのアイテムに積極的に取り組んでいる場合は、開発者として参加します。」スクラムのルールとして重要なポイントです。デイリースタンドアップは15分以内、毎日定時定型、つまり時間を変えてはいけない、参加者は開発者、つまりプロダクトオーナーとスクラムマスターは参加しなくても良い、ただしプロダクトオーナーとスクラムマスターが開発者でもある場合は参加可、というルールです。
「開発者は、デイリースクラムがスプリントゴールの進捗に焦点をあて、これからの 1 ⽇の作業の実⾏可能な計画を作成する限り、必要な構造とやり⽅を選択できます。これは集中を⽣み出し、⾃⼰管理を促進します。」開発者の自己管理が目標なので、プロダクトオーナーやスクラムマスターがあれやれこれやれと指図してはいけません。
「デイリースクラムは、コミュニケーションを改善し、障害物を特定し、迅速な意思決定を促進します。その結果、他の会議を不要にします。」一日一回15分のミーティングで、その他の無駄な会議に割く時間が大幅に減りますよ、という主張です。
「開発者が計画を調整できるのは、デイリースクラムのときだけではありません。スプリントの残りの作業を適応または再計画することについて、より詳細な議論をするために、開発者は⼀⽇を通じて頻繁に話し合います。」もちろん、デイリースクラム以外でチーム員同士が集まってはいけないということではまったくなくて、一日を通して必要に応じてどんどんコラボしてくださいね、と言っています。

スプリントの最後の日に二つのイベントがあります。そのひとつ目がスプリントレビューです。
「スプリントレビューの⽬的は、スプリントの成果を検査し、今後の適応を決定することです。」
「スクラムチームは、主要なステークホルダーに作業の結果を提⽰し、プロダクトゴールに対する進捗について話し合います。」スプリントレビューの参加者はスクラムチームと、招待されたステークホルダーやその他の関係者です。
「スプリントレビューにおいて、スクラムチームとステークホルダーは、スプリントで何が達成され、⾃分たちの環境で何が変化したかについてレビューします。この情報に基づいて、参加者は次にやるべきことに協⼒して取り組みます。新たな機会に⾒合うようにプロダクトバックログを調整することもあります。」プロダクトバックログはもちろんステークホルダーに見せて良いものです。むしろ積極的にプロダクトバックログを通じてステークホルダーとコミュニケーションをするとなにかと便利です。
「スプリントレビューはワーキングセッションであり、スクラムチームはスプリントレビューをプレゼンテーションだけに限定しないようにします。」ステークホルダーが招かれるので、スプリントレビューは放っておくとただのパワーポイントを使ったプレゼンミーティングで終わりがちです。大事なのは対話、フィードバック、協働です。スプリントレビューをぜひワーキングセッションにしましょう。
「スプリントレビューは、スプリントの最後から 2 番⽬のイベントであり、スプリントが 1 か⽉の場合、タイムボックスは最⼤ 4 時間です。スプリントの期間が短ければ、スプリントレビューの時間も短くすることが多いです。」スクラム実践者コミュニティーでは、2週間スプリントではスプリントレビューは最大2時間、1週間スプリントでは最大1時間、がコンセンサスです。

スプリントの最後のイベント、スプリントレトロスペクティブです。スプリントレビューがスプリントの「What」を振り返るミーティングだとしたら、スプリントレトロスペクティブは「How」の振り返りです。両方ともスクラム実践知識のところであらためて解説しますので、取り急ぎスクラムガイド上での定義です：
「スプリントレトロスペクティブの⽬的は、品質と効果を⾼める⽅法を計画することである。」
「スクラムチームは、個⼈、相互作⽤、プロセス、ツール、完成の定義に関して、今回のスプリントがどのように進んだかを検査する。多くの場合、検査する要素は作業領域によって異なる。」
「スクラムチームを迷わせた仮説があれば特定し、その真因を探求する。スクラムチームは、スプリント中に何がうまくいったか、どのような問題が発⽣したか、そしてそれらの問題がどのように解決されたか（または解決されなかったか）について話し合う。」
「スクラムチームは、⾃分たちの効果を改善するために最も役⽴つ変更を特定する。最も影響の⼤きな改善は、できるだけ早く対処する。次のスプリントのスプリントバックログに追加することもできる。」
「スプリントレトロスペクティブをもってスプリントは終了する。スプリントが 1 か⽉の場合、スプリントレトロスペクティブは最⼤ 3 時間である。スプリントの期間が短ければ、スプリントレトロスペクティブの時間も短くすることが多い。」2週間スプリントではレトロは最大90分、1週間スプリントでは1時間以内に抑えましょう。

さて、スクラムの作成物とその確約、コミットメントについてです。少し難しいコンセプトなので解説します。

スクラムチームが何を作るかというと当然プロダクトですが、複雑な問題を解決する属性のプロダクト開発なので、ウォーターフォール開発や工作のように部品と工程がはっきり見えるような作り方はできません。

一方で、透明性はスクラムの柱なので、プロダクト開発の過程をそれでも可視化したいわけです。そこで、スクラムでは、「作成物」というコンセプトを導入し、プロダクトバックログ＞スプリントバックログ＞インクリメントという流れのイメージでアウトプットを出して行く、見せていく仕組みを作りました。
もちろん、ただなんでもアウトプットすればいいものではありませんよね。価値あるものをアウトプットしてこそ、つまりアウトカム、結果、成果が伴ったものを出して行くことが大事です。アウトプット (output) からアウトカム (outcome) へ、規律を持って品質を保った作成物を出せるように、プロダクトバックログにはプロダクトゴールを、スプリントバックログにはスプリントゴールを、インクリメントには完成の定義 (Definition of Done) をという、可視化された確約 (コミットメント)、条件みたいなものですね、を作成物と対にして導入しています。
詳しく見ていきましょう。

ではスクラムの作成物の一番大きいものから、プロダクトバックログです。
「プロダクトバックログは、創発的かつ順番に並べられた、プロダクトの改善に必要なものの⼀覧です。」創発的 (emergent) というのは、複雑な属性のプロダクト開発である以上、最初からなんでも情報がそろっているわけではない、従って開発が進むにつれてどんどん新しい情報が出てくることをあらかじめ覚悟しておいてくださいね、という趣旨です。「順番に」というのは「ordered」の訳ですが、「整理、優先順位付けされた」という意味もあります。
「これは、スクラムチームが⾏う作業の唯⼀の情報源です。」さらっと書かれていますが、スクラムガイド的にはここはかなり大事な部分です。プロダクトバックログはマスターリストですよ、と。すべての情報をプロダクトバックログに集めてくださいね、というルールです。
次はプロダクトバックログリファインメントについての記述です。「1 スプリント内でスクラムチームが完成できるプロダクトバックログアイテムは、スプリントプランニングのときには選択の準備ができています。」プロダクトバックログアップデートをスプリントプランニングの前に終わらせておきましょう。「スクラムチームは通常、リファインメントの活動を通じて、選択に必要な透明性を獲得します。プロダクトバックログアイテムがより⼩さく詳細になるように、分割および定義をする活動です。これは、説明・並び順・サイズなどの詳細を追加するための継続的な活動です。」通常、継続的、とくどいほどに普段からプロダクトバックログのアップデートとリファインメントをするように習慣を作って欲しい旨主張しています。「多くの場合、属性は作業領域によって異なります。」プロダクトオーナーはプロダクトバックログのアップデート、リファインメントをひとりで抱え込む必要はありません。むしろ、専門的なことが多く出てくることでしょうから、せっかくクロスファンクショナルになっているスクラムチーム員を積極的に巻き込みましょう。
「作業を⾏う開発者は、その作業規模の評価に責任を持ちます。開発者がトレードオフを理解して選択できるように、プロダクトオーナーが開発者を⽀援することもできます。」ここで言う「評価」は、スクラムガイドの原文では「sizing」という文言です。これは直訳すると「大きさ判断」で、のちほどスクラム実践知識のプロダクトバックログアイテムの見積もり、エスティメーションのところで詳しく説明します。ここではエスティメーションは開発者の責任であることを明記しています。ただし「開発者がトレードオフを理解して選択できるように、プロダクトオーナーが開発者を⽀援することもできます。」と、プロダクトオーナーさん、手伝ってあげてくださいね、と言っています。
さて、確約、コミットメントです。プロダクトバックログと対をなすコミットメントはプロダクトゴールです。
「プロダクトゴールは、プロダクトの将来の状態を表しています。」目的、目標、ビジョン、最終到達点ですね。「それがスクラムチームの計画のターゲットになります。」
「プロダクトゴールはプロダクトバックログに含まれます。」プロダクトゴールはプロダクトバックログと一体化されていて、「プロダクトバックログの残りの部分は、プロダクトゴールを達成する「何か（what）」を定義するものです。」と、プロダックバックログアイテムと完全な連続性を保っています。
「プロダクトとは価値を提供する⼿段です。プロダクトは、明確な境界、既知のステークホルダー、明確に定義されたユーザーや顧客を持っています。プロダクトは、サービスや物理的な製品である場合もあれば、より抽象的なものの場合もあります。」ここ、ものすごく重要です。スクラムはソフトウェアプロダクト、ハードウェア商品の開発にとどまらず、サービス商品、あるいは商品として単体で売り出す予定のない、例えば社内サービス、業務フロー、リサーチといった抽象的なものにでも使えます。「価値を提供する⼿段」であり、「明確な境界、既知のステークホルダー、明確に定義されたユーザーや顧客を持って」いれば、なんでもプロダクトと呼んでください。
「プロダクトゴールは、スクラムチームの⻑期的な⽬標です。次の⽬標に移る前に、スクラムチームはひとつの⽬標を達成（または放棄）しなければなりません。」プロダクトゴールは一回決めたら変えてはいけません。固定です。もし変えたかったら、勇気を持ってそのプロダクトゴールを一旦放棄して、スプリントを中止して、再度あらたなプロダクトゴールを設定するところからスクラムをやり直してください。

プロダクトバックログと入れ子構造になっているのがスプリントバックログです。「スプリントバックログは、スプリントゴール（なぜ）、スプリント向けに選択されたいくつかのプロダクトバックログアイテム（何を）、およびインクリメントを届けるための実⾏可能な計画（どのように）で構成されます。」
「スプリントバックログは、開発者による、開発者のための計画です。」プロダクトバックログのオーナーはプロダクトオーナーですが、スプリントバックログのオーナーは開発者全員です。「スプリントバックログには、スプリントゴールを達成するために開発者がスプリントで⾏う作業がリアルタイムに反映されます。その結果、より多くのことを学ぶにつれて、スプリントの期間を通して更新されます。」スプリントバックログの更新責任も開発者にあり、またリアルタイム性が大事です。つまり、スプリント中に毎日どんどん更新される属性のものです。
「スプリントバックログはデイリースクラムで進捗を検査できる程度の詳細さが必要です。」デイリースクラムが「デイリースタンドアップ」とも呼ばれるのは、インオフィス(リモートでない)チームではかんばんボードの前にみんな集まって立ったままやるのが一般的なところから来ています。スプリントバックログとデイリースクラムは切っても切り離せない関係にあります。
「スプリントゴールはスプリントバックログの確約（コミットメント）です。スプリントゴールはスプリントの唯⼀の⽬的です。」乱暴な言い方をすれば、スプリントゴールを達成さえできれば、開発者はなにをやってもいい、ということです。「スプリントゴールは開発者が確約するものですが、スプリントゴールを達成するために必要となる作業に対しては柔軟性をもたらします。」
「スプリントゴールはまた、⼀貫性と集中を⽣み出し、スクラムチームに⼀致団結した作業を促すものです。スプリントゴールは、スプリントプランニングで作成され、スプリントバックログに追加されます。開発者がスプリントで作業するときには、スプリントゴールを念頭に置きます。作業が予想と異なることが判明した場合は、スプリントゴールに影響を与えることがないように、プロダクトオーナーと交渉してスプリントバックログのスコープを調整します。」この最後の一文が大事です。スプリントゴールはスプリントプランニングが終わった時点で、スプリントが終わるまで固定です。予定通り作業が進んでいなくてもゴールポストは動かしてはいけません。例えば商品の新しい操作パネルを作るというのがスプリントゴールだとします。当初はいろいろと調整できる機能を入れる予定でしたが、作業が予定外に難航しました。そこで調整項目を減らして少なくともオンオフボタンと、あとひとつふたつの必須項目だけの操作パネルにスコープを落としていいか、プロダクトオーナーと交渉します。プロダクトオーナーは、当初想定の6割のスコープにはなるが、最低限使える操作パネルはできるので、OKを出します。こうやって、スプリントゴールは変えずにスコープを変えて対応します。

作成物の最後はインクリメントです。直訳では「差分」に相当します。普段使わないコンセプトなので、少し慣れが必要でしょう。
「インクリメントは、プロダクトゴールに向けた具体的な踏み⽯ (stepping stone) です。インクリメントはこれまでのすべてのインクリメントに追加します。」プロダクトゴールを分解して分解して実行可能な計画にしたのがプロダクトバックログです。その分解して分解した構成要素がプロダクトバックログアイテムで、それをスプリントバックログにプル、引っ張ってきてスプリントでの作業に備えます。そしてスプリントでプロダクトバックログアイテムを作業して完了してできた結果が、インクリメントです。このインクリメントの積み重ねがプロダクトをゴールに向けて作ります。
「また、すべてのインクリメントが連携して機能することを保証するために、徹底的に検証する必要があります。価値を提供するには、インクリメントを利⽤可能にしなければなりません。」価値のないものを作っても意味がありません。インクリメントは完成の定義 (Definition of Done) を満たしてはじめて利用可能と宣言してリリースして良いものです。
「スプリントでは、複数のインクリメントを作成可能です。」当たり前のことですが、開発者は複数のプロダクトバックログアイテムを同時並行的に、あるいは漸次スプリントで作業して大丈夫です。
「インクリメントをまとめたものをスプリントレビューで提⽰します。それによって、経験主義がサポートされます。」ステークホルダーとの検証、適応プロセスですね。
「ただし、スプリント終了前にインクリメントをステークホルダーにデリバリーする可能性もあります。スプリントレビューのことを価値をリリースするための関⾨と⾒なすべきではありません。」これまた大事なポイントです。「Continuous Delivery – 継続的デリバリー」のコンセプトです。従来のプロジェクトマネジメント手法のゲートウェイ審査体制は、プロダクト開発の機動性を大幅に低下させます。また、クォリティーコントロール手法としても実はあまり効果的でないケースも多いことが経験主義からわかっています。そこで代わりにみられるようになったプラクティスが Continuous Delivery なわけです。スクラムではこの継続的デリバリーを全面的にサポートします。完成の定義の規律と、リアルタイムでのステークホルダーとのフィードバックループを作ることによって、品質は十分に管理できる、という経験主義の自信です。

スクラム理論の最後にスクラムのルールについて触れましょう。
2020年版のスクラムガイドでは、スクラムのルールについての具体的な記述がなくなりました。しかし、スクラムがルールベースであることには変わりません。少し深堀りしてみましょう。

2017年版のスクラムガイドでは、「スクラムフレームワークは、スクラムチームとその役割・イベント・作成物・ルールで構成されています。それぞれに目的があり、スクラムの成功や利用に欠かせません。」と、スクラムのルールがフレームワークの一部であるとはっきり述べています。「スクラムのルールは、役割・イベント・作成物をまとめ、それらの関係性や相互作用を統括するものです。スクラムのルールについては、スクラムガイド全体で説明します。」と、ルールを定義しています。
一方で、スクラムガイド2020年版では、スクラムガイドの本文の中にルールの表記がなくなりました。これはスクラムがルールベースではなくなったということでしょうか？
いいえ、まったくそういうことではなく、まず、2020年版でもスクラムガイドのタイトルは「スクラム公式ガイド：ゲームのルール」です。
また、2020年版のエンドノートに次の記述があります：「ここで概要を述べたように、スクラムフレームワークは不変(変更不可能)です。（訳注：「不変」というと未来永劫変わらないというイメージがあって、実際スクラムガイドは数年に一度更新されるので、この訳は原文の真意から外れているかもしれません。ここはスクラムのルールは勝手に変えちゃダメですよ、というのが意図なので、翻訳は「変更不可能」とした方が正しいと思います。）スクラムの⼀部だけを導⼊することも可能ですが、それはスクラムとは⾔えません。すべてを備えたものがスクラムであり、その他の技法・⽅法論・プラクティスの⼊れ物として機能するものです。」つまり、スクラムをやるならば、ルール通りにスクラムをやってくださいね、と言っています。ルールから外れてやるのも自由ですが、その場合はスクラムとはもう呼ばないでくださいね、とも言っています。
最後に、2017年版の「スクラムフレームワークを使用する具体的な方法にはさまざまなものがあり、それらについてはスクラムガイドでは触れません。」という表記と、2020年版のスクラムが「その他の技法・⽅法論・プラクティスの⼊れ物として機能するものです。」というくだりの部分についてですが、これは、最初の方のスクラムの定義で出てきた「スクラムフレームワークは意図的に不完全なものであり、スクラムの理論を実現するために必要な部分のみが定義されています」という記述の繰り返しです。スクラムの実践では、”Scrum AND”、スクラムと共に、というコンセプトがあり、これは、スクラムと共に、例えばリーンやデザイン思考などスクラム以外の様々なプロセスやツールを組み合わせて使うことを積極的に推奨するコンセプトです。
コアな部分はスクラムのルールを完全に守ってやってくださいね、と、でもそれ以外の部分は他の良いやり方をどんどんスクラムと組み合わせて使っていいですからね、というのがスクラムのルールの意図です。
これでスクラム理論は終了です。大変でしたね。良く頑張りました！

次に、スクラムの実践アドバイスを差し上げます。
いよいよスクラムをはじめるにあたりイメージしておきたいことや、スクラムガイドに必ずしも定義されていない、必須とされていないけれど、スクラムの実務では知っておきたいツールやコンセプトを紹介します。

まず、スプリントのリズムを意識しましょう。
プロダクトバックログからスタートして、スプリントプランニングをして、毎日のチームワークをはじめます。
スプリント期間中は、毎日定時定型のデイリースクラムを行います。
スプリント最終日には、スプリントレビューを開催して、最後にスプリントレトロスペクティブで締めくくります。
ひとスプリントが終わったら、すぐに次のスプリントに入る、こういったリズムです。
心臓の鼓動、脈拍と一緒で、スプリントは止まりません。スプリントが止まるのはプロダクト開発が終わった時かプロダクトオーナーが放棄を宣言した時だけです。

典型的な二週間のスプリントに落とし込んだスケジュールの例です。
まず、スプリント初日の月曜日はスプリントプランニングです。条件は二つ、(1)プロダクトバックログはリファインされた状態で始めましょう、(2)二週間スプリントの場合はスプリントプランニングは最大4時間以内に収めましょう。スプリントプランニングでプロダクトバックログのアップデート作業をすると時間の無駄です。プロダクトバックログは常日頃からフレッシュにアップデートしておきましょう。その責任はプロダクトオーナーにありますが、当然他のスクラムチーム員にも手伝ってもらいましょう。
スプリントプランニングが終わったら、スクラムチームは毎日の開発作業に入ります。終業時間でない限り、初日の月曜日からもです。
スプリント期間中は開発者は全員、毎日決まった時間にデイリースクラムで集まります。逆に言えば、スプリント中に開発者全員が必須で集まらないといけない毎日のイベントはこのデイリースクラムだけです。それ以外のミーティングは必要に応じてチーム員同士で決めて自由に集まってください。
スプリント最終日に、ステークホルダーなどを招待して、スプリントレビューを開催します。二週間スプリントの場合はスプリントレビューは最大2時間以内に収めましょう。
そしてスプリント最後のイベントはスプリントレトロスペクティブです。参加者はスクラムチーム員のみで、二週間スプリントの場合レトロは90分以内に留めましょう。

こちらのビジュアル二つは、スクラムガイドには載っていないけれど、プロダクトバックログのリファイメントで良く使われる実務ツール、コンセプトの例です。
プロダクトバックログにプロダクトのデザインと開発ステップを「エピック、ストーリー、タスク」と、大中小に階層化して分解、整理、表現するテクニックを、「チャンキング (chunking)」と言います。「このプロダクトはおおまかにこういう属性を持っています」、というエピックレベルの大きな塊、英語で言うチャンク (chunk) からはじめて、「このエピックは主にこういうストーリーで構成され」、と次の大きさの塊に分けて、最後に「そのうちのこちらのストーリーを作るにはこういう一連のタスクをやります」という風にさらに小さな塊に分けて整理、表現します。
チャンキングのメリットは強力です。複雑なプロダクト開発が管理しやすくなる、デザインや作業の優先順位付けがやりやすくなる、この後で説明するエスティメーション、作業の見積もりに有効、チームのコラボレーションとコミュニケーションを促進する、進捗と成果を可視化できる、デザインと作業の細かな適応と調整を図れる、等々やらない理由が見つかりません。さらに開発者のモチベーションにも貢献することを最後に付け加えます。大きなことに取り組み時は小さなことからはじめよう、と誰しもアドバイスを受けたことがありますよね。小さな達成感からはじめてそれを積み重ねて行くと努力が続きやすい経験をみなさん持っていると思います。チャンキングとは要するにそういうことです。
二つ目のビジュアルは、バックログアイテムを「ユーザーストーリー」として表現するテクニックです。プロダクトの機能でも、プロダクトを作る工程でも、「だれが、なにを、なんでやるのか」と、”who, what, why” を明確にして表現します。「ユーザーとして、私はこのプロダクトにこういう機能が欲しい、なぜならば…」、こう表現するとこのプロダクトファンクションを開発する開発者はなにをだれのためになんで作るのかイメージしやすくて、その機能を開発できた暁にはプロダクトマーケットフィット、顧客のニーズを満たす良いものができる可能性が高まりますよね。ユーザーストーリーは、価値の低いもの、無駄なものを作らない、というリーンとアジャイルのスピリットを実現するとても有効な手段です。

次はプロダクトバックログアイテムの見積もり、エスティメーションの実務です。
一般的なプロダクト開発の失敗要因の代表的なものとして、チームのキャパオーバーによる機能不全が良く挙げられます。
スクラムでは、スプリントのタイムボックスを利用して、チームのキャパシティーコントロールをします。
スプリントプランニングで、スプリントの限られた時間の中で達成できるスプリントゴールを、そしてできると見込まれる量の仕事だけを計画をするのはこのためです。
ところが、仕事量の見積もりというのは皆さんも経験がたくさんあると思いますが、本当に難しいものです。
プロダクトバックログアイテムの作業規模の見積もりの精度(つまり、最初の見積もりと実際の作業量を計測して作業が終わった時にその差が小さいこと)を上げていくと、スプリントプランニングの質があがり、スプリントゴールがより達成しやすくなります。
スクラムマスターがプロダクトオーナーと開発者にエスティメーション方法のコーチングに勤しむのは納得ですね。
この作業はMH何日、MH何時間、という風にマンアワー (Man Hour)、つまり作業を開発者がひとりで行ったと仮定した場合の作業時間を表す単位で予測するのが従来型の工数に基づくプロジェクトマネジメント手法です。ところが、人時工数でのマネジメントはリニアなコンセプトで、複雑な属性のプロダクト開発においては実態とそぐいません。
そこで知恵として生まれたのが、作業の難易度(複雑さ)や作業量(大きさ)を相対的に比較する「ストーリーポイント」を利用したエスティメーション、見積もり方法です。
このタスクは経験あるのでちゃちゃっとできそうなので1点、このタスクはちょっと複雑だから3点、一方でこのストーリーは二人がかりでやり方を少し調べないといけない要素もあるから8点、とかこのように時間ではなくて点数で表すと、それぞれの作業アイテムの複雑さや大きさを比較しやすくなります。
さらに、スプリントに慣れてくるとチームで一スプリント当たり総計何ストーリーポイント作業できるか、パターンが見えてきます。この合計ストーリーポイント数がチームのキャパシティーで、当然これをスプリントプランニングで使えます。
なお、ストーリーポイントで1, 2, 3, 5, 8, 13といったフィボナッチ数列を使うのは、エスティメーションを相対的な大きさではっきりと違いが見えるようにする知恵です。例えば、これは7か8か9かとエスティメートしても、違いが微妙すぎてわかりませんよね。これをこれは、5か8か13か、とエスティメーションするとはっきりと違いが見えてくるようになります。
Tシャツサイズを使うのもエスティメーションの実務の知恵です。たくさんあるバックログアイテムをひとつひとつ点数をつけていくのは最初は相対感に悩んで、意外に時間がかかるものです。そこで、まずはざっくりと、S/M/L/XLという大枠の区切りでアイテムを振り分けて、そのあと、それぞれのTシャツサイズの中でさらに相対的にストーリーポイントを割り振るという手順を踏みます。

バーンダウンチャートは、スプリントでのチームの進捗を、ストーリーポイントを利用して可視化するツールです。
スプリント初日にチームで合計100点のストーリーポイントでスタートし、20日後のスプリント終了日にゼロとなるのが目的だとしましょう。そうするとチームとして一日当たり平均5点分のストーリーポイントの消化ペースで作業すればスプリントゴールに達成できるという算段になります。ストーリーポイントの消化はバックログアイテムの完成の定義に基づくことは言わずもがなですね。
スプリントがはじまって当初は一日当たり5点かそれ以上のペースで作業ができていたが、数日したらペースが落ちて4点とか3点の日が出てきましたとしましょう。
これはスクラムチーム、特にスクラムマスターにとって有用な情報です。ペースが落ちているのは何か障害が発生していることにエビデンスでしょう。チームの進捗を妨げる障害を取り除くようにファシリテートするのはスクラムマスターの大事な仕事ですので、バーンダウンチャートは大変助かるツールです。
もうひとつ、ベロシティー(速度)というコンセプトがあります。「このスプリント10では100点分の作業が予定されていたがチームの生産性は高く、キャパシティーがあったのでスプリントゴールがより充実して実現できるプロダクトバックログアイテムをスプリントバックログに引っ張ってきて追加で作業し、結果105点分の作業を完了しました。そこでスプリント11のスプリントプランニングではチームは105点分の作業を計画することにしました。」このケースではベロシティーが100から105に上がりました。スプリントの期間は同じなので、チームの生産性が上がったこと、そして上がり具合がはっきりと指数化されて可視化されています。ベロシティーはこのようにチームの生産性、成長を図る尺度として大変有効です。これもストーリーポイントを使うメリットのひとつですね。

大事な大事な基本ツールなので、かんばんボードについて、また触れたいと思います。
Agile 101 アジャイル基礎講座で一回解説していますが、かんばんボードはスクラムのプロダクトバックログとスプリントバックログのベースのツールで実践に必須です。
スクラム理論に詳しくなった今の時点で、あらたな視点から復習してみましょう。
まず、基本のかんばんから。To Do, WIP, Done の三部構成で、これからやりますよという作業のカードを To Do の欄にならべ、取り掛かり始めた作業は WIP, Work in Progress のカラムに引っ張って、今やっていますよ、と見える化します。リーン用語では WIP は仕掛かかり中とか仕掛品と呼びます。作業が終わったものは、Done、完成コーナーに移動させます。
この一番の基本の3カラム構造のかんばんボードの導入だけでもチームの生産性は飛躍的に向上します。
ここからはさらにいろいろ改良を加えて行くことが可能です。
最たるものとしては、バックログ欄の導入です。思いついたベースのものをその都度 To Do カラムに入れるのではなく、その開発に必要な作業をあらかじめ考え得る限り洗い出してバックログにアウトプットし、プライオリティー付けして上位に来たものから To Do に引っ張って行く、そういう改良です。
スクラムでは、この右端のバックログがプロダクトバックログ、To Do カラムがスプリントバックログに相当します。

私が今まで見てきたいろいろなチームのかんばんボードの改良例をいろいろご紹介します。
まず、プロダクトバックログと To Do カラムを見てみてください。かんばんカードがグループ化されています。カードが一連に並んでるとパッと見どれも同じに見えますよね。そこで、エピック、ストーリー、タスクでグループ化して把握しやすくしてあります。
WIPカラムは作業員ボード化されています。誰がなにをやっているか、誰と一緒にやっているかの単位で現在進行している作業を見やすくしています。こうすると誰かに仕事が集中しているとそれが良く見え、チームとして対処しやすくなります。スクラムマスターも大助かりですね。
新たに Testing という検証ボードが挿入されています。完成の定義は、作業工程が終了しました、というような単純なものばかりではありません。作成したプロダクト機能が動くだけでなく、価値があるものかユーザーテストしてみないといけないかもしれません。また、作業をした人とは別のチーム員が完成の定義テストをして透明性をさらに向上させたいかもしれません。Testing コラムを作るのはこういったメリットがあります。
下の方に、トリアージュ、待機、キャンセルの三つのボックスがあります。これは、急ぎ仕事横やりリクエストを習慣的に持ってくるステークホルダー対策です。トリアージュというのは、病院の救急センターや被災地で傷病人がたくさん発生した際、手当ての緊急度に従って優先順をつけるシステムです。上役のリクエストだから無下に断れない、とついつい仕事を受け付けがちですが、スクラム的には透明性、集中、コミットメントどの観点からも問題ですよね。一方で、時にはその予定外のリクエストもスプリントゴールの達成のために有用な提案かもしれません。そこで考えられたのがこのプロセスです。予定外のリクエストが入ってきたら、プロダクトオーナーと開発者はトリアージュして、やるべきか否かを協議します。やろう、ということになったらその時点でのスクラムチームの残りのキャパシティーをチェックして To Do に追加する余裕があるかチェックします。たいていの場合はキャパシティーが満杯なので、そのままでは追加できないでしょう。なにかを犠牲にしなければいけません。この To Do アイテムはあきらめてやらないことにしよう、ということであればそれをキャンセルの箱に移してキャパシティーを作ります。この To Do アイテムは一旦 To Do から外すが、予定外のリクエストが出来次第もしチームのキャパシティーにまだ余裕があるようだったら後で To Do にもどそう、さもなくばスプリント終了時にプロダクトバックログに戻そう、ということであれば待機の箱に置きます。現在の To Do リストは変えないけれどあとで余裕があったらこの予定外のリクエストもやれるかもしれません、という時もこの待機ボックスは有効です。
スクラムガイドではプロダクトバックログ、スプリントバックログのフォーマットについては一切記述がありません。チームとして一番有効なやり方で自由にクリエイティブに作ってください。

とは言え、はじめてプロダクトバックログを作るときになんらかのガイドがあった方が助かるかと思いますので、指南します。
まずボードにチーム名、プロダクト名、そしてプロダクトゴールを書き出しましょう。

次にやりたいことを全部書き出しましょう。
現時点で考え得る限りのコトだけでOKです。完全である必要性はありません。
小さいことから大きいことまで、あとで並べ直しますので優先度などは気にしなくて大丈夫です。

さて、ここでチャンキングです。エピック、ストーリー、タスク、と、書き出したプロダクトバックログアイテムを、ロシアのマトリョーシカ人形のように入れ子構造にグルーピングしましょう。
完成の定義 (Definition of Done) を書き込みましょう。タスクレベルだけではなく、ストーリー、エピックレベルで完成の定義があるととても良いです。

そしてストーリーポイントで全プロダクトバックログアイテムをエスティメーションをして、最後に開発ステップの優先順位付けをしてプロダクトバックログは完成です。
プロダクトバックログが完成したら、スプリントプランニングで、スプリントバックログにつなげます。

先ほどのプロダクトバックログを左端に丸々持ってきます。プロダクトゴールの記載も忘れずに。
次にスプリントゴールを設定しましょう。
スプリントゴールの達成に必要なプロダクトバックログアイテムをプロダクトバックログから選んで、To Do カラムのスプリントバックログに引っ張ってきます。
選択したプロダクトバックログアイテムがエピックやストーリーレベルの大きいチャンク、塊の場合は、スプリントバックログに引っ張ってくるこ時点でタスクレベルに分解して大丈夫です。タスクの内容を記述する際は、完成の定義 (Definition of Done) もお忘れなく。
ストーリーポイントに基づくキャパシティーコントロールをして、To Do カラムがいっぱいになったらそれ以上プロダクトバックログアイテムをスプリントバックログに追加してはいけません。
いっぱいになったこのスプリントバックログで、スプリントゴールを達成することはできますか？検査の結果できなさそうだったら適応して、バックログアイテムの選択を変えるか、スプリントゴールを再考、調整しましょう。
これでスプリント準備OKです。では、スプリント開始です！

スプリント、スプリントプランニングの実践知識をカバーしましたので、スクラムイベント五つの残り三つ、デイリースクラム、スプリントレビュー、スプリントレトロをおさらいして、本講座は完了です。
デイリースクラム、「毎日、同じ時間、同じ場所、15分以内」です。デイリースタンドアップに柔軟性を持たせてもいいですが、その時点でもうスクラムとは呼ばないようにしましょう。
デイリースクラムの推奨パターン、「報連相」三点共有です。昨日やった仕事の報告、本日やる予定の仕事の連絡、そして障害、問題点、要支援事項などが上がってきましたら、相談リクエストしましょう。
念押しです: スクラムマスター(SM)、プロダクトオーナー(PO)はマネージャー、上司、ボスではありません。デイリースクラムはSMやPOへの報告会ではありません。SMやPOに向かって話すのではなく、チーム員同士に向かって話しましょう。
必要に応じてSMがファシリテート可能ですが、必ずしも毎日取り仕切る必要はありません。参加必須者は開発者だけです。つまり、SMやPOが開発者の一員でない場合は、SMとPOは必ずしもデイリースクラムに出席する必要はありません。むしろ、チームが慣れてきたらぜひ自己管理の原則に任せて開発者だけのデイリースクラムを奨励ください。
デイリースタンドアップの目的はチームワークのシンクロです。ただの朝礼や日時報告会で終わらせないようにしましょう。15分の短い時間にギュッと凝縮した、チームワークに貢献する価値ある情報共有を図りましょう。デイリースクラムはスクラムチームによる、スクラムチームのための毎日のシンクロミーティングです。あくまで、チームワークのためにあるミーティングです。

スプリントレビューは、スプリントの最後に開催する開発成果発表、報告、検証ミーティングです。
スクラムチームが主宰し、顧客、ステークホルダー、その他パートナー等を招待して開催します。スクラムチーム員のみでの内輪のスプリントレビューは本来の目標から外れています。
プロダクトオーナーがスプリントレビューをファシリテートします。
開発者は、スプリントで開発した項目のうち、「完成の定義 (Definition of Done)」を満たしたものを、参加者に発表、デモンストレーションします。完成の定義を満たしていない開発項目(WIP項目)の発表は避けます。参加者に作りかけのものを検証してもらっても意味がないためです。
大事なのは、参加者からフィードバックをもらうことです。フィードバックに基づき、次のスプリントを現状想定している計画のまま進めるか、修正を入れるか、あるいは開発を中止するか、大事な判断が次に待っています。スプリントレビューは検証の場です。

スプリントレビューが「What, 何を開発したか」を共有、振り返りするミーティングだとしたら、スプリントレトロスペクティブは「How, どうやって開発したか」、つまりチームワークの振り返りをするミーティングです。
スクラムチームのみが参加します。外部オブザーバーは参加不可です。スクラムマスターがファシリテートします。
チームワーク、開発手法、アプローチが、うまく行っていてもっとやるべき点、うまく行っていなくてやめるべき点、新しく試してみたいことを議論するやり方が一例です。レトロはその他いろいろなやり方がありますので、自由に試してみてください。
レトロの最後までに必ずひとつ、チームとして改善をコミットするアクションを決めてください。このアクションは次のスプリントプランニングでスプリントバックログに入れて、確実に取り組めるようにします。もちろん、このチームワーク向上アイテムにも、完成の定義の設定と次のスプリントレビューでの検証も忘れないようにしましょう。

良くがんばってくれました！以上を持ちまして、Scrum A to Z、スクラム導入講座を修了します。
スクラム理論と、スクラムをはじめるにあたって最低限必要な実践知識を学んでいただきました。
ここからはやってみるのみ！さっそくスクラムを試してみてください。応援しています。

修了クイズ: 30問

If this resonated

Mental models are a curious kind of tool, fast and slow at once. They are useful in the instant, yet they also quietly open a space to reflect. That's why learning through mental models tends to stick. If you would like more like this, here are some ways to stay connected.
Subscribe for Updates

Joining the Mental Model Dōjō learning community is free. Agile Organization Development, managed by Lifecycle Pte. Ltd., is committed to protecting and respecting your privacy, and we’ll only use your personal information to administer your account and to provide the products and services you requested from us. From time to time, we would like to contact you about our products and services, as well as other content that may be of interest to you. You may unsubscribe from these communications at any time. For more information on how to unsubscribe, our privacy practices, and how we are committed to protecting and respecting your privacy, please review our Privacy Policy. By clicking submit, you consent to allow Lifecycle Pte. Ltd. to store and process the personal information submitted.
Join Our Next Dōjō Session

Come learn in the open. Coach Takeshi shares what he is picking up from live client work, and tests new mental models with the community. Check the next session and reserve your spot.
Follow Us

　　　　M

Drop Us a Note