自分をごまかさずにフリーランス案件の工数を見積もる方法

時間を見積もる前に成果物を定義する

ウェブサイト、キャンペーン、連携、リニューアルといった曖昧な名詞だけでは、根拠のある見積もりは作れません。まず、ページ、状態、形式、連携、対応端末、提供されるコンテンツ、承認手順、受け入れ条件など、観察できる結果を定義します。

各成果物について、完了とは何かを短く書きます。二人の合理的な人が完成しているかどうかで意見を分けられるなら、まだ見積もれるほど具体的ではありません。予算を使い切ってから議論するより、今明確にする方が安く済みます。

• 何をどの形式で納品するか
• クライアントが何をいつまでに提供するか
• 対応する端末、ブラウザ、プラットフォーム
• 含まれる案、バリエーション、修正回数
• 見積もりから明示的に除外するもの

検証できる小ささまで作業を分解する

成果物を通常1〜8時間程度のタスクに分けます。「アプリを作る、60時間」というタスクは仮定を隠しすぎます。認証、アカウント状態、フォーム検証、レスポンシブレイアウト、分析、デプロイはそれぞれ別に見積もって確認できます。

繰り返し可能な作業と不確実な作業を分けます。既存のコンポーネントライブラリで作るページと、ドキュメントのない外部連携は同じリスクではありません。一つの数字にまとめると、既知の作業が未知の作業を補助することになります。

不確実なタスクには三点見積もりを使う

意味のある不確実性があるタスクでは、楽観値、最頻値、悲観値を記録します。実用的な加重式は、期待時間 = (楽観 + 4 × 最頻 + 悲観) ÷ 6 です。

たとえば、資料とアクセスが正しければ4時間、通常は8時間、APIの挙動が悪ければ20時間かかる連携を考えます。加重見積もりは9.3時間です。この式は不確実性を消しませんが、楽観ケースがいつの間にか正式な計画になるのを防ぎます。

悲観ケースがプロジェクトを破綻させるなら、単なるパーセントに隠してはいけません。固定総額を約束する前に、有償ディスカバリー、時間制フェーズ、あるいは判断ポイントを提案します。

見えない作業とクライアント依存を数える

制作時間は納品全体の一部にすぎません。ディスカバリー、会議、進捗連絡、ファイル準備、フィードバック確認、テスト、アクセシビリティ確認、引き渡し、デプロイもキャパシティを使います。必要な作業なら見積もりに含めます。

依存項目には責任者と期限が必要です。アクセスやコンテンツ待ちは請求時間を生まない場合がありますが、納期を遅らせ、コンテキストスイッチのコストを増やします。入力が遅れた場合に何が起きるかを明記し、スケジュールが現実に影響されないふりをしないでください。

• ディスカバリー、調査、要件の明確化
• プロジェクト管理と集約されたクライアント連絡
• コンテンツ準備、移行、データ整理
• 品質保証、アクセシビリティ、端末テスト
• 含まれる修正、デプロイ、引き渡し
• 直接費と専門外注

実例：小規模なウェブサイト更新

5ページのサイト更新に、ディスカバリーと構成4時間、デザイン10時間、実装22時間、コンテンツ入力と品質確認8時間、コミュニケーションと引き渡し5時間、含まれる修正ラウンド5時間が必要だとします。定義済み作業は合計54時間です。

CRM連携はまだ不確実です。三点見積もりが4、8、20時間なら期待値は9.3時間です。この不確実なタスクだけに20%の固定価格バッファ、1.9時間を追加します。計画合計は約65時間であり、54時間でも、適当に丸めた70時間でもありません。

内部ではタスク別見積もりを保持します。クライアント向け提案には成果物、前提、含まれる修正、価格、スケジュールを示します。時間は意思決定の根拠であり、毎回の見積書に法廷記録のように付ける必要はありません。

完了した案件を次の見積もりデータに変える

見積もりと同じタスク分類で実績時間を記録します。納品後に、差の原因をメモします。要件の曖昧さ、クライアントの遅延、技術的な想定外、やり直し、あるいは単純に楽観的すぎた見積もりなどです。

複数案件を終えたら、一般的なバッファを自分の実績レンジに置き換えます。実装は予測しやすいが、コンテンツ準備や承認は不安定だと分かるかもしれません。これは有用な運用データであり、ネットで「サイト制作は何時間かかるか」と聞くよりはるかに価値があります。

• 案件全体だけでなくタスクごとに見積時間と実績時間を比較する
• 重要な差異の原因を記録する
• 納品後に再利用タスクテンプレートを更新する
• 大きな見積もりは約束前に別の専門家にレビューしてもらう