読者です 読者をやめる 読者になる 読者になる

感謝のプログラミング 10000時間

たどり着いた結果(さき)は、感謝でした。

ソフトウェア開発でよく言われる「銀の弾丸など無い」とはどういう意味なのか本を読んでみた。

<スポンサーリンク>

ソフトウェア開発者であれば、様々な文脈で「銀の弾丸など無い」という言葉に触れたことがあると思う。

これは元をたどれば、1986年のIFIP(情報処理学会国際連合)という学会で発表された論文にたどり着く。
ロバート・L・パトリックが著した「銀の弾などない」という論文は1987年にIEEE(電気電子学会)の「コンピュータ」誌に再掲載されて大いに反響を呼んだ。

銀の弾丸など無い」という言葉の意味は、「ソフトウェアの生産性において、格段の向上をひとりでにもたらすようなプログラミング技法は今後10年間は登場しない」という意味である。

注意すべきは、当時はSpringフレームワークも無かったし、Cake PHPも無かった。
Ruby on Railsも無い1986年の頃の話だというである。
僕が生まれたか生まれないかくらいの話で、日本にバブルが来る前のことだ。
つまり、ものすごく昔、古き良き時代の話だ。

人月の神話という本がある。
この16章「銀の弾などない -ソフトウェア・エンジニアリングの本質と偶有的事項」という項目で、銀の弾丸について述べられている。
表紙の文言がこの章で述べていることを集約している。

「技術においても管理手法においても、それだけで十年間に生産性や信頼性と容易性での飛躍的な改善を一つでも約束できるような開発は一つとしてない」

さて、銀の弾丸とは何のメタファー(比喩)なのか?
銀の弾丸とは、「狼人間を魔法のように鎮めることができる」というものである。
では、狼人間というのはなんだろう?
狼人間とは、「慣れ親しんでいるものを恐怖に変えてしまうもの」のメタファーだ。
本ではこう書かれている。

慣れ親しんだプロジェクトにもこうした性質があり、ふだんは無害でまともなのだが、スケジュールの遅延、膨れ上がった予算、そして欠陥製品といった怪物にもなり得る。
そして私たちは銀の弾、すなわちコンピュータハードウェアのコストと同じようにソフトウェアのコストも急激に小さくしてくれる特効薬を求める必死の叫び声を聞くのである。

このような記述から、冒頭に記したような結論につながる。
すなわち、「特効薬などない」という結論だ。

なぜ、特効薬は無いのか?
論文では色々と書かれているのだけれど、記述が80年代っぽくて、まだ勉強不足の自分にはちゃんと理解できていない。
でも、なんとなく分かる部分をかいつまんで読み進めてみたい。

まず、「ソフトウェアの複雑性は本質的な性質であって、偶有的なものではない」という点。
言い換えると、ソフトウェアってのは本質的に複雑で、たまたま複雑だったり単純だったりするわけではないよってこと。
そして、ソフトウェアを構築する時に難しいのは、処理を書くことよりも、インターフェース(仕様)を作ったりデザイン(設計)する部分だよ、ということを言いたいのだと思う。

次に、同調性。
これは現場でもよくあるんだけど、一回作ったものはなかなか変えられない。
「既に動いているもの」に合わせるために、機能追加をするときなんかは色々と考えなければならない。
「多くの場合、ソフトウェアは、最後に登場したという理由で他に従わなければならない」と書かれているが、まさにその通りで、それこそが複雑性が発生する元であるという。

次に、可変性。
ソフトウェアは常に変更という圧力にさらされているという。
システム中のソフトウェアはその機能を具現化したものであり、機能こそがたいていの人が変更の必要性を感じる部分だからである。
例えば、今ならカーナビ。カーナビの形が嫌だ!変えてくれ!という人よりも、カーナビの表示が遅い!カーナビに口コミが表示されるようにしてくれ!
という要求の方が多いのではないだろうか。
このように、ソフトはハードによりも変更の圧力にさらされる部分が多い。

最後に、不可視性。
ソフトウェアの構造は本質的に視覚化できないままになっている、とされている。
そのため、強力な概念上のツールを作る意欲を阻害している、と。で、その概念上のツールが作成できないから、思考を阻害し、コミュニケーションを妨げている、とされている。

ちなみにUMLが登場したのが1996年。ちょうどこの論文が発表されてから10年後のことだ。

上で述べたような、ソフトウエアの本質的な性質から、生産性を劇的に向上させる魔法なんてないよ、というのが、この論文の論旨であるように思う。

ここからは僕の見解。
1986年にこの論文が発表されてから、10年間。
その間、たしかにソフトウェアは大きく進歩したかもしれないが、銀の弾丸は無かった。
しかし、ソフトウェアにとっての黄金期は次の20年だったのだと思う。

フレームワークが開発され、テストは自動化された。
サーバの構築までもが自動化され、人間はより創造的なことに時間を割けることになった。
勤勉で新しい技術を吸収する努力を惜しまないエンジニアにとっては、生産性が劇的に向上した時期に違いない。

一方で、Excelからコードの自動生成とか、努力しないダメなエンジニアを助けるようなツールは、どんどん駆逐されていっているように思うし、そのようなずれた意味での自動化が、開発現場を助けるようになるとは思えない。

本にも以下のように書かれている。

輝かしい進展は見えないけれど、一貫した努力こそが飛躍的な改善をもたらすはずだ。
王道はない。しかし、道はある。

魔法のような銀の弾丸は無いかもしれないけれど、一貫した努力をしているエンジニアにとって、確かな道はあった。
一歩一歩ではあるが、確実に進んできたのだと思う。

一方で、魔法の銀の弾丸ばかり探し求めて、1980年代の技術に未だにしがみついているエンジニアは、生産性の面でも技術者としても、価値を生み出すのがどんどん難しくなっていると思う。

1986年から27年経った今でも、魔法のような銀の弾丸は存在しない。
それでも、銀の弾丸を探さずに地道な改善を続けてきたエンジニアと、銀の弾丸を探し求めて努力を怠ったエンジニアの生産性の差は1000倍以上になっている。

読んだ本

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

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

感謝のプログラミング

今回で感謝のプログラミングは【463時間目】
10000時間まで、あと【9537時間】