なぜプロジェクト時間をいつも少なく見積もるのか — 無料労働をやめるための方法

過小見積は運ではなく仕組みの問題であることが多い

1件だけ予定を超えたなら不運かもしれません。5件連続ならそれはデータです。40時間で提案して60時間で終わることが繰り返されるなら、見積プロセスのどこかが欠けています。速く働く努力は少し役立ちますが、作業カテゴリそのものを除外した見積は速度では直せません。まず、超過を毎回別の事故として扱うのをやめ、提案を送る前に何が数字から消えているかを調べます。

過小見積が高くつく理由は、抜けた時間が消えないからです。時間制では予算について不快な会話が生まれ、固定価格ではそのまま利益が減ります。提案時には利益が出そうだった案件が、数週間の無償作業に変わることもあります。だから見積は本番前の事務処理ではなく、仕事そのものの商業モデルの一部です。

解決策は、すべてに一律30％を足すことではありません。根拠のないバッファは、楽観的な数字と同じくらい弱い考えを隠します。隠れた作業、曖昧なscope、依存関係、修正、コンテキスト切り替え、技術的不確実性、普通の日が順調に進むという楽観など、漏れの場所を特定します。原因が分かれば、自分で負担する代わりに価格や運用で管理できます。

目に見える制作だけを見積もり、その周辺作業を忘れている

人は見える中心作業の方が見積もりやすいものです。デザイナーは画面、開発者は実装、ライターは原稿、コンサルタントはワークショップを数えます。しかし案件にはdiscovery、会議、アクセス準備、フィードバック確認、テスト、回帰修正、デプロイ、引き継ぎ、請求、フォローアップもあります。メイン成果物ではないからといって、これらが架空の仕事になるわけではありません。

そのため経験者でも慣れた仕事を過小評価します。コア作業は本当に8時間でも、納品までの全体は12時間かもしれません。8時間だけで見積を作れば、経験が『慎重に間違う』代わりに『自信を持って間違う』原因になります。制作方法をよく知るほど、周辺の調整を頭の中で省略しやすいのです。

隠れた作業の標準チェックリストを作り、毎回使いましょう。すべての項目が毎回必要とは限りませんが、意識的に0時間と判断する方が存在そのものを忘れるより安全です。再利用できるリストがあれば、新しい提案が直前の苦い記憶に依存することも減ります。

• discovery、要件確認、仕様の明確化
• 顧客コミュニケーションとプロジェクト管理
• コンテンツ準備、データクリーニング、アクセス設定
• テスト、QA、アクセシビリティ、端末確認
• 含まれる修正ラウンドと手戻り
• デプロイ、引き継ぎ、ドキュメント、公開後確認

楽観バイアスが最良ケースを公式プランに変えてしまう

方法を知っている作業ほど、頭はきれいな経路を思い描きます。API文書は正しく、顧客は時間通りにアクセスを渡し、デザインは1回で承認され、パッケージは問題なく入り、legacy codeも素直に動く。集中時間の途中に緊急会議も入りません。こうして見積は『普通の案件の予測』ではなく『良い日の説明』になります。各仮定は単独なら妥当に見えるので、合計もプロらしく感じます。

必要なのは悲観主義ではなくレンジ思考です。不確実なタスクについて、楽観、最頻、悲観の3つを書きます。データがきれいなら4時間、普通なら8時間、隠れた問題があれば16時間という移行作業なら、3つを並べるだけで判断が変わります。不確実性が1つの自信ある数字の中から外に出てきます。

レンジは固定価格が危険なときも教えてくれます。悲観ケースで利益が壊れるなら、固定コミットには早すぎます。有料discovery、上限付き時間制、途中の判断ポイントが必要かもしれません。それは見積能力の不足ではなく、不足情報を無料のリスクとして引き受けない姿勢です。

曖昧なscopeはどんな見積も脆くする

名詞だけでは見積できません。ウェブサイト、ダッシュボード、ブランディング、統合、自動化はカテゴリであってscopeではありません。必要なのは、ページ数、state、統合、対応端末、コンテンツ担当、修正回数、受入基準、明確な除外事項など、観察できる成果と境界です。境界がない時間は、合意された案件ではなく頭の中の案件に対して付けられています。

scopeが曖昧だと双方が空白を自分の仮定で埋めます。こちらは通常フォームを想像し、顧客は条件分岐、CRM同期、analytics eventを想像する。こちらは決裁者1名を想定し、実際は3部署。こちらは商品データ提供済みと思い、顧客はデータ整形と取り込みまで含むと思う。自分の想像案件に対する計算が正しくても、現実の案件とは違います。

時間を出す前に『完了とは何か』を短く書きます。合理的な2人が完了かどうかで意見を分けられるなら、まだ明確化が必要です。全ピクセルを先に決める必要はありませんが、後で新しい依頼を『含まれる』か『scope変更』か判定できる境界は必要です。

• 広いラベルではなく名前の付いた成果物
• 重要な成果に対する受入基準
• 含まれる修正ラウンドの数と意味
• 顧客側の責任と必要入力
• 既知の除外項目と第三者費用
• 変更承認の書面プロセス

顧客依存は見積とスケジュールの両方に入れる

技術的には簡単でも運用上遅い案件があります。認証情報、原稿、法務承認、商品データ、ステークホルダー判断、外部ベンダーへのアクセスなどが必要だからです。入力が遅れても直接作業時間は大きく変わらないかもしれませんが、再スケジュール、コンテキスト切り替え、終えた仕事への再進入によって実際のコストは上がります。

依存事項には担当者と期限が必要です。背景の仮定ではなく見積に書きます。『実装開始前に顧客が最終原稿を提供』は飾りではなくスケジュール条件です。遅れれば納期が動くなら明記し、追加手戻りが起こり得るなら処理方法も決めます。

依存事項が作業量まで変えるなら価格にも反映します。クリーニングが必要かもしれないデータ、未知のAPI、予測できない形式のコンテンツを、最良ケースが保証されているかのように価格設定してはいけません。不確実性を価格に入れる、受け入れる入力を限定する、事実が見えるまで時間制にする、といった方法を使います。

魔法の一律％ではなく、リスク別のレンジとバッファを使う

バッファは理由があるときに役立ちます。慣れたデザイン作業ならほとんど不要かもしれません。文書が弱い外部統合なら広いレンジが必要です。両方に自動で20％を足すのは簡単ですが、どこが危険かを教えてくれません。案件後にもバッファが必要だった理由を学べません。

タスクを分解し、予測可能・変動・未知に分けます。予測可能なものは自分の実績、変動するものはレンジ、未知は固定価格前のdiscoveryを使います。その後、残った不確実性だけにcontingencyを付けます。これで他人の一般論ではなく実際の案件の形を反映した数字になります。

説明もしやすくなります。顧客に内部確率をすべて見せる必要はありませんが、『定義済みscope、明示した仮定、特定統合の不確実性に対する管理された余裕を含む』と説明できます。余裕に理由があり、不確実性を先に消せば小さくできる可能性もあります。

• 繰り返し作業には自分の履歴平均を使う
• 不確実なタスクには三点見積を使う
• 幅が大きい未知には有料discoveryを使う
• すべての行ではなく特定リスクにcontingencyを付ける
• 承認後の新scopeには変更プロセスを残す

毎案件の後に見積時間と実績時間を比較する

最終請求額だけ保存しても見積は改善しません。納品後、タスクカテゴリごとに見積と実績を比較します。10時間超過という情報は、10時間がどこから来たか分からなければ弱いものです。実装か、レビューか、顧客判断の遅れか、デプロイか、完全に忘れていたコミュニケーションか。総額は『外した』と教え、カテゴリは『なぜ』を教えます。

大きな差には短い理由を残します。時間がたつとパターンが見えます。コーディングは10％以内だがコンテンツ準備は毎回2倍、決裁者が3人いる案件は修正が増える、特定インフラは公開に時間がかかる、などです。これは自分の仕事と顧客に関するデータなので、一般的なネット記事より価値があります。

再利用する見積テンプレートをその証拠で更新します。完璧な予言が目的ではありません。記憶と楽観への依存を減らすことです。プロでも外しますが、外れをデータに変えます。同じカテゴリが3回超過したなら、4回目の見積は必ず変えるべきです。

実例：40時間の案件が61時間になるまで

小規模サイトを例にします。デザイン8時間、実装32時間で40時間の見積を出し、実績は61時間でした。反射的には『開発が遅かった』と思いますが、記録を見るとdiscovery 4時間、顧客対応5、コンテンツ整理4、テスト3、デプロイと引き継ぎ2、追加修正3がありました。元の制作見積はほぼ合っていて、案件全体の定義が間違っていたのです。

より良い見積は、discovery 4、デザイン8、実装32、コミュニケーション4、コンテンツ準備4、QA 3、引き継ぎ2、含まれる修正4として納品システム全体を数えます。リスク余裕なしで61時間です。魔法はありません。制作だけを案件と定義するのをやめた瞬間、抜けていた時間が見えただけです。

大事なのは質問を変えることです。『主なものを作るのに何時間か』だけでなく、『受入済みで実際に納品された状態まで何の作業が必要か』と聞きます。後者の数字なら事業を運営できますし、会話、レビュー、納品も予定に入るため顧客のスケジュールも現実的になります。

• 制作だけでなく納品までの全経路を見積もる
• 自信の中に隠さず不確実性に名前を付ける
• 依存関係と仮定を見積に結び付ける
• 見積と同じカテゴリで実績時間を取る
• 前案件の学びで次の見積を更新する