人月の神話

bonlifeです。SEとして、定番の本は読んでおかなきゃ、と思って「人月の神話」読んでみました。

人月の神話―狼人間を撃つ銀の弾はない (Professional computing series (別巻3))

汎用コンピュータをイメージしてたりするので読みづらく、理会し辛い部分も多いのですが、本質は今も変わっていないですね。ただ、これから読む人は第18章の『「人月の神話」の命題 - 真か偽か』を最初に読んだ方が良いんじゃないかな。その後、第19章を読んだ後、最初から通して読むと分かりやすいかも。
bonlifeが参考になった部分を超手短にまとめておきます。

• プログラミングシステム製品は個人使用目的の別個に書かれたコンポーネントプログラムの約9倍の労力を必要とする
  • 製品化に3倍の労力
  • 各コンポーネントプログラムをデザイン・統合化・テストして1つのまとまってシステムにすることに3倍の労力
• 人月は、間違った危険な神話 (人月とは「人」と「月」が相互に交換可能だということを意味)
• 遅れているソフトウェアプロジェクトへの要因追加は、さらに遅らせるだけである (「ブルックスの法則」)
  • 再配分作業とそのための中断、新しい要員の訓練、新たに必要となる相互コミュニケーション
• プログラマによって生産性は10倍違う
• 少数精鋭チームが最高 (非常に大きなシステムに取り組むと、開発が遅れ過ぎる)
• コミュニケーションと組織が重要
  • チームは可能な限り多くの方法で互いにコミュニケーションを図るべき
  • マネージャーとアーキテクトという2つの役割
• 文書
  • 目的、マニュアル、スケジュール、予算、組織図、フロアスペース配分、機械自体の見積り、販売予測、価格
  • 小規模プロジェクトであっても、マネージャは文書のセットを形式化すべき
  • 重要な文書をそれぞれ維持管理することで、状況の監視ができるようになり、万一の場合の警告メカニズムも得られる
• プロジェクトは1度に1日ずつ遅れる
• ハッスルプレイは必要不可欠
• 大規模プロジェクトでは、プラン・アンド・コントロールチームは貴重 (マイルストーン報告書を維持管理)
• ソフトウェアシステムは、人間の作り出したもののうちで、おそらくもっとも分かりにくく複雑なもの
• ウォーターフォールモデルは間違い (漸増的構築モデルの方が勝っている)

この本が古くならないのは、ソフトウェア開発プロジェクトのコミュニケーション、組織のあり方を中心に扱っているからですね。適切な文書化が行われ、関係者がちゃんと情報共有できるようになっている組織で、円滑なコミュニケーションが図れていれば大惨事は防げそう。人月の部分ばかりが注目されてますが、8割ぐらいの内容がすごく勉強になります。(2割は時代の流れと共に変わってしまった部分なので仕方がないですね。)
最後の「ウォーターフォールモデルは間違い」って部分はすごく納得できます。でも、社内の開発標準はウォータフォールモデルが前提だったりして…orz 実際にはプロトタイプ的なものをリリースして、2次開発、3次開発…といった感じで開発を進めるケースも多いので、マクロにはインクリメンタルなプロトタイプ開発になってたりするマジック。
インフラ部隊なので、まともなアプリケーションシステムの開発に関わったことがないのですが、いつか開発プロジェクトに参加することになった時には一度読み直してみようと思います。