完成の定義 Deep Dive

本資料は、2021年1月7日に行われたRegional Scrum Gathering Tokyo 2021のセッション 『スクラムにおける「完成」とはなにか？』に加筆修正し、スクラム Deep Diveシリーズのフォーマットにしたものです

Tidy First? ―個人で実践する経験主義的ソフトウェア設計
  • 著者／訳者：Kent Beck、 吉羽 龍太郎、 永瀬 美穂、 細澤 あゆみ
  • 出版社：オライリー・ジャパン
  • 発売日：2024-12-25
  • 単行本（ソフトカバー）：164ページ
  • ISBN-13：9784814400911
  • ASIN：4814400918
脳に収まるコードの書き方 ―複雑さを避け持続可能にするための経験則とテクニック
  • 著者／訳者：Mark Seemann、 吉羽 龍太郎、 原田 騎郎、 Robert C. Martin
  • 出版社：オライリー・ジャパン
  • 発売日：2024-06-18
  • 単行本（ソフトカバー）：312ページ
  • ISBN-13：9784814400799
  • ASIN：4814400799

Transcript

1. 完成の定義 Deep Dive 2021/1/7 fi 株式会社アトラクタ / Certi ed Scrum Trainer (CST) 吉羽 龍太郎 (@ryuzee)
2. はじめに 2 本資料について ▸ 本資料は、2021年1月7日に行われたRegional Scrum Gathering Tokyo 2021のセッション 『スクラ ムにおける「完成」とはなにか？』に加筆修正し、スクラム Deep Diveシリーズのフォーマットにしたもの です
3. 自己紹介 吉羽龍太郎 / Ryutaro YOSHIBA / ryuzee ▸ 株式会社アトラクタCTO /アジャイルコーチ / 翻訳者 ▸ Scrum Alliance 認定スクラムトレーナー （CST） 認定チームコーチ (CTC) ▸ Microsoft MVP （DevOps） ▸ X（Twitter）: @ryuzee ブログ: https://www.ryuzee.com/ 3
4. 自己紹介 最新書籍紹介（買ってください!!） 4
5. 完成の定義 DEEP DIVE スクラムガイド2020 5
6. 完成の定義 DEEP DIVE スクラムガイド2020の変更点 ▸ 指示的な部分を削減 ▸ ひとつのチームがひとつのプロダクトに集中する ▸ プロダクトゴールの導入 ▸ スプリントゴール、完成の定義、プロダクトゴールの居場所 ▸ 自己組織化よりも自己管理 ▸ スプリントプランニングの3つのトピック ▸ 幅広い読者のために全体的に文章を簡略化 6
7. 完成の定義 DEEP DIVE 7 3つの作成物に対するコミットメント 以前のスクラムガイドでは、明確なアイデンティティーを与えることなく、「スプリントゴー ル」と「完成の定義」について説明していた。 3つの作成物には、それぞれの「確約(コミットメント)」が含まれる。つまり、プロダクトバッ クログにはプロダクトゴール、スプリントバックログにはスプリントゴール、インクリメントに は完成の定義(カッコをなくした)が含まれる。 これらの存在により透明性がもたらされ、 作成物の進捗に集中できるようになる。 -- スクラムガイド2020
8. 完成の定義 DEEP DIVE ▸ インクリメントと完成の定義の紐付けが明確になった ▸ では、インクリメントとは何だろうか？ 8
9. 完成の定義 DEEP DIVE 9 インクリメントの定義（スクラムガイド2020） インクリメントは、プロダクトゴールに向けた具体的な踏み石である。インクリメントはこれまでのすべ てのインクリメントに追加する。また、すべてのインクリメントが連携して機能することを保証するため に、徹底的に検証する必要がある。価値を提供するには、インクリメン トを利用可能にしなければなら ない スプリントでは、複数のインクリメントを作成可能である。インクリメントをまとめたものをスプリントレ ビューで提示する。それによって、経験主義がサポートされる。ただし、スプリント終了前にインクリメン トをステークホルダーにデリバリーする可能性もある。スプリントレビューのことを価値をリリースするた めの関門と見なすべきではない 完成の定義を満たさない限り、作業をインクリメントの一部と見なすことはできない -- スクラムガイド2020
10. 完成の定義 DEEP DIVE ほかにインクリメントが登場する箇所(一部抜粋) ▸ 「スクラムチームは、スプリントで選択した作業を価値のインクリメントに変える」（p.4） ▸ 「スクラムチーム全体が、スプリントごとに価値のある有用なインクリメントを作成する責任を持つ」 （p.6） ▸ 「プロダクトバックログアイテムを価値のインクリメントに変換する方法は誰も教えてくれない」 （p.10） 10
11. 完成の定義 DEEP DIVE つまりインクリメントとは？ ▸ 過去に作ったインクリメントと今回のスプリントで作ったインクリメントの集合体 ▸ その集合体が全体として機能しなければいけない ▸ その集合体が全体として利用可能でなければいけない ▸ 価値がなければいけない ▸ 完成の定義を満たさなければいけない ▸ プロダクトゴールの実現に寄与する 11
12. 完成の定義 DEEP DIVE 12 そもそもプロダクトとは? ▸ スクラムガイド p.12 「プロダクトとは価値を提供する手段である。プロダクトは、明確な境界、既知の ステークホルダー、明確に定義されたユーザーや顧客を持っている。プロダクトは、サービスや物理的 な製品である場合もあれば、より抽象的なものの場合もある」 ▸ プロダクト＝価値を運搬（交換）するもの（書籍『プロダクトマネジメント』での定義） ▸ 我々の文脈だとソフトウェアが中心 ▸ とはいえ、プロダクト＝ソフトウェアではない ▸ ましてや、プロダクト＝顧客やユーザー向けに提供している部分だけでもない ▸ プロダクトを構成する主要要素としてソフトウェアが存在する
13. 完成の定義 DEEP DIVE とするとプロダクトバックログには何が含まれるのか？ ▸ プロダクト＝価値を運搬（交換）するものと考えたときに…… ▸ プロダクトバックログには、以下のものが含まれる可能性がある ▸ ソフトウェアの顧客向けの部分 ▸ ソフトウェアの内部向けの部分 ▸ プロダクトに関係するソフトウェア以外のもの ▸ プロダクトの将来の価値を生み出すもの（検証や実験、学習など） ▸ その他 ▸ スクラムガイド「プロダクトバックログは、創発的かつ順番に並べられた、 プロダクトの改善に必要なものの一覧である」 13
14. 完成の定義 DEEP DIVE 14 とするとプロダクトバックログには何が含まれるのか？ ソフトウェアの顧客向 けの部分 ソフトウェアの内部向 けの部分 プロダクトに関係する 将来の価値を生み出す ソフトウェア以外のも もの（検証や実験、学 の 習など） その他
15. 完成の定義 DEEP DIVE ▸ これを踏まえて完成の定義を考えてみましょう 15
16. 完成の定義 DEEP DIVE 16 完成の定義（スクラムガイド2020） 完成の定義とは、プロダクトの品質基準を満たすインクリメントの状態を示した正式な記述である。 プロダクトバックログアイテムが完成の定義を満たしたときにインクリメントが誕生する。 完成の定義により、作業が完了してインクリメントの一部となったことが全員の共通認識となり、透明性 が生み出される。プロダクトバックログアイテムが完成の定義を満たしていない場合、リリースするこ とはできない。ましてやスプリントレビューで提示することもできない。 そうした場合、あとで検討でき るようにプロダクトバックログに戻しておく。 -- スクラムガイド2020
17. 完成の定義 DEEP DIVE 17 この記述からわかること ▸ 「プロダクトバックログアイテムが完成の定義を満たしたときにインクリメントが誕生する」 ▸ 「プロダクトバックログアイテムが完成の定義を満たしていない場合（中略）あとで検討できるようにプ ロダクトバックログに戻しておく」 ▸ つまり 「すべての」プロダクトバックログアイテムは完成の定義を満たさなければいけない ということになる
18. 完成の定義 DEEP DIVE 18 プロダクトバックログアイテム、完成の定義、インクリメントの関係 ソフトウェアの顧客向 けの部分 ソフトウェアの内部向 けの部分 プロダクトに関係する 将来の価値を生み出す ソフトウェア以外のも もの（検証や実験、学 の 習など） P B I 完成の定義という共通理解による「検査」 イ ン ク リ メ ン ト その他
19. 完成の定義 DEEP DIVE ▸ これを踏まえると完成の定義はどういう形になるのだろうか？ 19
20. 完成の定義 DEEP DIVE 思考の叩き台としての完成の定義（Webアプリの例） ▸ コードやアセットがバージョン管理システムに登録されている ▸ コードは他の開発者によってレビューされている ▸ ユニットテストをすべてパスしており、カバレッジが90%以上である ▸ インテグレーションテストをすべてパスしており、主要ケースをカバーしている ▸ IE、Edge、Chrome、Safari、Firefoxで動作することが確認できている ▸ 静的解析により、重大度AおよびBの問題がない ▸ 必要なドキュメントの作成または更新が行われている ▸ OWASP ZAPでセキュリティの検証が行われていて問題がない ▸ テスト環境にデプロイ済である ※筆者が例として作ったものなので、網羅性や正確性はありません。そのまま使わないこと 20
21. 完成の定義 DEEP DIVE ▸ よくある例だけど、これってどうなのだろうか？ 21
22. 完成の定義 DEEP DIVE 22 プロダクトバックログアイテム、完成の定義、インクリメントの関係 ソフトウェアの顧客向 けの部分 ソフトウェアの内部向 けの部分 プロダクトに関係する 将来の価値を生み出す ソフトウェア以外のも もの（検証や実験、学 の 習など） P B I 完成の定義という共通理解による「検査」 イ ン ク リ メ ン ト その他
23. 完成の定義 DEEP DIVE 23 ※筆者が例として作ったものなので、上記の○△✗？に明確な基準があるわけではない点に注意 仕事の種類が多いほど画一的な基準の適用はうまくいかない 完成の定義 ソフトウェア(顧客 ソフトウェア(内 ソフトウェア以外 将来の価値創出 向け) 部向け) のもの その他 バージョン管理システムへ登録済 ○ ○ ○ △ ？ 他の開発者のレビュー済 ○ ○ ○ △ ？ ユニットテスト全パス＋カバレッジ90% ○ ○ △ ✗ ？ インテグレーションテスト全パス＋主要ケース網羅 ○ ○ △ ✗ ？ クロスブラウザ確認済 ○ ○ ✗ ✗ ？ 静的解析で重大問題なし ○ ○ △ ✗ ？ ドキュメント作成・更新済 ○ ○ ○ ○ △ セキュリティの検証済 ○ ○ △ △ ？ テスト環境にデプロイ済 ○ ○ △ ✗ ？
24. 完成の定義 DEEP DIVE 24 ※筆者が例として作ったものなので、上記の○△✗？に明確な基準があるわけではない点に注意 仕事の種類が多いほど画一的な基準の適用はうまくいかない 完成の定義 バージョン管理システムへ登録済 ソフトウェア(顧客 ソフトウェア(内 ソフトウェア以外 将来の価値創出 向け) 部向け) のもの ○ ○ ○ △ 【このような疑問】 他の開発者のレビュー済 ○ ○ ○ △ インフラ構築はどうなれば完成か？ ユニットテスト全パス＋カバレッジ90% ○ ○ △ ✗ スパイクはどうなれば完成か？ インテグレーションテスト全パス＋主要ケース網羅 ○ ○ △ ✗ プロトタイプやユーザーインタビューはどうなれば完成か？ その他 ？ ？ ？ ？ クロスブラウザ確認済 ○ ○ ✗ ✗ ？ 静的解析で重大問題なし ○ ○ △ ✗ ？ ドキュメント作成・更新済 ○ ○ ○ ○ △ セキュリティの検証済 ○ ○ △ △ ？ テスト環境にデプロイ済 ○ ○ △ ✗ ？
25. 完成の定義 DEEP DIVE 25 そこで、各領域に完成の定義を用意する ソフトウェア(顧客向け/内部向け) ソフトウェア以外(例: インフラ) 将来の価値創出 その他 バージョン管理システムへ登録済 他の開発者のレビュー済 ユニットテスト全パス＋カバレッジ 90% インテグレーションテスト全パス＋ 主要ケース網羅 クロスブラウザ確認済 静的解析で重大問題なし ドキュメント作成・更新済 セキュリティの検証済 テスト環境にデプロイ済 ここを埋める (たぶん一気には埋まらない)
26. 完成の定義 DEEP DIVE 26 そこで、各領域に完成の定義を用意する ソフトウェア(顧客向け/内部向け) ソフトウェア以外(例: インフラ) 将来の価値創出 その他 バージョン管理システムへ登録済 他の開発者のレビュー済 でも定義を埋めること以上に、共通理解こそが透明性を生む (スクラムガイドでは「正式な記述」と言ってるが誤解を生みそう) インテグレーションテスト全パス＋ ユニットテスト全パス＋カバレッジ 90% 主要ケース網羅 クロスブラウザ確認済 静的解析で重大問題なし ドキュメント作成・更新済 セキュリティの検証済 テスト環境にデプロイ済
27. 完成の定義 DEEP DIVE 27 そこで、各領域に完成の定義を用意する ソフトウェア(顧客向け/内部向け) ソフトウェア以外(例: インフラ) 将来の価値創出 バージョン管理システムへ登録済 他の開発者のレビュー済 ユニットテスト全パス＋カバレッジ 90% インテグレーションテスト全パス＋ 主要ケース網羅 クロスブラウザ確認済 静的解析で重大問題なし ドキュメント作成・更新済 セキュリティの検証済 テスト環境にデプロイ済 共通理解がすべて その他
28. 完成の定義 DEEP DIVE ▸ 完成の定義を「いつ」、「どうやって」決めるか？ 28
29. 完成の定義 DEEP DIVE 29 完成の定義（スクラムガイド2020） インクリメントの完成の定義が組織の標準の一部となっている場合、すべてのスクラムチームは最低 限それに従う必要がある。組織の標準になっていない場合、そのスクラムチームはプロダクトに適した 完成の定義を作成する必要がある。 開発者は完成の定義に準拠する必要がある。プロダクトに関わるスクラムチームが複数ある場合、共通 の完成の定義を作成して、それに準拠する必要がある。 -- スクラムガイド2020
30. 完成の定義 DEEP DIVE 完成の定義をいつ作るか？ ▸ 完成の定義は最初のスプリント1の開始前までに作るのが望ましい ▸ スクラムガイドには明確にそうは書いていない ▸ ただし完成の定義を満たさないと、PBIはインクリメントにならない、と明示されている ▸ つまりプロダクトバックログアイテムに着手する前に必要になる ▸ それはスプリント1の開始前になる ▸ ただ、継続的な手入れは必要（「正式な記述」という言葉は誤解を招きそう） ▸ 新たな種類の仕事が登場する場合には、随時更新していく ▸ これはリファインメントの作業から派生する可能性がある ▸ 今まで受け入れ基準と呼んでいたもののうち共通するものは完成の定義になるかも 30
31. 完成の定義 DEEP DIVE 31 完成の定義をどう作るか？ ▸ 「完成の定義が組織の標準の一部となっている場合、すべてのスクラムチームは最低限それに従う必 要がある」 ▸ 会社として従うべき基準が決まっているなら、それをもとにする ▸ これは議論の余地が多そう。プロダクトの種類に依存 ▸ 不足部分はスクラムチームで足せば良い ▸ 「組織の標準になっていない場合、そのスクラムチームはプロダクトに適した完成の定義を作成する必 要がある」 ▸ 組織の標準がなければ、スクラムチームで作る
32. 完成の定義 DEEP DIVE ソフトウェアやインフラでどの程度を目指すのか？ 32
33. 完成の定義 DEEP DIVE 完成の定義をどう守るのか？ ▸ 全員が完成の定義の内容を理解していなければいけない ▸ 誰でも見える形で文書化する（スクラムガイド2020で「正式な記述」とされた） ▸ 一方で、全てを詳細に記述することは不可能であり、それを維持することはできない ▸ 人間の力の活用は必要（チームメンバーによるレビューなど） ▸ 自動化できるものは自動化する ▸ 意識しなくても守れる仕組みを作る ▸ スプリントレトロスペクティブなどをきっかけにして改善していく 33
34. 完成の定義 DEEP DIVE 完成の定義をどう守るのか？ ▸ 全員が完成の定義の内容を理解していなければいけない ▸ 誰でも見える形で文書化する（スクラムガイド2020で「正式な記述」とされた） ▸ 一方で、全てを詳細に記述することは不可能であり、それを維持することはできない 共通理解がすべて ▸ 人間の力の活用は必要（チームメンバーによるレビューなど） ▸ 自動化できるものは自動化する ▸ 意識しなくても守れる仕組みを作る ▸ スプリントレトロスペクティブなどをきっかけにして改善していく 34
35. 完成の定義 DEEP DIVE 35 まとめ ▸ 完成の定義はインクリメントに対するコミットメントになった ▸ インクリメントは、過去と今回のインクリメントの集合体で、価値があり、プロダクトゴールに寄与 ▸ プロダクトとは価値を運ぶもので、ソフトウェアが中心だがそれだけに限らない ▸ 必然的に、プロダクトバックログにはソフトウェア以外のものも含まれる ▸ 完成の定義を満たさないとプロダクトバックログアイテムは完成しない ▸ つまり、さまざまなプロダクトバックログアイテムにあわせた完成の定義が必要 ▸ 完成の定義はスプリント1の前に用意する。会社の標準があればそれを踏まえ、なければスクラムチームで検討 する ▸ 文書化によって見える化し、自動化や仕掛け化によって意識しなくても守れるようにする。またレビューを活用す る。レトロスペクティブなどでスクラムチームとしての守り方を改善していく
36. 完成の定義 DEEP DIVE 36 まとめ ▸ 完成の定義はインクリメントに対するコミットメントになった ▸ インクリメントは、過去と今回のインクリメントの集合体で、価値があり、プロダクトゴールに寄与 ▸ プロダクトとは価値を運ぶもので、ソフトウェアが中心だがそれだけに限らない 共通理解がすべて ▸ 必然的に、プロダクトバックログにはソフトウェア以外のものも含まれる ▸ 完成の定義を満たさないとプロダクトバックログアイテムは完成しない ▸ つまり、さまざまなプロダクトバックログアイテムにあわせた完成の定義が必要 ▸ 完成の定義はスプリント1の前に用意する。会社の標準があればそれを踏まえ、なければスクラムチームで検討 する ▸ 文書化によって見える化し、自動化や仕掛け化によって意識しなくても守れるようにする。またレビューを活用す る。レトロスペクティブなどでスクラムチームとしての守り方を改善していく
38. 完成の定義 DEEP DIVE スクラムにおける完成は、あくまでスクラムのなかの話に過ぎない ▸ プロダクトは完成しない ▸ 機能として完成しても、それが役に立たないかもしれない ▸ ずっとフィードバックサイクルを回さないといけない ▸ スクラムの完成は、スクラムでの完成でしかない 38

Comment

No comments...