金融PMの予算管理実務：コスト超過を防ぐ体制とレビュー頻度の設計

「予算、あと3ヶ月でいくら残ってます？」と経営会議で聞かれて、即答できなかったPMを何人か見てきました。その場で数字が出せないと、それだけで信用を一気に失います。

結論から言うと、金融PMの予算管理でいちばん大事なのは、金額そのものを細かく追いかけることではなく「消化率と進捗率のズレを定期的に見る」ことだと僕は考えています。進捗に対して使い過ぎていないか、逆に使い切れずに遅れているかを、早い段階で掴む。この記事では、僕が勘定系刷新やBaaS導入のPMをやってきた中で体感した、予算超過の兆候の掴み方、超過が見えた後の実務対応、経営報告の組み立て方、そしてよくある失敗パターンまでをまとめます。予算管理は地味な業務ですが、炎上を未然に防ぐという意味では、進捗管理と同じくらい重要な仕事だと思っています。

0. 予算管理は「守り」ではなく「合意形成」の武器

予算管理というと、コストを削る、無駄を省く、という守りの仕事に聞こえるかもしれません。ただ実務でやっていることの中身は、もう少し違います。追加要件が出た時に「予算内でやるのか、追加予算を取るのか」を、感情論ではなく数字で経営層や業務部門と合意するための材料づくりです。予算表がしっかりしていれば、追加要件が出た瞬間に「これは当初スコープ外なので、追加予算がいくら必要です」と即座に言えます。逆に予算表が甘いと、なんとなく現場が無償で吸収してしまい、後から炎上する。僕が見てきた炎上案件の多くは、実は要件が膨らんだこと自体が問題ではなく、膨らんだ分の予算合意を取らずに突き進んだことが原因でした。予算管理がしっかりしているプロジェクトほど、追加要件への対応が早く、逆に揉めにくいというのが僕の体感です。

1. 金融PMの予算はなぜ簡単に超過するのか

金融システムの予算が超過しやすい理由は、僕の体感では大きく三つあります。一つ目は規制対応です。金融庁の検査指摘や監督局からの照会に対応するための追加開発が、プロジェクト進行中に降ってくることがあります。これは予算策定時点では見積れません。二つ目は多段階承認です。業務部門、システム部門、リスク管理部門、それぞれの承認を経るため、要件定義が確定するまでに時間がかかり、その間に前提条件（金利情勢、他システムの改修計画など）が変わって再見積りが必要になる。三つ目は外部委託比率の高さです。勘定系刷新のような大規模プロジェクトでは、開発工数の6〜8割程度を外部ベンダーに委託するのが一般的な体感値ですが、委託範囲が曖昧だと、契約変更のたびに追加費用の交渉が発生します。

この三つのうち、PMが手を打てるのは二つ目と三つ目です。規制対応は避けられないものとして、あらかじめ全体予算の5〜10%程度を予備費として確保しておく発想が必要になります。この予備費の割合は、プロジェクトの性質によって変わります。既存システムを大きく作り替える勘定系刷新は前例が少なく不確実性が高いので予備費は多めに、BaaS導入のようにパッケージやAPIをそのまま使う案件は前例が積み重なっているので予備費は少なめに、という調整をしています。実際に僕が関わったBaaS導入案件では、前例の多さを理由に予備費を全体予算の3%程度まで削って進めたところ、外部API提供元の仕様変更が入り、予備費だけでは吸収できず追加予算申請を1回挟むことになりました。前例があるからと予備費を削り過ぎるのも危険だという教訓です。

2. 要件定義フェーズで「凍結ライン」を作る

僕が予算管理で最初にやるのは、要件定義フェーズの終わりに「凍結ライン」を設定することです。凍結ラインとは、これ以降の要件変更はすべて追加予算申請の対象にする、という合意済みの基準線のことです。地方銀行の勘定系刷新プロジェクトに途中参画した時、要件定義フェーズが終わっても業務部門から「この機能も欲しい」という要望が途切れず、開発フェーズに入ってから3ヶ月で当初予算の約4割を追加要件対応に使ってしまっていた、という現場に出会ったことがあります。原因をたどると、要件定義フェーズの完了基準が曖昧で、「合意した」という認識が業務部門・開発ベンダー・PMOの三者で揃っていなかったことに尽きました。

そこから僕がやったのは、要件定義完了時点の合意事項を一覧化した「スコープ確定書」を作り、業務部門の部長クラスに押印をもらう、という地味な作業です。押印文化が残っている金融機関では、この一手間が効きます。押印以降の変更要望は、必ず「追加予算申請書」を通す運用に切り替えたところ、要望の数自体が3割ほど減りました。本当に必要な変更だけが上がってくるようになった、という感覚です。ただ、この運用には落とし穴もあります。別の案件では押印をもらった直後に気を抜いてフォローを現場任せにしたところ、2ヶ月後には口頭ベースの修正が積み重なり、申請書を通さない変更が10件近く溜まっていました。押印は起点にすぎず、月次で申請書を通した件数を突き合わせる運用まで含めて凍結ラインだと考えるべきだと反省しています。

3. 消化率と進捗率のギャップを毎月見る

凍結ラインを作った後は、月次のPMO定例で消化率（予算をどれだけ使ったか）と進捗率（工程がどれだけ進んだか）のギャップを見ます。理想は両者が同じペースで進むことですが、実務ではどちらかに偏ります。僕が目安にしている基準を表にまとめました。

この表はあくまで中規模の勘定系刷新プロジェクトを念頭にした目安です。BaaS導入のような数ヶ月単位の短期プロジェクトでは、月次ではなく2週間単位で見た方が実感に近くなります。期間が短い分、1ヶ月放置すると全体の3分の1が過ぎてしまうこともあるからです。また、このチェックは経理担当者だけに任せず、PM自身が必ず数字を見るようにしています。経理側の消化率と、現場が感じている進捗の実感には、ずれが出やすいからです。

4. 超過が見えたときの実務対応と経営報告

赤信号が出た時にPMがやるべきことは、原因の切り分けです。追加要件によるものか、ベンダーの見積り精度の問題か、それとも規制対応のような外部要因かを、まず整理します。僕が実務でたどっている流れを、所要目安つきで並べると次のようになります。

1. 赤信号の検知（当日〜翌日）：消化率と進捗率の差が20ポイントを超えたら、その場で原因調査を指示します。
2. 原因の切り分け（3営業日程度）：追加要件・見積り精度・外部要因のどれに当たるかをヒアリングして特定します。
3. 対応窓口の決定（1〜2営業日）：契約形態別に交渉先を確定させます。
4. 経営報告の準備（3〜5営業日）：過去プロジェクトの比較数字と更新後スケジュール案を作ります。
5. 経営報告と承認（次回の経営会議）：追加予算の承認と次回チェックのタイミングを合意します。

経営報告では、単に「予算が◯割超過しています」と言うだけでは判断材料になりません。僕が意識しているのは、同規模の過去プロジェクトとの比較を必ずセットで出すことです。例えば「今回の追加要件対応費は当初予算の4割相当ですが、3年前の別行での同種刷新プロジェクトでは2割相当でした。差分の主因は規制対応の追加開発です」というように、比較対象と定義をつけて説明する。数字だけを投げると、経営層は「PMの管理不足」と受け取りがちですが、比較と定義がセットになっていると、外部要因か内部要因かの判断がしやすくなります。もう一つ、経営報告の場でよく聞かれるのが「追加予算を承認したら、次はいつまでに終わるのか」という質問です。ここで曖昧な返事をすると、次の予算申請の説明力が一気に落ちるので、更新後のスケジュールと次に消化率をチェックするタイミングは必ずセットで出します。

5. よくある失敗パターンと対処

予算管理でPMがつまずくパターンは、僕の体感では三つに絞られます。一つ目は凍結ラインを作って運用しないパターンで、2章の失敗もこれに当たります。仕組みを作った直後がいちばん緩みやすいので、押印後1ヶ月は特に意識してフォローするのがおすすめです。二つ目は消化率だけを見て進捗率を見ないパターンです。消化率が健全に見えても進捗が遅れていると、後半にまとめて費用がかかります。二つの指標は必ずセットで見るのが対処になります。三つ目は予備費の存在を経営層に見せないパターンです。予備費の存在自体を説明していないと、いざ使う時に「なぜそんな予算があったのか」と疑問を持たれ、追加予算の説明がより難しくなります。最初の予算計画の段階で「これは規制対応など不確実性への備えです」と明示しておくのが、後々の説明コストを下げる近道だと感じています。

6. (結論)

金融PMの予算管理は、細かい費目を追いかける作業ではなく、要件定義フェーズで合意線を引き、月次（短期プロジェクトなら2週間単位）で消化率と進捗率のギャップを見て、超過が見えたら原因を切り分けて経営報告に落とす、という一連の流れです。特別なツールがなくても、押印文化を利用したスコープ確定書と、シンプルな消化率×進捗率のチェック表、そして凍結ライン運用のフォローさえあれば、実務としては十分に機能します。皆さんいかがでしたでしょうか。予算管理は地味な仕事ですが、炎上を未然に防ぐ一番手堅い武器だと僕は思っています。では今日もがんばりましょう。