炎上プロジェクトのヘルプに入って欲しいと頼まれたけど、なんだかヤバそう…。炎上プロジェクトに巻き込まれると何があるんだろう？何をしたらいいのかな？」
この記事ではそういった悩みを解決します。
この記事でわかること
- プロジェクト炎上とは？
- 炎上プロジェクトに巻き込まれるとどうなる？
- 炎上プロジェクトを火消しするためには？【体験談】
- なぜプロジェクトは炎上するのか？
- プロジェクトを炎上させないためには？
記事の信頼性
この記事を書いている私はエンジニア歴８年で、先日炎上プロジェクトのヘルプに呼ばれ（＝巻き込まれ）、というより、「ちょっと火消ししてきてくれる？」という雑な依頼を受けて、、、火消し対応に追われました。
その経験から、炎上プロジェクトを『予防』する方法、『対策』する方法を解説できます。
エンジニアなら１度は『炎上』という言葉を聞いたことありませんか？
ソフトウェアを作る会社であれば、社内のどこかのプロジェクトが炎上しているかと思います笑
ただ、まだ炎上プロジェクトに巻き込まれた経験がない人は、もし自分が巻き込まれたら…と不安に思いますよね。
炎上プロジェクトに巻き込まれると精神的にも体力的にもかなり削られます。
予め心の準備をしておくとともに、早く消化させるためにどうすれば良いか？逆に、炎上プロジェクトでやってはいけないことは何か？を知っておくことが大事です。
何も知らずに炎上プロジェクトに参加すると、ますます炎上が広がりつらい日々を過ごすことに…
そこで本記事では、
- 炎上プロジェクトを消火してゴールに導く『対策』方法
- プロジェクト炎上を未然に防ぐ『予防』方法
上記の大きな２つのテーマについて解説します。
この記事を読むことで、エンジニアが炎上プロジェクトを予防し、対策するために何をすべきかが分かりますよ。
プロジェクト炎上とは？
プロジェクトの炎上とは、用語として明確に定義がされているものではなく、事態が収束しないことを比喩しているものです。
ソフトウェア開発におけるプロジェクト炎上とは、QCDが意味するものが予定と乖離してしまい、あらゆる策を講じてなんとかしようとしている状況を表します。
ソフトウェア開発のQCDとは？
- Q：Quality。ソフトウェアの品質
- C：Cost。開発に必要な費用
- D：Delivery。 開発するために必要な期間・納期
プロジェクト炎上の例
- テストフェーズでたくさんの不具合が見つかり、直しても直しても収束ののメドが見えてこない
- 納期通りに開発を終えられそうになく、メンバーの残業時間や休日出勤を増やしたり、増員したりする
- 当初の見積もりと実際のコストが大幅に乖離した状況（大赤字）
「炎上」という表現は、最近では芸能人の発言に対してSNSで賛否両論で盛り上がっている状況で使われるので、馴染みがある人もいるかと思います。
炎上プロジェクトに巻き込まれるとどうなる？
炎上プロジェクトはなんとかして『火消し』、つまり、開発を終わらせるためにいろんな策が講じられます。
そのため、開発メンバとして炎上プロジェクトに巻き込まれると、嬉しくない事態に陥ります。
- 残業時間＆休日出勤が増える
- 人が壊れていく過程を見ることができる
- 倒れていく人がちらほら
残業時間＆休日出勤が増える
炎上プロジェクトを火消しするために、まずは元々プロジェクトに携わっていた開発メンバーの過労働、残業や休日出勤によりなんとかしようとします。
それでも収集がつかない場合は、外部のプロジェクトからヘルプで増員することもあります。
ヘルプで参画する人は、元々携わっているプロジェクトと掛け持ちになるので、残業時間が増えることになります。
人が壊れていく過程を見ることができる
「空を見上げるマネージャー、机の上には大量のコーヒーやレッドブルの空き缶、髭面や寝癖など、身だしなみがだんだん適当になり、やけに独り言が多い。彼にはいったい何が見えているのだろうか…。」
そんな不安と疑問を抱くほど、プロジェクトリーダーの壊れゆく様が見れたりします。
普段あんなに元気な人が別人のようになってしまう様子は必見です←
倒れていく人がちらほら…
残念ながら過酷な過労働に耐えきれず体調を壊してしまったり、精神的に病んでしまう人もいます。
別プロジェクトに移動するのであれば良いですが、倒れてしまい、その後に職場移動や退職してしまった人も…。
プロジェクト炎上、ダメ、絶対。
スキルがめっちゃ身につく
ダメなところが目立つプロジェクト炎上ですが、実は良いところもって、乗り切るとめっちゃスキルが身につきます。
というのも、炎上プロジェクトは窮地に追い込まれているので、時間のない中で課題解決や、圧倒的な生産性が求められます。
すると、真剣に頭を働かせる機会が増えるので、知らず知らずにスキルが身につくんですよね。
僕が組み込み機器開発の炎上プロジェクトにヘルプで参画したときは、LinuxのOSやカーネル、ドライバなどの下回り部分の不具合を解析したことで、めっちゃ知識が増えました。
自分で勉強すれば良いんですが、追い込まれるとやらざるを得ない状況なので、自然と知識が身につきました （笑）
補足：炎上プロジェクト＝デスマーチ
ちょっと余談。
炎上プロジェクトに関わって開発することはデスマーチと呼ばれたりもします。
度が過ぎた過労働をしても終わることのない開発をしている様は、死に向かって行進しているかの如く…。
炎上プロジェクトを火消しするためには？【体験談】
エンジニアとして働くのであれば、誰しも1度は経験するであろう炎上プロジェクト。もしあなたが炎上プロジェクトに巻き込まれたとき、何ができるでしょう？何をすれば良いでしょう？
一般的にプロジェクトの火消しは、プロジェクトを管理するPLやPMが次のような対策と調整を行います。
- 納期交渉
- コスト交渉
- 人員調整
一方で、PMやPLではなく、開発要員やテスターとして追加でアサインされる人の方が多いと思います。
その場合はどうすればよいでしょう？プロジェクトを火消しするために求められる働きとはなんでしょう？
ここでは、私が炎上プロジェクトに設計者として参画し、無事に火消しをした実体験をお話しします。
- プロジェクト規模：60人月（≒6000万円）
- メンバ数：依頼元３人、請負先１０人程
- 納期まで：残り１ヶ月
現状を正確に把握する
プロジェクトをゴールに導くためには、まずは現状を正確に把握することが必要です。何か対策を打つにしても、課題を捉え間違えて対策をしても効果は出ません。
参加したプロジェクトは以下の状況でした。
- 機能実装が完了していない
- マルチスレッドプログラミングが怪しい
- 不具合が多くテストの消化が遅れている
- 不具合が多く解析が追いついていない
- 構造設計者が不在（倒れた…orz）
- このままだといつ完了するか？が不明。
情報を見える化する
見つけた不具合はリストで管理されていたものの、ステータス管理や担当割り当ては不十分で、進んでいるのか、停滞しているのかよく分かりませんでした。
そこで、不具合件数の増減や担当者毎の不具合数などを見える化することを行い、以下の情報を見える化しました。
- 不具合は増えているのか？減っているのか？
- 誰が多く不具合を抱えているのか？
- 不具合が多く出ている箇所、原因は何か？
- 解析が難航している不具合はないか？
開発担当の立場からすると、ただでさえ精神的につらい状況なので、少しでも明るくなれる要素が欲しいんですよね。
不具合の残件数が減少傾向にあったり、自分が担当の不具合が減っていたり、ちょっとした成果が見えるだけで精神的にかなり違います。
根本原因に対して対策を打つ
状況を正確に把握し情報を見える化することで、プロジェクト炎上の本質的な原因が見えてきました。
状況と本質原因、それらに対して行った対策は以下の通りです。
| 問題点 | 根本原因 | 対策 |
| データベースを含むデータフロー、プロセス間の連携など、構造設計不備による不具合が多い | 構造設計者が不在（前任者が倒れた）、メンバが途中で入れ替わり＋ヘルプ参加者あり、で統率が取れていない | ・構造設計をレビュー、怪しい部分に品質向上策を実施 ・構造設計関連の不具合の対策方針は私のレビューを受けるよう統率 |
| 不具合が多くテスト消化が進んでいない | テスターが不具合解析も同時に実施、消化計画が機能していない | テスターが不具合解析せず、不具合を出し切るために消化を優先させる |
| 未実装機能の作成中のコードはマルチスレッド制御の設計が不十分で品質懸念あり | 実装者の実力不足 | スレッド制御周りを重点的にリファクタリング（ほとんど、フルスクラッチした）。未然に品質向上を図る |
| 全体的に品質懸念がある中で、不具合が出ていない部分がある | テストケースが表面的な部分しか網羅されておらず、いじわるテストなど複雑な部分を網羅するテストが組まれていない | ・テストケースを見直し、品質懸念がある部分の不具合を充実 ・不要なテストは削減して工数調整 ・知見者によるテストのヘルプ |
急がば回れ。焦っても仕方がないので、確実に効果があることをコツコツと行いました。
コミュニケーションを増やす
「なんで？作業時間が減っちゃうじゃん？」と思う人もいるかもしれません。
実は炎上しているときこそチームメンバー同士でコミュニケーションをとることが大切です。
なぜかと言うと、結局のところソフトウェア開発は「人」が資産だからです。
- 不具合１つでも、気軽に周りのメンバーと相談できる
- 今日やるべきこと、できたことをシェアすることで確実に進展している実感を掴む
- 進捗共有しつつ、時には冗談を言いつつ、つらい状況ながら明るい雰囲気で取り組めることの精神的安定
実際、状況を共有する日例会や、不具合対策のレビューの場など、コミュニケーションをする機会を増やしたことで、進捗的にもメンタル的にも良い状況に導けたと思います。
体力勝負
「実現可能な計画を立てて、打てる対策を講じ、あとは大丈夫！」
…とはいがないのがソフト開発。
そもそも当初の予定より遅れが出ているのは事実ですからね、残業で時間を確保するなど、多少の無理は必要です。
きれいごとだけじゃダメで、体力勝負出来ることもエンジニアにとって重要な要素。体を壊さないレベルで、頑張るしかないですね。
普段から体力作りはやっておくとよいですよ。
なぜプロジェクトは炎上するのか？
ここからは予防編。願わくばプロジェクトを炎上させないようにコントロールするのが理想です。
では、炎上しないためにはどうすれば良いか？
そのためにも、まずは『炎上する原因』を知ることが大切です。
プロジェクト炎上の責任はPM・PL
まず、プロジェクト炎上は、プロジェクトを管理する立場のプロジェクトマネージャー（PM）やプロジェクトリーダー（PL）の責任です。
プロジェクトが炎上する原因は以下のように様々あります。
- 最初の見積もりが甘く、スケジュール通りに開発が終わらない
- 当初の見積もりよりも開発量が増えたため、実装が終わらない
- 不具合が多くて品質が安定せず、開発が予定通り進まない
原因の本質は開発メンバの見積もりの甘さや設計実装力不足であることは間違いないです。
ただ、顧客や上の人など外部の人から見ると、プロジェクトをコントロールする立場の人が管理できていない、という見方をされます。
| 炎上の原因 | PM・PLに求められたこと |
| 開発メンバの技量不足で品質が悪く、納期に間に合わなかった | メンバの力量を把握してスケジュールを立てられない、もしくは、スキル不足を補うための対策を事前に講じてなかった |
| 当初の見積もりよりも開発量が増えていた | 開発量が増えていることを把握していない、増加コストに対する金額調整や納期調整を行なっていない |
| 不具合が多くて品質が安定せず、開発が予定通り進まない | 不具合の品質管理をせず、問題がありそうな部分に対してQupをするなど対策をしていない |
炎上しやすいプロジェクトの特徴
炎上するプロジェクトには必ずなんらかの理由があります。
私の経験上、以下のような特徴にあてはまるプロジェクトは要注意です。
- ソフトを知らない営業の人が安請、無理な納期で案件を受託する
- 開発の見積もりをする前にスケジュールが決まっている
- 仕様がコロコロ変わる、でも納期は変わらない
- 進捗の遅れが見えない・遅れに対して対策を打たない
- 技術調査が不十分で、実現性が不透明のまま開発を進める
- 10人以上が参加する大きめな開発にも関わらず、ソフトの構造設計をしない
- ソフト設計の良し悪しを判断できる人がいない
- 設計者やコードレビューがない、または不十分
プロジェクトを炎上させないためには？
今回の炎上プロジェクトの経験を踏まえた私の結論は、
『プロジェクトを管理できるPLと、ソフトを設計できるリードエンジニアがタッグを組む』
です。
PL・PMがすべきこと
プロジェクトをアンダーコントロールに置くことが全てです。
まずは進捗を見える化し、プロジェクトの進捗状況が正確に把握できていて、チームで共有できていることは必須です。
さらには開発メンバとコミュニケーションを十分取り、体調やメンタル面もケアできる。問題があればすぐに適切な対応を取り、必要があれば納期やコストをクライアントと調整できる。
開発メンバから見たとき、困ったときに頼れる存在であることが重要です。
プロジェクトの成功はPL・PMの力量にかかっています。
エンジニアがすべきこと
一方で、いくら優秀なPMやPLがいたとしても、プロジェクトは成功しません。
要求をソフト仕様に落とし込み、ソフトの良し悪しを判断して形にできるエンジニアの存在も必要不可欠です。
- 開発における技術的な課題は何か？
- 設計のキモとなる部分はどこか？
- コストを抑える工夫は？
- 品質を確保する戦略は？
- 拡張性を見込んだ設計は？
お互いが信頼し合うチーム
PLとエンジニアのパワーバランスが大事で、どちらかが権力を持ちすぎて言いなりになってしまうと上手くいきません。
相手の意見を聞き入れることもあれば、譲れない部分は意見が激突するぐらいがちょうど良くて、お互いを信頼し合わなければできません。
ソフトは人が作るものであり、意思疎通を図るためにはコミュニケーションが必須です。
プロジェクトが成功するチームは、必ず会話ができています。
注意：プロジェクト炎上中にやっちゃダメなこと
逆に、プロジェクト炎上中に1番やってはいけないことは、やみくもに人員を追加することです。
むしろ逆効果になるケースが多々ありますよ。
新しく参加した人にプロジェクトの状況やソフトの中身などを伝えたり引継ぎぐのも時間とコストがかかりますよね？
このあたり、『人月の神話』を読むと良いです。プロジェクト管理の立場になくても、エンジニアであれば一度は読んでおくべき一冊です。
火消しができるエンジニアは価値が高い
プロジェクトの成功はPMやPLが鍵を握っていて、1番評価を受けるのもプロジェクトを管理する立場の人です。
ただ、実際に物を作るのはソフト設計者やプログラマです。
プロジェクトを成功に導けるエンジニアになる→PLやPMから評価される→会社から評価される＝価値が高いエンジニア
です。
評価されるエンジニアは給料も上がりますし、さらにあなたを評価してくれる他の会社に移る道も開けます。
火消しができるエンジニアを目指すことで、他の人達との差別化を図り、価値あるエンジニアを目指しましょう。