「不安の共有が炎上を予防する」──プロジェクトを成功させるためにメンバー一人ひとりができること

炎上を回避するために、潜在的なリスクを察知する

　「皆さん、炎上してますか？」

　冒頭からそんな語りかけで始まったセッション。システム開発において、炎上したことがないという人はそう多くはないだろう。武方氏も、自分の失敗で炎上を起こしたこともあれば、炎上案件を助ける側になったこともあるという。

　そうした経験から、不安は炎上のサインになっているのだから、不安を伝えることで炎上を減らせるのではないかと考え、「『不安を伝えるためにはどうすればいいか』という発想のもと、さまざまなことに取り組んできた」と語る。

　そもそも「炎上」とは、計画に対して予算・期間・品質・QCDが未達になる「プロジェクトの失敗」が回避できそうもない状況に追い込まれることを指す。そうした状況下では、プロジェクトのメンバーが過剰な労働を継続的に強いられる。また、「リスク」はプロジェクトの計画を阻害する今後起こりうる事柄、「問題」は計画を阻害する、すでに発生した事柄と定義される。

　つまり、リスクが顕在化して問題が発生し、その結果として炎上し、最悪失敗に終わるという流れだ。この「炎上」を回避するには、それ以前の潜在的な「リスク」と顕在化した「問題」をコントロールすることが必要となる。

　そこでまず行うべきが「リスクマネジメント」だ。まず、①どのようなリスクがあるのかを洗い出し、②リスクの大きさを評価し、③それぞれに対する対応について考える。なお、システム開発における一般的なリスクはすでに先人が整理しており、「スケジュールの欠陥」「要求の増大」「人員の離脱」「仕様の崩壊」「生産性の低迷」などがあるが、いずれも回避は「マネージャーの仕事」という認識が一般的だろう。

　しかし、メンバーもまた炎上はいやなもの。炎上させないために、メンバーができることはないのか。武方氏は「あると思う」と言い切り、「それは自分が持っている不安を共有すること」と語った。それによってプロジェクトがうまくいき、チームが育つという。はたして、それはどういうことなのか。

　前述の5つのリスクすべてについて平等に備えることは、限られたリソースの中では難しい。そこで、優先順位をつけて対応する必要があるが、この「優先順位の付け方」にリスクが顕在化するかどうかが大きく関係するという。つまり、リスクはあくまで潜在的で、潜在したまま終われば問題にはならない。そこで、顕在化しそうなリスクを察知して備えられれば、効率的にリスクに対処できるというわけだ。