人月の神話を読んだ

銀の弾丸はないという言葉がいろんな記事で引用されてて本の存在は知っていたけどいい機会だと思って読んでみた。

  • 内容が古い、初版は1975年、いまは2021年、46年前の本である
  • 20周年記念版は1995年
  • IBMOS/360やAda、ALGOLが出てくる
  • C言語は1972年にリリースされているがあんまり流通していなさそう
  • 翻訳が読みづらくて苦痛
  • 第2章 人月の神話
    • プロジェクト失敗の大半は時間がたりないこと
      • 実際には作ってみたもののニーズがなかったりマーケに失敗したり新規性や進歩性がなかったりでマネタイズできず終了するのもよくある失敗例
    • 見積もり手法の人月は人と月が置き換え可能であることを暗示している
    • 実際には新しい人員が配属された際には作業が中断され、教育が必要になり追加の相互連絡が必要になる
      • コミュニケーションコストの増大
      • コードを書かないマネージメント層も増えるのでもっと複雑になる
      • 分業可能でコミュニケーションも必要ない仕事なら無限にスケールできるんだけど
      • 作業中断不要、教育不要、相互連絡が最低限でOKなくらい優秀で気前のいいひとが配属されるんだったらいいけど
    • 人と月は置き換え可能ではない
      • 期待しているスケジュールの枠内には収まらない
    • スケジュールを立て直すか仕事の規模を縮小するしかない
  • 他の章はエッセイのような感じでササッと目を通しておしまい
    • 設計と実装をわける、インターフェイスを定義する
      • ジェフ・ベゾスのすべてをAPIにせよみたいな話
      • 部署をわけて責任分界点を明確にしてコミュニケーションコストを減らす
      • 認証周りは認証基盤チームに任せる、APIは公開するから好きに使ってOK、要望があればIssueにどうぞ
    • バベルの塔が目的、要員、材料、時間、技術すべてあるのに失敗したのはコミュニケーションと組織がなかったから
    • 銀の弾丸になりそうなものは形になっているものもある(高水準言語、OOP、AI、自動プログラミング、プログラム検証、RAD、インクリメンタル開発など)
  • 自社開発で好きにやっているなら別にいいんだろうけど会社として受託案件を請け負っているのなら人月の話は避けられない
  • 銀の弾丸はないけどGitHub、CircleCI、Slackのようなツールを活用してコミュニケーションコストを圧縮したいところ
  • 採用するなら年間1万ドルエンジニアより年間2万ドルエンジニアのほうが生産性10倍なのでめちゃくちゃお得
  • 年間2万ドルエンジニアに気前よく末永く働いてもらいたい、必要な社内制度改革は全部やるべき
  • 2021年だと年間20万ドルエンジニア、国内だと年収1000万円のエンジニア
ソフトウェア開発の定番書『人月の神話』。「ブルックスの法則」で知られる
ブルックス教授によるこの名著が、同教授の35年ぶりの新刊「The Design Of Design」
(邦題「デザインのためのデザイン」)を記念し、従来の縦組みから横組みに変わり、
表紙カバーを新たに新登場。

IBMの大型コンピュータSystem/630、およびオペレーティングシステムOS/360の
開発チームを率いた著者が、プロジェクトで発生した問題点を詳細に分析し、
ソフトウェア開発にまつわる困難と展望について持論を展開したエッセイ集。
原著初版(1975年)の刊行から35年がたつ現在でも、大規模開発プロジェクトにおける
ソフトウェア工学の古典として読み継がれ、多くの読者を獲得している。

とくに、「遅れているソフトウェアプロジェクトへの要員追加は、
さらにプロジェクトを遅らせるだけだ」というブルックスの法則は名高い。
開発において「人員×月日」というスケジュール見積もりが適用されている問題を指摘し、
ソフトウェア産業において広くいきわたっている「人月の神話」を明らかにした。

また、刊行20周年記念して発行された増訂版では、発表当時大きな議論を巻き起こした
「銀の弾はない」をはじめとして、初版刊行以降に発表された著者の代表的な論文4編を収録。
各方面から寄せられたさまざまな議論に対して、著者があらためて自身の見解を述べている。