予算不足でプロジェクトを頓挫させないための心得

 ITプロジェクトマネージャ(以下PM)が職務の遂行上で遭遇するトラブルは、予算の不足、スケジュールの遅延、テクニカル的な障害、プロセス上の問題、感情的な対立など、その一部を挙げるだけでもきりがない。このうち予算の不足はPMが経験する最も普遍的な問題であり、これを解決するキーポイントは具体的な問題点が何処にあるかを特定することにある。その次の手順は、候補となるいくつかの対策を講じることであり、可能であれば予算不足そのものを解消する手段を見つけるという運びになるはずだ。

自ら質問を設定することで自分でその答えを見つけよ

 最初に設定すべき質問は、問題の発生時あるいは顕在化する前の段階にて行うものであり、それは「予算は誰が決めているのか?」というものである。つまりプロジェクト外部の人間から指定された予算枠なのか、それともプロジェクトマネージャである自分自身が必要な要件を判断した結果なのかということだ。

 次に確認すべきは、プロジェクトの現実性が出発段階から失われていないか、そして全体的なコスト分析は既に完了しているのかである。また既存の類似プロジェクトをベースとしているのかも確認し、そうであれば現行プロジェクトに固有の部分を特定しておく。ここで注意すべきは、厳密なものにせよラフなものにせよ、推測という行為は往々にして予算問題を引き起こす原因となるという点である。

 誰かが重要な情報の見落としないし計算違いをしていないか? また予算を組む際に、上層部からの了承を得やすくする目的で、最小限の見積もりを採用しなかっただろうか? 予算不足を引き起こした過去または現在の原因は、装置、人員、試験、開発などのどの分野に属すか、ないしはこれらが複合化しているのか? こうして問題の発生している場所が特定できたら、次に行うのはその修正である。

 こうした問題に対する解決策の1つは、言うまでもないが予算の追加である。新たな追加予算ないしは資金提供者を確保できれば問題は即座に解決されるはずだが、よほど重要なプロジェクトで強力な後ろ盾を有す場合でもなければ、追加予算を確保できる可能性は非常に限られているだろう。あるいは運がよければ、当初予算の中にPM裁量の予備費が組み込まれているかもしれない。そうであれば、今がそれを使うべき時期である。そうでない場合は、今回の出来事を教訓として次回の予算編成時には予備費を確保しておくようにすべきである。

現実的なソリューション

 予算の追加が不可能であれば、その他の部分を変更するしかない。まず最初は不可欠でない要件から削っていくが、必須の要件でもプロジェクトを破綻させないものであれば削除の対象とすべき場合もあるだろう。どのようなプロジェクトであれ、削除(あるいは後日のバージョンアップやアップグレード時までの延期)をして構わない要件はたいてい存在しているはずである。こうした要件については優先順位付けをして、最も優先度の低いものから削るようにする。

 PMとしては、技術的に適したより安価なソリューションがあれば、それを利用したいところだろう。サーバの変更やオープンソース系ソフトウェアの採用など、コスト削減につながる他のアプローチを選んだとしてもプロジェクトを成功に導くことができるかもしれない。またスパイラル(spiral)やアジャイル(agile)といった開発手法を適用することが役立つ場合もあるだろう。こうした措置によりプロジェクトを成功に導く方針が定まり、評価に値する成果を残すことができれば、次のフェーズまたはバージョン開発時に予算の増額が認められるかもしれない。

 装置の購入については、その見直し、延期、中止を一通りは検討すべきであろう。同様に大幅な人員削減をするという選択肢も存在するが、これら2つのオプションはスケジュールの遅延をもたらすであろうし、長期的に見ればプロジェクトの成功を困難にする危険性が生じてくる。よって可能であれば、過去に行った開発成果の再利用や、他のプロジェクトで購入したハードウェア/ソフトウェアの転用ができないかを検討すべきである。別プロジェクトの開発成果や備品で役立ちそうなものがあれば、素直に便乗させてもらうのも1つの方法だろう。その際に相応の金銭的負担を強いられるかもしれないが、丸ごと購入するよりは安価に済むはずだ。

 その他にも取り得る選択肢は各種存在しているが、そうしたものは宝くじを買う程度の成功率しか期待できなかったり倫理的な一線を越えるようなものが多い。現実的なオプションとして推奨できるのは以下のようなものとなるが、これらの大部分は規定の予算枠に収めるための措置であり、予算の超過分を補填するという性質のものではない。

  • 負担に見合うだけの予算追加が行われない限り、新規の要件を増やすスコープクリープ(scope creep)を許してはならず、仮に何らかの補償がなされる場合でも、そうした状況の発生は積極的に抑制しなければならない。スコープクリープや仕様の変更は、徐々にではあるがプロジェクトを蝕んでいくことになるからだ。些細な変更を1つ許すとそれは他の変更を呼び込むことになり、最終的にはプロジェクトが抜き差しならない事態に追い込まれ、完成した製品は当初に予定していたものと非常にかけ離れたものに変質する羽目になってしまう。確かにある程度の柔軟性は必要であり、特にそれは時間とともにカバー範囲が広がる性質のプロジェクト運営に当てはまる話である。ニーズやテクノロジの変化、関連ベンダの新旧交代、予算の増減、カスタマ要件の変質、企業体制の再構築などは常に起こり続けるものであって、そうした変化に対応することは不可避だが、プロジェクトで扱う要件の変更は最小限に留めるよう努めなくてはならない
  • 何らかの形でアーンドバリューマネジメント(Earned Value Management)の手法を取り入れてコストを追跡し、予算計画との突き合わせをできるようにしておく。アーンドバリューマネジメントとは、プロジェクトの進捗度合いを客観的に計測する方法の1つで、出来高管理システムとも呼ばれている。そして A)現状の達成分をコストに換算した値、B)そこに配分されていた予算、C)実際に消化した予算を比較するのである
  • 今後の運営コストを推定し、変化に応じて見直しをする。そのためには継続的なモニタリングが不可欠である。そうした措置を施し続けない限り、気づかない間にコストは増加していくものであり、プロジェクトをトラブルに陥れることになる
  • 複数のタスクを統合することでコストを削減し、不要な作業にリソースを食われないようにする。削減や統合できるタスクがあれば、そうすることで時間やリソースを切りつめることができるはずである。ただしこのアプローチでは1つの落とし穴に注意しなければならない。それは不可欠な部分まで削ってはいけないということだ。そうした部分での1円の節約は往々にして100円の出費となるからである
  • “金メッキ”の施された要件に手を出すなというのは、雇用する人材や購入する器具だけではなく、プロジェクトの“成果物”そのものについても当てはまる警句である。ここで言う金メッキされた要件とは、金メッキの装飾をした浴室の備品のようなものであり、つまり必要な機能は満たすがそれ以上の無駄を伴うという存在を指す。例えばあるプロジェクトで1台のラップトップマシンが必要になったとしよう。その要件は必要時にネットワーク接続をするだけの簡易ラップトップで済むというのに、野外での使用に耐える堅牢性と無線機能および大量のメモリを装備したハイエンドラップトップを購入したとすれば、それは無用な金メッキを施したことになる
  • 意思決定にあたっては費用便益分析を参考にする。またその際の意思決定は慎重に進めて、想定外の現象やコストが生じていないかを見逃さないようにしなければならない。感情に流されて判断を誤るのは禁物である
  • まず最初に状況を正しい方向に整理しておかないと、動き出した後での変更は予算的にも時間的にも無駄を生じさせることになる。この件に関しては、これ以上の説明は不要だろう
  • 契約業者や外部ベンダから提出された予算関係の書類は、間違いがないか必ず精査をする。意図的な不正を働こうとする者は少ないにしても、人間はミスをするものであるから、それがプロジェクトで賄えきれないほどのコスト増を招くかもしれない

スタート地点に立ち返る

 ここで、自分が予算配分を決定する立場にあったらと想像してみよう。そうした責任を負わされた人間にとっては、構築するのが当初予算であれ次年度予算であれ、その現実性が非常に重要な意味を持つはずだ。このような観点に立脚して考えると、予算計画は次のような3種類を組んでおくことが好ましいと言える。その1番目は、プロジェクトで使用するすべての要件を賄えるだけの“ドリームバジェット”であり、余裕があるなら欲しいレベルの要件や不測の事態に備えた予備費までを一切合切含めたものとしておく。

 2番目の予算は、プロジェクトの遂行に不可欠という基準で組んだものであり、つまりは最も実現性の高い要求である。通常こうしたものは先のドリームバジェットよりも少額になるはずだが、プロジェクトを進める上で必須ないしはそれに近い出費を賄えるようにしておかなくてはならない。ただしその中には、不測の事態に備えたある程度の予備費も含めておく必要がある。

 最後にくる3番目の予算は、プロジェクトを存続させて最小限の成果を上げられるギリギリ最低の金額である。そうした想定はPMとしては願い下げのはずだが、最悪の事態にも備えておかなくてはいけない。

まとめ

 マネージャと名の付く職務はいずれ劣らず大変なものだが、その中でもITプロジェクトのマネージャは最も負担の大きい部類に属すだろう。果たすべき仕事の量は膨大であるにもかかわらず、充分な時間や予算が与えられることはまずもってないからだ。そしてプロフェッショナルなPMであるならば、予算問題にも冷静に対処しなければならない。予算の不足は誰しもが経験する事態であるが、そこでパニックに陥ったり性急な決断を下すのは禁物である。そうした場合こそ本稿で提示した対策を実施する時なのだが、そこで自己完結してはいけない。

 自分が率いるチームのメンバにしろ、あるいは外部の人材にしろ、役立つものが得られるのであれば提案やサポートを求めるべきである。また、自分より経験が豊富な人間や、同様のトラブルに遭遇した人間と意見を交換するのも有益である。あるいは関連書籍やリサーチで情報を収集するのもいいだろう。問題解決をテーマとした既刊書や記事の中には予算関係を扱ったものも豊富に存在しているはずだ。いずれにせよ自分が管理するプロジェクトで発生した予算不足のソリューションを見つけるには、自分で設定できる質問に自分で出した答えを基に、自分に許される自由度、自分自身およびチームとしての創造力、自分が遭遇した問題の深刻度、そして自分のPMとしての管理能力を総合して検討しなければならないのである。

Wayne Turkはフリーランスのプロジェクト管理コンサルタントであり、Suss Consulting社と提携している。退役空軍中佐として現在は防衛関係の業務に携わっており、米国防総省を含む政府機関および営利/非営利組織の求めに応じて、情報技術プロジェクトや政策展開および戦略立案プロジェクトのサポートを務めてきた経験を有す。

ITManagersJournal.com 原文