タスクの追加や仕様変更は問題ではない

読んだ感想

ほとんどの場合、仕様書の作成者は全てを考慮していなかったことが判明します。それはいつも、設計や開発を始めてから問題が起きて、多くの仕様に問題があるせいだとなってから判明するのです。

作り始めないと見えてこなかった問題が出てくるのはよくある話である。その問題に対する対処が何かの処理を追加することになるのは悪いことではない。問題が出てくればそれに対処するためになにか追加する、もしくは仕様が変更されるのは当たり前の話で作り始めて初めて気づいた問題をそのまま放置するほうがまずいだろう。

では何が問題かといえば、タスクが追加された、もしくは仕様が変更された時点でスケジュールが変更されないことが問題なのだ。

開発者は一番最初に渡された仕様から自分が作るのにかかる時間を見積もってスケジュールを作っている。ここにバッファが入っているかもしれないが、そのバッファはあくまで一番最初に渡された仕様によるバッファだ。仕様変更やタスクの追加に使うのものではない。なので、スケジュールを変更せずにタスクの追加や仕様の変更を依頼するということは、「スケジュールまで作業する時間を増やしてくれ」という依頼を言い方を変えているにすぎない。最悪の場合は「働いている時間が足りないからもっと働け」と言われたと相手に認識されるてもおかしくないのである。

このスケジュールの変更、タスクの追加が定常的に行われだすと、開発者は自分を守るためにバッファを多めに取るようになる。仕様変更やタスクの追加を見越してバッファを増やしてスケジュールを取るようになるのである。そして、開発者が提示してきたスケジュールを見た責任者は前回に比べて作業量が少なく感じ、バッファを大量にとっているのではないかと勘ぐりだす。これによりスケジュール決定時に無駄な腹の探り合いが行われるようになるのである。開発者はこれぐらいしかできない理由を並べ立て、責任者はスケジュールまでにこれをやらないといけない理由を並べ立て、どちらが正しいかを主張しあうのだ。非常に不毛で無駄な話し合いをスケジュールを決める度に行うことになるのである。

相手がある開発はスケジュールが決まるのはしょうがない。ここまでにできていないと準備した広告の意味がなくなる場合や、店舗に発送する時間がなくなるなど色々な迷惑がかかる場合もあるだろう。この場合はしょうがない。スケジュールが伸ばせないのであれば頼むしか無い。なんとか間に合わせるために頑張ってくれと頼むのが筋だ。決してタスクの追加や仕様の変更ができて当然だと考えて言うべきでない。その一言は相手の見積もりが正確ではないといっているのと変わらないのである。

勘違いしてはいけないのは開発者と責任者は敵ではなく味方だ。どちらも良い物を作るために一生懸命作業をしている。そのことを念頭に置いて腹の探り合いなどはせずに、スケジュールを決めたいものである。