納期の遅れはプログラマだけの責任じゃない

大切なことは正確に作業時間を見積もることではなく、チーム全体がソフトウェアのリリースに責任を持つことだと思います。ソフトウェアをリリースする責任はプログラマだけにあるものではありません。見積もりの責任を個人だけに押し付けるのではなく、関係者全てが責任感を持てるような、そんなチームが理想なのではないでしょうか。

工数見積もりの正確さ

職業でプログラマをしていると必ず作業工数の見積もりをします。プログラマは今までの経験からコードの規模やテストにかける時間を予測し、｢これは何週間後にできそう｣といった報告をします。

しかしながら、この工数というものは非常にあいまいです。ほとんど予測通りに進むことはありません。作業終了日時を正確に予測することは難しいかもしれませんが、より正確にする方法はないのでしょうか。

プログラマの見積もり方

｢このプログラム、どのくらいで出来る？｣そう言われたのちの見積もり方法は、ほとんどプログラマの経験とカンに任されています。その時点でまずズレが生じてきます。人の性格によっては楽観的に見る人、慎重に見る人もいますよね。

また、ある程度経験をしたプログラマは、予想より少し多めに見積もるという習慣がついています。予測しなかったトラブルや別の緊急作業が入ったりした場合に備えておくためです。何日か多いぐらいならよいのですが、倍の工数を見積もっていることも少なくありません。

さらに自分だけではなく何人かでプログラムを作成する場合や、作成するプログラムの開発環境やAPIなどにたいして、プログラマがどの程度慣れ親しんでいるかも重要なポイントです。

精度を上げる方法

完璧な工数見積もりは難しいとしても、工数見積もりの精度を上げることが出来ると思われる方法を考えてみます。

少しきつめのスケジュールにする

あまりにも工数に余裕がないと、どこかで火をふくことになり、見積もりの意味がありません。逆に余裕があり過ぎてもよくないです。プログラマは追い詰められないと作業を始めない場合が多いので（笑）
最初に｢ベストケースでこのぐらいかな｣と思った工数＋αぐらいがオススメでしょうか。

定期的に見直しをする

プログラミングに限らず、実際に初めてみないと分からないことは多いものです。最初は｢このぐらいかな｣と思ったのに思わぬトラブルが発生することはよくあります。納期を定期的に見直すことでプロジェクトが火の海になることを防ぐことが出来るでしょう。

チーム全体で責任あるスケジュールを

大切なことは正確に作業時間を見積もることではなく、チーム全体がソフトウェアのリリースに責任を持つことだと思います。

見積もりはあくまで予測であって、完ぺきには出来ないものです。問題は、それを深く考えないで決めてしまうことです。

ユーザに対して納期を決めたから。プログラマが最初にこの期間でやると言ったから。ソフトウェアをリリースする責任はプログラマだけにあるものではありません。見積もりの責任を個人だけに押し付けるのではなく、関係者全てが責任感を持てるような、そんなチームが理想ではないかと。

納期は守ってもバグだらけなシステムを作るチームと、開発状況を逐一正直に報告するチーム。ユーザがどちらを信頼するかどうかなんて、説明の必要はありませんよね。：）