工数と期間の違い|レビュー・待ち時間を含めた見積もりの作り方

工数と期間|見積もりの基本:作業時間と待ち時間を分ける

「3人日だから3日でできますか」と聞かれたとき、そのまま肯定すると予定が崩れることがあります。人日は作業量、期間は開始から終了までの時間です。兼任、レビュー、回答待ちがあるなら、同じ作業量でも終了日は変わります。

見積もりを説明するには、一つの数字を出すより、作業量・稼働条件・待ち時間・不確実性を分ける方が役立ちます。以下の計算は説明用で、実案件の生産性や標準工数ではありません。

人日を日数へ変える前に、単位をそろえる

「1人日を何時間とするか」は組織の定義に合わせます。ここでは説明のため1人日=8時間とします。3人日なら24時間の作業量です。1日8時間をその仕事に使えるなら単純計算で3日、1日4時間なら6日の作業枠が必要です。

この計算には、休日、外部回答、作業の順序は含まれていません。「24時間÷1日4時間=6日」は終了日を確約する式ではなく、必要な作業枠を知るための計算です。

作成・確認・待ちを別に見積もる

申請フォームの設定を例にします。作成者と確認者は別人で、確認は作成後に行うと仮定します。

区分 作業量・時間 日程に置く条件
作成 16時間 作成者が1日4時間使えるため4日
自己確認・修正 8時間 同じ作成者が2日を確保
第三者レビュー 4時間 確認者が対応可能な日時を予約
指摘修正 4〜8時間の仮置き 指摘内容で再見積もり
承認待ち 作業量とは別 承認者から応答予定を確認
小さい画面では表を横にスクロールできます。

作成者の最初の作業量24時間だけを3日としても、兼任条件なら6日の枠が必要です。さらにレビューと修正の順序を置き、承認予定を確認して終了見込みを出します。待ち時間を「作成者の工数」に足すと、人員の負荷と日程の両方を誤解させます。

見積もりの根拠は、仕事の違いまで説明する

過去の似た作業を参考にするなら、今回との違いを確認します。項目数が同じでも、権限、例外、外部接続、承認者が違えば、作成・確認の負担は変わります。「前回も3日だった」だけでは根拠として弱くなります。

まだ仕様が揃っていないときは、幅で提示することもできます。ただし、「3〜10日」のような幅だけでは判断できません。何が確定すると幅が狭まるか、どの条件なら長くなるかを添えます。

説明用なら「既存認証を使える場合は設定・確認で24〜32時間。新しい認証連携が必要な場合は別見積もり。接続方式を確認してから確定する」と書けます。未確認の部分を、見積もりの中で確定済みに見せないことが重要です。

人数を増やしても、期間が人数分縮むとは限らない

24時間の仕事へ3人を投入すれば1日で終わる、とは限りません。分割できる作業か、共有する環境があるか、成果物を統合する時間が必要かを確認します。一人しか判断できない箇所や、前工程の結果を待つ作業は人数を増やしても短縮できない場合があります。

短縮案には「並行できる部分」「担当間の受け渡し」「追加の確認負荷」を記載します。応援を入れるまでの説明や権限付与も作業です。単純な割り算ではなく、成立する作業順序を作って比較してください。

予定を聞かれたときの回答を、条件付きで具体化する

作成と自己確認は計24時間を見込んでいます。
現在は兼任で1日4時間の枠なので、6営業日の作業枠が必要です。
その後のレビュー日時と指摘修正を含めて終了見込みを組みます。
認証方式が未確定のため、確認結果によって作業量を見直します。

これは曖昧な回答ではありません。数字の意味と、確定に必要な情報を明らかにしています。見積もりを更新するときは、見積もり時点・対象範囲・変更理由を記録し、当初の数字を書き換えて差分を消さないようにします。

予定と実績を比べる際も、作業量の超過なのか、作業枠の不足なのか、外部待ちなのかを分けます。原因によって、次に改善するのは分解方法、稼働の合意、承認経路のいずれかになります。

次に確認したい実務ガイド

PMO実務テンプレート・確認表の一覧から、目的に合う記事を探せます。

参考情報とこの記事の位置づけ

見積もりが時間・資源等を予測する活動である点の確認に使用。具体的計算は独自例です。 Atlassian:Project Estimation(確認日:2026年10月11日)。記入例・確認表は当サイトが説明用に作成したもので、実在の案件・実績ではありません。

週次報告書の書き方も必要な作業に合わせて参照してください。

アイキャッチ写真:Gabriel Cox / Unsplash。職場の実写ではなくイメージ写真です。

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!