「人月の神話」を読んでいるが現在進行形で全く分からない

おはこんばんにちは。

分からないものを何が分からないまま放っておくな、という電波を受信したので(?)
ちょうど今読んでいる「わからない」について書いていきます。
人月の神話を読んでいるのですが、現在進行形で全く分からねえという話です。
どうか心の広い方のみ、お読みください。

人月の神話を読むきっかけ

Amazonのオススメに出ていて、IT系なら一度は読んでおけ的な立ち位置の書籍に見えたからです。
後はSIer時代に痛い思い(人手が足りていなくて外部会社に委託してPMをしていたはずが、結局間に合わなくて自分が手を動かす羽目になった…etc)をしたので何かヒントがあれば良いと思いました。

手に入れたきっかけ

干し芋のリストから出産祝いでいただきました。ありがとうございます。

読む前の印象

銀の弾丸はない」の元ネタですよね。ぐらいの印象でした。
技術書ではなくてあくまでエッセイなんですねこれ。

読んだ感想

初版の序文

"オペレーティングシステム/360のマネージャーになったとき…"
ほーん、この人OS/360のマネージャーなんやな…OS/360ってなに?

ja.wikipedia.org 「本格的な商用OSとしては世界初であり…」

  • 磁気ディスク装置を扱う最初のOS→その前はなんだったの?テープ???
  • アセンブリ言語で記述された→今のLinuxはCやもんね
  • 当初より企業用として、プログラム(プログラマAPI)と運用管理(オペレータ用システムコマンド、JCL)を明確に分離している→その前は分かれてなかったの????
  • 現在のIBMメインフレームOS (z/OS) も、OS/360を受け継いでいる(上位互換)

今のメインフレームのもとになった(昨今メインフレームを触る機会はほぼないし私も触ったことがない…)OSというふうに理解しました。
OS/360のマネージャーをやっていた人が、大規模プログラム開発プロジェクトを進めるうえで、管理について悩んだことをまとめた本なんだな。と 思いながら読み進めることにしました。

第1章 タールの沼

"大規模システムプログラム開発は、過去10年もの間そうしたタールの沼のようなものだった"
 プログラムを、プログラムシステム製品にするにはどのような工程があって、どんなコストがかかるのか。最終的に9倍に膨れ上がるという話でした。
"作る喜び"
  わかる。何か作るのは楽しいよね。 "作る苦しみ"
 わかる。あんまりプログラム書かないけど、ちょっとしたスクリプトでもデバッグは大変だったからね。

第2章 人月の神話

"プログラマはみんな楽観主義者である"
 めっちゃわかる。だいたいスケジュールはトラブルが起こらない前提で引くし、バッファ持たせても「そんなにバッファいらんやろ」って言われて結局短いスケジュールにされるやつ。

"物理的制約が表現できるアイデアを束縛し、実現段階での良きせぬ困難を作り出す"
 使おうと思っていたOSSが実は達成したい目的のために使えなかった。みたいなことはよくあったのでそういう感じかなと思いました。

"人月とは、人と月とか互いに交換できるという意味である。"
"人と月が交換可能になるのは、多くの作業者の間でコミュニケーション(意思疎通)を測らなくても、仕事が分担できる場合である"
”…負担の増加分は要員数に合わせて線形に変化する"
人が増えたとき、最初の情報共有だけしとけばあとは即戦力…というわけにはいかないですもんね。
システムテストが短くスケジュールされがち、わかる(やったことがあります)

この章では、遅れているプロジェクトへの要因追加は、さらにプロジェクトを遅らせるだけだということを、丁寧に説明する章な気がしました。

第3章 外科手術チーム

少数精鋭が好ましいが、それだと大規模システム開発にはあまりに時間がかかりすぎるので、ミルズの案のように、完全に役割を分担してプロジェクトにあたるべき。ということを言っているのかなと思いました。

第4章 貴族政治、民主政治、そしてシステムデザイン

ここを今読んでいるところです。目を通したのですが結局何が言いたいのかがわかっていません。
コンセプトの完全性の章で、ランス大聖堂は建築家が我を通さず一貫してコンセプトを守ったから美しい。というのはわかりましたが、
OS/360とPDP10の例のところがよくわかりませんでした。どちらも触ったことも見たこともないからかもしれません。
後半も何が言いたいのかわからず。どうしたらいいんだ。

こんな感じです。「令和の世で「人月の神話」を読む」みたいな連載ないかな~~~~(他力本願)