Scrum
Scrumは、固定の役割、イベント、成果物を通じて、チームが複雑な仕事に短く反復的なサイクルで取り組めるようにするアジャイルフレームワークである。
Scrumは複雑な製品を開発・管理するためのアジャイルフレームワークであり、もともとソフトウェア開発の中で形作られたが、現在では多くの業界で使われている。その基盤には経験的プロセス制御という考え方がある。タスクを最初から最後まで事前に計画するのではなく、チームは通常1〜4週間続く、スプリントと呼ばれる短い固定の期間の中で作業する。各スプリントは使用可能な作業の増分で終わり、それがフィードバックの余地を生み、チームが次のステップを調整できるようにする。この透明性、検査、適応の組み合わせにより、Scrumは要求が不確実であったり変化しやすかったりする仕事に適している。
Scrumは3つの固定された役割を定めている。プロダクトオーナーは製品の価値に責任を持ち、やるべきことすべてを優先順位付けした一覧であるプロダクトバックログを管理する。スクラムマスターはチームがフレームワークの中で働き続けられるようにし、障害を取り除き、タスクを直接割り振ることなく協働を促進する。開発チームは作業を自ら計画し実行する。4つの繰り返されるイベントが各スプリントに構造を与える。開始時のスプリントプランニング、迅速な連携のためのデイリースクラム、構築したものを示すスプリントレビュー、そしてチームの協働の仕方を改善するためのスプリントレトロスペクティブである。
Scrumは、製品開発や多くの関係者を伴う複雑なプロジェクトのように、範囲や解決策が最初から完全には明確でないタスクに最も適している。固定のタイムボックスと定義された役割を持つ点でKanbanとは異なる。Kanbanは定められた反復を持たない継続的なフローにより重きを置く。従来のウォーターフォール計画と比較したときの利点は定期的な検証にある。誤った判断がプロジェクトの最後ではなく早い段階で表面化する。実務では、Scrumはフレームワークそのものよりも、振り返りが省略されたりバックログが放置されたりするような中途半端な実行によって失敗することが多い。
実践例
ある中堅の機械製造企業が、生産設備を監視する新しいソフトウェアを開発している。5人のチームは2週間のスプリントで作業し、各スプリントの開始時に、約40件の未処理バックログ項目の中から最も重要な10件を選び、15分のデイリースクラムで毎日同期を取る。10回目のスプリントを終えた5か月後、当初計画していた中間成果のない9か月の開発期間ではなく、最初の実用可能なバージョンが完成する。振り返りから、最初の3スプリントでは不明確な要求のためにチームの能力の約20パーセントが失われていたことが判明し、それ以降プロダクトオーナーはより明確なバックログの記述を書くようになる。
Leanshiftの活用方法
その核心において、スプリントレトロスペクティブは繰り返されるKaizenサイクルにほかならない。チームは立ち止まり、終えたばかりの仕事を率直に振り返り、次に進む前に働き方を意図的に改善する。これは、改善は一度きりのプロジェクトではなく、日々の仕事に組み込まれた定期的な習慣であるというLeanshiftの考え方に合致している。このように仕事をするチームは、製品を改善するだけでなく、自ら改善する方法を知っている人をより多く育てていく。
よくある質問
Scrumはソフトウェア開発だけに役立つのか?
いいえ。Scrumはソフトウェアで始まったが、現在ではマーケティング、製品開発、教育など、仕事が複雑で要求が途中で変わりうるあらゆる分野で使われている。
Scrumはカンバンとどう違うのか?
Scrumは、定義された役割とイベントを持つスプリントと呼ばれる固定のタイムボックスの中で動くのに対し、Kanbanは定められた反復のない継続的な作業の流れを可視化し、一度にどれだけの作業が進行中かを制限することに重点を置く。
小規模なチームでも専任のスクラムマスターは本当に必要か?
必ずしもフルタイムの役職として必要というわけではない。小規模なチームでは、誰かが通常業務と兼任することが多い。重要なのはファシリテーションとフレームワークそのものが実際に守られることである。