どのくらいでできる？

システム開発のプロジェクトでは、プログラマの「時間」は、きっちりと管理されるのが普通である。

例えば、「○○機能は３日でプログラミングする」というように、細かいスケジュールが引かれるだろう。

そういった状況の中、自分に与えられた作業がどのくらいの期間で出来るのか、ということを判断することは非常に重要である。

○○機能のプログラミングを任されたプログラマは、まず、自分がそれを３日でできそうかどうかを見積らなければならない。そして、できそうになければ、最初にそのように主張すべきである。３日後に「できませんでした」と言っていたのでは遅い。

リーダーが３日で出来るというのだから、がんばれば出来るのだろう、などと考えないほうがよい。自分がやる仕事は、最終的には自分が見積り、自分がスケジューリングするのだ。それも「プログラミングという仕事」の一部なのである。

★

スケジューリングが必要なのは、作業を与えられた時だけではない。１日目のプログラミングが終わった時点で、残り２日で全ての作業が出来るかどうかを判断することも大切である。このように、常に残作業を見積りながら仕事を進めなければならない。

そして、予定から遅れそうであれば、すぐにリーダーに報告する。これは絶対に躊躇してはならない。責任を感じて言い出しにくいという人もいるかもしれないが、開発作業の遅れなんて日常茶飯事だ。気にすることはない。

まともなリーダーなら、遅れを報告をしなかったことを責めることはあっても、遅れたこと自体を責めることはないだろう（※１）。

とにかく、遅れの報告は、早ければ早いほど良い。早く報告したほうが、再スケジュールなどの対策が取れる余地が多いからだ。

★

経験が少ないプログラマにとって、作業のスケジューリングは難しいものである。しかし、それをやらなければ、その場その場の思いつきで作業を行うような状態になってしまうだろう。そんなことでは、いつまでに作業が完了するのかわかったものではない。プロのプログラマとしては失格である。

どうしたらよいか分からない人は、まず、与えられた作業について、具体的にはどんなことをするのか、想像してみよう。作業をもっと細かいまとまりに分割して考えるといいだろう。次に、その細かい作業のひとつひとつについて、必要な時間を見積もる。そして、それを時間軸（カレンダー）上に配置するといいだろう。

こういった作業の見積は、プログラマという職種に特別に要求されるものではない。期限付きの仕事をする場合には、当たり前のことだ。しかし、意外と出来ない人も多いのである（※２）。