先日、システム開発のプロジェクトが炎上する理由についてブログにまとめました。プロジェクトが炎上する理由は一つではなく、様々な要因が積み重なって炎上していくものです。
これに対して、炎上してしまったシステム開発プロジェクトに対して、どのような対策が取られているかについてもツイッター上で聞いてみました。
炎上したプロジェクトにはよく火消し役が投入されますが、炎上を鎮火させるためにどんな施策が取られていましたか？良策、愚策含めてリプ欄で書いていただければと思います。
— 米村歩@日本一残業の少ないIT企業社長 (@yonemura2006) April 13, 2018
皆様からいただいた内容について、原文は上記ツイートのリプ欄をご覧いただくとして、炎上プロジェクトに対する施策を取りまとめてみました。当たり前のことですが、基本的にはプロジェクトが炎上してしまう理由に挙がっていることと反対のことをやるということですね。
プロジェクト炎上の原因となっている要因は一つではありませんが必ず存在しますので、それに対して一つ一つ炎上要因を取り除いていくことが対策の基本となります。万が一、システム開発のプロジェクトが炎上してしまった場合の参考になれば幸いです。
炎上を鎮火させるためにやってはいけない愚策
システム開発のプロジェクトが炎上した時に、最もやってはいけない愚策であり、なおかつ実際の炎上プロジェクトでは最も採用されやすい施策が、時間と人をとにかく投入する人海戦術です。これは無能な営業やマネージャーがよくやる愚策であり、さらにプロジェクトの炎上を加速させることになりますのでやめましょう。
既存メンバーの稼働時間を増やす愚策
炎上したプロジェクトでは、既に長時間残業によってプロジェクトメンバーが疲弊しているケースがほとんどです。そこでさらに徹夜や休日出勤という過酷な試練をプロジェクトメンバーに与えると、そこで心が折れてプロジェクトから離脱という事態が生じかねません。
これはシステム開発のプロジェクトが炎上する理由でも挙げられている理由である、「プロジェクトメンバーが突然いなくなる」や「プロジェクトメンバーの入れ替えが頻発している」を助長することにもつながり、火に油を注ぐ結果にもなりかねません。
そして心が折れかけている人間に対してさらに稼働時間を増やせという司令が下れば、嘘の進捗報告をしたり、問題があっても隠してしまいたいと考えてしまうのが人情というものです。これは「正しい進捗情報を報告しようとしない」や「問題点があっても隠蔽してしまう」を助長してしまうことにもつながり、さらにプロジェクトを炎上させてしまうことになりかねません。
プロジェクトメンバーの安易な稼働時間強化は、炎上しているプロジェクトをさらに良くない方向に導きかねない愚策ですので控えるべきです。
技術不足の新規メンバーを増やす愚策
人員が不足している時に適切に人員を増強することは悪いことではありません。むしろ頭数が足りていないのであれば当然補強すべきでしょう。ただし補強するのは戦力になる人員でなければなりません。
プロジェクトが炎上した時にありがちな人員補強として、誰でも良いからとにかく頭数を増やすという愚策が取られがちです。そうすると新人に毛が生えた程度のレベルの人達が大量にプロジェクトに投入されてくるようなこともあります。
新人に毛が生えた程度の戦力にならない新規プロジェクトメンバーが投入されてくると、プロジェクトはさらに景気よく燃えだします。システム開発プロジェクトが炎上する理由の一つである、「プロジェクトメンバーの技術力が不足している」が助長されるからです。
新しいプロジェクトメンバーが加入した時には、ただでさえプロジェクトに関する情報共有や引き継ぎが必要となるため助走期間が必要となります。そこに技術不足という要因が重なると、プロジェクトが炎上している中でさらに技術的な教育を行う負担まで加わってしまい、プロジェクトは烈火のごとく燃えだします。
頭数を増やさねばならず焦る気持ちは理解できますが、技術不足のメンバーを追加してもさらにプロジェクトを燃やす結果となるだけですので、必要なスキルを備えているメンバーに絞って増員するべきなのは当たり前のことです。
まずはプロジェクトメンバーの稼働を平常な状態にする
プロジェクトが炎上して、メンバーの稼働が異常な状況となっているのであれば、多少の残業はやむを得ないとしてもまずは十分な睡眠が取れる程度には稼働時間を下げることです。一見すると遠回りのようでもそれが炎上を鎮火させる近道です。
労働時間が長くなると集中力が落ちて生産性が落ちることは誰でも理解できることですが、労働時間が長くなることで生産量が落ちることもあるということは理解していない人が多いと思います。
アクシアでは２０１２年１０月に残業ゼロになりましたが、残業まみれだった２０１２年９月と比較した時に、残業ゼロとなった１０月の方が生産量は２７％増加しました。その具体的な理由については下記のブログ記事もご覧ください。
プロジェクト炎上を何とかしようと焦る気持ちに歯止めをかけ、プロジェクトメンバーに十分な睡眠と休息を与えて生産性も生産量もマックスとなるようにマネジメントすることが必要です。
プロジェクトマネージャーを交代する
それまでプロジェクトを引っ張ってきたプロジェクトマネージャーが引き続きプロジェクトマネジメントを継続できれば良いのですが、現実的にはそのマネージャーが力不足であったためにプロジェクトが炎上しているわけです。
プロジェクトを少しでも早く炎上から救い出し、通常のシステム開発のプロジェクトに戻れるようにするためにも、代わりの力のあるマネージャーを抜擢し、それまでのマネージャーは補佐役にする対応が望ましいと思います。
実際に炎上している開発プロジェクトでも、力のあるマネージャーに変わった途端にあっという間にプロジェクトが動き出して炎上が鎮火されていく様子を見たことがある人は少なくないと思います。
それだけシステム開発のプロジェクト成功の要否にはプロジェクトマネージャーの力が大きく影響します。
対応すべき内容の線引を明確にする
炎上したシステム開発プロジェクトではやるべきことであふれかえっています。そこにはシステムの障害として対応しなければならない内容と、中には仕様変更に当たる内容や、顧客の無茶な要求が含まれていることもあります。
プロジェクトをいち早く炎上から救うためには、これらのあふれかえっている問題に対して、対応すべき内容とそうでないものにしっかりと線引をする必要があります。全部対応していたらいつまでたっても炎上はおさまりません。
場合によっては激怒する顧客や、納期が遅れている弱みを握って無茶な要求を飲ませようとしてくる顧客もいるかもしれません。しかしプロジェクトを１日でも早く正常な状態に戻すためには、追加の仕様変更に対しては費用と追加のスケジュールをしっかりと要求し、顧客の無茶な要求は毅然とした態度で断ることが必要です。
顧客の立場を利用して無茶な要求を繰り返すゲスは少なからず世の中に存在しますが、そういう理不尽な要求からプロジェクトメンバーを守ることもプロジェクトマネージャーの仕事です。
そういうことがまともにできずに顧客からの要求は断りにくいなどと言い訳しているようであればリーダーをやる能力も資格もないと私は思います。顧客の無茶な要求を断れない人がリーダーをやれば、必然的にプロジェクトメンバーの残業時間は長くなり、最悪の場合はプロジェクトが炎上します。
適切な納期を再設定する
システム開発が遅延し、既に納期が遅れている中で中々難しい状況だとは思いますが、現実的に見て適切な納期を再設定する必要があります。
おそらく顧客は激怒していますし、プロジェクトメンバーの深夜残業や休日対応まで要求してくるかもしれません。しかしそんなことをすれば逆効果でさらに納期は遅れますし、無理なものは無理なので顧客がどんなに強く要求してこようとも、現実的な納期を設定しなければなりません。
ここで顧客が怒って強く言ってくるからと言って、非現実的な納期を設定してしまうのはプロジェクトマネージャーの仕事ではありません。そういうことは無能なプロジェクトマネージャーのすることです。
ここでやってはいけないことは、最速で順調にプロジェクトが進んだことを想定した納期を設定してしまうことです。システム開発のプロジェクトというものは、予測できない不測の事態は必ず起きるものとして進行しなければなりません。
そのためにはスケジュールにバッファが必要となりますし、バッファ無しのスケジュールを引いた時点でそのプロジェクトをうまく進行することなどできなくなります。
そうすると結局また何度も納期遅延を繰り返すことにもつながり、さらなる顧客の怒りを買うことになってしまいます。顧客から怒られたとしても最初から現実的な納期の交渉をすることが必要です。
もしどうしても顧客がバッファ無しのスケジュールを要求してくるのであれば、何か一つでも不測の事態が起きた場合には必ず納期が遅れるということを顧客に了承しておいてもらうべきです。
最速で納品するために顧客にも協力してもらう
システム開発が遅延して納期に遅れると顧客は当然怒ると思いますが、最速でシステムを納品するために顧客にも協力をしてもらう必要があります。
顧客の怠慢で未決定の仕様がある場合にはさっさと決めてもらう必要があります。またプロジェクト炎上時にはよくあることなのですが、顧客がプロジェクト遅延の説明を何度も何度も要求してくる場合があります。
これは顧客側の担当者も上司に説明が必要になるためで、そのために過剰な説明資料を要求したり、過剰な頻度で打ち合わせを要求したりしてしまうわけですが、これはプロジェクトの円滑な進行の妨げとなります。
プロジェクトを円滑に進め、少しでも早く炎上を鎮火させるためには、システム開発の進行を最優先させなければなりませんし、そのことを顧客側の担当者にも理解してもらう必要があります。
顧客側の担当者も上司に怒られるかもしれませんし、場合によっては評価に関わるかもしれません。だから不安になって、その不安をおさめるためにシステム開発をさらに遅延させてしまうような過剰な要求をしてしまうわけですが、そんなことをしても結果的には誰のためにもなりません。
悪いのは納期を遅延させた開発会社側かもしれませんが、プロジェクトを円滑に進行できるようにするためにも、顧客側にも協力をしてもらうべきです。
顧客が乞客だった場合にはその後の取り引きを考える
プロジェクトが炎上して納期が遅延し、顧客との約束が守られなければ顧客が怒ることは当然です。しかしそのことと、顧客が理不尽な要求を繰り返すことは話が別です。もし理不尽な要求を繰り返す顧客なのであれば、プロジェクト遅延の要因は顧客側にもあります。
納期が遅延していることに乗じて、それを利用して理不尽で無茶な要求をしてくる乞客は存在しますが、そういう相手と継続的に取引しても、どうせたいした利益にもなりませんし、またプロジェクトが炎上する要因にもなります。
自分達の否を顧客のせいにするのはあってはならないことは当然のことですが、システム開発のプロジェクトがうまくいかない要因の中には、少なからず理不尽な顧客が理由となっているものもあるはずです。
顧客がそういう相手だった場合には、両者のためにもその後の取り引きは考えた方が良いかもしれません。
