ノウハウ2026年5月6日

「フェーズが終わっても予算が半分残る」という状態を作った方法

プロジェクト終盤に「予算が足りない」と気づくのは、本当に苦しい状況です。

私がプロジェクトリーダーとして受託開発に携わっていた頃、何度かこの状況を経験しました。「設計が思ったより長引いた」「実装で想定外の仕様変更があった」——後から振り返ると原因はいくつも出てきますが、プロジェクト進行中はその兆候に気づけていませんでした。

この記事では、そういった状況を防ぐために実践してきた「フェーズ単位の予算管理」について整理します。

なぜ予算超過は「終盤に発覚」するのか

予算超過が終盤まで気づかれない最大の理由は、進捗確認の単位が大きすぎることです。

「プロジェクト全体で予算が残っているか」という視点だけで管理していると、設計フェーズが予算を食いすぎていても、実装フェーズが始まるまで問題として浮かび上がりません。

フェーズをまたぐたびに工数が積み上がり、実装が終わる頃には「テストに使える工数が残っていない」という状態になる——これが典型的なパターンです。

解決策は単純で、フェーズごとに「予算の何%を消化したか」を把握できるようにすることです。

具体的な手順を説明します。

プロジェクト全体の見積もりを「フェーズ単位」に分解します。

たとえばトータル100時間のプロジェクトであれば：

という配分を最初に決めます。この配分が「各フェーズの予算」になります。

実際の作業はタスクレベルで時間を計測します。重要なのは、タスクが「どのフェーズ・成果物に属するか」が分かる構造で記録されていることです。

タスクの実績時間がフェーズに集計される仕組みがあると、「設計フェーズ：見積もり25時間、実績18時間（72%消化）」という状況をリアルタイムで確認できます。

各フェーズが終わったタイミングで、計画と実績を比較します。

フェーズをまたぐたびに、次フェーズの計画を実績ベースで更新する——このサイクルが「予算超過を終盤まで気づかない」状況を防ぎます。

タイトルにある「フェーズが終わっても予算が半分残る」という状態は、設計フェーズに割り当てた工数の半分以下で設計が完了したケースです。

これを経験したのは、設計フェーズに「バッファを厚めに見ていた」案件でした。実際の設計作業は想定より早く進み、設計フェーズを終えた時点で見積もり工数の45%しか消化していませんでした。

このとき、残った工数をどこに使うかを意識的に決められたのは、フェーズ別の消化率を見ていたからです。「浮いた工数を実装のリスクバッファに回す」という決断ができ、後半のプロジェクトを余裕を持って進められました。

逆にいえば、「プロジェクト全体で何時間残っているか」しか見ていなければ、この余裕に気づけなかったかもしれません。

フェーズ別に工数を管理すると、状況の共有もしやすくなります。

「今、設計フェーズの工数を80%消化しています。このペースでいくと、残り20%（5時間）で設計を完了させる必要があります」という伝え方は、「設計が遅れています」よりも具体的で、メンバーが行動しやすい情報です。

問題の発見が早まり、対策の議論も数字ベースで行えるようになります。クライアントへの進捗報告でも、「フェーズAは予算の75%を消化して完了しました」という伝え方は、根拠がある分だけ信頼につながります。

また、複数人で進めるプロジェクトでは「誰がどのフェーズに時間を使っているか」の把握にもフェーズ別の記録が役立ちます。特定の担当者に工数が偏っている場合、早期に再配分の判断ができます。

フェーズ別管理を実践するなかで気づいたことがあります。見積もりは「プロジェクト開始前に作って完成するもの」ではなく、「実績に基づいて更新し続けるもの」だということです。

実装フェーズに入った時点で、設計の実績工数が確定します。その数字を使って「残りのフェーズ（テスト・納品）に使える工数は何時間か」を再計算し、必要なら計画を修正します。

このサイクルを回すためには、フェーズ別の実績が数字として取り出せる状態が必要です。「なんとなく進んでいる気がする」という感覚管理では、このサイクルは回りません。

「全体では順調に見えるのに終盤で詰まる」パターンを断ち切るのは、フェーズという粒度で工数を見ることです。

本記事で取り上げた「フェーズ別の工数管理」は、LayerClock でも対応しています。 4階層WBS（プロジェクト・フェーズ・成果物・タスク）で作業を構造化し、タスクの実績時間が上位層へ自動集計されます。フェーズごとの消化率をリアルタイムで確認できる仕組みを、無料から試すことができます。