狼男を撃つ銀の弾丸は，やはり存在しない．

• 「優秀なエンジニアがいなくてもやっていくために」 http://bugrammer.hateblo.jp/entry/2013/11/23/144649

うーん，とりあえず元ネタの本を読んでから全部書き直した方がいいと思う．*1

人月の神話

最新版．ただしピアソン桐原が技術書より撤退したため，絶版で店頭在庫のみになった本の一つ．*2 Amazonでの価格も高騰している．

追記：丸善出版より出版された．

人月の神話【新装版】

人月の神話―狼人間を撃つ銀の弾はない (Professional computing series (別巻3))

旧版その１．内容は基本的に同じはずだし，古本でなら今でも手頃な価格で手に入る．Amazonでの中古価格も若干高騰しているようだが許容範囲．

The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition)

Mythical Man-Month, The: Essays on Software Engineering, Anniversary Edition

洋書は普通に入手可能．Kindle版もある．*3 *4

ITの世界には「銀の弾丸は存在しない」という合言葉がある。これはどうやら狼やドラキュラを退治するときの道具が「銀の弾」らしく、古典的な名著であり、未だに参照され続けている『人月の神話』という本に収められている論文から来ているらしい。

どちらかというと合言葉じゃなく格言だし，ドラキュラではなく狼男な気もするが，まああまり重要な部分ではない．

silver bullet
a bullet made of silver, supposedly the only weapon that could kill a werewolf.

• chiefly N. Amer. a simple and seemingly magical solution to a complicated problem.

（Oxford Dictionary of Englishより）

英英辞典にも載ってるし，werewolf（狼男）と明記されてる．さらに詳しく調べたければOEDでも調べれば完璧．古い版だと「人月の神話 狼人間を撃つ銀の弾はない」と表紙にさえ書いてある．

なぜ、「銀の弾丸は存在しない」と言われるのかというと、ある諸問題に関して一気に片付けられるような、そういう解決策は無い。少なくともそれらの問題に関しては泥臭く、忍耐を持って接しないといけないという話だ。川を綺麗にするためには根気よく缶を拾ったりしなければいけないのと似たようなものだろう。

「銀の弾丸などない」は挑発的だった．ソフトウェアの生産性において格段の向上をひとりでにもたらすようなプログラミング技法は今後十年間は登場しない，と予言したからだ．その十年が経過するまであと一年残っているが，どうやら私の予言は大丈夫なようだ
（「人月の神話」の序文より）

とあるように，「ソフトウェアの生産性において格段の向上をひとりでにもたらすようなプログラミング技法」のことを「銀の弾丸」と呼んでいるものと考えられる．

泥臭い努力の話ではなく，川を綺麗にするのに大型作業機械を入れたり，浄化プラントを設置したりするような話．しかしそんな便利な道具は，ソフトウエア開発には存在しない．

元のドラキュラの話を知らないので、Wikipediaで聞きかじりに語るのだが、そもそも「銀の弾丸」といったところで、その「銀の弾丸」を使う存在というものがいる。ドラキュラの場合、それが「ヘルシング教授」である。ヘルシングといえば平野耕太の漫画を思い出すが、どうやら原作のドラキュラでは、この教授がドラキュラを退治したらしい。でもって、ドラキュラ・ハンターのことをヘルシングと呼ぶらしい。

　この記述を読みながら、「ああ、なるほど、ヘルシング教授というのは銀の弾丸なのか」なんていうことを考えたりしていた。

「人月の神話」においては，むしろ逆だろう．

特殊な超能力を有した吸血鬼ハンターだの狼男ハンターでなくても，銀の弾丸や十字架やニンニクや白木の杭を使うだけで，ただの人間が吸血鬼や狼男を倒せる．そういう一般人でもモンスターを退治できる特殊な武器や戦術が銀の弾丸だと思う．*5

プログラマーが好きな話題として、「生産性のあるプログラマーは」というのがある。

違う．

それが何度となく引用されるのはそれが「好きな話題」だからではなく，それが真実だからだ．

生産性のあるプログラマーは10倍とか100倍とか言われるが、自分が平凡なプログラマーであるが故に、この手の話題は好きにはなれない。

好きになれなくても結構．しかしそれがどれほど過酷でも，現実は受け入れなければならない．

ソフトウエア開発 55の真実と10のウソ

過酷な現実を嘆くだけで努力を忘れた人間は，歳を取ると老害と呼ばれるようになるんだろうな．自分はそうなりたいとは思わない．

あともう一つ好きになれないのは、それがプログラマー単体の問題に終始してしまって、環境とか、あるいは関係性なるものを考えるのを捨ててしまっているからだ。

うーんと，それこそが「銀の弾丸はない」という話だと思う．

「環境とか他の技術を変えれば凡人でも生産性を10倍にできる！この『銀の弾丸』IDEや開発プロセスやUMLモデリング手法を買って下さい！」というわけだ．だがそんな物は存在しない．*6 *7

ピープルウエア 第2版　ヤル気こそプロジェクト成功の鍵

デスマーチ 第2版　ソフトウエア開発プロジェクトはなぜ混乱するのか

他に組織論とかも当然組み込んでるよ．ただしそれは低レベルプログラマー専用ってわけじゃないから，良い組織にいる高レベルプログラマーは低レベルプログラマーより高い生産性を示し続けるだけの話．

なぜ環境の問題や、人間関係の問題を言うのか。というのも、プログラムというのは、繊細な作業であると思っているくらいでちょうどいい作業だからだと思っているから。

人間関係というか，「コミュニケーションコストが高く付く」というのがソフトウエア開発の重要な性質の一つだ．

第二の誤った考え方は，見積もりとスケジューリングに使われる仕事の単位，すなわち「人月」そのものである．コストは人数と月数の積に比例する．が，進捗はそうではない．したがって，仕事の大きさを測る単位としての人月は，疑うべき危険な神話なのだ．人月とは，人と月とが互いに交換できるという意味だからである．

人と月とが交換可能になるのは，多くの作業者の間でコミュニケーション（意思疎通）を図らなくても，仕事が分担できる場合だけである．これは小麦を刈り取るとか，綿を積むとか言うことには当てはまるが，どうがんばってもシステムプログラム開発には当てはまらない．

仕事が連続していて分担できない場合，人を増やすという対策はスケジューリング上，なんの効果も生まない．女性がどれほど沢山動員されたところで，子供一人が生まれてくるまで十月十日かかるのと同じだ．多くのソフトウエア開発作業はデバッグという順次的性質があるためにこうした特徴を持っている．
（「人月の神話」，第2章「人月の神話」の「人月」より）

先に調整を必要とする人の数が労力のコストに絶対的な影響を及ぼすと述べた．というのは，コストの大部分がコミュニケーションコストと，うまくコミュニケ-ション出来なかったことにより発生するマイナス面の修復（システムのデバッグ）だからだ．

なお，上記の「川を綺麗にするためには根気よく缶を拾ったりしなければいけない」というのも，こういう「コミュニケーションを図らなくても仕事が分担できる作業」で，ソフトウエア開発の比喩としては不適切なものの一つ．

現実をシビアに考えてみる。そのシビアさというのは、自分のところにはドラキュラを退治してくれるヘルシング教授はやってこないだろう、という過酷な認識から始めるべきだと思う。

既に述べたようにこの比喩も「人月の神話」の話としては不適切．

「凡人だけで吸血鬼や狼男を倒す方法を考えよう！そのための戦術や武器を開発すればいいんじゃね？」と考えても，実際にはそのような戦術や武器 ー即ち「銀の弾丸」ー は存在しない．

とするならば、やるべきことというのは、「優秀なエンジニアを採用する」ではダメで、「平凡なエンジニアでも、優秀なエンジニアと同等の力を発揮できるような環境を整えていく」ことであり、そういうことが出来るようにしていくことだと思う。

これも同様．

そんな便利な「銀の弾丸」は存在しない．

たとえ凡人でもそれを使うだけで生産性が何倍にもなる「銀の弾丸」を探し求める「青い鳥症候群」的なものは，初心者プログラマーや（初心者から熟練まで含む）管理職ならば，誰もが一度はかかる麻疹や中二病のようなものかもしれない．

例えば、自分のポンコツ事例だと下のような感じだ。

• 仕様書を読み違える

（中略）
で、このポンコツを直すためにはどうすればいいのか。

• 仕様書を読み違える -> チケットを切って作業を行う、あるいはテストを書いて理解している仕様を明確にする

仕様書を適切に解釈し矛盾や無駄を見抜く能力も，良いテストを作る能力も，いずれも属人的なプログラマーのスキルの一つ．低スキルのプログラマには，それは解決策になりえない．*8

ここにも「銀の弾丸」は存在しないのだ．

コメント欄より，

どうも、コメントありがとうございます。

確かに100倍は盛りすぎたかな。ただ近いことは言われてる、という証言はたびたび見ますね。事例としては以下のようなものとか。

＞＞ 「それも、人数じゃない。出来る技術屋の確保。プロジェクトはこれに尽きます。ITエンジニアの生産性って、人によって30倍くらい違いますから。」
http://brevis.exblog.jp/20765925/

よりによって，それを引用しますか……．orz

その人，ド素人じゃん．
http://d.hatena.ne.jp/JavaBlack/20130708/p1

s

本筋と全然関係ないですが、原作のドラキュラではヘルシング教授は補佐的な役割で、クライマックスのドラキュラ伯爵との対決時も、主人公ジョナサンの恋人を後方で守ってるだけで直接攻撃しません。なお原作には銀の弾丸も出てこないです。まあ後世の二次作品で色々設定が膨らんだので、一般的なイメージではヘルシング教授が颯爽と現れて問題を退治してくれるってことになるのかもしれませんが。

http://b.hatena.ne.jp/entry/bugrammer.hateblo.jp/entry/2013/11/23/144649

• id:ardarim 長期的視点では、平凡なプログラマでも一定の生産性を担保できる環境やツールを整備するというのが理想ではあるけど、やはり限界がある。システムを逸脱する優秀なプログラマの存在が期待されるのは仕方がない。

• id:m-matsuoka プログラミング 凡人に何かやらせるよりも、ちゃんとしたエンジニアにシェルスクリプトでも作ってもらったほうが効率的。必要なのは凡人をエンジニアに鍛え上がることで、凡人に安寧を与えることではない。

• id:seven_pairs 冒頭の例で言えば、ヘルシング教授じゃなくてもドラキュラが倒せる武器のことを銀の弾丸と呼ぶはず。『平凡なエンジニアでも、優秀なエンジニアと同等の力を発揮できるような環境』も銀の弾丸なのでは？

• id:Cald 会社が優秀なエンジニアを集めることと、凡人でも回せるようにすることって対立した概念なの？会社としては凡人でも回せる環境づくりは当然で、その上で優秀な人がいたらもっとよく回せるよって話でしょ？

加えて，優れた先進的なツールほど，開発者のスキルの有無が大きく影響すると思う．高スキルな人には鬼に金棒だが，低スキルな人だとツールに振り回されて，ない方がマシになることもしばしば．そして生産性の差は開く一方になる．*9 *10

低レベルプログラマに使えるツールは，高レベルプログラマにも使えるし，低レベルプログラマの生産性を押し上げるツールは，高レベルプログラマの生産性もやはり押し上げる．しかし高レベルプログラマには有効なツールが，低レベルプログラマに有効とは限らない．たとえばオブジェクト指向プログラミングやデザインパターン，例外機構のような今では当たり前となった技術ですら，低レベルプログラマには使いこなすことが出来ない．

だからどんなツールを用いて低レベルプログラマの底上げを図ったとしても，「低レベルプログラマの生産性が高レベルプログラマと同じになる」ことは非常に考えにくい．

• id:knjname 最後の段落、環境を改善できるエンジニアが優秀というのはその通りなので、平凡なエンジニアは手順を増やすことに終始します。もっと底辺想像してください。

なるほど．

手順を減らすためには，全行程を熟知し，どれが必要でどれが不要かを見抜いて取捨選択しなければならんから．「なんか良く分からないけど，動いてるから良いじゃない」な人は手順を減らしたり最適化したりは出来ない．

• id:tzt ダメなことに鈍感になって諦めてしまわないで、工夫して改善しようと行動できることこそが優秀なエンジニアの条件なのではないかと最近思っている。

• id:kiyo_hiko 「平凡なエンジニアでも、優秀なエンジニアと同等の力を発揮できるような環境を整えていく」 まずはマルチモニターから。

一緒になるとは思わないけど，たしかにあるね．デュアルモニタや増設メモリの費用すらケチるような会社は多い．

• id:rti7743 場合によって優秀の定義が変わって、ミスしない人から、知識がある人、手が早い人まで指しているのが議論をわかりづらくしていると思う。
• id:raitu 知らない人が100人集まっても知ってる1人に敵わないのが知識労働。しかしその「知ってる1人」は他の事しらなかったりね。優秀の定義は難しい
• id:tail_y “優秀なエンジニアがいなくてもやっていくために”／手元にいるエンジニアが実は優秀なのではと疑ってみるといいと思うんだよね。環境で化ける人とか、実は能力あっても環境で発揮出来てないパターンも
• id:kumaroku 優秀の領域、尺度は本人を含め同じ目線で見る事が出来ないのよね。資格は試験に優秀ってのはわかるけど仕事に優秀かはわからないし。仕事といってもね。いろいろあるから。

• id:gakusi 平凡と良いながら標準偏差のだいぶ右の方にいらっしゃるんじゃないのかな（もっと右が居るからと言ってそこは平均値とは言えない）。いやまあなんのデータも持たないただの感想ですが。

• id:kappaseijin 能力を伸ばす話と失敗をさせない&リカバリーする話が混ざっているような。仕組が大事なのは同意。

• id:s17er 優秀なエンジニアって魅力ある企業が抱えてる場合がほとんどで、中小のどうとでもない会社だと既存メンバーをどう底上げするかが大事だよね。仮に優秀なエンジニア採用できてもあっさりやめたりすることあるし

底上げは重要だが，それだけでは無意味だと思う．

中途で入った優秀なエンジニアが辞めるような会社は，新卒で入って底上げされて優秀になったエンジニアも辞める会社だから．

• id:hryord 激しく同意。スーパープログラマー最高みたいな風潮はクソだと思う。例えばそいつが事故や病気になったらどうするんだろう？全体を底上げして安定した仕事ができるようにするのがチームでやっている意味だと思う。

いつからスーパープログラマは一人しかいないと勘違いしていた？

加えて，低レベル プログラマの書く糞コードの方が，引き継ぎコストは遙かに高かったりする．低レベルプログラマが糞コードを大量生産してから夜逃げしたら，スーパープログラマなしで一体どうやって尻ぬぐいできると思う？

Twitter

その通りだと思います．

でも勉強しない人は過去の失敗事例を知らないままなので，今日もまた同じ失敗を繰り返してるという．生暖かく見守りましょう．

「人月の神話」より抜粋．

久しぶりに出してきたので，ついでに興味ある部分を幾つか抜き出しておく．（一部は上と重複．）

スケジュールの遅延が発覚した場合，自然（かつ伝統的）な対応として要員を追加することがある．火に油を注ぐがごとく，この対応は事態を悪化，それもかなりひどくする．火が大きくなればガソリンをもっと欲するように，悪循環はこうして始まり，結局大失敗に終わる．

第二の誤った考え方は，見積もりとスケジューリングに使われる仕事の単位，すなわち「人月」そのものである．コストは人数と月数の積に比例する．が，進捗はそうではない．したがって，仕事の大きさを測る単位としての人月は，疑うべき危険な神話なのだ．人月とは，人と月とが互いに交換できるという意味だからである．

人と月とが交換可能になるのは，多くの作業者の間でコミュニケーション（意思疎通）を図らなくても，仕事が分担できる場合だけである．これは小麦を刈り取るとか，綿を積むとか言うことには当てはまるが，どうがんばってもシステムプログラム開発には当てはまらない．

仕事が連続していて分担できない場合，人を増やすという対策はスケジューリング上，なんの効果も生まない．女性がどれほど沢山動員されたところで，子供一人が生まれてくるまで十月十日かかるのと同じだ．多くのソフトウエア開発作業はデバッグという順次的性質があるためにこうした特徴を持っている．

シェフと同じ立場にあるプログラマにとって，得意先の急な注文で作業予定を変更することはできても，実際の完成までコントロールは出来ないということに注目してもらいたい．例えば，二分で出来ますと約束したオムレツがうまい具合にできあがってくるかもしれない．もし二分でオムレツが出てこなかったら，顧客はどちらかの選択をしなければならない．つまり，出てくるまで待っているか，生焼けで食べるか，である．ソフトウエアの顧客も同様の選択が迫られてきた．

一方，コックには別の選択肢，すなわち火を強くすることが出来る．その結果は往々にして片面が焦げていてもう一方はまだ生という，救いようのないオムレツである．

一環として，経験を積んだプログラマグループの実績を測定した．そのグループの中だけでも，最高と最低の実績比率は生産性にして十対一，プログラム開発のスピードと量ではなんと五対一だった．ようするに，年間二万ドルのプログラマが年間一万ドルのプログラマの十倍も生産性が高いと言うことである．その逆もまた真だろう．しかし，このデータからは，経験と実績との間に何の相関も見られなかった（コレが常にそうだとは言えないと思う．）

先に調整を必要とする人の数が労力のコストに絶対的な影響を及ぼすと述べた．というのは，コストの大部分がコミュニケーションコストと，うまくコミュニケ-ション出来なかったことにより発生するマイナス面の修復（システムのデバッグ）だからだ．このことからも，システム構築は出来るだけ少人数で行いたいと思うことに繋がっていく．

結論は単純だ．つまり，二百人体制のプロジェクトに，極めて優秀で経験豊富なプログラマでもあるマネージャーが二十五人いたら，残りの集団百七十五人は首にしてしまい，マネージャーをプログラミング作業に戻せば良いのだ．

このジレンマは決定的なものだ．効率性とコンセプトの完全性の観点から見れば，デザインと制作は少数精鋭で行いたい．だが，大規模なシステムでは，製品をタイムリーに発表できるように，出来るだけ大量の要員を投入する方法が望ましい．

一方そうでない理由はインプリメンテ−ションをデザインすることが創造的作業でないというなら，外部仕様書を書くことも同じ事だからだ．種類の異なる創造的仕事なのだ．インプリメンテーションのデザインは，アーキテクチャが与えられているとしても，外部仕様書のデザインと同じくらいデザインの創造性と新しいアイデアと技術的卓抜さを必要とし，かつそれを発揮できる場だ．実際のところ，製品のコストパフォーマンスは実現者に最も依存し，それはちょうど使いやすさがアーキテクトに最も依存しているのと同じ事だ．

1950年代から1960年代の間に行われたどの研究からも，利用者は給与管理や在庫管理，会計管理などには店頭パッケージを使いたがらないことが示された．要件があまりに特殊で，ケースバイケースで違いが大きすぎたからだ．ところが1980年代には，そういうパッケージは需要も多く，広く普及している．何が変わったのだろうか．
（中略）
現在(1995年？)5万ドルのオフコンを購入する人は，カスタマイズされた給料支払いプログラムを発注することなど想像も出来ないので，自分の給料支払い方法の方を利用可能なパッケージに合わせようとする．

いずれも常識中の常識だが，SIerやマネージャにとっては認めたくない不都合な真実．

*1:で，トラックバックを送ろうとすると，はてなブログにはこれがないんだなあ．

*2:http://d.hatena.ne.jp/JavaBlack/20130808/p1

*3:こっちも同様．

デザインのためのデザイン

The Design of Design: Essays from a Computer Scientist (English Edition)

*4:最初の版はかなり古い．今となっては古典中の古典．

The Mythical Man-Month: Essays on Software Engineering

今となっては常識なので必ずしも読む必要があるとも思えないが，たまにこういうトンデモ理論を振りかざしてくる管理職から自己防衛するために，理論武装として必要になることがある．空しい．

*5:何年も修行した「波紋使い」でなくても，紫外線照射装置を使えば一般人でも倒せますっていうアレとか．

ジョジョの奇妙な冒険 第2部 カラー版 7 (ジャンプコミックスDIGITAL)

*6:同様に触れ込みだけ立派で失敗したものというと，CASEツールとか，コードの自動生成とか，形式的仕様記述とか，MDAとか，CMMIとか情報プロセス標準化だとか．あと何があったっけ？

*7:シグマプロジェクトもこの口だっけ．

*8:何度か書いているが，たとえば「a*b+cを計算する関数のテスト」なら容易に書ける，これが「疑似乱数が十分にランダムであることを検証するテスト」となると，それがスラスラ書ける人はそう多くはない．

*9:「Ｆ１のようなレースマシンの方が乗用車よりずっと速く走れる」的な話．凡人がレースマシンに乗ってもマシンのパワーに振り回されて，下手すると乗用車で走るより遅くなる．本当に早く走れるのは最高のレーサーが最高のレースマシンに乗った時のみ．

*10:PRESS ENTERのstaticおじさんみたいな話は，そんなに珍しい話でもない．http://el.jibun.atmarkit.co.jp/pressenter/2010/11/1-828a.html

ITエンジニア小説　高慢と偏見