(Wikipedia スクラム (ソフトウェア開発)より)

スクラム（Scrum）は、ソフトウェア開発における反復的で漸進的なアジャイルソフトウェア開発手法の1つである。この方法論は「柔軟かつ全人的なプロダクト開発ストラテジーであり、共通のゴールに到達するため、開発チームが一体となって働くこと」とされる。この方法論は、製品開発における伝統的な、シーケンシャルなアプローチとは大きく異なる。この方法論は、チームが自発的に組織だって行動することを可能にする。この自己組織化を実現するのは、すべてのチームメンバーが物理的に同じ場所にいること、あるいは密なオンライン共同作業を通じ、全員が日々直接会ってお互いにコミュニケーションをとり、プロジェクトにおける規律を守ることである。

スクラムのカギとなる基本原則は、プロジェクト開発の途中で、顧客は、要求や必要事項を変えられるという認識である。予想できない変更について、計画に基づく方法で対処することは、容易ではない。したがって、スクラムは経験に基づくアプローチを採用する。問題を十分に理解することも、定義することもできないので、現れた要求へ素早く対応するためのチームの能力を最大化することに集中する、というアプローチである。

歴史

1986年に野中郁次郎と内弘高が「新製品開発のプロセス」について日本の組織とNASAといったアメリカの組織との比較、分析を行った研究論文「The New New Product Development Game」が『ハーバード・ビジネス・レビュー』に掲載される。その中で柔軟で自由度の高い日本発の開発手法をラグビーのスクラムに喩えて「Scrum（スクラム）」として紹介したEZ。

野中、竹内の論文に着想を得たJeff Sutherland、John Scumniotales、Jeff McKenna が、1993年にラウンドトリップ・エンジニアリング（一種の反復型開発）を取り入れたオブジェクト指向プログラミング設計・分析ツールを構築し、実践したのがソフトウェア開発手法としてのスクラムの最初であるITmedia。当時、素早い開発が求められており、要求仕様を簡単に動作するコードに変換する方法が求められていた。同じころ、ケン・シュエイバーが自社 (ADM) でのソフトウェア開発にこの手法を用いた。スクラムは産業界での様々なベストプラクティスに基づいており、それらがソフトウェア開発手法としてのスクラムの元となった。

このプラクティスは2003年に『アジャイルソフトウェア開発スクラム』としてまとめられたITmedia。

方法論

技法

スクラムに定められた技法はないが、以下の技法が有効だと評価されている。

1. テスト駆動開発
2. リファクタリング
3. 継続的インテグレーション

スクラムにおける役割

チーム

スクラムでは、開発チームはスポーツのチームのように機能しなければならないとされる。つまり、各メンバーが協力し、全体として同じゴールを目指す。スクラムでは、チームの人数は、5人から9人が適当とされ、実装とテストの能力を持つ。チームは、作業プロセスと作業結果の責任も持ち、自らチーム内の管理を行う。

プロダクトオーナー

製品の総責任者。 顧客の意思の代表としての役割を担う。 ビジネスの視点（ROI等）においてプロジェクトに問題がないことを保障する役割を持つ。 顧客の要望（ユーザーストーリー）をプロダクトバックログに優先順位を付けて反映させる。

スクラムマスター

スクラムフレームワークが正しく適用されていることを保証する役割であるが、権限としては間接的である。主な作業は、チーム内外の組織間調停( ファシリテーション )と外部妨害を対処することとされる。従来のプロジェクトマネージャがこの役割を担うことが多いが、プロジェクトそのものを管理するわけではない。

バックログ作成

バックログには以下の2種類がある。

プロダクトバックログ

製品に必要な要素を項目に起こした一覧。バックログを整理して上下関係で優先順位を表す。各項目はチームによって相対難易度（コスト）の見積もりを付けられ、プロダクトオーナーが顧客観点からの価値を見積もる。スクラムチームによって上位項目は詳細化される。

スプリントバックログ

スプリント（後述）の開始時、そのスプリントで実現する仕様をまとめたもの。スプリント完了時に、コーディング/テスト/ドキュメンテーションが完了していることを要求される。スプリントバックログはプロダクトバックログを管理可能な単位に細分化したもので、通常1つの項目を、プロダクトバックログと同じ相対難易度か、スプリントバックログ独自の相対難易度か、慣れていない組織では8人時から16人時で完成できるように見積り、項目を分ける。

プロジェクト区分

プロジェクトは最長4週間の期間に分割される。一つの期間をスプリント（Sprint）と呼び、スプリントごとに実装すべきバックログが入力となる。

工程

スクラムの開発工程は主に6つの活動からなる。「計画ミーティング」、「製品基準の調整・レビュー・配布」、「スプリント」、「スプリントレビュー」、「振り返り」、「クロージャ」である。このうち、計画ミーティング・スプリント・スプリントレビュー・振り返りが繰り返し行われる。

計画ミーティング

プロダクトオーナーは、スプリントで実現させたいプロダクトバックログを、優先順位を伴って確定する。このとき、プロダクトオーナーは、チームに対して、プロダクトバックログの消化数を強制することはできない。これまでのチームのパフォーマンス（ベロシティ・前回スプリントで達成したプロダクトバックログの相対見積り合計）から、どの程度のプロダクトバックログが消化できそうかとを予測するうえでの参考とし、より大きなチーム運営として取り組むためのフィードバックとする（例：今より早く製品を仕上げていくには、チームに人員を追加する）。

チームは、プロダクトバックログの相対見積りを行う。プロダクトオーナーは、プロダクトバックログを勝手に見積もってはならない。また、チームは、プロダクトバックログの優先順位を勝手に変更してはならない。プロダクトバックログの見積りが非現実的と思われる場合、あるいは優先順位についての知見がある場合、プロダクトオーナーは、プロダクトバックログについて、チームに説明する必要がある。プロダクトオーナーは、そのフィードバックを元に、最終的なバックログを決定し、チームと合意する。

プロダクトバックログに対する決定のほかに、スプリント終了時に達成するスプリントゴールを定める。ゴールは、プロダクトと直接関係のない内容でも構わない。チームを改善するあらゆる取り組みを対象とする（例：継続インテグレーション可能な環境を整える・外部ライブラリの使用方法について、チーム内で共有する）。

スプリント

スプリントは、実際にソフトウェア開発が行われる工程である。スプリントは、開発、まとめ、レビュー、調整の繰り返しである。

スプリント内では、決まった順序は存在しない。必要に応じて、バックログの項目を開発し、まとめ、レビューする。また、項目によっては、単にレビューと調整だけで済む場合もある。どのように開発されるかは、そのバックログ項目の内容による。通常は、1週間から4週間のタイムボックスが設定される。

スクラム会議

スプリント期間中、チームは、毎日スクラム会議を開く。スクラム会議は、平日の決まった時間に決まった場所で行う。また、15分以内で完了させなければならない。また、スクラムマスターは、必ず出席しなければならず、チーム全員に対して、「前回のスクラム会議以降、何をしたか」「問題はあるか」「次回のスクラム会議までに何をするか」などの質問をする。会話は、これらの質問への応答に限られる。その質疑応答の結果によっては、即座に別の会議を開くこともある。問題があると報告された場合、スクラムマスターは、即座に意思決定する責任を負う。問題が外的要因によるものである場合、スクラムマスターが、その解決の責任を負う。

スプリントレビュー

スプリントの後には、必ずスプリントレビューが行われる。スプリントレビューでは、スプリントで開発されたソフトウェアのレビューが行われ、必要に応じて、新たなバックログ項目が追加される。また、このレビューには、顧客、マネージャ、開発者が参加する。なお、場合によっては、営業やマーケティング関係者も参加する場合もある。

スプリントとスプリントレビューの繰り返しは、製品の機能や品質が十分であると顧客が判断するまで繰り返される。その後、クロージャ（終了）工程へと移行し、リリースの準備が行われる。

振り返り

振り返りでは、スプリントゴールの達成度、スプリントで発生した問題、その問題に対する改善策などについて話し合う。また、次回のスプリントゴール目標についての取りまとめを行う場合がある。

クロージャ（終了）

クロージャでは、最終的なデバッグ、マーケティング、販売促進を行う。

クロージャの完了をもって、プロジェクトは終了する。ソフトウェア開発の予測は困難であるため、完了が予定より遅くなったり、早まったりすることもある。しかし、スクラムによる制御（後述）を行うことで、その遅延を計算できる。

制御

開発工程というブラックボックスを管理可能にするため、スクラムには制御（controls）が用意されている。制御とはスクラムの技法とプロジェクト進捗の組み合わせである。

結果を分析することで、プロジェクトマネージャは何らかの意思決定を行う。例えば、

• バックログ項目数によりプロジェクトの規模を見積もる。
• 実装が完了したバックログ数からプロジェクトの進捗状況を見積もる。
• リスクの定量化によってプロジェクトの複雑度を見積もる。

スクラムの制御はメタデータモデルで表される。