人月の神話

ソフトウェア開発では開発工数を「人月」で見積もることが多いと思います。

この人月に対して、フレデリック・P・ブルックス,Jrは「人月の神話」という書籍を1975年に出版しました。

ソフトウェア開発に関してさまざまな側面から提言を行っています。

そして、これらの提言は今から40年以上前に行われたソフトウェア開発での経験から生まれたものですが、今でも当てはまる項目が多いです。

なぜ、内容が時代遅れにならないのか？

それは、人とチームについて書かれているためそう簡単に時代遅れにはならないのです。

ソフトウェア開発にまつわる問題は執拗でやっかいなのであり、その本質を理解することは困難だがその困難な本質を理解するように努めなければいけません。

が、プログラミングは次の5種類の喜びを与えてくれます。

①モノを作り上げる純粋な喜び

②他の人々の役立つものを作る楽しさ

③複雑なパズルのような組み立て部品を完成させ、それが巧妙に転回するのを眺めるおもしろさ

④常に新しいことを学ぶという喜び

⑤非常に扱いやすいメディア（媒体）で作業する喜び

なぜ、プログラミングが楽しいか？

それは私たちの心の不覚に宿っている創作意欲を満たしてくれるからであり、また、私たちすべての人間に共通な感覚を楽しませてくれるからです。

しかし、プログラミングには作る苦しみもあります。

プログラミング開発は、多くの人々が目標達成のため、もがき苦闘するタールの沼であるとともに、また独自のの喜びと苦悩を伴った創作活動でもあります。

多くの人々にとって喜びが苦悩よりはるかに勝っているのであり、本書はそういう人たちのためにタールの沼を渡るための架け橋を提供しようとするものである。

「仕事の大きさ」を測る単位として人月を用いることは間違いです。

コストは実際に人数と月数の積に比例しますが、進捗はそうではありません。

したがって、仕事の大きさ測る単位としての人月は疑うべき危険な神話です。

人月は人と月とが互いに交換できるという意味だからです。

人と月が交換可能になるのは多くの作業者の間でコミュニケーション（意思疎通）を図らなくても仕事の分担ができる場合だけです。

ソフトウェアを開発するのは機械でなく人であるため、当然ながら開発者間のコミュニケーションが必要であり、そのコミュニケーションのコストを無視することはできません。

遅れているソフトウェアプロジェクトへの要因追加はさらに遅らせるだけです。

システムデザインにおいて、コンセプトの完全性こそがもっとも重要であり、そのためにはアーキテクトが必要になります。

2度目に作ったシステムは1度目と比較してどうしても多くの機能を入れようとして失敗してしまいます。

これを避けるためにもアーキテクトは役に立ちます。

アーキテクトの決定内容をいかに他の実装者に伝えるかについてのコミュニケーション方法について述べられています。