積読消化 - 人月の神話

これまでたくさんの技術書を買ってきて、残念ながら積みっぱなしで読んでいない本がいくつか (も) ある。今年はこれを一掃すべく、技術書を新たに買わず、書棚に並ぶ積みっぱなしの本を読むことに時間をあてようと、年の初めに誓った。と言いながらすでに 4 月に突入しており、依然として 1 冊も消化しないまま時間が過ぎていたのだが、この頃一念発起して、1 冊読んだ。表題の「人月の神話」である。

読むだけでもいいのだが、何かしら本を読んだことにまつわる OUTPUT を出すことで、本への理解が深まることを狙いとして、書評などという大げさなものではないが、読書感想文を書くことにした。


言わずと知れたソフトウェア開発にまつわる本の中でも名著と呼ばれる作品で、ずいぶん前から書棚にあった。一章二章程度は読んでいたと思うのだが、通読はしていなかった。

本書は大規模ソフトウェアのシステム開発におけるマネジメントに焦点を当てた本である。ぐらいの前提知識はあったのだが、実際に読んでみると、プログラミングやそれにまつわるツールといったところにも言及があって、少し驚いた。1970 年代に書かれた本なので、具体例はいちいち古めかしい。読んでも正直よく知らない (もしくは名前ぐらいしか知らない) 単語が出てくる。OS/360 とか。特にデバッグやプログラミング、ツールに関する話題は、現代では類書が多くあるので本書では斜め読みする程度にとどめた。

本書によれば、人と月が交換可能であるには、作業者の間でコミュニケーションをとる必要がない場合に限る、とある。作業者間でコミュニケーションをとる必要がある場合、作業者を増やせば増やすほど、コミュニケーションコストが増していく。この状態のまま作業者を増やし続けていくと、いつしか作業者を増やすことによる作業者一人あたりのコスト減よりも、コミュニケーションコストの増分のほうが大きくなってしまう。

経験上、ソフトウェアの開発において、コミュニケーションをとる必要がないようにするのは難しいか、ごく一部の作業に限られるように思う。ソフトウェアの開発は意思決定の連続なので、識者、あるいは関係者への相談は絶え間ない。プログラミング中においても、API の策定、API の使い方の説明、コードの説明、テスト方法の情報展開など、コミュニケーションをとらなければならない機会はいくらでもある。

先にあげた本書の人月に関する説明は、とてもしっくりくる。普段もやもや考えていたことが、すっきりと理解できたような、そんな気分になる。

16 章は、かの有名な「銀の弾はない」という格言の章である。この章が書かれた当時、銀の弾として期待された技術や手法を、バッサバッサと「銀の弾ではない」と切り捨てていく様は、残念な気持ちになると同時に、とても気持ちがいい。

ソフトウェアの難しさを本質的困難と偶有的困難の 2 つに分けてアプローチしている。本質的困難とは、ソフトウェアにそもそも備わっている性質からくる難しさで、偶有的困難とは、主にソフトウェアの表現にまつわる難しさであると説いている。偶有的困難をいくら軽減しても、本質的な難しさは軽減されないので、限界があるとのこと。偶有的困難を軽減するツールの例として、高水準言語、ツール、よいハードウェアの導入などを挙げている。いくら高級なプログラミング言語を使ったところで、ソフトウェアの本質的な難しさ (本書では「仕様の決定と、そのテスト」を挙げている) は軽減されない。確かに。

ソフトウェアの本質的な難しさへの取り組みのひとつとして、迅速なプロトタイピングを挙げている。現代のアジャイルと似たようなアプローチではないかと理解している。現代のソフトウェアは、事前に正確かつ完璧に設計することが難しい。これは顧客が事前に正確な要件を提示することも難しければ、技術者がそれを正確に仕様に落とすことも難しいことに起因する。この溝を埋めるひとつの方法として、迅速なプロトタイピングを挙げている。実際に動くものをみることで、顧客は本当の要件に気づく。また、技術者なプロトタイピングによって仕様の理解を深める。これを繰り返していくことで、仕様を洗練させ、ソフトウェアの品質を高めることに繋がる。


上でも少し書いたが、全体的に例が古めかしく、改めて古い本であることを認識させられた。その一方で、内容は陳腐化しているどころか、現代ではベストプラクティスとして語られているような内容がいくつもあった。著者の慧眼によるものか、逆に現代のベストプラクティスが本書をベースにしているものなのかは分からないが、読んでみる価値は大いにあったと思ったのだった。