見積もりでは百時間だった仕事が、終わってみると百五十時間かかっていた。
この時、最初に出やすい説明は「作業が遅かった」です。
でも、実際には途中で要求が増えた、顧客との認識が違った、例外処理が後から見つかった、確認のやり直しが発生した、といった複数の理由が混ざります。
工数だけを記録しても、なぜ増えたかが残らなければ、次の見積もりは賢くなりません。
必要なのは、予定と実績の差を、変更の理由まで分けて残すことです。
工数超過は、作業速度だけの問題ではない
工数が増える原因は、大きく六つあります。
- 最初から抜けていた：必要な作業を見積もりへ入れていなかった
- 要求が増えた：途中で新しい機能や対応が追加された
- 認識が違った：顧客と開発側で完成像が異なっていた
- 例外が見つかった：正常な流れ以外の処理が後から分かった
- 手戻りが起きた：確認不足や設計変更で作り直した
- 完了が曖昧だった：どこまで確認すれば終わりか決まっていなかった
これらを全部「開発に時間がかかった」でまとめると、改善策も全部「もっと速く作る」になります。
原因が違えば、直す場所も違います。
追加要求を無料で飲み込むと、売上は同じで原価だけ増える
固定金額の案件では、途中の小さな変更をそのまま受けることがあります。
一つひとつは小さく見えても、積み上がると利益を削ります。
- 入力項目を一つ増やす
- 権限の例外を追加する
- 一覧の並び順を変える
- 通知先を条件で分ける
- 既存データを移行する
変更自体が悪いわけではありません。
問題は、当初の範囲から変わったことを記録せず、金額、期限、優先順位のどれも変えないことです。
その状態では、顧客から見ると同じ案件、会社から見ると原価だけ増えた案件になります。
最初の見積もりを、比較できる単位へ分ける
総工数だけで見積もると、どこで差が出たか分かりません。
少なくとも、次のような単位へ分けます。
- 何を実現するかの整理
- 画面や操作の設計
- 業務ルールの実装
- 外部システムとの接続
- データ移行
- 正常時の確認
- 異常時と境界条件の確認
- 顧客確認と修正
- 公開と運用準備
細かくしすぎる必要はありません。
次回の見積もりで再利用できる程度に、差が分かる単位へします。
変更が起きたら、六つの項目を残す
変更履歴には、次を記録します。
- 変更内容：何が変わったか
- 発生理由：要求追加、認識違い、技術制約、法令、品質など
- 発見時点：いつ分かったか
- 影響：工数、期限、金額、品質への影響
- 判断者：誰が採用を決めたか
- 次回への学び：見積もり、質問、確認方法のどこを変えるか
変更を記録する目的は、誰のせいかを決めることではありません。
同じ種類の変更を、次回は早く見つけるためです。
要求から完了証拠までつながっていないと、最後に手戻りが増える
完成の判定が曖昧な仕事ほど、終盤に修正が増えます。
「会員登録を作る」だけでは、何をもって完成か分かりません。
- 誰が登録できるか
- どんな情報を入力するか
- 重複した場合はどうするか
- 確認メールが届かなければどうするか
- 管理者は何を確認できるか
- どの証拠で動作を確認するか
具体的な利用場面と確認条件を先に置くと、作った後の認識違いを減らせます。
要件定義の進め方は、要件定義の完全ガイドで整理しています。
PM on Railsでは、変更を元の目的までたどれるようにする
私たちは開発で、PM on Railsを使っています。
何を実現したいか、誰が何をしたいか、具体的にどう動けば正しいか、何を作業し、どう確認したかを関係付けて管理します。
途中で変更が起きた時も、単なる作業追加ではなく、どの要求や利用場面が変わったのかをたどります。
これにより、次のことを確認できます。
- 元の要求が曖昧だったのか
- 途中で新しい要求が増えたのか
- 作業の分解が不足していたのか
- 確認条件が足りなかったのか
- 同じ変更が別の機能にも影響するか
PM on Railsを入れるだけで工数超過がなくなるわけではありません。
ただ、差が発生した場所と理由を、次の見積もりへ戻せるようになります。
案件終了後は、見積もりと実績を原因別に比較する
振り返りでは、総工数の差だけでなく、原因別の時間を出します。
- 当初範囲の作業
- 追加要求
- 認識違いによる手戻り
- 技術的な想定外
- 顧客確認待ち
- 品質確認の追加
- 社内のやり直し
たとえば百五十時間かかった案件でも、当初範囲は百五時間、追加要求が二十五時間、認識違いが二十時間なら、担当者の作業速度だけを責めるのは違います。
一方で、毎回同じ種類の認識違いが出ているなら、最初の質問や確認方法を変える必要があります。
見積もりの差を、次の案件で検索できる知識にする
案件ごとの振り返りを会議で話して終わると、数か月後には忘れます。
次の案件で、条件が似た過去案件を探せるようにします。
- 業界
- 利用者数
- 画面数
- 外部接続の数
- データ移行の有無
- 権限の複雑さ
- 当初見積もりと実績
- 追加された要求
- 手戻りの原因
これが増えるほど、「以前の似た案件では何が抜けたか」を見積もり時に確認できます。
会社の知識を検索可能にする考え方は、判断の理由を会社へ残す記事とも共通します。
工数超過を減らす五つの運用ルール
- 見積もりを再利用できる作業単位へ分ける
- 当初の範囲と追加要求を分ける
- 変更ごとに工数・期限・金額への影響を確認する
- 完成条件と確認証拠を作業前に決める
- 案件終了後、差の理由を次の見積もりへ反映する
すべての変更で契約書を作り直す必要はありません。
小さな変更なら、優先順位を入れ替える、別の機能を後ろへ送る、追加時間を承認するなど、影響を合意できればよいです。
大事なのは、追加を追加として扱うことです。
経営者が見るべき数字
案件管理では、次を追います。
- 見積もり工数と実績工数の差
- 追加要求に使った工数
- 手戻りに使った工数
- 顧客確認待ちの期間
- 案件別の粗利
- 同じ原因が再発した回数
- 過去成果物を再利用できた割合
工数超過だけを減らそうとすると、必要な品質確認まで削る危険があります。
粗利、品質、納期、顧客満足を合わせて見ます。
時間を記録するだけでなく、時間が増えた理由を会社へ残す
予定より時間がかかった案件には、次の見積もりを良くする材料があります。
何が抜けていたのか。いつ分かったのか。どの質問を先にすれば見つかったのか。どの確認条件が足りなかったのか。
作業時間の差を、原因と判断まで残す。
そうすれば、同じ失敗を繰り返さず、見積もりの精度、案件の粗利、顧客との合意を一緒に改善できます。
生成AI開発の費用と見積もりで確認すべき条件は、生成AI開発の費用相場にもまとめています。
Beekleにご相談ください Beekleでは、AI活用や業務システム開発について、作るものの整理、費用感、進め方まで一緒に確認します。まだ曖昧な段階でも、最初に何を決めればよいかから相談できます。