読者です 読者をやめる 読者になる 読者になる

どらちゃんのポッケ

R・統計・技術メモなど勉強ログ置き場

人月の神話を読んだ感想など

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

全体的な感想

  • バックグラウンド自体は古くなっているが、今のテクノロジーの中であっても、十分考慮する点が多いなと思った
  • 書籍の中でも触れていたが、IT分野だけでなく、「チームでモノを作る」という行為に対する良い示唆を与えてくれる
  • 今まで、デモやR&Dの中でしかアプリを作成したことがないが、経験したことがうまく言語化されている
    • 「あー、あった!」的なことがたくさん

印象に残った点(太字が感想、その他が内容)

ソフトウェアの本質は複雑性なので、開発はたいてい難しい

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

コミュニケーションコストについて

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

マイルストーンは具体的・明確な基準を持つイベントにしないといけない

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

人月というが、人と月は交換可能なものではないということ

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

さいごに

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