見積もり過程でキロステップを基準にしないと、商談が成立しない話が来ました。
(例)40キロステップで構築されている現行システム(バッチ処理)を改修/改善する案件。
元受の話によると ,経験則から, 製造から統合テスト完了までの期間をステップで割れば,200ステップ/一人/一日 となるそうで、40Kステップなので 40K/200= 200人日で受けるながれになるそうな。
オブジェクト指向とまで行かなくても,部品の再利用化,車輪の再発明はしない..という姿勢が浸透していると思っていただけに面食らったしだいです。
40キロステップが大きいとみるか小さいと見るかは別として,現行ソースは業務要件通りの処理毎の塊が延々と続いているところをみると、ルーチン化/部品化によるステップ縮小の可能性は大に見える。
オブジェクトクラスを旨く構築すれば,数分の一に縮まる公算も大きそう。 そうなると,見積もり工数の前提である 200ステップ/一人/一日が崩れる。
黙っていようか、議論に持ち込み現実の実態を認識してもらおうか迷いましたが、先方は手続き型見積もり手法を信じているようなので、黙って話を合わせることにしました。(ずるいですね自分..orz)
翻って考えると, サブシステムの要件から基礎クラスを見出し,クラス化する工数を除いた,実装段階の工数見積もりの根拠は示せるのだろうか、有効に使えばば, 700～800ステップ以上/日 の時もある気はする, 100ステップ/日 の時は無いような気がする。
それ以前に,完成後の総ステップ数が大幅に縮小しそうなので,根拠となる総ステップ数の意味が薄い。
しかし元受の現実商談の工数根拠はステップ数での工数しかないようだ。そもそも未開発のシステムの総ステップ数が,要件定義の段階で算出できることが摩訶不思議です。だからIT業界の見積もりの不透明感/アヤフヤ感があるのだろうね。