人月の神話

ソフトウェア開発、プロジェクト管理の古典でありバイブル。
本書の意義は、人月は指標として有用でない「神話」であること、ソフトウェア開発を劇的に進歩させる「銀の弾丸」のような方法がないことの２点を１９７０年代に予言したことにある。
また、ブルックスの法則がある。

遅れているソフトウェアプロジェクトへの要員追加はさらに遅らせる

人月の神話

仕事の大きさを測る単位としての人月は、疑うべき神話なのだ(p14)

人と月は等価交換できない。スケジュールが遅れたからといって人を増員してもスケジュールは短くならないどころか教育などの負担増でより遅れる。

私は以下の目安を使用してソフトウェア開発のスケジュールに対応してきた(p17)
1/3　計画
1/6　コーディング
1/4　単体テストおよび初期システムテスト
1/4　すべてのコンポーネントを統合して行うシステムテスト

バベルの塔（大規模プロジェクト）

大規模プログラム開発プロジェクトにおけるコミュニケーション(p69)
プロジェクト手引書
正式なプロジェクトの手引書は最初から使用しなくてはならない。
プロジェクトで作成される文書はプロジェクト手引書の構成に従わなければならない。

大規模になる場合は文書を構造化して木構造にすること。必要に応じてサブツリーごとの配布リストができる。

製作主任が上司で、技術主任がその右腕となる場合(p75)
技術主任が時間を圧迫されることなく、技術的判断を下せる権限を確立してやることだ。

労力はプログラムサイズの累乗になることを示している。(p82)
労力(＝人月)＝(定数)×(命令数)＾1.5　

図では、500K行のプログラムが(500K)^1.5/(60*60*24)≒4000(人月)で計算されているみたい。

パイロットプラントと大規模化(p106)

たいていのプロジェクトでは、最初に完成したシステムはほとんど使い物にならない。遅すぎたり、大き過ぎたり、使いにくかったりする。

試作して破棄する工程が必要と。

プログラムメンテナンスの基本的問題は、欠陥の修正が実質的には次の欠陥を生み出す可能性（２０～５０％）を秘めていることだ。(p111)

モジュールの総数はリリース番号とともに線形に増加するのに対し、影響を受けるモジュールの数はリリース番号に対し指数的に増加する(p112)

修正を重ねるとシステムの整合性が悪くなって陳腐化する。

一回に追加するコンポーネントは一つだけにする(p138)

当たり前なことだがついつい背いてしまうという例。

パート図(p144)

クリティカルパスが明確なら、担当はそうならないようがんばるというお話。

フローチャートは、プログラム文書作成のうちでもまったく過大評価されてきたものの一つだ。(p155)
フローチャートはプログラムの判別構造を示すもので、構造の一面を示しているに過ぎない。

さらにプログラムと文書の二重管理は難しいので、ソースプログラムの中に文書を組み込むことを提案し、自己文書プログラムと呼んでいる。今ではdoxygenなどのツール一般的に使われていることと思うが、当時から言及されていたんですね。

銀の弾丸などない(p165)
ソフトウェア開発作業における本質的な部分として以下を提案している。

購入できるものをあえて構築しないようにするための大市場の利用
ソフトウェア要件の確立に際し、開発循環計画の一部として、迅速なプロトタイピングを使用すること。
実行と使用とテストが行われるにつれて、より多くの機能をシステムに追加しながら、ソフトウェアを有機的(系統的)に成長させること
若い世代の素晴らしいコンセプトデザイナーを発掘し、育てること。

そして、当時から10年間で、技術、管理手法の両面で、生産性、信頼性、容易性を飛躍的に改善させる銀の弾は存在しないことを予言している。（そしてそれは予言どおりの結果になった。）銀の弾とは、民話の狼人間を魔法のように鎮めることができることから引用している。

ソフトウェア構築において困難な部分は、この概念構造体の使用作成とデザインおよびテストにあって、表現することやその表現に忠実かをテストすることではないと考えている。

数学や物理学は、複雑な現象を単純化したモデルを構成し、そのモデルからある性質を引き出すが、ソフトウェアは複雑性が本質的な性質であることため、同様の方法を使えない（p169)

ソフトウェア製品開発に関する古典的問題の多くは、その本質的な複雑性と、ソフトウェアの大きさに従ってその複雑性が非線形に増大することに由来する

ソフトウェアの場合、土地には地図、シリコンチップには回路図、コンピュータには結線図という具合に、幾何学的表現が整っているわけではない。

ソフトウェアの構造は複数の一般的な有効グラフで構成されていて、お互いに重なり合っているため、その構造を本質的に視覚化できていない。
そのため、グラフの結びつきを取り除き、ソフトウェアの構造を制限したり単純化したりすることで、複数の階層構造図になるように努力している。
強力な概念上のツールが必要。

銀の弾を期待して(p174)
銀の弾となる可能性があるものとして次をあげて評価している。
*Adaとその他の高水準言語の進歩
*オブジェクト指向プログラミング
*人工知能
*エキスパートシステム
*「自動」プログラミング
*ビジュアルプログラミング
*プログラム検証
*環境とツール
*ワークステーション

ソフトウェアパッケージの一般化(p185)
ソフトウェアのコストは開発コストのため、複数の利用者がｎ個のコピーを使用することで開発者の生産性がｎ倍になる。
ソフトウェアパッケージの一般化することで低価格化されると、給料支払システムのようなカスタマイズされたソフトウェアでも、自分の給料支払い方法の方をソフトウェアに会わせて使用するようになる。

インクリメンタル開発(p187)
ソフトウェア開発は建築要素のメタファーを有用に使ってきたが、概念構造体が複雑すぎて、根本的に異なるアプローチをとらなくてはならない。
インクリメンタル開発によって、まず動くように作られるべき。動くことでやる気を促す効果がある。


第17章(p193)
増訂版で追加された補足。約十年間で主張が間違っていないことを検証している。

大量の語彙を学習する(p212)

現在では大規模なライブラリをもった結果、プログラミング語彙が大きくなり、語彙習得が再利用を妨げる要因になっている。例として、メンバーが3000を超えるクラスライブラリで各々10～20のパラメータ、オプション変数が指定が必要とある。

*人々は文脈の中で学んでいくので、部品ライブラリだけではなく、構成した製品の実例をたくさん公表する必要がある。
*人々は綴り以外暗記しない。構文と語義は、文脈の中で使用しながら少しずつ学ばれていく。
*人々は構文クラスによって語構成規則をグループ化するのであって、互換性のあるオブジェクトのサブセットによるのではない。

第19章(p243)
二十周年記念版で追加。

多くの人間によってデザインされていながら、利用者という一人の頭脳からみたコンセプト上の統一がとられていなければならない。

アーキテクチャとインプリメンテーションの分離。一人を製品アーキテクトに任命するという主張を強めている。

（間違っててもよいから）利用者群を定義してその特性を推測して機能を絞り込むこと。あれもこれも機能を詰め込むと使いにくくなる(p250)

コンセプトの完全性を持った例としてWIMPインターフェースを上げている。（WIMP：ウィンドウ、アイコン、メニュー、ポインティングインターフェース）
実際の机と同じであるデスクトップメタファー。

ベームのモデルとデータ「ソフトウェア工学の経済学」(p265)

最初の出荷までのコスト最適スケジュール時間T
T=2.5×(人月)^(1/3)
月数で表した最適時間は、予想された人月労力の立方根に比例する
投入された要員の人数には関係なく、計算された最適スケジュールの3/4より短い時間内で成功したプロジェクトはほとんどない

ピープルウェア

「主要な問題は、本質的には技術的というより社会学的なものだ」

お勧めしている。