理不尽な開発工程

ソフトウェア開発現場の七不思議の3回目。

> 3. 仕様が決まる前に納期が決まる。

顧客の要望だから、他社に対抗するために必要だから、トップの指示だから等々理由は様々だが、最終のリリース日程だけが先に決まっている開発プロジェクトがある。そんな得体の知れないプロジェクトに限って仕様は「これから決める」ことが多く、しかも作業工程を見積ってみると「納期に間に合わない」ことが分かったりする。

無茶苦茶な工程でもやれと言われた以上は努力するしかないが、そのまま突き進んでも失敗は目に見えている。そこで現実的な意味での成功を得るために、政治的な交渉が必要となる。自分たちが実現可能な範囲はどこなのか冷静に検討を繰り返しつつ、妥協可能なラインを目指して駆け引きを行わなければならない。

  • 本当に必要な機能は何なのか?後回しに出来る機能は無いのか?
  • 開発リソースの増強や応援を依頼できないのか?
  • 本当にすべてを作る必要があるのか?既存の資産を流用出来ないのか?

仮に、そんな交渉をしても譲歩を引き出せないようであれば、そんなプロジェクトからは身を引くべきだと個人的には考えている。無謀な作業工程で開発者を酷使するような組織から得られるものは少ないように感じるし、「押し込めば何でも出来る」と気づいてしまった会社は次も同じやり方をしてくるものだ。個人を殺して会社へ滅私奉公するのは日本人の得意とするところだが、そうやって会社に潰されたエンジニアを何人も見てきた。開発のプロとして最大限の努力はすべきだ。しかし、同時にその限界も自覚しておく必要がある。

本書では何回も、「そんな場合は会社を辞めよ」と書いた。
(中略)
誤解しないでほしいが、会社に罰を下すとか、復讐するために辞めろと言っているのではない。打開不可能な状況になったり、交渉相手が一切の譲歩を拒否したのなら、会社を辞めるのが合理的な行動と言っているにすぎない。人生はさまざまだし、いろいろなプロジェクトがある。世の中には、ほかにもたくさんの職がある。

デスマーチ 第2版 ソフトウエア開発プロジェクトはなぜ混乱するのか

デスマーチ 第2版 ソフトウエア開発プロジェクトはなぜ混乱するのか

デスマーチ 第2版 ソフトウエア開発プロジェクトはなぜ混乱するのか