一部のプロジェクトでは、なぜか状況が悪化していき、そこから抜け出すことができない。そのプロジェクトが失敗した原因を調べても、誰もが納得できる1つの原因が見つかることはない。それでもプロジェクトが軌道から外れていくときには、理由は分からないながら、問題が起きていることは誰でも分かる。このような状況は、ばつの悪いものになり得る。プロジェクトが失敗しつつあるのは明らかなのに、理由が分からないということがなぜ起きるのだろうか。これは普通、「じわじわと死に至る」ケースだ。プロジェクトリーダーが病気になり1週間遅れた、ハードウェアの故障でサーバが1日ダウンした、QAスタッフの家族が亡くなった、などといった仕方のない問題が積み重なって、作業の遅れが致命的になる場合がある。とにかくがんばって進めれば、この謎の問題はなくなり、プロジェクトはまた順調に戻ると思ってしまうことも多い。しかし、実際にはそうはならない。もし、プロジェクトが失敗に向かっているようであれば、はっきりと理由が分からなくても、成果に対する想定を修正できるように、関係者に知らせる必要がある。
仕事には異なるゴールを持つ多くの人が関わっており、時にはそれらのゴールが矛盾していることさえある。例えば、あなたはQAチームに自分のアプリケーションをテストしてもらう必要があるが、ほかのプロジェクトの方が優先順位が高く、あなたのアプリケーションは締め切りのずっと後までテストしてもらえないかも知れない。この種の仕事上の障害はよく起こる。もしこの状況を自分で解決できないのであれば、どれだけ遅れるか、どのような選択肢があるかを判断し、それを上司に説明すべきだ。その情報があれば、上司はそれに基づいて判断をすることができるし、場合によっては優先順位を変更するかも知れない。
もし作業データがコンピュータ上に保存されているのなら、データを1つしか持たない理由はまったくない。定期的にバックアップを取るべきであり、そのバックアップは別の場所の別のデバイスにおいておくべきだ。ローカルファイルをネットワークサーバ上にバックアップしてもよいだろうし、ネットワーク上で作業をし、IT部門にこの問題を扱わせてもいい。唯一の不可欠なファイルがあなたのノートPCの中にあり、それを落として読めなくなってしまったという理由で上司が許してくれると思うのなら、それはまったくの誤りだ。現実には、「バックアップがなかった」という言い訳を使えば、上司はあなたを信用できず、今後はプロジェクトを任せられないと考えるだろう。作業のバックアップは必ず取り、壊れたUSBドライブに入っていたのが唯一のファイルだったと、上司に話さなくてはならないような事態が生じないようにすることだ。
時には、不可解な出来事が起こり、仕事が進められなくなることがある。確かにそういうことは起こるものだ。そういったでたらめな問題で、あなたのプロジェクトが遅れたり、満足にできなかったということを、上司は受け入れるだろうか。もちろんだめだ。しかし時には、特に最後の瞬間に何かが起きたときには、できることがないという場合もある。これについては、とにかく上司の攻撃をかわすしかない。
この記事は海外CBS Interactive発の記事を朝日インタラクティブが日本向けに編集したものです。
CNET Japanの記事を毎朝メールでまとめ読み(無料)
ものづくりの革新と社会課題の解決
ニコンが描く「人と機械が共創する社会」
ZDNET×マイクロソフトが贈る特別企画
今、必要な戦略的セキュリティとガバナンス