ソフトウェアの納期と見積もりの納期だけの話


プロジェクトの納期です。例のアレを読んで、ですが。


納期の話を持ち出してきたとき、「それ、プロジェクトじゃないんだろ」と思ったらあなた、えらい。逆に、疑問に思わなかったらあなた、危ない。


なぜ、納期の話を持ち出してきたときにプロジェクト化プロジェクトでないかが関係するのでしょうか。


それはプロジェクトは有期限の業務活動だから、です。期限のない業務活動はプロジェクトではない。デファクトスタンダードでの定義なので、この定義が変わらない限りこの前提は変わらないわけです。そこを暗黙に話を始めるのはコンテキストを知らない読者をミスリードさせてしまうのでどうかなぁ、と。


納期には2種類ある
プロジェクトには納期が2種類あるのです。動かせない納期と動かせる納期。納期になのに動かせる納期があることに驚いたら、それは「納期はうごかせない」と固定観念に囚われ過ぎています。まぁ、いくら動かすことができないはずだと思っていた納期を動かす場合は、そう何度も変えられないですけど。


また、一方に動かすことができない納期というものもあります。こっちはどう頑張ってもダメです。諦めて、さっさと終わらせましょう。


動かすことができない納期
全くもって動かすことができないのは、「法令対応」でしょうね。これは動かすことができない。なんらかの別に手段で回避できるのであれば別でしょうけれど、まずは委託元は全力で「対応して」といってくるでしょうから。


もうひとつは、並行プロジェクトがあって、プロジェクトのリリースに依存関係がある場合は、ほとんど無理ですね。もし納期を自責で動かすつもりなら並行するプロジェクトが遅延するコスト負担を被るのが前提になります。逆に言えば、並行プロジェクトから納期を伸ばしてくれと言われたら費用を請求しないといけないわけです。リリースまでの体制を維持しなければならないし、ソフトウェアやハードウェアの保守費用やら回線費用やらもろもろコストが変わるでしょうから。


自費で全部被るつもりなら、まぁ、動かすことができる納期になってしまいますが。


動かすことができる納期
動かすことができる納期って割とあります。ただ、動かすためにはそれ相応の体力と精神力が必要です。誰が動かすというかによりますが。


ただ、納期を動かす場合には、それ相応の理由が必要だし、自責なら契約不履行になりかねないですし。そうなるとこれまで掛けてきたプロジェクトコスト+契約金額(契約で瑕疵の上限を契約金額2している場合)ですけどね。


納期を契約元から言い出す場合は、SIerなどの委託先としては追加見積もりですから通常は喜ばれますね。その期間に内緒の未完の課題に手をつけたり、危なっかしい品質未達の状況を回復させたりできますから。


納期を委託先から言い出す場合は、先に書いたとおりです。粛々と終わらせましょう。


納期がなければ結局終わらないんだろう
例のアレもそうだけれど、納期がなかったら一体いつ終わるんですかね。いや、終わらしてくれるんですかね。夏休みの宿題も終わらせられなかったんじゃないのかなぁ。そんなSEに納期を無くさせたら誰が責任を持ってデリバリーするんでしょうか。


でもさぁ、結局、納期を決めないと言いつつも、いつかはリリースするわけだ。ちゃんと作るものは作り揃えて。じゃあ、納期あるじゃん。


納期と見積もりの話でしたっけ。


納期が決まっているのに、請負ができないくらいの見積もりしかできないなら、「出来高払い」の契約にしたらいいじゃないですか。逆に言えば、請負契約ができる見積もり精度を持っているから請負で契約しているんでしょう。


出来高払いならお金が続く限り納期は変更可能です。理屈上は。でも、それはプロジェクトではない。期限がないから。ただ、契約上、期間を区切ってプロジェクトだ、といってもいいですが。そうすると結果的にスコープやら納期に何を納めるかなどなど契約の種類で制約が出てきますが。


結論。

・どこの国の契約でやるのか。国内の話でいいのかしら。民法が下敷きにあるのかな。請負と準委任と
・見積もりは、請け負えるほど精度で契約を選んでね
・納期は動かすことがほぼできますよ。例外もあるけど。自責ならコスト負担を
・期限がないのはプロジェクトではないからね