「気づいたら予算オーバー」を防ぐ ― フェーズ単位で“このままいくと”を読む
プロジェクト終盤に「予算が足りない」と気づくのは、本当に苦しい状況です。
私がプロジェクトリーダーとして受託開発をしていた頃、これを何度も味わいました。やっかいなのは、進行中にまったく気づかないわけではない、ということです。「設計、ちょっと押してるな」「なんとなく今回きつそうだな」——薄々は感じている。でも、それが“数字”としてはっきりするのは決まって期末や締めのタイミングで、その頃にはもう打てる手が限られている。毎回そこで大慌てになる、というのが実態でした。
この記事では、その“なんとなく”を、まだ動けるうちに“数字”に変えるための、フェーズ単位の見方を整理します。
なぜ予算オーバーは「手遅れ」で発覚するのか
理由は大きく2つあると思っています。
ひとつは、**そもそも進行中に見ていない（見えづらい）**こと。日々の作業に追われていると、いま全体の何%を使ったかを立ち止まって確認する機会は、なかなかありません。仮に確認しようとしても、工数がフェーズや成果物に分かれて集計されていなければ、ぱっと見では分からない。結果、危険は「なんとなくヤバそう」という“感覚”のまま、明確な問題として浮かんでこない。そして感覚は、行動を起こすには弱すぎます。
もうひとつは、見るときの単位が大きすぎること。「プロジェクト全体でまだ予算が残っているか」だけで管理していると、設計が予算を食いすぎていても、全体ではまだ余って見えてしまう。フェーズをまたいで工数が積み上がり、実装が終わる頃に「テストに使える時間がない」と発覚する——この“感覚のまま手遅れ”が、典型的なパターンです。
裏を返せば、対策は「まだ動けるうちに、感覚を数字に変える」ことに尽きます。しかも見るべきは「このフェーズの予算を何%使ったか」だけではありません。全体の何%を消化していて、このままのペースだと最終的にどこへ着地するか——そこまで見えて初めて、「今動けば間に合う／このままだと足りない」という判断ができます。
フェーズ別予算管理のやり方
具体的な手順を説明します。
ステップ1：フェーズごとに工数の見積もりを割り当てる
プロジェクト全体の見積もりを「フェーズ単位」に分解します。
たとえばトータル100時間のプロジェクトであれば：
- 要件定義：10時間
- 設計：25時間
- 実装：50時間
- テスト・納品：15時間
という配分を最初に決めます。この配分が「各フェーズの予算」になります。
ステップ2：タスクレベルで実績を計測する
実際の作業はタスクレベルで時間を計測します。重要なのは、タスクが「どのフェーズ・成果物に属するか」が分かる構造で記録されていることです。
タスクの実績時間がフェーズに集計される仕組みがあると、「設計フェーズ：見積もり25時間、実績18時間（72%消化）」という状況をリアルタイムで確認できます。
ステップ3：途中と区切りで「消化率」と「着地見込み」を見る
ポイントは、フェーズの終わりだけでなく、途中でも消化率を確認することです。たとえば設計の見積もり25時間に対して実績が20時間（80%）なら、まだ設計は終わっていないのに残りは5時間しかない、とその場で分かります。「見ていないから手遅れになる」を防ぐのは、この“途中で見る”習慣です。
- 設計が見積もりの90%を超えたら、実装フェーズの計画を見直す
- 設計が50%で終わったら、浮いた工数をどこに回すか考える
さらに、フェーズの実績が出るたびに「このままいくと全体でどうなるか」を一度引き直します。設計が見積もりの1.4倍かかったなら、残りのフェーズも同じ傾向と仮定して全体の着地を概算する。「全体100時間の予定が、このペースだと130時間」という見込みが中盤で出れば、まだ打つ手があります（この“着地の読み方”は完了時工数（EAC）の記事で詳しく扱っています）。
見えていれば、「余った」ときにも動ける
消化率を見る価値は、足りないときだけではありません。逆に“余った”ときにも効きます。
ある案件で、設計フェーズにバッファを厚めに積んでいたことがありました。実際の設計は想定より早く進み、フェーズを終えた時点で見積もりの半分も使っていなかった。このとき「浮いた工数を実装側のリスクバッファに回す」と意識的に決められたのは、フェーズごとの消化を数字で見ていたからです。おかげで後半を余裕をもって進められました。
「全体でまだ何時間残っているか」しか見ていなければ、この“余り”には気づけなかったはずです。数字で見るというのは、危険を早く察知することであると同時に、使える余白を見つけることでもあります。
工数の見える化がチームコミュニケーションを変える
フェーズ別に工数を管理すると、状況の共有もしやすくなります。
「今、設計フェーズの工数を80%消化しています。このペースでいくと、残り20%（5時間）で設計を完了させる必要があります」という伝え方は、「設計が遅れています」よりも具体的で、メンバーが行動しやすい情報です。
感覚で「遅れています」と言うと、相手は「頑張って」としか返せません。けれど「設計を80%消化、残り5時間で終える必要がある」と数字で言えば、「ではレビューを1回に減らそう」「この機能は次フェーズに送ろう」という具体的な相談に変わります。数字は、責任追及ではなく“次の一手”の話に空気を変えてくれます。
問題の発見が早まり、対策の議論も数字ベースで行えるようになります。クライアントへの進捗報告でも、「フェーズAは予算の75%を消化して完了しました」という伝え方は、根拠がある分だけ信頼につながります。
また、複数人で進めるプロジェクトでは「誰がどのフェーズに時間を使っているか」の把握にもフェーズ別の記録が役立ちます。特定の担当者に工数が偏っている場合、早期に再配分の判断ができます。
見積もりを「一度作ったら変えないもの」にしない
フェーズ別管理を実践するなかで気づいたことがあります。見積もりは「プロジェクト開始前に作って完成するもの」ではなく、「実績に基づいて更新し続けるもの」だということです。
実装フェーズに入った時点で、設計の実績工数が確定します。その数字を使って「残りのフェーズ（テスト・納品）に使える工数は何時間か」を再計算し、必要なら計画を修正します。
このサイクルを回すためには、フェーズ別の実績が数字として取り出せる状態が必要です。「なんとなく進んでいる気がする」という感覚管理では、このサイクルは回りません。
途中で見積もりを引き直すのは、「最初の読みが外れた」と認めるようで、少し気が引けるものです。私も昔はそうでした。けれど実際は逆で、実績が出た時点で計画を直せるのは、むしろプロの動き方だと思っています。最初の見積もりは“いちばん情報が少ない時点での仮説”でしかありません。情報が増えたのに更新しないほうが、よほど不自然です。
結局、「感覚」を「数字」に変えるだけ
長くなったので要点だけ。予算オーバーが手遅れで発覚するのは、進行中は“なんとなくヤバい”という感覚のままで、それが数字になるのが期末や納品間際だからです。やることは、その感覚をまだ動けるうちに数字に変えること——フェーズに予算を割り当て、途中と区切りで消化率を見て、実績が出るたびに「このままいくと全体でどうなるか」を引き直す。これだけで、終盤の大慌てははっきり減りますし、その数字はそのままチーム共有やクライアント報告の根拠にもなります。要は、見積もりを「一度作って終わり」にせず、実績で書き換え続けるということです。
「全体では順調に見えるのに終盤で詰まる」パターンを断ち切る手は、結局この粒度で“見る”こと以外にあまり思いつきません。とはいえ私自身、忙しくなるとフェーズ終わりの確認をつい飛ばしてしまうので、ここは仕組みで強制するくらいでちょうどいいと思っています。
関連記事
本記事で取り上げた「フェーズ単位で先を読む工数管理」は、LayerClock でも対応しています。 プロジェクト→フェーズ→成果物→タスクの4階層で作業を構造化し、タスクの実績が上位の工程へ自動集計されます。フェーズごとの消化率と全体の進み具合をリアルタイムで確認できるので、“なんとなくヤバい”を数字にしてから動けます。無料から試すことができます。