切羽詰まったプロジェクトを生み出すUndone Workの影響
新年明けましたね。あけましておめでとうございます。りょくちゃです。今年もよろしくおねがいします。
開発が進むにつれて予期してなかった問題が発覚するんですが、なんとかならないでしょうか。よくプロジェクト終盤に炎上状態になります。
自分はこういうプロジェクトにUndone Workの考え方を紹介することがあります。今日は文章にして誰にでも同じように伝えられるようにしてみます。みなさんのチームで参考になれば嬉しいです。
Undone Work
まずUndone Workを説明させてください。自分がしる限り大規模スクラムフレームワークLeSSが元ネタの概念になります。
Undone WorkはDoneの定義をみたしたプロダクトバックログアイテム (以下PBI) をリリース可能にするまでに必要なタスクです。
例えば、Doneの定義を満たしてもリリースまでにパフォーマンステストが必要な場合、そのテストはUndone Workってことです。この場合、パフォーマンステストはDoneの定義に含まれていません。
スクラムに馴染みがない方向けに例えるなら、実装ステップを終えて、実装ステップでやろうと計画してやれなかったことをテスト工程で行っていれば、このやれなかったことがUndone Workって感じですね。
この場合、やれなかったことが予め実装ステップの完了条件（Doneの定義）に組み込まれているのかどうかがポイントになるわけなんですが……ちょっとややこしい。厳密には計画されていて後回しになる仕事は「未完了」「Doneしてない」仕事です。つまり、計画すらされていないのがUndone Workってことになります。
潜在的なリスクの隠蔽
臭いものに蓋をするように、あとのステップでなんとかしようとするとプロジェクトの潜在的なリスクが高まるきっかけになります。
どうしてかというと、Undone Workは実施されるまで潜在的なリスクを隠蔽するからです。
パフォーマンステストはいい例じゃないでしょうか。やってみるまでどれだけのリスクがあるのか予めわかりません。テストをした結果、終盤で設計の練り直しが必要になるとわかったら……。
遅延のリスク
Undone Workはチームに遅延のリスクを持ち込みます。
Undone Workは積み重なるとリリースに向けてやらなければいけないことが時間を圧迫するためチームの柔軟性を下げてしまいます。結果として計画の見直しが必要になります。もし、リリース時期を調整できないとしたら......。
どうやって対応していくか
プロジェクトを観察した結果、どうやらUndone Workがあるようです。さて、どうしましょう。
プロジェクトをスクラムチームが進めているならDoneの定義の見直しをしてUndone Workへの対処をおすすめします。
Doneの定義を満たした結果、すぐにリリース可能なプロダクトになっていることが理想です。こうすれば、曖昧さがなくなりDoneの定義を満たしたけど、やるべきことが漏れてUndone Workになる心配はありません。
Doneの定義に書かれていれば計画段階でやるべきことに気づけるので、予期しなかった問題になることが減るからです。
また、将来のUndone Workを減らすためにできることを考えます。例えば、開発プロセスの構造にアプローチしてUndone Workをへらすアプローチもありそうですね。ウォーターフォールで進めているのなら、プログラムの構築後にまとめてテストをするチームは多いのではないでしょうか。この場合、その構造がチームのリリースに対する予測可能性を下げてしまっているので、早い段階からソフトウェアをDoneの定義に従って完成した状態にしていけるような方針で、プロセスを考え直してみるのもありなんじゃないかなと思います。例えば、スクラムも参考にできるかもしれません。
Undone Workが多くなればなるほど、遅延のリスクと潜在的なリスクの隠蔽は高まっていきます。できる限り早い段階からUndone Workは減らしていくことが吉。そうすれば、チームが予期しない仕事に振り回されることもなく予測可能性がぐんぐん上がって行きますね。それではまた次回！