完了
「完了条件は難しいらしい。」
どうやら、完了条件を明確にすると云うのは難しいことらしい。振り返ってみれば、特定個人に限らず、けっこう多くの人が苦手としていたように思う。例えば「xxx の作成」と云う作業があった時、その完了条件として「xxx が完了すること」となっていたりするのだ。「いや、だから、どうなったら完了するのかを明確にしないと…」と突っ込みを入れる訳だが…。
「梯子を立てかけておいてくれ!」そんな用事を頼まれたとする。この作業の完了条件は、「梯子を立てかけること」では十分ではない。「梯子が立てかけられた状態になること」である。「パソコンの電源を落としておいてくれ!」なら、「スイッチをオフにすること」ではなく、「電源ランプが消えること」である。もし、電源ランプが付いたままなら、「スイッチをオフにしても、電源が切れないんですけど…」と問題を報告するはずだ。
完了条件は自分が何をするかではなく、何がどのような状態に変化するかである。
- 本を読み終わるのは、読むページがなくなった時。
- 掃除の終わりは、綺麗になったらではなく、掃除する (と決めた) 場所がなくなった時。
- 映画の終わりは、上映するフィルムがなくなった時。
- 「ごちそうさま」は、食べずに残っているものがなくなった時。
- 恋人と別れは、愛の残量がゼロになった時…と云うのは冗談だ。
- 設計は設計が完了したら終わるのではなく、盛り込んでない要件がなくなった時に終わる。
- 関数の作成は、動かない要求仕様がなくなった時に完了する。
- 試験は試験をやったら終わるのではなく、未消化の試験がゼロになったら完了するのである。
すべての物事に適用できる訳ではなく、対象の状態の変化を完了条件にできないものもある。代わりに時間や鶴の一声を完了条件にすることもあるのだが、それは例外と考えて、できるだけ避けるようにした方がいい。もし、どうしても完了条件を設定できない場合は、一つステップを踏まなければならないかもしれない。例えば、未消化の試験がゼロになったかどうかは、試験が数えられるようになっていなければならないから、まずは試験を数えられるようにすることが必要となる。そのためには…と遡って連鎖して行くのだが、今回の話はここまで。
状態の変化として捉えられるかどうかが一つのポイントだと云うお話。*1
*1:システム設計における状態分析と同じスキルが求められる。…と云うことは、ちゃんと完了状態を把握できないところがやった状態分析は、ちょっと怪しいかもしれない。
