費用増額の原因は過去にある | 見積に関する仮説検証ができているか
itpjstudy
プロジェクトの悩みの大きなひとつは、プロジェクトが進むにつれて、費用が増えていくことです。少なくないユーザ企業が、ITパートナからの増額提案を貰って、十分な納得ができずにモヤモヤしたまま契約にサインしているのではないでしょうか。
今回は、そういったプロジェクト費用の増額について、どのように向き合えばいいかについて、取り上げます。
増額の打診はいきなり来るが、増額の原因は過去に発生している
多くのユーザ企業にとって、ITパートナからの増額提案は突然の出来事だと思います。しかし、実際には、ユーザ企業も、「うまく行ってないな。ITパートナも、どんどん人員を増強していて、コストはどうなっているんだろう」と薄々気が付いていたはずです。
増額見積の前に、その予兆はあった。つまり、増額の原因は過去にあることがほとんどです。
費用増の原因例
- 要件定義や設計フェーズで、追加仕様が膨らんだ
- 関係者との調整・合意形成に、想定以上に時間が取られる
- チームが若手中心になってしまい、生産性が低い
- 実装の大きな方針転換があり、大きな手戻りが発生している
- ユーザ企業の要員不足を、ITパートナがカバーしている
など、様々な原因が考えれますが、たいていは工数増が直接的な原因です。そして、その工数増の原因は、想定していた見積前提が変わったことに起因することがほとんどです。
つまり、見積前提からの乖離が、費用増の原因になっているのです。
見積手順の理解が、見積増の原因理解にも役立つ
下記は、以前の回で取り上げた初期見積の基本的なステップです。当初の見積金額も、いきなり出てきたわけではなく、ステップを踏んで考えられてきたものです。
もし当初想定とは違って費用増額となったのであれば、この手順のどこかに想定違いがあったということになります。
なお、こういった想定があるのは、不思議なことではありません。プロジェクト開始前は、いろいろと分からないことも多く、さまざまな仮定をおいて見積をしています。つまり、この時点の見積は「仮説」にしかすぎません。
そのため、その仮説が正しかったのか、仮説検証をする必要があるのです。
タスク別×月別工数表は、状況を理解しやすい
この仮説検証を行う際に有用なのが、タスク別月別工数表です。
初期見積の際は、一足飛びに金額計算まで進むのは難しいため、見積前提確認 ➡ 工数試算 ➡ リソースプランに展開といった具合にステップを踏みました。しかし、再見積においては、初期見積時に立てた大前提がありますので、色々な要素を包含したタスク別月別工数表の運用が可能です。
タスク別月別工数表は、以下のようなイメージです。
タスクをあまり細かくする必要はありません。チーム別工数を少し分割するくらいで構いません。あまり細かくすると、管理・運用するのが大変になります。問題が潜んでいそうな場所を、ざっくり把握するためのものですから、粗くても大丈夫なのです。深掘りは、その後、範囲を限定して実施すれば良いのです。
タスク別月別工数表イメージ
時系列で見ることで、見えてくるものがある
そして、このタスク別月別工数表が力を発揮するのは、時系列で見比べたときです。それにより、状態変化がつかめます。状態変化をつかむことの重要性は、別の回でもお話しましたが、状態変化をつかめれば、「何かが起きている」ということが分かってきます。
なお、ユーザ企業側で、見積情報を更新することは大変ですので、ITパートナにやってもらいます。ITパートナ内では、自社の採算管理のため、たいてい毎月情報更新しています。そのため、どこまで開示してくれるかは、ITパートナ次第なところもありますが、依頼して構わない内容です。
ITパートナから定期的に、更新された工数表を出してもらう
下記は、そうやって見ることで発見できる気づきのイメージです。例えば、7月時点の工数表と8月時点の工数表を比較することで、前回見積に比べて「あるタスクの工数が増えた」「工数のピークが移動している」「新しいタスクが増えた」などに気づくことが出来ます。
時系列で見て発見できた気づきイメージ
気づきを得られれば、原因を深掘りしていくことができる
一番の問題は、何を深掘りして良いのか分からないことです。そうすると、モヤモヤしたまま、増額契約にサインすることになります。それでは、工数増を生み出した真の問題を解決することは難しいです。
大事なことは、まずは「気づきを得られる仕組みをつくる」ことです。
仮説検証は繰り返すことが必要
いろいろな確認をして再見積して、いったん予算の更新は終わります。しかし、それで終わってはいけません。
前述したように、見積は、あくまで見積前提にもとづく仮説でしかありません。そのため、数か月後には、想定外の状況がまた起きているかもしれません。そのため、プロジェクトが終わるまで、この仮説検証を繰り返すことがとても重要なのです。
さて、今回は「見積は仮説である。そのため、継続的に仮説検証が大事」ということをお話しました。この「仮説」であるという考えを持つことで、見積に対する取り組み方も変わってくると考えます。
「仮説なので、間違っているかもしれない。だから、常に確認しなければならない。」今回は、この考えをご理解頂けると幸いです。
最後まで読んで頂き、ありがとうございました。ご意見・ご感想を頂けますと幸いです。
ITプロジェクト研究会
