Regional Scrum Gathering Tokyo 2021 Day 2 「スクラムにおける「完成」とはなにか？」
202/01/07に開催されたRegional Scrum Gathering Tokyo 2021での発表です。
https://confengine.com/regional-scrum-gathering-tokyo-2021/proposal/14653
チーム参加してきました
aslead Agile のチーム「オキザリス」にて参加してきました。
チーム7人で参加して、その場で実況しつつ、記事も作っています。
このセッションは
- スクラムガイドにでてくる「完成」ってなんなんだろう？
- 「完成」の定義っていつどうやって作って、守っていければいいんだろう？
というお話です。
はじめに
スクラムガイド2020と、スクラムガイドで出てくるいくつかの言葉の定義の確認です。
スクラムガイド2020の変更点は？
- 私事的な部分を削減
- ひとつのチームがひとつのプロダクトに集中
- プロダクトゴールの導入
- スプリントゴール、完成の定義、プロダクトゴールの居場所
- 自己組織化よりも自己管理
などなど、色々な変更点がありました。
インクリメントとは
スクラムガイドのあちこちに登場するインクリメント。
過去に作ったインクリメントと今回のスプリントで作ったインクリメントの集合体のこと。
価値がなければいけない、完成の定義を満たさなければいけません。
そしてこのインクリメントが、プロダクトゴールの実現に寄与します。
プロダクトとは
価値を提供する手段。プロダクト＝価値を運搬（交換）するもの。
私たちだとソフトウェアが中心になるけれど、プロダクト＝ソフトウェアというわけではありません。
ソフトウェアを動かしているインフラも、ソフトウェアのドキュメントもみんなプロダクト。
プロダクトバックログには何が含まれる？
プロダクトの改善に必要なものの一覧のことです。
- ソフトウェアの顧客向けの部分
- 内部向けの部分
- 関係するインフラなど、ソフトウェア以外のもの
- 将来の価値を生み出すような検証や実験、学習など
つまりプロダクトバックログは、双発的かつ順番に並べられているものになります。
完成の定義とは
ここからは本題、スクラムの完成の定義に目を向けます。
スクラムガイド2020を見てみる
完成の定義については、以下のような記述が。
完成の定義とは、プロダクトの品質基準を満たすインクリメントの状態を示した正式な記述で
ある。
プロダクトバックログアイテムが完成の定義を満たしたときにインクリメントが誕生する。
完成の定義により、作業が完了してインクリメントの一部となったことが全員の共通認識とな
り、透明性が生み出される。プロダクトバックログアイテムが完成の定義を満たしていない場
合、リリースすることはできない。ましてやスプリントレビューで提示することもできない。
そうした場合、あとで検討できるようにプロダクトバックログに戻しておく。
んん？？
この内容だと、すべてのプロダクトバックログは完成の定義という共通理解によって検査しないと
インクリメントに変えられないように解釈できる...
完成の定義はどんなケースでもあてはまるもの？
ソフトウェア依存の完成の定義や、ドキュメント依存の完成の定義、完成の定義にも色々あるはず。
画一的な基準として完成の定義は用意できないのでは？
じゃあどうすれば「完成」なの？
各領域（ソフトウェア、ソフトウェア以外、将来の価値創出、...、その他）ごとに完成の定義を用意すべき？
といっても、そんなに一気に完成の定義を決めることはできません。
ここでスクラムの基本に立ち返ってみると、「一気に各領域の完成を定義するより、チームとして共通理解を持つことこそが透明性を生むのでは？」という考察に。
「完成」の定義を決めて、守っていくには
いつ、どうやって「完成」の定義を決める？
-
最初のスプリント1開始前に作るのが望ましい
- 完成の定義がないとインクリメントにできず、PBIが宙ぶらりんになってしまいます。
- だからこそ、スプリントの前に作成が必要。
-
カイゼンのサイクルをまわして、完成の定義を手入れしていく
- 新しい種類の領域があれば、随時更新していく必要があります。
- どうなれば完成なの？という会話をスクラムチームでしていく中で、共通理解を持つことが大事。
-
会社として従うべき基準が決まっているなら、それをベースに
- とはいえこれは議論の余地あり。
- 会社基準はあれど、社内向け、社外向けなどプロダクトの種類にも依存しそうです。
足りない要素があるなら、それはチームで作っていけばよし！
組織の標準がないなら、それもまたチームで作っていけばよし！
完成の定義のレベル感は？
いつでもリリースできる状態が理想。ということは
- 最初からリリースできる品質を維持
- 出荷前にリリースできる品質と、現状の品質ギャップを埋められる
というレベル感が理想。
定義をどう守る？
ただその定義を紙に書いて周知しておけば、完成の定義が守れるわけではありません。
- 全員が完成の定義を共通理解することが大事。
- 誰でも見える形でその定義を文書化する。でも一方で全てを明文化・維持するのは難しいというのも事実。
- 自動化できるものは自動化して、意識しなくても守れる仕組み作りをするのは大事。
- とはいえ、レビューなど人間の力も必要。
- 単に定義を標準化したり、チェック項目で機械的にならないよう気を付ける必要がある。
- そしてその定義は、レトロなどをきっかけにカイゼンしていく。
さいごに
プロダクトはというものは最後まで完成しないのです。
あくまで、スクラムの完成はスクラムの完成にすぎないのです。
感想
チームとして透明性高く動くために、完成の定義への共通理解を持つことが必要なんだなと改めて認識できました。
あまり定義を形式化・標準化してしまうとただ淡々と作業をこなすだけになってしまいそうなので、
ちゃんと人間の力を入れられる余地を残すことに注意したいです。
余談ですが、私自身昨年10月にオキザリスチームにjoinしてからスクラムガイドの旧バージョン（？）を読んだばかりで、実はスクラムガイド2020をまだ読めていなかったりします...
セッション前に読んでおけばよかったなあと反省しながらお話を聞いておりました。