短納期の案件について考えてみた

今日、ようやくユニットテストまで終わったので、振り返りをしつつ、短納期の案件を考えてみる。

短納期の案件は自分の中では、3ヶ月くらいの案件と想定しているのだけど、今まで楽できたものが一つもない。

今の案件も2月開発スタートでテストも含めて4月工完。そしてステップ数は19Kstep。これを二人がかりでやる。

母体があるからコピペできるとこも多いんだけども。開発作業を進める中で、Struts2に詳しくなったり、C#アプリケーションも作れるようになったり、いいこともたくさんあるけども。

圧倒的に時間が足りない。

本当はユニットテストもしっかりやりたいのに、時間がなく。コーディングも作り込みたいのにタイムアウト。品質悪くなるのも目に見えて、品質管理部門の担当者の引きつる顔が目に浮かぶ。

そもそも問題点は何か？

それほどレベルの高くない三年目(もう三年目か！ヤバス！)を主たる担当者に数えて見積もりを出したところにあるのではないかと考えた。

お前が頑張れよ。という声が聞こえるがそれはおいといて。

そもそもIT企業の見積もりって使える人の頭数を数えて、工数としてカウントし、一人当たりの単価で方式が一般的だけど、ここに個人のレベルがどれほど加味されてるのか謎。

しかもカウントされた人間のプロジェクト中でのレベルアップなんて全くカウントされてないんじゃないか？

こういう短期納期の案件では成長を待つまでもなく納期が迫るから、担当者の意識の高さ、成長の速さにプロジェクトの成否がかかってくるとも思えてくる。

じゃあ見積もりを高くすればいいかというと、そんなことしたら仕事がない。泡を食うのは現場サイド。そりゃ管理部門に苛立ちも感じるよ。

話が逸れたような逸れてないような。

今感じてる結論として、短納期の案件を任された時は、速く成長して成長したことが分からないように楽できる部分を楽すること。速く終わっちゃうと、「あ、こいつ余裕ある。じゃあこれもお願い」なんて言われかねない。徹夜作業は勘弁してください。精神やられます。