工数見積もりをなるべく正確にしなくちゃって時にやる手順

前提

・1人月〜6人月くらいのプロジェクト
・要件定義がほぼ完了している。UIについて、利用者との合意がほぼ取れている(もしくは、機能さえ満たせていればUIは開発者が決めて良い状況)。
・開発体制が、"自分(+誰か)" or "自分と同程度かける人(+誰か)"
・工数見積もりに1日の猶予はもらった
(・ゆるゆる始まったプロジェクトが終わりそうで終わらなくて炎上してる時にも使う)

心構え

1. 「工数はどれくらい？」と聞かれたら、工数と想定開発体制と納期をセットで返す
   • たとえ、聞いてきた人がエンジニア(出身者)だとしても、開発体制と納期は明示する方が安心安全
2. 会議や雑務や時短勤務等の考慮を数値化する。
3. 残業を工数に入れない。どっちにしろ、想定外のことは起こるので、残業するハメになる。

STEPS

STEP1：工数を出す

1. やることをリスト化する
   例)既存システムに追加開発するプロジェクト

   開発内容
   仕様書更新
   参照用API作成
   更新用API作成
   画面A 作成
   既存画面B 修正
   バッチ作成
   総合テスト
   性能テスト
   監視追加

2. 自分が0.5〜1人日(4〜8時間)でできる単位まで細分化する

   • UnitTestは、if分岐全部やる場合、機能実装と同じ〜2倍程度の実装工数かかる(実感)

   例)

   開発内容	詳細	工数
   仕様書更新	編集 レビュー	1.0
   参照用API作成	I/F定義	0.5
   	認証 認証用UnitTest	0.5
   	DB検索①	0.5
   	DB検索用UnitTest①	0.5
   	DB検索②	0.5
   	DB検索用UnitTest②	0.5
   	メイン実装	0.5
   	メイン実装用UnitTest※	0.5
   	レビュー5回	0.5
   	結合テスト項目出し※	0.5
   	検証環境確認 ステージング環境確認 本番環境確認	0.5
   更新用API作成	I/F定義	0.5
   	認証 認証用UnitTest	0.5
   	パラメータチェック※	0.5
   	パラメータチェック用UnitTest※	0.5
   	DB更新①	0.5
   	DB更新用UnitTest①	0.5
   	メイン実装	0.5
   	メイン実装用UnitTest※	1.0
   	レビュー5回	0.5
   	更新履歴書き込み※ 更新履歴書き込み用UnitTest	0.5
   	結合テスト項目出し※	0.5
   	検証環境テスト ステージング環境テスト 本番環境テスト	1.0
   画面A 作成	パス定義	0.5
   	初期描画mock	1.0
   	初期描画API呼び出し	0.5
   	初期描画UnitTest	1.0
   	更新mock	0.5
   	更新値バリデーションチェック※	1.0
   	更新API呼び出し	1.0
   	更新UnitTest	1.0
   	javascript実装	1.0
   	デザイン定義	1.0
   	レビュー7回	1.0
   	結合テスト項目出し	0.5
   	検証環境テスト(ブラウザA、ブラウザB、ブラウザC)	1.0
   	ステージング環境テスト(ブラウザA、ブラウザB、ブラウザC)	1.0
   	本番環境テスト(ブラウザA、ブラウザB、ブラウザC)	1.0
   既存画面B 修正	mock実装	0.5
   	ロジック実装	0.5
   	UnitTest	0.5
   	レビュー1回	0.5
   バッチ作成	関数定義	1.0
   	関数①ロジック実装 UnitTest※	1.0
   	関数②ロジック実装 UnitTest※	1.0
   	関数③ロジック実装 UnitTest※	0.5
   	関数④ロジック実装 UnitTest※	0.5
   	メイン実装 UnitTest※	1.0
   	レビュー6回	0.5
   	結合テスト項目出し	0.5
   	検証環境テスト	0.5
   	ステージング環境テスト	0.5
   	本番環境テスト	0.5
   	リリース手順書作成※ 検証環境への適用	1.0
   	ステージング環境への適用	0.5
   	本番環境への適用	0.5
   総合テスト	総合テスト項目出し	0.5
   	テスト項目レビュー	0.5
   	検証環境テスト	1.0
   	ステージング環境テスト	0.5
   	本番環境テスト	0.5
   性能テスト	プログラム実装	0.5
   	テスト実施	0.5
   監視追加	リリース手順書作成※ 検証環境への適用	0.5
   	ステージング環境 本番環境への適用	0.5

   ※非機能要件(になりがち)。これを抜くと工数が約半分になる。初期見積もりの工数には入っているはずだが、いつの間にか、後回し→忘却されやすい部分。

3. 狭義の「工数見積もり」は、ここまで

   例)

   開発内容	工数(人日)
   仕様書更新	1.0
   参照用API作成	5.5
   更新用API作成	7.0
   画面A 作成	13.0
   既存画面B 修正	2.0
   バッチ作成	11.5
   総合テスト	3.0
   性能テスト	1.0
   監視追加	1.0

   小計：45人日
   バッファ：45 * 0.1 = 4.5人日
   管理工数：45 * 0.1 = 4.5人日

   合計：54人日

STEP2：誰がやるかを考える

実際に手を動かすのは誰か？を考え、工数に係数をかける

例） API・バッチ：自分、画面側：新人(×1.3)

開発内容	工数(人日)	作業者に準じた工数
仕様書更新	1.0	1.0
参照用API作成	5.5	5.5
更新用API作成	7.0	7.0
画面A 作成	13.0	17.0
既存画面B 修正	2.0	3.0
バッチ作成	11.5	11.5
総合テスト	3.0	3.0
性能テスト	1.0	3.0
監視追加	1.0	1.0

例) API・画面：プログラマー(委任契約)(×0.9)、バッチ：自分

開発内容	工数(人日)	作業者に準じた工数
仕様書更新	1.0	1.0
参照用API作成	5.5	5.0
更新用API作成	7.0	6.0
画面A 作成	13.0	12.0
既存画面B 修正	2.0	2.0
バッチ作成	11.5	11.5
総合テスト	3.0	3.0
性能テスト	1.0	1.0
監視追加	1.0	1.0

STEP3：納期を考える

1. いつから開発着手できるか？

2. 1週間で、本件開発にかけられる時間はどれくらいか？

   • 例1) 社員
     • MTG：1 hour
     • 朝礼：10min×5
     • 採用面接：1hour
     • 本件以外の保守もしくは開発(不具合修正等)：4 hour
     • 有給(月1日取得想定)：2 hours
     • 本件開発にかけられる時間：31 hours/40 hours
     • つまり、工数×1.30が必要な営業日日数
   • 例2) 時短社員(7時間勤務)
     • MTG：1 hour/1 week
     • 朝礼：10min×5/1week
     • 有給(月1日取得想定)：1.75 hours
     • 本件開発にかけられる時間：31 hours/40 hours
     • つまり、工数×1.30が必要な営業日日数
   • 例3) リモート委任契約エンジニア
     • MTG：15min×2/1week
     • 有給(月1日取得想定)：2 hours
     • 本件開発にかけられる時間：37.5 hours/40 hours
     • つまり、工数×1.06が必要な営業日日数

3. 年末年始休暇、GW、夏季休暇等を考慮に入れ、納期を試算する

   STEP1の例)をちゃんと見ると、API・画面の工数の中でも、レビューは"自分"の工数になる。とか、"自分"開発部分のレビューは誰の工数使うのか？とかあるが、総数が変わらなければ、あとは開発途中のタスクの割り当て調整でなんとかなる。

   • 例) 2020/08/01から開発開始、API・画面：プログラマー(委任契約)、バッチ：自分のケース
     • プログラマー
       • 必要営業日日数：25人日*1.06=26.5営業日
         • 2020/08の稼働日：17営業日
         • 2020/09/14に完了
     • 自分
       • プログラマー作業と同時に作業できる部分：15.0人日*1.30=19.5営業日
         • 2020/08の稼働日：17営業日
         • 2020/09/03に完了
       • 総合テスト・性能テスト：2.5人日*1.30=3.25営業日
         • 2020/09/15〜09/18
     • 納期：2020/09/23から受入テスト実施可能

STEP4：工数と想定開発体制と納期をセットで返す

例)
「工数は54人日、APIと画面をプログラマーの〇〇さん・バッチ他を自分がやるとして、8月開発開始で9末にはリリースできるかと思います。」