読んで欲しいと思っている人

POやステークホルダーと品質について共通言語や目標が欲しい開発者
開発者と品質について共通言語や目標が欲しいPO
スクラムで品質について困っている人

読むとわかること

完成の定義（Definition of Done）とはどんなものか
スクラムと非機能的な品質の関係性
タイミーのWorkingRelationsSquadでどんな完成の定義を作り、活用していきたいと思っているか

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

インクリメントが常に守るべき状態のことです。スクラムガイド¹では以下のように説明されています。

完成の定義とは、プロダクトの品質基準を満たすインクリメントの状態を⽰した正式な記述である。プロダクトバックログアイテムが完成の定義を満たしたときにインクリメントが誕⽣する。

つまり完成の定義を満たしていない成果物は、いかに優れた機能であってもインクリメントとなることはありません。スクラムの原理原則として、完成の定義で合意した事柄は後回しにされることはありません。

また、完成の定義の対象はインクリメント全体です。プロダクトバックログアイテムによって生まれる差分ではありません。プロダクトは常に全ての完成の定義を満たすことが要求されます。

なぜ完成の定義を作ったのか

スクラムの原理原則に則るのであれば、そもそも必要だから作ります。もっと言えば、完成の定義の作成はありとあらゆるプロダクトバックログアイテムの完了よりも優先されます。完成の定義がないとプロダクトバックログアイテムが完成した状態がわからないためです。

しかし今回はそのような教科書的な話ではなく、もっと現実で発生した問題に基づいて作成理由をお伝えできればと思います。大きく3つの問題を解決したかったために作成しました。

プロダクトが抱えている課題を明らかにしたい
スクラムチーム内の開発者が非機能的な品質を改善をするために発生する説明責任を緩和したい
技術改善Weekをやめたい

1つずつ解説したいと思います。

プロダクトが抱えている課題を明らかにしたい

さて、この説明をするためにはタイミーの組織構造を説明する必要があります。タイミーの組織は一部Spotifyモデルを参考にした概念を採用しています。

普段共に活動するチームのことをSquadと呼び、同じ技術領域を担当しているエンジニアの集合をChapterと呼びます。

タイミーでは基本的に開発を行なっているチームが運用も行います。一方でそうは言ってもSquadが生んだ問題をChapterが改善を試みているという場合があります。また、特定技術において生まれた新技術などはChapterの単位で取り組まれることがほとんどです。本質的にはプロダクトが開発速度向上やメンテナンス性を保つためにやらなければならないことであるのに、その管理をChapterに負わせてしまっているという状況になっています。

結果として、プロダクトの課題であるはずなのにスクラムチームの関心から外れてしまっています。これをなんとかするために今回作成した完成の定義ではこれまでChapterの関心事とされていたことも明確に記述しています。下記はその一例です。

これまではChapterというところで隠されていた課題がスクラムチームに対して透明になっています。これによって今のプロダクトはどんな課題を抱えているのかが明らかになりました。

スクラムチーム内の開発者が非機能的な品質を改善をするために発生する説明責任を緩和したい

先ほどの話につながっているのですが、Chapterは課題は扱っているもののそれを解決する人は基本的にSquadに所属しています。結果としてChapterで対応するとなった課題はSquadに持ち帰られ、POに交渉を行い着手するという状況になっています。

交渉するというのは基本的にコストです。また、POがプロダクトバックログに対して説明責任を果たせば果たすほどその並び順は開発者にとって納得のいくものとなっていきます。結果としてChapterに持ってきた課題は対応が後回しにされることがしばしばありました。

スクラムの基本的な考え方としては品質が基準に達していないインクリメントはリリースできないはずなのに、品質に対する対応が劣後していく特殊な事態となっています。

ここに対して完成の定義としてチームで合意してしまうことで果たすべき説明責任は少なくなっていき、品質の改善に対応しやすくなるのではないかと考えています。

技術改善Weekをやめたい

WorkingRelationsSquadでは技術改善Weekという取り組みを実施しています。6週間に1度プロダクトバックログアイテムではなく、各々好きな技術的な課題に取り組むという時間です。

開発者が交渉を行うことなく非機能的な品質を維持するために始めた取り組みです。

改めて考えるとこれはスクラムチームの課題を覆い隠すことに一役買っています。なぜならスクラムチームが品質に一部問題があるようなリリースをしたとしても後日対応できてしまい、スクラムチームに対応しなければならないこととしてFBが蓄積していかないためです。

常に品質の高い開発をしていれば技術改善Weekは必要ないはずなのに、なぜか品質が技術改善Weekに依存する形になり、スクラムチームは問題を解決するきっかけを失っています。ただし、現時点では技術改善Weekは日々開発を続ける中で対応できない課題に対応するために存在しています。やめるためには日常的により品質の高いインクリメントを作り続ける必要があります。技術改善Weekは直ちに止める話になるわけではありませんが、通常のスプリントで品質の高いプロダクトが開発できるようになれば不要になると考えています。

技術改善Weekは本質的にはリリーススプリントと大差ありません。この存在によって意味のあるインクリメントをスプリントレビューで提供し続けることができない瞬間があるというのも大きな問題だと考えています。

成果物

上記を考えながらWorkingRelationsSquadでは下記のような完成の定義を作ってみました（画像は一部抜粋）。

現状Doneとなっているものも、Undoneとなっているものもあります。Undoneの中でも開発対象の差分だけであれば守れるものもあれば、そうでないものもあるというのが現状です。全てをDoneにできるように頑張りたいと思っています。

余談

チームメンバーの感想

完成の定義を作った時に下記のような感想がありました。

理想はありつつ、やっていないことが可視化されて厳しい気持ちにもなった

これをみた時はかなり嬉しかったです。

スクラムはできていること、できていないことを全て透明にしていくフレームワークです。スクラムの取り組みによって、できていないことが明らかになったのであればそれはスクラムの考え方ではとてもポジティブで大いなる第一歩だと感じています。

こう言った感想を素直に伝えてくれるチームメンバーには感謝の気持ちでいっぱいです。

完成の定義とプラットフォームエンジニアリング

完成の定義はプラットフォームエンジニアリングをやっていく上でかなり面白いツールだと思っています。なぜならUndoneが多ければ多いほど、チームは認知負荷が高いと考えることができるためです。本来やらねばならないことが頑張らないとできないという状態ということもできます。また、複数のチームで運用して共通してUndoneなのであれば、そこにプラットフォームチームが介入する余地があるでしょう。うまくゴールデンパスを作れれば課題内在性負荷や課題外在性負荷が下がり、1つDoneが増えるのかもしれません。同じ期間のスプリントでやれることが増えたとしたら、それはプラットフォームエンジニアリングの大きな成果になると思っています。

また、場合によってはプラットフォームチームから何かを強制するためにも活用できると考えています。これはプラットフォームチームがセキュリティやコストなどの側面から何かを依頼する際に良いインターフェースになると考えています。

タイミーではそれぞれのストリームアラインドチームの認知負荷が高いという話があって2年くらい経っていますが、いろんなツールや考え方を駆使して下げていければ良いと考えています。