製造工程の生産性を、うるう年計算の取り組み方を例に考えてみよう。
簡単なロジックの例として「うるう年計算」をモチーフにしてますが、
よくあるプロジェクトの機能要件（たとえば「原価計算」とか「月次精算」とか）に置き換えて読んでください。
ダメダメな新人さんは、、
「うるう年の計算」など念頭にもなく、テスト工程で見つけられなければ4年に一回バグる。
生産時点の生産性はある意味高いが、品質保証や瑕疵担保にかかわる莫大な費用がのしかかる。
ー10000倍
できる新人さんは
先輩を見つけて質問しまくるので、先輩の貴重な工数を使い果たす上に
時間もかかるが、成果物としてはそこそこのものができる。
−1倍
ダメダメな1−3年目のプログラマーは、
ちょくちょく詰まりながらも、仕様面などで確認を取りながらプログラムを作る。
うるう年の計算を頑張ってifとforで5時間ぐらいかけて作る。
1倍
できる1−3年目のプログラマーは、
標準APIでうるう年チェックがないかを確認して
10分ぐらいで実現する。
30倍
ダメダメな4−10年目のプログラマーは、
オブジェクト指向プログラミングを用いて
分岐条件をオブジェクトにカプセル化して
うるう年の計算を2時間で作る。
2.5倍
できる4−10年目のプログラマーは、
そもそも面倒なうるう年計算がいらない要件に調整する。
製造工数という意味では0だが、1分としよう。
300倍
ダメダメなPL/PMは
うるう年計算が面倒かどうかしらないか工数を見込んでない
実現段階では、別で見込んだ費用から食いつぶす計画になる。
ー30倍
できるPL/PMは
見積もり段階でできるエンジニアを捕まえて、いろいろ質問攻めにして見積もるから
うるう年計算が面倒らしいということだけしかしらないが、
普通の工数を確保しておいて、はやくできたなら他のバッファとして使うつもりでいる。
30倍
※世の中の大体のPMは、ダメダメな1-3年目ぐらいのPGを工数の基準にしているという独断と偏見を元に書いています。
