“普通なら取れない”予算を確保する秘訣：失敗しない戦略実現術、プログラムマネジメント（4）（2/3 ページ）

[清水幸弥, 遠山文規, 林宏典，＠IT]

追加予算を依頼するための説得材料をどう作るか

　速水は、まず松本に「クラウドへの移行期間を3年とした場合／5年とした場合のキャッシュ・フローのシミュレーション」と、「その不足分を銀行借入で賄う場合の金利などの資金コスト」を算出してもらった。次に、営業部の丹羽、開発部の城田とともに、「当初期待していたクラウド化による効果」と、「5年かけてしまう場合のクラウド化の効果」を計算し、「5年かけることで得られなくなる分」を可能な範囲で金額に換算してもらった。こうして数値化された「ベネフィット」から資金コストを引いて「ベネフィットの総和」とした（図1）。

図1　速水が作った、ベネフィットからコストを引いた「ベネフィットの総和」。黄色の実線が3年計画、点線が5年計画のベネフィットを表す。ご覧の通り、パッケージ製品のクラウド版への完全移行を遅らせ、計画を5年間に引き伸ばすと、キャッシュフローは良化する。だが機能の充実が遅れる分、製品の競争力が低下する他、ターゲットである中堅中小企業の顧客獲得に出遅れるため、得られるベネフィットの総額は低下する

　速水は、さっそくできた比較表を深沢に見せにいった。満足する深沢の表情を思い描いていたのだが、速水が見たのは、意外にも渋い顔をする深沢であった。

深沢：「資金繰りとしては、これだけだと不十分だね。投資のタイミングについても考えないと」

速水：「タイミング、と言いますと？」

深沢：「例えば、開発が順調に進むことで予算が予定より早くなくなったり、営業がパイロット顧客から良い手応えがあって、開発を前倒しにしたいと考えたりしたとき、いつ追加の予算を調達するんだろう？ これについて会計の立場から言うと、現金は開発には極力使わず、借入金の返済に回した方がいいと考えているはずだよ。その方が金利は減るわけだからね。つまり、このメリットを上回るという確証が得られてからでなければ、予算増額要求には応じてくれないと思うよ」

速水：「なるほど……」

深沢：「だからといって、予算がたっぷりあったりするのも問題なんだ。例えば、何かがうまくいかなかった時も、軌道修正しないまま開発を進めてしまい、その結果、経費がかさんで最後に足が出る、といったこともあり得る。だから初めに『絶対必要な予算がどの程度で、どんな条件がそろったら追加の予算が下りるのか』について、あらかじめ合意を取っておくことが必要なんだよ。そうすることで、追加資金が必要になったときの手続きがやりやすくなるんだ。フェーズ＝ゲート法のことは知っているかい？」

速水：「自動車の開発などで使われている方法ですよね。確か、要所要所で全部門の代表が集まってデザインレビューをするっていう」

深沢：「そう。今回のプログラムは開発本部だけでなく、サービス、営業とチームを組み、それぞれが担当しているアクティビティを同時に進めていくわけだからね。要所にゲートを作っておいて、『次に進めるための条件が整っていること』を確認することが必要になる。こうした作業があれば、必要な予算を『会社にとっての必要経費』として確保しやすくなるんだ。もっと言えば、ゲート通過地点でのKPIの達成状況に応じて予算を増減できるような仕組みを作っておけば、無駄使いを抑えつつ、ベネフィットを最大化するチャンスを追求できる。当然、予算も確保しやすくなる」

速水：「なるほど……それに財務課にとっては、プログラムが各ゲートに達した時点で、追加予算額を変更することになったとしても、その理由についてはKPIを通じてチーム全体が責任を取ってくれることになる、というわけですね」

深沢：「その通りだ。まずは節目となるゲートをいくつか設定し、そのゲートに対して各KPIがどの程度、追加予算額と連動すべきかを、チームで確認するといいよ」

　速水は、再び財務課に掛け合い、主要スケジュールを基に、3年間の計画を3つのフェーズに分け、予算追加のタイミングについては以下の条件を取り付けた。

　「条件：ゲート1、2のそれぞれにおいて、『クラウド環境上にリリースした機能数』『Webアプリ開発の基本情報技術者数』『既存のライセンス版向けの仕事量 vs クラウド版向けの仕事量』『ターゲットとする中堅・中小企業の新規顧客数』が目標値に達していない場合、2年目分、3年目分の追加予算を半額とする」――

図2　プログラム全体スケジュールとゲート

　財務課と資金繰りの話がまとまったところで、速水は、「事業の位置付けと目的、前提条件、投資対効果、フェーズを含めた実行計画、実行体制、KPIなどを『事業提案書』としてまとめ、田村本部長や、社長の承認を得ておくように」と、深沢からアドバイスを受けた。事情が変わって予算やリソースの確保が難しくなった時に、事業を見直すために立ち返る「原点」とするためだ。この承認が下りれば、いよいよクラウド事業の正式スタートとなる。

資金繰りもプログラムマネジャーの仕事

　プログラムマネジメントの特徴の1つとして、「不確実な要素が残る状況の中、その時々の状況に対応しながらベネフィットを最大化する」ことが挙げられる。しかし一般に、組織において必要な予算を確保する際には、予算の総額に対して今後必要な経費を申請し、必要な金額の配分を受ける。通常業務や「プロジェクト」は、この「決められた配分予算」の中で運用する。従って「不確実性に対する臨機応変さが求められるプログラム」と、こうした「配分額を固定して執行する予算の枠組み」とのギャップは、プログラムマネジメント上、避けられない課題となる。

　ではどうすれば良いのか？ プログラムマネジメントでは、こうしたギャップがある中で必要な予算を獲得するための仕組みとして、「ビジネスケース」を作成することを提唱している。「ビジネスケース」とは、ひと言で言えば、「投資の費用対効果を示すストーリーないしシナリオ」であり、「ベネフィットに応じたコストの正当性を、定性的あるいは定量的に示すもの」である。

　ただ、プログラムマネジメントにおいてビジネスケースを作成する際には、予算を策定するとき、「必要経費の設定根拠に、あらかじめ不確実な要素を含ませておく」点が特徴となる。一般に、業務部門やプロジェクトチームが予算を策定する際には、不確実な要素に対して予備費を計上するだけだが、プログラムマネジメントでは、その「不確実な要素に掛かる経費」が、プログラムの進行に伴い、次第に明らかになっていくことを考え合わせて、必要な追加資金を想定しておくのである。

　このビジネスケースの作成で留意すべき点は以下の通りである。

1. ビジネスケースの前提条件
2. ベネフィットの受益者と、受益者から見て必要な金額
3. 受益者の費用負担に対する責任
4. 資金の調達方法
5. 想定済みの不確実要素（リスク／チャンス）と、KPIへの影響
6. 資金面でのマイルストン（ゲート）と、そこでの追加予定額
7. 追加予定額を増減させるKPIと、ゲートでの目標値

ベネフィットが増大するならば予算も増加可能

　こうした予算獲得のアプローチは、ベネフィットを最大化する上で不可欠なものとなる。というのも、「プロジェクト」の場合、スコープが決まった時点で予算は固定されている。従って、事業を推進する際、複数の選択肢があったとしても、その選択は予算に縛られてしまう。今回の A社のストーリーに当てはめれば、クラウド化という事業を「プロジェクト」として扱い、所与の予算内で実施することが求められていたら、「移行期間3年のスケジュール」という選択はできなかったはずだ。しかし、　「プログラム」の場合は、ベネフィットが増えるのであれば予算を増額しても良いと考える。プログラムの目的は、ベネフィットの最大化だからである。

　似たような話は個人でもある。例えば、一定の英会話力が必要となり、英会話教室に通うと決めたとしよう。1回当たりの料金は定額で、都合に合わせて回数・曜日を選べたとする。「友人を作りながら、気長に学習したい」なら、曜日を固定して週1回通うだけで十分だが、「半年以内に英語での面接試験にパスできなければ昇進の話が流れる」という場合は、時間さえあれば週2回以上は通った方が効果が上がる可能性が高い。この場合、「半年以内に昇進できれば、得られるベネフィットは大きい」と判断すれば、「たとえローンを組んででも通う回数を増やすべき」という選択肢もおのずと出てくる。しかし、これが「プロジェクト」のように予算が固定されている場合、「半年以内に昇進」というベネフィットが見えていても、「通う回数を増やす」という選択肢はそもそも選べないわけだ。

　ビジネスの場合も、少しの追加投資で大きな追加ベネフィットが得られる機会があり、なおかつ追加資金を獲得可能な場合は、積極的に活動すべきである。「予算ありき」の「プロジェクトマネジメント」的発想では、せっかくの好機をみすみす逃してしまいかねない。「ベネフィット重視」の「プログラムマネジメント」の視点でビジネスを捉えることは、財務面でも重要と言える。

　ただし、ベネフィットを見積もる際には、1つ大きな注意点がある。それは追加予算をもらうことによる「受益者は誰か」ということと、「受益者の費用負担に対する責任」を明確化することだ。前述した英会話の例のように、個人の問題なら話は別だが、企業の場合、複数の利害関係者が存在する。

　A社のストーリーで言えば、追加予算を投じて、クラウド化のスケジュールを早めることでメリットを得られるのは営業部だ。少しでも早くクラウド化できれば、クラウド版の販売に注力できたり、中小企業の市場開拓を急げるなど、さまざなメリットが得られる。だが、そうしたメリットは追加予算の増大と開発チームの貢献の下に成り立っている以上、当然ながら、“メリットを享受しただけの結果を出す責任”も求められるのである。従って、ベネフィットを見積もる際には、「メリットを享受した際の想定売り上げ額」など、それなりに根拠のある判断基準を使って、明確に数値化することが重要となるのだ。