不具合農場 地獄の大豊作不具合様は本日もすこやかなれば、本日も大豊作なり。 不具合様には不具合をお供えすべし。 今日もお供え物作ってますか? |
トップへ戻る ブログのトップへ戻る Word Press |
|
不具合道楽 地獄のフルコース不具合御飯 不具合味噌汁 不具合満漢全席 | ||
コンピューターのはらわた無修正大公開 | ||
不具合設計局キャンペーン中 |
2007-09-03 (Mon)
_ [違法派遣時代] ドキュメントと推測
いくつものプロジェクトの中で一つだけ私のお気に入りだったプロジェクトがありまして、このプロジェクトでは良いコードが書けたと思っています。しかし、このプロジェクトは他のプロジェクトが起こしたトラブルを被ってしまい、プロジェクトとしては振るいませんでした。当時、私が書いたプログラム設計書がやり玉に挙げられました。
発注相手が乗り込んできて、ソースコードの中から適当に1行選び、「この行は設計書のどこに対応していますか?」ときました。この1行、プログラムの中ではかなり補助的な部分のコードで、設計書にはこの部分に関する記載がありませんでした。で、鬼の首を取ったようにやりこめられました。私の見解ですが、設計書と実際のソースコードは完全には対応しないです。というのは、設計書は重要な部分に的を絞って書いてあり、前提事項のような部分は記述しないし、当然付随するような部分も記述しません。あと、仕様書が穴だらけで、厳密な設計が出来ないというのもありました。今だったらキレて反論しているところでしょうが、当時の私はまだ2年生でした。ミーティング用のテーブルだったのですが、私は半泣きで、あと一言やりこめられたら、本気で泣きそうになりました。でまあ、その場はこちらの会社の責任者が何とか納めました。
で、納品となりました。納品先での評価は最悪で、「バグっている。品質が悪い」とのことでした。で、このバグっているというのが、どうしてそれがバグなのか全く根拠がないんですよ。仕様書(納品先が書いている)のどこを見ても、その動作がバグであると分かるような記述はありません。これで、「このような状態で本当に管理できているのか?」ときました。ブチキレて、「だったら、お前らが書いた仕様書で、これがバグだと分かる部分がどこにあるのか?」と言い返したい気分でした。もう、テストしている人間が「正常な動作はおそらくこうだろう」と推測して、それと違うからバグだと言っている状態です。設計書の件ではさんざんやりこめたくせに、これですよ。ムカつきました。あと、仕様ということで同意している箇所についてまでバグ票を書いてきて、こっちが「これで本当に管理できているのか?」と言いたい状態でした。