不確定要素があったら請負でなんて見積もれないですよ

ワタシ「それでさ、このプロジェクトは社員だけでデリバリーするんだっけ」
提案SE「そうしたいところなんですが、人がいないんですよ」
ワタシ「ふうん、で、どうするの」
提案SE「リーダクラスは確保するとして、他はパートナーとスキームを作るとおもいます」
ワタシ「人がいないんじゃそうなるよね」
提案SE「はい」
ワタシ「で、契約の条件は整理できているのかな」
提案SE「お客様とは請負で」
ワタシ「へー、請け負うんだ。請負でねぇ、これを」
提案SE「はい、請負でないとダメだと言われていますので」

ワタシ「何それ」
提案SE「だからお客様から請負でやってほしいと言われていまして」
ワタシ「ところでさ、この案件の提案、請け負えていると言えるのかなぁ」
提案SE「請け負えているじゃないですか、契約条件に『う・け・お・い！』って書きましたし」
ワタシ「（なにか変なもの見た気がする）請負って書いたら請負で契約したいと意思表示になるけれどね」
提案SE「なにか変でした」
ワタシ「（もう、いろいろとね）提案内容はどうかなぁ」
提案SE「…」

ワタシ「請負ってね、何を作るか見積もり時点で仕様が決められないとお見積もりすることができないんだよ。これどういう意味かわかるかな」
提案SE「３ヶ月で要件定義して、そのあと設計してと普通のフェーズになっていますけど」
ワタシ「その要件定義で何を定義できるか予測つくのかな」
提案SE「それがわからないから要件定義をするんじゃないですか」
ワタシ「要件定義はそうだったとしようか。では、そのあとの設計では何を設計するのかな」
提案SE「要件定義で決めた要件ですよ」
ワタシ「そうだねよね。要件定義で決めた要件のうち、システムで実装することに決めた要件のシステム仕様を設計するわけだ」
提案SE「はい、そうですよ」
ワタシ「さて、ここで不確定要素があるんだけど」

提案SE「なんですか、その不確定要素って」
ワタシ「決まっていない要素。この場合は見積もりをするときに変数として変わってしまう要素、かな」
提案SE「ないんじゃないですか、だって要件を決めてそれを設計するだけですよ」
ワタシ「よく見てみようよ。いいかい、要件定義では業務要件の中からシステム要件と業務の要件に分別する。そうしないとシステム化の範囲が決まらないからね」
提案SE「そうですね」
ワタシ「設計では、システム化要件を方式や実現仕様に詳細化する」
提案SE「はい」
ワタシ「わかったでしょう」
提案SE「えっ、いえ」
ワタシ「要件定義で何がシステム仕様になるか誰も知らないんじゃないのかな」

提案SE「お客さまは知っているんじゃないんですか」
ワタシ「だったら、見積もり依頼書なり、RFPなり出してもらわないと」
提案SE「見積もり依頼ならいただきましたが」
ワタシ「あれ、メモみたいなものじゃない」
提案SE「たしかにそうですが」
ワタシ「請け負うなら、定量的であることと実現する方式が決まっていないと見積もれるとは言えないんだよ。要件定義でどんなシステム要件になるかわからないのだから、誰も知らないんだよ。それを不確定要素があると言っているんだよ」
提案SE「でも請負でやってほしいと…」
ワタシ「だったら、その不確定要素をもっと具体的なってから受け追えばいいじゃない」
提案SE「あぁなるほど。じゃあ、設計以降は請け負えますね」
ワタシ「いやいや、それはデリバリーチーム次第。要件定義を本気で終わらせられたらいいと思うけど」
提案SE「一旦、その線でお客さまと会話します！」