システム開発をする上で、完了条件は避けて通れない。完了条件とは、いつ仕事が終わったかを定義するものである。この仕事が完成したということをステークホルダー間で合意できる基準といってもよい。

仕事全体の完了を示す完了条件もあれば、仕事が次のステップへと移っていいという指標になる完了条件もある。完了条件は、下位の完了条件が満たされることという完了条件もあれば、同じような大きさの完了条件が全て満たされてはじめて完了となるようなものもある。おおよそ仕事として分割できる単位であれば、完了条件があるといってもよい。それだけに、完了条件は重要である。

完了条件というと、どうも固い言葉で手戻りを許さないウォーターフォール型の開発でしか使われていないと感じる人もいるかもしれない。ところが、スクラムといったアジャイルプロセスであってもDoneの定義（＝完了条件）は重要な位置を占めている。もちろん、ウォーターフォール型の完了条件が静的で事前に計画されたものであるのに対し、スクラムの完了条件は動的で時間経過とともに変化するものであるという違いはある。

完了条件は、同時に責任範囲でもある。ある仕事を担当している人が何を完了すれば、その仕事を完了したとみなすかを定義しているからだ。良い完了条件は、そのステップで必要な作業について過不足なく定義している。その完了条件を満たせば、担当者が責任を果たしていることが明らかになる。

完了条件が定義されていない仕事は、責任の所在があいまいで、いつまで経っても終わらない仕事になる。その仕事の担当者が終わったと思っていても、他のステークホルダーがそう思うとは限らないからだ。基準がないので、「完了したと思う」と「完了しているとは思わない」との間で水掛け論になってしまう。

また、完了条件がなければ管理することはできない。完了が定義されていないということは、何をやるかが明確になっていないということである。何をやるかが明確になっていないということは、それをどれだけ終えているという進捗状況の把握もできない。何かをやっても、それが必要な作業であるのか、余計な作業であるのかも判断できなくなってしまう。

仕事をするときには、完了条件を定義しよう。仕事をしたのに仕事が終わらないのなら、完了条件を見直そう。完了条件は仕事をするうえでの欠かせない要素だ。