変化と開発
- 一発で完璧なものを作るのはほぼ不可能だ。失敗した仕様や設計をやり直す機会が開発の過程として存在する計画を始めから立てる必要がある。
- 顧客の要求・要件も不変ではない。プログラムが作られ、テストされ、使用されていくにつれ、顧客のニーズも考えも変わっていくものだ。
- 開発の戦略や技術も、開発者が新しく何かを学べば変化していくものだ。
- 変化に対応しやすくするには、変化を見越した適切な形で、モジュールも、関数も、インターフェイスも、ドキュメントも作成すべきだ。
- 変化に対応するには、バージョン番号を付けて区切りを設け、バージョン毎にスケジュールと凍結日を付与する必要がある。
変化と組織
- 設計者がドキュメントを書きたがらないのは、怠惰からでも時間不足からでもない。まだ考える余地があると思いつつ決めたことを文章化したくないという気持ちからだ。何にせよ、もし「批判が来ても大丈夫にしておかないとまずい」というような脅威を感じさせる組織体制になってしまっているならば、完全に防御できるもの以外は何も文章に書かれない。
- 変化に対応できるシステムを作るよりも、変化に対応できる組織を作ることの方が難しい。しかし、システムに変更があったなら開発体制にも変更が必要だ。
- 組織の管理形態には工夫が必要だ。実例として、全ての職位を廃止した例もあるし、管理系と技術系で二重の職位階層を設け状況に応じて技術者がマネージャーになったりその逆ができたりする体制を作った例もある。
- 能力的に可能であるならば、上級職の人は、マネジメントと技術（プログラミング）の両方がいつでも出来る人であり続けるべきである。チームのトップである主開発者が自身の手も動かすという第3章のミルズの案は、このことを可能にする根本的解決策の1つである。
- また、ミルズの案では、割り当てる仕事をチーム単位で変更することが比較的容易である。これにより、システムの、そして、それを作っている組織の変更が比較的容易となるのである。
プログラムのメンテナンス：2歩進んで1歩下がる
- 広く利用されているプログラムをメンテナンスするコストを合計すると、典型的には開発コストの40%以上になる。
- 副作用の見落としなどにより、ある不具合の修正が別の不具合を生むことがままある。ソフトウェアの構造がまったくきれいなままだったり、ドキュメントが非常に良かったりでもしない限りは、遠くに及ぶ副作用には見落としが発生するだろう。
- 完璧な回帰テストは理想だが、それを実現するためのコストはとても高い。
- 副作用がより少なくなるように、もしくは、よりはっきり分かるように開発すれば、メンテナンスコストを大幅に削減できる。つまり、少数の人員で少数のインターフェイスになるように設計すれば、バグは少なくなる。
プログラムの終焉：1歩進んで1歩下がる
- ある研究では、モジュールの総数がリリース番号に比例して増加した一方で、影響を受けるモジュールの数はリリース番号に対して指数的に増加したことが観察されている。
- 修正を重ねていくにつれ、ソフトウェアに元々あった構造は失われ、混沌とした状態になっていく。そして、不具合修正によって発生した不具合の修正だけで手一杯になっていき、ソフトウェアはいつしか進歩しなくなる。
- その上、時が経つにつれ、ハードウェアは変わり、ユーザーの要求・要件も変わっていく。事実は、ソフトウェアは永久には使えないということである。新しいソフトウェアを一から作るときがいつか来るのである。
- こうして、ソフトウェアはその寿命を終える。
他の章はこちらから：
「人月の神話」の要点
人月の神話の要点・ポイントをまとめています。原著に基づき、人月の神話の要点・ポイントを主に箇条書き形式でご紹介しています。
picolab.dev
2022.04.18
