hitode909の日記

以前はプログラミング日記でしたが、今は子育て日記です

計画の科学

三点見積もりでもやってみるか、という話になって、id:onkさんにおすすめされたので読んだ。PERT、Program Evaluation and Review Techniqueについて教えてくれる本。1965年の初版が電子書籍化されていておもしろい。
読んでたら、こんなの大学の授業でやったなってだんだん思い出してきた。

PERTは各タスクの依存関係をグラフにしたもので、見積もり時間を持っているもの。ガントチャートと違って、各タスクの依存関係や、遅れたときに全体に影響がある箇所や、余裕がある工程がどこなのかを可視化できる。
ja.wikipedia.org

以下は読書メモ

  • ネットワークは関係者が集まって描く。お互いの意見を出し合って最高のプランがネットワークとしてまとまるのが良い点
  • 見積もりトータルフロートが0であるパスがクリティカルパス。そのパス以外はフロートがあり、早くやっても仕方ない。クリティカルパスを縮めると、それ以外のパスのフロートがゼロになる形で縮められる。スケジュールを早めると、クリティカルパスが増えていく
  • 三点見積もりについて、楽観値=全て円滑に進んだ場合、最可能値=最頻値、悲観値=すべてうまくいかなかったとき。これらは約束ではなく技術上の見積もり
  • 一企業のプロジェクトについても妥当性を有するかは疑問が多い、10回中1,2回発生する両端の数値を見積もりできるのか→不確かな要因をネットワークの最後に表示する
    • 普段の開発では、よく適当に決めたバッファ期間を設けている。バッファ期間をプロジェクトの序盤に使い切ってしまい二度と回復しないことが多い…。
  • 山本五十六長官は3つの作戦計画を準備していた。大成功の場合、予定通りの場合、失敗した場合。
  • クリティカルパスは全体の平均数パーセントで、10パーセント以上になることはめったにない。注意を要する作業と日程的に手を抜ける作業を区別できる
    • アサイン決めるときにも参考にできそう、本には、優秀な社員を配置する、という話が書かれていた。兼務やインタラプトの多い社員はクリティカルパスから外すというのも考えられそう

ネットワークの図を関係者が集まって作ろうというのが気に入った。エンジニアに対して、見積もりを出してください、とか言ってエンジニアが出してくるんじゃなくて、いろんな知識を持ってる人が協力して、チームとして作れると、皆の認識が揃って、健全にことを進められそう。プロダクトバックログの見積もりをみんなでやるのに似ていると思う。
属人化した、勘と経験で気合でやってしまっている工程も図にしておくと人に引き継ぎやすくなるかもしれない。全容のわからない仕事を急いでやってみたけどそこは重要ではなく急いでやったことに意味がなかった、ということがあると悲しい。

計画の科学 どこでも使えるPERT・CPM (ブルーバックス)

計画の科学 どこでも使えるPERT・CPM (ブルーバックス)