プロジェクト炎上の原因の3割は「そんな話は聞いてない」

プロジェクトの炎上原因は何でしょうか？

技術不足？
人材不足？
管理不足？

これらが原因のこともありますが、

「そんな話は聞いていない」

という、コミュニケーション不足も多いです。

プロジェクトの炎上は、
派手なトラブルで起こるというより
小さな認識のズレが積み重なって、
気づくと大きな問題になります。

今回は、現場でよく起きる
「認識齟齬による炎上」
について書いてみます。

「当たり前」は共有されない

あるプロジェクトで、こんなことがありました。

「この期間は作業してはいけない」

開発側はその話を聞いておらず、
その期間を考慮せずにスケジュールを組んでいました。

依頼側からすると、
その期間は長く続いている慣習で、
当たり前の禁止期間でした。
そのため、事前に説明をしていませんでした。

なぜ不満が生まれるのか

これは要件定義漏れにあたり、開発側からすると
「必要な要件や制約条件が提示されなかった」
になるのですが、多くの場合、

• スケジュール調整

• 作業順序の変更

といった対応を、開発側が残業などで吸収することになります。

依頼側からすると「当たり前」に対して
お金がかかることに抵抗があり、
追加費用の手続きも煩雑になるため、
開発側から費用請求できるケースは多くありません。

その結果、開発側には不満が生じます。

「この資料を見ておいてください」という地雷

もう一つ、現場でよくあるケースがあります。
「この資料を見ておいてください」
と共有されるケースです。

もし資料が10ページ程度であれば、全部読むことも可能です。
しかし実際には数十ページに及ぶ資料が共有されることも珍しくありません。

依頼側としては
「資料は共有した」
という認識です。

一方、受け取る側は
「どこに書いてあるの？」
「どこを読めばいいの？」
という状況になります。

結局、ここでもやはり認識齟齬が生じます。

問題の本質は「情報不足」ではない

この問題の本質は、情報量ではありません。

原因の一つは、伝え方です。
例えば、「この資料を見ておいてください」ではなく、「P45～47に作業禁止期間の制約が書かれているので、この部分は必ず確認してください。」であれば、状況は大きく変わります。

重要な情報は「どこにあるか」を指定する

これだけでも、認識齟齬はかなり減ります。

投げて終わりにしない

TeamsやSlackなどのチャットツールが普及し、
資料も簡単に共有できるようになりました。

しかしその結果、
「投げて終わり」
のようなコミュニケーションが
増えていないでしょうか？

研究でも、コミュニケーション手段には
「情報の豊かさ（リッチさ）」
の違いがあると言われています。

対面コミュニケーションは
・表情
・声のトーン
・身振り
・空気感
など多くの情報を含むため、
最も誤解が起きにくい手段とされています。

一方、チャットやメールのような
テキスト中心のコミュニケーションでは、
・相手が理解していない
・困っている
・納得していない
といったサインが見えません。

対面であれば
「今の説明、伝わっていないな」
と表情から気づくこともあります。

しかしチャットでは、それが分かりません。
その結果
「伝えたつもり」
「聞いていない」
という認識齟齬が生まれやすくなっています。

PMが気にすべき炎上原因は能力ではなく構造

プロジェクトが炎上すると
・技術力の問題
・人材の問題
・スキル不足
といった話になりがちです。

しかし、PMが気にしたほうがよい炎上原因は、
能力ではなく構造です。

今回の件でいうと「情報共有の仕組み」の構造です。

「そんな話は聞いてない」
この言葉が出てきたとき、
プロジェクトにはすでに小さな歪みが生まれています。

このサインをキャッチし、
なぜ、それが起きたか、背景も含めて丁寧に確認して
「今いるメンバー・能力で改善できる構造はないか？」
と自問し、改善プランを検討することが重要です。

今回の記事がよかった方は、こちらもぜひご覧ください！