プロジェクトは静かに壊れていく

プロジェクトは顧客の実現したいことを受託側が見積もりして、委託元の顧客と契約して初めて立ち上げられる。見積した契約をもとにプロジェクト計画が立てられ、QCD(Quality, Cost, Delivery)の目標を設定し、必要なリソースを手配してプロジェクトを開始する。

PMBOKが席巻してから10年を超えた今となっては、契約をもとにプロジェクトを立ち上げることがごく当たり前の日常になっていると思うのです。契約を明らかにし、プロジェクトの計画を立て、必要なリソースを確保し、プロジェクトを始める。そうしたプラクティスを実践しても、それでもなお世の中のプロジェクトの60%はQCDのいずれかでトラブルを起こしているのです。

でも、プロジェクトは急にトラブルを引き起こすわけではありません。プロジェクトマネージャやキーパーソンが不慮の事故に巻き込まれるなど例外は無いとは言わないですけれど、その確率は少ないです。

プロジェクトは突然崩壊するわけではないけれど、では、プロジェクトは一体いつ、何を起因に崩壊してくのでしょう。

ふと、思いつくことがありました。それは「見逃す。」と言う行為です。プロジェクトの日常には、プロジェクトチームを中心としたアクティビティで満たされ、運営されています。プロジェクトがおかしくなる予兆は、そうしたプロジェクトの日々のアクティビティの一つが計画と違う動きをし始めることから始まります。その計画と違う動きをし始めているアクティビティの「異変」に気づいているのに反応をしないことがコトを大きくする作為なのだと思うのです。

例えば、

「レビューで指摘が多い。」
「完了日を超過しても作業が終わらない。」
「顧客からの情報提供が3日遅れている。」

これらの事象はプロジェクトでは日々起きていることです。それもごく普通に。その、日常に起きているコトがプロジェクトを静かに崩壊させるかどうかの分水嶺は、一つひとつのアクティビティがコントロールされているかどうか、プロジェクトマネージャやプロジェクトメンバの目が行き渡っているかどうか、です。

「レビューで指摘が多い。」の事象を見て想像しなければならないことは、deliverableの品質不良です。品質が顧客要件を満たさないのであれば、品質を満たすまでのコストを投入するか、契約不履行になるか、など最悪のケースまで思い至らなければなりません。ただ、それは極端なケースなので、その前に事実としてあることを正しく理解し、原因の内にある真因を探索しなければなりません。

「レビューで指摘が多い。」ことの真因が、メンバのスキル不足なのか、開発プロセスの問題なのか、それともレビュー観点の誤りなのか。もしかすると、プロジェクトチーム内のコミュニケーションが問題なのかもしれません。いずれにしても原因はプロジェクトチームがいるプロジェクトルームにあるのです。

「レビューで指摘が多い。」のように一見して、一つのアクティビティとしては大したことがないような気がしていても、その先にあることを如何に想像できるかが結果的にプロジェクトを失敗する道のりから進むべき道へ引き戻す働きかけとなるのです。一つひとつのアクティビティの誤差が小さくても、そのアクティビティが100、200となった時の誤差の塊は無視できるものではなくなるのですから。

そうした観点で見ると、一つのアクティビティの差異を見逃すという行為は、静かにプロジェクトを崩壊させる幇助に加担していることになりかねない、ということです。プロジェクトチームのメンバ誰もがそうしたセンサーが働かないとすると、そのプロジェクトチームは茹でガエルと同じように日々の異変に気づかず、おかしいと気づいたらすでに茹であがっていたことにしか気づかないのです。だから、みんなこういうんです。

「なんでプロジェクトがおかしくなっていたのわからない。」

と。プロジェクトがトラブルになるときは、静かに壊れ始めるのです。