製造業アジャイル勉強会参加レポ：スクラムにおける「完成」とはなにか？

f:id:izumii-19:20210204102155p:plain

製造業アジャイル勉強会に参加してきました。

夜打ち合わせが入っていて参加できるか微妙だったんですが、OSTのマーケットプレイスくらいから途中参加できました（家事しながらだったので聞き専状態でしたが）。

beyond-hardware-agile.connpass.com

RSGT2021で@ryuzeeさんが発表された「スクラムにおける「完成」とはなにか？」を視聴しました。 zoom動画公開期日が迫っているのでこういう同時視聴企画ありがたい。*1

confengine.com

ダイジェスト

スクラムガイド2020の変更点のなかから「完成の定義」について
- ３つの作成物に関するコミットメントが追加された
  - プロダクトバックログのコミットメントは、プロダクトゴール
  - スプリントバックログのコミットメントは、スプリントゴール
  - インクリメントのコミットメントは、完成の定義　←これ
インクリメントってなんだ
- スクラムガイドにやたら登場する。が説明しづらいし誤解されやすい
- インクリメントとは、過去に作った員栗目のと今回のスプリントで作ったインクリメントの集合体。　i++ってことだね。
- スクラムガイドから読み解く「インクリメント」
  - その集合体が全体として機能しないとならない
  - その集合体が全体として利用可能しないとならない
  - その集合体が価値がないとならない
  - 完成の定義を満たさなければならない - プロダクトゴールの実現に寄与するものでなければならない
プロダクトってなんだ
- 価値を運搬（交換）するもの
- われわれの場合だとソフトウェアなんだけど、ソフトウェアに加えサービスとかサポート、営業とかも含むのでプロダクト＝ソフトウェアではない（プロダクトの一部がソフトウェアではある）。
上記の「プロダクト」の定義をふまえて考えた時に、プロダクトバックログには何が含まれるべきか？
- プロダクトバックログとはプロダクトの改善に必要なものの一覧
  - ソフトウェアの顧客に見える部分
  - ソフトウェアの顧客に見えない部分
  - ソフトウェア以外のもの（インフラとか）
  - 将来の価値をうむもの（検証、学習、実験）
  - その他
- つまりプロダクトに関するものならなんでもプロダクトバックログになる。なんということでしょう！
【本題】完成の定義について考察
- 状態遷移
  - PBIが完成の定義を満たした時にインクリメントが誕生する
  - PBIが完成の定義を満たさなければPBLに戻す、または削除する
  - つまり全てのPBIは完成の定義を満たさなければならないと言える
- どうすれば良いか
  - プロダクトの各領域ごとに完成の定義を定義するようなマトリクス作成する？
  - マトリクスキレイに埋めることよりも、スクラムチームやステークホルダーとの共通理解を作ることが大事。
- 完成の定義はいつつくる？
  - スクラムガイドから考察する（明確に書かれているわけではない）と「スプリント1の開始前までにつくる」が正解っぽい。
  - 最初から全部網羅できそうにないので、継続的な手入れが必要。
  - 最新をアップデートしつづけて共通理解する。リファイメントの時が良さそう。
- 完成の定義はどうつくる？
  - 会社標準があるならそれに則るという考えもあるが、一辺倒に適用すると場合によってはオーバーエンジニアリングになる可能性があるので注意が必要
  - 足りないものは足す
  - スクラムチームで都度考える。ただし透明性を確保するためになぜそうなったのか説明は必要
- 完成の定義の守り方
  - 全員で理解、共通理解することが大事
  - 自動化できるものは自動化する
  - とはいえ人の力も必要
  - レトロスペクティブでアップデート
- まとめ
  - 完成の定義は定義をまとめた文書ではなく共通理解である。突きつめると「透明性、検査、適用」に立ち戻った考え方になる
  - 共通理解は透明性を担保するために必要不可欠
  - スクラムにおける完成はスクラムでの完成でしかない

セッションの感想

もともとこのセッションをみたいと思った理由がゴールの定義を理解できていないと何をやっても真のゴールに到達しないので、ゴールの定義を自分の中で明確にしたいという考えが自分の中にあったからなのでした。

「完成の定義」と言われると完成が文書化された状態で定義されているものとイメージしがちだけど、プロダクトは価値を運搬するものでありプロダクト≠ソフトウェアという性質を考慮すると、スプリント1が始まる前までに完成の定義を全網羅することはハードルが相当高いし、スプリントの途中でも変わることを考えるとやる意味とか効果とか微妙だと感じました。

で「透明性、検査、適用」というスクラムの原則に立ち戻り考察すると「完成の定義とは、定義を全網羅した何かを作ることよりもチームやステークホルダーとの共通理解を持ち続けること」ということに行き着くわけですね。

その共通理解の中で自動化できるものは自動化すればよいし、そうでないものはリファイメントやレトロスペクティブでアップデートし共有して最新を共通理解とする必要があります。そしてこれを継続するということ。

最初このセッションのタイトルを見た時に「完成の定義はこう書くべき」という話だと思っていたので、いい意味で裏切られ感がありましたね。

自分ではスクラムガイドからここまで考察できないし、その話を20分でまとめてくれて話してくれるってRSGTってすごくないですか？親切にもほどがありますよね（ほめた）。

おまけ ：プロダクトマネジメントを読んでおいたおかげで前提知識があって聞けたのがよかった。