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

出典: フリー百科事典『ウィキペディア(Wikipedia)』
移動: 案内検索

スクラム: Scrum)は、ソフトウェア開発における反復的で増分的なアジャイルソフトウェア開発手法の1つである。中心点は「開発チームが一体にすると共有されている目的を追い求める柔軟なプロダクト開発ストラテジー」である。比較的に「伝統的と順次的なさしかける方法」の優先度が低い。

スクラムはチームメンバー全員の口頭のコミュニケーションを励ますとチームが自動で揃うことを可能にする。

スクラムの主な点1つとは、プロジェクト開発の途中で対象顧客の欲求が変わる可能性も予想も簡単に解決もできない問題が発生される可能性も認める。よりて、スクラムはプロジェクトの問題を全幅的に理解することが出来ないので、チームのタスクを早く済む力と新しい変更に急に対応する力を上げる実験的な手法となる。

歴史[編集]

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

スクラム的手法を以前から開発プロジェクトで使っていた企業として、富士ゼロックスキヤノン本田技研工業日本電気セイコーエプソンブラザー工業3Mゼロックスヒューレット・パッカードなどがある。これらのプロジェクトについては、一橋大学野中郁次郎竹内弘高Harvard Business Review 誌に "The New New Product Development Game" として発表している(1986年1-2月)。逆に言えば、この論文がスクラムという用語の元となった。

方法論[編集]

技法[編集]

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

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

スクラムにおける役割[編集]

チーム
スクラムでは、開発チームはスポーツのチームのように機能しなければならないとされ、各メンバーが協力し、全体として同じゴールを目指す。スクラムではチームの人数は5人から9人が適当とされ、実装とテストの能力を持つ。チームは作業プロセスと作業結果の責任も持ち、自らチーム内の管理を行う。
プロダクトオーナー
製品の総責任者。 顧客の意思の代表としての役割を担う。 ビジネスの視点(ROI等)においてプロジェクトに問題がない事を保障する役割を持つ。 顧客の要望(ユーザーストーリー)をプロダクトバックログに優先順位を付けて反映させる。
スクラムマスター
スクラムフレームワークが正しく適用されている事を保証する役割であるが権限としては間接的である。主の作業はチーム内外の組織間調停( ファシリテーション )と外部妨害を対処することとされる。従来のプロジェクトマネージャがこの役割を担う事が多いが、プロジェクトそのものを管理するわけではない。

バックログ作成[編集]

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

  1. プロダクトバックログ - 製品に必要な要素を項目に起こした一覧。バックログを整理して上下関係で優先順位を表す。各項目はチームによって相対難易度(コスト)の見積もりを付けられ、プロダクトオーナーが顧客観点からの価値を見積もる。スクラムチームによって上位項目は詳細化される。
  2. スプリントバックログ - スプリント(後述)の開始時、そのスプリントで実現する仕様をまとめたもの。スプリント完了時に、コーディング/テスト/ドキュメンテーションが完了していることを要求される。スプリントバックログはプロダクトバックログを管理可能な単位に細分化したもので、通常1つの項目を、プロダクトバックログと同じ相対難易度か、スプリントバックログ独自の相対難易度か、慣れていない組織では8人時から16人時で完成できるように見積り、項目を分ける。

プロジェクト区分[編集]

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

工程[編集]

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

計画ミーティング[編集]

スプリントで実現させたいプロダクトバックログを、優先順位を伴って確定させる。プロダクトオーナーはプロダクトバックログを提示する。この時、プロダクトオーナーはチームに対してプロダクトバックログの消化数を強制することは出来ない。これまでのチームのパフォーマンス(ベロシティ・前回スプリントで達成したプロダクトバックログの相対見積り合計)から、どの程度のプロダクトバックログが消化できそうかという参考とし、より大きなチーム運営として取り組む為のフィードバックとする(例:今より早く製品を仕上げていくには、チームに人員を追加するなど)。 チームは、プロダクトバックログの相対見積りを行う。プロダクトオーナーが勝手に見積もってはならない。また、チームがプロダクトオーナーが提示したプロダクトバックログの優先順位を勝手に変更してはならない。チームはプロダクトバックログの見積りが非現実的と思われる場合、あるいは優先順位についての知見がある場合は、プロダクトバックログに対して説明を行う必要がある。プロダクトオーナーはそのフィードバックを元に、最終的なバックログを決定し、チームと合意する。 プロダクトバックログに対しての決定のほかに、スプリント終了時に達成するスプリントゴールを定める。ゴールはプロダクトと直接関係のない内容でも構わない。チームを改善するあらゆる取り組みを対象とする(例:継続インテグレーション可能な環境を整える・外部ライブラリの使用方法について、チーム内で共有する)。

スプリント[編集]

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

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

スクラム会議[編集]

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

スプリントレビュー[編集]

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

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

振り返り[編集]

スプリントゴールの達成具合や、スプリントで発生した問題とその改善について話し合う。次回のスプリントゴール目標についての取りまとめも含まれる場合がある。

クロージャ(終了)[編集]

この工程での作業は、最終的なデバッグ、マーケティングや販促のための作業である。

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

制御[編集]

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

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

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

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

名称[編集]

その名称はスポーツのラグビーでのスクラムに因んでいる。

参考文献[編集]

関連項目[編集]

外部リンク[編集]