プロジェクト進行のトラブルで、予算の問題って切ってもきれないですよね。
人・モノ・金、それらの管理が管理者には必要になるので、リーダーは逃れられない悩みを抱えていると思います。そういった悩みを抱えている方は、こちらの記事をどうぞ。
こんにちは！コンじゃぶろーです！
プロジェクトを成功に導くためには、多くの要素が重要ですが、その中でも「予算管理」は特に重要なポイントです。しかし、多くのプロジェクトがこの予算管理において、さまざまな障害に直面しています。なぜ予算オーバーは頻繁に起こるのでしょうか？その根本原因は何なのでしょうか？そして、最も重要なことは、これらの問題をどのようにして前向きに解決していくかです。
この記事では、プロジェクトの予算管理における一般的な課題を深堀りし、それらに対する実践的な解決策を提供します。受注側と発注側の両方の視点から問題を分析し、双方にとって最適な道を模索します。
プロジェクトの予算問題は、単なる数字の問題に留まらず、プロジェクト全体の運命を左右する重大な要素です。適切な予算管理は、プロジェクトの成功への道を切り開く鍵となります。では、具体的にどのようなアプローチを取れば良いのでしょうか？
本記事を通じて、プロジェクト予算管理の真の意味を理解し、実際の現場で直面するであろう問題に対して、具体的で実践的な対策を学んでいきましょう。
本日の記事、重要なポイント
- 予算オーバー、受注側と発注側の言い訳
- 「報告が遅れる」仕組みを再構築する
原因を探る：プロジェクト予算問題の真実
受けた仕事の予算を使い切ってしまったのは、いったいどちらの責任なのでしょうか？
答えは両方の責任です。
両方の責任というと反論が巻き起こりそうですが、
受注側は、技術力や提案力が低い証明にしかなりません。
発注側は、ディレクション能力が低い証明にしかならないからです。
愚か者が２人出会うと、交通事故になるというやつです。
ただ、ここで責任の所在を突き止めるだけでは意味が無いので、
問題が起きるメカニズムと、対策をまとめたいと思います。
お互いが歩み寄り、予定通り開発できる関係を築かなくてはいけません。
予算オーバーの根底にある誤解。受注側と発注側の異なる見解
仕事を受注する時。「〇〇円で、△△を作ります。」という契約を結びます。
要件書（案件書・案件概要・仕様書・設計図 等と呼ばれる事もある）で、何を作るかを決めた状態でスタートされます。
この「何を作るか」に関して、双方で認識が違うと、開発中に「予算オーバー」のトラブルが発生します。
ハンバーガーを２つ頼んで、ハンバーガーが１つしか出てこなかったら怒られる。
簡単に言うと、こういうメカニズムです。
予定していたものが、予定していた内容・時間・価格で出来上がってこないという事ですね。
発注側と受注側で双方の言い分が食い違うと、トラブルに発展します。
まずは、双方の言い分を見てみましょう。
受注側の言い分
受注側の言い分を言い出したらキリがないですが、よくあるモノをまとめてみます。
- 予算不足：もともと少ない予算で仕事を受けていた。
- 要件変更：途中で発注側から仕様変更があった。
- あいまいな要件：もともと、何を作るかあいまいだった。
たいていの言い分は、発注側の責任である事を訴えたモノです。
しかし、どれも受注側の方で解決できる問題だったりします。
契約書においても受注側は、発注側より立場が弱いので、上記理由のほとんど受注側の責任として取り扱われる事が多いです。
なので、「とても報告しずらい」ので、ごく自然に発注側への報告が遅れる仕組みになっています。
受注側でイイワケできないケース
受注側でさえ、これは「いいわけ」が苦しい・・・というものもあります。
多くは、技術力が低い等の理由で「品質」が悪いパターンです。
- 対応漏れ：作る予定だったモノが、完成していない。
- 人不足：作っているメンバーが、予定通り入れず・・・。
- 品質：不具合が多くて・・・まだ動いていない・・・。
さすがに受注側の責任なので、報告できず困り果てる状況になります。
こちらも、報告ができずにズルズルひっぱり、報告が遅れやすくなります。
発注側の言い分
受注側だけではなく、発注側の言い分もしっかりまとめる必要があります。
- できるって言ったからお願いした。
- いきなり無理と言われても対応できない。
- 予算を追加と言われても、今更そんな事を上に報告できない。
- 完成予定日は決まっているから、変更できない。
すべて「契約する前に言ってよ」という内容になります。
予算オーバーの報告は、たいてい納期ギリギリになって「もう無理」となった時に露見します。
契約書がある以上、発注側からしたら「作ってくれ」にしかならないんですが、
その結果「受注側」が逃走してしまっては余計にひどい状況になります。
双方の言い分をぶつけ合うと、トラブルにしかならない
受注側と発注側の言い分を見ていると、喧嘩にしかならない事が分かると思います。
ただ、いかなる理由があろうとも、基本的に発注側の方が強いので、受注側は「対応してくれ」で済まされる場合もほとんどだと思います。
なおさら、受注側は報告しづらくなっています。この状況だと、発注側もギリギリまで気づけなくなります。
不毛な争いを続けて困るのは、発注側なので、ここの仕組みをどうにかしなくてはいけません。
受注側の挑戦と解決策
受注側からの、報告が遅れないようにするにはどうすれば良いでしょうか？
双方からの対策が必要です。
問題なく開発を進めるのは、「お互いの責任である」という意識を、受注側と発注側が持つ事が大切です。
そして報告しやすい環境づくりをしなければいけません。
スケジュール管理の重要性とその方法
受注側がしなければいけない対策は、発注側が抱く「ストレス」を減らす努力です。
いかなるサービスも、お客様の「ストレス」をいかに減らすかが大事になります。これは受注側の、最低限のマナーになります。
受注側で考えなければいけないのは以下の通りです。
- スケジュール管理する
- 発注者への報告
- 品質管理する
受注側の対策 １．スケジュール管理
スケジュールの目的は、問題が起きた時に、すぐその事に気づく事です。
スケジュール表を作る事が目的ではありません。
スケジュール管理する上で、よくあるスケジュール見直しタイミングと注意点をリストアップします。
- 見積もり時
- 開発スタート時
- 開発中の作業遅れ
- 要望対応（追加仕様発生時）
受注側の対策 １-1． スケジュール管理 変更タイミング：見積もり時
まだ、案件が発生するかどうか分からないタイミングです。
あまり時間がかけれない為、片手間で見積もる事も多く見積もり者のセンスが非常に大切になります。
トラブルを防ぐ為には、見積もり者１人の責任にしない事と、開発が確定した時に、開発メンバーと協力してスケジュールを作るのをおススメします。
見積もり時の注意点が、開発メンバーに伝わりづらいからです。
伝達ミスで見積もり時の想定と、開発したモノがかけ離れている事は、普通に発生します。
受注側の対策 １-2． スケジュール管理 変更タイミング：開発スタート時
見積もり時のスケジュールを、信用してはいけません。
忙しい中で見積もりをしている事が多いので、たいてい精度が低いです。さらに、対応する予定の人員によって得意不得意があると思います。
現実的で具体的なスケジュールを組んで、しっかり作り直しましょう。
もし、この時点で予算オーバーしているなら、関係者を集めて対策が必要です。
決して、見積もりが正しいという前提で進行しない事が大切です。
受注側の対策 １-3． スケジュール管理 変更タイミング：開発中の作業遅れ
開発中に作業遅れが発生したら、必ず予算オーバーになります。
グループで共有して、必ずどうリカバリーするかを話し合いましょう。
話し合ったら、スケジュールを更新します。
スケジュールが最新になっていないと、作業遅れが発生した事にも気づけなくなります。
受注側の対策 １-4． スケジュール管理 変更タイミング： 要望対応（追加仕様発生時）
発注側から要望が発生した場合は、一つずつ「対応する」「対応しない」の判断をして下さい。
「対応する」場合は、発注側を巻き込んで、「どう対応する」かを決めて下さい。
全て、想定外の対応なので、１つでもそれは予算オーバーです。
ついつい、現場の担当者が「対応する」と判断してしまいがちだったりしますが、そうならないようにメンバー内の意識を統一してください。
対応方法の意識を統一していないと、「Aさんが対応した内容を、Bさんが削除する」こういう事が発生します。
受注側の対策 2． 開発の各段階における対応戦略
何か大きな問題が発生した場合は、発注者へ報告するルールを決めておきましょう。
報告は、まめにした方がいいです。
できるならば、「報告したらOK」では無くて、「何が起きて」「どういう」影響が起きるのかを誤解無く説明してください。そして、「どう対応するか」を含めて報告するようにしましょう。
ここで重要なのは、発注側を「不安」にさせない事です。
「不安」がうむのは、「要望」です。
雑に報告をすると、未来の時間を奪う事になります。
ただ、「不安」を取り除く為に、「嘘」の報告をするのはNGです。
危険な橋は渡らないようにしましょう。
受注側の対策 3． 品質管理と予算コントロール
開発中に、途中の状態を見せるタイミングを用意して、完成形のイメージを、発注側に伝えるという事に意識してください。
品質が低くて困る事はとても多いです。
発注側が「不安」に感じない程度に、品質をコントロールする努力をしましょう。
- 途中の品質を見せる
- 不具合を減らす
いつ、途中の状態を見せるかを、事前に発注側と決めるようにしましょう。
そして、不具合は発注側が不安に感じる要素です。不具合が発生しづらい作りにしたり、デバッグをしっかりするようにしましょう。
発注側の視点：期待と現実のギャップ
発注側がしなければいけない対策は、話がしやすい関係づくりです。
言いづらい事を、言いやすい関係にするのは、発注側の腕の見せ所になります。
高圧的に、奴隷のように無理やりやらせるのは、コンプライアンス的にかなりやばい物があります。
新しい開発会社に仕事をふる際は、初期コストがかなり高くなってしまいます。
進捗管理や品質管理のやり方、納品方法に関しての理解に時間がかかるからです。
案件をこなす度に、開発会社から逃げられていては、この初期コストばかりかかってしまいます。
なので、「仕事をあげてやっている」という意識はもたない方がいいです。
まとめ：予算問題を解決へ導く実践的アプローチ
何かを作る時は、発注側も受注側もお互いに「不安」を感じにくい環境づくりに努めなくてはいけません。
そういう意味で、「予算オーバーで作れない」は、少し乱暴な対応になります。
受注側は無責任ですし、発注側はそれを言わせないように、お互いが報告しやすい環境をつくらなくてはいけません。
そもそも「予算オーバーでは作れない」と言っても、言われても、モノは完成しません。
受注側は、発注側が最高だと思うモノを作り、発注側が追加予算を払いたくなるような状況にした方がいいと思います。
発注側から、要望がたくさん出てくるというのも、発注側の不安の表れです。
品質に不安があるから、要望を出しているわけです。
「要望が多いから・・・」と言った時点で、受注側の提案力や技術力が無いと言っているようなモノなので、予算のイイワケはしない方がいいですよというお話でした。
以上、さしあたり、今思う事でした。
ここまで読んでいただけてありがとうございます。
皆様の良い人生の一助になれば。
コメント