まじめに読まれない”40年前に書かれた古文書”
本日は、田山花袋の蒲団と同じくらい、知られているけど読まれていない名著「人月の神話」についてご紹介します。
人月の神話とは？
人月の神話というのは、ソフトウェア開発の”単位”である「人月」という概念が、神話に過ぎない（つまり、意味をなさない）という悲しい真実を軸に、ソフトウェア開発が如何に困難を伴うものであるかを説いた名著です。一言でいえば、10人月の仕事＝1人で10か月かかる仕事は、「人月という単位が絶対であれば”10人で1ヶ月”でできるハズ」だが、そんなことは起こりえない、というお話です。そして、この状況を打破し、遅延したプロジェクトに100人投入して一瞬でシステムを完成させるような「魔法の道具（＝狼男に決定打を与える”銀の弾”）」は存在しない*と結論付けられます。
本書は、1975年（40年前！）に初版が発行されました。それが本書の1~15章です。その後、補稿とも言うべき「銀の弾などない（16章）」「銀の弾などない 再発射（17章）」が発表された後、初版から20年が経過した1995年に「人月の神話から20年を経て（19章）」が発表されました。
そして、その1995年から現在までには、さらに20年が経過しています。もはや「古典」を飛び越えて「古文書」と称されても仕方ないくらいの一冊です。
非常に今日的で、普遍的。
この書籍では、40年が立った今日でも全く色褪せることのない真理が沢山語られています。そして、その内容の大半は、ソフトウェア開発に限らず、非常に普遍的なものです。本書をしっかりと読むことは、様々な職種の人にとって、得るものが多いと僕は思います。
本気で読み込みすぎたという反省
というわけで、本当に気合を入れて読み込んでみました。
ただ、気合を入れすぎて、第0回~第21回の「22回連載」となりました。総文字数が（引用文も含んで）7万4,000字になってしまったので、もう、それ、直接書籍を読んだらいいんじゃないの？と我ながら思ったりもしつつ、とはいえ、書籍は30万字くらいあるのでそれよりは幾分マシなんじゃないかと思う次第です。まぁ、折角書いたので、お時間のある時に興味のある項目だけでもピックアップしてお読みいただければと思います。（とりあえず第0回を読んでいただいて、その後、興味のある回を選んでいただくのがオススメです）
「読み込み」の目的と狙い
本書を読み込んでいくにあたり、幾つか気を付けたことがあります。
- 明らかにシステムに特化した部分には、踏み込まない
- 時代遅れになってしまっている概念には、極力触れない
- 翻訳が回りくどかったりする部分は、思い切って「僕の解釈」でシンプルに書き直す
- システムに明るくない人＝ビジネス領域の人が読んでも分かるような具体例を可能な限り付加する
僕は、SE → 戦略コンサル → 起業 というキャリアを経てきました。そのキャリアを歩む中で、世の中における「ビジネス世界の住人の、システム領域に関する無理解」が、著しい非効率を生んでいるように感じています。システムは、ビジネス課題を解決するためのツールに過ぎません。どんなシステムを作るのか？は、どんなビジネス課題の解決を目指すのか？と同義です。にもかかわらず、多くのビジネスマンは、システムのことをあまり理解しようとせず、ベンダーにもやっとしたボールを丸投げして終わります。（関連記事：上流（ビジネス）と下流（システム）の切り分け）
この状況を打破するには、ビジネス世界の住人が「システム開発とはどういうものであるか」を”もう少しだけ”理解することが必要だと思うのです。現在は、その仕事をシステム世界の住人に押し付けている状態だと思います。「ビジネスがどういうものであるか、システムサイドが理解しろ」という要求をしているわけですね。これは（ある意味ではシステムサイドの方に失礼かもしれませんが）実現不可能な無理難題です。そんな無理難題をシステムサイドに押し付けるから、その間に入るコンサルティングファームが高い報酬を得て、”要件の翻訳作業”をすることになるわけです。（それはそれでもちろん価値があるんですけれど、コンサルはもっと有益に使うべきだと思うんですよね・・・高いんだし。）
それらを踏まえ、今回の一連の読み解きにおいては、ビジネス領域にも適用できる普遍的な部分を括りだしていくことに留意しました。それによって、本連載を読んだビジネス世界の住人が「自分事」としてイメージしやすくなることに加えて、システム開発における勘所も何となく理解できるようになることを目指してみました。その試みが上手くいっているかどうかは分かりませんが、騙されたと思って、ちょっと読んでみてくださいませ。
脚注） *：正確さを期するなら「ソフトウェア開発には固有の困難性（むずかしさ）があるので、人月の神話が成立しない。その困難性を魔法のように解決しうる銀の弾はない」という表現の方が適切だと思いますが、そのあたりは個別解説記事でご確認ください
連載目次：
- 第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章）
- おまけ：読まれない名著「人月の神話」を本気で読み込んでみた（まとめ） ※本稿
