- プログラミングの納期が守れなくて悩んでいる
- 納期間際になると胃が痛くなる
- 「自分のスキルが低いせい」だと自分を責めてしまう
こういった悩みをもったプログラマー向けに、納期を守るための工夫と、それでも遅れそうな時にダメージを最小化する伝え方を解説します。
なお、納期を守りにくいのは、必ずしも個人のスキルだけの問題ではありません。仕様の不確実性や、関係者間の依存関係に起因する部分も大きいです。この記事では、その前提でできるだけ「自分でコントロールできる範囲」に焦点を当てて整理しました。
そもそも、プログラマーの納期はなぜ守りにくいのか
プログラミングの工数を事前に正確に見積もるのは、現実的には難しいことが多いです。
似たような機能でも、案件・システムごとに仕様が微妙に違い、組み合わせる他アプリケーションや既存資産との相性で予想外の不具合が出ることがあるからです。
なので、納期に向き合うときは「全ての遅延を防ぐ」より、自分でコントロールできる範囲の遅延を減らす方向で考えると、気持ちが楽になります。
具体的にやれることを4つにまとめました。
納期を守るための4つのコツ
- リスクが大きい作業の工数は多めに見積もっておく
- リスクが大きい機能から先に着手する
- 仕様の不明点は「回答期限つき」で質問する
- 見積もり時点で成果物(ソースコードなど)を少しだけ作ってみる
①リスクが大きい作業の工数は多めに見積もっておく
プログラミングの工数を正確に見積もるのは、慣れた人でも難しい部類の作業です。
特に、次の3点のいずれかに当てはまる場合は、リスク分の工数を上乗せして見積もることをおすすめします。
工数を多めに取りたいケース
- 初めて担当する機能やプログラミング言語である
- 要求仕様があいまい
- ソフトウェア設計・プログラミング難易度が高い
初めて担当する機能やプログラミング言語である
初めて担当する機能・プログラミング言語の場合、そのことをお客様に正直に伝えて工数を多めに取っておくほうが安全です。
たとえば、UI機能しか作ったことがないエンジニアが、いきなり通信制御機能を実装する場合などです。
機能ごとに「ハマりやすいポイント」がだいたい決まっていますが、その機能を初めて扱う段階で全部を予測するのは難しいです。
要求仕様があいまい
要求仕様があいまいな場合は、早めに質問するのが基本です。
「この質問の回答がないと工数が正確に出せない」と思う点は、可能な限り見積もり時点で質問しておきます。
見積もり段階で質問しきれない場合は、「この仕様が不明なので、見積もりの粒度はかなり粗くなっています」と正直に添えておくと、後の手戻りリスクを下げられます。
ソフトウェア設計・プログラミング難易度が高い
プログラミング難易度が高い場合も、工数を多めに見積もる余地があります。
たとえば、他アプリケーションとのやりとり(通信制御)が多い機能では、特定の条件が成立したときだけ不具合が出ることがあります。
他アプリケーションと組み合わせたときに予期せぬ動作になるのは、よくあることです。
そういうときは大幅な仕様調整が発生する可能性があるので、それを見越して多めに工数を確保しておくと安心です。
②リスクが大きい機能から先に着手する
見積もりが承認されて作業に入ったら、リスクが大きい機能から先に着手するのがおすすめです。
リスクが大きい機能は問題が発生しやすく、納期に影響する可能性も高いからです。
例
通信制御機能を実装する際、「プログラムを完成させて他アプリケーションと組み合わせたら、うまく通信できなかった」というのは珍しくない出来事です。
その場合、仕様調整やプログラム修正が発生します。
特に仕様の調整作業には時間がかかります。
早めに仕様の不備・不明点を洗い出してお客様にボールを投げておき、その間は別の機能の開発を進めると、納期に遅れる確率を下げられます。
③仕様の不明点は「回答期限つき」で質問する
仕様の不明点が発生したら、回答期限つきで質問するのがおすすめです。
「〜までに回答がないと納期に間に合わないため、お手数ですがご回答お願いいたします」という形で、早めに相手にボールを投げてしまいます。
注意点として、「1時間以内に回答お願いします」のような短すぎる期限は避けたほうが無難です。
質問内容によっては仕様変更を伴うこともあり、時間がかかるからです。
回答期限は1〜2日後を目安にしておくと、相手にも悪い印象を持たれにくいです。
どうしても緊急の場合は短い期限で依頼することもありますが、その場合は「なぜ短い期限なのか」を一緒に説明できると、関係者の納得感が上がります。
④見積もり時点で成果物(ソースコードなど)を少しだけ作ってみる
見積もりが特に難しい場合は、見積もり時点で成果物を少しだけ作ってみる手もあります。
もはや「見積もり」とは言いにくい裏技ですが、人は経験していない作業を正確に予測するのが苦手なので、難所の検証用として有効です。
体験談
私がエンジニアだった頃、お客様から「絶対に工期を遅らせられない」と強く言われる場合がありました。
そういったときは、自分の身を守るためにも、ソースコードを先に少し作ってみて、どれくらいの難易度と工数になるかを確認していました。
「見積もりは明日中に提出します」と一日確保して、見積もりと同時並行でプログラムも書いてみる、というイメージです。
そこまでしないと、プログラムの製作期間を正確に見積もるのは難しいケースもあります。
それでも納期に間に合わないと分かったときの伝え方
ここまで工夫しても、納期に間に合わないと分かる場面はあります。そのときは、分かった時点でできるだけ早くお客様に連絡するのがポイントです。
連絡が遅くなるほど、お客様側で取れる対応策が減ってしまうからです。
連絡する際は、次の2点をセットで伝えると話が早く進みます。
一緒に伝えたい内容
- 納品可能日(どれくらい遅れそうか)
- 納期に間に合わない理由(現時点で分かっている事実ベース)
納期に間に合わないと分かった段階で、再計画をして「どれくらい遅れそうか」を見積もっておきます。
理由については、できる範囲で「予想外の事象が起きた」ことを事実ベースで説明できると、相手の納得感が上がります。
例えば、次のような理由であれば、お客様側でも対応の判断がしやすくなります。
伝えやすい理由の例
- 他担当者の機能で大規模なバグが見つかり、自分の作業が一時的に止まった
- システム仕様不明点の質問に対する回答が、提示した回答期限までに返ってこなかった
- サードパーティライブラリに想定外の制約が見つかり、設計を一部やり直す必要が生じた
「できる範囲のことをやった上で遅れた」状況であれば、「今回は仕方ないかな」とお客様に思ってもらえる可能性が高まります。
逆に、「対策をほとんど打たずに納期だけ過ぎた」状況だと、次の仕事につながりにくくなる場合が多いです。
納期に対する心構えで意識したいポイント
納期に対する心構えで意識したいポイントは、次の3つです。
意識したいポイント
- 他メンバーへ何かを依頼するときは、必ず期限日付きで依頼する
- 自分起因で納期に遅れない工夫を、できる範囲で続ける
- 自分起因で遅れそうな場合は、なるべく早く連絡する
特に1点目について補足します。誰かに
- 「質問に回答してください」
- 「TBDとなっている上位仕様を決めてください」
- 「ソフトウェアのバグを直してください」
などを依頼するときは、「この日までに対応してもらえれば、自分の進捗は遅れない」という希望の対応完了期限日を依頼相手にも共有します。
この共有が大事なのは、次の2つの理由があるからです。
期限日を共有する意味
- 希望の期限日までに対応できないと分かれば、自分の納期影響もその時点で判断できるから
- 依頼される側は自分の本来の作業を優先しがちで、依頼対応が後回しになりやすいから
体験談
メールで依頼するときは、プロジェクトリーダー(工程管理責任者)をCCに入れて、本文に「この期限日までに対応が完了しなければ、私の工程がXX日遅延する見込みです」と添えていました。
こうすることで、依頼相手の本来の作業と自分の依頼対応のどちらを優先するか、プロジェクトリーダーが判断しやすくなります。
本当はゆとりを持って他メンバーの手伝いもできる作業計画が理想ですが、現実のプロジェクトは限られた人数・短い工期で多くの成果を出す必要があるので、なかなかそうはいきません。
その中で、自分の担当範囲については「事前にコントロールできるリスクを減らしておく」だけで、納期に対する精神的な負担はかなり減ります。
関連記事
工数見積もり自体の難しさと対策については、こちらの記事も参考になります。
また、納期に追われやすい職場環境については、こちらの記事も合わせてご覧ください。
二次請け独立系SIerに就職する際に知っておきたい3つのデメリットと見極め方
まとめ
プログラマーが納期を守るための4つのコツと、遅れそうな時の伝え方について解説しました。
ポイントは、「全ての遅延を防ぐ」のではなく、自分でコントロールできる範囲の遅延を減らすことに意識を向けることです。
正直ベースで実力に見合った工数を出し、リスクが見える範囲でバッファを取っておけば、納期に対する精神的な負担はだいぶ軽くなります。
プロジェクト全体の納期(工期)は本来プロジェクトリーダーの責任範囲なので、まずは自分の担当機能の納期を守ることに集中していきましょう。