プログラマの慢心。IT業界の現状。

友人から以下のようなメールが送られてきて、ホントなの？と聞かれた。

1. プログラマがコードを書く。バグはないと信じている。
2. 製品テストが行われて30個のバグが発見される。
3. プログラマは20個のバグを修正し、残り10個はバグではないとテストチームに説明する。
4. 再び製品テストが行われ、バグ修正の結果5つの機能が正しく作動しなくなっていることが発見される。さらに15個の新たなバグが発見される。
5. 上記の工程3、4を数回繰り返す。
6. マーケティング部が楽観的な開発計画に基づいた製品発表を行ったことや、営業部からの圧力により、製品が時期尚早に出荷される。
7. ユーザにより100個のバグが発見される。
8. プログラマが他社に転職する。
9. 緊急で新たに開発チームが組織され、ほぼすべてのバグを修正する。
その過程で新たに500個のバグが生まれる。
10. テストチームのエンジニアが過労やうつ病により休職する。
11. 構造的な問題を解決するために一から開発し直すべきだという結論に達し、新たなプログラマが採用される。
12. プログラマがコードを書く。バグはないと信じている。

ブラックジョークらしいのだが、完全に否定できない。
どこかしらに心あたりがあるからだ。
ちなみに俺は7年、プログラマをやって、うつ病で現在、休職中。
そろそろ、休職期限が満了するのだが、復帰できるかさだかでない。

とりあえず2

http://anond.hatelabo.jp/20081204222554

プログラマというかIT業界の慢心

僕は鰻だ

ＰＧ以上に傲慢なのは，元請の大手ＩＴ企業の役員どもだろ。
下に丸投げしてテメエのボーナスばかり増やしてキター！

もう、それも終わりだがな．．．

--------------------------------------------------------------------
さて、「プライム・ベンダーはまだよいが、下請けさんはねぇ・・・」の話だが、
確かに大手SIerから仕事を請け負っているベンダーはこれからが厳しい。
ITサービス業界の多重下請け構造が景気の調節弁になっているのは冷厳な事実
だから、多くの下請けベンダーが苦境に陥るのは間違いない。単に案件が減るだけでなく、
プライム・ベンダーがオフショア活用を加速させるからだ。

　ただし、すべてがそうはならないだろう。あちらこちらで“下克上”が起きる可能性がある。
何かと言うと、下請けベンダーがプライム・ベンダーに取って代わるケースだ。
　開発が終わるとプライム・ベンダーは営業担当者ですら、ほとんど顔を見せない。
そして下請けベンダーの担当技術者が常駐でシステムの面倒を見てくれている。
ユーザー企業にはよくある話だが、彼らにとって大事なパートナーはプライム・ベンダーではない。
無理を聞いてくれ、自分たちの業務も知り尽くした下請けベンダーの担当者だ。

　そんなわけだから、システムのリプレースの際に現行システムのベンダーが提案に行ったら、
下請けベンダーの担当者が客側の席に座っており、その人に向かって提案内容の説明をしたという
マンガのような事態が起きる。また、ある下請けベンダーが蛮勇を奮って、新規開発案件で
プライム・ベンダーと競合し、見事ユーザー企業から直で受注したという話も聞いた。

　こうしたことはプライム・ベンダーにとっては“許しがたい下克上”かもしれないが、
ユーザー企業から言えば当然のことだ。やはり信頼できるパートナーに仕事は発注したい。
というわけで、景気後退で案件が減る今、下請けに甘んじていたベンダーには下克上に
チャレンジすることをお勧めする。ITサービス業界の下請け構造はもうもたないのは目に
見えている。ユーザー企業とのリレーションがあるなら、それに賭けるべきだ。

>>1
鬱が治らないということにして、生活保護もらえばいいよ。
んで、家でしこしこシェアウェア作って
小銭稼ぐ。
コレ、ベスト！

>>7

生活保護もらえるの？？

で、友人にはなんて返信すればいいだろう？
皆さんの意見を聞きたいです。

「疲れてるんだな、はやく寝ろ」

>>8
鬱で仕事ができないって認定貰えばね。

もちろん、一人暮らしは絶対。
復職できなかった場合は、チャレンジしてみる価値あるでしょ。

でも、最近は不況のせいで厳しくなってるらしいけど。

>>11　

認定は医者の診断書とかがいるのかな。
親と同居ではダメなのですかい？？

日本の慢心の間違いだろw

鬱の診断書なんて簡単に貰えるよ。

ソース：精神科通院中の俺

>>14

ぉぉ。それを区役所とかに持っていって、生活保護の申請したことは？

>>12
親と同居は無理ですな。
世帯単位でおりるので、働ける人、金がある人がいるなら養ってもらえって話になる。

最初30バグがあってそのうち20のバグを修正した結果15のバグと5の不具合が発見されるってことは
(3)を何度繰り返してもおかしいところは30のままでかわらないから無駄ってことじゃないか

それプラスユーザが100見つけて全部で130のバグ。
ところが(9)でその130をほとんど潰して新たに500ってことは
(9)の過程をやらないほうがはるかに良いってことじゃねえか
さすがにそこまでひどくないわ。

あと大規模開発でバグがないと信じてるプログラマはいません。

30や100のバグがなんだ。

そんなんでプレッシャーを受ける人間は鬱になる。

バグなんて大腸菌みたいなもんだろ。敵ではなく、適度にコントロールしながら共に生きるものだ。

>>1
ぶっちゃけ、自分の書いたコードのバグすら収束させられないPGはクズなので、
その内容はある程度正しいけど、全ての場面で適用されるとは限らない。

>>19

人が書いた設計書もないソースを修正しているPGもいるわけで、多くのPGはその時、その時でベストを尽くしてると思う。
だから過労になるし、鬱にもなる。

「バグはないと信じている。 」

これは嘘だと思うよ。そう思ってるのだとしたら、何かがおかしい。

1. プログラマがコードを書く。バグはあるものなので、速く誰かに見つけて欲しいと思っている。

これじゃない？

バグがないと信じてたり、願ったりしたって始まらないよ。心が持たない。
バグは必ずあるもの。発見できないのは、上司、使用者も含め、プロジェクトチームの責任。

信じる根拠は何だ？

たとえば、宇宙飛行士は身の安全を信じてロケットに乗り込んでいると
思うが、その根拠は？　

その根拠は、科学技術の正しさ。
その根拠は、基礎にある現代物理学の正しさ。
その根拠は、物理法則における再現性。
と、言う具合だな。

バグが無いと思う根拠は何だ？

長い経験を積んだプロの直感か？
何度もレビューを繰り返したことか？
全ての末端ルーチンのホワイトボックステストを終了させた事か？

数百人のテスターを雇って、数年に渡りテストを繰り返したことか？

×　バグはないと信じている。
△　バグが見つからないことを祈っている（そのプログラムが使われなくなるまで）。
○　バグが見つからないことを祈っている（そのプログラマがその会社で使われなくなるまで）。

中小規模と大規模では全然違うとは思うけど、実装レベルの不具合を減らすことは
可能だと思う。ちょっと自分のための整理もかねて書いてみる。

まず、不具合とは何か？を分ける必要がある。

1.ユーザ側担当者の要件が実業務と違ってた。
2.ユーザからの要件と開発側の認識がずれていた。
3.開発側上流での要件認識と、設計・実装者の認識がずれていた。
4.実装者は正しく要件を把握しているが、それとは違う実装になってしまった。

1から3と4では質的に違いがある。1から3は、これは情報共有の問題、コミュニケーションの
問題で、プロジェクト進行の方法、要件定義書のフォーマットを工夫するなどして認識相違を
できるだけ縮小するしかない。

だけど、4については技術的に問題がほぼ解決できる。これはプログラマの実装時に
発生するいわゆる「バグ」というもので、バグは以下の2つの種類に分けられる。

1.単純な間違い。電話番号欄に顧客氏名が表示されるなど。これは少しテストすればすぐ分かる。
2.複合的要件で発生する不具合。特定手順での操作で、システムが止まってしまう、間違ったデータ
挿入が起きるなど。これはあらゆるテストを行ったとしても完全に拭い切ることは難しい。

この2が問題で、問題があるコードは実は仮にテストで不具合が発見されても修正によって
さらに不具合が発生する確率が高い。且つ、この手のコードは修正が難しく、当然リリース後の
要望対応なども困難。対応するとさらにまた不具合が出る確率が高い。

◎　バグを仕様と言えるような裏道を作る。
◎　バグが出にくいテストケースにしておく。

長くなったのでわけました。

この、見えない不具合が発生しやすい、修正すると更に不具合を作り出しやすい、要望
対応によってまた更に不具合が発生しやすい、そういうコード。これはもう長期で見たら
開発会社としてはメンテで割に会わない工数が発生する不良債権だ。

これをどうやって避けるか？まず、不具合が出ないプログラミング方法を考えるべき。
不具合が出にくい順序で上げてみると、不具合を出さないのには

1.プログラミングをしない。
2.プログラミングをできるだけしない。
3.プログラミングをするが、必ず決まったソースコードになるようにする。
4.必ずしも決まったソースコードにはならないが、基本構造は全て同じにする。
5.基本構造から考慮する必要がある。

この順番になる。1から3は、つまり決まった設計書フォーマットなどからマクロで
コード生成をする、或いは、決まったXMLスキーマに従ったXML記述によって
コードを書く、ということになる。これらの生成されたコードは、それを解釈する
メタプログラムに不具合が無ければ、絶対に不具合は発生しない。

4はよく知られたフレームワークなどを使用するということ。

5はつまりは1から4までを規定するコードのプログラミングとなる。特に1から3で
定形で作成されるコードのインタプリタ部分の作成、これが重要だ。

何が言いたいかと言うと、世の中のプログラマの大半は、5の作業ができない。そして
4の枠内でやらせても、放置しておくと危険なコードを書いてしまう。そこで設計書などを
厳密に書くとか、スキル高い人間が面倒見る（尻フキをする）となるが、これは時間の無駄。

まず、彼らに「いかにコードを書かせないようにするか」を考えるべき。放置してても
必ず決まったコードしか書けないようにしておけば、スキルの高い少数の人間は、
5の作業に専念ができる。そして品質は必ず高くなる。

プログラミングは他の物作り産業と比較すると、作業者の裁量が大きすぎる。実際には
「思わぬ動作」をしないようにするためのセオリーがあり、よいコードとはどうあるべきか、
というのは厳然と存在するが、一般のプログラマはそれが理解できない。

ある処理内容を適切な意味ごとに分割し、それを抽象化し、他の部分で再利用をし、
それがまた高次の処理を可能にし、結果として自然と仕様追加などが容易で、信頼性が
高くなるということが理解できない。

理解させる、というのは無駄。逆に理解できてなくても絶対に同じ作業結果になるように
すること、これが大事だ。

長文失礼。

>>24
言ってること自体はわからんでもないが、担当が不明瞭だと思う。

A. 「世の中のプログラマの大半」に相当するスキルの人
B. 5の作業に専念する「スキルの高い少数の人間」
という登場人物がいるのはわかったが、
AをBに管理させるつもりなら、Bの負荷は余計高くなる。

理想論を言えば、ここに以下を追加する。
C. Aを管理するためのフレームワークを開発する人
D. 客先の矢面に立って開発「以外」の問題を吸収する人

で、マネージャーD、設計者B、リーダーC、コーダーA、という担当にするわけだが、
そもそもコーダーAに対して、その質の悪さを解消するための、
優秀なBCDを揃えるという事自体が事実上不可能に近い。
オフショア開発が失敗するのも同じ理屈だろう。

ちなみに、バグが無いと信じているのは、上で言うCとDだけだと思うよ。
優秀なCなら、フレームワーク利用方法の誤りを解消していけるだろうけど。

>>28
オフショア開発の問題は、開発技術というよりも仕様把握の問題が大きい。
これはコミュニケーションギャップがある上に、日本人だと「気をつかう」
ところが、外国人に出した際には通じないという点にある。

マネージメント全体として、これがものすごい大きな問題だ、というのは分かる
けど、いわゆるプログラムのバグ、というものとは別レベルの問題だと思う。

世間の大半のコーダーにコードを書かせないようにする、というのは可能。
この一般プログラマはもう工場で決まった作業をやるようにしてコードを書く。
裁量は一切与えない。これなら品質は保証される。

プログラマ：バグがないと信じているというより、バグが見つかって嫌味を言われるのが嫌だ。
上：俺の計画は間違ってないし、プログラマどもがミスすることは絶対許さない。

>>23
俺は別にバグが見つかっても良いけどなぁ
むしろありがたい
見つかったバグは修正出来るんだから

見つからないけど潜在しているバグの方がやっかいだろう
この手のは論理的なものだったりして、
表面的な挙動に現れにくいこともあるから、
少し手が空いたら、以前書いたモジュールを見直すように心がけてはいるが

テスト担当には申し訳ないが、
テストケースをこちらから増やすこともあるよ
出来ればリリース前に一通りのバグを出して、
自信を持って提供したいから

>これはコミュニケーションギャップがある上に、日本人だと「気をつかう」

仕様以外のことはしないからな。
再入力の再にパラメータ再チェックしないとか当たり前だからな〜。

インターフェースを定義する　または　レイヤー化するという発想が一般のプログラマにはないよね。
クラスの動作を明確にすることで、役割が単純になるのと同時に差し替え可能になるということがなぜわからないのか不思議

Web系では普通だろ。
テンプレートエンジン使う。

[バグがないと信じている]

この文書

[バグがないと確信している]

元は恐らく英語
大昔のPC98時代
WIN3.1/95のカーネルを作った作者だったか？インタビューが掲載された雑誌があった
この文面だった

用は
自身の主観で自分の言質を信じているわけで矛盾なく説明している文書で
その文意には当時天才的なフレーズを感じた
バグがあっても信じているだけなんで罪はないかと







ACEESS95関係でその昔カーネルモジュールのパッチを充てたよ（実はバグでした）

美しいソースコードにコメントは必要ないからって理由で
規約でコメント禁止にしてる現場ほどソースが汚いや。

美しいの意味が違うってこと？

>>37
ありえない。まさに慢心。スレ正しい。

>>38
ううん、美しいソースにコメントは必要ない。
のもとに実際できあがった物は
美しいとは言えず、何してるかも分からない。
汚いソースだった。
まさに企画倒れ。

理想は立派だった。そこは認めたい。
足りなかったのは美しいコードを書けるエンジニアだった。


そもそもコメントなしで書いたソースを
一年後の自分がこれは美しい！と思えるのか。
少なくとも僕にはムリ。

おいらの会社では、レビューとは担当者にとって
「弁護士のいない東京裁判(A級戦犯を一方的に裁いた裁判)」
と言われている。
説明の言葉尻を捕まえて、
そう、揚げ足を取って終いには
「だからお前はいつまで経っても『売女の子』なんだよ！」
とまで罵声を浴びせられる。リーダーや管理職連中がより汚い
罵声を競う競技会へと変貌してしまう。うちのレビューで
理性を保っていられる管理職はまずいないな。皆が狂っていく。
『売女の子』なんて日本語で言うなよな。まったく！

佐野場備市

>>1
致命的なのは除けば、バグのないソースはない。

おい、てめえ鏡で自分をよく見ろ。話はそれからだ。

致命的な人間だっているんだ、細かい事は神しか知らんわ。

>>37
絶対開きたくないソースだな。
下呂まみれの電柱と同じだ。

オープンソースはコメントないけどな
おかげで解析が大変

>>1
すげーじゃん
仕様変更・追加がまったく発生してないなんて！

∨∨∨∨∨∨∨∨∨
[[[[[[[[[[[ 仕様変更・追加がまったく発生してないなんて！ ]]]]]]]]]]]（キリ！！キリ！！！！キリッッ！！！！きリキリ！！！！
∧∧(キリッ

マジでゴミなんだな

勤務経験が無ければ理解できませんよねｗ

>>45
その方が解析楽だけどな
コメントは仕様変更なんかで嘘になってる場合もあるが
動いてるプログラムのソースはバグは有っても嘘は吐かないし