こんにちは、@yamakenjiです。
仕事でスクラムを組んでチーム開発を行っていくため、
アジャイルとスクラムの全体像を把握し、いつでも振り返れるように自分用のメモとして残しておくことを目的とします。

アジャイル開発、スクラムとは？

アジャイル開発とは、ソフトウェア開発手法の一つです。
目的に対して計画を行い、設計や開発、テスト、レビューを細かく定期的に行うことで仕様変更や修正に手戻りを最小限にし、
プロダクトの価値を最大限に提供することを目的としています。 アジャイルソフトウェア開発宣言

スクラムとは、アジャイル開発の一つの方法です。
複雑な問題に対応する適応型のソリューションを通じて、⼈々、チーム、組織が価値を⽣み出すための軽量級フレームワークです。スクラムの定義
スクラムでは、最低限のルールだけで構成されているため、各スクラムチームごとの状況に応じて、それぞれ適用できそうなルールややり方を導入していくこともできます。

スクラムチームとそれぞれの役割

スクラムチームは主に「プロダクトオーナー」「スクラムマスター」「開発メンバー」の3つの役割から構成されています。

• プロダクトオーナー(PO)：プロダクトの責任者。プロダクトの価値の最大化に責任があり、プロダクトバックログの管理やステークホルダーとの協業などを行う
• スクラムマスター(ScM)：スクラムが円滑に機能することに責任がある。障害を取り除いたり、支援を行ってスクラムがうまく回るようにサポートする
• 開発メンバー：プロダクトのインクリメントを提供することに責任がある。チームは、プロダクトを作るために必要な作業は全て行う必要があり、 能力に差があっても個人が複数のことをできるようになることが望まれる

プロダクト・バックログ

プロダクト・バックログとは、機能や要求、要望、修正など、プロダクトに必要なリストのことであり、
「どういうことを実現したいか(ゴール)」「絶対に達成したいことは何か」をもとに作成されます。

リストは、実現したい順に並び替えられており、得られる価値やリスク、必要性などによって決定します。
開発メンバーは順番が上位のものから開発を行います。
また、日々ゴールを意識する必要があり、ゴールに近く/達成するためにどういう作業が必要か/優先すべきかを考える必要があります。 そのため、プロダクト・バックログはチームの合意のもと、並び替えたり追記することが可能です。

プロダクト・バックログの見積もりは、「PO」が「後どれぐらいの作業量が残っているか」「これまでの結果をもとに何時ごろ終わりそうか」などを知るために開発チームが行います。

スプリント・バックログ

スプリント・バックログとは、スプリント期間中のスプリントゴールに対しての実現方法のリストです。
スプリントゴールは、プロダクトバックログから選択し、「本スプリントでどのような価値を提供できるか」を開発チームが約束する物です。 スプリントゴールを達成するために、どのような作業が必要かを表したのがスプリント・バックログアイテムです。 個々の作業は1日以内で終わるサイズを目安に分割します。具体的にしておくことで、「完成の定義」を明確にし、作業の管理がしやすくなります。

スプリント・バックログの見積もりは、選択したプロダクト・バックログに対して、 「どれぐらいの作業量が存在するか」「いつぐらいまでに終わりそうか」などを開発チーム目線で把握するために行います。 見積もり数は、一定間隔でスプリントを回していくことで、チームが各スプリントで達成できる作業量の見積もり精度が高くなり、見通しが良くなります。

スクラムイベント

デイリースクラム

デイリースクラムは、毎日同じ時間、同じ場所で開発チームが集まって、現在のスプリントバックログをもとにスプリントゴールが達成できるかを話し合います。
人数が少なかったり、進捗が遅れていたとしても、デイリースクラムの時間は延長せず、毎回決まったタイムボックスで行います。
ただの進捗報告会ではなく、スプリントゴール達成の障害になる問題を発見し、作業の見直しや再計画を早期に行い、スプリントゴールを達成することが目的です。

スプリントレビュー

スプリントレビューは、スプリントの最後にステークホルダーに対して、スプリントの成果物をデモを行い、プロダクトゴールに対する進捗を確認します。 レビュー時には、以下のようなことを共有します

• 未完成・完成したプロダクトバックログ
• スプリントでうまくいかなかったことや問題点、解決方法の共有・議論
• プロダクトバックログに追加すべき項目の議論
• 今後の見通し また、スプリントの成果と検査を参考に、プロダクト・バックログの調整を行ったりします。

スプリントレトロスペクティブ

スプリントレトロスペクティブでは、直近のスプリントに対してうまく行ったことやうまくいかなかったこと、今後の改善点などを整理します「KPT」。 うまくいかなかったことは、「なぜうまくいかなかったのか」の背景やプロセスなどを見直して根本に着目します。 振り返りを定期的に行うことで、次回以降のスプリントの品質や効果を高め、チームがよりよく仕事を進めれるようになります。

最後に

スクラムとは、プロダクトに関わる人間全員が、短い期間で定期的に共有・議論・振り返りの場を設け、より良いプロダクトを提供できるように改善を繰り返すことということがわかりました。 特にリモートワークが中心となった近年では、デイリースクラムは定期的に行うことで、誰がどのタスクを行っているのか、進捗は順調か、メンバーの体調はどうか、などを把握することができます。
アイテムに対する見積もりは、「作業時間」ではなく「作業量」で見積もるというところも面白かったです。 チームで、「誰かが抜けても進めるように」というところで、個人の力量に依存する作業時間ではなく、作業量では相対的に見積もれるというところがポイントなのかなと思いました。
また、開発チーム全体で合意を取るところと、役割分担して責任を移譲するというバランスも開発を進めていく上で、つかめたらなと思います。

参考

スクラムガイド2020
SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発
アジャイルソフトウェア開発宣言