スクラム開発を紐解く：価値・原則・プラクティスへのガイド（2024 Advent Calendar 3日目）

この記事は私をシニアエンジニアにしてくれた「真のアジャイル開発」体験記の 3 日目の記事です。このアドベントカレンダーは「ある機能開発チームでスクラム, XP, DevOps を一度に実践したら真のアジャイル開発ができた」という内容です。執筆者は全てプログラミングをするパンダです。

本記事ではスクラム開発について概観します。

スクラム開発の概観

スクラム開発（以下、スクラム）はアジャイルなソフトウェア開発の手法として知られています。スクラムはスクラムイベントと言われている各種の会議やアクティビティが有名です。このため、スクラム開発の手法を導入すると必ずチームがアジャイルに開発を進められると勘違いされてしまうことが多々あります。しかし、スクラムに含まれるものはスクラムイベントだけではありません。スクラムガイド2020年版からスクラムの定義を引用します。

スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、⼈々、チーム、組織が価値を⽣み出すための軽量級フレームワークである。 「スクラムガイド2020年版」 p.4

では、スクラム開発とは具体的にどのような開発手法なのでしょうか。最初にスクラムが重要視する価値について触れておきましょう。

スクラムが重視する5つの価値

スクラムは「価値、原則、プラクティス（実践）」の3つで構成されています。スクラムが追求する価値は以下の5つです。

• 確約（Commitment）: やり切ることを約束すること
• 集中（Focus）: やるべきことに集中すること
• 公開（Openness）: チームの情報の透明性を確保すること
• 尊敬（Respect）: 相手に対してリスペクトの念を持つこと
• 勇気（Courage）: 不確実性の高いことに対して勇気を出して一歩踏み出すこと

良いチームというものを想像した時に、これらの特徴をいくつも兼ね備えていることは想像に難くありません。スクラムの原則とプラクティスは、これら5つの価値を実現するための手段なのです。

スクラムイベントのようなプラクティスだけを取り入れても必ずしも成功するとは限らない理由がここにあります。プラクティスを実施してもこれらの価値がチームで体現できていなければ形骸化し、本当に意義があるかわからないけどとりあえず実施するだけの「儀式」と揶揄されてしまうのです。

スクラムの原則

エッセンシャルスクラムによると、スクラムの原則は「変動性と不確実性」「予見と適応」「検証による学び」「仕掛かり中の作業（WIP）」「進捗」「作業効率」とされています。これらの原則はさらに分解され、心構えやアドバイスとして文章化されています。これらを簡単にまとめると以下のようになるでしょう。

• 変動性と不確実性: 変化を受け入れつつ不確実性を低減させること
• 予見と適応: 将来を見越した上で現実的な方法を取り入れること
• 検証による学び: 重要だけど不確実性の高い箇所を優先し、手を動かして新しい知識を得て次の行動に活かすこと
• 仕掛かり中の作業（WIP）: タスクの管理を効率的に行うこと
• 進捗: 動くものを基準にして計画を見直し続けること
• 作業効率: 品質の高いものを焦らずに、しかし素早く作ること

これらの原則は全てスクラムの5つの価値のいずれかに基づいたものです。例えば、検証による学びは不確実性に立ち向かう「勇気」や優先順位の高いことに「集中」して取り組むことだとも言えます。

スクラムのプラクティス

スクラムのプラクティスは「役割」「アクティビティ」「作成物」に分けられます（「エッセンシャルスクラム」による）。さらに細分化すると以下です。なお、「ルール」にはここでは触れません。

• 役割
  • プロダクトオーナー
  • スクラムマスター
  • 開発チーム
• アクティビティ
  • スプリント
  • スプリントプランニング
  • デイリースクラム
  • スプリントの実施
  • スプリントレビュー
  • スプリントレトロスペクティブ
  • プロダクトバックログリファインメント
• 作成物
  • プロダクトバックログ
  • スプリントバックログ
  • 出荷判断可能なプロダクトインクリメント

この記事ではアクティビティをスクラムイベントと呼ぶことにします。スクラムイベントと作成物は関係しあっています。その関係図は以下のようなもので、ループを形成しています。

役割について触れると、スクラムチームは1人のプロダクトオーナー、1人のスクラムマスター、複数人の開発メンバーで構成されるとスクラムガイドにあることを反映しています。アクティビティと作成物については別の記事で詳述します。

価値、原則、プラクティスを貫くスクラムの理論

ここまでスクラムの価値、原則、プラクティスを紹介しました。チームメンバーのあるべき姿や指針、実践するべきことはここまでで示されました。しかし、スクラムは何らかの思想に裏打ちされたものなのでしょうか。その問いはスクラムガイドの「スクラムの理論」で答えられています。

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

さらに経験主義を採用しているスクラムの三本柱は「透明性」「検査」「適応」と述べられています。これらを簡単に説明すると以下のようになります。

• 透明性（transparency）: 作業プロセスや作成物を隠さずに公開すること
• 検査（inspection）: 作成物や進捗状況のチェックをしてフィードバックを得ること
• 適応（adaptation）: 検査で得たフィードバックに基づき、課題を解決するアクションを起こすこと

特に「検査」と「適応」は、この後スクラムイベントを解説する中で繰り返し登場する重要な考え方です。

スクラムは全てを実施する

スクラムは全てを実施することで本領を発揮するフレームワークです。

スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、⼈々、チーム、組織が価値を⽣み出すための軽量級フレームワークである。 「スクラムガイド2020年版」 p.4

スクラムは無料であり、本ガイドで提供されるものである。ここで概要を述べたように、スクラムフレームワークは不変である。スクラムの⼀部だけを導⼊することも可能だが、それはスクラムとは⾔えない。 すべてを備えたものがスクラムであり、その他の技法・⽅法論・プラクティスの⼊れ物として機能するものである。 「スクラムガイド2020年版」p. 14

全てのプラクティスを実施するのは大変そうだから重要な一部だけを取り入れようという態度は明確なアンチパターンです。プラクティスや作成物全てに意味があり、相互に関係しあっているからです。

これだけ多くのことを実施するスクラムは、なぜ自分自身を「軽量級フレームワーク」と自称するのでしょうか。スクラムイベントや作成物の定義や方針スクラムガイドで語られるものの、実際にどのツールを使えばいいとか何曜日の何時から何時間実施するといったような細かい指定はないからです。日本語版のスクラムガイドが目次を含めて14ページしかないことがその証拠です。

スクラムは軽量級フレームワークであり、スクラムガイドはその定義や方針を定めたものです。しかし、それだけではスクラムをどう実施するのか見当がつきません。だからといって全部で413ページあるエッセンシャルスクラムという手厚いながらも分厚い本を読破するのも大変です。このアドベントカレンダーは3ヶ月間スクラムを実施した実録を通して、両者の橋渡しをすることが一つの目的でもあります。

スクラムが軽量級フレームワークであることはエッセンシャルスクラムでも述べられています。

スクラムは標準化されたプロセスではない。（中略）スクラムは作業をまとめ上げ、管理するためのフレームワークだ。このスクラムフレームワークは価値、原則、プラクティスに基づいている。 それらを基礎として、組織にあったエンジニアリングプラクティスや、スクラムのプラクティスを実践するための具体的なアプローチを追加できる。その結果として現れるのは、あなた独自のスクラムである。 「エッセンシャルスクラム」 p.14

スクラムの具体的な実践の仕方はチームによって異なります。何か一つの正しいスクラムのやり方があって自分たちはそれに沿っているか外れているかなどとは考えずに、チームメンバーが最大のパフォーマンスを発揮できる形でスクラムを運用していくことが望ましいのです。

自分たちのスクラム運用

自分たちのプロジェクトで実施したスクラムの運用例を紹介します。まず、スクラムガイドをチームメンバー全員で輪読しました。また会社の書籍購入制度を利用して全員がエッセンシャルスクラムを購入しました。

スクラムイベントの司会はスクラムマスターが担当していました。スクラムマスターはEMでもあるのでプロジェクトの進捗に責任を負っています。しかし、開発メンバーに対して「先にこのタスクをやった方がいい」などの具体的な指示は出していませんでした。チームがどう動くかを一歩引いて観察し、困った時に助言をくれるコーチとして振る舞ってくれました。

チームメンバーが「この場合、スクラムではどう考えるのか」という疑問を持った時、スクラムマスターは口頭で回答していました。その後、Slackでエッセンシャルスクラムやブログ記事からより詳しい考え方を引用して、何ページを参照のことという形でしっかり答えてくれました。

認定スクラムマスターの方が答えてくれるという安心感とチームメンバーの疑問に対して一緒になって考えてくれる上に、口頭と出典ありの二段構えで誠実に答えてくれる姿勢によってチームメンバーからスクラムマスターに対する信頼はとても厚かったです。

スクラムマスターの回答は特にエッセンシャルスクラムからの引用が多かったため、スクラムイベント中にチームメンバーがスクラムマスターに質問した時、自分は裏で即座に手元のエッセンシャルスクラムの目次を開いて該当箇所を探し、その疑問と答えが書かれていそうな箇所を読むようにしていました。これを何度か繰り返すうちに、エッセンシャルスクラムの中にスクラムでよく起きることがほとんど解説されていることに気づき、自分の疑問も自分で解消できるようになりました。

スクラムマスターのファシリテーションは1ヶ月ほど続きました。チームメンバーがスクラムイベントのやり方を理解し始めた2ヶ月目から、プロダクトオーナーと開発メンバーがランダムで司会をすることになった。スクラムイベントは全て一枠50分で設定されていたので司会は一枠ごとの交代制でした。

しかし、必ずしもこれを真似る必要はありません。実際にチームの習熟度に応じてリファインメントの時間を減らしたり、スプリントの期間を変えたりと時期によって柔軟に変化していたからです。これはあくまでも一例なのです。

（プロジェクト中盤のスクラムイベントのカレンダー）

スクラムのループ図で見たように、スクラムはプロダクトバックログリファインメントから始まりスプリントレビューで終わります。次回からはこの順番で各スクラムイベントの定義と自分たちのプロジェクトでの運用法を詳述します。