人月の神話 の商品レビュー

フレデリック・P.ブルックスJr.【著】,滝沢徹,牧野祐子,富澤昇【訳】

2020/08/30

ソフトウェア開発という歴史の浅い製品開発とはどういう性質のものか、どこに問題が潜んでいるか、どう対応するか、なぜ困難かを1975年にまとめている。

そして驚くべきことが、2020年現在においても置き換え可能なものばかりで、悪く言うと解決していない、ということ。

プロジェクトにおいてスケジュール以内で終わったものはほとんどない、であったり、要員追加が解決方法ではない、など。

そしてテクニカルな問題というよりも、社会学的な問題、というところが存在し、コミュニケーション工数の増加、引いてはコンセプトが散在し、よくわからないものができてしまう。

ますますこの傾向は加速するとみられる、なぜなら現状までのシステム化は現在の業務をいかにデジタルに置き換えるか、というところが主流だったが、今後はデジタルを使って新しいビジネスを行う、という断面に来ているため、ますますコンセプトの統一や一貫性を持たせ続けてプロジェクトを完走することは困難になる。

そしてアジャイルへ、ということが現在主流だが、驚いたのは当時からデモプロトやとにかく動くものを作る、ということがすでに語られていること。想定するに、当時は逆にそういうことを行う必要性がなかったのだと思われる。

テクニカル面ではクラウドの発展でインフラを意識しないこともできるようになってきているが、本書で書かれているのはそういったポイントではないため、解決策とはなりきれない。つまり銀の弾は未だに存在していないということだと言える。他社との協業などますます複雑性は増していると思われる。

また、アーキテクトの統一のための組織論、役割分担も語られており、今でも通用するないようばかりであり、
いかに難しいものを扱っているか、ということを痛感するばかり

2021/08/08

今から40年前に書かれたものとは思えない。今読んでも十分に価値のある著書である。
以下の一説は端的にシステム開発の抱える問題を言い表している。

「第二の誤った考え方は、見積りとスケジューリングに使われる仕事の単位、すなわち『人月』そのものである。コストは実際に人数と月数の積に比例する。が、進捗はそうではない。したがって、仕事の大きさを測る単位としての人月は、疑うべき危険な神話なのだ。人月とは、人と月とが互いに交換できるという意味だからである。
　人と月が交換可能になるのは、多くの作業者の間でコミュニケーション（意思疎通）を図らなくても、仕事が分担できる場合だけである。これは小麦を刈り取るとか、綿を摘むとかいうことには当てはまるが、どうがんばってもシステムプログラム開発には当てはまらない。」

全くその通り。なぜ40年前からこんな当たり前のことが叫ばれているというのに、いまだに人月を使って不透明な見積もりが行われ、実際に本書で書かれているような失敗があちらこちらで起こっているのはどういうことなのだろうか。

2.6　コスト計算をもとにして組み立てられた見積もり技術は、労力と進捗とを混同している。人月は、間違った神話である。というのも、人月とは「人」と「月」が相互に交換可能だということを意味しているからだ。
2.7　複数の人々の間で仕事を配分することは、コミュニケーションという余計な労力―教育および相互コミュニケーション―をもたらす。

3.3 少数精鋭チームが最高である。―人数はできるだけ少ない方がよい。
3.5　少数精鋭チームで非常に大きなシステムに取り組むと、開発が遅れすぎる。
3.6 ほとんどの大規模システムの経験から、大規模化のためにやみくもに人を投入する方法だと、コストばかりかかって進捗が遅く、非効率であるということ、またコンセプトが統合されていないシステムが出来上がってしまうということが分かる。

4.1 「コンセプトの完全性こそ、システムデザインにおいて最も重要な考慮点だ。」

6.1 デザインチームに要員がたくさんいる場合でも、細かな決断にいたるまで一貫性を持たせるために、結果的に１人か２人で書くことにする。

7.1　バベルの塔プロジェクトは、コミュニケーションとそこから生まれる組織がなかったために失敗した。

9.16 データやテーブルの表現をやり直すことで、戦略的突破が実現されることはさらに多い。表現はプログラミングの本質なのだ。
※私にフローチャートだけを見せて、テーブルは見せないとしたら、私はずっと煙に巻かれたままになるだろう。逆にテーブルを見せてもらえるなら、フローチャートはたいてい必要なくなる。

11.3 たいていのプロジェクトでは、最初に完成したシステムはほとんど使い物にならない。遅過ぎたり、大き過ぎたり、使いにくかったりする。ひどいものになるとこの３つすべてが当てはまっていることもある。
11.6　だから、1つは捨て石にするつもりでいることである。どうしたってそうせざるを得ないのだから。

14.1 「プロジェクトはどうして1年も遅れるようになるのか？…一度に1日ずつ」。
14.2 1日ごとの遅延は、災難による遅れに比べ、気づくことも予防することも、さらにはその分を取り戻すこともより困難になる。

・「1つは捨石にするつもりで構築せよ」という考え方における最大の誤りは、ソフトウェア構築に関して古典的な順次モデルまたはウォーターフォールモデルを暗黙のうちに想定していることだ。
・ウォーターフォールモデルの基本的な誤解は、プロジェクトでは各工程が１回だけで、アーキテクチャが見事で使いやすく、インプリメンテ―ションデザインが適切で、テストの進捗に合わせて実現段階の修正が可能だと仮定していることである。
・ウォーターフォールモデルは、システムテストとそれが含意するユーザーテストを構築過程の最後に持ってきている。そこで利用者にとって考えられないような扱いにくさや、とても容認できそうにない性能、あるいは利用者のエラーや悪気を引き起こしそうな危険性などを発見したときには、もうすっかり完了してしまっている可能性がある。

・私が提案することは次のような内容である。
　●購入できるものをあえて構築しないようにするためのマスマーケット（市販製品）の利用。
　●ソフトウェア要件の確立に際し、開発反復計画の一部として、ラピッド（迅速な）プロトタイピングを使用すること。
　●実行と使用とテストが行われるにつれて、より多くの機能をシステムに追加しながら、ソフトウェアを有機的（系統的）に成長させること。
　●若い世代の素晴らしいコンセプトデザイナーを発掘し、育てること。

2017/01/19

一部現代にも通用するが全体として小難しい

ITの分野で時々名前をきく本。興味があったので借りて読んでみた。
1980年代付近に書かれた本で，ソフトウェア開発に関する問題について書かれている。よくきくのは2章の人月に関する話と16章の銀の弾丸の話。

ソフトウェア開発に置いては，人と月は交換可能ではない。新しく人を投入しても教育やコミュニケーションのコストあるので，むしろ効率が悪くなるという話。
昔に書かれたので，内容は全体的に古臭い。そして，学者が書いたのか，翻訳が悪いのか長くて堅苦しくてわかりにくくて読みにくい。たしかにソフトウェア開発に関する問題としては今でも通用するところがあるかもしれない。
しかし，単純に読みにくいし過大評価されすぎだと思う。

2024/05/18

"コストは実際に人数と月数の積に比例する。が、進捗はそうではない。…人と月が交換可能になるのは、多くの作業者の間でコミュニケーション（意思疎通）を図らなくても、仕事が分担できる場合だけである。"

2015/10/19

古い本なので例えが古すぎる + 実際に大規模なガチ開発をしたことがないので、理解しづらいところも割とあった。
前半は僕にとってわかりやすく、特に
・人月がなぜ人と月の等価交換ではないか
・デザインやらコンセプトは一人ないしは少数で固めるべき
・セカンドシステム症候群
などはなるほどな、という感じだった。

2014/05/24

僕らITの人は「人月」と「単価」で見積もります。5人で3ヶ月の仕事は15人月。じゃあ、15人投入すれば1ヶ月でその仕事は終わるのか？って話。無理です。「人」と「月」は交換可能ではないから。

全体の方針はプロジェクトの最初に優秀な人間が少人数で決める。このことで全体の整合性や一貫性が根付くのである。そーだー。

全体をサマリーしている18章だけでも読む価値あります。

2.6 コスト計算をもとにして組み立てられた見積もり技術は、労力と進捗とを混同している。人月は間違った危険な神話である。というのも人月とは「人」と「月」が相互に交換可能だということを意味しているからだ。

3.7　外科手術チーム編成のチーフプログラマは、コミュニケーション負荷を徹底的に削減することで、少人数の頭脳による製品の完全性、および多くのサポートスタッフによる総生産性の工場を得る方法を提起できる。

15.14　プログラムを修正する人が使用する文書では、単にそのプログラムがどうなっているのかを示すのではなく、なぜそうなっているのかを伝えることが重要だ。目的こそ理解の鍵になる。高水準言語の構文であっても目的を伝えはしないのだから。

2013/12/03

プロなら古典ぐらい読もう！
７章　The boss と The technical director は別の talent が必要、とある。これを一緒にしていいのは小規模プロジェクトだけ(｀´）

2013/10/21

学生のうちに読んだけど、正直あまりピンと来なかった。プロジェクト管理の必要に迫られてからよめばもっと身になったかも。

2013/10/17

40年近く前に書かれているため、技術的には古く参考となる部分は多くない。しかし、考え等は今でも十分に通用するどころか非常に示唆にとんでおり参考となる部分が多い。

2013/10/10

ソフトウェアプロジェクトがなぜ難しいのか、それは本質的に複雑で難しいものを解決する手段だから。
銀の弾はないものの、理解しておくべきことは幾つもある。例えば、
•人と月は相互に変換不可能
•アーキテクチャはごく少人数で決めるべき
•遅延したプロジェクトに要員を追加するとさらに遅れる

こういうことを現場では感覚的に理解してる人は少なからずいそうだか、現場を知らない人は理解してなさそう。そういう人にこそ読んでいて欲しいと思う