「Developers Summit 2024」レポート（AD）

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

【16-E-3】プロジェクト炎上を予防するためにメンバーひとりひとりができること

2024/04/05 12:00

リスト

　「プロジェクトが炎上する」ことは、システム開発で最も起こってほしくないことの一つであることは間違いない。はたして、炎上を予防する手段はあるのか。メンバーとしてできることはあるのか。日本発のデジタルイノベーションファームを標榜するNCDC株式会社で、自社プロダクトの立ち上げを担当するプロダクトマネージャ／シニアエンジニアの武方順平氏が、同社での取り組みや施策、そこから生まれたツール「PJ Insight」について紹介した。

リスト

編集部注

　本稿は、CodeZineに掲載された、ソフトウェア開発者向けカンファレンス「Developers Summit 2024（デブサミ2024）」のセッションレポートを転載したものです。プロダクトづくり、プロダクトマネジメントに近しいテーマを選りすぐってお届けします。

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

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

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

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

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

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

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

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

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

メンバーの「不安」から顕在化前のリスクを察知するツール

　PJ Insightは従来型のプロジェクト管理手法では把握が難しかった「プロジェクトメンバーの本音や不安」を定期的に収集して、PMやPMOが現場の状況を把握しやすいように可視化します。PJに潜むリスクの早期察知に課題を感じられている方は、ぜひPJ Insight（公式サイト）をお試し下さい。無料トライアルも実施中です。

メンバーができることは「不安と感じていること」を共有すること

　もちろん、理想的には、マネージャーがプロジェクトの内部事情・外部事情を把握し、適切な判断ができればいいが、実際にはできていないことも少なくない。

　武方氏は、「PM（プロジェクトマネージャー）はスーパーマンではない。分からないこともあるし、顕在化するリスクを見逃すこともある。そんなときこそ、メンバーが不足している部分を補えれば、チームとしては問題ないだろう。例えば、専門性の高い分野の知識、作業の中で得られた知識、過去の経験から得た知見、リアルタイムな進捗状況など、メンバーの方が詳しいことはたくさんある」と語る。

　例えば、あなたが開発チームのメンバーだとして不安を感じているとすれば、それはプロジェクトのリスクの顕在化を、自身の経験や知見から察知していることになる。

　つまり、感じているささいな違和感や不安が、炎上リスクのサインである可能性が高い。それも顕在化が近い、もしくは部分的に顕在化しているかもしれないというわけだ。これをリスクマネジメントに活かすには、「メンバーが自身の不安として感じていることを共有すること」が大切になる。

　もちろん、自分が感じている不安が「単なる杞憂ではないか」という反論もあるだろう。しかし、一般によくあるリスクとして、過去の問題は今回もリスクになる可能性がある。また、一般的でないリスクとして、プロジェクト固有の条件や組織だからこそ起きる問題も存在する。つまり、経験から感じる不安は十分な根拠と言える。

　そしてもう一つ、「自分が感じていることは他のメンバーも分かっているはず」との思いから、あえて言葉にする必要を感じないというケースもある。しかし、自分が指摘することで、他者も同じ不安を持っていることが判明すれば、確実性が高まる。つまり、共有することで、よりリスクを回避できる可能性が高まるというわけだ。

　しかし、「不安を伝えると炎上を回避できるのでどんどん伝えよう」といっても、実際にはそう簡単にいかないもの。不安を感じても、楽観的に考えて不安を打ち消したり、口にすることなく済ませたりということも経験があるだろう。

　また、「言い出しっぺ」になることで対応する責任が降ってきたり、チームとして考慮する必要が生じたり、「面倒になる」ことを回避しようという気持ちも働く。まして自分の責務でないところに口を挟むことで、「どう思われるか不安」という心理もあるだろう。不安を伝えるというハードルの先に「いいこと」があると分かっていても、ハードルが乗り越えられないでいるという状況だ。

メンバーの「不安」から顕在化前のリスクを察知するツール

「不安を共有すること」には、失敗しても成功しても意味がある

　この「マイナスの意見を表明するハードル」は、時にプロジェクトへの不安よりも大きくなることがあり、そうなってしまうと自分が感じたことを共有することは難しくなる。こうした状況こそ「心理的安全性が保たれていない」と言える。なお、心理的安全性を提唱したエドモント博士は、この阻害要素として「①無知だと思われる」「②無能だと思われる」「③邪推をしていると思われる」「④ネガティブだと思われる」という対人リスクの不安を上げている。

　それではこれらを乗り越えて、不安を伝えるにはどうしたらいいのか。そのための方法として、まず「乗り越えるためのエネルギーを与える＝動機づけする」ことが挙げられる。つまり、不安を共有したことで、チームががんばってリスクに対応し、結果としてプロジェクトがうまくいって自分も楽になる……といった理解が進み、広がれば、不安を共有するモチベーションがアップする。

　そしてもう一つ、乗り越えるハードルを低くするという考え方だ。不安を感じた時に、PMのところに行って話をするのはなかなかハードルが高い。いわば意志の力に頼って、行動を起こすことであり、再現性が高いとはいえない。そこで、習慣化やルーティンワークとすることで、それに乗ることで頑張らずに不安を伝えられるというわけだ。

　とはいえ、これもまた理想論であり、心理的安全性は1日でかなえられるものではなく、そう簡単に不安を共有してもらえない。リスク対応が失敗すれば、なかなか成功体験につながらず、「言わなければよかった」と感じてしまうこともある。

　しかし、一方で仮に対応に失敗しても、不安にチームで向き合うという経験が得られれば、「不安」を共有すれば、みんなで向き合って対応してもらえるという認知を育める。そうした一つひとつの積み重ねが、心理的安全性をつくる唯一の手段といえるだろう。また、失敗自体が学びとなり、これまで後手後手で対応していたものから、先手でのリスク対応の経験値を高めるものとなる。これはチームにとってはもちろん、個人の成長にもつながる。

　武方氏は「不安共有に成功しても、失敗しても、不安を共有・受容して向き合うことで、心理的安全性が高められる。だから、成功するかは分からなくてもやっていくほうがいい」と語った。

各メンバーの「不安」と向き合い心理的安全性を高める

不安の共有をシステム化したNCDCでの取り組み

　それでは具体的に「不安」をどのようにして共有していけばいいのか。NCDCでは、当時30人のメンバーが5〜10のプロジェクトに同時並行で関わり、週次で朝礼を行っていた。まず朝礼で、プロジェクトへの不安を5段階で評価するアンケートをとり、その場で気になるものがあれば当人に確認し、対応が必要と判断されれば、その場で実施を決定していた。

　「その場で」実施していたのは、スピードを重視したからだという。アンケートを投げっぱなしにするとなかなか回答が返ってこず、結果を見て再びヒアリングする必要が生じることがある。また、各プロジェクトごとに情報が閉じる傾向があったため、社内で取りこぼしがないよう、あえて全社朝礼で実施した。

　ここで注意が必要なのは、「人事目的ではない」ということの周知だ。あくまでプロジェクトを改善することが目的であり、回答の結果などでメンバーを評価しないことを徹底させた。そうすることでネガティブな内容もアンケートに書けるようになったという。

　この結果、「気がつかなかったリスク」を見つけられるようになり、例えば「スケジュールの不安」を感じている人が共有することでスケジュールを調整したり、「負担が大きいメンバー」を見つけてフォローしたり、いくつか改善もかなった。そして、もう一つのメリットとして、間接的ながら、不安を共有するという経験を得られたことは大きかった。自分が抱えている不安と似た不安を他の人も抱えていると感じることは、いい経験になったという。

　一方で次のような問題点が見つかり、それらを改善する方法について試行錯誤がなされた。

問題1：関与する人数が増えて対人リスクも増え、全体の前では話しにくくい

　回答結果を全体で確認せず、マネージャーが一次チェックをし、不明点をメンバーに確認するようにした。その上で、リスクを評価・状況をまとめるという手順をとった。

問題2：「どうして不安に感じるのか」という質問自体に圧力を感じる人も

　漠然とした不安について、正確に理由や根拠を答えるのは難しい。そこで、理由を尋ねるのではなく、「何があったのか」という事実だけを聞くようにした。

問題3：会社の規模が拡大し、限られた時間で詳細を詰めるのではスケールが難しい。

　プロジェクトごとに行うようになり、スケールできるようになった。個別では回答率が下がることが懸念されたが、もともとアンケート文化が定着しており、現段階では問題にはなっていない。

　こうしたことを踏まえて、プロジェクトごとに5段階評価とコメントで、不安を共有してもらうことを目的にアンケートを取り、回答をもとに本人とマネージャーがコミュニケーションをとってリスクを把握し、さらにその内容をレポートなどにまとめて経営陣やステークホルダーにも共有するようにしている。なお、プロジェクト間で不安を共有するために、情報をオープンにし、「不安を感じること、共有することは悪いことではない」という文化を定着させつつある。