「アジャイル開発」は存在しない？ その５ ～　Scrum（スクラム）実践編③　～

足掛け2年かかってしまったシリーズも今回でいよいよ最終回。これまでに説明しきれなかった残りの「Scrum（スクラム）」の実践ポイントのお話になります。

はじめに

今回は前回までに説明しきれなかった「3つの成果物」と「完成の定義（Definition of Done）」についての解説です。
勿論両方ともスクラムガイドに明記されているものの、実際のチーム運用に落とし込むと「形骸化」したり、「曖昧な状態で進めてしまう」ケースも散見されます。
本記事では、3つの成果物と 完成の定義（Definition of Done） にフォーカスして、実践者が気をつけるべきポイントを整理しました。

Scrum の “3つの成果物” とは？

スクラムガイドに定義されている成果物（Artifacts）は以下の3つです。
　１．プロダクトバックログ
　２．スプリントバックログ
　３．インクリメント
それぞれが持つ意味と注意点を以下で詳しく見ていきましょう。

1. プロダクトバックログ

簡単に言うと、何を作るか（の優先順位）を管理する一覧です。プロダクトオーナーが最終的な管理責任を持ち、常に最新状態に保つ必要があります。複数名による「PO チーム」は良くある運用上の工夫ですが、あくまでも最終的な意思決定は1人に絞るべきです。
チームが成長したら、プロダクト改善のためのアイデアが提案されるようになるでしょう。そのような場合も含めて、複数名で補助するスタイルは良いのですが、責任の所在が曖昧になるような集合意思決定には要注意です。
また、（特にPOは）「プロダクトゴール」が重要であることをお忘れなく。

2. スプリントバックログ

スプリントバックログは、スプリント期間中に「何を」「どうやって」実現するかを明示する開発チームの作業計画です。スプリントゴールを達成するために選ばれたプロダクトバックログアイテム（PBI）と、それを完了させるための具体的なタスクが含まれます。

実践で気を付けるべき点は、まずスプリントゴールを明確にすることです。単なるタスクの羅列ではなく、チーム全員が「今回何を実現するのか」を共有することが重要です。次に、PBIの粒度を適切に分解し、1〜2日で完了できるタスク単位にすることで、進捗の把握と柔軟な対応が可能になります（スプリント期間が1週間の場合、1つのタスクは最大でも半日程度で完了できるレベルに落としこむ方が良いでしょう）。

また、タスクはチームが自律的に選んで進めること（Pull型）が推奨されます。作業状況はカンバンなどで見える化し、デイリースクラムでの共有に活かしましょう。さらに、スプリント中の不要な変更は避け、あらかじめ定義した完成の定義（Definition of Done）（後述）に従って成果を判断することも大切です。

最後に、ふりかえりを通じてタスク分解や見積もりの精度を継続的に改善していく文化を醸成していくことが、スプリントバックログを強い実践ツールに育てるポイントです。

3. インクリメント

インクリメントは、スプリントの成果として完成したプロダクトの一部であり、「本番リリース可能な状態」の動作するソフトウェアを指します（但し、市場の状況等を含め、実際に本番リリースを行うかどうかはPOが判断することになるので、また別の話になります）。スクラムにおいては、スプリントごとに少なくとも1つのインクリメントが作成されるべきであり、それはチームが合意した「完成の定義（Definition of Done）」を満たしていなければなりません。

実践で注意すべき点は、「動くものを出す」ことを徹底することです。資料やプロトタイプではなく、実際に動作確認できる完成品を示すことで、プロダクトオーナーやステークホルダーとの信頼関係が築けます。また、未完成のままレビューに持ち込まれるケースも見られますが、本来それは避けるべきです。

インクリメントはチームの成果であり、スプリントごとの進化を示す指標です。「毎回本番に出せる品質で作る」という意識を持ち続けることが、スクラムの価値を最大化する鍵となります。

完成の定義（Definition of Done）とは？

インクリメントを「Done（完成）」と判断するための要件セットです。
一般には「単体テスト合格」「コードレビュー済み」「ビルドが通っている」「ドキュメント更新済み」などのチェックポイントが含まれます。

大前提として、完成の定義（Definition of Done）（以下 DoD）は チーム全員で合意・公示されたものであり、単なる形式ではなく、品質の根拠となるべきものです。
No. ポイント 解説
１ DoD はチームの契約である チーム全員が納得できるチェックリストを作り、その内容を共有して守る習慣を定着させましょう。形式だけ DoD が存在して守られていないような状態ではその存在意味が薄れます。
２ DoD を甘くしすぎない 「単体テストだけ」で済ませてしまうと、不具合率が高まるリスク大となります。必要最低限の品質ゲート（レビュー／動作確認など）についても DoD に明記しましょう。
３ DoD は進化する チームが成熟するにつれ DoD の内容・粒度もレベルを上げるべきです。KPT やふりかえりで DoD を見直す機会を設けましょう。
４ PO ＆ 開発者の DoD 認識を一致させる P.B.I. を PO が Done 承認するには、開発者の「Done」と PO の認識が揃っていることが必要です。レビュー前に擦り合わせておきましょう。
５ Undone（未完成）の判断を先延ばしにしない スプリントレビュー時に「これは未完成」と指摘されるのは、本来避けるべきです。ただ、そのような場合は、PO と開発者が合意し、次スプリントでの対応方針を決めて前に進むようにしましょう。
６ インクリメントは「本番可能な完成品」であるべき 形だけのデモや資料ではなく、動く実際の成果物でレビューを行う文化をつくりましょう。
７ PoC や検証ピースは別扱いにする プロダクトバックログとは別管理し、DoD を曖昧にしない工夫が必要です。
８ DoD のチェックは自動化できるものは自動化する 例えば単体テストの実行等をCI／CD に統合することでDoneの条件の実施漏れを防ぎ、完了条件のブレをなくします。
９ DoD をスプリントバックログにも明示する 各スプリントのP.B.I. にタグやリンクで DoD 条項を目視できるようにし、実施漏れを防ぎます。
１０ DoD を軸にフィードバックを循環させる スプリントレビュー・レトロスペクティブでの課題 → DoD 更新 → スプリント計画への反映、を繰り返すサイクルこそ Scrum の生命線です。

実践をより強くするために

ふりかえりを活用して DoD をアップデート

スプリントレトロスペクティブ（ふりかえり）では、DoD の妥当性や適用状況を議題にしましょう。また、その際は複数の「Try」を設定せず、次のスプリントで着手する改善点を1つに絞ると効果測定しやすくなります。

PO やステークホルダーを含むスプリントレビュー文化の醸成

品質や価値を開示する場として公開的なレビューを検討すると、外部からのフィードバックも得やすくなります（ゲーム業界などでは一般的なスタイルだそうですが、一般的なシステム開発においても関係者に向けて公開する事で有益なフィードバックが得られるかもしれません）

まとめ

・Scrum の成果物（プロダクトバックログ、スプリントバックログ、インクリメント）はそれぞれ 本質的な役割と関係性があります。
・完成の定義（Definition of Done）は単なる「定義」ではなく、品質と責任を担保するチーム全体の契約です。
・DoD を軽視せず、継続的に見直しながら運用する文化を築くことが成功の鍵になります。

Scrum を単なる「形式」で終わらせず、「価値ある成果」を生み出す手段にしたいなら、まずは 成果物の扱いと DoD の運用をチーム全体で意識することが重要です。
ここまでお付き合いいただき、ありがとうございました！