やることベースから、完了ベースへ

「システム開発のスケジュールは完了ベースで書くべし」

システム開発で用意されるスケジュールは、軒並み "やることベース" になっている。いつからいつまで、何をするのかをガントチャートなどで表現している訳だが…。

例えば、「100m 走る」と云う表現は、一見すると "やることベース" だが、ゴール地点が 100ｍ 先であることが明確になっている。「コップの牛乳を飲み干す」なんてのも同様、コップに入っている牛乳の量が完了基準となる。これらは、一見すると "やることベース" だが、実質は "完了ベース" のタスクなのだ。

ところが、システム開発で「基本設計をする」と云うのは完了基準が実に曖昧だ。「基本設計書」と見出しを付けて、罫線でレイアウトをととのえて、それっぽい単語が並んでいれば、多くの人にはその善し悪しは分からない。だから、仕様の曖昧さや問題が内包されたまま、期日になった時点で完了として、次の工程に進んでしまう。宝くじに当たるほどの幸運に恵まれれば、完成度の高い基本設計書が作られるかもしれないが、どこの会社のどの開発チームの誰が担当するかで、できあがってくるモノの程度はさまざまになるのは、多くの人が経験している周知の事実だろう。このように、完了基準が曖昧で何をするかだけが決まっていることを "やることベース" と呼ぶ。これが根本原因とまでは言わないが、解決しなければならない大きな問題点の一つだ。"やること" ではなく、"完了条件" にシフトしてゆかなければならないことを強く訴えたい。

何年か前から、テストファーストが提唱されている。これは、テストが通ればコーディング完了となるので、コーディング作業を "やることベース" から、"完了ベース" に変える良い手段だ。このように、完了基準の曖昧さを排除することが、認識の共通化につながり、効率の改善を進め、期待値と実質の差異の現象をもたらす。無駄な作業なんて、誰もやりたくないし、誰もやらせたくないのだ。そのためには完了基準の明確な共通認識が必要なのだ。曖昧だと期待値が大きくずれるんだから。

"やること" として記述されたタスクは、完了条件を簡略化したエイリアスだと云う共通認識を持ちたいものだ。