昔、雇われエンジニアだった頃、
「納期」って、顧客が要求する絶対的なものだと思っていました。
当時私が所属していたのは小さな下請け企業でしたが、設計書を渡されてプログラム開発する工程ではSES契約(準委任契約)ではなく請負契約になることもあり、そこに「納期」は付きものでした。
で、最初は割と順調というか、少し余裕持って作業を進めるのですが、日が経つにつれ、どういうわけか必ずと言っていいほど仕事が押してきます。
(なぜなのかはとりあえず置いておきます)
やがて「納期」がせまるともう大変。
深夜残業や休日出勤を繰り返し、どうにかこうにかプログラムを完成させて納品します。
と言ってもその時点でのプログラム品質はとても褒められたものでなく、その後のテストでボコボコにされてしまうこともよくありました。
(なぜなのかはとりあえず…)
そこまでして「納期を守る」ことにシャカリキになっていたのですが、当然その理由は「顧客の要請だから」というものだと思っていました。
「お客様が希望する納期に納めるのが仕事だから」と。
それから早や30年。
小さな会社の経営者となった今、私は「納期を守る本当の理由」を痛いほど知っています。
発注側の事情ではなく、受注側の事情であることが圧倒的に多いのです。
もちろんプレスリリースでローンチ日を公表したとか、法改正に伴って施行日までには絶対必要なシステムなどなら納期は発注側の事情です。
データ移行の関係上、本稼働開始のタイミングは年に一度の決算期しかない、などのケースもあり得ますね。
しかしそうでない場合、「納期を守らなければならない」理由は一つ。
受注側が「早く請求したい」からです。「入金日を確定させたい」からです。
要は売上確定と資金繰りの問題なのですね。
だから、「たとえ顧客都合であっても納期遅れは開発会社の経営にダメージを与える」と言えます。
逆に言うと、「売上のずれや資金繰りに対する影響が少ないのであれば、納期遅れはさほど問題にならない」とも言えるのです。