プロジェクトの残工数を予測する：完了時工数（EAC）の考え方
プロジェクトの途中で「このまま進んだら、最終的に何時間かかるか」を答えられますか。
「設計が終わった時点で予算の40%を使ってしまった。残りの工程は本当に60%で収まるのか」——この問いに感覚ではなく数字で答えられるかどうかは、プロジェクト管理の質に大きく関わります。
EAC（Estimate at Completion：完了時工数）は、その問いに答えるための概念です。難しそうに聞こえますが、考え方はシンプルです。この記事では、EACの基本と実務での使い方を整理します。
EACとは何か
EACは「現時点の実績ペースで進み続けると、プロジェクト完了時点の総工数はいくつになるか」を推計する数字です。
たとえば、100時間で完了する予定のプロジェクトがあるとします。全体の40%の作業が終わった時点で、実績工数が50時間だったとします。
このとき「予定では40時間で40%終わるはずだったのに、実際には50時間かかった」という事実が見えます。
残り60%の作業も同じペースで進むとすると、完了時の総工数は次のように推計できます。
EAC = 実績工数 ÷ 進捗率 = 50 ÷ 0.4 = 125時間
当初の見積もりは100時間でしたが、現在のペースで進むと125時間になる、ということです。この数字が出るのがプロジェクトの中盤であれば、まだ対処する時間があります。
EACが「感覚の予測」と何が違うのか
「このままいくとまずいな」という感覚を持つことはできます。しかし感覚には再現性がなく、他の人に伝えられません。
EACが有用なのは、「何時間オーバーする可能性があるか」という予測が数字として出るからです。
- 「設計フェーズのペースが想定より遅い」という感覚
- vs「設計フェーズの進捗ペースで計算すると、プロジェクト全体でEACが150時間になる。当初見積もりより50時間多い」という数字
後者があると、クライアントへの説明・スコープの見直し・追加工数の交渉という次のアクションが取れます。感覚のままでは、「なんとかなるかもしれない」という先送りが起きやすくなります。
EACを使った「早期警戒」の仕組み
実務でEACを使うとき、特に有効なのは「フェーズ終了ごとに計算する」アプローチです。
要件定義フェーズが終わった時点で、「実績工数 ÷ 進捗率」を計算します。ここでEACが当初見積もりを大きく上回っていれば、「設計フェーズ以降を見直す必要がある」という判断が早期にできます。
逆に、EACが見積もりを下回っていれば「想定よりスムーズに進んでいる、後半のフェーズに余裕が生まれる」という判断もできます。
フェーズをまたぐたびにEACを計算するサイクルを作ることで、プロジェクト終盤の「予算が足りない」という発覚を、プロジェクト中盤の「このペースでは予算が足りなくなる」という予測に変えられます。
EACを計算するために必要なもの
EACを計算するためには、2つの情報が必要です。
1. 実績工数（どこまでに何時間かかったか）
タスクレベルで時間を計測し、それがフェーズ単位で集計されている状態が必要です。「今日まで合計何時間使ったか」だけでなく、「設計フェーズに何時間使ったか」という情報が取り出せる構造でなければなりません。
2. 進捗率（全体のどのくらいが終わっているか）
進捗率の計測は難しい部分です。「タスクの完了数 ÷ 総タスク数」という方法が一般的ですが、タスクの大きさが均一でないと正確な進捗率は出ません。
実務的には、「見積もり工数のうちどのくらいを消化したか（消化率）」を進捗率の代わりに使う方法もあります。「設計フェーズの見積もり30時間のうち、実績が20時間 → 設計フェーズは67%消化」という考え方です。
フェーズ別の見積もり消化率でEACを簡易計算する
「進捗率」を正確に出すのが難しいとき、フェーズ別の消化率を使って「このフェーズは予算内で収まりそうか」を確認するだけでも十分実用的です。
たとえば：
- 設計フェーズの見積もり：30時間
- 設計フェーズの実績（フェーズ終了時）：42時間（140%）
設計フェーズで見積もりの140%かかったということは、残りのフェーズでも同じ傾向が続くとすれば、プロジェクト全体でも140%かかると予測できます。
- 当初の見積もり：100時間
- EAC（推定）：100時間 × 1.4 = 140時間
「40時間のオーバーが予測される」という数字が出れば、クライアントへの説明や見積もりの修正を早めに動けます。
オーバーは続くのか、今回だけか ― EACの2通りの読み方
ここまでの式には、実は隠れた前提があります。「いまのペースが、この先も同じように続く」という前提です。設計で140%かかったから、残りも140%かかるだろう、と。
でも現場では、そうとは限りません。超過には二種類あって、どちらだと見るかで先の読み方が変わります。
ひとつは、続くタイプ。見積もりの立て方そのものが甘い、自分の作業が構造的に遅い——原因がこの先のフェーズにも当てはまるなら、崩れは繰り返します。このときは、これまでのペースをそのまま伸ばすのが素直です。
- EAC = 実績工数 ÷ 消化率
- さきほどの例なら、40%終わって50時間 → 50 ÷ 0.4 = 125時間
もうひとつは、今回だけタイプ。序盤にだけ仕様変更が集中した、特定のメンバーが一時的に抜けた——超過の原因が一過性で、残りの工程には持ち越さないと見るなら、超過ぶんは飲み込んだうえで、残りは当初の見積もりどおり進むと考えます。
- EAC = 実績工数 ＋ 残りの当初見積もり
- 同じ例なら、すでに50時間使っていて、残り60%ぶんの当初見積もりは60時間 → 50 ＋ 60 = 110時間
同じ「40%終わって50時間」でも、続くと見れば125時間、今回だけと見れば110時間。15時間の幅が出ます。
私は、どちらか一方に決めきらず、この幅のまま持っておくのがいいと思っています。「最悪125、うまくいけば110」と幅で言えると、報告の相手にも判断の余地を渡せる。そして次のフェーズが終わったら、また両方を引き直す。フェーズをまたぐたびに幅が狭まっていって、終盤には一点に近づいていきます。どちらの数字が実際に近かったかを後から見れば、自分の超過が「続くクセ」なのか「事故」なのかも見分けがついてきます。
あといくら残っているか ― ETC と VAC
EACが「最終的にいくつになるか」なら、そこから派生する数字が二つあって、報告のときに地味に効きます。
ETC（残作業見込み）＝ EAC − 実績工数。「あと何時間残っているか」です。125時間の予測で、いま50時間使っているなら、残りは75時間。予算やスケジュールの相談は、総額のEACより「あと75時間」のほうが話が早いこともあります。
VAC（完了時差異）＝ 当初見積もり − EAC。「当初からどれだけずれる見込みか」で、マイナスなら超過です。100時間の見積もりでEACが125時間なら、VACは −25時間。この一つの数字で「25時間ぶんの超過が見えています」と切り出せます。
名前は仰々しいですが、どちらも引き算ひとつです。EACを一つ出しておけば、残りも差分もその場で言える、というだけの話です。
EACを「精度の改善」に使う
EACはプロジェクト進行中の管理ツールとして有用ですが、プロジェクト終了後に使うことでも価値があります。
プロジェクトが終わったとき、「当初の見積もり」「実際のEAC計算値（フェーズ終了時に推計していた最終工数）」「実際の完了工数」の3つを比較します。
- EAC計算値と実際の完了工数がどのくらい近いかを確認する → EAC計算の精度を評価できる
- 当初見積もりとEAC計算値がどのくらい乖離していたかを確認する → どのフェーズで見積もりが甘かったかを特定できる
この振り返りを繰り返すと、「自分はどのフェーズでEACが大きくずれる傾向があるか」が見えてきます。それが次のプロジェクトの見積もり補正材料になります。
結局、EACの使いどころ
整理すると、EAC（完了時工数）がやっているのは「現在のペースで進むと最終的に何時間かかるか」を推計することだけです。式は実績工数 ÷ 進捗率で、進捗率が出しづらければ見積もりの消化率で代用しても十分実用になります。これをフェーズが終わるたびに計算しておくと、プロジェクト中盤の段階で「このままだと足りない」を察知できる。終わってから実績と突き合わせれば、自分がどのフェーズで読みを外しがちかも見えてきます。
EACというと「大きなプロジェクト管理の手法」という構えたイメージがあるかもしれませんが、やっていること自体は割り算ひとつです。難しいのは計算ではなく、その前提になる「フェーズ別の実績」がちゃんと残っているかどうかで、私の経験では躓くのはたいていそちらでした。
関連記事
本記事で取り上げた「完了時工数（EAC）の予測」は、LayerClock でも対応しています。 フェーズ別の工数実績を自動集計し、現在のペースをもとにした完了時工数の予測をリアルタイムで確認できます（Businessプラン）。無料プランで記録の仕組みを整えてから、試してみてください。