スクラム実践者が知るべき97のこと

14ビジネスに舵を取り戻すスクラム

ラファエル・サバー

ソフトウェア開発に対する従来のアプローチにおいて、約束といえば合意したスコープがスケジュールや予算に収まるようにすることだった。スコープと時間と予算の組み合わせが従来の「成功」の定義だったのだ。スコープを小さくて実行可能な作業の単位に分解し、見積もり、積み上げ、たっぷりとバッファ（コンティンジェンシーと呼ばれるものだ）を加えてから、期日を決定するのが通常だった。期日や予算が決まったあとにスコープが調整されていたなら、あなたは運がよかった。でき上がった計画には、最終的な成果物に収束させるために実行が必要なすべての作業が含まれており、チームは山のようなタスクをかきわけて進む必要があった。期間の大部分で実際の進捗はかなり不透明だったが、タスクリストのチェックではいつも青信号になっていた。最終日に近づくにつれ、実際のリリースを予定通り行うのは難しいと否が応にもわかった。

これは、非常にリスクの高い「オール・オア・ナッシング」手法だった。変更の余地がほとんどなかっただけでなく、約束された結果が約束の日までに実際に準備できるという保証もほぼなかった。

このような従来の手法では、ビジネスはプロダクトのマーケット投入までの時間を制御できないばかりか、このままやっていてもプロダクトがリリースできるのかできないのか現実的な見識すら持てなかった。明らかにビジネスは舵を取っていなかったのだ。

スクラムでは、プロダクトを短いサイクル（スプリント）で作り、各スプリントの終わりにリリース可能なインクリメントを作り出すことになっている。単に計画されたタスクを遂行するのではなく、実際のユーザーにリリース可能で現実の価値を提供する「完成」バージョンに収束させていくことが中心となる。毎スプリント、その時点でプロダクトが解決しなければいけない課題のうち最も重要だと思われることに取り組む。毎スプリント、プロダクトオーナーの語るビジネス情報と優先順位にもとづいて、顧客やユーザーにとって最も価値が高いものについての仮説を立てる。もう長期計画でわからないことが多くても目をつぶらなくてよい。 ...