読者です 読者をやめる 読者になる 読者になる

NOと言わなきゃエンドレス

お客の要望にNOと言わなきゃエンドレスだ。

締め切りは来週の火曜日。
現在ソフトウエアの試験中なのだが、今回修正したバグ以外のものが、でるわでるわ。

試験はお客が取り仕切って実施していたのだが、全然試験してないことが、こう言ったことからもわかる。

いや、試験してない、と言うのは語弊がある。試験は何万項目戸やっているのは知っている。
要は大事な試験をしていない、ってことだ。

当然、お客は言う。

「これもついでに直して」

俺は調査して、工数を見積もる。

「直すのにはこれだけ期間がかかりそうです」

というと、お客から「もっと効率化できない?」とかひどいときには「何が何でも直せ!」とか言われる。

おれは、決してYESも言わない。というか言えないのだ。

ソフトウエアは根性論ではつくれない。
できない、とは言わない。
ある意味において、できないことはない。

それは事実なのであるが、ある程度の省略できない作業はあるのだ。それが見積もりに記載されていることなのだ。

お客は俺の会社の他の誰か(いわゆる御しやすいヤツ)に意見を求めたあと、こう言う。

「xxxさんは、もっとはやくできるといってますよ!?」

だが、俺はYESと言わない。

「じゃあ、彼に任せてみたら如何ですか? 僕は僕の見積もりを信じているのでYESとは言えません。」

なぜ、俺はそんなに頑なかと言うと過去にそれを呑んでヒドい目にあったからだ。


あと、お客はたまに勘違いをしている。

例えば、おれが一週間かかる、といったところを、お客が3日でやれ、といって開発がスタートする。

で、結局一週間かかったとした場合に
お客のそのまたお客が怒る。

「3日でできるっていったじゃねーか!」

そりゃそうだ。
で、お客は俺に言う。

「なんで遅れたんだ!」

「俺は一週間で見積もりを出したはずです。それを推して3日でできると、そのまた先のお客さんに確約したのはあなたでしょう?」

これはリアルにあった話。
もちろん、俺はおとがめなしだった。

見積もりは予定ではない。
見積もりは、最悪で何日、最良で何日と出すべきで、

調査 2人日
設計 5人日
実装 3人日
試験 4人日

とか書いてある見積もりを見ると、頭がくらくらする。
リスクが全く考慮されてない。
リスク込みの見積もりだ!というなら、じゃあそれも明文化してお客に提示しろよ!と思う。

少なくとも
①調査 2人日~4人日
②設計 調査で見つかった問題箇所による
③実装 調査で見つかった問題×5人時

リスク
ほげほげ
ぴよぴよ

くらいは最低書いてないと、誰も説得できないだろうと思う。

調査してから見積もりができれば正確なんだけど、それができないことが往々にしてあるからなあ。

NOと言わなきゃエンドレス、になってしまった。俺の先輩が安請け合い、ってわけじゃないがお客の要望を飲んでしまった。

この期間内に終わらせます、とのたまったからさぁ大変。

いや、終わるかどうかを心配してるんじゃなくて、品質が担保できるのか?ってこと。

短期間で高品質なものが作れたら、そりゃ良いけど、それができてればサービンインした後にこんなにバグはでない。

そのあたりを、俺たち開発者もお客も考える必要があると思うんだけどな。
多分、その先輩も納得して無いんだよ。

納得してないまま、物事を進めなきゃいけないことがあるってのは
子供じゃないから知っているんだけど
納得せず進めるプロジェクトがうまく言った試しはない。

それが続いていくと、品質が悪いシステムができてしまうんじゃないのか?

時間がないと、バグ箇所だけ直す、とか消極的対処をするのは、善悪で言うと悪だ。
全体を見て、本来こうあるべき設計、というものを調査、議論して、導き出して行くべきなのに
締め切りとか、今期の売り上げとか、稼働制限とかに、邪魔されて、なあなあのシステム開発が進められていることを、世間の人はもっと知っても良いと思うんだ。

話がだいぶそれたが
やると言ってしまったからには
最善を尽くそうと思う。

目下、それくらいしかできない。
いちエンジニアとしては。