スクラム開発とは？アジャイル開発との違いは？

こんにちはー！インディです。

本日は、スクラム開発ってなに？ということについて解説させていただきたいと思います。

というのも、今年から新しい企業に入社してお仕事をさせていただいているんですが、そこが結構ガチガチのスクラム開発をしているんですよねー。

僕は以前ちょっとだけスクラム開発をしたことあるんですが、ほんとに「なんちゃって」程度だったんですよね笑

なので、「スクラム開発って結局どういうこと？」「よくアジャイル開発というのも聞くけど、それとはどう違うの？」という初歩的なところから書籍と公式ガイドで学び始めました。

今回参考にした書籍、公式ガイドはこちら

SCRUM BOOTCAMP

スクラムガイド

公式ガイドの方が新しくて詳しいので、こちらを主に参考にさせていただいています。

ですが、SCRUM BOOTCAMPは実践的・体系的に書かれていて、漫画形式でわかりやすいのでこちらもおすすめです！

スクラム開発は、変化の激しいこの時代にマッチした素晴らしい開発手法だと思います。

この記事を読めば、スクラム開発をこれから取り組みたい！学びたい！と思っている方が、スクラム開発の全体像を掴むことができると思います。

また、それだけでなく、どんな思想・理論で成り立っているかまで理解することができるはずです。

それでは、スクラム開発の基礎を学んでいきましょう！

スクラム開発とは

アジャイル開発の手法の一つであり、「スクラム」というフレームワークを使用した開発手法のこと。

（引用：2019年ラグビーＷ杯準々決勝 vs南アフリカ）

アジャイル開発とは

プロジェクトを細かい単位に区切って進める開発概念のこと（agile =「俊敏な/素早い」）
「事前に全てのことを正確に予測し、計画することはできない」ということを前提にしている
メリット：仕様変更などにすぐ対応できる、サービスインまでの時間を早められる
デメリット：全体の進捗状況やスケジュールの把握が困難なこと、綿密な計画が必要

（参考）スクラム開発以外の手法例
- エクストリームプログラミング（XP）
    - 技術面に重きを置いたプログラマ中心の開発手法
    - 事前の計画よりも仕様や要件の途中変更への柔軟な対応を重視している
- ユーザー機能駆動開発（FDD）
    - 顧客にとっての機能価値を重視した開発手法
    - ユーザーのビジネスを見える化して必要な機能を洗い出し、適切な間隔で反復的にソフトウエア開発を繰り返す
- カンバン
    - カンバンボードを中心にタスクを整理しながら進める
    - スクラムとの違いは、時間やイベントに縛られておらず柔軟であること

スクラムの理論・特徴

理論

スクラムは「経験主義」と「リーン思考」に基づいている。
経験主義では、知識は経験から⽣まれ、意思決定は観察に基づく。リーン思考では、ムダを省き、本質に集中する。
（2020スクラムガイドより引用）

特徴

「経験主義」に理論を元にスクラム三本柱が作られている。
- 透明性
  創発的なプロセスや作業は、作業を実⾏する⼈とその作業を受け取る⼈に⾒える必要がある
- 検査
  スクラムの作成物と合意されたゴールに向けた進捗状況は、頻繁に確認されなければならない
- 適応
  やり方に問題があったりもっとうまくできる方法があれば、やり方そのものを変更する
要求を価値・リスク・必要性を基準に並べ替えて、その順にプロダクトを作って成果を最大化する
固定の短い時間（＝タイムボックス）に区切って作業を進める

5つの価値基準

スクラムが成功するかどうかは、次の5つの価値基準を実践できるかどうかにかかっている。
（メモ：僕は3C2Rで覚えました）

確約（Commitment）：それぞれがゴールの達成に全力を尽くし、互いにサポートしあうことを約束する
勇気（Courage）：正しいことをする勇気を持ち、困難な問題に取り組む
集中（Concentration）：全員がスプリントでの作業やゴールの達成に集中する
公開（Release）：全ての仕事や問題を公開することに合意する
尊敬（Respect）：お互いを能力ある個人として尊敬する

これらの価値基準を一人一人が意識することでスクラム三本柱のクオリティが上がり、結果的にスクラム開発が成功する。

3つの役割

プロダクトオーナー（PO）

プロダクトバックログの管理責任者
1プロダクトにつき1人
プロダクトが生み出す価値を最大化する責任がある
プロダクトバックログの最終的な責任者はあくまでPOであり、POが決めたことを他人が勝手に覆してはいけない

仕事内容
- ビジョンを周りに共有
- リリース計画と予算の管理
- 顧客や関連部署とプロダクトバックログの項目内容を確認したり、相談する
- プロダクトバックログを常に最新に更新する
- プロダクトバックログの項目が完成しているかどうかを確認する

開発チーム

POが順位づけたプロダクトバックログの項目を順番に開発する
通常3~9人で構成（それ以上の場合はチームを分ける）
開発チームはプロダクトを作るために必要な全ての作業ができなければいけない（設計からテストまで全てできなければいけない）（＝機能横断的なチーム）
開発チーム内では役職や肩書きはなく、外部から仕事の進め方を指示されることもない。（＝自己組織化）

スクラムマスター

イベントのプロセスを円滑に回して、POや開発チームを支える役割
スクラムのルールや成果物、進め方をチーム全体に理解させる
イベントの司会進行をしたり、スクラムのやり方を教える
スクラムの外にいる人からの妨害を排除する
マネージャーや管理者ではない

5つのイベント

スクラム開発には5つのイベント（正式には4つ？）がある。
これらのイベントは透明性を実現するために設計されており、それぞれのイベントを規定通りに運用しなければ検査と適応の機会が失われれる。

スプリント

最長1ヶ月までの同じ決まった長さで開発を進める期間のこと
この期間の中でプロダクトバックログ項目を完成させるのに必要な作業全てを行う
必ず固定期間で終了し、もし最終日に作業が残っている場合でも延長しない
もしスプリント中に作業の意味がなくなったら、POの判断で中止することができる

スプリントプランニング（タイムボックス：最大8h/1ヶ月）

スプリントで実⾏する作業の計画を⽴てるイベント
2つのトピックを扱う
1. なぜ価値があるか、何を達成するか（Why, What）
  - POは今回のスプリントになぜ価値があるのかを明らかにする
  - POはプロダクトバックログ項目から、今回のスプリントで何を完成させるのかを仮決定する（基本的にバックログ項目の上位から）
  - POはこれらをスプリントゴールとしてまとめる
  - 事前準備としてプロダクトバックログの詳細を決める「プロダクトバックログリファインメント」の作業が必要
2. どうやって実現するか（How）
  - 選択したプロダクトバックログ項目ごとに、具体的な作業を洗い出す
  - スプリントゴールと作業一覧を合わせてスプリントバックログという

プロダクトバックログリファインメント（リファインメント）
- プロダクトバックログアイテムの詳細、見積もり、優先順位づけをチームで行う作業
- リファインメントをいつどこで行うかは定義していないが、スプリントプランニング前に余裕を持って行う
- リファインメントに使う時間はスプリントの10%以内（２週間スプリントなら半日〜１日程度以内）

デイリースクラム（タイムボックス：15分）

スプリントバックログの残作業を確認しながら、このまま進めてスプリントゴールが達成できるのかを検査する
複雑さを無くすために、毎日同じ時間、場所で開催する
進め方に特に決まりはないが、以下の三つの質問に答える形で進めることが多い

スプリントゴール達成のために、自分が昨日やったことは何か？
スプリントゴール達成のために、自分が今日やることは何か？
スプリントゴール達成のために、障害となることは何か？

あくまで「検査」と「適応」の場（進捗を確認して調整する場）であって、問題解決の場ではない
- 問題を報告した場合は、デイリースクラム終了後に改めて会議を設定すること

スプリントレビュー（タイムボックス：最大4h/1ヶ月）

スプリント最終日に、PO主催でスプリントの成果をレビューするイベントのこと
必要なステークホルダー（利害関係者）を招待し、プロダクトに対するフィードバックをもらう
レビューする内容は完成の定義を満たしたものだけとする
- スプリントレビュー前までに、チーム全体で、完成したものとそうでないものの項目を明らかにしておく

（そのほかの報告・議論内容）
- 完成しなかったプロダクトバックログ項目について説明する
- スプリントでの問題点、解決した方法について議論する
- POがプロダクトの状況やビジネス環境について説明する
- プロダクトバックログに追加すべき項目の有無について議論する
- 開発を進める上で問題となる事項について議論する
- 現在の進捗を踏まえてリリース日や完了日を予測する

スプリントレトロスペクティブ（タイムボックス：最大3h/1ヶ月）

スプリントの品質と効果を高める方法を計画する（もっとうまく仕事を進める方法を考える）
今回のスプリントがどのように進んだのかを振り返る
何がうまくいったのか、何が問題だったか、どうすれば解決できるかについて話し合う（KPT）
チームに最も役立つに絞り、できるだけ早く適応させる（一度に沢山の変更をしない）

3つの作成物と確約

上記のイベントを通して、3つの作成物が作成される。
各作成物には、進捗を測定するための確約（＝コミットメント）が存在する。

プロダクトバックログ

実現したいこと（機能・要件・修正）を洗い出し、リストにして並べたもの
実現された時に得られる価値、リスク、必要性をもとに順位づけられている
それぞれに作業量を相対的に見積もった値が設定されている
POが常に管理して、最新に保っている必要がある

（確約）プロダクトゴール

プロダクトの将来の状態を表す目標で、チームの長期的な目標のこと
必ずひとつ存在しており、チームはそれに向かって達成（または放棄）しなければならない

スプリントバックログ

スプリント内で行うプロダクトバックログの項目のこと
スプリントバックログは、スプリント期間中も開発者が自由に追加したり削除することができる
一般的に、作業は1日で終わるぐらいの大きさに分割している（デイリースクラムで検査しやすくするため）
担当者を決めることはなく、実際に作業に着手するときに、作業する人自身がプロダクトバックログの項目を選択する

（確約）スプリントゴール

スプリントの唯一の目的であり、これによって作業に柔軟性をもたらす
スプリントゴールは常にチームが意識しており、それによってチーム全体に一貫性と集中をもたらす

インクリメント

過去に作ったものと、今回のスプリントで完成したプロダクトバックログ項目を合わせたもの
スプリント終了時点でインクリメント内の項目が全て正常に動作していなければならない

（確約）完成の定義

何をもって「完成」とするかの基準のこと（＝品質基準）
実際にリリースするかどうかに関係なく、完成の定義を満たしているものは必ずリリース可能である
完成の定義を満たすことによって、その項目がインクリメントに追加される
途中で定義を削るとプロダクトゴールを達成できなくなる可能性があるので注意が必要

議論

プロダクトバックログアイテムの内容をもっと具体的にしていきたい
2017年と2020年の違い（https://scruminc.jp/blog/2885）
- スクラムマスターとPOと開発者がよりフラットに近い
確約っていうのは価値ではない？
- 目的だと、インクリメントの解釈がおかしくなる
- バックログのアイテムが全て達成されると、ゴールが達成される
プロダクトゴールが曖昧になっている？
- プロダクトゴールが達成されたら、次のゴールが設定される
- プロダクトゴールは一個でなくてもいい
  - 一つのゴールは必ず達成させるべきだが、柔軟にしておくべき
- プロダクトゴールはない？
  - 現在はSSOとストップウォッチを達成すること
    - これを達成してユーザーにどういう体験を与えるか？

（参考）関連用語

https://files.esa.io/uploads/production/attachments/2716/2022/02/02/121590/8e36b263-ec42-463b-b92f-a91005b0007e.png

書籍以外の参考

2020スクラムガイド：
https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf
プロダクトバックログのつくり方やメンテナンス方法を解説：
https://service.shiftinc.jp/column/4983/
カンバンとスクラムの違い：
https://asana.com/ja/resources/waterfall-agile-kanban-scrum?utm_campaign=Brand–JP–JP–Catch-All–All-Device&utm_source=google&utm_medium=pd_cpc_br&gclid=Cj0KCQiAi9mPBhCJARIsAHchl1zPb85LKsiIILvTnmvN_HYHAG_UxcdpgiOf5qOLoi4a23bVq-4DFocaAhNHEALw_wcB&gclsrc=aw.ds