現場で出された計画表を真に受けてはいけない

» 2020/08/31

現場で出される計画表はデタラメだと思った方がいいです。計画表というより、理想表という方が正しいです。実際、開発や構築案件で出される計画は、おおよそ以下のようなものが多いかと思います。

要件定義からコーディング、コーディングを完了させて、単体試験、結合試験と進んで導入試験をクリアしてプロジェクトが完了というパターンです。

ただ、実際はこんなきれいなシングルタスクでプロジェクトは進みません。この予定を実現するとすれば、以下のような動きをしなければ実現できないと考えています。

要件定義の段階で、調査と称して先行コーディングと先行単体試験を済ませておく必要があります。お金をもらっていないのにコーディングと調査をするのは、費用の無駄かと思うかもしれませんが、調査した内容は会社の情報資産として活用しましょう。そういう先行投資と資産活用をしないから、要件定義がまともにできないのです。

もし、単体試験や結合試験で問題を検出したら、本来であれば「テストしたかいがあった」です。しかし、お客さんやエライ人は「けしからん」と怒ります。予定表に引かれたテストは、テストであってテストではありません。シナリオです。ノーミス、もしくは想定内の軽微な不具合だけが検出されるというシナリオを実現する必要があります。なので、実際の単体試験が始まる前に試験を済ませて、実際のテスト期間にするのは、テストではなくテストの演技です。

実際には、要件定義が終わった段階でおおよそのコーディングと検証を済ませておく必要があります。それができなければ、人の三倍の速度で、単体試験をこなしながらコーディングと結合試験の準備をする必要があります。案件が始まった段階で結合試験の条件を調べていかないと、手続き等が間に合わない等のトラブルが発生しやすくなります。導入試験に関しても、同様の考え方が適用されます。基本は、計画表の予定が始まってからやることは、作業ではなく演技です。

あと、現行踏襲や他のプロジェクトからドキュメントをコピペすればいいという考えから、ドキュメントを作成する工数が見積もられていないケースが非常に多いです。だいたいコピペで済むつもりで舐めてかかって、内容がまとまらずにグチャグチャなドキュメントで辻褄を合わせるのが、よくあるケースです。コピペで済むと舐めてかかる人より、普通に一から書く人の方が質が高いドキュメントが早く書けます。工程表には平行作業で行う前提で、ドキュメント作成の枠を設けておきましょう。

現場で出される予定表は、別プロジェクトの資産をコピペして工数を削減する前提なので、準備と調査のプランがごっそり抜けがちです。そこを押さえると、炎上しても勢いを抑えることができます。