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

この項目では、ソフトウェア開発における用語について説明しています。本義のスクラムについては「スクラム (ラグビー)」をご覧ください。

プロダクト開発におけるスクラム（英: scrum）は複雑な問題への適応型ソリューションをチームで開発し価値を生み出すための軽量級フレームワークである^[1]。

概要[編集]

複雑な問題に対する完璧なソリューションを1度で実現することは難しい。異なるアプローチとして、不完全なソリューションを素早く出しそこから学び改善する、適応型ソリューションがある。適応型ソリューションをチームで開発するために従うべき少数の規則・軽量フレームワークがスクラムである。スクラムはソリューション開発のフレームワークであるため、その目的は開発したソリューションを介して価値を生み出すことである。

スクラムは「問題に対する解決策を列挙」「高優先度の策を一定期間でチームで実行」「結果の検査に基づく調整」「その繰り返し」を実現できる環境を生み出すシンプルなアプローチである^[2]。スクラムのカギとなる基本原則は、プロジェクト開発の途中で、顧客は、要求や必要事項を変えられるという認識である。予想できない変更について、計画に基づく方法で対処することは、容易ではない。したがって、スクラムは経験に基づくアプローチを採用する。問題を十分に理解することも、定義することもできないので、現れた要求へ素早く対応するためのチームの能力を最大化することに集中する、というアプローチである。

スクラムはチームが自発的に組織だって行動することを可能にする。この自己組織化を実現するのは、すべてのチームメンバーが物理的に同じ場所にいること、あるいは密なオンライン共同作業を通じ、全員が日々直接会ってお互いにコミュニケーションをとり、プロジェクトにおける規律を守ることである。

背景[編集]

複雑な問題と適応型ソリューション[編集]

複雑な問題は難しい。もし1回で問題への完璧な解決策/ソリューションを提供できれば大きな価値を提供できる。しかし「完璧に計画されたソリューション」は往々にして不完全に終わる。そうでないやり方の1つが適応型ソリューション（英: adaptive solutions）である。すなわち最初は不完全だが段階的に学び改善されていくソリューションである。

ソリューション開発と目的[編集]

ソリューションの別名はプロダクトである。なぜならプロダクトは価値を提供する手段（ソリューション）だからである^[3]。例えばカップラーメンというプロダクトは空腹という問題を解決し満腹という価値を提供するソリューションである。プロダクトはあくまで手段であり、価値こそが目的である。

プロダクトは人の手によって開発される。プロダクトが手段ということは、プロダクト開発もまた手段である（手段を生み出す手段）。言い換えれば、ソフトウェア開発は出力（output）としてプロダクトを生み出し、プロダクトは利用された成果（outcome）として価値を生み出す。スクラムはソリューション/プロダクト開発の方法論である^[4]。ゆえにスクラムの目的は（ソリューションを生み出すことではなく）生んだソリューションを介して価値を生み出すことである^[5]。

軽量フレームワーク[編集]

適応型ソリューションを開発するために厳密で重厚なプロセス・手法を用意することも可能だが、スクラムは異なるアプローチをとる。スクラムは最低限で軽量な工程の枠組み（プロセスフレームワーク）のみを提供する^[6]。すなわちスクラムは開発の流れ、ポイントとなるイベントのみを定義する^[7]。実際のソリューション開発ではスクラムフレームワークに則った上で全体の具体的手順を構築する。このようにスクラムは軽量級フレームワークである。

歴史[編集]

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

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

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

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

スクラムは適応型ITソリューションすなわち適応型ソフトウェアを開発する（ソフトウェア開発）ために発明され、のちにアジャイルソフトウェア開発手法の1つに分類された。現在ではソフトウェアに限らずあらゆる適応型ソリューション/プロダクトの開発に適用される^[12]。

背景理論[編集]

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

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

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

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

検査[編集]

検査（英: inspection）は現状把握、すなわち目標と現状の比較・評価である。検査により開発の進行に伴う変化・問題を検出する^[15]。検査の目的は適切な方向への適応である^[16]。目標が示されていないと比較対象がいないため、十分な検査がおこなえない（例: 発生した問題は検査できても方向性のズレに気づけない）。ゆえに目標の透明性が良い検査の前提となっている^[17]。PDCAサイクルの Check 段階に相当する。

スクラムチーム[編集]

スクラムチーム（英: Scrum Team）はスクラムの基本単位となる小さなチームである^[18]。

スクラムチームはスポーツチームのように機能しなければならない。各メンバーは高い専門性を持ちながら自らのポジションに拘泥せず、1つのゴールを目指し全員が1つのチームとして協力する。つまり専門分野（例: マネジメント、エンジニアリング、デザイン）をもつ様々なプロフェッショナルが分野にとらわれず、1つのプロダクトゴールへ焦点を合わせプロダクト開発を行うチームがスクラムチームである^[19]。

スクラムチームはプロダクトゴール達成に必要な全ての活動を責務とする（必要な権限とそれを行使する責任を持つ）^[20]。すなわち開発において、どのメンバーが何（what）をいつどのように（how）行うかはスクラムチーム自身が決定し自己管理する^[21]。価値ある成果物を生み出す（プロダクトゴールを達成する）ことに関して、チームとしてステークホルダーに対する説明責任を負う^[22][23]。

スクラムチームは適応型プロダクトを開発する。ゆえに適応に必要な速度を担保できるサイズの小ささが必要であり、1チーム10人以下が推奨される^[24]。

スクラムチームには以下の3つの明確な役割・責任が定義される。

プロダクトオーナー[編集]

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

スクラムマスター[編集]

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

開発者[編集]

開発者（英: Developer）は各スプリントにおいて、利⽤可能なインクリメントの あらゆる側⾯を作成することを確約する役割を担う。開発者が必要とする特定のスキルは、幅広く、作業の領域によって異なる。

方法論[編集]

スクラムは経験主義（透明性・検査・適応）を実現するために、以下の作成物とイベントを定義する^[25]。これらのフレームワークに則ることでチームとプロダクトの透明性が向上し、正しい検査が定期的におこなわれ^[26]、素早い適応がおき、良いプロダクトが生み出される。

スクラムの作成物は1つの確約（英: commitment）をもつ。目標たる確約を明示することで進捗測定すなわち検査が可能になる^[34]。プロダクトバックログにおけるプロダクトゴール、スプリントバックログにおけるスプリントゴール、インクリメントにおける完成の定義がそれぞれ検査基準となる確約である^[35]。確約はプロダクトの理想状態を示しており、開発者にこの達成を求める（ゆえに検査される）。プロダクトそのもの状態を明示された検査対象とすることで、逆説的に、スクラムは開発過程の大きな自由度を開発者にもたらしている^[36]（「この状態が目標だ、完成度を検査する。作り方は君に任せる」という方式、ミッション・コマンド）。

プロダクトゴール[編集]

プロダクトゴールはプロダクトの将来の状態である^[37][38]。すなわち将来のプロダクト利用が生み出すべき価値である。ゴールは評価可能であり、全員に共有され、一度に1つのみ設定される。

プロダクトゴールはプロダクトの目標である。これによりスクラムチームはプロダクトゴールの実現を目標として計画を立案できる^[39]。プロダクトゴールは評価可能である^[40]。これによりプロダクトの進捗が検査可能になり、プロダクトが適応できる^[41]。プロダクトゴールはチームとステークホルダーに共有される^[42]。これによりチームは提供すべき価値を把握して「なぜ（why）これを開発するのか」を理解でき、目的意識を持った自律的な開発が可能になる^[43]。プロダクトゴールは一度に1つのみ設定される。これによりチームは単一のゴールへ向け集中できる^[44]。

例えばタクシーサービスが掲げる「顧客は平均7分でタクシーを捕まえられる」は定量評価可能なユーザー体験であり、プロダクトゴールに相応しい。

プロダクトバックログ[編集]

プロダクトバックログ（英: Product Backlog）はプロダクトが目指す姿とそうなるための要素の一覧である。プロダクトバックログはプロダクトゴールとプロダクトバックログアイテムからなる^[45]。

プロダクトバックログアイテム（PBI）はプロダクトゴールを達成する「何か（what）」の定義であり、理想形に必要な要素を示す。PBIはコストと顧客価値が見積もられ優先順位をもつ。プロダクトに対する要求は常に変化する。例えば変化を引き起こす物事としてプロダクトの利用・成長、市場からのフィードバック、ビジネス要求・環境の変化、技術の登場などがある^[46][47]。プロダクトに対する要求の変化に対してプロダクトバックログは「適応」する。すなわちプロダクトバックログの項目は要求の変化に応答して変化する。プロダクトバックログを更新していくことで、製品は常に適切で競争力をもち便利な方向へ開発されていく^[48]。

プロダクトバックログの最終的な決定と責任はプロダクトオーナーにあり尊重される。そこに至るまでのバックログへの関わり方（オーナー主体かチーム取り組みか）はプロジェクト次第である^[39]。またPBIがもつべき具体的項目は各プロジェクトごとに定義される（スクラムはあくまでフレームワークである）^[45]。

プロダクトバックログリファインメント スプリント期間中、チームはプロダクトバックログの健全性を保つための会議を開く。プロダクトバックログの健全性を示す指標として、INVESTが用いられることが多い。

インクリメント[編集]

インクリメント（英: Increment）はプロダクトゴールへの一歩となる、具体的な成果物である^[49]。インクリメント（増分）を積み上げていくことで理想形のプロダクトが実現する。インクリメントの原料はPBIである。いわばアイデアであるPBIを開発者が実装することでインクリメントとなる。作業中の途中産物はインクリメントではなく、"完成の定義"を満たした段階でインクリメントとなる^[50]。インクリメントはリリース可能である^[51]。

完成の定義[編集]

完成の定義（英: Definition of Done）はPBIの完成品が満たすべき品質基準である。

スプリント[編集]

スプリントはアイデアを価値に変換する、すなわち実際に開発が行われる工程である^[52]。

スクラムは適応型プロダクトを開発する。つまりプロダクトは短期間で開発・実践投入・学習・適応を繰り返す必要がある。開発工程として計画・開発・日次見直し・レビュー・調整を含んだ一定期間の区切りがスプリント（英: Sprint）である。スプリントを設定することでプロダクトが目標とする価値へ定期的に適応するように誘導される^[53]。素早い適応のためにスプリント長は1ヶ月以下に設定される^[54]。

スプリント内では、決まった順序は存在しない。必要に応じて、プロダクトバックログの項目を開発し、まとめ、レビューする。また、項目によっては、単にレビューと調整だけで済む場合もある。どのように開発されるかは、そのバックログ項目の内容によるが、プロダクト全体として、インクリメンタル／イテレーティブに開発されることが多い。

スプリントでは検査と適応のために以下の4つのイベント（プロセス）を組み合わせて用いる^[55]。

• スプリントプランニング: スプリント期間の最初に行われる。スクラムチームでスプリントバックログを生成する。この過程でチームメンバー間の認識差異がないことを最終確認する。

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

• スプリントレビュー: スプリント最終盤にはスプリントレビューが行われる。このプロセスではスプリント成果の検査と適応をおこなう^[57]。すなわち生み出されたプロダクト/ソリューションが目標とする価値（プロダクトゴール）を実現しているかレビューする。インクリメントを中心にプロダクトが評価され、必要に応じてPBIが追加・変更される。このレビューには顧客・プロダクトオーナー・開発者（場合により営業・マーケター）が参加する。レビュー対象はインクリメントであり、未完で終わったPBIは含めない（ソリューション評価にならないため）^[58]。

• スプリントレトロスペクティブ（振り返り）: スプリント終了時には振り返りが行われる。このプロセスでは開発工程の検査と適応をおこなう。スプリントで発生した問題とその改善策などを検討し、必要に応じてプロセス改善のPBIを追加する。

スプリントではPBIがインクリメントへ実装される。インクリメントは完成の定義を満たしリリース可能な状態にある。ゆえにスプリントの途中、スプリントレビューより前の段階でデプロイされうる^[59]。デプロイ判定（受け入れテスト）は"完成の定義"でなされるべきであり、スプリントレビューが障害物となって適応を遅くする事態を招いてはいけない^[60]。

スプリントバックログ[編集]

スプリントバックログはスプリントの計画である^[61]。このスプリントで実現したい成果（スプリントゴール）、そのために必要なPBI、PBIを生成する手順計画からなる^[62]。スプリントバックログはデイリースクラムで進捗を検査可能な程度の詳細度が必要である^[63]。スプリントプランニングで生成され、状況の変化に応じて適応する^[64]。

スプリントゴール[編集]

スプリントゴールはスプリントがプロダクト改良を通じて提供する価値の目標である^[65][66]。スプリントの目的はスプリントゴールそのものである^[67]。作られるプロダクト（what）やプロダクト開発手順（how）のみでなく、生み出したい成果すなわち価値（why）に注目するためにスプリントゴールは設定される^[68]。状況の変化により設定されたスプリントゴールがもはや役に立たなくなった場合、そのスプリントは中止される^[69]。

組み合わせ技法[編集]

スクラムは工程の枠組み・フレームワークである。すなわちスクラムの上に具体的なプロセスを配置し完成形のシステムとなる。ゆえに様々な技法・プロセス・パターンをスクラムとともに採用できる^[70]。以下が技法の例である。

1. テスト駆動開発
2. 受け入れテスト駆動開発（英語版）
3. リファクタリング
4. 継続的インテグレーション
5. ユーザーストーリー: 顧客要望の対話的分析、プロダクトゴール・スプリントゴールの表現

開発工程というブラックボックスを管理可能にする手法がある。結果を分析することで、プロジェクトマネージャは何らかの意思決定を行う。例えば、

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

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

ベロシティは前回スプリントで達成したプロダクトバックログの相対見積り合計である。

プロダクトゴール設計[編集]

スクラムはプロダクトゴール達成を唯一の目的とし、優れたソリューション/プロダクトの開発を可能にする。しかしその前提として、プロダクトゴールすなわち提供する価値の質はすべてを左右する。価値のないプロダクトゴール（無価値な価値）を達成する完璧なプロダクトが完成しても、それは価値を生み出さない^[71]。そのため良いプロダクトゴールを設計する様々な技法がスクラムフレームワークと共に採用されうる。

プロダクトゴールはしばしばプロダクトのビジョン（英: Vision）から演繹される。プロダクトのビジョンは企業が掲げる理想像である。プロダクトは徐々に改善されながらビジョンへ向かうため、いくつもの状態を経ることになる。プロダクトゴールはその1つ1つの状態に対応する^[72]。

提供すべき価値が不確かな段階ではプロダクトゴール自体を探索する必要がある（c.f. 商品開発）。その場合、適応的な価値探索をおこなう。プロトタイピングを通してMVPを作成し価値を探索する。リーンスタートアップはそれを実現する方法論の1つである。プロダクトマネジメントは価値探索から開発までを含んだマネジメントである。

プロダクトゴールが不確かな場合、プロダクトゴールを設定すること自体が意味を持つ。なぜならプロダクトゴールのもつ特性（長期目標・単一・可測・公開）は具体的であり、ステークホルダーとの議論を中身あるものにするからである^[73]。

プロダクトゴールの最終決定はプロダクトオーナーの責務である。その過程でスクラムチームを巻き込むことは現場の感覚・知恵を取り入れまたチームの更なる自己管理を促進する意味で有意義である。ゴールは達成すべき目標であるが、実際にユーザーが手にするのは開発されたインクリメントの総体たるプロダクトである。

参考文献[編集]

• 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。 

関連項目[編集]

• Dynamic systems development method（英語版） (DSDM)
• ユーザ機能駆動開発 (FDD)
• エクストリーム・プログラミング (XP) - 複数あるXPのプラクティスの一部を、スクラムと組み合わせて使われることが多い
• en:Comparison of Scrum software -スクラム（ソフトウェア）の比較（英語）

脚注・出典[編集]

外部リンク[編集]

• Agile business Institute
• SCRUMワークショップ体験記 @IT 情報マネジメント
• Scrum （有）メタボリックス
• Implementing Scrum
• Scrum Alliance
• Scrum et al - Google Techtalk with Ken Schwaber（ビデオ）
• Scrum in five minutes
• Scrum articles directory
• Agile Alliance's Scrum library
• InfoQ.com / Agile
• Tackle - a web-based Scrum Tracking Tool
• スクラムチュートリアル（オンライン）