スクラム（）は、ソフトウェア開発における反復的で漸進的なアジャイルソフトウェア開発手法の1つである。この方法論は「柔軟かつ全人的なプロダクト開発ストラテジーであり、共通のゴールに到達するため、開発チームが一体となって働くこと」とされる。この方法論は、製品開発における伝統的な、シーケンシャルなアプローチとは大きく異なる。この方法論は、チームが自発的に組織だって行動することを可能にする。この自己組織化を実現するのは、すべてのチームメンバーが物理的に同じ場所にいること、あるいは密なオンライン共同作業を通じ、全員が日々直接会ってお互いにコミュニケーションをとり、プロジェクトにおける規律を守ることである。スクラムのカギとなる基本原則は、プロジェクト開発の途中で、顧客は、要求や必要事項を変えられるという認識である。予想できない変更について、計画に基づく方法で対処することは、容易ではない。したがって、スクラムは経験に基づくアプローチを採用する。問題を十分に理解することも、定義することもできないので、現れた要求へ素早く対応するためのチームの能力を最大化することに集中する、というアプローチである。スクラムが開発手法として登場したのは1993年、Jeff Sutherland、John Scumniotales、Jeff McKenna がラウンドトリップ・エンジニアリング（一種の反復型開発）を取り入れたオブジェクト指向プログラミング設計・分析ツールを構築したのが最初である。当時、素早い開発が求められており、要求仕様を簡単に動作するコードに変換する方法が求められていた。同じころ、ケン・シュエイバーが自社 (ADM) でのソフトウェア開発にこの手法を用いた。スクラムは産業界での様々なベストプラクティスに基づいており、それらがソフトウェア開発手法としてのスクラムの元となった。スクラム的手法を以前から開発プロジェクトで使っていた企業として、富士ゼロックス、キヤノン、本田技研工業、日本電気、セイコーエプソン、ブラザー工業、3M、ゼロックス、ヒューレット・パッカードなどがある。これらのプロジェクトについては、一橋大学の野中郁次郎と竹内弘高が "Harvard Business Review" 誌に "The New New Product Development Game" として発表している（1986年1-2月）。逆に言えば、この論文がスクラムという用語の元となった。スクラムでは定めた技法はないが、スクラムでは以下の技法は有効だと評価されている。バックログには以下の2種類がある。プロジェクトは最長4週間の期間に分割される。一つの期間をスプリント（Sprint）と呼び、スプリントごとに実装すべきバックログが入力となる。スクラムの開発工程は主に6つの活動からなる。「計画ミーティング」、「製品基準の調整・レビュー・配布」、「スプリント」、「スプリントレビュー」、「振り返り」、「クロージャ」である。このうち、計画ミーティング・スプリント・スプリントレビュー・振り返りが繰り返し行われる。プロダクトオーナーは、スプリントで実現させたいプロダクトバックログを、優先順位を伴って確定する。このとき、プロダクトオーナーは、チームに対して、プロダクトバックログの消化数を強制することはできない。これまでのチームのパフォーマンス（ベロシティ・前回スプリントで達成したプロダクトバックログの相対見積り合計）から、どの程度のプロダクトバックログが消化できそうかとを予測するうえでの参考とし、より大きなチーム運営として取り組むためのフィードバックとする（例：今より早く製品を仕上げていくには、チームに人員を追加する）。チームは、プロダクトバックログの相対見積りを行う。プロダクトオーナーは、プロダクトバックログを勝手に見積もってはならない。また、チームは、プロダクトバックログの優先順位を勝手に変更してはならない。プロダクトバックログの見積りが非現実的と思われる場合、あるいは優先順位についての知見がある場合、プロダクトオーナーは、プロダクトバックログについて、チームに説明する必要がある。プロダクトオーナーは、そのフィードバックを元に、最終的なバックログを決定し、チームと合意する。プロダクトバックログに対する決定のほかに、スプリント終了時に達成するスプリントゴールを定める。ゴールは、プロダクトと直接関係のない内容でも構わない。チームを改善するあらゆる取り組みを対象とする（例：継続インテグレーション可能な環境を整える・外部ライブラリの使用方法について、チーム内で共有する）。スプリントは、実際にソフトウェア開発が行われる工程である。スプリントは、開発、まとめ、レビュー、調整の繰り返しである。スプリント内では、決まった順序は存在しない。必要に応じて、バックログの項目を開発し、まとめ、レビューする。また、項目によっては、単にレビューと調整だけで済む場合もある。どのように開発されるかは、そのバックログ項目の内容による。通常は、1～4週間のタイムボックスが設定される。スプリント期間中、チームは、毎日スクラム会議を開く。スクラム会議は、平日の決まった時間に決まった場所で行う。また、15分以内で完了させなければならない。また、スクラムマスターは、必ず出席しなければならず、チーム全員に対して、「前回のスクラム会議以降、何をしたか」「問題はあるか」「次回のスクラム会議までに何をするか」などの質問をする。会話は、これらの質問への応答に限られる。その質疑応答の結果によっては、即座に別の会議を開くこともある。問題があると報告された場合、スクラムマスターは、即座に意思決定する責任を負う。問題が外的要因によるものである場合、スクラムマスターが、その解決の責任を負う。スプリントの後には、必ずスプリントレビューが行われる。スプリントレビューでは、スプリントで開発されたソフトウェアのレビューが行われ、必要に応じて、新たなバックログ項目が追加される。また、このレビューには、顧客、マネージャ、開発者が参加する。なお、場合によっては、営業やマーケティング関係者も参加する場合もある。スプリントとスプリントレビューの繰り返しは、製品の機能や品質が十分であると顧客が判断するまで繰り返される。その後、クロージャ（終了）工程へと移行し、リリースの準備が行われる。振り返りでは、スプリントゴールの達成度、スプリントで発生した問題、その問題に対する改善策などについて話し合う。また、次回のスプリントゴール目標についての取りまとめを行う場合がある。クロージャでは、最終的なデバッグ、マーケティング、販売促進を行う。クロージャの完了をもって、プロジェクトは終了する。ソフトウェア開発の予測は困難であるため、完了が予定より遅くなったり、早まったりすることもある。しかし、スクラムによる制御（後述）を行うことで、その遅延を計算できる。開発工程というブラックボックスを管理可能にするため、スクラムには制御（controls）が用意されている。制御とはスクラムの技法とプロジェクト進捗の組み合わせである。結果を分析することで、プロジェクトマネージャは何らかの意思決定を行う。例えば、スクラムの制御はメタデータモデルで表される。名称はスポーツのラグビーでのスクラムにちなむ。

出典:wikipedia