プロジェクト炎上はなぜ起こる？炎上の3つの要因と、”酸素”を断つ鎮火＆予防方法

プロジェクトの炎上は、それに関わる誰にとっても望まない出来事です。しかしどんなに努力してマネジメントしたとしても、時にそれは避けられないものとして発生してしまいます。

いったいプロジェクトの炎上は、なぜ発生してしまうのでしょうか。またいざ発生してしまったときに、どのように対処したら良いのでしょうか。

実は、火事で炎が燃え広がったときの鎮火方法と、プロジェクトの鎮火方法は似ているところがあります。あわてて水をかけると、かえって燃え広がってしまうものです。

今回は、プロジェクトが炎上したときに、どのように対処すれば良いか解説いたします。

後藤洋平

プロジェクト工学提唱者。株式会社ゴトーラボ Founder/CEO。「チームに覇気がなく一体感がない」 「議論が空中戦になりがち」 「無駄な会議で時間を浪費しがち」 そんな組織の炎上体質を改善するための、プロジェクト工学ワークショップを提供しています。

ITプロジェクトの炎上はなぜ起こる？

約半数が失敗!? ITプロジェクトの難しさ

日経クロステックが2018年に行なった調査では、情報システムプロジェクトの47.2％が失敗に終わっていると報告されました。一昔前には「プロジェクトの成功確率は30％」といわれていましたので、その時よりかは改善しています。

しかしそれでも、発注したものが2分の1の確率で、納期が遅延したり、コストが余計にかかったり、品質が満足いかなかったりしてしまうというのは、恐ろしい話です。たとえばマイホームを建てようとしてそんなことがあったら、大変な問題ですよね。

ITプロジェクト炎上の3つの要因

ITプロジェクトが炎上してしまう要因には、大きく3つあります。先ほどマイホームのたとえ話を出しましたが、ITプロジェクトはまさしく建築の世界と比較すると分かりやすいでしょう。

• 要素技術の進化が激しい一方で、工程管理の技術の進歩が遅い
  建築分野では新規格のネジや部材というものはそうそう出るものではありませんが、ITでは次々と新たな言語やフレームワークが登場しています。しかし、それら新しい技術や仕組みを「管理する手段」はより良いものがあまり出てきていません。それぞれの技術進歩の差異が、現場を混乱させる一因であることは否定できません。

• 成果物が抽象的で、事前にその設計内容を確定するのが難しい
  建築は一度図面を引いたらその寸法どおりにモノを作り進められますが、情報システムにおける設計では、データのインプットとアウトプットの定義や動的な遷移など、静的に確定した「モノ」としての表現が難しいのが実際です。

• 製造コストが低いため、変更や修正が容易にできてしまう
  建築物が出来上がってから間取りを修正するのが難しいのは素人目にも明らかですが、ソフトウェアの場合は「ちょっとプログラムを修正したらできるんじゃないの？」と思われがちです。そして実際、できてしまう場合も多くあります。しかし「いつまでも修正し続けることが可能」なのはは便利なようで、実は「いつまでたっても終わらない」を招いてしまうものでもあります。最初のうちは善意と親切心で「それぐらいだったら大丈夫ですよ！」と応じていたものが、気づくといつのまにか引き返せない混乱の沼にはまってしまっていた、なんてことも……。

炎上したプロジェクトの鎮火方法

プロジェクトの炎上とはなにか

そもそも「プロジェクトが炎上している」とはどういう状況でしょうか？

本稿では、以下の3条件をすべて満たした状態を「炎上」と定義したいと思います。

• 作りたいモノが、事前に取り決めていた納期やコストで実現できる見通しが失われた
• 新たに取り決めを交わしたいが、なんらかの理由により合意形成できない
• 結果、とりあえずやらなければならない作業が次々と発生しており、止められない、終わらない……

ものづくりにおいて、「作ってみたら思ってたのと違った」というのは日常茶飯事です。大切なのは発生したギャップに対して、常に関係者が状況を理解し、あるべき道を探し、合意し直すことです。

しかしどうしても、その「合意のし直し」が難しいときがあります。それは複合的な要因によります。たとえば受託者側にミスがあったが、それは依頼者側が無茶な要望を出しすぎたせいだった……というふうに、どちらにも非があるときに「じゃあどうするか」というラインの引き直しが難しいのです。

「責任の追及」はプロジェクト炎上の鎮火につながらない

プロジェクトが炎上したとき、「どちらが悪いかをハッキリさせて、その責任を取らせればよい」と思うかもしれません。しかしそれは絶対にしてはいけない方法です。

火事で炎が燃え上がっているときにいきなり水をかけたら、鎮火するどころか火種が拡散し、さらに炎上してしまう……ということがありますが、プロジェクトの炎上もこれに似ています。

火事の鎮火でもっとも確実なのは「酸素の供給を断つ」ことです。火は燃えれば燃えるほど、空気の対流を生み、どんどん次の材料を自分で呼び込んでしまいます。「水をかけて温度を下げる」という方法につい目がいきがちですが、酸素という根本原因に目を向けることが必要です。

「根本原因を断つ」ことがプロジェクト鎮火の最善施策

では、プロジェクト炎上の根本原因とは何でしょうか。それは「認識」「作業」「意思伝達」のどこかに必ずそれは潜んでいます。

なにか仕事があったときに、それを順調に終わらせたいのは依頼者も受託者も同じです。うまくいかない原因は悪意のもとにあるのではなく、工程上の不具合にあります。

どの過程で不具合が発生しているのかを突き止め、それを改善することが鎮火につながるもっとも確実な方法です。

プロジェクトの炎上を防ぐ方法

「認識」「作業」「意思伝達」を正確に

ひとたびプロジェクトが炎上してしまったら、それを鎮火するのは容易ではありません。プロジェクト炎上は事前に防ぐことが大切です。

では、プロジェクト炎上の予防はどのようにしたら良いのでしょか。

鎮火方法でも解説しましたが、「認識」「作業」「意思伝達」を正確にしておくことが予防においても最適解です。

• 「認識」を正確にする方法
  言葉の表面だけで理解したつもりにならないこと。伝聞に頼らず、常に裏を取り、一次情報に接すること。受け取った情報を言語化して相手に提示し、間違いがないかを確認すること。
• 「作業」を正確にする方法
  まずは、面倒くさがらないこと。そのうえで、素早く、正確にできる方法を工夫すること。ただ作業をするだけでなく、チェックやレビュー期間をあらかじめ予定しておくこと。
• 「意思伝達」を正確にする方法
  テキストファイル、エクセル、スライド等の形式を適切に選ぶこと。電話、メール、チャット、会議等の伝達経路を適切に選ぶこと。伝えた後に、伝えたいメッセージがちゃんと伝わったかを確認すること。

身体の健康も、発病してから治療するのと、普段から予防しておくのとでは、かかるコストが全然違います。（発病して初めて健康の大切さに気付く、とも言いますが……）

特効薬やエナジードリンクのような、「これを使ったら即元気！」というソリューションはありません。普段からのコンディション維持をし、プロジェクト炎上に備えるのが基本になります。

炎上そのものが悪いのではない、そこから何も学びがないのが悪い

ここまで「病気の予防とプロジェクト炎上の予防は似ている」とお話しました。しかし時に、どんなに気を付けていても、避けられない外部要因でプロジェクトが炎上してしまうこともあります。できればトラブルなく仕事をしたいものですが、なかなかそうもいきません。

そこで、ひとつの発想の転換をご提案したいと思います。それは「炎上という出来事を前向きにとらえる」ということです。

• 炎上は、自分たちに足りていないものを気づかせてくれるきっかけです
• 炎上は、それをともに乗り越えたチームは確実に結束力が高まり、信頼関係が強化されます
• 炎上は、それが「やらされた仕事」ではなく、「進んでやった仕事」であった場合、文化祭のようなお祭り騒ぎにも似た高揚感のあるイベントでもあります

もちろん、いわゆるブラックな職場の理不尽な炎上は健康を害するものであり、正当化されてはいけません。そうではなく、この仕事を自分の成長機会にしたいと素直に思えるような現場だった場合は、きっとそこから得られるものは大きいでしょう。炎上それ自体を悪いものだと決めつけて忌避するのではなく、「いかにそこから意味を見出すか」という視点があれば、また違った世界が見えてきます。

まとめ

本稿では「プロジェクトの炎上はなぜ起こるか」「プロジェクトの炎上とはどんな現象なのか」「プロジェクトの炎上が起きたらどうやって鎮火するか」「プロジェクトの炎上を予防するためにはどうしたら良いか」を解説させていただきました。

そしてプロジェクトの炎上をいかに受け止めるかで、あなたのキャリア感はまた違ったものが見えてくるでしょう。ぜひ、ご参考にしていただければと思います。