システム開発での工数見積もりの実務上の解決方法

工数の見積もりは難題なのは、作ってみたことのないシステムを誰が作るかわからない（力量的な意味で）のに見積もろうとしているシステムのコストをひねりださなければならないからです。

ここでプロジェクトの定義をおさらいしますが、プロジェクトとは唯一無二な有限の業務活動です。唯一無二とはメンバや顧客や適用技術と実現する目的がぴったり一致することはないからです。これ大事。仮に全部同じ組み合わせがあったとしてもメンバは２回目ならスキルレベルが上がっていますからね。というか、同じものなんて作らんし。

戻って、こんなエントリを見つけたので興味津々で見たら「何か違う」という違和感しか。その違和感なんだろーなーとおもってリンクの先をチラッと見てみたら、これ、いわゆる工数見積もりだな、と思えたのは一番最後だけ。最後から３番目のDeNAのはそれなりだけどごく一部というか。

工数見積もりやスケジュール管理で参考になる記事10選 | UX MILK

開発の見積もりとスケジュール管理 - クックパッド開発者ブログ　初心者向け
不安とストレスから解放される見積りとスケジュール方法 - Qiita　どこで見積もりのこと書いているの…
なぜ開発で見積り失敗して忙しくなりがちなのか(アジャイルな見積りと計画づくり読んだ) - $shibayu36->blog;　これは「お」っとおもったけど結局書いてない
開発者の仕事が遅いわけではない！納期が遅れるホントの原因 | 開発手法・プロジェクト管理 | POSTD　これは進捗が遅れる原因
初心者エンジニアにおすすめしたい「進捗どうなった？」と言われないための仕事の進め方 - Qiita　この見積もりは実行時の作業完了の見通しのことだね
「人が足りない！」と気づいた頃にはもう手遅れ、スケジュールの遅れはどうすれば取り戻せるか | サイボウズ式　これは進捗管理というか炎上対策？
2点見積もりが意外とうまくいった話 — Mobage Developers Blog　ここまできてやっと見積もりらしい見積もりのブログが登場と思えるほど既出が…
想定する見積をより正確に！工数見積の誤差を減らすPERT手法とは | 株式会社LIG　まともな見積もりの手法の話だ！
「工数一日」は「明日できる」じゃない！エンジニアと非エンジニアのギャップとは - paiza開発日誌　ぜんぜん見積もりじゃない…
工数見積りの海を彷徨う - hidekatsu-izuno 日々の記録　これが一番まともな見積もりのブログ！！

見積もりは２種類ある
見積もりは２種類あります。入札や価格提示の際の見積もり。本来はこっちを指す。もうひとつは、プロジェクトの実行の際に作成するときのプロジェクト計画での見積もり。ありがちなのは、価格提示の見積もりした人とプロジェクト実行のプロジェクトマネージャが違って、実行計画の「工数が足らねー！」となるやつ。

もう一度書くけど、普通は前者の価格提示の工数見積もりがターゲット。

見積もり手法はいろいろある
FP法とか類推とかCOCOMOIIとか。

正確な見積もりはできない
どれでもいいけど、過去実績がないと見積もった工数見積もりの確からしさは確かめられないし、あったとしても実績工数の条件はプロジェクトとは唯一無二のものだから見積もろうとしている工数と対比できるとは言えない。

開発手法の違い、スクラッチかパッケージカスタマイズかインフラみたいなものでは同じ見積もり手法は使えない。結局、作るもののキーファクターを押さえて、その実績値を持っていないと単なるギャンブルにしかならない。そんなのエンジニアリングとは言わない。

実務上の解決方法
担当する業務領域のプロジェクトの実績をきちんと残すことが最重要なのですよ。構成メンバと技術レベル、計画工数と実績工数、実現したシステムのインタフェース数、機能数、品質状況などなど。あとWBS。そうそうシステム構成も。

ざっくりしたWBS、見積もりレベルならレベル２くらいで展開してざっくり工数としたものと実績のキーファクターを比較する。乱暴だけど。ここでキーファクターが同じなのに工数が違えば何かが特殊な要因があるか、抜け漏れがあるのかもしれない。でも、キーファクターは参考値なので。そのキーファクターも実績が蓄積されれば指標として使えるので頑張って貯めよう。

あとは、実際のプロジェクトのアサインメンバが決まっていれば係数をかければいいし、未定ならこのレベルのメンバと前提を残すしかない。間違ってもドリームリームで工数を弾かないこと。