完了の定義を決める

「できました」と言ったのに、「まだ終わってない」と返される。お互いに悪気はないのに、なぜかモヤモヤする。そんなことはありませんか。

ケンジが、ひなたに声をかけました。

「終わり」は人によって違う

「終わった」という言葉は、人によって指す範囲が違います。

• 画面ができたら終わり（デザインや見た目）
• 動いたら終わり（実装）
• テストして問題がなければ終わり（品質）
• お客さんが OK と言ったら終わり（承認）

これが食い違うと、「できました」「まだ終わってないよ」の往復が起きます。だれも怠けていないのに、手戻り（やり直し）が生まれます。

同じ「終わった」でも、どこまでを指すかで段階があります。

画面ができた見た目→動いた実装→テストした品質→お客さんが OK承認

自分の「終わり」が、どの段階かを見てください。

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

完了の定義とは、「この状態になったら、完了としてよい」という条件を、先に決めておくことです。英語の頭文字から DoD とも呼ばれます。

課題 1 件ごとに決めてもよいですし、チームで共通のルールを決めておいてもかまいません。

完了条件の書き方

確かめられる形で書く

「きちんと動く」は、人によって基準が違います。だれが見ても、できた・できていないが判断できる形にします。

あいまい	確かめられる形
きれいに表示される	PC・スマホ（幅 375px）で、デザインどおりに表示される
ちゃんと送れる	送信すると、確認メールが届く
お客様に確認してもらう	桜井さんから「OK」の返信をもらう
速くする	トップページの表示が 3 秒以内になる

「だれが」判断するかも決める

完了を決める人は、作った本人とは限りません。

• 作った人が自分で確認すれば完了
• 別の人（レビュー担当）が見て完了
• お客さんが確認して完了

どれにするかで、必要な日数が変わります。お客さんの確認が要るなら、その待ち時間も、予定に入れておく必要があります。

「だれが確認して終わるか」は、ステータスで表せます。たとえば、こんな画面です。

• 「確認待ち」の列は、作業は済んで、確認を待っている課題
• 「完了」の列に、確認が済んだ課題が移る

共通の完了条件を持つ

課題ごとの条件のほかに、チームで共通のチェックを決めておくと便利です。たとえば Web 制作なら、次のようなものです。

• 主要なブラウザで表示を確認した
• スマホで崩れていない
• 誤字・脱字を確認した
• リンク切れがない

完了条件は「あとから変わる」こともある

打ち合わせで条件が変わったら、本文を直して、変更があったことをコメントに残します。黙って基準を動かすのが、いちばんトラブルのもとです。

まとめ

• 「終わり」の意味は人によって違い、ズレが手戻りを生む
• 完了条件は、確かめられる形で、先に書いておく
• だれが完了を判断するかも決める
• チーム共通のチェックリストがあると、抜けにくい
• 条件が変わったら、記録を残す

akamine でやるなら

akamine では、課題の本文に完了条件を書き、ステータスを「確認待ち」から「完了」へ動かすことで、「だれが確認して終わるか」を表せます。完了にするのは、本文の完了条件がそろったときです。ステータスの動かし方は「ステータスを動かす」を見てください。

• 画面の下の帯で、ステータスを順に進められる
• 「完了」は帯のいちばん右にある

関連する記事

• 本文の書き方（背景・やること・完了条件）
• ステータスの設計
• 課題の粒度はどのくらい？