ポスト
目次
via pixabay.com
【はじめに】
前々回（ https://base.terrasky.co.jp/articles/py78i ）、および前回（https://base.terrasky.co.jp/articles/jVNHn ）は、「Agile」の歴史についてのふりかえりとScrum（以下スクラム）の基礎的な内容を解説しました。今回は前回のブログでは触れられなかったスクラムの内容について、もう少し踏み込んで解説をしたいと思います。また、スクラムを実際に現場で実践しようとする時に役に立つコツやプラクティスについて、偉大な先人達から学んだり教わったりしたことや、私自身の現場経験も踏まえて解説したいと思います。
そして、前回のブログで投げかけた「１．スクラムにおいてスプリントレトロスペクティブ（ふりかえり）のイベントはなぜ外せない一番重要なイベントなのか？」「２．スクラムマスターがプロダクトオーナー（以下、PO）と話し合って、プロジェクトを進めるのでなければ、一体誰が責任をもってプロジェクトを進めるのか？」「３．スクラムを実践する上で行われている具体的なプラクティスについて」「４．スクラムにおける『完成の定義』とは？」についても、織り交ぜて解説したいと思います。
そして、前回のブログで投げかけた「１．スクラムにおいてスプリントレトロスペクティブ（ふりかえり）のイベントはなぜ外せない一番重要なイベントなのか？」「２．スクラムマスターがプロダクトオーナー（以下、PO）と話し合って、プロジェクトを進めるのでなければ、一体誰が責任をもってプロジェクトを進めるのか？」「３．スクラムを実践する上で行われている具体的なプラクティスについて」「４．スクラムにおける『完成の定義』とは？」についても、織り交ぜて解説したいと思います。
【5つのイベント】
今回はスクラムイベントから解説したいと思います（以下、1週間単位で回していく時のサンプルです）。
【スプリント】
こちらは前回のブログで、「ポイントは決まった長さである入れ物（時間の単位）」と紹介していました。スクラムガイドでは「タイムボックス」という表現が特に説明もなくさらっと登場していますが、文字通り「時間の」「箱」ということになります。因みに他のアジャイルな開発手法でも同じような考え方をしているものはあります（eXtreme Programming における「イテレーション」等）。スクラムの場合はこの「スプリント」を基本・基準として、一定のリズムを刻みながらゴールに向かって進むことになります（カチっとした「箱」を積み上げながら、ゴールに向かって近づいていく感じです）。
では、何故一定のリズムが重要なのでしょうか？
それは、スクラムで解決しようとしている課題・問題が大きく関係します。仮にその対象が「明確」で、かつ「動かない」ゴール（＝解決したい課題・問題）であれば、そこに至るまでの計画は立てやすく、またマイルストーンも必ずしも一定期間で置く必要はないでしょう。例えば内部の作業の都合や、他者・他社との作業合流のタイミングのような外部要因も加味しながら、キリの良いタイミングでマイルストーン置くことも可能です。
一方で「不明確」で「時間と共にその場所が変わってしまう」ゴールの場合はどうでしょう？マイルストーンの設定自体が難しく、仮に置いたとしても「そもそもそれはマイルストーンたりえるもの（場所・タイミング）なのか？」ということにならないでしょうか？そこで、スクラムでは「（コントロール不能な）ゴールを目指すのなら、（コントロール可能な）自分たちの方に尺度・基準を持ってくる」という考え方をしています。もう少し説明すると「大体ゴールはあの辺にある（と思う）。今まではこれくらいのペースでここまで進んでこれた。だから、後どれくらいでゴールに到達できそうだ」という考え方で見積もって、計画を立てるという考え方です。そのために必要なことが、「スプリントの期間を固定することで、自分たちのペース・スピードを把握する」ということになります。
もし逆にスプリント期間が固定されておらず、毎回期間が変わってしまったらどうなるでしょう？今まで進んできたペースがわからなくなってしまいます。その状態で曖昧なゴールに向かって進もうとすると、見積りや計画も立てられない状態で闇雲に進む状態＝行き当たりばったりで進むことになってしまいます。
では、何故一定のリズムが重要なのでしょうか？
それは、スクラムで解決しようとしている課題・問題が大きく関係します。仮にその対象が「明確」で、かつ「動かない」ゴール（＝解決したい課題・問題）であれば、そこに至るまでの計画は立てやすく、またマイルストーンも必ずしも一定期間で置く必要はないでしょう。例えば内部の作業の都合や、他者・他社との作業合流のタイミングのような外部要因も加味しながら、キリの良いタイミングでマイルストーン置くことも可能です。
一方で「不明確」で「時間と共にその場所が変わってしまう」ゴールの場合はどうでしょう？マイルストーンの設定自体が難しく、仮に置いたとしても「そもそもそれはマイルストーンたりえるもの（場所・タイミング）なのか？」ということにならないでしょうか？そこで、スクラムでは「（コントロール不能な）ゴールを目指すのなら、（コントロール可能な）自分たちの方に尺度・基準を持ってくる」という考え方をしています。もう少し説明すると「大体ゴールはあの辺にある（と思う）。今まではこれくらいのペースでここまで進んでこれた。だから、後どれくらいでゴールに到達できそうだ」という考え方で見積もって、計画を立てるという考え方です。そのために必要なことが、「スプリントの期間を固定することで、自分たちのペース・スピードを把握する」ということになります。
もし逆にスプリント期間が固定されておらず、毎回期間が変わってしまったらどうなるでしょう？今まで進んできたペースがわからなくなってしまいます。その状態で曖昧なゴールに向かって進もうとすると、見積りや計画も立てられない状態で闇雲に進む状態＝行き当たりばったりで進むことになってしまいます。
と、ここまで書くとそろそろ「ベロシティ」の話が出てくるのではないか？と気づかれる方もいるかもしれません。はい、その通りです。スクラムを進めていくために、一定のリズムを刻むのはベロシティを測るためのキモになります。「ベロシティ」という単語は、「そのチームがゴールに向かってどれくらいの速度で進めるか（進んでいるか）」を測るための尺度を意味します（「ベロシティ」について書き始めるとまた脱線してしまうので、今回はこちらのブログを紹介しておきます。
ベロシティを生産性と言ってはいけない理由 – プロダクトマネジメントの要諦 The Rules of the Game of Product Management
アジャイル界隈では言い古された感がありますが、ベロシティを生産性と言ってはいけないおはなしです。 ベロシティと…
まとめると、「スプリント」は「曖昧なゴールに向かって着実に進むために必要な一定のリズムを刻む考え方」ということになります。
【スプリントの実践ポイント】
その１．スプリント期間はどれくらいの長さがよい？
では、具体的なスプリントの期間はどれくらいにすればよいのか？という疑問が出たかもしれません。スクラムガイドでは「スプリントは 1 か月以内の決まった長さとする」と規定されていますが、プロダクト（ゴール）の内容や、チームの習熟度、技術的・環境的要素等いくつもの変数があるため、正直なところ、時と場合によります（「It depens.」というヤツです）。ただ、個人的には不安があるのならまずは2週間で始めてみてはどうかと思います（先に掲示した図は後の説明のこともあり1週間になっていますが）。そして数スプリント試してみてそのチーム・状況にどうしても合わないと思ったら、思い切って短く（ないしは長く）するのも手だと思います。
誤解のないように補足しておくと、初めに決めたスプリント期間は変更しないのが原則です。ですので、2スプリントやってみて余裕があったから3スプリント目から1週間に短縮して、うまくいかなかったから4スプリント目から2週間に戻して、、、という感じでコロコロとスプリント期間を変えるのはNGです。そしてもっと良くないなのは、「次のスプリントはやることが多そうだからスプリント期間を倍にしよう」という、「やること（スコープ）に合わせて、スプリント期間をその都度変更してしまおう」という方向に進むことです。これは要注意です（そんなことをしていると、いつまでたってもベロシティが計測できません。結果として見積り・計画もできない状態が続き、スクラムによる開発ではなく単なる「行き当たりばったり開発」になってしまいます）。
誤解のないように補足しておくと、初めに決めたスプリント期間は変更しないのが原則です。ですので、2スプリントやってみて余裕があったから3スプリント目から1週間に短縮して、うまくいかなかったから4スプリント目から2週間に戻して、、、という感じでコロコロとスプリント期間を変えるのはNGです。そしてもっと良くないなのは、「次のスプリントはやることが多そうだからスプリント期間を倍にしよう」という、「やること（スコープ）に合わせて、スプリント期間をその都度変更してしまおう」という方向に進むことです。これは要注意です（そんなことをしていると、いつまでたってもベロシティが計測できません。結果として見積り・計画もできない状態が続き、スクラムによる開発ではなく単なる「行き当たりばったり開発」になってしまいます）。
その２．スプリントの開始はいつにすればよい？
スプリントを始めるタイミング（曜日）はいつがよいかという話があります。経験上、週半ばに設定しておく方がよいのではないかと考えています。週初めの月曜をスプリントの開始にして、金曜をスプリントの終わりにしたいという気持ちはわかるのですが、日本の場合、祝日法の関係で、結構月曜が祝日で休みになることが多いので、「今回のスプリントは月曜が祝日だから、イベントを火曜に変更して・・・」といった余計な調整事が増えるという理由が1点目です（会議室を使う場合に、一般的なカレンダーや予約機能で対応している「定期的に予約する」という機能が非常に使いづらい、というか使えない）。
2点目は後述する「スプリントレビュー」や「スプリントレトロスペクティブ（ふりかえり）」のイベントが金曜に行われると、土日を挟んで「はて、先週のふりかえりで決めたことって何だったけ？」という状態になる場合があるというのが理由です（そんなのは筆者だけだ、というツッコミがあるかもしれませんが・・・）。
2点目は後述する「スプリントレビュー」や「スプリントレトロスペクティブ（ふりかえり）」のイベントが金曜に行われると、土日を挟んで「はて、先週のふりかえりで決めたことって何だったけ？」という状態になる場合があるというのが理由です（そんなのは筆者だけだ、というツッコミがあるかもしれませんが・・・）。
その３．スクラムイベントを同日に実施してもよい？
最後にもう一つ、後述するスクラムのスプリントの開始時と終了時のイベント（「スプリントプランニング」「スプリントレビュー」「スプリントレトロスペクティブ（ふりかえり）」）を同日にやってしまうという考え方もアリです。外部からアジャイルコーチを招聘しているようなチームだと、イベントを2日に分けると両日に来てもらうための調整が必要になったりしますが、その手間も減ります。また、「鉄は熱いうちに打て」の格言の通り、イベントを同日にやってしまった方が「そのスプリントで学んだことを次のスプリントにつなげやすくなる」という効果も期待できます。
【スプリントプランニング】
スプリントの初めにスクラムチーム（＋状況によってはその他の関係者）が集まって行われるイベントです。スクラムガイドではスプリント期間が1か月の場合、スプリントプランニングにかけられる時間は8時間が最大と定義されています（そのためスプリント期間が1週間なら、最大2時間ということになります）。
スクラムに取り組むのが初めてのチームの場合、時間がオーバーしがちになるのですが、それはある程度仕方がないと思います。ちょっと前に「タイムボックスが重要」と書いておきながら前言を翻すようで申し訳ないのですが、これに関しては時間がオーバーしてもやりきるべきです。なぜならスプリントプランニングが中途半端になってしまうと、「スプリントの途中で何をやったらよいかよくわからなくなって、結果としてスプリントゴールが達成できませんでした」となりかねないからです。ただ、数スプリント回してみて、それでも時間オーバーすることが続くようなら、「スプリントレトロスペクティブ（ふりかえり）」が不完全なのか、スプリントプランニングでやろうとしていることが多すぎるのか、いずれにせよ何らかの問題がありそうです（個人的には「頑張れ、スクラムマスター」と言いたいかな、と）。
また、最新のスクラムガイドでは「スプリントプランニングでは3つのトピックについて対応する」と記述されています。トピックの一つ目に「このスプリントはなぜ価値があるのか？」が追加され、「Why？」について考えること・共有することがキモになっています。
スクラムに取り組むのが初めてのチームの場合、時間がオーバーしがちになるのですが、それはある程度仕方がないと思います。ちょっと前に「タイムボックスが重要」と書いておきながら前言を翻すようで申し訳ないのですが、これに関しては時間がオーバーしてもやりきるべきです。なぜならスプリントプランニングが中途半端になってしまうと、「スプリントの途中で何をやったらよいかよくわからなくなって、結果としてスプリントゴールが達成できませんでした」となりかねないからです。ただ、数スプリント回してみて、それでも時間オーバーすることが続くようなら、「スプリントレトロスペクティブ（ふりかえり）」が不完全なのか、スプリントプランニングでやろうとしていることが多すぎるのか、いずれにせよ何らかの問題がありそうです（個人的には「頑張れ、スクラムマスター」と言いたいかな、と）。
また、最新のスクラムガイドでは「スプリントプランニングでは3つのトピックについて対応する」と記述されています。トピックの一つ目に「このスプリントはなぜ価値があるのか？」が追加され、「Why？」について考えること・共有することがキモになっています。
トピック 1：このスプリントはなぜ価値があるのか？
トピック 2：このスプリントで何ができるのか？
トピック 3：選択した作業をどのように成し遂げるのか？
まとめると、「スプリントプランニング」は「そのスプリントのスプリントゴールをどうやれば実現できるかについて、スクラムチーム内で話し合って詳細に計画する場」ということになります。
【スプリントプランニングの実践ポイント】
その１．実際はどんな感じで進めるの？
では、実際の現場ではどうすればよいかという話ですが、筆者が現場で経験・コーチしたスプリントプランニングでは、大きく2つのフェーズに分けて進めていました。その時は簡単に前半戦、後半戦と呼んでいましたが、前半戦ではPOからプロダクトバックログに載せられているプロダクトバックログアイテム（P.B.I.・・・いわゆる実現したい要件、機能）の説明が行われます（プロダクトバックログの説明は次回のブログで）。以前のスクラムガイドでは前述の「トピック 1」は明確に項目化されていなかったのですが、自分が経験した現場の場合、思い返すと結果的には「トピック 1」と「トピック 2」について、この前半戦で説明していました。開発者はその内容について適宜質問を行いPOが要望しているP.B.I.に対して、それぞれ見積を行うことになります。
見積については幾つかの見積方法がありますが、「プランニングポーカー」という方法がメジャーなプラクティスです（というのが個人の感想です）。詳細な実施方法については、他のブログや書籍などに譲るとして重要なポイントを1つだけ紹介させていただきます。
「見積をした結果も重要だが、それ以上にその過程が重要」
POの説明を受けて、開発者がその実現にどれくらいかかりそうかを見積もっていくわけですが、その際に行われる会話が非常に重要です。開発者側から質問が行われることで、その対象（別の言い方をすると「ドメイン＝問題領域」）に対して、より開発者の理解が進みます。また、PO側も同様に開発者側からの質問で、より深掘りした検討や仮設構築を行うことにつながります。合わせて、POと開発者間の認識齟齬や理解不足等を「あぶり出す」ことができます。
また、開発者同士の間でも見積に極端な差が出た場合、例えば「その機能はライブラリがあるから簡単に実装できる」という開発者Aと「いや、以前そのライブラリを使った時パフォーマンスに問題があって、作り直す羽目になった」という開発者Bとの会話で、認識齟齬の解消や、ノウハウの共有が行われるという効果もあります。そしてそれを聞いていたPOが「では、その機能はそこまでかけてやる価値はないから、先にこっちの機能を進めてほしい」という感じで臨機応変に計画を変更・修正することが可能になります。
スクラムマスターはこの辺りを意識して、会話を引き出すようにファシリテートしてほしいものです。逆に、もしPOから「この機能とこの機能は必須だから、このスプリント内で絶対に完成させてくれ」という感じのプレッシャーがかけられて、開発者が「じゃ、（本当は見積を5ポイントで出したいけど）2ポイントで・・・」というようなプランニングになっていたとしたら、、、スクラムガイドの5つの価値基準を思い出しつつ、頑張れ、スクラムマスター！
見積については幾つかの見積方法がありますが、「プランニングポーカー」という方法がメジャーなプラクティスです（というのが個人の感想です）。詳細な実施方法については、他のブログや書籍などに譲るとして重要なポイントを1つだけ紹介させていただきます。
「見積をした結果も重要だが、それ以上にその過程が重要」
POの説明を受けて、開発者がその実現にどれくらいかかりそうかを見積もっていくわけですが、その際に行われる会話が非常に重要です。開発者側から質問が行われることで、その対象（別の言い方をすると「ドメイン＝問題領域」）に対して、より開発者の理解が進みます。また、PO側も同様に開発者側からの質問で、より深掘りした検討や仮設構築を行うことにつながります。合わせて、POと開発者間の認識齟齬や理解不足等を「あぶり出す」ことができます。
また、開発者同士の間でも見積に極端な差が出た場合、例えば「その機能はライブラリがあるから簡単に実装できる」という開発者Aと「いや、以前そのライブラリを使った時パフォーマンスに問題があって、作り直す羽目になった」という開発者Bとの会話で、認識齟齬の解消や、ノウハウの共有が行われるという効果もあります。そしてそれを聞いていたPOが「では、その機能はそこまでかけてやる価値はないから、先にこっちの機能を進めてほしい」という感じで臨機応変に計画を変更・修正することが可能になります。
スクラムマスターはこの辺りを意識して、会話を引き出すようにファシリテートしてほしいものです。逆に、もしPOから「この機能とこの機能は必須だから、このスプリント内で絶対に完成させてくれ」という感じのプレッシャーがかけられて、開発者が「じゃ、（本当は見積を5ポイントで出したいけど）2ポイントで・・・」というようなプランニングになっていたとしたら、、、スクラムガイドの5つの価値基準を思い出しつつ、頑張れ、スクラムマスター！
その２．昨日の天気で見積もりするってどういう意味？
大前提として、スクラムで進めていく必要があるプロジェクト、スクラムを採用しようとするプロジェクトは複雑で予測が難しいものになります（そもそも正確な予測ができるタイプのプロジェクトなら、筆者ならWaterfall型の開発の方をおすすめします）。
そのため、「今までどれくらいのスピードで進んでこれたか」を参考にして次の見積・計画の材料にするわけですが、その時の材料が「昨日の天気」ということになります。「夜、月に雲がかかってぼんやりとしていたら、翌日雨が降ることが多かった。今晩の月もぼんやりしてるから、明日は雨になるんじゃないか」という感じです。
ですので、（そのドメインや技術に対して経験の蓄積が浅い）プロジェクトの開始当初の見積は精度が低くなってしまいますが、スプリントを重ねる度に高くしていく・高くなっていくのがスクラムの良いところです（2024年初頭の現在、スクラムの業界界隈ではさらに話が進んで「見積なんていらない」といった話も出ているそうですが、まだ不勉強なので今回はご紹介できず、、、いずれ機会があればご紹介したいと思います）
そのため、「今までどれくらいのスピードで進んでこれたか」を参考にして次の見積・計画の材料にするわけですが、その時の材料が「昨日の天気」ということになります。「夜、月に雲がかかってぼんやりとしていたら、翌日雨が降ることが多かった。今晩の月もぼんやりしてるから、明日は雨になるんじゃないか」という感じです。
ですので、（そのドメインや技術に対して経験の蓄積が浅い）プロジェクトの開始当初の見積は精度が低くなってしまいますが、スプリントを重ねる度に高くしていく・高くなっていくのがスクラムの良いところです（2024年初頭の現在、スクラムの業界界隈ではさらに話が進んで「見積なんていらない」といった話も出ているそうですが、まだ不勉強なので今回はご紹介できず、、、いずれ機会があればご紹介したいと思います）
× × ×
余談ですがSalesforceの場合、そもそも「なるべく開発（＝Visualfoceでの画面の作り込みや、Apexでのビジネスロジックの作り込み）はしないようにして、AppExchangeで提供されているようなアプリの導入や、標準機能を活用しましょう」というのが基本的な考え方なので、言語を利用したいわゆる通常のシステム開発よりも見積がしやすい（ハズ）です。
逆に言うとSalesforceで下手に「開発」しようとすると、折角Salesforceが提供してくれている利点・うま味を活かすことができなくなり、開発時点の見積や設計、本番リリース後の運用や拡張性にまで悪影響が残ってしまうという大きなマイナスを背負ってしまうことになりかねません（もちろん、お客様の要望・要件を実現するために「開発せざるを得ない」状況はあるのですが、Salesforceのプラットフォームを採用するメリットを捨てて、デメリットを許容できるかをしっかりと検討して、お客様にも合意を取ってから進めた方が良いでしょう）
余談ですがSalesforceの場合、そもそも「なるべく開発（＝Visualfoceでの画面の作り込みや、Apexでのビジネスロジックの作り込み）はしないようにして、AppExchangeで提供されているようなアプリの導入や、標準機能を活用しましょう」というのが基本的な考え方なので、言語を利用したいわゆる通常のシステム開発よりも見積がしやすい（ハズ）です。
逆に言うとSalesforceで下手に「開発」しようとすると、折角Salesforceが提供してくれている利点・うま味を活かすことができなくなり、開発時点の見積や設計、本番リリース後の運用や拡張性にまで悪影響が残ってしまうという大きなマイナスを背負ってしまうことになりかねません（もちろん、お客様の要望・要件を実現するために「開発せざるを得ない」状況はあるのですが、Salesforceのプラットフォームを採用するメリットを捨てて、デメリットを許容できるかをしっかりと検討して、お客様にも合意を取ってから進めた方が良いでしょう）
その３．後半戦はどんな感じですすめるの？
前半戦で「今回のスプリントではどのP.B.Iを進めるのか（Why及びWhat）」について決めた後、後半戦ではそれらのP.B.Iを「どのように進めるのか（How）」を計画していきます。その際のコツとしては、「具体的に、適切な大きさに」分解していく、という点が挙げられます。
ただ、これも時と場合によりますが、例えばスプリント期間が1週間の場合、筆者なら最大でも作業にかかる想定時間は半日程度の大きさにまで分解することをおすすめします。できれば、1時間～2時間くらいまで分解しておくのが良いかと思います。そのレベルまで分解することで、各P.B.I.に対する具体的な作業イメージを固めてチーム内で共有し、極端な話をすれば誰がやっても同じ結果になる・できるように持っていく感じです。そうして、分解した結果を集計した結果、前半戦で見積もっていた大きさから大きくズレてしまっていることがわかれば、そこで改めてPOも交えてスコープの調整をすることになります（前半戦で想定していた見積よりもオーバーしていたら、スコープを削ることについて話し合い、逆に見積よりも少ない工数でできそうであれば、P.B.I.の追加を検討することになります）。
ただ、これも時と場合によりますが、例えばスプリント期間が1週間の場合、筆者なら最大でも作業にかかる想定時間は半日程度の大きさにまで分解することをおすすめします。できれば、1時間～2時間くらいまで分解しておくのが良いかと思います。そのレベルまで分解することで、各P.B.I.に対する具体的な作業イメージを固めてチーム内で共有し、極端な話をすれば誰がやっても同じ結果になる・できるように持っていく感じです。そうして、分解した結果を集計した結果、前半戦で見積もっていた大きさから大きくズレてしまっていることがわかれば、そこで改めてPOも交えてスコープの調整をすることになります（前半戦で想定していた見積よりもオーバーしていたら、スコープを削ることについて話し合い、逆に見積よりも少ない工数でできそうであれば、P.B.I.の追加を検討することになります）。
【デイリースクラム】
いわゆる「朝会」です。こちらはスプリント期間に関わらず、最大で「15分」と決まっています。実施方法として「スタンダップミーティング」という文字通りホワイトボード等の前にチーム全員が集まって、立ったままMTGを行うというプラクティスが有名です。これは、「15分」というタイムボックスを守りやすくする、という効果があります（座っているとついついダラダラと話をしてしまうかもしれませんが、「立って」やることによってそれを身体的・心理的に防止しよう、という感じです。最近のリモート作業の場合ではそれぞれの作業場所で座ったままモニタの前でやっていることが多いと思いますが）。ついつい脱線してしまうかもしれませんが、15分という時間で収まりきれないような課題や相談事はデイリースクラムが終わってから必要な関係者を集めて別の会議で話を行うよう、ファシリテートするのが肝心です。
以前のスクラムガイドでは開発チームメンバーが「前回のデイリースクラムから行ったこと」「次回のデイリースクラムまでに行うこと」「問題点について説明する」という内容が明記されていたのですが、最新のスクラムガイドではそれらの記述はなくなりました（この辺りの話は以下の動画で、Jeff 氏が説明していますが、「日本の場合は特にスプリントゴールを意識することなく形式的に質問をしているチームがある」というケースがあったため、あえて具体的な質問例を除外して、議論すべきトピックを明示するようにしたそうです）
以前のスクラムガイドでは開発チームメンバーが「前回のデイリースクラムから行ったこと」「次回のデイリースクラムまでに行うこと」「問題点について説明する」という内容が明記されていたのですが、最新のスクラムガイドではそれらの記述はなくなりました（この辺りの話は以下の動画で、Jeff 氏が説明していますが、「日本の場合は特にスプリントゴールを意識することなく形式的に質問をしているチームがある」というケースがあったため、あえて具体的な質問例を除外して、議論すべきトピックを明示するようにしたそうです）
スクラムガイド2020 Jeff Sutherland博士解説ビデオ
via
www.youtube.com
以下に、もう少し詳細に説明しますが「デイリースクラム」は「そのスプリントのスプリントゴールを実現するために、必要に応じて再計画・調整を行う場」ということになります。
【デイリースクラムの実践ポイント】
前回のブログでも少し触れましたが、スクラムにおける「朝会」はいわゆる「進捗確認」の場とは少し（大きく？）目的が異なります。いわゆるWaterfall開発でも「朝会」は行われていると思いますが、その場は「リーダーに対してメンバーが1対1で進捗を報告する場」になっていないでしょうか？デイリースクラムは「計画された今後の作業を調整しながら、スプリントゴールに対する進捗を検査し、必要に応じてスプリントバックログを適応させる」場であり、簡単にまとめるとスクラムの3本柱の「検査」と「適応」に対応した、「再計画の場」ということになります。とは言うもののチームが慣れていないうちは、スクラムマスターは15分という制限時間を意識してファシリテートするのが良いでしょう。1～2スプリントも回せば、かなり改善できるのではないかと思います（スクラムのイベントの中で一番数多く実施されるイベントですし、スクラムマスターはその変化をチームにフィードバックできると良いでしょう）。
また、スプリントを開始した当初はスクラムマスターがファシリテーションすることが多いと思いますが、個人的にはできるだけ早いうちにその役割を開発者の持ち回りにするようにした方が良いと考えています。その辺りについては、下記ブログを紹介しておきます。
また、スプリントを開始した当初はスクラムマスターがファシリテーションすることが多いと思いますが、個人的にはできるだけ早いうちにその役割を開発者の持ち回りにするようにした方が良いと考えています。その辺りについては、下記ブログを紹介しておきます。
朝会の司会はローテーションがオススメ | Agile Studio
こんにちは、天野勝です。スクラムでは「ディリースクラム」、XPでは「ディリースタンドアップ」、チームファシリテーションでは「朝会」など、様々な呼ばれ方をする毎日行なう最大15分間のミーティングでは、司...
【スプリントレビュー】
このスプリントレビューと次のスプリントレトロスペクティブはスプリントの最終日に行われるイベントになります。今回のようなスプリント期間が1週間の場合なら、最大1時間で行われることになります。このイベントの目的は「スプリントの成果を検査し、今後の適応を決定すること」になります。昔は開発チームがPOに対してそのスプリントの成果（物）をプレゼンして、そのスプリントで達成する予定だったP.B.I.が達成されているかを確認するという感じでした。ポイントになるのは、あくまでも「本番リリース可能な成果物」で説明することであり、「このように作るつもりだったという張りぼてやパワーポイントの資料」をレビューする場ではない、ということです。ですので、もしもそのスプリントの中で本番リリース可能な成果物を開発チームが作り出すことができなければ、「このスプリントでは成果物なし」という結果をPOに報告するという場になります（筆者は幸いにしてそのような現場には立ち会ったことはないのですが）。
そして、POがその成果物を確認（検査）した結果、P.B.I.の内容や、後述する「完成の定義」を満たしていないと判断した場合は、それは「Undone（ゴール未達成）」ということになり、次スプリントに持ち越して対応するのか、いったんそのP.B.I.は保留して別のものを進めるのかなどの判断をPOが行うことになります（その逆は「Done（ゴール達成）」です）。
最新のスクラムガイドではその辺りは改定されており、「スプリントレビューはワーキングセッションであり、スクラムチームはスプリントレビューをプレゼンテーションだけに限定しないようにする」となっています（こちらの内容は後述する実践ポイントで説明します）
そして、POがその成果物を確認（検査）した結果、P.B.I.の内容や、後述する「完成の定義」を満たしていないと判断した場合は、それは「Undone（ゴール未達成）」ということになり、次スプリントに持ち越して対応するのか、いったんそのP.B.I.は保留して別のものを進めるのかなどの判断をPOが行うことになります（その逆は「Done（ゴール達成）」です）。
最新のスクラムガイドではその辺りは改定されており、「スプリントレビューはワーキングセッションであり、スクラムチームはスプリントレビューをプレゼンテーションだけに限定しないようにする」となっています（こちらの内容は後述する実践ポイントで説明します）
まとめると「スプリントレビュー」は「そのスプリントで出した成果について確認を行い、プロダクトゴールにどこまで近づけたかを確認する（検査する）場」ということになります。
【スプリントレビューの実践ポイント】
１．P.B.I.のDone、Undoneの判断はスプリントレビューだけで行うの？
上述の通り、昔はスプリントレビューでそのスプリントで実施する予定のP.B.I.の成果を確認していました。現在ではP.B.I.が完了できたらスプリントレビューを待たずにスプリント期間中に開発チームからPOに対して確認を依頼するというように、バンバンとDone・Undoneを判断してP.B.I.を完了させていくスタイルの方が主流になっているようです。
具体的にはデイリースクラムのタイミングで開発チームからPOに「P.B.I.の1つ目が完了したので、この後で少し時間もらえますか？」という感じで調整を行い、P.B.I.を都度完了させていくイメージです。ですので、スプリントレビューのタイミングでは今回のスプリントで対応予定だったP.B.I.はどこまで完了したかを確認する程度で、プロダクトゴールを達成するために次のスプリントではどのようにP.B.I.に取り組んでいくのかをスクラムチームで議論することに時間を多く割いていくスタイルに移っているようです。
言い換えると、昔よりもより積極的に開発チームがPO、ステークホルダに働きかけて、チームとしてゴールを達成することが重要視（明確化）されてきていると言えます。
具体的にはデイリースクラムのタイミングで開発チームからPOに「P.B.I.の1つ目が完了したので、この後で少し時間もらえますか？」という感じで調整を行い、P.B.I.を都度完了させていくイメージです。ですので、スプリントレビューのタイミングでは今回のスプリントで対応予定だったP.B.I.はどこまで完了したかを確認する程度で、プロダクトゴールを達成するために次のスプリントではどのようにP.B.I.に取り組んでいくのかをスクラムチームで議論することに時間を多く割いていくスタイルに移っているようです。
言い換えると、昔よりもより積極的に開発チームがPO、ステークホルダに働きかけて、チームとしてゴールを達成することが重要視（明確化）されてきていると言えます。
２．実際はどのように行われているの？
ゲーム業界の場合はスプリントレビューを社員食堂のようなオープンな場で行い、PO、開発チーム、スクラムマスターやステークホルダ以外の他チームのメンバーもふらっと参加できるようなスタイルで行われている現場もあるそうです。
筆者はエンタープライズ系しか関わってこなかったので、チーム関係者以外がスプリントレビューに参加するということを経験したことはないのですが、アジャイル・スクラム関係のイベントに参加して話を伺った際にそのような興味深い話を聞くことができました（「ゲーム」の場合、そのチームに直接関わっていなくても「操作感」や「見た目」等、ユーザーの視点でフィードバックが行えるので、そのような進め方をしても貴重な意見を集めることができるそうです）。
筆者はエンタープライズ系しか関わってこなかったので、チーム関係者以外がスプリントレビューに参加するということを経験したことはないのですが、アジャイル・スクラム関係のイベントに参加して話を伺った際にそのような興味深い話を聞くことができました（「ゲーム」の場合、そのチームに直接関わっていなくても「操作感」や「見た目」等、ユーザーの視点でフィードバックが行えるので、そのような進め方をしても貴重な意見を集めることができるそうです）。
【スプリントレトロスペクティブ】
最後のイベントが「スプリントレトロスペクティブ」です。こちらは「ふりかえり」という日本語の方が馴染みがあるかもしれません。こちらはスクラムガイドに「品質と効果を高める方法を計画することである」とありますが、今回の例のような1週間スプリントの場合、45分を上限に行うことになります。このイベントは非常に重要で、日本でも有数の某アジャイルコーチからも「スプリントレトロスペクティブだけは外したらダメ。（チームの練度が上がってくると）デイリースクラムを実施しない、というような判断をするチームも出てくるが、スプリントレトロスペクティブを外すことはない」と教わったことがあります。理由はシンプルで、このイベントを実施しないとスクラムのフレームワークとして準備されている「適応」の場を失ってしまうことになるからです。
スクラムを採用した会社・チームが継続的に生産性を上げたり、品質を上げたりすることができるのは、このイベントで自らのチームの活動について「検査」し、定期的・継続的に見直し（適応）を行うためです。「スプリント毎に」見直しを行い、小さな変化を積み重ねていくことが、最終的に大きな結果・変化につながります。一般的なWaterfall型開発の場合、このような場は用意されていないと思います（正確に言うと、ゴールがわかっている前提なので、予め最適な手法・手段等を選択することが（理論的に）可能になるため、ふりかえる必要がないということになるでしょう）。「ポストモーテム」という考え方は存在しますが、プロジェクトの終わりに実施することが基本で、多くてもフェーズ終わり毎に実施する程度だと思います。そのためそこで得られた教訓は次回以降のプロジェクトでしか生かすことはできません。また、プロジェクト期間が長くなればそもそもどんなことが起きていたかを思い出すのも一苦労になってしまいます。
スクラムを採用した会社・チームが継続的に生産性を上げたり、品質を上げたりすることができるのは、このイベントで自らのチームの活動について「検査」し、定期的・継続的に見直し（適応）を行うためです。「スプリント毎に」見直しを行い、小さな変化を積み重ねていくことが、最終的に大きな結果・変化につながります。一般的なWaterfall型開発の場合、このような場は用意されていないと思います（正確に言うと、ゴールがわかっている前提なので、予め最適な手法・手段等を選択することが（理論的に）可能になるため、ふりかえる必要がないということになるでしょう）。「ポストモーテム」という考え方は存在しますが、プロジェクトの終わりに実施することが基本で、多くてもフェーズ終わり毎に実施する程度だと思います。そのためそこで得られた教訓は次回以降のプロジェクトでしか生かすことはできません。また、プロジェクト期間が長くなればそもそもどんなことが起きていたかを思い出すのも一苦労になってしまいます。
まとめると「スプリントレトロスペクティブ」は「そのスプリントの活動を見直し（検査し）、次のスプリントで試行する改善策について検討する（適応する）場」ということになります。
【スプリントレトロスペクティブの実践ポイント】
１．実際はどんな感じで行うの？
スクラムガイドの記載内容だけでは、どのようなことをすればよいのかのイメージをつかみにくいのですが、この場では「KPT（A）」「YWT」「Fun/Done/Learn」等々、いろいろなプラクティスが存在する事だけをお伝えしたいと思います（実施方法は書籍やブログ等今はかなり豊富に情報が手に入りますので）。
チームカラーに合わせて、いくつか試してみるのも良いと思いますが、一番メジャー（？）な「KPT（A）」を実施する際のコツを一つだけお伝えします。それは、いくつも改善（Try）したいことが出てきたとしても、次のスプリントで実施することは1つに絞り込むことです。ついつい複数のTryを試したくなりますが、それをしてしまうと、次のスプリントでTryの効果を検査しようとした時に「どれが効果があったんだろう？」という事になってしまう場合があります。
チームカラーに合わせて、いくつか試してみるのも良いと思いますが、一番メジャー（？）な「KPT（A）」を実施する際のコツを一つだけお伝えします。それは、いくつも改善（Try）したいことが出てきたとしても、次のスプリントで実施することは1つに絞り込むことです。ついつい複数のTryを試したくなりますが、それをしてしまうと、次のスプリントでTryの効果を検査しようとした時に「どれが効果があったんだろう？」という事になってしまう場合があります。
２．「ふりかえりのふりかえり」を行ってみよう
スプリントレトロスペクティブも回数を重ねると、新しい意見が出てこなくなったり、マンネリ化してしまったりすることがあります。そのような場合は「ふりかえりのふりかえり」を行ってみるのも良いでしょう。
また余談ですが、過去について考える「ふりかえり」に対して、未来について考える「むきなおり」という考え方もあります。
また余談ですが、過去について考える「ふりかえり」に対して、未来について考える「むきなおり」という考え方もあります。
【おわりに】
かなり長くなってしまったので、今回はここまでとさせていただきます。スクラムのフレームワークの残りの「3つの役割」「3つの成果物」「その他のルール」については、次回のブログをお楽しみに！
以下、おまけで今回の参考書籍をいくつか紹介しておきます。
以下、おまけで今回の参考書籍をいくつか紹介しておきます。
via www.amazon.co.jp
Amazon.co.jp: アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~ : Mike Cohn, マイク コーン, 安井 力, 角谷 信太郎: 本
￥
Amazon.co.jp: アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~ : Mike Cohn, マイク コーン, 安井 力, 角谷 信太郎: 本
via www.amazon.co.jp
SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発 | 西村 直人, 永瀬 美穂, 吉羽 龍太郎 |本 | 通販 | Amazon
￥
Amazonで西村 直人, 永瀬 美穂, 吉羽 龍太郎のSCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発。アマゾンならポイント還元本が多数。西村 直人, 永瀬 美穂, 吉羽 龍太郎作品ほか、お急ぎ便対象商品は当日お届けも可能。またSCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発もアマゾン配送商品なら通常配送無料。
via www.amazon.co.jp
アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き | Esther Derby, Diana Larsen, 角 征典 |本 | 通販 | Amazon
￥
AmazonでEsther Derby, Diana Larsen, 角 征典のアジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き。アマゾンならポイント還元本が多数。Esther Derby, Diana Larsen, 角 征典作品ほか、お急ぎ便対象商品は当日お届けも可能。またアジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引きもアマゾン配送商品なら通常配送無料。
via www.amazon.co.jp
これだけ! KPT | 天野 勝 |本 | 通販 | Amazon
￥
Amazonで天野 勝のこれだけ! KPT。アマゾンならポイント還元本が多数。天野 勝作品ほか、お急ぎ便対象商品は当日お届けも可能。またこれだけ! KPTもアマゾン配送商品なら通常配送無料。
59 件
