スクラム (ソフトウェア開発)
出典: フリー百科事典『ウィキペディア（Wikipedia）』
スクラム（英: Scrum）は、ソフトウェア開発における軽量なアジャイルソフトウェア開発手法の1つである。その名称はスポーツのラグビーでのスクラムに因んでいる。
目次 |
[編集] 歴史
スクラムが開発手法として登場したのは1993年、Jeff Sutherland、John Scumniotales、Jeff McKenna がラウンドトリップ・エンジニアリング（一種の反復型開発）を取り入れたオブジェクト指向プログラミング設計・分析ツールを構築したのが最初である。当時、素早い開発が求められており、要求仕様を簡単に動作するコードに変換する方法が求められていた。同じころ、ケン・シュエイバーが自社 (ADM) でのソフトウェア開発にこの手法を用いた。スクラムは産業界での様々なベストプラクティスに基づいており、それらがソフトウェア開発手法としてのスクラムの元となった。
スクラム的手法を以前から開発プロジェクトで使っていた企業として、富士ゼロックス、キヤノン、本田技研工業、日本電気、セイコーエプソン、ブラザー工業、3M、ゼロックス、ヒューレット・パッカードなどがある。これらのプロジェクトについては、一橋大学の野中郁次郎と竹内弘高が Harvard Business Review 誌に "The New New Product Development Game" として発表している（1986年1-2月）。逆に言えば、この論文がスクラムという用語の元となった。
[編集] 方法論
[編集] 技法
以下に、スクラム開発で必要とされる技法をあげる。
[編集] チーム作成
スクラムでは、開発チームはスポーツのチームのように機能しなければならないとされ、各メンバーは独自に動きながらも、全体として同じゴールを目指す。スクラムではチームの人数は6、7人が適当とされる。チーム代表をスクラムマスターと呼び、その仕事はプロジェクト内のスクラムプロセスの実装と管理である。スクラムチームは全体としてスクラム的手法を実践し、スクラムマスターはそれが正しい方向に進むようにする。スクラムマスターは世話役的な役割であり、権限としては間接的である。スクラムマスターはチーム外部との管理的作業を主に行い、チーム内では解決しようのない障害について「調停者」として働く。
[編集] バックログ作成
バックログには以下の3種類がある。
- 製品バックログ - ある時点での要求仕様のリポジトリ。製品の所有者（資金提供者）による抽象的な要求であることが多い。
- リリースバックログ - 製品バックログを整理して優先順位付けし、次のリリースで実現するものを抜き出したもの。スクラムチームによって製品バックログよりも詳細化される。
- スプリントバックログ - スプリント（後述）の開始時、そのスプリントで実現する仕様をまとめたもの。スプリント完了時に、コーディング/テスト/ドキュメンテーションが完全に完了していることを要求される。スプリントバックログはリリースバックログを管理可能な単位に細分化したもので、1つの項目を通常8人時から16人時で完成できるように項目を分ける。
[編集] プロジェクト区分
プロジェクトは最長4週間の期間に分割される。一つの期間をスプリント（Sprint）と呼び、スプリント毎に実装すべきバックログが入力となる。
[編集] スクラム会議
スプリント期間中、チームは毎日スクラム会議を開く。スクラム会議は平日の決まった時間に決まった場所で行い、15分以内で完了させる。スクラムマスターは必ず出席する。スクラムマスターはチーム全員に、「前回のスクラム会議以降、何をしたか」、「問題はあるか」、「次回のスクラム会議までに何をするか」を質問する。会話はこれらの質問への応答に限られる。その質疑応答の結果によっては即座に別の会議を開くこともある。問題があると報告された場合、スクラムマスターは即座に意思決定する責任を負う。問題が外的要因によるものである場合、スクラムマスターがその解決の責任を負う。
[編集] 工程
スクラムの開発工程は主に5つの活動からなる。「リリース計画レビュー」、「製品基準の調整・レビュー・配布」、「スプリント」、「スプリントレビュー」、「クロージャ」である。このうち、スプリントとスプリントレビューが繰り返し行われる。
[編集] スプリント
スプリントは実際にソフトウェア開発が行われる工程である。スプリントは、開発、まとめ、レビュー、調整の繰り返しである。
スプリント内では決まった順序は存在しない。必要に応じてバックログの項目を開発し、まとめ、レビューするし、項目によっては単にレビューと調整だけで済む。どのように開発されるかはそのバックログ項目の内容による。
[編集] スプリントレビュー
スプリントの後には必ずスプリントレビューが行われる。ここで、スプリントで開発されたソフトウェアのレビューが行われ、必要に応じて新たなバックログ項目が追加される。レビューには顧客、マネージャ、開発者、場合によっては営業やマーケティング関係者も参加する。
スプリントとスプリントレビューの繰り返しは、顧客に製品の機能や品質が十分と判断されるまで繰り返される。その後、クロージャ（終了）工程へと移行し、リリースの準備が行われる。
[編集] クロージャ（終了）
この工程での作業は、最終的なデバッグ、マーケティングや販促のための作業である。
この工程の終了をもってプロジェクトは完了する。ソフトウェア開発の予測は困難であるため、完了が予定より遅くなったり、早まったりすることもある。しかし、スクラムによる制御（後述）を行うことで遅延を計算できる。
[編集] 制御
開発工程というブラックボックスを管理可能にするため、スクラムには制御（controls）が用意されている。制御とはスクラムの技法とプロジェクト進捗の組み合わせである。
結果を分析することで、プロジェクトマネージャは何らかの意思決定を行う。例えば、
- バックログ項目数によりプロジェクトの規模を見積もる。
- 実装が完了したバックログ数からプロジェクトの進捗状況を見積もる。
- リスクの定量化によってプロジェクトの複雑度を見積もる。
スクラムの制御はメタデータモデルで表される。
[編集] 参考文献
- (PDF) Rising, L., Janoff, N.S. (2000). The Scrum Software Development Process for Small Teams
- (PDF) Schwaber, K. Advanced Development Methods. SCRUM Development Process
- (PDF) Dr. Sutherland, J. (October 2004) Agile Development: Lessons learned from the first scrum
[編集] 関連項目
- Dynamic System Development Method (DSDM)
- ユーザ機能駆動開発 (FDD)
- エクストリーム・プログラミング (XP) - スクラムと組み合わせて使われることが多い
[編集] 外部リンク
- SCRUMワークショップ体験記 @IT 情報マネジメント
- Scrum （有）メタボリックス
- Implementing Scrum
- Scrum Alliance
- Scrum et al - Google Techtalk with Ken Schwaber（ビデオ）
- Scrum and XP from the Trenches（非常に大きいPDFなので要注意）
- Scrum in five minutes
- Scrum articles directory
- Agile Alliance's Scrum library
- InfoQ.com / Agile
- Tackle - a web-based Scrum Tracking Tool
