もしもプログラマが飛行機を作ったら

http://www.youtube.com/watch?v=Nq55R7R-qfw
これを見て気分が悪くなるのは俺がプログラマだからか?
ソフトウェアってのはプログラマだけで作ってるんじゃないだろ。たとえ飛行機を未完成で(あくまで当初の仕様通りであって未完成ではないが)飛ばせようが、既に飛んでる状態で「屋根を追加してくれ」って言う客と、それを聞いて「OK、できますよ」って言ってしまう営業とかSEとかが間にいるだろうが。
そもそもこの動画みたいな屋根のないジェット機が仕様としておかしいと作り始める前に指摘しなかった奴が無能なんだろ、なんでノーチェックでプログラマんとこまで来てんだよ。今までジェット機見たことない奴らだけで仕様考えて作らせて飛ばせて、そんで飛んでる最中に屋根追加か。あほが。知らないものを想像だけで作るなよ。
もちろん飛行機でそんなあほな話はない。が、ソフトウェアの場合「仕様変更って言ってもソースコードをちょちょっといじるだけでしょ?」みたいな認識でさっき思いついた仕様をちょちょっと乗せてくるから困る。もちろん物によってはちょちょっと直せますから、仕様変更分の金が出るならもちろん直しますが、後から後から変更するなら何のための要求定義だったのかちゃんと反省会してほしい。そもそも、要求定義だの設計だのの方がコーディングよりもよっぽど単価高いんだから、その時点で完成品のイメージの精度が100%に近くないとおかしいだろ。ウォーターフォール型の話な。最初に全部要求定義したはずなのに後戻りを繰り返す失敗設計をアジャイルとか呼ぶ奴は偉い順に滝から落ちて死んでくれ。
あと単純に別システムのリプレースみたいな物のとき、「いや、前のシステムはこうだったからこうしてくれ」みたいなのを後付けで出されるのが一番腹立つ。「知らないものを想像だけで作るな」と上で書いたが、リプレースの場合は完全に知ってる人がいる。お客様方は元のシステムについて熟知してるでしょうがこっちは全然知らないんだから知ってる事をまず全部教えてくれよと言いたい。前のシステムの事なんて知るか。もしくは前のシステムの仕様全部よこせ。まあ結局直しますけども。
いや、ちゃんとした手続き踏まずに直すからちょろいと思われてんのか?

ちょっと追記

ネタにマジレスしてる自覚はあるが腹立つもんは腹立つので。

逆にプログラマがちょちょっと直す敏捷性を評価してるものと解釈した場合も書くか

この動画を見る限り、この飛行機が運用上明らかに問題となっていそうな部分は機内サービスのドリンクがモロに客にぶっかかっている点だけだろう。このドリンクが熱々のコーヒーだったら訴訟沙汰になっている。屋根がつくまでドリンク提供というサービスは停止されているべきだ。
また、恐らく問題になっていそうなのはタイヤだ。一応ついてはいるが、何か触っていたので「離陸はできたが着陸の保障はできないかもしれない」状態かもしれない。ぶっつけ本番で着陸するのはNGだろう。下手したら死ぬ。着陸を機内サービスと同じレベルで考えてもらっては困る。
逆に問題なさそうなのは肝心の飛行機能だ。この状態で何故か乗客も凍死せず飛べているのだから屋根とか主翼とか無理に弄らなくても良いのではないか。この状態での離陸にOKが出ているのだから、屋根とか主翼とかは着陸してから「追加実装の契約の書面を交わして」直せばいいだろう。あと、座席を追加しているが、こんなもん後でいいだろう。あの状態から誰が座るんだ。
結局ちょちょっと直させてるのはやっぱりむかつくということで。

あー、むしろ俺と同じスタンスって解釈でいいのか?

I like this job.って言った後変な顔してるから「やっぱこれはないだろう」って主旨と見ていいんだろうか