はじめに
ソフトウェア工学のバイブル(色々な意味で)と呼ばれるこの本、
たまたま本屋で見かけたため、つい買ってしまいました。
購入した書籍の詳細はこちら。
https://pub.maruzen.co.jp/book_magazine/book_data/search/9784621066089.html
折角なので、この本の読み進め方、なるほどと思った点などを、
wikipediaとは違う観点で書いて行こうと思います。
https://ja.wikipedia.org/wiki/人月の神話
概要
そもそも「人月の神話」が何か知らない人もいると思うので、説明します。
著者
フレデリック・ブルックス( Frederick Phillips Brooks, Jr. )さん。
https://ja.wikipedia.org/wiki/フレデリック・ブルックス
英語版wikipediaの方が詳しい経歴あり。
- IBMでOS/360の開発グループマネージャなどを務めた。
- コンピュータ・アーキテクチャは彼の造語。
- 1999年のACMチューリング賞受賞者
- ブルックスの法則 をこの書籍で提唱
形式
エッセイという事になっている(原文：ESSAYS ON SOFTWARE ENGINEERING)。
自身が開発グループのマネージャを務めた IBM OS/360 の開発を振り返りつつ、
ソフトウェア開発手法についての研究結果を紹介しながら持論を展開する流れ。
他にも IBM stretch の話が出てくる。
参考文献の番号([3]など)は通し番号ではなく、章ごとに独立しているので注意。
年表
- 1964年： OS/360発表
- 1975年： 「人月の神話」刊行
- 1995年： 16章～19章が追加された20周年記念版が刊行
- 2017年： このページがQiitaに投稿される
OS/360開発プロジェクトについて
開発規模
ピーク時のプロジェクトメンバは総計1,000人超え
開発に5年かけたので、単純計算で60,000人月
開発環境など
1960年代前半のため非常に古いです。
| 項目 | 内容 | 補足 |
|---|---|---|
| 言語 | アセンブラ | C言語の登場は1972年 |
| 連絡手段電話 | 口頭、電話、紙の文書 | 当時はメールも無かった |
| テキスト編集 | タイプライター⇒コンピュータ | テキスト編集システムは自分たちで開発 |
| 文字コード | EBCDIC | 当時はASCIIコードの普及前 |
| ターゲット | メインフレーム System/360 | 今では System Z に引き継がれている |
| 開発モデル | ウォーターフォール(※) | スパイラルモデルの提唱は1988年 |
※著者は今ではウォーターフォール否定論者。
用語集
この本では現代ではあまり見かけない用語や、言葉の使われ方がされています。
それらを以下にまとめました。
| 用語 | 意味 |
|---|---|
| アーキテクチャ | この本では「外部設計」という意味と捉えるとしっくりくる |
| インプリメンテーション | 直訳すると実装だが、「内部設計」+「実装」といったところか |
| 本質的複雑性 | プログラムの状態の増加によって生じる複雑性 |
| 偶有的複雑性 | 付随的複雑性とも、本質的でない複雑性(例：ワープロがない) |
| セカンドシステム | その人が2番目に携わったシステム製品 |
| もう一つの顔 | ソフトウェア製品のドキュメントの事 |
| コンセプトの完全性 | インターフェイスの一貫性、良い例として挙がMacの操作性の統一感 |
章一覧
どの章にどんなことが書かれているのかをざっくりまとめました。
実際に読む場合、第18章を最初に読むことをお勧めします。
第1章 タールの沼
なぜソフトウェア開発は難航するのかについて。
第2章 人月の神話
なぜ人員を2倍にしても開発期間が単純に1/2にならないか、研究結果を元に図示。
第3章 外科手術チーム
できるプログラマとできないプログラマのの生産性の差についての研究結果を紹介。
できるプログラマのみで構成した少数精鋭チームには開発できる規模の限界があるため、
実際問題として大規模開発においてはどうするか。
ここでいう外科手術チームとは開発部隊を10人ずつに分割したチームのこと。
各チームの執刀医(チーフプログラマ)がチーム間の調整をすればコミュニケーションコストを削減できるという考え。
第4章 貴族政治、民主政治、そしてシステムデザイン
何を作るのかと、どうやって作るかは分けて考えるべきだという事について。
ここでいう貴族とは何を作るかの方を考える人たち。
第5章 セカンドシステム症候群
その人が最初に担当した製品に比べて、2回目に担当した製品では
凝りすぎて要らない機能まで作りこみがちという話。
続編もののゲーム等にありがちですね。
第6章 命令を伝える
仕様をどうやって書くか、それをどうやって開発者に伝えるかについて。
第7章 バベルの塔は、なぜ失敗に終わったか？
旧約聖書に登場するバベルの塔の建設失敗を、プロジェクト管理の観点から検証。
これは21世紀のプロジェクト管理についても当てはまる点が多いと思います。
第8章 予告宣言する
見積もりについての各研究成果を紹介。
これも今の時代でもうまくできていないですね。
第9章 5ポンド袋に詰め込んだ10ポンド
当時のプログラムのメモリ使用量について。
この章の最後の2ページは今でも参考になる気がします。
第10章 文書の前提
どんなドキュメントが必要か、なぜ必要か。
第11章 1つは捨石にするつもりで
今の言葉でいうプロトタイピングについて。
第12章 切れ味のいい道具
当時のデバッグ環境について。
今の時代だとあまり当てはまらないですね。
第13章 全体と部分
モジュール分割とデバッグについて。
今でも当てはまる話が結構あります。
第14章 破局を生み出すこと
なぜプロジェクトが遅延するかについて。
この当時で既にPERT図を使ったスケジュール管理が行われているのは驚き。
第15章 もう1つの顔
どのようにドキュメントを書くべきか。
既にフローチャートが時代遅れ扱いされている。
第16章 銀の弾などない――ソフトウェアエンジニアリングの本質と偶有的事項
ここから20周年記念版(1995年)で追加された章。
この章では今後何がソフトウェアの本質的複雑性を解決しうるかについて述べられている。
第17章 「銀の弾などない」再発射
関連する論文、論説への意見や反論。オブジェクト指向について。
第18章 『人月の神話』の命題――真か偽か
1975年に書いた1～15章の概略と20周年記念版の1995年の観点からの補足
この章を一番最初に読むことをお勧めします。
第19章 『人月の神話』から20年を経て
1975年に書いた1～15章のうち、どの章が1995年現在で有効か、どれが時代遅れになったか。
これからの展望について。
読んだ感想
タイトルにある人月の神話に直接関係してくるのは2章と3章で、
2章では人員を増やせばその分コミュニケーションコストが増加すること、
それに対して3章では10人程度の開発部隊をチームに分割することで
コミュニケーションコストの増加をある程度抑えられる事が示されています。
プロジェクトに途中から人員を追加した場合、教育や分担替えのコストで
更に遅延するだけというブルックスの法則は2017年現在でも健在だと感じます。
これに関しての解決策としてはモブプログラミングなどがあるのかなと思います。
3章では同程度の経験を積んだプログラマでも生産性に10倍の差があるという研究結果も
紹介されており、人月という指標が開発部隊の全体としての能力を測るのに全く使えないという
印象を受けましたが、以降の章で人月という言葉が指標として普通に出てくるのは少し残念に感じました。
また、ウォーターフォールで開発している事、規模の単位が命令数である事など
様々な個所で古さを感じてしまいます。
それでも現代のソフトウェア開発に通じる教訓は随所にあると感じました。
おわりに
間違いの指摘、他の本のお勧めなどなどなど、コメントをください。