プログラムシステム製品の開発コスト
大規模システムプログラム開発において、設定されたゴール、スケジュール、及び、予算を全て満たした事例は少ない。一方で、大きな開発チームが作った製品を上回るプログラムをガレージの2人組が作った事例はある。この対比について考えるには、何が作られているのかに目を向ける必要がある。
- 単なるプログラム：プログラマ個人で使うもの。よくプログラマ個人が想定する生産性はこれに対するものである。
- プログラム製品：多くの環境や入力データに対応し、誰でもテスト・修正・拡張が可能なもの。入力可能範囲をカバーしたり境界値を確認したりする十分な数のテストケースが必要。デバッグ済みの単なるプログラムに比べ開発コストは少なくとも3倍。
- プログラムシステム：協調して機能するプログラムコンポーネントの集まり。協調のための仕組みやコンポーネントの間での資源の分配が必要。コンポーネントの可能な組み合わせ全てについてカバーできるようなテストが必要。プログラムシステムの1コンポーネントの開発コストは単なるプログラムに比べ少なくとも3倍。
- プログラムシステム製品：システムかつ製品であるもの。開発コストは単なるプログラムに比べ少なくとも9倍。
プログラムシステム製品の開発チームという体制に対して、ガレージの2人組という体制が取って代わらない理由がここにある。
（「少なくとも何倍」というのは著者による推定である。）
開発の喜び
- 物を作る純然たる喜び。例えば、泥遊びで作った泥団子。
- 他人のために有用な物を作る喜び。例えば、お父さんの仕事場用にと作ったペン立て。
- 複雑でパズルのようなものを作る魅力。例えば、ピンボールのような。
- 新しく学ぶ喜び。本質的には、同じプログラムを再び書くことはない。
- 頭の中で思い描いたことを現実にできるほどの柔軟性を持つプログラムというもので仕事をする喜び。プログラムはやり直しが効いて扱いやすいが、このことは第2章で触れるように問題でもある。
開発の苦しみ
- 完璧でなくてはならないこと。伝説に登場する呪文のように一語一句間違えてはならない。
- 責任に見合う権限が与えられないこと。仕事の環境やゴールでさえコントロールできることはまれである。ただし、どんな分野であれ、物事を成し遂げる仕事においては、正式な権限が責任に見合うだけ与えられることはないようだ。完遂へと向かう勢いの中で、正式な権限ではなく実際の権限が得られるのだ。
- 他人のひどいプログラムに付き合う必要があるとき。
- つまらないバグ取り。楽しい仕事だけではない。
- 多くの人が思うよりもデバッグには時間がかかること。よって、テストは延々と続き、最後の難しいバグはなかなか取れない。
- 技術は常に進んでいるため、製品は完成したときには常に時代遅れであるということ。しかし比較対象が未完成であるならば、その完成にはどうせ時間がかかるのだ。相手がコンセプト段階であり、その実装がまだ存在していない場合は特にそうである。
他の章はこちらから：
「人月の神話」の要点
人月の神話の要点・ポイントをまとめています。原著に基づき、人月の神話の要点・ポイントを主に箇条書き形式でご紹介しています。
picolab.dev
2022.04.18
