bbz

銀の弾丸

_
previous | next | edit
1: 2005/10/27(Thu) 00:02
silver bullet 「特効薬」を意味するらしい。狼男を撃ち殺すために必要なのが銀の弾丸であることからきているそうだ。
これは「人月の神話」というソフトウェア開発の管理について書かれた本の副題である。
2: 2005/10/27(Thu) 00:05
この本を初めて読んだのはいつだったろうか。まだCOBOLプログラマだったと思う。わたしはちっぽけではあるがシステム開発を仕事としていて、かならずプロジェクトが遅れ、システムがうまく動作せず、何度も何度も修正と再設計を必要とするのに嫌気が差していたときに読んだのである。おそらく日経コンピュータか何かで紹介されていたのだと思う。
3: 2005/10/27(Thu) 00:10
結構ボリュームがあり、また論じられているシステムが何百人という人員が分散作業するというものでせいぜい10人程度の規模の開発にはちょっと縁遠い感じがして、パラパラとめくる程度にしか読まなかった。
ただ、「人月で進捗は測れない」「遅れているプロジェクトに人員を追加するとさらに遅れる」「銀の弾丸などない」などにうなづいて、ではどうすればいいか?とは考えなかった。

「全体スケジュールの半分をテストに当てる」
というのは、現状とはかけ離れていて、テストの工程などおまけのように扱われていた。しかし当時のわたしにはスケジューリングをするような立場にはなかったのでこれもフーンという程度に読んだだけだった。
4: 2005/10/27(Thu) 00:14
わたしのやっていた開発では、設計・開発・テスト・マニュアル作成・メンテナンスまで全部担当した。
そのとき思ったことがある。
・仕様書なんかどうせ後付けなんだから無意味なんじゃないか
・マニュアルを先に作ってしまった方がいいんじゃないか
・納品後バグが出るのは仕方のないことだ、出たら直していけばいい
5: 2005/10/27(Thu) 00:18
わたしが開発をしていたときには、「実装(implimentation)」「アーキテクチャ」「コーディング」という言葉は使わなかった。

基本設計、詳細設計、プログラミング(プログラミング開発)、単体テスト、結合テスト、運用テスト、という感じだ。

実際には運用テストなどなく、ぶっつけ本番である。
スパイラルとかいう言葉もなく、工程に後戻りは無い。

実際は納品してから作り直すのは日常茶飯事だったが。

6: 2005/10/27(Thu) 00:20
Windowsなんか、毎日のようにバグが出ている。
それに比べれば・・・なんて思ったこともある。わたしが開発をしていたのはWindowsの無い時代だ。パソコンなんかごく一部の人しかもっていなかった。
7: 2005/10/27(Thu) 00:21
そのWindowsが登場する頃から、わたしは開発現場から離れていき始め、最近ではもうすっかり縁が切れたと思っていたら、とんでもないプロジェクトに組み入れられてしまった。
8: 2005/10/27(Thu) 00:26
そこで、ソフトウェア開発の進捗や工程について考えさせられることとなり、読まずにいた「人月の神話」を再び開いたのである。今の仕事は開発者ではないのだが、本書が非常に参考になる立場にある。
9: 2005/10/27(Thu) 00:29
今思っているのは、「では、どうしようか」という事である。
わたしはスケジュール通りに完了するどころか、いまだかつてまともに稼動したシステム開発プロジェクトに参加したこともなければ見たこともない。ソフトウェア開発とはうまくいかないものだ、というあきらめの境地に立っている。
10: 2005/10/27(Thu) 00:32
いや、あきらめの境地に立っていたのだが、
そんなことを言っていても泥沼にはまるのはたくさんなので、
何かいい方法を考えましょう、銀の弾丸なんか無いって言うなら、作りましょう、いや、そもそも本当に銀の弾丸がないと狼男は倒せないんですか、斧で頭カチ割ったらどうですか、とそういうことを考えてみたいと思うのだ。
11: 2005/10/27(Thu) 00:35
それがわかったら、俺は堀江や三木谷のようになれる。
そこまでいかなくても一生くいっぱぐれないくらいには間違いなくなれる。これはC言語でプログラミングをする事なんかより、はるかに有益な高度なやりがいのある仕事だ。
12: 2005/10/27(Thu) 00:38
古今東西、もっとも成功したソフトウェアとは、間違いなくMSWindowsである。ほかに何があるだろうか?linux。Oracle。AcrobatReader。
わからない。でもWindowsは5本の指に入ることは間違いない。
だから、Windowsをまねすればよいというのが一つの方法だ。やってみよう。
13: 2005/10/27(Thu) 00:42
Windowsは、素人をターゲットにした。
機能よりも、対応するハードウェアの多様さを重視した。
それはシェアを占める為などではないのだ。純粋に、万人にコンピュータを広めたいという情熱があった。ここだ。
この、情熱。誰かを喜ばせたいという意欲。
14: 2005/10/27(Thu) 00:45
そして、「とりあえず出す」という精神。駄目だったら直してもう一回出す。それも、開発をスパイラルに行うなどというものではなく、製品として、「できた!」と言ってパッケージしてとにかく出す。たたき台ではなく、完成品です、と言ってだす。
不十分であることは重々承知であるが、製品として出すからには、とりつくろう必要がある。それが、機能を選択して虚飾を捨てるということである。
15: 2005/10/27(Thu) 00:52
MSは相当な苦労があったと思う。たしかにWindowsには悪態をつきながら使ってきたが、それを十分に上回る恩恵を受けてきた。Windowsは本当に世界を変えた。IT革命ではない、Windows革命なのだ。MSが仕事のやり方を変えた。ワープロ、表計算、メール、インターネット、みんなWindowsという窓が開いたことによって、世界中に広まったのだ。

linuxなどのオープンソースで開発されているものは、すべてWindowsが開拓してきた道を歩いているにすぎない。
16: 2005/10/28(Fri) 22:16
ソフトウェア開発が泥沼にはまる原因がわかった。
まず、基本的に人間は自分がしんどくない程度に、仕事を長くやる傾向にある。仕事すること=カネをもらえることで、時間がその単位であるから、長くやるほどたくさんカネがもらえるというわけ。
17: 2005/10/28(Fri) 22:17
しかも、8時間以上働けば2.5割増し、さらに10時すぎたらその2.5割増しと、長くやればやるほど特するわけだ。
でも、普通は、一日8時間もやれば疲れるし飽きるので、みんな帰るわけだ。家も恋しいのでね。
しかし、ソフトウェア開発では、ちょっと事情が異なります。
18: 2005/10/28(Fri) 22:19
まず、何をやっているかが、他人にわかりにくい。少なくとも、上司にはよくわからない。技術の進歩が早いし。プログラミングじたい、個人のセンスに依存しているところがある。だから、その人が何をしているかはその人にしかわからない、嘘をつこうと思えばいくらでも付ける。
あるリクエストに対してこういうアウトプットを出すのに、3000ステップ必要だとプログラマが言い張れば上司は何もいえない。
19: 2005/10/28(Fri) 22:21
さらに、ソフトウェア開発に費やされる労力、肉体的な労力は限りなくゼロに近い。座ってキーボードを叩いているだけである。おばちゃんの井戸端会議だって立っているからもっとしんどいだろう。
20: 2005/10/28(Fri) 22:23
だから、労働者の原則、しんどくない程度に仕事は長時間したほうがいい、は、ソフトウェア開発においては極端に適用されてしまうのである。コストは人件費だけであるから。かかるとしたらPCや開発ツール、仕事場の家賃くらいか。たかがしれている。
21: 2005/10/28(Fri) 22:25
つまり、プログラマが少しでも自分の収入を増やそうという利己心が、プロジェクトの進捗を遅らせ、コストを増加させ、赤字になるということです。
22: 2005/10/28(Fri) 22:28
あと、プログラミングが楽しいこと。麻薬的な快楽があること。
これがそれに従事するものの疲労を忘れさせ、通常の労働では考えられない仕事の仕方をさせる。

しかし、実際は彼らはべらべらおしゃべりしている程度のチカラしか使っていない。それで得た金はパチか風俗に消える。
23: 2005/10/28(Fri) 22:29
はい、現状分析は終わり。
これ以上やっても愚痴になるだけ。

さあ、じゃあ、どうしたら改善するかを考えようね。
24: 2006/11/25(Sat) 06:57
もう1年たちましたか・・・
問題はコミュニケーションである。
コミュニケーションと一言で言うと意味が広すぎるのだが、
単に意思疎通を十分に行うと言う事ではない。
毎日進捗を時間やテスト実施項目数、バグ件数、プログラムのステップ数などにより細かく報告させる事は、今の職場でされている事であるが、作業者と管理者の負担をともに増すだけである。
25: 2006/11/25(Sat) 06:59
管理者にとってはそれらの数値がないと進捗が見えないということなのだろうが、そんな数値は報告者のさじ加減でどうにでもなる。進捗が悪ければ項目を細分したり、項目の重みが大きいと言ったりできるし、8時間遊んで2時間で作業して、10時間かけてやりました、ということもできる。
26: 2008/02/05(Tue) 20:25
2000年問題ももう懐かしい話になってしまった。私はそれが話題になっているころにMSに行くための面接を受けたのだが、その時に担当者に2000年問題についてあまり考えた事はないのかと言われてカチンときた。しかし今になって考えてみると、MSではどこの誰が作ったかわからないようなデバイスやドライバ、アプリなどを動かすOSでは、問題が起こることを前提に考えるのが当然だったのだろう。私はベンダーがハードからコンパイラ、DB、エディタからファイル設計ツールまで何から何まで準備されていたから、そのような心配がいらなかった。私が世間知らずだったこともあるが、2000年問題をなめてるだろみたいな言い方がムカついた。実際2000年問題なんかほとんど何もなかったよね?
27: 2008/02/05(Tue) 20:27
枠である。中身はない。あなたの職業はなんですか?と言われたときに絵描きです、というのと、枠を作ってます、というのとではどちらがカッコいいだろう?もちろん絵描きである。誰だって枠をつくるひとよりは絵を描く人に、球場を作る人よりはプレイヤーに、なりたいだろう。わたしもずっとそう思ってきた。しかし、windows, 2ちゃんねる、google、yahoo, secondlife、youtube,mixiなど、世間を騒がせているサービス、巨万の富を手にするまでになっているITという名のサービスは、みんな枠なのである。中身はユーザーが作り、枠はその内容にいっさい関知しない。私はずっと、人々が感動すること、喜ぶこと、楽になること、熱狂することを作れば金持ちになれると思い込んでいて、そんなの俺には無理だなあなどと思いながらぼんやりとあこがれていた。しかし、最近ようやくそうではなくて、枠を、場を提供しさえすればビジネスとして成立するということがわかり始めた。
そういえば、TCP/IP自体がその原則にもとづいている。そしてNGNはそれに反している。
中身まで関与すればよりよくなるというのは甘い誘惑だけど必ず失敗する・・・。

考えてみるとなんでもそうだな。秀丸、オフィス、各種ゲーム機、携帯電話、テレビ、パソコン・・・・「コンテンツ」はユーザが自由につくるもので、商品にはならない。提供するのは場所と、せいぜい材料くらいで、あとはユーザにまかせる。余計なおせっかいはユーザの自由を奪う事にしかならない。

今著作権が危機に瀕しているけど、もしかして音楽も文学も、それ自体では対価が得られない時代がくるのかな・・・著作権はなくなる・・・・・・・。とうてい考えられないんだけど、実際今そうなりかけてる。

でもなんか不思議な感じがする。枠よりも中身の方が価値があるような気がしてしかたがないんだが・・・。それとも確かに価値はあるがカネにはならない、っていうことかな。
人材派遣もそうだな・・・証券会社もそうだな・・・
枠だ。枠だけ作ったほうが儲かるんだ・・・

これはもしかしてデスマーチをなくす答えかもしれない。
デスマーチが発生する一因は工程の後戻り、つまりユーザがこれはやっぱりダメだと差し戻した事による作り直しである。もう、ユーザがやりたいことはユーザに任せて自由に作ってもらう。そのためのフレームワークだけを提供する、そうすればこんなことにはならない。細かいUIまで作ってユーザの承認をもらうことはない。
28: 08/09/05(Fri) 20:33
みなさんはソフトウェアというものを過小評価しており、テストを過大評価している。
しかし、デベロッパーについては過大評価している。テスターは、テストを過大評価しているのに思うような結果がでないことの責任を負わされて結果として過小評価されている。

ソフトウェアに対する過小評価というのは、それはモノとは違って無限の可能性と柔軟性を秘めており、やろうと思えばなんでもできる、ソフトウェアに不可能はない、というくらいの底知れないものであることを見過ごしているということである。単なるハードウェアに付属するオマケのように考えている人が多い。

テストについての過大評価というのは、ソフトウェアそのものに対する過大評価と裏表の結果である。ソフトウェアが無限に柔軟で測定不能な可能性を秘めているため、テストで発見されるバグには限界があるし、テストで問題がなければバグがないことを証明したことにもならない。

また、バグというのはカビとかゴミとか、そしてまさに虫などが混入するようなものではない。そういうものもあるかもしれないが、非常にマレである。多くは、人為的なものである。誤解であったり、考慮もれであったり。そして、あるバグの発見は、類似のバグが潜んでいる可能性を高める。

大量生産されるモノをサンプリングして瑕疵を見つける場合なら、瑕疵がみつかり取り除かれたから製品の質は全体として向上した、といえるかもしれないが、ソフトウェアの場合はむしろ逆である。人為的なミスであり、確率的な問題ではないから、バグを取り除くことは実は品質の低下の警告となる。

デグレードというものも、ある。バグは無意識に発生するのではなく、むしろ意図してつくられるものである。ソフトウェアバグは原因ではなくて未熟な技術者が生み出した結果である。結果だけをたたいてその未熟な技術者になにも処置をしないならば、バグの対処による新たなバグの可能性は非常に高い。

ソフトウェアの開発にも、試験にも、段階がある。初期の試行錯誤のような段階から、最後の検品のような段階まで。初期はバグを探すという傾向の強いテストであり、後期は正常動作を確認するという傾向が強くなる。

デベロッパーを過大評価しているというのは、いま述べたような、バグは人為的なものであることに対する無理解などのことである。また、ソフトウェアの可能性を理解していないことにより、デベロッパーのちょっとした細工でそのデベロッパーを評価してしまうような相対的な過大評価もある。ソフトウェアはなんでもできるのである。それに制限をかけているのは開発者である。開発者が制限をゆるめればソフトウェアは脅威の威力を発揮する、開発者が制御しきれないくらいに。だから、ソフトウェアを縛り付けて牙をぬいて角を折って、ほんの限られた能力だけを使用しているのである。

29: 08/09/09(Tue) 23:29
COBOLという文字がスラッシュドットに出てきたとき、なぜか恥ずかしくなった。懐かしいよりも、恥ずかしい方が強い。自分はかつてCOBOLをやっていた、というのはあまりかっこいいことではないと思っている。

私がCOBOLをやって数年たった頃にはもう、「COBOLは終わった」というような雰囲気がCOBOL部隊のなかでもあった。COBOL部隊からVB部隊、C部隊への異動が増えていった。

わたしはdbMAGIC部隊という、社内ではトラブる事で悪名高い言語というか開発ツールの担当になり、やっぱりトラブって、心身ともに病んで退職した。

でも、dbMAGICは、使っていてすばらしいと思った。ただ、COBOLと同じように使おうとしているからプロジェクトがうまくいかなかったのだと思う。まあ、MAGICのことはさておいて、COBOLであるが、依然として需要はあるようである。

わたしもまだ求人があるなとは思っていたのだが、ここにきて廃れるどころかやや増えてさえいるように見える。

仕事を探していたとき、COBOLの求人もあるのかと聞くと、求人はあるが、古いシステムのお守りだから、これからを考えたらやめたほうがいい、と言われた。
一度引退してから2ヶ月程COBOLをやったことがあるが、継続されなかったところを見ると試用期間でハネられたのだろう。

それからもう、10年以上たっている。さすがに10年ものブランクはきついだろうか?
30: 08/10/04(Sat) 07:54
ソフトウェアのバグを根絶することが可能か不可能かはともかく、それを目指すために必要なことは、徹底的なテストではなく、ソースコードの整備である。ソフトウェアというものは、人間がコンピュータに下している命令であって、ほとんどはその命令自体が間違っていることが原因である。ほとんどが人為的なミスである。それも、ほとんど故意と言ってよいような。

テストによって不具合が見つけられることは、デベロッパーにとって恥である。完璧にソースコードを理解していれば、バグは発生しない。
テストによってバグが見つかったということは、そのソフトウェアの作成者がバグを発生させる可能性を持っていることを示しているのであり、バグそのものはそのほんの一部の姿でしかない。

ある製品のバグが、リリース後に出たような場合にテスト不足を責めることがあるが、それは間違っている。
テストではバグは減らせない。

学校のテストと同じである。
期末試験を実施して、50点だった。まちがえた問題について再教育して、再テストをしたら100点になった。
これでその生徒はその学期の課程を完全に理解した、ということにはならない。
テストはおおよその確認しかできないからだ。テストに答えることが目的ではないし、テスト自体の正当性もテストされるべきであるし。

そういう、テストの効果の限界を知っているので、私はあまりテストを厳密にしなくてもよい、という主義である。
ざっとテストをして、問題の傾向が見つかったら、開発チームにフィードバックし、ソフトを作り直す。
バグをつぶすのではなく、作り直す。

バグというのは先ほど言ったように、開発者の未熟の結果である。根本的な解決はその未熟の除去である。
ソフトウェアを育てることは、技術者を育てることである。

テストというのは、ソフトウェアをテストしているのではなく、技術者をテストしているのである。
技術者のひとつのミスは、複数のバグとなって現れる。あるミスによって引き起こされる不具合を全部消すのではなく、その原因を除去すればバグは消える。

バグは偶然飛び込むものではないのである。
^
previous | next | edit