エンジニアは残念なプロジェクトを選べない

「残念なプロジェクトってあるじゃん。」
「残念、ですか。あ、トラぶるプロジェクトですね。」
「そうそう。あれ、どうやったら見分けられると思う。」
「いろいろあると思うんですが、なんでしょうねぇ…プロジェクトメンバが作るモノを理解していないとか、ですか。あと、どうやって作るか前提が無い、とか。」
「そうそう、そんな感じ。」
「何か見開ける方法があるんですか。」
「見積もり精度が悪い、つまり、リスクを見切れていない案件は低価格を付けるのよ。」
「低価格の案件は危ない。」
「いや、価格は案件のサービス内容に相対するから一律にそうとも言えない。」
「では。」
「提案する技術者の提供サービスに対する技術力の有無、だね。」
「提案するSEが何を提供しようとしているかわかっているか、いないかということですか。」
「まーそうだね。」
「そんなことあるんですか。だって、自分で提案書を書いて提案するんですよね。」
「だから、最初の言い方になるんだよ。『リスクを見切れていない案件は低価格を付ける』にね。」
「ああ。」
「だからね、トラぶるプロジェクトは提案時にトラぶることが潜在的に運命づけられる。デスティニー。ただ、デリバリーがそのあたりを察するとプロジェクトが暴れないように必死にコントロールしてしまうからなかなか露呈しない。」
「でも、デリバリーがいつもカバーできるわけではない、と。」
「そう。だから、提案時にどれだけ提供サービスの技術内容を詰めているか、価格に見合っているかを見ないといけないわけ。」
「でもそれって、見積もりを出す前のレビューにいないとわからないですよね。」
「あ、気づいちゃった。開発チームはさ、もうアホな条件で契約した後にそれを、ね。」