炎上プロジェクトを立て直す唯一の方法はリスケだ
炎上プロジェクトはどうやっても手に負えないものです。かといって炎上プロジェクトは絶対になくならないでしょうし、炎上させたくて炎上しているわけでもないでしょう。
DXが叫ばれるようになった昨今では、ますますプロジェクトマネジメントの重要性が増しています。今後も炎上プロジェクトが発生してしまう危険性があります。
そうなると炎上させないように進めることと、炎上したときの対策を知ることが必要になります。
正直に言って、炎上プロジェクトを立て直す唯一の方法はリスケだと私は考えています。炎上プロジェクトでは計画が破綻しているため、計画自体を立て直すしかありません。
今回は私自身が炎上プロジェクトをいくつか経験したこと、そして長年マネジメントに携わり定時帰りしてきたことから、炎上プロジェクトの立て直しについて解説します。
プロジェクトが炎上してしまった経験がある方や、炎上しないようにマネジメントしたい方などの参考にされば幸いです。
Contents
炎上プロジェクトの特徴
残業が多すぎる
炎上プロジェクトは残業がとても多いです。80時間や100時間は普通で、酷いプロジェクトだと160時間くらいあったりします。
プロジェクトが炎上しているかどうかを測るのに解りやすい指標が残業時間です。
私自身も管理職がマネジメントに失敗したプロジェクトで、サービス残業を毎月200時間もしたことがあります。
また協力会社の助っ人として参加したプロジェクトが、残業時間が160時間くらいだったということもあります。
そんな体験から残業は下らないと考えていますし、残業は下らないという記事も書いています。こちらの記事にもサービス残業を200時間した体験を書いています。
納期に間に合わない
炎上プロジェクトは残業がとても多いのですが、その理由は納期に間に合わないからです。納期に間に合わせるために残業でカバーしているのです。
炎上プロジェクトは、無制限の残業をすることで必死に納期に間に合わせようとしています。しかしそんな長時間の残業をしても、まともな品質の成果物は作れませんし、疲労で効率も全く出ません。
それでも納期に間に合わせようと必死に無制限の残業をするのが炎上プロジェクトです。
しかしそもそも論として、間に合いようのない納期を死守するというおかしなことをしているのが炎上プロジェクトです。
品質がボロボロ
炎上プロジェクトは無制限の残業をしています。そんなに残業したら疲労困憊で身も心もボロボロになってしまいます。
当然ながら疲労困憊でボロボロの状態で、まともな品質の成果物を作るなど不可能です。つまらないミスを連発してますます進捗が遅れるだけです。
それでもランナーズハイならぬワーカーズハイになって、納期に間に合わせるべく無制限の残業をするのが炎上プロジェクトです。
間違いなく悪循環です。そんなやり方では次から次へと不具合が見つかり、収拾がつかなくなります。
メンバーが疲弊している
無制限の残業をし続ければ、当然ながらメンバーは疲労困憊となります。疲れないわけがありません。
たまに残業賛美の人がいて、「いくら残業しても疲れない」とか「残業して疲れるヤツは甘えている」などと言います。しかしそういう人はランナーズハイならぬワーカーズハイになっているだけで、疲労に気付いていません。
自分の効率が落ちていることにも気付けず、つまらないミスを連発しているだけです。
無制限の残業を続ければ、みんな疲弊してしまいます。炎上プロジェクトを続ければ、メンバーはいつか燃え尽きて休職や離職をするか、過労で倒れて退場となります。
また炎上プロジェクトでは重々しい雰囲気がフロア全体にあふれています。しゃべる人がいなくなり、しゃべっても愚痴ばかりとなります。でも愚痴が話題になると延々と続きます。
炎上プロジェクトは手遅れの状態
炎上した時点で計画が破綻している
炎上プロジェクトは残業地獄の状態です。しかしそもそも論として、プロジェクトの計画を立てる時点で無制限に残業をすることを前提でスケジュールを引くなどありえません。
つまり炎上プロジェクトではどこかで想定外の事態が起きて、納期に間に合わない状態となったのです。そして納期に間に合わせるために残業を無制限にして仕事を進めているのです。
ということは当初の想定が成り立たなくなっています。つまり計画は破綻したのです。こういうときは計画を見直すことで立て直しを図るしかありません。
炎上プロジェクトで書籍を探したら面白そうな書籍を見つけました。火消し経験が豊富なマネージャーが書いた本です。私も気になったので読んでみたいです。
この本の説明をサラッと読んだところ、炎上したら立て直しを図るようです。私も同じ考えです。計画が破綻したなら、立て直してリスタートするしかありません。
プロジェクトのトラブル解決大全 小さな問題から大炎上まで使える「プロの火消し術86」【電子書籍】[ 木部 智之 ]
残業でカバーしても上手く行かない
先ほども書きましたが、無制限に大量の残業をしても疲弊してしまうので、効率も品質も落ちてしまいます。これでは思うように進みません。
またプロジェクトの状況によっては、どう考えても納期に間に合わないこともあります。残業でカバーするよりも立て直しを図る方が明らかに有効な選択です。
そして何より、無制限の残業をすることでメンバーの幸福度や健康を損ないます。残業でボロボロになった状態でまともなパフォーマンスは出せません。最悪の場合は心身を病んで休職せざるを得なくなってしまうかもしれません。
残業が幸福度や健康を損なうという話はこちらにも書いています。
よってプロジェクトが炎上したら残業地獄を止めて、残業地獄にならずとも完了するように立て直しを図ることが大事です。
例えて言うなら、炎上プロジェクトのやり方はスコップでトンネルを掘るのに「人海戦術で夜通し休みなくやればなんとかなる！」と言っているようなものです。機械がなければどう考えても無謀です。
人員追加しても効率はすぐに上がらない
炎上プロジェクトでは次から次へと人員が追加されます。人海戦術で解決しようとマネジメント層が考え出すのです。
しかし遅れているプロジェクトに人員を追加するのは悪手であることが知られています。それは人月の神話という本に書かれています。
プロジェクトに人員を追加しても、プロジェクト独自の知識やプロセス、必要なスキルなどを教えなければいけません。そのためどうしても教育コストが発生します。また人が増えれば増えるほどコミュニケーションコストも上がります。
プロジェクトは人海戦術と長時間労働ではない方法で進めるべきです。
炎上プロジェクトをリスケして立て直す際の観点
炎上プロジェクトの状態について解説したところで、立て直しについて解説します。
私は自分自身が炎上プロジェクトをメンバーとして体験した経験と、マネジメントを長年やって定時帰りを繰り返してきた経験から、炎上プロジェクトは立て直しを図るしかない、そして立て直すにはリスケしかないと考えています。
ここでは炎上プロジェクトをリスケする上で気を付ける観点を書いていきます。
中途半端なリスケをしない
リスケをするなら中途半端にやってはいけません。ガッツリとやりましょう。これは2010年頃に日経システムズという雑誌で、マネジメントを小説形式で解説するという連載記事に書かれていたことです。
私が参加させられてしまった炎上プロジェクトのいくつかは、中途半端に2週間ずつ納期を延期するということを繰り返していました。毎回のように納期直前になって納期を2週間だけ延期するのです。
リスケ直後はあまり残業せずに帰り、数日で残業地獄の生活に戻るのです。結果的に納期には間に合わず、また延期します。
こんなことを繰り返しては、いつすべての成果物が完成するのか解りません。「一体いつになったら終わるんだ？」とか「またかよ…」と私も思いましたし、そういう声も周りから聞こえてきました。
こんなやり方では顧客もメンバーもプロジェクトマネージャーを信用できなくなります。
よってリスケをするならガッツリとしましょう。何度も中途半端な延期を繰り返して、関係者を失望させてはいけません。それでは単なるその場しのぎであり、根本解決になりません。
リスケは中途半端にではなくガッツリとやろうという記事も書いています。こちらも参考にしてみてください。
ゼロベースで考える
リスケをするときはガッツリとやりましょうと解説しました。
ここで重要なことはゼロベースで考えることです。体制も納期もスコープもゼロベースで考え直しましょう。新規プロジェクトをやるかのように計画を立てるのです。
ここで納期をずらすのは解るけどスコープは変えられるのか？と疑問に思ったかもしれません。
私が見た炎上プロジェクトの例では、納期までに絶対というわけじゃない機能を納期の後に開発するという選択をしたプロジェクトもありました。そのプロジェクトは顧客側のデッドラインが決まっていたためにこういう選択をしたのだと私は考えています。
基本的には体制と納期を確実なものにし、スコープは変えづらいものだと私は考えています。しかし顧客側にどうしても譲れないデッドラインがあるなら、スコープを縮めてでも納期を優先するのもありだと私は考えます。
ただしここでスコープを調整せずに納期を縮めてはいけません。ましてや人を増やせばスコープを縮めずとも納期を短くできると考えるのは危険です。
理由は人月の神話という本を読んでください。人を増やしても教育やコミュニケーションのコストがかかるから、生産量は人数に比例しないのです。
またアジャイルサムライという本には、納期荒ぶる四天王という表現が出てきます。時間、予算、品質、スコープの4つを荒ぶる四天王としています。
ここで唯一変えられるのがスコープだとしています。納期を延期することは難しく、予算を増やすことはほぼ無理、品質を守らねばクレームやリコールにつながります。よってスコープしか変えられないという話になります。
アジャイルサムライ 達人開発者への道 [ ジョナサン・ラスマセン ]
もっとも炎上プロジェクトでは納期に間に合わないので、まずは納期を確実に達成できる日にずらすことです。そうした上で体制（スキルや人数、会社としてのサポートなど）や進め方、スコープを検討しましょう。
反省点を活かした計画を立てる
リスケして次こそ達成可能な計画を立てるためには、炎上原因を徹底的に調べる必要があります。
先に断っておくと、私自身は炎上プロジェクトに放り込まれたことはあれど、炎上プロジェクトをマネジメント側として立て直したことはありません。しかし炎上プロジェクトを反面教師とすることで、定時帰りを繰り返してきました。
つまりプロジェクトが炎上した原因を知り、対策を立てることで、炎上を防止したり、残業を減らしたりできるのです。
私は自分自身が炎上プロジェクトに参加させられて、炎上プロジェクトの悲惨な状態を見た経験から、典型的なプロジェクト炎上パターンがあると考えています。こちらの記事にまとめています。
これを読んでの通り、マネジメントに問題があるからプロジェクトの炎上につながります。多くは知識や注意力、リスクに対する意識などがあれば防げることです。
こちらも参考にしつつ、炎上原因と対策を洗い出し、リスケ後は同じ失敗をしないようにしましょう。
次こそは確実に完了できるという計画を立てる
リスケで大事なことは次こそ確実にプロジェクトを完了させられるという計画を立てることです。
先ほども書きましたように、中途半端なリスケでは何度も繰り返すことになるので、顧客やメンバーの信用を失います。
ここまで解説したゼロベースで新規プロジェクトのように考えることや、炎上原因を分析して対策を取ること、安易に人海戦術で乗り切ろうとしないことなどを踏まえて、確実な計画を立ててください。
それが顧客に成果を納めることやメンバーを潰さないことにつながります。
終わりに
炎上プロジェクトはIT業界のとても悩ましい問題です。
またDXが叫ばれるようになった昨今では、IT業界に限らずあらゆる企業がプロジェクトの失敗に直面する可能性があります。そんな中で炎上してしまうプロジェクトが出てくる可能性も否定できません。
だからこそ炎上しないように進めること、そして炎上原因を知って対策を立てることが大事です。そして炎上してしまったら、原因や対策を把握して確実に完了できるように立て直すことです。
私もまだまだ勉強途中であり、マネジメントの道に終わりはありません。今後もいい方法を学んだら記事を書いていきます。
