@bussorenre です。
スクラムで議論が難しい要素の一つに「DONEの定義」というものがあります。 「プロダクトが顧客にリリースされるまでに必要なすべての要素」のうち、スプリント中に完了できるものがDONE、できないものがUNDONE というすごくざっくりした定義をしたりしますが、「DONEの定義」という名前に引っ張られてDONEを定義しようとすると上手く行きません（実際上手く切り分けられませんでした）
そこで、とにかくプロダクトの企画からリリースまで、ありとあらゆるすべてのタスクを列挙していき、以下の３つに整理します。
- このタスクはチームの責務であると明確に言えるもの
- このタスクはチームの責務ではないと明確に言えるもの
- どちらとも言えない、わからないタスクや、今まで存在しなかった新たなタスク
「このタスクは開発チームであると明確に言えるもの」はそのまま「DONEの定義」に放り込むことができます。設計・実装・レビュー・テスト等、どんな組織でもおおよそ存在するであろうタスク要素は分解が簡単ですが、そうでないタスクも全然あると思います。
「このタスクは開発チームの責務ではないもの 」と明確に言えるものは、基本的にDONEでもUNDONEでもない、「やらなくていいタスク」として扱えます。しかし、このリストは定期的に見返す必要があります。「本当にやらなくて良いタスクだったのか？」「組織の境界がどうなっているのか？」という、スクラムチームの周囲を取り巻く環境を把握する唯一のコンパスになるからです。
そして、最後「どちらとも言えないわからないタスク」は「UNDONEの定義」になります。UNDONEは言い換えると負債です。UNDONE が積み重なれば積み重なるほど、プロジェクトはどこかで爆発します。UNDONE と定義されたタスクを、いかにして「DONEの定義」に落とし込み負債の解消に務めることが出来るかどうかは、スクラムマスターの腕の見せ所の一つです。
過去の経験上、しっかり意識していないと「UNDONE」に陥りやすいなと考えているタスクは
- リリース
- QA
- ドキュメンテーション
の３つです。特にドキュメンテーションは本当に難しいです。大真面目にやると、実際にコードを書く業務の３倍くらいはドキュメンテーションの読み書きに費やしていってると言っても過言じゃないくらいの膨大な量になるし、かといって適当にやると後から「このコードなんでこんな挙動しているんだ？」と言って、混乱のもとになって結果的にタイムロス（=負債）になります。また、一度ドキュメントを書いたから良いというわけではなく、コードと同様にドキュメントもメンテナンスされ続ける必要があります。このドキュメント保守が非常に厳しい。
ドキュメンテーションは「コード」に対するドキュメントの話だけでなく、あらゆる要素に対して発生します。例えば、コンテンツの管理（どこにどのファイルが格納されているか）といったドキュメントであったり、顧客対応履歴（ex.課題管理票の更新）であったり、そもそもプロジェクトに関わるファイルがあっちこっちに散らばってどれがどのファイルだったかわかりにくくなったりなど。
他にはenvファイルの更新（devとprodで違う値をどう確認するか）とかがUNDONE になったりするでしょうか。
「全体のタスク - UNDONE = DONE」という至極シンプルな計算で DONE を定義すると、DONEの定義に明確性が増し、またチームが持つ課題を認識しやすいと思われます。DONEの定義をにらめっこしてても良いDONEの定義はできません。
