人月の神話

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

• 販売会社／発売会社: ピアソン桐原
• 発売年月日: 2010/12/01
• JAN: 9784864010054

商品レビュー

2020/08/30

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

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

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

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

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

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

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

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

2018/10/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章の銀の弾丸の話。

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