見積もりの工数表の作り方｜根拠を見せる技術
工数表の「実装20時間」という数字だけでは、顧客はその作業が何を含むか理解できない。見積もりの説得力は計算の細かさより、…
text: HYPE編集部
エンジニアの記事一覧へ工数表の「実装20時間」という数字だけでは、顧客はその作業が何を含むか理解できない。見積もりの説得力は計算の細かさより、成果物と前提条件の関係で決まる。仕様が曖昧な仕事をどう分解し、変更に備えるかを具体的に考える。
成果物から作業を分解する
Web制作なら画面設計、実装、確認、公開作業を分ける。作業名を「開発一式」にすると変更時の議論が難しい。
ウェブサイト改修の見積もりなら「制作一式」とまとめず、要件整理、画面設計、実装、試験、公開準備などに分ける。個々の工程に成果物を対応させると、顧客は何に時間が必要か理解しやすい。タスクを細かくし過ぎると表が読めなくなるため、判断が必要な粒度でまとめる。作業の抜けがないか納品範囲から逆算する。
前提条件を工数に結びつける
原稿支給の有無、デザイン確定日、検証環境、承認者の人数で作業量が変わる。見積もりの欄外に前提を明記する。
同じ画面数でも既存コードの状態や確認者の人数で工数は変わる。提供される原稿、デザインの確定状況、外部サービスの接続、テスト環境の有無を書き出す。前提が未確定な部分は仮置きとして明示し、変化した場合に再見積もりする条件を設ける。相手に都合の良い最小工数だけを提示すると後の説明が難しくなる。
体系立てて学びたい場合は、Webスキルを学ぶオンラインスクール デイトラのようなオンラインスクールも選択肢になります。
前提条件が変われば、同じ成果物でも必要な作業は変わります。厚生労働省のフリーランス取引に関するガイドライン案内も参照し、取引条件を明示する考え方を工数表の前提欄に反映しましょう。
不確実性を隠さない
外部APIや既存コードの調査が必要なら調査工程を分ける。未知の問題まで確定額に押し込まない方が信頼につながる。
外部APIの仕様確認や未知の不具合は、作業開始時点で確定できないことがある。調査を先行工程として切り出し、そこで得られる情報に応じて次の作業範囲を決める方法がある。リスクを隠した一律の時間ではなく、確定している作業と不確実な作業を表で分ける。追加作業が発生したときの承認手順も用意したい。
レビュー回数を決める
修正をどの工程で受けるか決め、仕様変更と不具合修正を区別する。契約前に言葉の定義を共有しておく。
顧客が複数部署に確認する案件では、レビュー待ちと制作作業を分けて計画する。誰がいつまでに何を確認するか決まらないと、担当者が待機する時間を見積もりへ反映しにくい。初稿後の軽微な修正と仕様変更を同じ扱いにせず、認識合わせの会議や再試験の工数も考える。合意した回数を超えるレビューは別協議にする。
公開や納品の環境を整えるなら、レンタルサーバー エックスサーバーのようなレンタルサーバーも候補になります。
工数と価格を混同しない
作業時間は説明資料の一つで、価値や責任まで単純に比例するものではない。見積もりでは成果物と品質条件を併記する。
作業に必要な時間をそのまま販売価格にすると、設備費や管理費、事業継続のための利益を無視しやすい。工数表はまず作業量と範囲を説明する資料として使い、価格設定には固定費や責任範囲も考慮する。作業単位の値引きを求められたら、単価だけを下げるのではなく、対象機能や確認工程を見直せないか検討する。
価格の検討では、作業時間だけでなく、事業として継続できる収支の見通しも必要になります。日本政策金融公庫の創業計画書に関する案内は事業計画を組み立てる際の資料として公開されており、数字を計画へつなぐ視点が参考になります。
実績との差を次回に活かす
完了時に予測と実績の差を記録する。手戻りか技術調査かを分ければ、単価だけを下げずに見積もり精度を改善できる。
案件終了後は予定と実績を比較する。要件確認が長引いたのか、実装が難しかったのか、レビューで変更が重なったのかを分ける。単純に「次回から多めに取る」とするのではなく、見落としていた工程を明らかにしたい。顧客にも説明可能な見積根拠が増えれば、次の商談で納期や費用の協議を進めやすくなる。
学んだことを仕事につなげる入口として、スキルマーケット ココナラで小さな案件から始める方法もあります。
見積と実績の差を残すときは、個別案件の感想だけでなく、次回に使える条件の違いまで記録することが大切です。中小企業庁「中小企業白書・小規模企業白書」のような公的資料も、事業環境を振り返る材料として活用できます。
工数表に載せる列を選ぶ
項目、作業内容、前提、想定工数、確認者、除外範囲を並べると、数値の意味を説明しやすい。API連携なら認証方式が確定しているか、既存の仕様書が使えるかを前提欄へ記載する。調査して初めて分かる項目には確定値を置かず、着手前に再確認する事項として分ける。工数表の合計と見積金額が一致するかより、表の説明と契約の範囲が矛盾しないことを確かめたい。
顧客の確認作業が必要な工程には、制作側だけの作業時間を入れて終わらせない。返答待ちで納期が変わる場合は予定表へ反映する。仕様変更が見積条件を超える場合の手順を明確にすると、案件の途中で予算の話をしやすくなる。
見積もりの説明で避けたい誤解
工数が増えた事実と、価格を上げる必要性は同じ説明ではない。追加費用が必要なら、変更された仕様や新たに必要になった試験の範囲を示す。単に作業時間が長かったという理由だけでは契約変更の根拠にならない場合がある。
設計を固めないまま詳細な工数を要求されたら、確定している範囲と調査後に決める範囲を分けた提案を考える。未知の技術要件に一つの数字を当てるより、判断の段階を示す方法が役立つ。
時間単位で作業を積み上げても、待ち時間や関係者との調整が漏れると工程表は成立しない。レビュー担当者が別部署にいる場合は承認に必要な日数を作業時間とは別に計画する。
値引きの相談では成果物の縮小だけでなく、顧客側で原稿や素材を準備できるかも検討できる。ただし移管した作業の品質確認が必要なら、その負担を見積もりから消さない。
短い見積もりの会話で「簡単です」と言い切ると、既存データの確認やテストの時間が見落とされやすい。作業の難易度を判断する前に、どの環境へ実装するのか、変更で既存機能へ影響しないかを調べたい。調査を契約前にどこまで行うかも仕事の範囲であり、無制限に無償対応する前提にしない方がよい。
仕事と売上につなげるための判断
工数表を添えた見積もりは、顧客が予算を削るときにも優先順位を決めやすくする。金額を調整するなら何を制作対象から外すか明確にし、必要な試験まで安易に削らない。案件後に実績を記録していけば、次の受注時に根拠のある説明ができるようになる。
出典
CTA
仕事の取り方や単価の決め方で迷ったら、HYPEへご相談ください。→ お問い合わせはこちら
※本記事にはプロモーションを含みます。
合わせて読みたい
つくる人の仕事のヒントを、週1で
新しい記事と、学び・案件のヒントをメールでお届けします。
RECOMMEND
注目のコンテンツ
