【書籍】人月の神話
【書籍】人月の神話
購入とその動機 2026-03-31 (火)
人月の神話、たぶん買った事もあるはずだし2回くらい読んだ気もするのだが、手元には見つからなかったので、たぶん電子化前に買ったものと思われる。
最近カクヨムで駄作を読みすぎているという自覚があり、もうちょっとカクヨムを読んでいる時間を減らそう、という気がしていた。 でも現在【書籍】最強の集中力を読んでいるのだが、たまに納得出来なかったり気に食わない主張をしている所に入ると読む気が失せたりして、 やる事が無くなってしまう。
そこで、もうちょっと無害でだらだら読める何かは無いかな〜と思っていた所、 マストドンで達人プログラマの話になり、自分もなんか前に書いたなぁ、と過去に書いたRe^2: 複雑さのはなし（から定番本について） / karino2 - Message Passingを読み直していたら、 人月の神話の事を思いだした。
もう良いコードの書き方みたいなのは同意出来ない事の方が多いし何かを学べる気も全くしないので読む気は起こらないが、 人月の神話などはむしろ今でも読めるんじゃないか？という気がして、 ついカクヨムでランキングから駄作を探してしまう時に代わりに読んでみるか、と買ってみた。
第1章 タールの沼
二人のプログラマがガレージで作るものとOS/360の違いの話は、少し時代を感じる。この単なるプログラムからお金にする間のそれぞれの3倍を、 どうやって無くすか、というのが、業界がずっと頑張って探求している事に思う。 完全にプログラムだけになった、とは言えないけれど、ここで述べられている多くの「〜でなければならない」というのは、 そうでも無い状態でお金にできている。
また、この頃はプログラムをお金にするというのを、商品として出荷するようなイメージでいて、 ヒットすればお金になり、ヒットしなければお金にならない、というケースが全くでてこない。 これは時代の変化であると同時に、 ソフトウェア開発の本質の重要な所でもある、 「ほとんどのソフトウェアはヒットしないので失敗である」という前提が無い。 むしろガレージで二人で作っていたものの方がこの本質を良く理解していると思う。
ただこういう現代との乖離は、当時はそうだったんだな、というだけで、別に読んでいて不快だったりイライラしたりはしない。 これは中途半端に現代に近く無いので、かえって歴史として素直に読めるからなんだろうな。
一方、タールの沼のようにソフトウェア開発プロジェクトが進まなくなるという比喩は現代でもそのまま当てはまる。 また、「作る喜び」のセクションはほとんどそのまま現代にも通用する話で、 「作る苦しみ」はプログラマの裁量がずっと大きくなった以外はこちらも現代に多く通用する。 通用するだけじゃなくて、むしろLLMのコードagentが実用化段階に入った結果、 この作る喜びは改めて問われている事でもあって、とても現代的な話に見えてくる。
期待通りカクヨムの代わりにダラダラ読むには良さそうな気がしてきた。よしよし。
第2章、人月の神話はさすがに良く書けている
人月の神話は他の章と比べても一般性が高い気がする。現代から見てもさすがに良く書けた章だな。
この本の多くの場所がOS/360のシステムプログラムを前提としている所が多く、 そのソフトウェアのあり方自体が現代では避けられるようになっているため、 当てはまりが良くないものも多い。 むしろ何故それらを現代では避けるようになったのか、というのを知るのにこの本の記述が役に立つ、みたいな性質だったりする。
だが2章に関してはもう少し一般的で、製造業的なものの延長として組織が構成されている時に発生する共通の問題になっている。 そうした組織自体が時代遅れではあると思うけれど、 素人が考えると現代でもこうしたくなる所なので、それがソフトウェア開発でやろうとするとどうなるのか、 ということを知るには現代でも普通に役に立つ。 そしてこういう組織はOS/360というシステムプログラムの時代性ほどには過去になってない気もする。
だからこの章は今読んでも価値を感じるのだろうな。
第3章、外科手術チーム
こんな話あったっけ、というほど印象に残っていない章だったが、チーム構成の一案みたいなのが載っている。 現代ではあまり見ない構成で、別段それが現代の普通のやり方と比べて優れているかが何も分からないので、 こんなのを見せられても困ってしまう。
ただ副執刀医は置いといて、他は割と現代でも存在する役割ではある。 一つのチームに入れるのは一般的では無く、それぞれ別のチームになりがちだな、と思うが。
MSなんかはトライアドとしてdev, test, PMの三人を組ませる伝統があって、これは外科手術チーム的なものを縮小したものという気がする。 ただこれも現代では一般的では無いよな。
昔よりもプロダクトの境界が人の境界になっていない気がする。プロダクトがアクティブな時期とあまりアクティブでない時期があって、 アクティブでない時にはそのプロダクトのチームは他のプロダクトにも掛け持つ事になって、 そういう柔軟さと組織構造の硬直性を両立させるためには、組織構造はプロダクトと一緒にはしづらい、という気がする。
大きなサービスでも機能がプロダクトに相当する感じで、やはり人が柔軟に役割を変えていくので、 開発チームに全部所属させるのは難しい気がするな。
それと昔よりもプログラマがやる範囲は増えた気がする。 その結果、コーディング以外はおざなりになって、 例えばOS/360に比べてAndroidのドキュメントは酷いものとなっている。 なっているが、より完全な方が市場で勝っている訳では無いので、 より必要なものだけにフォーカスしているとも言える。
やはり当時は、競争という意識が低いよなぁ。あるタスクが不要かどうかを、市場では無く顧客の言う事で判断してしまっている気がする。
あまり意義のある章という気はしないが、当時を偲ぶ歴史的な資料としては、へーという気分で読めるな。
4章、アーキテクトとコンセプトの完全性 2026-04-04 (土)
アーキテクチャは一人または少数の人間で考えてコンセプトの完全性を達成するのが大切で、 その制約の元で実装者が実装するのが良い、という話。
現代では多くのソフトウェアで、独立したアーキテクトというのは居なくなっている。 そしてコンセプトの完全性はだいぶ後退しているような気もする。
個人的な印象ではJavaとか.NETの頃は割とコンセプトの完全性は高かった気がする。 webのはやってるフレームワークとかも割とその辺はしっかりしていた気もする。 一方Androidはそうでも無い。iOSはどうかな？Androidよりはマシな気はするが、.NET時代よりはだいぶ劣っている気もする。
アーキテクトを実装から独立しなくなったのは、言語やライブラリの向上により、実装とアーキテクチャを記述する事の差が減ってきたから、という要素はある。 現在は自然言語でアーキテクチャを記述したいとは思えない。型チェックやインテリセンス無しで大規模な記述なんてしたくないだろう。 結果として実装とアーキテクチャの境界が曖昧になり、実装の中に埋め込まれた。
コーディングのフィードバックの軽視
この本は、コーディングによるフィードバックを軽視している。この本に限らず、製造業の延長としてソフトウェア開発を考えていた時には皆この部分を軽視していた。 ハッカーと画家はそこの重要さを説いた所が偉かった。
コーディングは、その途中で言語を通して世界からの反発があり、その反発が問題に対するより深い理解を生み、 その深い理解がアーキテクチャに反映されないといけない、というのが現代の主流となる考えだろう。 それがアーキテクチャとコーディングを分離するのを避ける結果になっていると思う。
アーキテクチャを考える良い方法としてコーディングがある。コーディングにはアーキテクチャを考える以外の余計なコストも入ってしまうが、 それを分離してより効率的に考えられる何かを作るのは結局費用対効果に見合わないため、コーディングをアーキテクチャを考えるツールとして使っているというのが現状ではないか。
実装から生まれるアーキテクチャ
アーキテクチャは先に考えるものでは無くて後に生まれてくるもの、というのも現代的な考えと思う。 先に設計図を書くようにつくるものでは無く、 実装の中で石を削って生まれてくる石像のような何か。
削っていくのがリファクタリングで、このリファクタリングでアーキテクチャを生み出していくというのがこの頃と現代の大きな違いのように思う。
一方、実装すれば勝手に生まれるというものでも無く、 問題のドメインや規模によって生まれた方が良かったり別に不要だったりもする。 この辺の事情も問題の多様性にあっている。
ただ本来はアーキテクチャを削り出していかないといけない時にそれをサボってしまうというのも良くあり、 それは独立してアーキテクチャをちゃんと定義しなかった時と同じ問題が発生する。 その問題は本書の記述が割とそのまま適用されるようにも思う。
LLM時代にはまた再燃しそうな話ではある
アーキテクチャを実装の前に定義する、という話は、LLMに実装を生成するという時には似た構造になる。 この辺の話はLLM時代にはいかにももう一度やる事になりそうだ。 一方で実装のフィードバックをどうするのか、という問題は結局また問われる事になり、 最終的にはアーキテクチャも人間が記述すべきでは無い、という結論になりそうな気もする。
まぁその辺の事はその辺に興味のある人が探求する事だろうな。 自分はそういうのにはなるべく近づかずに、もっと違う事に注力したいと思っている。
5章、セカンドシステム症候群は古びてないな
１つ目は我慢していろいろ妥協したものを作れるのに、２つ目は夢いっぱいを詰め込みすぎて現実離れした失敗作を作りがち、という話。 これは普通に現代でも良くある話だよなぁ。
大型リリースを避けるというのは現代では増えたけれど、一方で大型リリースが必要なケースは依然としてあり、 その場合には何らかのプラクティスでこれを避けているという事はない気がする。
大型リリースが減ったというだけで、大型リリースの難しさの多くは現代でもそのままだよなぁ。
6章、命令を伝える 2026-04-12 (日)
どうやってメンバー全体にアーキテクトの決断を周知徹底させるか、というような話。 外部仕様として自然言語で書かれたマニュアルを作るんだ、みたいな事が書かれているが、 このような先に書かれる外部仕様としてのマニュアルというのは現代では死滅したよな。
あった方が良いというのはありえる話だが、まぁ現実として無い。
ミーティングの話もあり、週に一回半日のミーティングがあり、さらに一年に一回全体ミーティングがあってこれは何日も続くとか。 うげぇ、という感じだな。 まぁ現代では間違いなく機能しないだろう。
ただ、週次ミーティングの、変更の提案が文書化されて最初に共有されて〜みたいなのは、PEPとかに現代でも引き継がれているな。 ミーティングでは無いが、プロポーザルを文書化して議論して進めていく、というのは受け入れられたと言えそう。
このくらいの規模の開発になると、現代はほぼ必然的にオンラインベースになるよなぁ。 地理的に一箇所にメンバーが集まっている事もほぼ無いだろう。 これも良い事というよりは、それが現実、という話だろう。 何千人というメンバー全員をオフラインで数日間議論させる、というのはもう無理だ。
7章、バベルの塔は、なぜ失敗に終わったのか？ 2026-04-13 (月)
この章はなんの章かを表すのが難しいが、大規模プロジェクトのコミュニケーションのための組織構造、という話か。 アーキテクトとマネージャーが出てきてそれぞれの役割の違いなどを説明する。
現代でもテックリードとマネージャーという感じで割と生き残っている概念に思う。 ただアーキテクトとリードは同じでは無いし、ICという概念も弱いが。 それでもマネージャーとは別の技術主任というものが必要である、 という事に注目しているのは正しいと思える。
リードの上にリードリード的なのを置いて技術の組織階層を作り、 チームとしてはPeople Manager的なマネージャを置くというのが自分が居た頃のMSの構造だった。 ただ職責ごとの組織構造とチームごとの組織構造は定期的に行ったり来たりしていた。 この辺の構造は答えは無い所だよなぁ。
プロジェクト手引書というのは絶滅しているように思う。少なくとも自分はそれが何なのかすら知らない。 ただ連番に書いてツリー構造にもする、 というのはIssue Trackerのチケットと、それをWikiなどにまとめるというのと似た話には感じられる。 そしてリビジョン管理が無い時代のこの辺の話はさすがに遠い歴史って感じだな。 現代ではこうしたドキュメントが開発の初期で準備されてみんなが読むという事は無い。
なぜコード中心になっていったのか？
この本を読んでいるとかつてはドキュメントがより重視されていたのがわかる。 そしてドキュメントを重視するのはメリットも多い。
ではなんで比重が下がっていったのか？というと、結局コードコンプリートに書いてあった、コーディングだけは省略される事が無い工程だから、という事に思う。 省略されうる工程は省略される事があり、 そうした省略された工程を含むプロジェクトの存在を前提に大きなプロジェクトは考える必要があるので、 全体に完全に何かを課すのが難しい、という事に思う。
また、プロジェクトの変遷でいろいろなものは失われる。組織的な事情で閲覧権限が無いメンバが生まれたりもする。 けれどコードだけはそうしたいろいろな圧力を跳ね返す強みがある。 コードが無いとビルドが出来ないから。
だから時代が進むに従い、結局コード以外は残らなかったという事が繰り返し起こり、 その結果コードにいろいろと埋め込むノウハウが発達したんじゃないか。
コード中心の方が優れたプラクティスだった、というよりは、コード中心の現場がそこにある以上、 そこで使えるプラクティスじゃないと意味が無い、という事に思う。 だから理論的に考えるだけだと出てこない結論だったのだろうと思う。
「XXでなければならない」と本書では繰り返し述べられるが、現実がそうで無いならこうした主張はむなしい。 アジャイルマニフェストの「包括的なドキュメントよりも動くソフトウェアを重視する」と言ったのは、 わざわざそれを言う必要があったのだろうな。