プロジェクト費用の膨張サイクルは、精神面の作用が大きい。そこから抜け出るのは、大変難しい
itpjstudy
残念ながら、すべてのプロジェクトがうまく行くわけではありません。なかには、延伸を繰り返し、大きな費用増になってしまうケースもあります。
こういうとき、ユーザ企業のマネジメント層や外部関係者には、「このままでは、うまく行きそうにないな」と感じられることが多いです。しかし、プロジェクトの現場は、「あともう少しで、難局を抜けられるはず」と頑張り続けているケースが多いように見えます。
今回は、どうしてこういう状況が発生するのかについてお話したいと思います。
膨張サイクルに入ってしまうとき
プロジェクト運営が、一時うまく行かないことは、決してめずらしいことではありません。たいていの場合は、原因を分析して、正しい対策を打つことによって、リカバリされます。
ただ、そうはならないケースもあります。
状況分析を十分にせず、最初の延伸を安易にしてしまう
うまく行かないケースでは、たいてい状況分析が十分にできていません。
- 「どうして遅延してしまったのか」の分析が浅い
- 「現在のスループットはどれくらいで、残件を終えるのに、後どれくらいかかりそうか」が定量化できていない
そういったときに、起きていがちなプロジェクト内のコミュニケーションは、こんな感じです。
経営層
どういう状況が起きているのか、よく分からない。第三者レビューなどを入れて、見える化した方が良いのではないか？
リーダ
いまは、遅延を最小限にできるかどうかの瀬戸際なんです。
現場メンバには、レポーティングよりも、現場の問題に集中させたいです。ですので、現場メンバへのヒアリングはしないでください。
皆さんも感じられているように、こういうときは、うまく行きません。結果として、延伸を繰り返していくことになります。
名目をいろいろと変えながら、モグラ叩き的に延伸を繰り返す
上記は、延伸を何度も繰り返している例ですが、決して珍しいケースではありません。
リーダ
システムテスト1の延伸タスクが終わったのですが、色々改修をかけたので、全体の品質を再確認するために、「システム1.5」として、再度クイックにテストを行います。
リーダ
システムテスト1.5を実施中に、システムテスト2に向けたリスクを発見しました。システムテスト2を円滑に進めるために、「品質テスト」を実施します。これで、システムテスト2がスムーズにできるはずです。
リーダ
品質テストは終わったのですが、いくつか重点確認した方が良いシステム機能が識別されたので、それら機能に限定して「重点テスト」を実施します。システムテスト2に入る前に見つかって良かったです。
意外に少なくない数のプロジェクトで、こういった状況を見かけます。
状況の分析ができていないため、問題を一度に洗い出すことができず、モグラ叩きになってしまうのです。結果として、テストの効率を上がりませんので、ダラダラと長い時間がかかることになってしまいます。
こういう状態になると、プロジェクトマネージャも、問題の根本解決に踏み込むというよりも、延伸のための名目探しの方に頭を使うようになってきます。そうなると、プロジェクトに任せていても、この状態を脱することはできません。
モグラ叩きの場当たり的な延伸が、巨大な費用増につながる
場当たり的な延伸のよくないところは、大きな体制の維持につながることです。
スケジュール延伸になるような状況では、たいていリカバリのために人員が増強されています。そして「あと、もう少しでリカバリできます」という根拠ない方針にもとづき、「いまが正念場なので、体制を維持してやりきろう！」ということになることがほとんどです。
結果的に、大きな体制が維持され続けて、巨額な費用増になります。
悲しいことに、問題の見える化が十分できていませんから、対策も適切でないことも多いです。また、大きな体制ですから、効率よく仕事が出来ていない人も多数います。
そのため、大きな費用を投下した割には、成果が小さいということになりがちです。
英断をして、一度プロジェクトを止められるか
こういう状況下で、ITパートナの品質管理レビューを受けるとよく言われるのは、「いったん、プロジェクトを止めて、状況を確認した方が良いんじゃないか？」ということです。
前述のように、かけている工数（＝費用）の割に成果が小さいことがほとんどです。そのため、いったん止めて、正しいやり方でやり直した方が良いとアドバイスされます。
この見える化の活動には、留意しておきたいことがあります。
プロジェクト外から品質管理のエキスパートを入れる
状況として、プロジェクトリーダやPMOをはじめ、プロジェクト側だけでは、状況の見える化ができなかったということですので、第三者が入ることが有用です。
プロジェクトメンバだけで立て直すことも、できなくはないですが、いままでやってきたことを否定するのは心理的にも抵抗のあることですので、なかなか難しいです。
現場ヒアリングをしっかり行う
うまく行っていない状況が続くときは、現場の運営がよくない状態です。現場メンバが感じる色々な課題が、プロジェクトのリーダ陣にうまく伝わっていないことが多いです。そのため、第三者から客観的に確認することが必要です。
なお、よく第三者レビューをすると、現場が止まると心配されますが、実際には止まりません。
実際には、メンバ全員のヒアリングは行いませんし、ヒアリングしたとしても1-2間です。リーダ陣は、リカバリプランの作成などでかなりの時間を奪われるかもしれませんが、プロジェクトが止まるほどにはならないことが多いです。
管理し切れる規模でプランを考える
延伸を繰り返しているときに起きていがちな状況として、リーダ陣がメンバのタスクを管理できていないということがあります。そこで、打ち手として、管理し切れる規模にプロジェクト体制を縮小するということが挙げられます。
体制を縮小すると、プロジェクト期間を延ばすことになりがちですが、お金を垂れ流しながら、延伸を続けるよりは、よっぽどマシです。
プロジェクト計画で織り込んでおいた方が良いこと
プロジェクトの費用見積をする際には、以下のような形で体制規模を想定することが多いと思います。
開発期間は開発工数がかさむが、開発が終われば、開発者をリリースでき、体制を小さくできるというものです。
しかし、実際には、なかなかそうなりません。
テストフェーズで、色々な問題が検知されて、不具合対応などで、結局開発者はリリースできず、大きな体制を維持することになることが多いです。
そういったこともあり、安全を見て、予め、プロジェクト後半の体制を厚めに想定しておくことも多いかと思います。
体制を大きくするにせよ、予め計画立てておくことが重要
ダメなのは、場当たり的に体制を増強・維持することです。よく考えて、計画的に進めるという状況を維持することが大切です。
今回は、延伸をケースに費用増についてお話をしました。前述したように、プロジェクト内ではなかなか正常に物事が考えられない状態になっていることが多いです。そういったプロジェクトの心理状態もよく理解して、プロジェクトに向き合うことが大事になります。
実際のリカバリにおいては、色々なノウハウが必要となりますが、その辺は、また別の形で取り上げたいと思います。
最後まで読んで頂き、ありがとうございました。ご意見・ご感想を頂けますと幸いです。
ITプロジェクト研究会
