読者です 読者をやめる 読者になる 読者になる

nekoTheShadow’s diary

技術ブログとして始めたはずが、読書&愚痴ブログになりました(´・ω・`)

ブルックス『人月の神話【新装版】』(2014年、丸善出版)

読書

人月の神話【新装版】

人月の神話【新装版】

ソフトウェア開発におけるプロジェクトマネジメントの古典であり、読んでいないシステムエンジニアはもぐりだとか(適当)。新卒でSIerに身を投じた人間として、このたび読んでおくことにしました。

もともとが古い本(1975年)のため、内容がまったく時代遅れかと思いきや、そんなことはなく、現代の日本でもありうる話ばかりでした。確かにこまごまとした部分に古さを感じるようなこともあった(とくに技術面)のですが、プロジェクトマネジメントや組織づくりに関しては現代日本のSIerが抱えていそうな問題が指摘されています。となると1975年から日本のソフトウェア開発は進歩していないということになりますね……。

内容について、気になった点を箇条書きにしておきます。

  • 本書では繰り返し「システムの中心的なコンセプトの重要性」を解いており、それに合わせたチーム作りや組織作りを推奨しています。わたしもこの意見に賛成。完成度の高いモジュールを組み合わせれば、おのずと完成度の高いシステムができるような気もしますが、これは間違い。組み合わせ方にもコツ=「中心的なコンセプト」があり、それなくしてはめちゃくちゃなシステムが出来上がるだけです。
  • 「人月は交換できない」というアイディアは知的作業全般に言えることでしょう。プログラミングならなおさら、できるプログラマとできないプログラマの生産性が段違いであることは、プログラマなら知っているはず。また「遅延しているプロジェクトに人員を追加しても、コミュニケーションコストと教育コストがのしかかるせいで、プロジェクトがさらに遅延だけ」という「ブルックスの法則」も人月の交換不可能性から導き出されています。
    • とはいえプロジェクトの規模を見積もる尺度として人月ぐらいしかないというのも現実なので……。どうすりゃいいのか(´・ω・`)
  • 本書はチーム全員がチームの資産に簡易にアクセスできる状況を理想としており、その実現のためドキュメントやコミュニケーションの方法論を提示しています。結論はごく当たり前(というか本書が当たり前にした)ものなので割愛しますが、気になったところが1点。本書ではより安価なコミュニケーション手段として電子メールを推奨してますが、電子メールってそんなにコミュニケーションコストが低いですかね?
    • 1975年の本なので、当時としては電子メールは最良の手段だったのかもしれませんが、現代に生きる私としては電子メールですらつらいときがあります(マナーとかcc/bccとか)。まあだからこそビジネス向けチャットが流行っているのかもしれませんね。
    • わたしも仕事でチャットをつかいたいでござる(´・ω・`)
  • 銀の弾丸などない」ときどき開発手法について書かれたブログが炎上しているのを見たりしますが、やはりソフトウェア開発に王道はないと思います。ただ「王道はない」ことは「道はない」ということとイコールではありません。より洗練されたメソッドを試行錯誤しながら使っていくのが現実的な最適解でしょう。