フレデリック・P・ブルックス Jr. / 人月の神話[新装版]
これを読まずに「人月」という言葉は使えない。
いつか読む、と思い続けていた名著。読後感は「やっぱそうだよね」。
複雑なんだよ！！っていうことを言い切ってもらってエンジニアとしてはすっきりしたというか。
細かなヒントが散らばっててよかったです。
アジャイルがかなり市民権を得てきた現在では、目新しいことはほとんどないのかもしれません。
でも、ITプロジェクトはほとんどが「新しいものを作る」という挑戦なので「工数を見積る」事自体がかなりふわっとしたものにならざるを得ない、という勘所をちゃんと認識しているかどうかというのは、アジャイルでも大事な感覚だと思います。
（※「新しいものを作る」のでないならそれは開発ではなく運用です）
以下、感想や自分なりの要約。
１、タールの沼
喜びと苦しみ。２、人月の神話
人と月が交換可能になるのは、多くの作業者間でコミュニケーション（意思疎通）を図らなくても、仕事が分担できる場合だけである。でも、システム開発においてそんなことはありえないので、交換は不可能。
途中で人を追加してもリカバリできないのが普通。
1/3 計画
1/6 コーディング
1/4 単体テストおよび初期システムテスト
1/4 全てのコンポーネントを統合して行うシステムテスト
くらいが、著者の経験則によるざっくり見積。
遅れているソフトウェアプロジェクトの要員追加は、さらにプロジェクトを遅らせるだけだ。
簡単な例で、それを説明してくれているので、ここは広く読むべき。
３、外科手術チーム
チームが大きくても、肝のアーキテクトは2名くらいに集中せよ。あとは役割分担。
４、貴族政治、民主主義、システムデザイン
コンセプトの完全性こそ、システムデザインにおいて最重要な考慮点。そういう意味では、少数の２名程度がコンセプトメイクとそのコントロールをするので、貴族政治といえる。
５、セカンドシステム症候群
2回目、となると意気込みすぎて、やりすぎ仕様になることがあるので注意。６、命令を伝える
マニュアル？会議？これは普遍的すぎうえツールが古すぎて参考にならず。７、バベルの塔はなぜ失敗
コミュニケーションと組織の不足。これが大事。制作主任と技術主任が同一人物パターン、6人程度のチームなら機能するが、兼ね備える物は稀だし、仕事量が集中してしまう。
制作主任が上司、技術主任が右腕パターン、技術主任にちゃんと権限を渡す。制作主任の機嫌もちゃんと取れるようにする。
う～ん。なるほど。
８、予告宣言する
実際のコーディングは、全体タスクの1/6くらい。実際には雑多な作業にかなり時間を使うので注意。
９、5ポンド袋に詰め込んだ10ポンド
メモリの話。時代的に、また、今回手にとったテーマに対しあまり参考にならないので飛ばす。10、文書の前提
形式の整った文書、必要という話。まぁそりゃそうだ。
11、1つは捨て石にするつもりで
最初の1つは完全じゃないと思うくらいで取り組め。目的も変わるし。組織もそれについていけるように考えろ。
ちなみに、修正とか改善は、エントロピー増になるのでいいことないかもよ、と。
12、切れ味のいい道具
時代的にいらないと判断して飛ばす。13、全体と部分
ルールパターン。構造化プログラミング、トップダウンデザインなど。ちゃんと読んでない。レシピ的に読み返すのはありかも。
デバッグ話は時代的に略。
14、破局を生み出すこと
上司ならだれでも二種類の情報が必要。新たな処理が必要な、計画にとっての例外的状況と、教育のための実態状況に関するもの。上司はまず、行動を取るための情報と、状況を理解するための情報を区別すべき。
マネージャで解決できる問題には立ち入らない。明らかに状況を検証している時には問題に対する行動を起こさないようにする。
メーティングや評価・検討会あるいは大きな会議を、状況検討のためか問題対策のためかはっきり区別せよ。
…じわじわ、小さな遅れが、実はクリティカルなので、そういうものにこそ本気でオンスケ足らせる努力をせよ。
15、もう1つの顔
文章に書くべき内容。目的、環境（ハードウェア構成など）、入力と出力の閾値？、機能と使用されるアルゴリズム、入出力フォーマット、バッチ処理？、操作方法、、、、
フローチャートはいらない、自己文書おすすめですよと。
16、銀の弾などない
王道はない。しかし、道はある。ソフトウエアの進歩が例外的に遅過ぎるのではなく、コンピュータハードウェアの発達があまりにも速い。
ソフトウェア構築において困難な部分は、この概念構造体の使用作成とデザインおよびテストにあって、それを表現する仕事やその表現に忠実か否かをテストする仕事ではないと考える。
ソフトウェアの複雑性は本質的であり偶有的なものではない。
数学や物理学は、複雑な現象を単純化したモデルを構成し、そのモデルからある性質を引き出し、…、進歩を遂げた。この方法でうまく行ったのは、モデルで無視された複雑性が現象の本質的な性質ではなかったから。
ソフトウェアは本質的に複雑な上、不可視性がなく、可変性が高い。。
偶有的困難を解決したこれまでの発展3つ。
高水準言語、タイムシェアリング、統一された環境。
高水準言語の進歩は期待に値するが、本質的な解決はもたらさない。
オブジェクト指向。これも期待はあるが、本質的な解決はもたらさない。
人工知能。作者は期待しない。
ソフトウェア構築で最も困難な部分を1つあげるなら、それは何を構築するのかを的確に決定することである。
概念的作業において、詳細な技術的要件を固めることほど難しいものはない。
インクリメンタル開発、、、、
17、銀の弾などない 再発射
誤解を受けるな、悲観的な言葉ではない。改善を少しずつ進めていける。再利用性は理想的なスピードでは進んでいない。
18、「人月の神話」の命題─真か偽か？
まとめ。19、「人月の神話」から20年を経て
20年経ってやっぱり主張したいこと。コンセプトの完全性と、それに責任を持つアーキテクトが１人必要。少数精鋭でやれ。
アーキテクチャとインプリメンテーションは分割せよ。
捨て石にするつもりで作ってはいけない。。ウォーターフォールを大前提とした話だったから（捨て石にするつもりでと書いた）だ。
情報隠ぺい（オブジェクト思考プログラミングにみられる）がソフトウェアデザインのレベルを上げる唯一の方法。
パソコンの普及スピードは予想外だった。
パッケージを使って構築する、という流れは期待できそうだ。