【書籍】人月の神話
【書籍】人月の神話
購入とその動機 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時代にはいかにももう一度やる事になりそうだ。 一方で実装のフィードバックをどうするのか、という問題は結局また問われる事になり、 最終的にはアーキテクチャも人間が記述すべきでは無い、という結論になりそうな気もする。
まぁその辺の事はその辺に興味のある人が探求する事だろうな。 自分はそういうのにはなるべく近づかずに、もっと違う事に注力したいと思っている。