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

出典: フリー百科事典『ウィキペディア(Wikipedia)』
ナビゲーションに移動 検索に移動
ソフトウェア開発
中心となる活動
パラダイムとモデル
方法論とフレームワーク
開発支援
プラクティス
ツール
標準と機関
用語集

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

スクラムは工程の枠組み(process framework)であり、工程や技法ではない[1]。大枠としてスクラムを採用しさらに各工程において特定の技法を利用する、といった利用法になる[2]。例えばスクラムを採用した上で設計・実装・テスト工程の手法としてテスト駆動開発を採用する、といったことが可能である。

スクラムでは開発プロジェクトを数週間程度の短期間ごとに区切り、その期間内に分析、設計、実装、テストの一連の活動を行い、一部分の機能を完成させるという作業を繰り返しながら、段階的に動作可能なシステムを作り上げる。スクラム開発における反復の単位を「スプリント」という。

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

歴史[編集]

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

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

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

スクラムの定義と解説はスクラムの創設者Ken SchwaberとJeff Sutherlandによる「The Scrum Guide」にまとめられており[6]、スクラムの改良に伴ってこのガイドも更新されている。

背景理論[編集]

スクラムは経験主義に基づいている。スクラムでは、小さい実践を繰り返して経験を生みその経験に基づいて判断し知識を得ることで、製品の将来をより正確に予測し不確実性を制御できるという哲学をもっている[7]。これは綿密かつ巨大な計画で将来を事前に見通そうとする態度と対比される。

この哲学に基づいた実践をおこなうために、スクラムには3つの柱がある[8]

  • 透明性/transparency
  • 検査/inspection
  • 適応/adaptation

スクラムでは透明性によりチーム全体に現状が正しく共有され、製品が頻繁に検査されて異常が素早く見つかり、それに適応して製品・プロセスが修正されることを期待する。これが実現できればチームへ経験が蓄積し、製品はより良い方向へ向かう。

スクラムの方法論はこのような背景理論に基づいて構築されている。

方法論[編集]

技法[編集]

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

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

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

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

バックログ作成[編集]

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

プロダクトバックログ
製品に必要な要素を項目に起こした一覧。バックログを整理して上下関係で優先順位を表す。各項目はチームによって相対難易度(コスト)の見積もりを付けられ、プロダクトオーナーが顧客観点からの価値を見積もる。スクラムチームによって上位項目は詳細化される。
製品に対する要求は常に変化する。例えば変化を引き起こす物事として製品の利用・成長、市場からのフィードバック、ビジネス要求・環境の変化、技術の登場などがある[9][10]。製品に対する要求の変化に対してプロダクトバックログは「適応」する。すなわちプロダクトバックログの項目は要求の変化に応答して変化する。プロダクトバックログを更新していくことで、製品は常に適切で競争力をもち便利な方向へ開発されていく[11]
スプリントバックログ
スプリント(後述)の開始時、そのスプリントで実現する仕様をまとめたもの。スプリント完了時に、コーディング/テスト/ドキュメンテーションが完了していることを要求される。スプリントバックログはプロダクトバックログを管理可能な単位に細分化したもので、通常1つの項目を、プロダクトバックログと同じ相対難易度か、スプリントバックログ独自の相対難易度か、慣れていない組織では8人時から16人時で完成できるように見積り、項目を分ける。

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

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

工程[編集]

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

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

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

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

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

スプリント[編集]

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

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

スクラム会議[編集]

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

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

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

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

振り返り[編集]

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

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

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

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

制御[編集]

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

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

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

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

参考文献[編集]

  • Ken Schwaber and Jeff Sutherland. (2017). The Scrum Guide.
    • スクラム創始者によるスクラムの定義と解説
  • (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
  • 西村直人永瀬美穂吉羽龍太郎『スクラム・ブート・キャンプ・ザ・ブック――スクラムチームではじめるアジャイル開発』翔泳社2013年
  • 『アジャイルソフトウェア開発スクラム』ピアソンエデュケーション、2003年。ISBN 978-4894715899

関連項目[編集]

脚注・出典[編集]

  1. ^ Scrum is a process framework that has been used to manage work on complex products since the early 1990s. Scrum is not a process, technique, or definitive method. SCRUM GUIDES 2017
  2. ^ Rather, it is a framework within which you can employ various processes and techniques SCRUM GUIDES 2017
  3. ^ Takeuchi, Hirotaka; Nonaka, Ikujiro (Jan 1, 1986). “New New Product Development Game”. ハーバード・ビジネス・レビュー. https://cb.hbsp.harvard.edu/cbmp/product/86116-PDF-ENG 2017年8月24日閲覧。. 
  4. ^ a b 伊藤真美 (2013年2月1日). “「実践知リーダーシップとアジャイル/スクラム」-野中郁次郎氏が国内最大のスクラムイベントで講演”. EnterpriseZine(翔泳社). 2017年8月24日閲覧。
  5. ^ a b c スクラム提唱者から学ぶ、チームの不幸を減らすたった2つの方法 (1/2)”. ITmedia (2011年4月13日). 2017年8月24日閲覧。
  6. ^ Scrum is defined completely in the Scrum Guide by Ken Schwaber and Jeff Sutherland, the originators of Scrum. SCRUM GUIDES 2020-08-16閲覧
  7. ^ Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach to optimize predictability and control risk. SCRUM GUIDES 2017
  8. ^ Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation. SCRUM GUIDES 2017
  9. ^ As a product is used and gains value, and the marketplace provides feedback, the Product Backlog becomes a larger and more exhaustive list. SCRUM GUIDES 2017
  10. ^ Changes in business requirements, market conditions, or technology may cause changes in the Product Backlog. SCRUM GUIDES 2017
  11. ^ Requirements never stop changing, so a Product Backlog is a living artifact. The Product Backlog evolves as the product and the environment in which it will be used evolves. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful. SCRUM GUIDES 2017

外部リンク[編集]