ENGINEER エンジニア 2026.11.07

工数見積もりの型｜時間で見積もる人と成果で見積もる人

開発作業の所要時間だけを数えると、要件確認や検証、納品後の修正負担が抜けやすい。見積もりで説明できる範囲を明確にし、契約…

text: HYPE編集部

開発作業の所要時間だけを数えると、要件確認や検証、納品後の修正負担が抜けやすい。見積もりで説明できる範囲を明確にし、契約後の赤字と認識違いを減らす。予約ページなら「閲覧者が空きを見る」「日時を選ぶ」「確認メールが届く」までを画面遷移で描き、管理者の予約変更やキャンセル対応は別の行にする。実装対象を画面単位で示せば、見積りの段階で発注者が不足機能を指摘できる。

Table of Contents

最初に成果物を言葉にする

機能名だけでなく利用者、操作、入力、出力、納品形式を一組にする。予約機能でも管理画面とメール通知の有無で対象が変わる。

見積もりは、作業を分解してから工数を置くのが基本です。調査・設計・実装・確認を分けると、抜けが見えてきます。

作業を分解して工数を置く

調査、設計、実装、テスト、レビュー、デプロイ、説明資料に分解し、それぞれ前提条件と担当を記す。

既存システムの調査、画面設計、API接続、例外処理、端末別確認、公開作業を別行にし、各行へ見積時間と依存する資料を記す。レビュー待ちを開発時間と同じ箱に入れず、顧客承認が必要な工程には承認日を置く。

工数分解を課題として練習できる開発教材なら、見積表の粒度を磨きやすい。体系立てて学びたい場合は、Webスキルを学ぶオンラインスクールデイトラのようなオンラインスクールも選択肢になります。

時間見積もりと成果見積もりの違い

時間は作業量の把握に強いが依頼側には価値が伝わりにくい。成果基準は目的を伝えやすいが範囲の境界が欠かせない。

時間型では調査ログや作業明細を提出し、成果型では「何ができれば検収か」を具体化する。たとえば商品一覧の速度改善なら測定環境を、予約機能の完成なら正常系とエラー系の動作を先に合意する。

分からない部分は、固定金額に混ぜないこと。調査を別枠にすると、後からの揉めごとが減ります。

不確実性を別枠にする

外部APIや既存コードの品質が未確認なら固定金額に混ぜず、調査フェーズや追加対応の条件を分ける。

古いプラグインや外部APIが絡む場合は、接続確認だけを先行調査として切り出す。調査後に追加費用が必要になったときの判断者と、進行停止の条件を見積書に付ければ、不明点を無理に固定価格へ押し込まずに済む。

見積書に含めるものと含めないもの

サーバー費、ライセンス、素材準備、データ移行、公開後の保守を含むか明記する。

ドメイン更新、ホスティング、メール送信費、画像購入、既存データ整理は制作費と支払先が異なり得る。見積書には「発注者が直接契約」「制作者が立替」「今回の対象外」を区分し、月次費用と一時費用も分ける。

費用範囲の整理を学ぶなら、サーバー・素材・移行費を分けた見積演習が役立つ。体系立てて学びたい場合は、Webスキルを学ぶオンラインスクールデイトラのようなオンラインスクールも選択肢になります。

見積書や、その後の請求書に何を書くかは、税の制度とも関わります。国税庁のインボイス制度の特設ページでは、適格請求書の記載事項などが案内されています。

変更依頼は差分で扱う

初回に決めた仕様に対し変更点と影響範囲を説明し、納期と金額を再協議する。

デザイン確定後に検索条件の追加が入った場合、変更前の仕様書と新要望を並べ、実装、試験、公開日に与える影響を示す。口頭で了承せず、差分見積と新しい検収項目に承認をもらってから着手する。

変更を差分で扱う発想は、制作物の変更履歴を残す運用とよく似ています。GitHub Docsの入門ページでは、変更を記録しながら共同作業を進める手順が案内されています。

クライアントへの説明方法

工数の多さを訴えるより、各工程がどんな事故や手戻りを防ぐかを説明する。

テスト工数を説明するときは「確認します」で終えず、決済失敗時の表示、フォームの未入力エラー、スマートフォンの表示など具体的な確認画面を挙げる。各工程が防ぐ不具合を発注者が選択できる形にする。

工程ごとの検収条件まで説明する課題を選ぶと、顧客への提案を具体化できる。材料を広げるなら、雑誌のオンライン書店 Fujisan.co.jpで専門誌を読む方法もあります。

終わった案件の実績は、次の見積もりの材料です。想定との差を記録しておくと、精度が上がっていきます。

見積もりの根拠を説明するとき、取引条件をめぐる社会の動きを押さえておくと、話が価格だけに寄りません。中小企業庁の中小企業白書・小規模企業白書では、価格転嫁や取引条件が中小企業の課題として取り上げられています。

実績を次回の見積もりへ戻す

実績時間と想定時間、修正理由を案件終了時に記録し、再利用できる見積もり台帳を作る。

工数台帳には当初見積、実作業、差分理由、仕様変更、顧客確認待ちを別列で残す。次の同種案件では「入力フォームの項目追加」の実績だけを参照し、前回と今回で違う外部連携は再調査する。

比較表で判断する

見積もりの軸	時間・工程	成果・納品条件
得意な場面	調査や不確実な作業	要件が固まった制作
注意点	成果の説明が必要	範囲変更を明確にする

自分の仕事と売上にどうつなげるか

具体的には「予約フォームを作ってほしい」という依頼を受けたら、まず予約完了までの画面と送信通知の行き先を書き出す。管理者の取消操作が必要なのか、既存の顧客台帳と連携するのかも確認する。そのうえで作業見積と成果物の検収条件を別の欄に書く。開発中に「キャンセル待ちも追加したい」と言われた場合には、元の機能一覧に追加した行を示して、テスト範囲と納期を説明できる。これが単なる値引き交渉ではなく、追加する価値を説明するための土台になる。