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

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

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

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

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

［　問題提起　］

［　結論　］

［　コメント　］

［　読了した日　］

2014/10/29

よく引用される「銀の弾丸などない」は誤解されて解釈されてる気がする　著者は警告したいわけではないんじゃないか

2014/08/13

何ら驚きをもたらさない当たり前の抽象的な訓示と、それを例証する凄まじく時代遅れの具体例（OS/360とか…）が、ダラダラと並べられているだけの本。

人と月は交換できない、という主張だけは、見るべきものがあるが、これはブルックスの法則と呼ばれ本書の初版発行時既に提唱されていたもので、本書のオリジナルというわけではない（但し、別に著者がオリジナルを騙っているわけではない。きちんと「ブルックスの法則」として紹介している）。

この法則を世に広く知らしむる結果となった点だけは、評価に値するかもしれないが、正直、なぜこれが名著として長年推薦図書とされてきたのか、私には理解できない。

新たに追加された19章「『人月の神話』から20年を経て」の冒頭に登場する、飛行機で偶然著者のとなりに座って本書を読んでいた乗客と、私は同じ意見である：

著者「その本はどんなです？勧めますか？」
乗客「フン。私が知ってることばかり書いてあるよ」

☆１つ。

2014/06/09

久しぶりに読むのに骨が折れた本。
こういう本って、難しいことを分かりにくく書いてますね。
だから1回だけ読んでも内容を理解しきれないというか。
とはいえ、難解だから再読したいとは思わないというか。

もう少しシンプルに書いてくれたらいいのに、
といつも思います。

【勉強になったこと】
・管理と技術のリーダーを兼務出来るのは、
　せいぜい3〜6人で構成されたプロジェクトまで。
　それ以上大きくなると見きれない。

・優秀なアーキテクト、マネージャーがいることが、
　プロジェクトの成否の大半を占める。
　それくらいITプロジェクトは人依存のプロジェクト。

・プログラムの汎用化は、汎用化を意識せず開発するときの
　2〜3倍の作業工数を見込むべき。

・スケジュールを見積もるとき、
　工数配分は、以下配分になることが一般的である。
　　設計　　　：1/3
　　開発　　　：1/6
　　単体テスト：1/4
　　総合テスト：1/4
　つまり、コーディングにかかる工数はたかがしれている。

・プロジェクトマネージャーにとって必要なのは、
　テストにおいて歯に衣着せぬ言いっぷりが出来る
　第三者機関である。

・プロジェクトマネージャーにとって重要な仕事は、
　　全員を同じ方向に進ませること
　　コミュニケーションを図ること
　である。アウトプットが無いように見えるが、
　上記を怠った結果、破綻してしまったプロジェクトは多い。

・とめどなく遅れるスケジュールは、
　モチベーション低下の最たる理由。

・マネージャーは、事実を吸い上げる努力を怠ってはいけない。
　そういう意味では、働きやすい雰囲気を作ることも仕事。
　ここでいうマネージャーは、経営者に置き換えても同じ。
　何故なら、プロジェクトは小規模の企業経営に似てるから。

・後フェーズで要員追加しても効果が出ないことが多い。
　これは、教育にかける時間が多くかかってしまうため。