私はもともとインフラSEなのですが、ひょんなことからアジャイル開発のプロ集団にJoinすることになりました。
初めてのスクラム実践にチャレンジするなかで、同僚からおすすめされた「最初にこれ読んどくといいよ！」という資料がこれでした。
※ちなみにスクラムとは「アジャイル開発」の実践方法の一つ、というのが両語の関係性のようです。
スクラムガイドとは？
いわばスクラムの聖書のようなもので、無料で公開されているのですが日本語版で18ページと非常に分量が少なくコンパクトなのが特徴です。
スクラムを発明したKen Schwaber氏とJeff Sutherland氏によって2010年に初版が世に出され、そこから継続的に改版がなされており最新は2020年版です。
アジャイル初心者の私がこのガイドを読んで学んだ内容を簡単に共有できればと思います。
3分で読めるようにまとめますが、追加で10分とれる方はぜひスクラムガイド自体をざっと読んでみていただき、自分の頭でスクラムを咀嚼いただければと思います。
スクラムガイドを読む前の私の認識
- スクラムマスター：開発チームリーダーみたいなもの？
- プロダクトオーナー：社内システムで言うユーザー部門（要求部門）みたいなもの？
- バックログ：タスク＆課題管理表みたいなもの？
スクラムガイドの内容
私の理解に基づくまとめ＆感想です。一つの見解としてご覧いただき、もし誤り等に気付かれたら是非お知らせくださいますと幸いです。
スクラムの定義
絵にするとこうです。これがスクラムだ！
スクラムの理論
- スクラムは「経験主義（＝観察から判断）」と「リーン思考（＝ムダを省く）」に基づいている。
- 経験主義の三本柱：透明性、検査、適応
スクラムの価値基準
この5つを実践できるかどうかでスクラムの成功が決まる。
- （互いのサポートを）確約
- （スプリントの作業に）集中
- （作業や課題を）公開
- （メンバー互いに）尊敬
- （困難に取り組む）勇気
スクラムチーム
スプリントごとに価値ある有用なインクリメントを作成する責任を持つ。
- スクラムマスター1人＋プロダクトオーナー1人＋複数人の開発者
- 機能横断型＆自己管理型
- スプリント期間内で重要な作業を完了するために必要最低限の大きさ（10人以下）
開発者
以下の責任を持つ。
- スプリントの計画を作る
- 完成の定義を守って品質を作り込む
- スプリントゴールに向けて毎日計画を適応させる
- プロとして互いに責任を持つ
※計画立案も含めて開発者自らがコントロールできるのが面白いですよね。
ウォーターフォールのシステム開発でいう「作業員」と大きく違う部分だなと思いました。
プロダクトオーナー
1人の人間であり委員会ではない。以下の責任を持つ。
- スクラムチームが生み出すプロダクトの価値を最大化する
- 効果的にプロダクトバックログを管理する
スクラムマスター
このガイドで定義されたスクラムを確立させることに責任を持つ。
- スクラムチームとより大きな組織に奉仕する真のリーダーである
- さまざまな形でスクラムチーム、プロダクトオーナー、スクラム導入組織を支援する
※「リーダー」というよりも「一歩引いて見守る＋後押しする」イメージの方が近いのかなと思いました。
スクラムイベント
（イメージ図）
スプリント
- 1ヶ月以内の決まった長さとする
- プラダクトゴールを達成するために必要なすべての作業はスプリント内で行う
- スプリントの反復によって、ゴールに対する検査と適応が確実になり予測可能性が高まる
※同じスパンを繰り返すことで、経験を得る→次の計画を見積もる、のプロセスの精度が上がっていくことが狙えますね。
スプリントプランニング
話し合って以下に対応する。
- このスプリントはなぜ価値があるのか？（スプリントゴールを定義）
- このスプリントで何ができるのか？（プロダクトバックログから選定）
- 選んだタスクをどのように成し遂げるのか？（選んだバックログを作業へ分解）
デイリースクラム
- 毎日同じ時間・場所で15分行う
- スプリントゴールへの進捗検査＋今後のスプリントバックログを調整
- チームの自己管理を促進し、他の会議を不要にしてくれる
スプリントレビュー
- スプリントの成果を検査し、今後の適応を決めていく
- チームからステークホルダーへ作業の結果を提示する
- ただのプレゼンではなく、話し合うワーキングセッションである
※このプロセスにより、従来型のプロジェクトマネジメントにおける「報告」のようなタスクを代替できる（無くしていける）と言えそうです。
スプリントレトロスペクティブ
- （作成物ではなく）チームの行ったプロセスを検査する
- うまくいったこと、問題、解決方法などを話し合う
- 改善のために最も役立つことは何か？を特定して早く対処する
※いわゆる「ふりかえり」ですが、スクラムの特徴的なイベントの一つですよね。従来の仕事の仕方で忙殺されているとなかなか実施されない活動ですが、検査によって改善を繰り返すスクラムでは欠かせないイベントなんですね。
スクラムの作成物
それぞれ「確約（コミットメント）」を含んでおり、これによって進捗を測定できる。
※「成果物」ではなく、バックログを含む「作成物」なのがミソですね。
プロダクトバックログ
- プロダクトの改善に必要なものの一覧
- スクラムチームが行う作業の唯一の情報源
- 確約するもの＝プロダクトゴール（将来の状態）
スプリントバックログ
以下で構成される。
- 確約するもの＝スプリントゴール（なぜ）
- プロダクトバックログから選ばれたもの（何を）
- インクリメントにするために実行可能な計画（どのように）
インクリメント
- プロダクトゴールに向けた具体的な踏み石
- スプリント内で複数作ってよい
- 確約するもの＝完成の定義（レビューしてもらえる条件）
※従来のシステム開発でいうところの「成果物」に近いのがこれでしょうか。ただし物ではなく「価値が確実に積み上がった」ことにフォーカスしているのが面白いですね。（余談ですが、Qiita株式会社さんの旧社名は「Increments株式会社」でした）
最後に
上記のようにスクラム独自のキーワードは色々と登場するのですが、実践する際は形にばかりこだわると「なんちゃってアジャイル」になってしまいそうなので、なぜこういった形式になっているのか？根本思想はどこにあるか？を考えながらプラクティスを取り入れていくのが良さそうだな…と感じています。
私もこれから現場で実践してスキルを身につけていきたいと思います！