今回は、スクラムについて次の観点で説明します。
スクラムとは
スクラム（Scrum）とは、1990年代にケン・シュエイバー氏とジェフ・サザーランド氏によって作られたアジャイル開発手法の一つです。
この手法は、柔軟で自由度の高い日本発の開発手法をラグビーのスクラムに喩えて「Scrum（スクラム）」として紹介した、野中郁次郎と竹内弘高が1986年に出した「The New New Product Development Game」という研究論文がベースとなっています。
ケン・シュエイバー氏とジェフ・サザーランド氏によって書かれた「The Scrum Guide」を見ると、「スクラムは、複雑な問題に対する適応的な解決策を通じて、人々やチーム、組織が価値を生み出すのを支援する軽量なフレームワークです」と書かれてます。
なので、スクラムは、あくまでも軽量なフレームワークであり、個別具体的な内容については個々の組織やプロジェクトで考えて適用する必要があります。
スクラムを支える３つの柱
スクラムには、その背景に、小さな実践を繰り返すことで知識を得ることができ、それによって将来をより正確に予測し不確実性を抑えることができるという考え方があります。
この考え方を実践するためにスクラムには次の３つの支柱があります。
透明性（transparency）
「The Scrum Guide」では、透明性について次のように言及しています。
新たに発生するプロセスと作業は、作業を行う人々だけでなく、それを受け取る人々にも見える状態でなければなりません。
重要な意思決定は、3つの正式な成果物、プロダクトバックログ、スプリントバックログ、インクリメントに基づいて行われます。
透明性が低い成果物は、意思決定の価値を損なったり、リスクを高めたりする可能性があります。
そして、透明性は検査を可能にします。
透明性のない検査は、誤解を招き、無駄を生じさせます。
検査（inspection）
「The Scrum Guide」では、検査について次のように言及しています。
スクラムの成果物と合意された目標に向けた進捗は、望ましくない変化や問題を発見するために、頻繁かつ慎重に検査されなければなりません。
検査を助けるために、スクラムでは、スプリント、スプリントプランニング、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブといいう5つのイベントを発生させて検査のリズムができるようにします。
検査は適応を可能にします。
適応を伴わない検査は無意味と見なされます。
スクラムのイベントは、変化を促すように設計されているのです。
適応（adaptation）
「The Scrum Guide」では、適応について次のように言及しています。
製品を生産するプロセスが許容範囲を外れて逸脱した場合や、生成された製品が受け入れられない場合は、プロセスや生産するための資源を調整する必要があります。
その調整は、さらなる逸脱を最小限に抑えるために、できるだけ早く行われなければなりません。
関わる人々が権限を与えられていない、または自己管理ができていない場合、適応はより困難になります。
スクラムチームには、検査を通じて新しい情報を得た瞬間に適応することが求められるのです。
スクラムの構成要素
次の図は、スクラムの全体像を表したものです。
スクラムは、
- ３つの役割（ロール）
- ５つのイベント
- ３つの成果物
スクラムの役割
「The Scrum Guide」では、スクラムを構成する組織について次のように言及しています。
スクラムの基本単位は少人数のスクラムチームです。
スクラムチームは、1人のスクラムマスター、1人のプロダクトオーナー、そして3人から9人のデベロッパーから構成されます。
スクラムチームの中には、サブチームや階層は存在しません。
スクラムチームは、一度に1つの目標、すなわちプロダクトゴールに集中する専門家から成る統一されたチームなのです。
ここでは、スクラムチームを構成する３つの役割について説明します。
デベロッパー
「The Scrum Guide」では、デベロッパーについて次のように言及しています。
デベロッパーは、スクラムチームの中で、各スプリントにおいて使用可能なインクリメントを作成することに責任を持つ人々です。
デベロッパーに求められる特定のスキルは広範囲にわたり、作業する領域によって異なることが多いですが、開発者は常に次のことに責任を負います。
さて、デベロッパーの開発チームは、通常、３人から９人までで構成されます。
３人未満の場合、相互作用が少なかったり、個人のスキルに依存する場合が多くなります。
また、10人以上の場合、コミュニケーションコストが増えることによって開発の効率が落ちてしまいます。
開発チームは、仕様書の作成、IT基盤の構築、コーディング、テストなど製品を作るために必要なすべてのタスク（課業）を遂行できなければなりません。
これを機能横断的チームと呼びます。
それから、開発チーム内では、役職やスキルなどによる特定の肩書はありません。
開発チーム内での進め方は、開発チームのメンバーの合意のもとで決められ、外部からの指示で決められることはありません。
あくまで開発チーム全員で責任を持って作業を進めていきます。
これを自己組織化と呼びます。
開発チームで主体的に様々なタスクを遂行することで、自ら学び、開発チームの能力が継続的に向上していくのです。
プロダクトオーナー
「The Scrum Guide」では、プロダクトオーナーについて次のように言及しています。
プロダクトオーナーは、スクラムチームの作業から生まれる製品の価値を最大化する責任を負います。
また、プロダクトオーナーは、効果的なプロダクトバックログの管理にも責任を持ち、その内容には次のことが含まれます。
- プロダクトゴールを策定し、明確に伝えること
- プロダクトバックログアイテムを作成し、はっきりと伝えること
- プロダクトバックログアイテムを優先順位に従って整理すること
- プロダクトバックログが透明で、見える化され、理解されていることを保証すること
プロダクトオーナーは、合議制の委員会ではなく1プロダクトにつき1人です。
プロダクトオーナーが決めたことを他人が勝手に変えることはゆるされません。
プロダクトオーナー自身が決めることで、結果に対して責任を持てるようになるのです。
スクラムマスター
「The Scrum Guide」では、スクラムマスターについて次のように言及しています。
スクラムマスターは、スクラムガイドに定義された通りにスクラムを確立する責任を負っています。
なので、その役割は、スクラムチーム内および組織全体で、スクラムの理論と実践を理解してもらう手助けをすることです。
また、スクラムマスターは、スクラムチームの効果を上げる責任を負っています。
なので、その役割は、スクラムフレームワーク内でスクラムチームがその実践を改善できるよう支援することです。
スクラムマスターは、次のような方法でスクラムチームに奉仕します。
- チームメンバーに自己管理と機能横断的なスキルをコーチングする
- スプリントの進捗を妨げる障害を取り除く
- スクラムチームが完成の定義を満たす高価値のインクリメントを作成することに集中できるよう支援する
- すべてのスクラムイベントが実施され、前向きで生産的に進行し、時間枠内で行われるようにする
スクラムマスターは、製品をうまくつくれるようにプロダクトオーナーやデベロッパーを支える役割であり、管理責任を負うマネージャーではなりません。
なので、ある人がスクラムマスターとプロダクトオーナーを兼任してはなりません。
スクラムマスターとプロダクトオーナーの意見は、その責任により相反することがあります。
2つの相反する意見が1人の中に混在すると正しい意思決定ができなくなります。
スクラムのイベント
ここでは、スクラムチームを構成する5つのイベントについて説明します。
スプリント
「The Scrum Guide」では、スプリントについて次のように言及しています。
スプリントはスクラムの鼓動（heartbeat）であり、アイデアが価値に変わるところです。
スプリントは一貫性を保つために1週間から1か月以内の固定された期間で行われます。
前のスプリントが終了するとすぐに、新しいスプリントが開始されます。
スプリントプランニング、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブを含め、プロダクトゴールを達成するために必要なすべての作業はスプリント内で行われます。
スプリントの間には、次のことが守られます。
- スプリントゴールを危険にさらすような変更は行われない
- 品質は低下させない
- プロダクトバックログは必要に応じて改善される
- より多くのことがわかるにつれて、作業のスコープはプロダクトオーナーと共に明確化され、再交渉されることがある
スプリントは、1週間から1か月以内の固定された期間に区切って、繰り返し開発を進めます。
この区切られた固定の短い時間のことをタイムボックスと呼びます。
タイムボックスに区切って開発を繰り返すことによって、開発チームにリズムが生まれ、作業に集中できるようになります。
スプリントプランニング
スプリントを始めるにあたっては、まずスプリントで何を作るのか（What）、どのように作るのか（How）を計画する必要があります。
この計画のことをスプリントプランニングと呼びます。
スプリントプランニンは、1ヶ月のスプリントであれば8時間、スプリントの期間が短ければ、それに合わせて短くするのが普通です。
スプリントプランニンでは、次の2つのトピックを扱います。
- スプリントゴールは何か
まず、プロダクトオーナーが今回のスプリントで達成した目標、スプリントゴールを明確にします。
そして、そのスプリントゴールを実現するために完成させるべきプロダクトアイテムを選択します。 - どうやってプロダクトアイテムを実現するか
次に、開発チームが、プロダクトアイテムを実現するための作業を洗い出し具体的な計画を立てます。
プロダクトアイテムを実現するための作業一覧を、後述するスプリントバックログとしてまとめます。
スプリントバックログは、開発チームの作業計画であり、スプリントの期間中、自由に作業を追加したり削除したりすることができます。
デイリースクラム
スプリントプランニングが終われば、開発チームはスプリントゴールの完成に向けて作業を進めていきます。
スクラムでは、各スプリントバックログの作業担当者をあらかじめ決めず、作業できる人が都度タスクを選択して進めます。
そこで、このまま進めてスプリントゴールが達成できるのかどうかを毎日、同じ時間、同じ場所に開発チームのメンバーが集まって検査するイベントがデイリースクラムです。
デイリースクラムは、開発チームの人数に関係なく、15分間のタイムボックスで行い延長はしません。
スプリントレビュー
スプリントバックログのタスクが終わると、プロダクトオーナー主催で、スプリントの成果物をレビューするイベントを開催します。
これをスプリントレビューと呼びます。
プロダクトオーナーは、製品のステークホルダー（利害関係者）をスプリントレビューに招待し、製品に対するフィードバックを得るようにします。
スプリントレビューでは、通常、次のような報告や議論を行います。
- スプリントで完成しなかったプロダクトバックログアイテムについて説明する
- スプリントでうまくいかなかったことや問題点、解決した方法について議論する
- プロダクトオーナーが製品の状況やビジネスの環境について説明する
- プロダクトバックログに追加すべきプロダクトバックログアイテムの有無について議論する
- 製品の開発を進めるうえで問題となることについて議論する
- 現在の進捗を踏まえて、製品のリリース日や完了日を予測する
なお、スプリントレビューに使える時間は1ヶ月のスプリントであれば4時間、スプリントの期間が短ければ、それに合わせて短くするのが普通です。
スプリントレトロスペクティブ
スプリントレビューが終了したら、スプリントレトロスペクティブというイベントを開催して、スプリントでの製品開発において問題がなかったか、もっと成果を出すたにできることがないか検査します。
「The Scrum Guide」では、スプリントレトロスペクティブについて次のように言及しています。
スプリントレトロスペクティブの目的は、品質と効果を向上させる方法を計画することです。
スクラムチームは、個人、相互作用、プロセス、ツール、完了の定義などに関して、スプリントがどのように進んだかを検査します。
スクラムチームは、スプリント中にうまくいったこと、遭遇した問題、それらの問題がどのように解決されたか、または解決されなかったかを話し合います。
スクラムチームは、効果を改善するために最も効果的な変更を特定します。
最も影響力のある改善はできるだけ早く取り組まれ、次のスプリントのスプリントバックログに追加されることもあります。
スプリントレトロスペクティブはスプリントを締めくくるイベントで、1か月のスプリントの場合は最大3時間に制限され、スプリントの期間が短ければ、それに合わせて短くするのが普通です。
スプリントレトロスペクティブは、スクラムチームが学習し環境に適応（adaptation）するための重要なイベントなのです。
スクラムの成果物
ここでは、スクラムチームを構成する3つの成果物について説明します。
プロダクトバックログ
プロダクトバックログは、製品を改善するために必要な項目、プロダクトバックログアイテムを順序立てて記載した、漸進的なリストです。
プロダクトバックログは、優先順序の高いプロダクトバックログアイテムを上位に並べて作成します。
アプリケーションを開発するときは、アプリケーションのユースケースをプロダクトバックログアイテムにすることができます。
プロダクトバックログは、優先順序の高いプロダクトバックログアイテムを上位に並べて作成するので、アプリケーションのユースケースをプロダクトバックログアイテムにする場合、ユースケースの開発順序を設計する必要があります。
例えば、トランザクションデータは、マスターデータが前提となるので、「注文の登録」ユースケースなどトランザクションデータを登録するユースケースの前に、「顧客の登録」ユースケースや「商品の登録」ユースケースなどマスターデータを登録するユースケースを実現する必要があります。
なので、「顧客の登録」ユースケースや「商品の登録」ユースケースは、「注文の登録」ユースケースより先に開発する必要があります。
この場合、プロダクトバックログアイテムの優先順位は、「顧客の登録」ユースケース、「商品の登録」ユースケース、「注文の登録」ユースケースという順番になります。
スクラムチームは、1つのスプリント内で完了できるプロダクトバックログアイテムをスプリントプランニングイベントで選択します。
その際、プロダクトバックログアイテムの内容を精査する作業をします。
この精査作業をリファインメントと呼びます。
リファインメントでは、
- プロダクトバックログアイテムの内容を具体的にする
- プロダクトバックログアイテムに関する疑問点を解決する
- プロダクトバックログアイテムを自分たちが扱えるサイズに分割する
- プロダクトバックログアイテムの作業量を見積もり
などを行います。
プロダクトオーナーは、開発者に対してトレードオフを理解し選択する手助けをすることで影響を与えることができます。
プロダクトバックログには、製品の長期的な目標であるプロダクトゴールが設定されます。
プロダクトゴールは、スクラムチームが計画を立てる際の目標となる、製品の将来の状態を表します。
スプリントバックログ
スプリントバックログは、スプリントゴール（なぜ）、スプリントのために選ばれたプロダクトバックログアイテムのセット（何）、およびインクリメントを提供するための実行可能な計画（どのように）で構成されています。
スプリントバックログは、デベロッパーによって作成されるデベロッパーのための計画です。
スプリントバックログはスプリントが進むにつれて新しいことがわかるたびに更新されます。
スプリントバックログには、デイリースクラムで進捗を検査できる程度の詳細が含まれている必要があります。
スプリントバックログでは、スプリントゴールを設定します。
スプリントゴールは、スプリントにおける単一の目標です。
スプリントゴールはデベロッパーによるコミットメントですが、それを達成するために必要な具体的な作業については柔軟性を持っています。
スプリントゴールはチームの一体感と集中力を生み、スクラムチームが別々の取り組みではなく、一緒に働くことを促進します。
スプリントゴールはスプリントプランニングのイベント中に作成され、その後スプリントバックログに追加されます。
デベロッパーがスプリント中に作業を進める際には、常にスプリントゴールを意識しています。
もし作業が予想と異なる場合は、デベロッパーはプロダクトオーナーと協力して、スプリントゴールに影響を与えることなく、スプリントバックログの範囲を交渉します。
インクリメント
インクリメントは、プロダクトゴールに向けた段階的で具体的な成果物です。
各インクリメントは、それまでのすべてのインクリメントに追加され検証されます。
これにより、すべてのインクリメントが一緒に動作することが確実になります。
価値を提供するためには、そのインクリメントが使用可能である必要があります。
インクリメントは完成の定義を満たすものでなければなりません。
インクリメントが完成の定義を満たしていない限り、それはインクリメントとは見なされません。
完成の定義は、製品のインクリメントが要求される品質基準を満たしたときの状態を正式に説明するものです。
プロダクトバックログアイテムが完成の定義を満たした瞬間に、インクリメントが生まれます。
完了の定義は、インクリメントの一部としてどの作業が完了したかを全員に共有理解させることで、透明性を生み出します。
もしプロダクトバックログアイテムが完了の定義を満たしていない場合、それはリリースすることも、スプリントレビューで提示することもできません。
代わりに、それはプロダクトバックログに戻され、将来的に再検討されます。
インクリメントの完成の定義が組織の基準の一部である場合、すべてのスクラムチームはそれを最低限の基準として守らなければなりません。
デベロッパーは、完成の定義に従うことが求められます。
スクラムの5つの価値基準
最後にスクラムを活用して成果を出すための５つの価値基準について紹介します。
- 確約（Commitment）
それぞれの人がゴールの達成に全力を尽くすことを確約する - 勇気（Courage）
正しいことをする勇気を持ち、困難な問題を取り組む - 集中（Focus）
全員がスプリントでの作業やゴールの達成に集中する - 公開（Openness）
すべての作業や問題を公開することに合意する - 尊敬（Respect）
お互いを能力ある個人として尊敬する
スクラムチームは、単にフレームワークの内容を実行するだけでなく、これら5つの価値基準を踏まえて行動することで最大のパフォーマンスを上げることができるのです。
[…] アプリケーション開発 スクラムなどアジャイル開発の手法を適用して& […]
[…] 414;す。 継続的な改善は、スクラムのスプリント単位のデータドリブンŀ […]