目次
ソフトウェア開発者のバイブルだが・・・誰にも読まれていない
こんにちは、元SE（システムエンジニア）の田中です。新卒でSEになった2000年当時に「バイブル（聖書）」として読むことを勧められた一冊が、この「人月の神話」です。
だれにも読まれないバイブル
本書は、素晴らしい名著です。1975年に発刊され、すでに40年が経過しています。そんなにも長い期間「バイブル」として増刷され続けている本書について、著者であるフレデリック・P・ブルックス氏はこんな言葉を残しています。
この本は「ソフトウェア工学のバイブル」と呼ばれている。なぜなら、誰もがこの本を読んでいるが、誰もこの本で述べていることを実践しないからである。
出所：wikipedia
はっはっは、と声をあげて笑うべきところでしょうが、残念ながら、現実はもっと残酷です。正確には、「誰もがこの本を買っているが、誰もこの本を読んでいないからである」と言うべきです。
ちゃんと読むと、とても良いことが書いてある
然しながら、この本は、本棚に飾っておくだけでは、あまりにもったいない良書です。
そもそも、タイトルの「人月の神話」とは、「人（労働人数）と月（投下時間）が交換可能である」という、ソフトウェア開発の世界では「常識」とも言うべき考え方が、「単なる神話に過ぎない」と述べているわけです。これは、凄いことです。しかし、それから40年が経過した今も、人と月は交換可能であるかのように扱われ続けており、そして、非常に悲しいことに「デスマーチ」なプロジェクトが量産されています。
それは、いったいなぜなのか。本書をしっかり読むことで、ソフトウェア開発の本質が見えてくるわけです。
少しだけ頭出しをしておくと、本書はIBMの「OS/360」の開発における”失敗”に基づいて書かれています。一説によると、5,000人年！もの工数が投下されたと言われる、この伝説的なソフトウェア開発プロジェクトでの失敗から学ぶべきものは非常に多いハズです。
ただ、めちゃめちゃ長くて「読みにくい」
しかしながら、非常に残念なことに、本書は非常に長いです。19章で約300ページあります。（初版時の内容である15章までで、168ページとかですね）
そして、非常に読みにくいのです。訳者の方の並々ならぬ努力の跡が随所に感じられますが、いかんせん読みにくい。イメージでいうと「指輪物語」の和訳が非常に読みにくかったのと似てます。スッと頭に入ってこないんですよね。指輪物語を村上春樹が翻訳したら、相当読みやすくなるだろうなと思うんですよね、って、まぁそんなことしたら、フロドの一人称が「ぼく」になって、妙に達観して何かというと「やれやれ」とかつぶやきだすわ、エルフの声を「梅雨時の竹林を吹き抜けた風のよう」とかって表現しだして別の意味で頭に入ってこないような気もしますが。
さて、話がそれましたが、そんなわけで、これを頑張って読み通すには相当な労力が必要です。なので、大抵の人は、途中で心が折れてしまうわけですね。
こころが折れる前に「18章」を読もう
そんな大作を読む気力も根性もない、という人は、全てをあきらめる前に、ひとまず「18章」を読んでみることをお勧めします。
18章は『人月の神話』の命題 -真か偽か と題されています。なんと、1~15章の内容をたった24ページにサマライズしてくれているのです。
尚、18章の最初に、著者はこんなことを書いています。
「概略だけで済む内容なら、どうして165ページもの長さになったのか」などとは言わないでもらいたい
まぁ、そういいたくなるよねって感じですが、さすがに著者本人がまとめただけあって、非常に良くまとまっています。ですので、とりあえずこの章を読む、という選択は正解です。（読書感想文を書くときに、あとがきとか解説とかを先に読む、的な感じですね）
田中の「オススメ順序」
いやいや、もうちょっと頑張って理解したいんだ！という方にオススメの読み方もあります。
それがコチラ。
18章で全体を把握し、16→17→19で、情報の鮮度を上げる。というものです。（まぁ、18章＋19章だけでもいいですけどね。）この読み方にすることで、18章(24p)＋16章(26p)＋17章(21p)＋19章(38p)の、100ページ分くらいで済みます。
その上で、18章の中で特に気になったところを、原文＝1~15章にあたる、というのが良いと思うのです。
この連載は「田中のオススメ順序」に沿って進めます。
というわけで、本連載では、この「田中のオススメ順序」に沿って、読み解きを進めていくこととします。
ただ、最初に読み解く18章は「サマリー」ですので、原著を読んでもらうことを強くお勧めしたいと思いますので、「各章のタイトルの意味するところを説明する」に留めます。その後、16章・17章・19章の順で読み解きを進めていき、さらに（18章と重なる部分は非常に多いでしょうが）1章～15章を、それぞれ深堀していく、という流れとなります。
では、次回＝読み解き初回は、「18章を読み解く：各章のタイトルの意味するところ」です。長期連載：火の鳥を読み解く並の超大作になってしまいそうですが、何卒お付き合いいただければと思います。
ぜひ、「ソフトウェア開発のバイブル」を一緒に読み解いていきましょう。
連載目次：
- 第0回：人月の神話とはなんなのか？ 【当記事】
- 第1回：各章のタイトルの意味するところは？（18章）
- 第2回：銀の弾は無いけど”銃”はあるよね（16章）
- 第3回：反論に対する反論（17章：前編）
- 第4回：再利用って、口で言うほど簡単じゃないんだよね（17章：後編）
- 第5回：やっぱり、人と月は交換できないのだ（19章）
- 第6回：”翻訳する”ということにも、本質的なむずかしさがある（エピローグ/訳者あとがき）
- 第7回：「プログラムを書く」と「システムを作る」は別物だ（1章）
- 第8回：人と月は交換可能ではない、という言葉も魔法の言葉じゃないよ（2章）
- 第9回：少数精鋭×複数チーム＝生産性の高い大規模システム開発（3章）
- 第10回：コンセプトの完全性を優先せよ（4章）
- 第11回：慣れてくると、やりすぎるのが人の常（5章）
- 第12回：文書は、アーキテクトの”製品”であると知れ（6章）
- 第13回：コミュニケーションの効率化がプロジェクト成功の秘訣（7章）
- 第14回：”見積り”にも銀の弾は無いのだ（8章）
- 第15回：メモリが安くなったからといって「無限」だとは思わない方が良い（9章）
- 第16回：ドキュメントにまとめることは”形式”ではなく”本質”（10章）
- 第17回：その場に留まりたければ、走り続けなくてはならない（11章）
- 第18回：「考える」と「作る」は別物（12章）
- 第19回：プログラムを書いても、動くとは限らない（13章）
- 第20回：今日の遅れを見過ごすな（14章）
- 第21回：ユーザーのための文書も”製品”の一部だ（15章）
- おまけ：読まれない名著「人月の神話」を本気で読み込んでみた（まとめ）
