機雷がなんだ! 全速前進!

SEというかプログラマというか、日々のエンジニア生活の中で体験したことなどを中心に書きためていくことにする。

*[本]人月の神話

最近あらためて「人月の神話」を読みました。

f:id:orinbou:20201221010023p:plain

人月の神話(20周年記念増訂版)

昨年の12月はAWS re:Invent 2019へ向かう途中でマウンテンビューのコンピュータ歴史博物館へ立ち寄った。そこに、この本の原著(と思われる本)が展示されていた。 最初の刊行は1975年だから、きっとその当時のものだと思う。

The Mythical Man-month:人月の神話

初版から既に45年が経っているにも関わらず、この本は今でも尚、大規模開発プロジェクトのソフトウェア工学の古典として読み継がれている名著と言われている。本の横に書かれているのは、あの有名な『ブルックスの法則』で 

「遅れているソフトウェアプロジェクトへの要員追加は、さらにプロジェクトを遅らせるだけだ(Adding manpower to a late software project makes it later.)」

 というやつです。最近たまたま、この本を思い出すきっかけがあったのであらためて手に取ってみた。

 

まず、本の表示の獣を何故かずっと熊と思い込んでいたのだが、実はメガテリウム(オオナマケモノ)という新生代(約5百万~1万年前)の生物だった。確かに熊と違って尻尾が太い。全長6~8mで体重3tにもなるそうで熊よりよっぽどデカい。そして、第1章「タールの沼」の直前に下記の絵が掲載されており、左側にサーベルタイガーも描かれており確かに古代(新生代)を前提とした絵であることが分かる。

f:id:orinbou:20201223013526p:plain

タールの沼

この本の中で、著者のブルックスは、大規模なソフトウェア開発をもがけばもがくほど絡みつくタールの沼に例えている。

 

そして著者はソフトウェア開発の複雑性を次のように区別して考えている。(第16章)

 

●「本質的な複雑性」

 ソフトウェアの性質に固有な困難のこと

【本質:データセットやデータ項目間の関係、アルゴリズムや機能呼出などが組み合わさったコンセプトで構成されたものであり、同じ概念構造が多くの異なる表現で表されるという点で抽象的である。にもかかわらず、非常に正確で十分に詳細であるということ】

【困難:概念構造体の仕様作成とデザインおよびテスト】

 

●「偶有的(副次的あるいは不随の)な複雑性」

 目下の生産性にはつきまとうが本来備わっているものではない困難のこと

【例:実装(言語、ランタイム、ツール、プログラミング手法)にかかわるもの】

 

このように区別したうえで、ソフトウェア技術の進歩(例:高水準言語、オブジェクト指向プログラミングなど)は、主に偶有的な複雑性を解決して生産性を向上してきたが本質的な複雑性を攻略できた訳ではないと主張している。(確かにそうかも)

 

つまり、本質的な複雑さは、依然として攻略困難な課題として存在し続けており、それこそがソフトウェア構築は(当時と比べて飛躍的にテクノロジーが進歩した今でもなお)いつでも困難であり続けており「銀の弾丸はない」ということに繋がっているように思う。

 

この本は、最初の刊行では15章までだったけど、この20周年記念贈訂版では16~19章が付け加えられており、当時から20年の時の経過をふりかえっての後日譚が多く記載されている。

 

その中で、順次モデルまたはウォーターフォールを改良したウィンストン・ロイスについても触れているのが興味深い。それにも関わらず、未だにロイスは改良前(フィードバックが許されない古典的な)のウォーターフォールの父として語られているのを耳にすることがあるので少々気の非常に毒に思う。聞くたびに「そうじゃないんだよ」と訂正しているけど。あと、米国防総省の黒歴史DOD-STD-2167のことも書いてあった。日本にも強い影響を与えた仕様ですね(今や黒歴史?)

 

漸増的(インクリメンタル)構築モデルの利点を述べ、常にシステムが動く状態にしておくことの重要性についても触れているのは興味深いし、(当時の)マイクロソフトの「毎晩構築」アプローチは、継続的インテグレーションとデイリービルドの考えを地で行ってる感じがした。

 

『人間が全て(そう、だいたいのところは)』の節で言及している「成功のためには、プロジェクトに携わる人々の質、およびその組織形態と管理こそが、使用するツールや採用する技術的アプローチよりもはるかに重要な要因であると考えている」という点にも一考の余地があると思う。同じページでデマルコの「ピープルウェア:生産的なプロジェクトとチーム」も引用されていた。両翼からのアプローチは大事ですよね。

 

経済学者E.F.シューマッハーの「小さいことは美しい:あたかも人間を重視するかのような経済学の研究」を引用して、チームに権限を委譲して自由を与え、結果の責任を持たせることで準企業体を目指す企業がいる、など他にも興味深い話は多々あったけど、キリがないのでこの辺で。

 

本書の最後の節に「ソフトウェアエンジニアリングというタールの沼は、これから当分の間厄介なままだろう。人類が、手の届く範囲の、あるいはギリギリで届かないところにあるシステムを、ずっと試していくことは容易に想像がつく。ソフトウェアシステムは、人間の作り出したもののうちで最も複雑なものだろう。」と書かれている。これは増訂版が出版された1996年に書かれたもので、その時点から更に25年が経過している。

ソフトウェアエンジニアリングが今尚タールの沼のままなのかどうかはさておき、ソフトウェアの本質的な複雑性はさほど変わっていないと思う。ので、考えてみれば大変な(だが面白い)仕事を生業にしたもんだな、とつくづく感じる。(勿論いい意味で、)