IT業界で仕事をしていると必ず「システム開発の見積り」を行う事になります。
その中で「システム開発の見積り」作業に関する謎をちょっと書いてみようかと。
(あくまでも私見で、すべてがあてはまるわけではありません。)
見積り依頼をしている方が強い?
見積りは「これでどれくらいの金額がかかる」というもので、見積りをお願いする側、される側に上下はないはずなのだが、IT業界のシステム開発の見積りでは、経験上、発注側が強いように思われる。
きちんと見積りをして出した金額に「高い、予算が1000万円なので1000万円以上の見積りは受け取らない」なんてこともざら。
なら最初から「1000万円以内の見積り頂戴」と言ってくれれば良いのに。
本見積りが概算見積りを超えるとNG
よくあるのが年度末に「来期の予算確保のためにシステム開発の見積りが欲しい。詳細は未定部分が多いので『概算見積り』でOK。作業を本当に発注する時は再度見積りをお願いする。」なんてことを依頼されます。
で、『概算見積りを1000万円』で出して、いざ実際に打合せを重ね、詳細にシステム開発を行う『本見積り』を『1200万円』提出すると「予算が1000万円しかないので、それ以内でないと発注できない。」と言われる。
「ちゃんと仕様を確定して再度見積りすると○○が増えているので増額になるのは仕方ない」と言っても「じゃ発注しない。1000万円でやってくれるとこ探して、そこに発注する。」となる。
仕事を欲しい受注側は「1000万円の見積り」にして受注。
無事に『炎上プロジェクト』の完成。
見積りの条件が変わっても再見積りにはならない
見積りに「見積りをした条件」を書いて「変わったら再見積りね~」と書いてあっても、その後『再見積り』が行われることはほぼ無い。
「条件かわりましたよ~」と言っても、なんだかんだ理由をつけてそのまま・・・。
ここでも無事に「炎上プロジェクト」完成。
発注側の言う金額に無理やり合わせる
見積りをした結果が発注側と受注側で異なるのが当たり前。
で、ここで発生するのが「なんとかして発注側の金額に合わせよう攻撃」。
その手順は大体以下の通り
- 仕様不明確等で乗せていたリスク工数を削る
- 削れると思われる機能を削る
- 成果物(特にドキュメント関係)を作らないことにして開発工数を削る
- できもしない『部品共通化』を持ち出して開発工数を削る
まとめ
こうやって、今日もどこかで「炎上プロジェクト」が増殖されて行くのである・・・合掌。