はじめに
普段はスクラムやアジャイル開発に携わっていないエンジニアが、初めてスクラム手法での開発に参加し、スプリントレビューというイベントに参加しました。
本記事では、その際に感じたことや学んだことを中心にまとめています。
これからスクラムを学ぼうとしている方や、初めてスプリントレビューに参加する方の参考になれば幸いです。
前提
スクラムとは何か。についてや、
スクラムの詳細については本ブログでは言及しません。
あくまで個人がスプリントイベントに参加して受けた印象や考察についてまとめています。
スクラムやスクラムイベントの詳細については他の記事を参照してください。
スプリントレビューとは
とはいえ、軽くスプリントレビューについては触れておきたいと思います。
スプリントレビューとは、スクラムにおける重要なイベントの一つです。
開催時間は？
スクラムでは各スクラムイベントの開催時間目安が規定されています。
スプリントレビューはスクラムイベントの最後から2番目に開催され、スプリントの期間によってその開催時間が決まります。
基本的な1ヶ月周期のスプリントの場合は最大で4時間確保します。
誰が参加する？
開発者とプロダクトオーナーは必須で、スクラムマスターは任意参加です。
私が参加したスプリントレビューは主にファシリテーター役でスクラムマスターも参加していました。
目的は？
スクラムガイドでは以下のように記載されています。（※和訳）
スプリントの結果を検査し、将来の適応を決定することです。スクラム チームは作業の結果を主要な関係者に提示し、製品目標に向けた進捗状況について話し合います。
イベント中、スクラム チームと関係者は、スプリントで達成されたことと、環境内で何が変わったかをレビューします。この情報に基づいて、参加者は次に何をすべきかについて協力します。新しい機会に対応するために、製品バックログも調整される可能性があります。スプリント レビューは作業セッションであり、スクラム チームはプレゼンテーションに限定しないようにする必要があります。
このように、単なる成果のレビューにとどまらず、次回以降のスプリントや将来に向けた調整の機会を得ることが目的ようです。
流れ
基本的にはスプリントのインクリメントを確認し、プロダクトオーナーやステークホルダーがフィードバックします。
1. インクリメントを確認
インクリメントとは、スプリントの終了時に完成した 成果物 のことを指します。
これには新しい機能や改善された機能が含まれます。
スプリントレビューでは、開発者がこのインクリメントを実際にデモンストレーションし、完成度や機能性を確認します。
ここで重要なのは、事前に定めた完了の定義（Definition of Done）に従っていることを確認することです。 また、開発者視点ではなく利用する側の視点で説明や操作などを心がける様にします。
定義によってデモンストレーションの方法はさまざまですが、
タスク別のデモンストレーション具体例は以下の様になります。
開発タスク
実装された機能をリアルタイムに操作してミーティングの画面共有などで見てもらうか、開発環境での動作結果のスクリーンショットなどを共有します。
設計検討タスク
検討結果の設計図や考慮ポイントをDesign Docなどのドキュメントにまとめたものを共有して説明します。
調査タスク
調査結果をまとめたドキュメントなどを共有し調査結果を説明します。
その他以下のような方法も駆使します。
- プロジェクト管理ボードを見せながら背景や進行予定を共有する
- ドキュメントツールを見せながら実際の作業記録を共有する
- Githubを見せながらソースコードや実装箇所を説明する
2. フィードバックを得る
デモンストレーションの後、プロダクトオーナーやステークホルダーからフィードバックを得ます。
具体的なフィードバック例を以下に挙げます。
どこに実装される？スコープは？
デモンストレーションの中で実装される部分や環境などが明確になっていない場合はすり合わせます。
開発/検証/本番などの環境、実装対象のスコープなどを明確にして認識齟齬をなくして影響を及ぼす対象やリスクをクリアにします。
考慮できている？
実装内容を踏まえた上で、考慮できてないかもしれない部分についてすり合わせます。
実際に考慮できていなかったと判断された場合は次のスプリントにて未考慮部分に対応できるように計画を立てるなどします。方針策定、設計考慮タスクなど切り出すイメージです。
リリースまでの期間は？次スプリントでどこまで進める？
実装環境を開発/検証環境としていた場合は、本番環境へのデプロイスケジュールやリリースまでに必要な期間をすり合わせます。次のスプリント計画の前情報となります。
どこに時間がかかっていたのか？
計画通りに進まないタスクがあった場合、原因を共有します。タスクの切り出し方が良くなかったのか、想定外の事態が発生していたのかなどを明確にしてその場で改善案を検討することもあります。
注意点
フィードバックの段階では反省や感想などの会話に発展しないように注意します。 反省点や改善のディスカッションはスプリントレビューの次のイベントであるレトロスペクティブに任せるべきであり、 スプリントレビューの場ではできたこと・できなかったことの説明や整理に集中すべきです。
3. 未完了タスクの確認（できなかったことを確認）
完了できなかったタスクについて説明します。進行中に直面した問題や課題を明確にし、次のスプリントでどのように対応するかを話し合います。
タスク進行中に都度、作業ログのコメントとして進捗状況を記録しておくと共有しやすいです。
考慮不足だったために時間がかかっていたのであれば、計画していたタスクには元々どれくらいの時間を見積もっていて、実際にどれくらい作業にかかったのかが明確になっていることが重要です。
スクラムでは作業タスクをプロダクトバックログアイテム（PBI）やスプリントバックログアイテム（SBI）に分類してチケット化し、プロジェクト管理ツールで管理します。
未完了タスクの整理が終わったらできなかったアイテムを次のスプリントの枠へ移動させて調整します。
4. タスクの完了処理
フィードバックを反映し、全てのインクリメントが完了の定義を満たしていることを確認できたら、その場でタスクを完了ステータスに変更します。
5. スプリントの完了処理
全てのインクリメントがレビューされ、タスクが完了となったらスプリント自体のステータスを完了とします。 完了できなかったタスクは次期スプリントに移動するなど、このタイミングで適切に対応します。
その他
レビュー中には他開発者からも随時気になる点がある場合は質問をします。
実装の詳細までは全員が把握しておく必要はないですが、他の機能やリリースに影響を与える可能性があるかどうかは重要な考慮点となりますので、特にその観点からも不明点が出てきた時点で質問して懸念点は払拭しておく必要があります。
全体的な感想
アウトプットの質と進捗状況の記録が大事
スプリントレビューまでにインクリメントを仕上げることは大前提ですが、
考慮もれや計画外の事象も発生しうる前提として、ステークホルダーに説明できるように準備しておくことが求められます。
タスクを消化中に浮かび上がったアイデアや意思決定の流れもプロジェクト管理ツールやドキュメントなどでメモ書きやコメントレベルでも良いので記録しておくことでレビュー中のディスカッションが有意義になると思います。
心理的安全性と透明性が肝
レビュー中、終始全員が自由に発言できる環境が整っており、随時気になることやわからないことがあれば積極的に質問したりいい感じに指摘をしたりと、とにかく 心理的安全性が高い と感じました。
タスク進行中に感じたことや問題点もありのまま共有し、カイゼンに向けてチーム全員が真摯に取り組む姿勢が大事だと感じました。
ウォーターフォールのMTGとの対比
あまり効果的な比較とは言えませんが、いわゆるウォーターフォール開発のミーティングと比較すると、良い意味できっちりと構造化された様な詳細なアジェンダを準備する必要はないと感じました。
デモンストレーションで共有されるインクリメントと、その補足解説やフィードバックがスプリントレビューの肝心な部分です。
補足解説のために、タスク進行中に発生した課題や問題は関連するドキュメントやログとして都度記録されるため、個別に詳細なアジェンダを用意しなくても、ミーティング時点で共有すべき情報が一通り揃っている状態で臨むことができます。
この点において、ウォーターフォール開発手法のミーティングと比較すると、スクラムではドキュメント文化や、開発者が開発中に発生した事象や懸念点を整理して記録する能力が重要だと感じました。
最後に
スクラムのイベントはレビュー以外にもあるので、機会があれば他のイベントや関連するトピックについても今後ご紹介したいと思います。
でわ。
