これをやるプロジェクトは炎上する！典型的な炎上パターン10選と対策
プロジェクトが炎上、すなわちQCDが守れず残業地獄に陥ることはよくあります。システム開発プロジェクトは特に炎上が多く、炎上したプロジェクトでITエンジニアたちが疲弊していく様をデスマーチと呼びます。
残念ながら下請やメンバーという立場でプロジェクトをコントロールすることはできません。IT業界では下請として働いている人たちは炎上プロジェクトに出くわしてしまうリスクもあります。
しかしプロジェクトをマネジメントする側として言わせてもらうと、炎上するプロジェクトには典型的なパターンがあります。マネジメントをする側としては、炎上パターンを知って避けるということはできます。
これで炎上が無くなるわけではありませんが、マネジメントをする人にとっては炎上パターンはアンチパターンとして参考になります。
今回は典型的なプロジェクトが炎上するパターンを紹介します。そして炎上しないための対策や考え方を紹介します。
マネジメント経験が豊富な方にとっては当たり前かもしれません。しかしマネジメント初心者やこれからマネージャーを目指す方には是非ともアンチパターンとして知っておいて欲しいです。
Contents
楽観的なスケジュール
よくある楽観的なスケジュール
炎上するプロジェクトが立てるスケジュールは楽観的という特徴があります。おいおいそんなに上手く行くのかよ！と言いたくなるスケジュールです。
すべてが想定以上に上手く進む前提で、想定外が一切起きない前提でスケジュールを組んでいるのです。
これではスケジュールがドンドン遅れていくのは当たり前です。そして残業でカバーすることになり、みるみると残業時間が増えていきます。ましてやリスクが顕在化すれば収拾が尽きません。終電や休日出勤を繰り返すことになります。
意外とこんないい加減なマネジメントが普通に蔓延っているから驚きです。
楽観的なスケジュールの例
ちょっと例を挙げてみましょう。
Aさんは東京から伊勢神宮に旅行に行こうと考えました。
東京からですと新幹線で名古屋まで行って、名古屋から乗り換えて伊勢に向かいます。
ここで乗換時間をどれだけ取るかです。何も考えないと乗換に10分あれば十分かなと思ってしまいます。その想定でスケジュールを作って、友人と現地で待ち合わせをする約束をしたらどうなるでしょう？
ここで落ち着いて考えてみましょう。
名古屋駅はとても大きい駅です。下手をすると迷ってしまい、乗換に30分くらいかかるかもしれません。
また東京から名古屋までのぞみなら1時間ですが、昼食はどうしましょう？名古屋で取るか伊勢まで我慢するか。名古屋ですとお店が混んでいて並ぶのに10～20分かかるかもしれません。
また伊勢までの電車は東京や名古屋の電車よりも本数が少ないでしょう。ホームでの待ち時間も多く発生します。
この辺りを考えず、上手く行くとかこんなもんだろという考えで作るスケジュールが楽観的なスケジュールです。
スケジュールを作るときは情報収集や調査・検討をしっかりやって、高確率で達成できるようにしましょう。
スケジュール作成とは作戦計画を立てること
スケジュール作成はスケジュール表を埋めることやWBSを作ること、ガントチャートを作ることではありません。作戦計画を立てることです。
マネージャーがスケジュールを作るときは、自分は将軍としてこの部隊を率いて、こういう作戦で勝利を手にすると考えるつもりで作りましょう。
楽観的な思考と悲観的な思考を使い分ける
なぜ楽観的なスケジュールを作ってしまうかというと、人間は楽観的な生き物だからです。上手く行くことだけを考え、上手く行かないことや想定外のことは考えないようにするのが人間です。
普通に生きている分は問題ないかもしれませんが、マネジメントにおいては非常に危険な考え方です。
マネジメントをやる際には、楽観的な思考と悲観的な思考を使い分ける必要があります。スケジュール作成は慎重に、問題解決策の選定は楽観的に行きましょう。
計画を死守しようとする
炎上プロジェクトは計画を死守しがち
仕事は想定外がよく起こります。スケジュール通りに行かないケースはよくありますし、見積通りの工数にならないこともよくあります。
そんなとき炎上プロジェクトがよくやることが、当初の計画を死守しようとすることです。
例えば毎日のように深夜まで残業し、休日出勤も常態化しているのに、リスケをしないプロジェクトを私はいくつも見てきました。
技術的にこの仕様は無理があると解っていても、何が何でもその仕様で作らないといけないんだと譲らないプロジェクトもありました。
炎上プロジェクトが計画を死守する理由は、当初の約束を守れませんでしたと言えないからだと私は推定しています。本当の理由はプロジェクトによって違うでしょうけど。
ダメなら計画を変更しよう
プロジェクトを上手に進めるためには臨機応変な対応が必要だと私は考えています。想定外は仕事に付き物だからです。
もし想定より難しい問題が発生し、当初の納期を守れない場合は、リスケも考える必要があります。
炎上プロジェクトではリスケを徹底的に避け、納期直前になってからリスケを行います。しかも1週間など少しずつ伸ばします。それでは足りないと明らかに解っているのにです。
もしリスケするなら、ガッツリとやりましょう。これで次こそできると思えるスケジュールを作るのです。
リスクを考えない、あるいは起きてから考える
炎上プロジェクトでは楽観的なスケジュールが作成されているという話をしました。
それとも関わるのですが、炎上プロジェクトでは楽観的に考えてリスクを考えていないケースが多いです。
リスクは必ず起きます。リスクをどう管理するかはマネジメントにおいてとても重要です。私はリスク意識がそのまま残業時間に響くと考えています。
よってプロジェクトを炎上させないためにはリスクを意識しましょう。作業毎に、選択肢毎に、どのようなリスクがあって、どの程度の影響力と発生率があるのか、どんな対策が打てるのかを考えましょう。
また嫌な予感やグレーゾーンなこと、どうしても気になることも要注意です。そういうことは後で問題になる可能性があります。これもまたリスクです。
そして事前対策で潰して行きましょう。
フィット&ギャップができていない
フィット&ギャップができていないプロジェクトは高確率で炎上する
私はフィット&ギャップができていないプロジェクトが炎上するのを幾度も見てきました。そしてフィット&ギャップができていないのに炎上していないプロジェクトを見たことがありません。
フィット&ギャップとは目的に対して手段がどれだけ合っているかということです。
フィット&ギャップの例
ちょっと例を挙げてみましょう。
Aさんはプロジェクトの打ち上げの幹事になりました。
参加者の希望を聞いてみたら、Bさんはガッツリとビールを飲みたい、Cさんは日本酒がいい、Dさんは最近は寒いから鍋が食べたい、Eさんは今回のプロジェクトは大変で疲れたから、贅沢して寿司がいいとのことです。
すべての要望を満たすお店を探すのは大変です。かといって誰かの要望だけ聞いて、他の人の要望は却下するのも考えものです。
Aさんはお店の種類毎に各自の要望をどれだけ満たせるかを表にしてみました。
| お店の種類 | 寿司屋 | 居酒屋 | 鍋屋 |
| ビール | ○ | ○ | ○ |
| 日本酒 | ○ | ○ | △ |
| 鍋 | × | △ | ○ |
| 寿司 | ○ | △ | × |
こうしてみると、条件を満たしていないお店があることが解ります。○はフィットしていて、△は微妙だけど一応ある、×はないのでギャップです。
実際にはこんなに単純じゃないですが、ここでは解説のために単純化しています。
フィット&ギャップで問題が発生することがある
ここで問題なことは、企業が製品を導入するときにフィット&ギャップがちゃんとできていないケースです。この場合に導入プロジェクトが炎上します。最悪の場合、頓挫して中止になることもあります。
製品の導入に当たり、自社にとって必要な機能や要件を洗い出します。そして製品毎にどれだけ満たせるかを検討します。
ここで問題なのが、他社も導入しているから、最近流行っているから、実績が豊富だから、有名企業が使っているから、営業のプレゼンが上手いからなどの理由で決めることです。
あるいは有名企業の製品だからとか安いからなどの理由や、えいや！と勢いで決めてしまうことも問題です。
こうなってくると、自社に合っているかどうかを考えていません。そしてプロジェクトが進んで行くと、実はこの製品じゃ上手く行かないとか、やりたいことができないという問題が発生します。問題の解決に多くの時間とコストを費やす羽目になります。
例えて言うなら、郊外で畑仕事でもやりながら広い家で伸び伸びと暮らしたい人が、駅近でデザインのいい物件を見つけて惹かれて、そちらにしてしまったようなものです。便利には便利だけど、家賃は高いし狭いでしょう。やりたかった畑仕事もできません。
どちらが単純にいいかではなく、自分はどんな要素が必要かという観点で、満たしていることと満たしていないことを洗い出して検討することが大事です。これがフィット&ギャップ分析です。
ちなみにDX時代になってIT投資が増えていますが、それゆえに益々フィット&ギャップが大事になっています。こちらにDXとフィット&ギャップをテーマに記事を書いていますので、参考にしてみてください。
根性論に頼る
炎上プロジェクトは根性論に頼ります。とにかくがむしゃらに働け！と言ったところです。
ここまでで炎上プロジェクトは何でも上手く行く想定、何か起きても計画を死守するということを書いてきました。
つまり作戦もへったくれもないのです。頑張って何とかするという考えです。
またルールが異常に厳しいプロジェクトも存在しますし、上が下へ丸投げを平然とするプロジェクトも存在します。
ルールが異常に厳しいプロジェクトでは、不具合が見つかったらテストを全てやり直しというものもありました。罰則で人を管理するやり方で上手く行くはずがありません。
とにかく頑張るでは根性論です。マネージャーは戦略と戦術で勝負しなければいけません。戦略とはやることとやらないことの選定や方針、方向性を決めることです。戦術とは上手く行く方法を考え、実践することです。
ステークホルダーとの関係構築をしない
ステークホルダーとの関係構築はマネジメントで欠かせない仕事です。
顧客といい関係を築かない、協力会社といい関係を築かない、メンバーといい関係を築かないということになれば、仕事は上手く行きません。
顧客や協力会社と対立したり、責任の押し付け合いをしているようでは、何もかもが上手く進みません。
炎上プロジェクトでは顧客との対立はよくあり、問題や進捗遅れを隠すということもよく行われます。スケジュール表を内部向けと外部向けに作り、順調ですと嘘をついているプロジェクトを見たこともあります。
また協力会社に対しても、仕事だからやれよでは通じません。それでは最低限のことしかやってくれないでしょうし、投げやりな仕事をされてしまう可能性もあります。やっつけ仕事になれば認識違いだって多々起きるでしょう。
ステークホルダーにはしっかりと礼儀を払い、協力関係を築きましょう。顧客や協力会社の協力を得られれば、仕事はスムーズに行きます。
自分たちの凄さを見せつけてくれる！という人もいますが、そういう自己満足は脇に置いた方が安全に仕事を進められます。
手段が目的化する
手段の目的化もまた典型的なプロジェクトが炎上するパターンです。
例えば最近はAIが流行っています。それゆえAIを導入して何かしたいと考えている会社は少なくないかもしれません。また生成AIが増えたことで、個人でもAIを導入して何かしたいと考えている方も少なくないかもしれません。
しかしAIもツールです。何かやりたいことがあって、AIを使うと便利だからAIを使うのです。AIを使うこと自体を目的化しても、使い道がありません。
例えばcanvaは非デザイナーでもそれなりのデザインをするためのツールです。これもAIが使われています。
ここで重要なことはAIを使いたいからcanvaを使うのではないということです。それではただ遊んでいるだけでしょう。
重要なことは、イラストとかプレゼン資料のデザインをデザインの素人がやるのは難しいので、ツールとAIの力でそれらしいものを作るということです。目的はそれらしいクオリティのイラストやプレゼン資料の作成です。
DX時代になって、AIを使って何かをするのではなく、AIを使うこと自体が目的化して炎上し、頓挫したプロジェクトを見ました。手段を目的化してはいけません。
また最初は目的がしっかりしていたけど、プロジェクトが進むに当たって問題が増えてくると、手段が目的化します。すなわちプロジェクトで作っているものや使っている製品を活用することが目的化し、本来の目的を見失うこともあります。
プロジェクトが上手く進まなくなったときや、難解な問題に当たったときは、本来の目的は何だったのかを思い出してください。
手段の目的化についてもDX時代というテーマで記事を書いていますので、参考にしてみてください。
前例や一般論に固執する
前例がないからできない、毎回このやり方でやっているからこの通りにする、普通はこうでしょ？というセリフを私は聞き飽きています。
これらはプロジェクトを炎上させるプロジェクトマネージャーがよく言うセリフです。
前例がないからできないではいつまで経ってもできません。そういうときは勉強をして必要な知識を獲得しましょう。そして反復型で実験しましょう。仮説検証型アプローチでやれば、知らないことがあっても進められます。
毎回こうしていると言っても、今回は状況が違えば多少アレンジしてもいいです。型は素早く知識を吸収し、素早くミスなく作業する上で有効です。しかし型に忠実である必要はないです。
そして普通はこうでしょ？はろくなものではないです。
マネジメントはスケジュール表やWBS、ガントチャート、課題管理表など一般的に必要とされるものを作って、進捗管理しながらそれらを更新していけばできるものではありません。
部隊を率いる将と同じように、状況を見て戦略や戦術を立てて目的を達成することがマネジメントです。
普通ならやることだけをやってマネジメントができるわけではないのです。よって普通に囚われると抜け漏れや想定外が沢山発生し、プロジェクトは炎上します。
そもそもプロジェクトは独自性があるものです。個別の目的や制約条件があるからプロジェクトなのです。よって一般論で全てが通じるわけではありません。
判断軸（コンセプト）がない
判断軸に沿って決めることが大事
プロジェクトにはコンセプトがあります。一番最初にこのプロジェクトは何を目指すのかを決めます。基本的には目指すことに近づけることならやる、目指すことと関係なければやらないということになります。
マネジメントをやっていると、意思決定が常につきまといます。決めるということを何度もしなければいけません。
そんなときに何を基準にするかという判断軸が必要です。それが当初に目指していたものやコンセプトです。
製品開発やクリエイティブ系の制作プロジェクトであれば、製品や作品のコンセプトすなわちこういう製品・作品を実現するというものがあります。
これこそが判断軸であり、これを実現できるかどうかで判断します。決して一般論や普通はこうという判断をしてはいけません。
判断軸に沿って決める例
例えばAさんはアットホームにくつろげるカフェを出店したいとします。
コンセプトはアットホームにくつろげるカフェです。これが顧客にとっての価値でもあり、Aさんが出したいお店の特徴かつ価値です。
Aさんは家具屋に行っていいテーブルや椅子を探すことにしました。そしたらテーブルと椅子のセットが特売でなんと半額引きでした。しかし狭くて窮屈な感じがします。一人当たりのスペースは腕を横に広げる余裕すらなさそうです。安さが売りのチェーン店みたいです。
お買い得だからこれを買ってお店に置きたくもあります。しかしここでコンセプトを考えてみると、Aさんのお店ではゆったりくつろげる広いテーブルやソフトな椅子の方がに合いそうです。
これがコンセプトに沿って判断するということです。
この選択肢はプロジェクトの目的やコンセプトに合っているか？マネジメントをやっていると選択に迷うことはありますが、そんなときこそ自分にこう問うてみてください。
判断軸を無視して決めることの弊害
先ほどのAさんのカフェで、半額引きのテーブルと椅子のセットを買ったとしましょう。これでお客さんはくつろげるでしょうか？
お店はアットホームにくつろげるという宣伝文句なのに、安さを売りにしているチェーン店のように狭いスペースでコーヒーを飲んでも、ゆったりはくつろげないでしょう。チェーン店のカフェにはこういうスペースのお店もありますが、Aさんのお店のコンセプトには合いません。
結局お客さんがゆったりくつろげないということで、顧客満足度や顧客の滞在時間に影響が出そうです。改善策として、もう少しゆったりと広めのスペースを取れるテーブルを買うことになるでしょう。
判断軸に合わない選択を取ると、やり直しになったり、全然効果が無かったり、進む方向を間違えたりします。
残業で解決しようとする
仕事には想定外が付き物ですし、上手く行かないこともよくあります。しかしそうしたときに残業でカバーしようとする人はとても多いです。
1日当たり1時間程度の残業でカバーできるならしてもいいでしょう。しかし常習的に残業しなければいけない、1日に3～4時間、月に60～80時間もの残業をしなければカバーできないのなら、そもそも計画を見直す必要があります。
残業が沢山発生している時点で計画は破綻しています。当初の作戦が通用しないことを示しています。作戦を立て直すべきです。
しかしこんな残業時間を普通としているプロジェクトは沢山あります。
まるで残業が狼人間を撃つ銀の弾丸と信じられているかのようです。世間一般では残業すれば何でも解決すると思われていますが、違います。そもそも残業をあまりしなくてもQCDを守って終わるような計画を立てましょう。
残業は銀の弾丸ではないですし、万能な手段でもないです。残業には多くの犠牲を伴います。残業が多ければ多いほど、マネジメントが上手く行っていないと自覚すべきだと私は考えています。
現実には残業が多ければ多いほど頑張っているとされますが、それはただ残業している自分に酔っているだけです。
終わりに
私は炎上プロジェクトをいくつも見てきました。ときには炎上プロジェクトに配属されてしまったこともありました。
炎上プロジェクトを見てハッキリと解ったことは、マネジメントに問題があるということです。
ほとんどの人は炎上プロジェクトを経験しても、愚痴を言って終わりです。自分でマネジメントすることで、炎上しないプロジェクトマネジメントをしようなんて人は見たことがないです。だから私は自分で実践しています。
今回紹介した通り、プロジェクトが炎上する典型的なパターンは存在します。これらをアンチパターンとしてしっかり学んで、健全なプロジェクトマネジメントをしていきましょう。
