- プログラミングの納期が守れなくて悩んでいる
- 納期間際になると胃が痛くなる
こういった悩みをもった方向けに、プログラマの納期の守り方について解説します。
目次
プログラマが納期を守る方法
正直なところ、難易度の高いシステム開発になればなるほど、納期を守ることは無理ゲーです。
なので、「自分のせいで納期に間に合わないことを防ぐ」ことに集中することが重要です。
少し脱線しましたが、納期を守るために気を付けるべき点は次の4点です。
- リスクが大きい作業の工数は多めにとっておく
- リスクが大きい機能から作業着手する
- 仕様の不明点は回答期限つきで質問する
- 見積もり時点で成果物（ソースコードなど）を作り始めてしまう
①リスクが大きい作業の工数は多めにとっておく
プログラミングの工数を正確に見積もることはほぼ無理ゲーです。
似たようなプログラムでも、案件・システムごとに微妙に仕様が違うからです。
とくに、下記の3点のリスクがあるか確認します。
- 始めて担当する機能やプログラミング言語である
- 要求仕様があいまい
- ソフトウェア設計・プログラミング難易度が高い
始めて担当する機能やプログラミング言語である
始めて担当する機能・プログラミング言語の場合、そのことをお客様に正直に伝えて工数を多めにとっておくべきです。
たとえば、UI機能しか作ったことがないエンジニアが、いきなり通信制御機能を実装する場合などです。
機能ごとに不具合が生じるパターンなどが決まっていますが、初心者がそれを予測することは不可能です。
要求仕様があいまい
要求仕様があいまいな場合は、早めに質問をするべきです。
「この質問の回答がないと工数が正確に把握できない」と言う場合、何としてでも見積もり時点で質問をするべきです。
見積もり段階で質問ができなければ、「この仕様が不明なので見積もりの粒度がかなり粗くなりました」と正直に言うのがよいでしょう。
ソフトウェア設計・プログラミング難易度が高い
プログラミング難易度が高い場合も工数を多めにとる必要があります。
たとえば、他アプリケーションとのやりとり（通信制御）が多い機能の場合、特定の条件が成立した場合のみ不具合が発生するケースがあります。
他アプリケーションと組み合わせた時に予期せぬ動作になることはよくあります。
そうなった場合、大幅な仕様調整が発生する可能性があるので、それを見越して多めに工数を見積もっておく必要があります。
②見積もり時点で成果物（ソースコードなど）を作り始めてしまう
見積もり時点で成果物を少しずつ作り始めてしまう手もあります。
もはや見積もりとは言えない裏技ですが、人間は経験していないことを予測することは難しいので、最終手段として考えておきましょう。
体験談
私がエンジニアだった頃、お客様から「絶対に工期を遅らせることができない」と注文が入る場合がありました。
そういった場合、自分の身を守るために、ソースコードを先に少し作ってみてどれくらいの難易度と工数がかかるかを確認しました。
何かしら理由をつけて「見積もりは明日中に提出します」と伝え、見積もりと同時並行でプログラムも作ってしまいます。
もしくは、自宅に帰って軽くプログラミングの予習をして見積もり時間を推測することをします。
それくらい、プログラムの製作期間を正確に見積もりすることは難しかったです。
③リスクが大きい機能から作業着手する
見積もりが承認され、いざ作業開始となった場合は、リスクが大きい機能から作業を着手すべきです。
なぜなら、リスクが大きい機能は問題が発生しやすく、納期に影響する可能性が高いからです。
例
通信制御機能を実装する際、「プログラムを完成させて他アプリケーションと組み合わせたが、うまく通信できなかった」となることはよくあります。
そういった場合、仕様調整やプログラム修正が発生します。
とくに仕様の調整作業には時間がかかります。
早めに仕様の不備・不明点を洗い出してお客様にボールを投げておき、その間は別の機能の開発を進めることで、納期に遅れる確率を減らせます。
④仕様の不明点は回答期限つきで質問する
仕様の不明点が発生した場合は、回答期限つきで質問するのが鉄則です。
「〜までに回答がなければ、納期に間に合わないため、恐れ入りますが回答お願いします」という形で質問することによって、早めに相手にボールを投げてしまいましょう。
注意点として、「１時間以内に回答お願いします」など、あまりにも回答期限が短すぎるのはNGです。
質問によっては仕様を変更しなければならないパターンもあり、時間がかかります。
回答期限は1〜2日後にしたほうが悪印象をもたれずに済むでしょう。
どうしても緊急の場合は回答期限を短くするのも仕方ありませんが、「工程管理がヘタな人」というレッテルを貼られてしまう可能性が高いです。
それでも納期を守れない場合
納期を守れないことが分かった段階で、早めにお客様に連絡します。
見積もりミスや手戻り作業の増加などにより、自分のせいで納期が遅れるのであれば、なおさら連絡は早ければ早いほどよいです。
連絡する際は、以下も一緒に伝えます。
- 納品可能日(どれくらい遅れるか)
- 納期に間に合わない理由
納期に間に合わないと分かった段階で、再計画をして納品可能日がどれくらい遅れるのか見積もっておきます。
納期に間に合わない理由としては、できる限り「自分だけのせいで遅れたわけではない」「お客様に納得してもらえるだけの予想外の出来事が起きた」ことを伝えられるかがポイントです。
例えば、次のような理由であれば、そこまで悪印象はもたれないでしょう。
- 他担当者の機能で大規模なバグがあり作業がストップした
- システム仕様不明点の質問に対する回答が提示した回答期限までに返ってこなかった
「最大限やるべきことをやった」上で納期に遅れたのであれば、「今回は仕方ないかな」とお客様に思ってもらえる可能性も高くなり、次のプロジェクトの仕事にも影響が少ないです。
逆に、「何も対策をできずに納期に間に合わなかった」ならば、今後そのお客様から仕事を受注できる可能性も低くなってしまいます。
納期に対する心構えで重要なポイント
納期に対する心構えで重要なポイントは次の通りです。
- 他メンバーへ何かを依頼する場合、全て期限日付きで依頼すること！！！
- 自分のせいで納期に遅れることを何としてでも避ける心構えを常に持つこと
- 自分のせいで納期を守れない場合、できる限り迅速に連絡をすること
まず、誰かに
- 「質問を回答してください」
- 「TBDとなっている上位仕様を決めてください」
- 「ソフトウェアのバグを直してください」
などを依頼する場合、「この日までに対応してくれたら自分の進捗は遅れない」という期限日を確認します。
そして、自分が希望する対応完了期限日を依頼相手に確認します。
この確認は、以下の意味において非常に重要です。
- 希望の期限日までに依頼の対応が完了できないと言われた時点で、自分の納期が守れないことが確定するため
- 依頼される側は自身の本来の作業を優先し、依頼された対応を後回しにしがちであるため
体験談
メールで依頼する際は、プロジェクトリーダー(工程管理責任者)をメールの写し(CC)に入れておき、メール本文に「この期限日までに依頼の対応が完了しなければ、私の工程がXX日遅延する見込みです。」と書いていました。
こうすることで、依頼相手の本来の作業と自分の依頼の対応のどちらが優先であるのか、プロジェクトリーダーに判断を促すことができるからです。
あとは、自分のせいで納期に遅れないことだけを考えて仕事に取り組めばよいです。
私がエンジニア時代の頃は、「自分のせいで納期に遅れないようにする、自分のせいで納期に遅れないようにする・・・」と常に暗示をかけながら仕事をしていました(^^;)
本当の理想は、他メンバーの手伝いもできるくらいゆとりをもった作業計画にできればベストです。
しかし、たいていのプロジェクトは、少ない人数・短い工期でより多くのアウトプットを出して利益を得なければならないので、ゆとりをもてる望みは薄いです。
まとめ
プログラマの納期の守り方について解説しました。
ポイントとしては、「自分のせいで納期に間に合わないことを防ぐ」ことに集中することです。
「自分のせいで納期に遅れる」＝「エンジニアとしての能力が低い」とみなされやすいです。
正直ベースで実力に見合った大きめの工数を出しておけば、リスクは少なくなるでしょう。
プロジェクト全体の納期（工期）は、プロジェクトリーダーの責任範囲です。
まずは自分の担当機能の納期を守ることに注力しましょう。