スクラム

開発を始める前には、どの機能が使われるかも、どの実装がうまく動くかも、すべてはわかりません。
計画だけを詳しくしても、その不確実さは残ります。
スクラム（Scrum）は、複雑な問題に取り組むチームが、小さく成果を作り、実際に得た情報から次の判断を変えていくためのフレームワークです。

作った結果から計画を変える

スクラムでは、プロダクトオーナーが、プロダクトを改善するための仕事をプロダクトバックログに並べます。
チームはそこから仕事を選び、一定期間のスプリントで、利用可能な成果を作ります。
その成果と周囲の変化を関係者と確かめ、次に取り組む仕事を調整します。

この判断を支えるのが、透明性、検査、適応です。
たとえば「完成した」と報告された機能にテストが残っていれば、使える状態かどうかを正しく検査できません。
完成の定義を共有し、実際の状態がわかるようにすることが、計画を変える前提になります。
スクラムでいうインクリメントは、既存の成果と組み合わせて使え、完成の定義を満たす成果です。

予約サービスを改善する例

たとえば、予約サービスで「利用者が電話せずに予約を変更できる状態」を目指すとします。
最初から変更に関する全機能を作る代わりに、チームは日時変更だけを扱う小さな範囲を選びます。
画面だけでなく、空き枠の確認や変更後の通知まで含め、使えるところまで完成させます。

その成果を関係者と確認すると、「変更できる期限が画面からわからない」という問題が見つかるかもしれません。
そこで次の仕事を、変更対象の拡大よりも期限の説明へと並べ替えます。
完成件数だけを数えていれば見落とす問題を、動く成果から見つけて判断に反映する例です。
実際の利用状況を確かめるには、リリース後の観察も必要になります。

イベントごとに確かめる対象が違う

スクラムのイベントには、それぞれ次の判断をするための目的があります。

  • スプリントプランニング：今回の目的、取り組む仕事、実現するための計画を決めます。
  • デイリースクラム：開発者がスプリントゴールへの進捗を確かめ、直近の計画を調整します。
  • スプリントレビュー：関係者と成果を検査し、プロダクトを今後どう変えるかを検討します。
  • スプリントレトロスペクティブ：チームが品質や仕事の進め方を改善する方法を計画します。

これらはすべてスプリントの中で行います。
会議を開催していても、観察した問題が次の仕事や進め方に反映されなければ、検査と適応がつながっていません。

導入時に確認すること

まず、チームが扱うプロダクトの範囲、目指す状態、完成と呼べる品質をそろえます。
そのうえで、使える成果を作るための技能と、学んだ結果に応じて計画を変える権限がチームにあるかを確かめます。
スクラムは、仕様の書き方やテストの技法までは指定しないため、それらは仕事に合わせて補う必要があります。

「毎朝集まり、仕事を2週間ごとに区切る」だけでは、成果の検査や意思決定まで整うとは限りません。
スクラムマスターは、こうした不足をチームや組織と確かめ、スクラムが機能するよう支援します。

参考資料