5分でプロジェクト管理を理解できるなら、
デスマーチと呼ばれるプロジェクトはこの世に存在しない！
ITエンジニアは3Kなんて言われてない！
気を病んで突然会社に来なくなっちゃう人もいない！
そんなカオスなプロジェクトに一筋の光が！
この記事はとてもよく書かれている。とてもよくまとめられている。
5分で絶対に分かるプロジェクト管理
ぜひ、ソフトウェア開発にかかわる人全てに読んでもらいたい記事だ。
そして、読むだけじゃなくて理解しろ！
でもこの記事、ちゃんと読むと10分はかかるよね？
タグ: プロジェクト管理
要件を 聞いてばかりで なぜ切らぬ馬鹿 開発サイドは 折れるほかなし
解説
受注金額や納期も考えず、ユーザ要件をすべて受け入れてしまうのは、あまりに愚かであり、そのような要件定義担当者は馬鹿といわざるを得ない。
だが、デスマーチプロジェクトの開発担当者は、折れて受け入れざるを得ない非情な現実を嘆いた歌。
今日の会議中、俺が心の中で詠んだ一首。
最適な工期は「投入人月の立方根の2.4倍」。
デスマーチ化するプロジェクトの条件の1つは工期の設定が不適切であることだろう。調査から導き出された標準開発工期は「投入人月の立方根の2.4倍」。
立方根って何だっけ…？ 一瞬思い出せなかったよ。
1000人月ならば、24ヶ月。
100人月ならば、約11ヶ月。
10人月ならば、約5ヶ月。まぁ、確かにこんな感じだろうね。
工数（人月）の設定ではシステムの画面数やファイル数も使える。調査から導き出されたのは「必要工数＝0.1×ファイル数＋1.3×画面数＋0.3× バッチ数」という数式。その中でも工数と最も高い相関を示すのは画面数で、「必要工数＝画面数×1.55」との数式も示された。
この式が、一番役に立ちそう。一番肝心な総工数を概算するときに、パッと算出できて便利。
概算工数を出すときって、根拠は勘と経験しかないから「ほんとにこんなにかかるの？」って言われたとき、明確な根拠など無いので理由を説明できないことが多い。で、その場で理由見つけて誤魔化すってよくやるなぁ。
なにより、提示された工数が多すぎる／少なすぎるのを素早くチェックできるのがいい。
でも、デスマーチの原因って、工期が短いことよりも、その根拠となる総工数を無理して小さく見積もるのが、一番の原因だよね。「ほんとにこんなにかかるの？」っていう圧力に屈しちゃう人がいるのよ。