問題を知りながら放置した結果、八方ふさがり状態に

4．臭いものに蓋（見て見ぬふりをして、改善も行わない）
　プロジェクトが中止されずに継続してしまうという悪い状況の中で、さらに悪いことが起きます。

　内部ではさまざまな問題が発生し続けているのに、外部には問題が伝わらないという二重構造のせいで、問題に「蓋」がかぶせられてしまいます。

　表面的にはプロジェクトは順調に進んでいることになっているので、見直しのための予算などは認められません。プロジェクト担当者は問題の実態を知っていますが、このフェーズになると自分自身でできることが少ないので、問題を他責にして放置し「見て見ぬふりをする」という状態になりがちです。その結果、さまざまな問題が放置され続け、それらの問題を解決する道筋さえ見えなくなるのです。

　情報システムのプロジェクトでは、「使われないシステムは安定稼働する」という皮肉な言葉があります。新システムとして完成はしたものの、機能や性能に問題があるので、利用者はシステム以外の方法で作業を行うことになります。少数の人が一部の機能しか使わないため、システム障害が起こることが少なくなります。それどころか、システムに障害が発生しても誰も気づかない状態にすらなります。

　しかし、プロジェクトの運営側には、この状況を是正するモチベーションがあまり生まれません。システムが安定稼働していれば、自分の責務を果たしていると言いやすいからです。システムが使われているかどうか、役に立っているかどうかは、二の次です。システムの利用頻度が少ないことが判明したとしてもそれは利用者側の問題であり、運営側の問題ではないとの意識になりがちです。そして、そもそもシステムの利用頻度が測定されません。

　こうして、ないないづくしの状態のまま、プロジェクトが生み出した不完全なシステムが放置されます。これが、「臭いものに蓋」をされた状態です。プロジェクトのせいで苦労している現場担当者から見ると蓋を取り外すことができない最悪の状態になってしまいます。

　プロジェクトを継続するなら、最低限の見直しや維持管理を行うべきですが、それすらも十分に行われません。八方ふさがりの状態になってしまうのです。

これから始めるプロジェクトも、同じ“失敗構造”になるかも…

　失敗プロジェクトの構造を説明してきました。どのように感じられたでしょうか。同じような経験をした方もいらっしゃるでしょう。

　プロジェクトは難易度が高い活動であり、失敗する確率も少なくありません。ただ、プロジェクトが失敗したときに、その原因を個別事象の重ね合わせとして分析することが多いように思います。「現場の反対を押し返せなかったから」「予算が削られてしまったから」「委託事業者が期待した働きをしなかったから」といったさまざまな原因が挙げられますが、それらの問題を表面的に俯瞰するだけでは次のプロジェクトに活かせる教訓になりません。プロジェクトの特性や背景は毎回異なるので、前提が違う状況で教訓を活かすことが難しいからです。

　しかし、これらの失敗原因をもう一段階「蒸留」して捉えなおすと、ヒト・モノ・カネの観点から共通的な問題を抽出することができます。失敗するプロジェクトは金太郎飴のように同じ構造を持っていることを説明しました。つまり、これから開始するプロジェクトも、同じ構造になってしまう可能性が高いのです。

　私たちがこの構造の発生原因と対応方法を学べば、さまざまなプロジェクトで教訓を活かすことができます。その教訓を分かりやすくまとめたものが「全体地図」です。

　プロジェクトの規模が大きくなるほど、問題の規模も大きくなります。計画時点の不備が露呈してさまざまな問題が起こったときに、その問題に対して異なる意見・立場を持つグループができ、ヒトの問題が一層複雑化します。モノとカネについても多数の問題が複合的に重なり、局所的な問題と思っていたものがプロジェクトの命運を揺るがす重大問題へと変化します。そして、問題構造が複雑になるほど正確な状況を把握できなくなり、膠着状態が続いてしまいます。

　しかし、過去に何度も通ってきた失敗の本質を理解できれば、それを教訓として活かし、同じ過ちを犯すことを防げます。「全体地図」を使って説明する教訓は、小規模なプロジェクトはもちろんのこと、大規模なプロジェクトになるほど重要性が増す教訓となっています。