人月の神話を読んだ感想など - どらちゃんのポッケ

IT業界に身を置きながら、今まで絶版で手に入らなかったということもあり、恥ずかしながら、人月の神話をまだ読んでいなかった
- よく勉強会などで、「銀の弾丸がホゲホゲ」という下りも、元ネタは知っていたけど、原著にあたってなかった・・・
しかし、丸善出版さんから人月の神話【新装版】として再販されたので、ぜひ読まなくては！と思い読んだので感想を書く
- 関係ないけども、EFFECTIVE JAVA 第2版 (The Java Series)も再販されました
  - これも目を通さないといけないやつです

全体的な感想

一番、印象に残った。確かにそうだなと思った。単純なものであれば、自分で作成できてしまうので、お金を頂いて行う仕事としてのコードは、何らかの部分が高度に複雑なものになっているはず
加えて、車などの形が決まっているものとは違い、仕様変更が簡単にできてしまうということ
- 要件が決まらない、ひっくり返るということ。変更に対応するような開発は難しい
システムは見えないということ
- UIの部分しか見えないので、その他の部分は人間の思考によって作成する
- 開発の早い段階から、少しでも再集計を見えるようにするデモは重要！
そうなると、プロジェクトの成功の銀の弾丸はないというのも納得

スケジュールを決める時には、人が増えると、その分、コミュニケーションコストも考慮したスケジュールにしないといけない
コミュニケーションは、メール・直接・電話/公式・非公式をフルに使用するべきだな
コミュニケーションの取り方によっては、正確でない進捗報告（悪意のない場合もある)を助長してしまう恐れがあるので、コミュニケーションリスク・コストは重要なものととらえるべき

今まで、マイルストーンは、「ホゲホゲが完成する」というくらいで、明確な基準がなかったなと反省した
じゃあ、その完成とはどういう状態なのか？というもう一歩進んだことが必要なので、意識したい
- 抽象的な基準にしてしまうと、解釈が入り込む余地が生まれてしまい、人によって基準が異なってしまうし、ごまかすこともできてしまう
- 誰がどうみても、YES/NOで判断できるような基準がマイルストーンには必要

教育コスト、コミュニケーションコスト、ブルッグスの法則がある
あくまでも見積もりの目安として、人月をとらえるべき。単純な足し算ではない。
- ブルッグスの法則：遅れている案件に人員をつっこんでも、さらに遅れるだけという法則
少し違う話になるが、QCONのときに、「人月」としてとらえてしまうと、「交換可能な仕事しか与えられなくなるので、コミットメントしにくくなる」という話もあったので、人月とは別の尺度があっても良いのかもしれない
このブルッグスの法則の問題に対する対応はどうすればいいのだろうか？について、思考だだ漏れ的に以下に書く
- 一方で、残業時間・過労死などの問題もあるので、既存の人だけでまわすのにも限界があるし・・・
- スケジュールの引き直し、機能縮小しかないのだろうか・・・
- もっと早めの段階で手を打たないといけないのだろう
  - となると、早めとはいつのことをいうのだろう？マイルストーンで遅れたら？
  - 結局は、「ケースバイケース」となってしまうのか・・・？

会社の中でのプロジェクトの振り返りの結果は、奇麗に抽象的にまとめすぎたり、チェックリストになってしまったりりがちだと思う。
- あまり心に響かないので、生の声を残しておくと感情移入しやすかったり、状況をイメージしやすかったりするのかな？とか思ってみたり
プロジェクトに関わる人すべてが読んで、損はない本だと思います。