スクラム入門

SCM の再認定とスクラムを再勉強するため執筆した。

スクラムとは

  • スクラムとはアジャイル開発の中で最も広く認知されている手法の一つ。問題解決と顧客への価値提供 という大きな本質がある。
  • スプリント と呼ばれる一区切りの時間を設定し、一般的に2週間（1週間〜4週間で設定可能）タスクを遂行する。スプリントを継続して実施し、改善し続ける。
  • スクラムでは MVP （最低限必要なプロダクト） の開発からはじめ、開発を積み重ねてゆく。顧客やステークホルダーに対する提供する価値を徐々に高めてゆく。
  • スクラムでは書類作成などは一切行わず、顧客中心で価値を素早く提供することに重きを置き、繰り返し成果物の提供に重きを置く。
  • レトロスペクティブ とよばれる振り返り活動で、次のスプリントに移る前に改善を実施する。
  • スクラムでは顧客への提供価値のことを ユーザーストーリー と呼ぶ。

スクラムの歴史

スクラムの歴史は、野中郁次郎氏と竹内弘高氏による1986年に発表されたハーバードビジネスレビュー（HBR）の記事「新たな新製品開発競争（The New New Product Development Game）」に掲載された所から開始された。

1993年、Easel Corporation の Jeff Sutherland と彼のチームは、1986年の記事の概念をオブジェクト指向開発、経験的プロセス制御、反復型開発、増分ソフトウェアプロセスの概念と組み合わせることで、ソフトウェア開発プロセスで使用されるスクラムプロセスを作成した。

アジャイルとスクラムの位置付けについて

Aglie Framwork

  • リーン: アジャイルとカンバンの属性を共有する上位概念で 価値の提供、人間の尊重、ムダを最小化、透明化、変化への適応、継続的な改善に注力する ことである。つまり、組織やチームにとって有益なものは何でも実行し、使用するアプローチが何かに関わらず、最高の成果を上げることが目的である。
  • カンバン方式: リーン方式に触発されソフトウェア開発の場面では2000年代半ばに、当時流行していたアジャイル方式への代替として出現した。なお、カンバンはトヨタの生産方式が元となっている。カンバンは視覚的に業務管理を行う手法である。
  • アジャイル手法: アジャイルは2001年に、ソフトウェア業界の思想的リーダーは アジャイルソフトウェア開発宣言 を提唱した。なお図では 様々なフレームワークと方法を対象とする包括的用語 として記載している。
  • スクラム: スクラムはアジャイル手法の一つとして提唱された手法である。
アジャイルソフトウェア開発宣言

私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。

プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、

価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。

スクラムとウォーターフォールの違い

比較表
スクラム ウォーターフォール
目的 価値を重視した迅速なデリバリー
顧客中心主義		 要求事項を中心とした長期的なデリバリー
ビジネス中心主義
実施方法 反復的 連続的
スコープ 可変・交渉可能 固定
改善方法 改善のための継続的な反省 プロジェクト終了時に得られる教訓
テスト方法 頻繁なテスト フェーズ中のテスト
役割 役割が曖昧 定義された役割の人々
具体的な違いについて
  • スクラムでは「顧客と価値を重視した迅速なデリバリーすること」が特徴だが、ウォーターフォールは一般的に長い時間をかけてプロダクトをデリバリーし、顧客や価値よりも「ビジネスや要件定義を優先する」。ウォーターフォールでは要件定義やビジネスにおける目標を重視し、そのために期間や予算の摺り合わせを行う。スクラムでは要件定義を行うものの、反復的にプロダクトを提供する。
  • スクラムではあるプロダクトを作ると、それを改善していき、より良いプロダクトになるように継続的に改善を重ねる。一方ウォーターフォールは直線的に「A」「B」「C」といったフェーズで別れる。計画・テスト・デリバリーを行う。これらは各工程を順番に行う。
  • スクラムではスコープは変更と交渉可能なため、仕様を確定させることは難しくなる。また、変更すべき点があれば交渉し、改善していく必要があるためステークホルダーとの対話が重要となる。一方ウォーターフォールではスコープは確定しており、基本的に変更は出来ない。変更が必要となる場合は、変更依頼や経営陣から承認を受ける必要がある場合もある。ウォーターフォールではプロジェクト開始時に同意した仕様に則るため、変更を受け入れる場合が少ない。
  • スクラムでは改善のため変更を積極的に受け入れる。顧客、エンドユーザー、チーム内で改善方法や別の方法は無いか絶えず議論を行う。一方ウォーターフォールではプロジェクトの最後に振り返りを行い、そのプロジェクトから学んだ教訓を他のプロジェクトに活用させる。この場合、プロジェクト期間中に問題が発生した場合、作業の改善や追加機能の実装が出来る可能性がある。なお、スクラムではスプリントの一環として振り返りを行う。そしてその内容を次のプリントで反映させる。
  • スクラムでは何度もテストを繰り返し実行するが、ウォーターフォールでは校庭ごとにテストを行う。スクラムでは継続して何度もテストを行い、継続的な変化と改善をもたらす。全てにおいて絶えず改善を行っていく。
  • スクラムでは スクラムマスター プロダクトオーナー 開発チーム の役割で構成される。スクラムではさまざまな役割を流動的に担当し、チームで協力し役割を超えて一緒に働く。ウォーターフォールでは役割は決定的でいつも同じ役割となる。

スクラムチーム（スクラムの役割）

  • スクラムマスター
    • スクラムの知識があり、ビジネスにおいてスクラムを推進し調整を行う人のこと。またスクラムチームのチームの目標達成のためにサポートを行い、作業の妨げになるものを取り除く役も担う。デイリースクラムやレトロスペクティブといった様々なイベントにも参加する。
    • 従来のリーダーとは異なる点は、チームに指示の作業を出すのではなく、チームの作業をサポートし、チームの作業の障害を取り除くという役割であること。チームに足りない物を確認し、時間内・予算内にプロジェクトを遂行できるよう調整する。また、各イベントを規律正しく進められるようサポートする。
    • 作業の優先順位を確認し、フィードバックを受ける。また顧客の声を代弁するプロダクトオーナーやその他関係者との情報交換を行い、常にチームの状況を共有する必要がある。
    • スクラムマスターはチームを常に改善し続け、常に作業を反復し遂行し続けられるように調整し、スプリントを繰り返しながらチーム全員で目標達成を目指す。
  • プロダクトオーナー
    • プロダクトオーナーはスクラムマスターや開発チームと連携しチームの作業の優先順位を管理する。優先順位は顧客のニーズに基づくため、プロダクトオーナーは顧客側に立つビジネスサイドの担当者がつくことが多い。
    • プロダクトバックログの管理も担当し、チームが共有すべき情報や作業の優先順位など最新の状態に保つ責任がある。顧客が何を求めているかなどの情報を正確に把握し、チームがやるべきことを明確にする。
    • 作業目標や予算、日程といった変更事項や、作業の変更が生じた場合は経営陣と交渉を行う。
    • プロダクトオーナーとスクラムマスターは役割が異なるため、兼任すると負担が大きく、利害の衝突につながる可能性があるため。別の担当となる必要がある。
    • プロダクトオーナーはチームの作業の優先順位や集中すべきことの決定における役割を担う。
  • 開発チーム
    • チームの残り全員が担当する。スケジュールに送れず、予算内に確実な成果を出すために目標や目的に沿って作業を進める。
    • 一般的に、開発チームの人数は3〜9名で開発担当者以外に、デザイナーやITアーキテクトや、プロジェクトマネージャーがスクラムマスターを兼任して参画することもある。

スクラムイベント（スクラム構成要素）

Scurm Workflow

  • スクラムを試験的に始めるのであれば、パイロット版の開発を行う。5人のプロジェクトで短いスプリントを実施し、最初から完璧を目指さない。
  • スプリント は短い期間で結果を素早く確認および継続的に改善し、プランニングを見直す。
  • スプリントはイテレーションと同義で、タイムボックスの期間を表す。また成果物という意味の インクリメント という言葉があり、スプリントではインクリメントを提供します。スプリントは最終的な成果物としてインクリメントを提供する。
  • スクラムはプランニングと改善を反復して継続する。スクラムではこれを レトロスペクティブ で実施する。その他、プロジェクトの改善に向けた、失敗や改善点を学ぶ話し合いは PIR または 導入後レビュー と呼ばれ実施される。
  • また、改善点の把握には カンバン のようなツールを活用したり、 バーンダウンチャート や ベロシティチャート を利用することもあります。

用語集

5つのスクラムイベント

スプリント
  • 一区切りの時間を設定し、一般的に2週間（1週間〜4週間で設定可能）タスクを遂行する期間。プロジェクトはスプリントを継続して実施し、改善し続ける。
スプリントプランニング
  • プロダクトバックログからスプリントに落とし込むために、タスクを分解し、そのタスクを可視化するための作業
  • 大枠の流れとして POとプロダクトバックログの確認 プロダクトバックログの作成とPOの合意 が行われます。
デイリースクラム
  • 毎朝スプリントの進捗確認を行うミーティング。今日やることや困っていることなどの問題確認を行う。問題解決は行わず、15分以内で終了する。
スプリントレビュー
  • スプリントの成果物をステークホルダーに示し、フィードバックを得るためのスプリントの最後に実施する。今後のスプリントの進め方について話し合い、プロダクトバックログを調整する。
レトロスペクティブ（振り返り）
  • スプリントの最後に行う改善ポイントを振り返るために実施する。KPTと呼ばれる方法で実施することが多く、スクラムチームの改善を継続的に行う。

3つのスクラム成果物

プロダクトバックログ
  • プロダクトを作成するにあたっての要求事項を順番に並べたリスト。スクラムではリストの上から順番に終わらせていく。一般的にはビジネス価値の高いものが上位に来る傾向にある。
スプリントバックログ
  • スプリントで実施するプロダクトバックログ項目のサブセットと、それを分析し具体的なタスクに落とし込んだもの。 プロダクトバックログでは通常、実装に関する記述をおこなわないが、スプリントバックログは開発チームがそのスプリントを完成させるために必要な作業であるため具体的に記述する。
インクリメント
  • 完成の定義を満たしており、リリースしようと思えばリリースできるプロダクトのこと。

参考文献