こんにちは、ヒーニョンです。
「プログラマ年収1000万円超えに向けて日々やるべきこと」で紹介した「人月の神話」の書評です。
| ジャンル | 精神論 |
|---|---|
| 評価 | |
| 読みやすさ | |
| 対象者 | 中級プログラマ、マネージャー |
| ページ数 | 321ページ |
必要性
プログラマとしてやっていくなら避けては通れない書籍です。開発の中でも「銀の弾丸などない」という会話がでてきますが、それはこの書籍からきています。西洋の信仰において、銀で作られた弾丸は、狼男や悪魔などを撃退できるとされいますが、ソフトウェア開発においては特効薬は無いやゆされています。書籍の表紙は以前は狼男?でした。
僕が読んだのは、さらに前で表紙が白でしたが、狼男でした。
ちょっとネタバレ
作る喜び
この本を読まれる方は、作る苦しみは十分体験されていると思います。一度初心に戻って作る喜びを思い出して見ましょう。
- 物を作り上げる純粋な喜び
- 他の人々に役立つものを作る楽しさ
- 複雑なパズルと説くおもしろさ
- 常に新しいことを学ぶという喜び
- 常に扱いやすい媒体で作業する喜び
僕は「新しいことを学ぶ喜び」が一番強いです。できなかったことが、できるようになる。これほど満足感を得られることはありません。
誤った考え方
見積りとスケジューリングに使われる仕事の単位は一般的に「人月」が使われると思います。コストは人数と月数の積に比例しますが、進捗はそうはいかないという真実が隠蔽されプロジェクトに混乱をきたすのです。
ブルックスの法則で「9人の妊婦を集めても、1ヶ月で赤ちゃんを出産することはできない」と説明されていますが、遅れているプロジェクトへの要員追加はさらに遅らせるだけなのです。それは、新たに投入された開発者が生産性の向上に貢献するまでには時間がかかるし、人員の投下はチーム内のコミュニケーションコストを増大させるのです。
だから、仕事の大きさを測る単位として「人月」は、疑うべき危険な神話です。
最新版の表紙に描かれているバベルの塔ですが、なぜ建設失敗に終わったのでしょうか?
コミュニケーションが成功を左右する例として書かれています。
できるプログラマとできないプログラマ
「できないプログラマ」と比べ2倍の給与をもらっている「できるプログラマ」は10倍生産性が高いといわれています。少数精鋭が効率の良いことに間違えはないのですが、非常に大きなシステムをタイムリーに開発するには、時間が掛かりすぎるというジレンマがあります。
ソフトウェア開発でどのような文書が必要か?
僕がかけだしのプログラマだったころ間違っていたのが、プログラムとは別の資料をキッチリ作ろうとしたことでした。ソースコードにはコメントを書き、フローチャートを用意したりすることが大切だと思っていました。
この書籍では僕の考えを全否定です。「フローチャートの呪い」ということで、フローチャートの実用性を否定しています。何より重要なのが人が読んで理解できるソースコード、すなわち「自己文書プログラム」をすることです。プログラマといて10年以上経ちますが、読みやすいソースコードは一番大切な文書だと実感しています。
まとめ
タイトルは「人月の神話」ですが、「銀の弾丸などない」でも良かったと思うほど重要なキーワードです。
技術や管理手法において生産性や信頼性と容易性での飛躍的な改善を一つでも約束できるような開発は一つとしてないのです。
ソフトウェアの複雑性に取り組むことが我々の仕事であり、魔法のような解決策は存在しない以上、革新的な改善を待ったり期待したりするのではなく、段階的な改善を進めていくことが重要なのです。
ではまたヾ(^^へ)
コメント