人月の神話 新装版 の商品レビュー

フレデリック・フィリップス・ブルックス(著者),滝沢徹(訳者),牧野祐子(訳者),富澤昇(訳者)

2019/10/27

言わずと知れた名著。「銀の弾などない」はあまりにも有名。
現代にも通ずる内容は多いものの、最初に刊行されたのは1975年という事もあって、いかんせん内容が非常に古い。
今のIT技術者にはピンと来ない記述が非常に多く、読むのは大変だろう。

2019/08/15

あまりに引用されすぎて初読でもどこかで聞いたことのある話が続くように感じてしまう、システム開発の古典中の古典です。だいたいどこかで焼き直しを見たことはあるにせよ、そうは言っても孫引きではなく直接引用したいときはあるので目を通して損はないかと思います。

2018/08/04

ITシステム開発全般における指南書的な本。なんと初版1975年なのですが、いまにも通じることが多いのと、40年前とは思えない先見性のある本なのです。
続きはこちら↓
https://flying-bookjunkie.blogspot.com/2018/08/blog-post_4.html
Amazon↓
https://amzn.to/2LIJQf8

2017/05/07

下記にレビューを書いた

ソフトウェアの複雑性は本質的な性質であって偶有的なものではない: プログラマの思索 http://forza.cocolog-nifty.com/blog/2017/05/post-3793.html

2017/05/06

確実に、私がSEとしてものを考える土台の一部になっている本です。

◆時代の風雪に耐えて生き残る名著

ＩＴの世界における1年の進歩は、一般社会の進歩の10年分／30年分／100年分に匹敵するとか諸説ありますが、
そのＩＴの世界で1975年、いまから40年前に書かれたということは、とりあえず　「大昔」　の話なのだと。

そんな大昔に書かれた本が、今まで残っているというのはすごいことだなーと思います。
新しい本なら、一時的な話題で盛りあがることがあるけど、本当に良いものじゃないと、時代を超えて残ってはいけない。

少なくとも、システム開発に携わる諸々の仕事（プログラマ、SE、システムアーキテクト、プロマネなど）の分割や、役割分担についての知見は現役です。

源氏物語を読むときに、「墨でラブレター書くとか古すぎだろー！」とか「烏帽子？！だっさ！！！」とかいう文句を誰も言わないのと同じで、
フローチャートやパフォーマンスの話になったら、「昔はそういう文化もあったのねー」と微笑んで読み飛ばしていくのがコツです。

◆そんな現役の知見・役割分担について、印象に残ったポイント

・人を増やすと、一人あたりの生産性が下がるだけでなく、チーム全体としての生産能力が下がるケースもあるということ。
　（1＋1が2にならず、1.8くらいにとどまるだけじゃなく、1＋1が0.8になってしまうこともあるということ。）

・７章の終わりの、ＰＭとＳＡの役割分担に関する考察。
　ＰＭとＳＡはどっちが上司になっても、同一人物でもよくて、でもどっちの役割もチームの中で必要。
　⇒ＰＭとかＳＡという肩書が与えられたら、自動的に役割分担が決まるんじゃなくて、
　　　当人同士の適正や能力をみて、どういう進め方でやっていくのがいいか、自分たちで（あるいはもっと上の人を交えて）ちゃんと話し合う必要があるんだと思った。

2016/01/22

スケジュールが遅れる原因は1日ごとのじわじわした遅延によるもの。
マイルストーンではなく、ミルストーン（ひき臼）。じわじわした遅延を見て見ぬ振りして、じわじわとやる気をすり潰す
悪い知らせを伝えるのが好きな人はいない ソフォクレス
銀の弾丸などない
ソフトウエアは最後に登場したという理由で他に従わなくてはならない。あるいは、従わせやすいとみなされている。
大当たりしたソフトウエアは必ず変更される。役に立つと分かると新しい使い方を試そうとするので、拡張機能を要望される。また、対象機械機器よりと寿命が長い。新しいOSが出ても、うまく動くと要求される。
人と月が交換可能になるのは、多くの作業者間でコミュニケーションを図らなくても仕事が分担できる場合だけ。女性が大勢いても、子供が産まれるまでにかかる時間は変わらない。コミュニケーションを伴う作業の場合は、コミュニケーションコストがかかるため、かえって酷い状況になる。
ブルックスの法則 遅れているソフトウエアプロジェクトへの要因追加は、さらにプロジェクトを遅らせるだけだ
150人の無能集団よりも10人のエリート集団の方が早く、質も良い。ただ、150人を暇にさせるという判断は難しいものだ。
コミュニケーションを減らすためには、機能の細分化と専門化。

2016/01/11

レビュー書いた http://kimikimi714.hatenablog.com/entry/2015/12/09/210000

2015/03/09

　古典。

　組織構成における指摘は自分の経験も含め多く当てはまる部分があり、また、解決されていないと感じている部分も同様である。プロジェクトの途中での人員追加は却ってプロジェクトの遅延を招くという点、少数精鋭では大規模な開発には耐えられないという点、ドキュメント整理や秘書の専業者が必要というのは大いに同意できる。残念ながらこれらの問題を理解、体感しているのは現場の技術者だけであり、本書が広く読まれているはずなのに何も解決していないのが不思議でならない。

　一方でソフトウェア開発に関しては著者がすでにその一線から退き、研究者となっているため、【新装版】で追加された部分も含め”現場を知らない”状況に陥っているように感じた。そして、ある種のMacintosh信仰が目を曇らせていると感じる部分もある。統一されたデザインやコンセプトを重視するあまり、ユーザビリティを軽視しているのはまさにそれで、コンピュータが一般化した今、使いにくいというのはデザインやコンセプトの失敗と言える。また、個人的に全く同意できないのはフローチャートはデザインに使えないという指摘である。確かに、規格どおりの記述で詳細まで記述するやり方では煩雑すぎる。また、現在のような大規模なシステムの詳細を記述するのに向かないという指摘も同意できる。しかしデザインに使うことは可能である。処理(□)と分岐(◇)と処理の向き(→)によってシステムがどういった条件でどのような処理をするべきかというグランドデザインを描くことが可能であるし、モジュール単体のデザインにおいても、簡単なフローチャートを描いてみれば煩雑な部分が見え、デザインの方向性が見えてくる。物は使いようである。にも関わらずただひとこと”使えない”としてしまうのは些か乱暴である。

　ソフトウェア開発の本として読むよりも組織構成の本として読んだほうが良いし、参考にすべきは組織論の部分だろう。

2014/12/20

私が生まれるより前の書籍にも関わらず、いまもなおシステム開発の現場で問題になっている
課題と同じ内容が書いてあったり、アジャイル・XPなどのノウハウと通じる概念が記載されている。

以下、特に印象に残った内容を列挙します

・少数精鋭が理想だが、それができない大規模案件のジレンマ
・マニュアルは形式的定義で厳密さを、散文形式でなぜか？を説明する
・最初から実現不可能なプロジェクトをバベルの塔に例える
・有能な管理的能力と強力な技術的能力を兼備している人間は稀
・技術的騎兵隊としてトップクラスのプログラマの確保が重要。管理職のキャリアパスと技術職のキャリアパスを用意。両者は同一ランクなら同格。技術職から同格の管理職への移動で昇給されてはならない。
・ツール担当。マネージャーはツール製作の要員を出し惜しみしてはならない。
・分業と部分最適化の弊害。実装担当に対する利用者思想の啓蒙はマネージャーの責務
・ソフトウェアは本質的に難しいので万能策はない。偶有的(副次的)な難しさがほとんどなら銀の弾もありえたのであろうが。
・ソフトウェアの複雑性。規模の拡大は同じ要素ではなく、異なる要素が増えるためどんどん複雑になる。
・構文上の誤りは、システムのコンセプトの誤りに比べてとるにたらない
・人月の神話20年を経ての著者の意見。こんにちでも人月の神話が支持される理由。ソフトウェア開発が、正常に、適切に進化しなかった。 労働集約的なまま。

2014/11/22

［　内容　］
本書は、プログラム開発の管理がなぜたいへんなのか、という疑問に答えようとするものである。
プロのプログラマや管理職、特にプログラマの管理職を対象にしている。
増訂版では、最近の考えを補足した。
アメリカ計算機学会のＡＣＭ／Ａ．Ｍ．Ｔｕｒｉｎｇ賞受賞。

［　目次　］
タールの沼
人月の神話
外科手術チーム
貴族政治、民主政治、そしてシステムデザイン
セカンドシステム症候群
命令を伝える
バベルの塔は、なぜ失敗に終わったか
予告宣言する
五ポンド袋に詰め込んだ十ポンド
文書の前提
一つは捨石にするつもりで
切れ味のいい道具
全体と部分
破局を生み出すこと
もう一つの顔
銀の弾などない―本質と偶有
「銀の弾などない」再発射
「人月の神話」の命題―真か偽か
「人月の神話」から二十年を経て
五十年間の不思議、興奮、それに喜び

［　問題提起　］

［　結論　］

［　コメント　］

［　読了した日　］