予算を使いすぎていることに気づくのは、たいてい使い終わった後です。
私がそれをやったのは、月次の集計だけで予算を見ていた頃でした。毎月、経理から出てくる数字を確認して、問題なさそうなら次の月に進む。この運用だと、8月に使いすぎたことが分かるのは9月の中旬です。その時点で打てる手はほとんど残っていません。
この記事では、コストを見える化すると言ったときに、具体的に何を、どの粒度で、どの頻度で見るのかを書きます。予算管理がなぜ必要なのかという入口の話はプロジェクトの予算管理の重要性の方にあります。
目次
1. 月次で見ていると必ず手遅れになる
冒頭の話の続きを書きます。
ある案件で、実装が想定より難航して、メンバーが残業で吸収していた時期がありました。私はその状況自体は把握していたのですが、それが金額としていくらになっているかは見ていませんでした。
翌月に集計が出てきて、その月だけで想定の1.4倍ほど使っていたことが分かりました。しかも、遅れは解消していません。つまり、翌月も同じペースで使う見込みが立っている状態でした。
このとき困ったのは、対策を打つ余地がすでに小さくなっていたことです。予算の半分以上を消化した後でスコープを削る交渉をするのは、着手前にやるのとは難易度がまったく違います。顧客からすれば、こちらの都合で後から範囲を減らす話でしかありません。
問題は使いすぎたことではなく、使いすぎていることを知るのが遅かったことでした。見える化というのは、要するにこの遅れをどこまで縮められるかという話だと思っています。
2. 何を見るか：金額ではなく工数から入る
システム開発の案件では、費用の大半が人件費です。私が関わる規模だと、7割から8割はここになります。
ということは、金額を追いかけるより工数を追いかけた方が早いです。工数はその週のうちに分かりますが、金額になって出てくるのは締めた後だからです。同じものを見ているのに、片方はリアルタイムで、もう片方は1か月遅れます。
具体的には、次の三つを見ています。
- 消化工数：これまでに何人日使ったか。
- 残工数：残りの作業を終えるのに何人日かかる見込みか。
- 残予算工数：予算の残額を人日に換算するといくつか。
大事なのは二つ目です。消化した分だけを見ていると、「予算の6割を使って進捗も6割だから順調」という判断になりますが、これは残りの4割が計画通りに終わる前提です。難航している案件では、この前提がすでに崩れています。
残工数を毎回作り直すと、進捗率では見えなかったズレが出てきます。予算の6割を使った時点で、残りの作業に予算の7割分の工数が要ると分かれば、そこで手が打てます。
正直なところ、残工数の再見積もりは面倒です。メンバーに聞いて回る必要があるので、心理的にも軽くありません。ただ、ここを省くと結局は締めてから気づくことになります。
3. クラウド費用は放っておくと見えなくなる
人件費の次に効いてくるのがクラウドの利用料です。これは人件費と逆の性質があって、誰も作業していなくても増えます。
私が経験した中で一番間抜けだったのは、検証用に立てたGPUインスタンスを止め忘れていたケースです。学習が終わった後もそのまま起動していて、数週間気づきませんでした。作業としては何も進んでいないのに、費用だけが積み上がっていたことになります。
この種の支出は、月次の請求書を見るまで表に出てきません。しかも請求書は名目でしか分かれていないので、どのプロジェクトの分なのかが判別できないことも多いです。
対策として今やっているのは次の二つです。
- プロジェクト単位でタグを付ける。どの案件がいくら使っているかを分離できる状態にしておきます。これをやっていないと、そもそも見える化の対象になりません。
- 金額でアラートを設定する。想定の月額を超えたら通知が飛ぶようにしておきます。閾値の設定は雑でよくて、気づくのが早くなること自体に価値があります。
どちらも最初に一度やれば済む作業です。それでも設定を忘れたまま走り出す案件が今もあるので、キックオフ時のチェック項目に入れるようにしました。
4. どの頻度で見るか
結論としては、週次に落ち着きました。
日次は続きません。試したことがありますが、数字の更新にかかる手間に対して、日単位で分かることが少なすぎました。工数は日によってぶれるので、毎日見ると判断を誤ります。
月次は前述の通り遅すぎます。1か月分の使いすぎが確定してからしか分からないので、気づいた時点で選択肢が減っています。
週次だと、使いすぎに気づくまでの遅れが最大1週間に収まります。そして週次の定例がすでにあるなら、そこに数字を持ち込むだけなので運用の追加コストもほぼありません。私の場合は、リスクの確認と同じ場でまとめて見ています。この定例の組み立て方についてはリスク管理の重要性：ITプロジェクトでのベストプラクティスにも書きました。
5. ツールを入れる前に決めること
予算管理のツールはいろいろありますが、入れれば管理できるようになるわけではありません。
私の経験では、ツールを検討し始める段階で失敗しているケースがあります。「何を見たいか」が決まっていないままツールを選ぶと、入力の手間だけが増えて、出てきた画面は誰も見ないという結果になります。実際、導入したものの3か月で使わなくなった管理ツールがあります。
先に決めるべきなのは、次の三つだと思います。
- 見る項目：消化工数、残工数、クラウド費用など、判断に使う数字を絞る。
- 見る頻度：いつ、誰が見るのか。既存の定例に載せられるか。
- 入力する人と手間：誰が数字を入れるのか。その人にとって現実的な手間か。
これが決まっていれば、正直なところ表計算ソフト一枚でも足ります。私が今使っているのも、実質的には共有スプレッドシートです。規模が大きくなって手作業が破綻してから、ツールを検討すればいいと思っています。
なお、予算の情報は外に出していい種類のデータではないので、外部サービスを使う場合はデータの保存先とアクセス権限は確認しておく必要があります。
6. まとめ
コストの見える化でやることを整理すると、こうなります。
- 金額ではなく工数を見る。金額は締めた後にしか出てこないので遅い。
- 消化工数だけでなく残工数を見る。進捗率だけでは、残りが計画通りに終わる前提を検証できない。
- クラウド費用はタグとアラートで分離する。作業していなくても増えるため、人件費とは別の仕掛けが要る。
- 週次で見る。日次は続かず、月次は遅い。
- ツールより先に、見る項目と頻度を決める。
私がやった失敗は、どれも「見ていなかった」のではなく「遅れて見ていた」ことが原因でした。見える化の目的は、正確な数字を出すことではなく、気づくのを早くすることだと思っています。
予算管理がなぜプロジェクトマネージャーの仕事なのかという話はプロジェクトの予算管理の重要性に、試行回数と計算リソースで費用が読みにくくなる機械学習案件の事情は機械学習プロジェクトにおける予算管理の成功要因に書きました。予算を含めた管理全体の枠組みはITプロジェクトマネジメントの基礎とその重要性を参照してください。