コンテンツ
炎上プロジェクトの特徴
炎上プロジェクトは、予定していたスケジュール通りに作業が進められなくなり、プロジェクトの状況が火事場のように燃え上っていることを例えとした言葉になる。
簡潔に言うと、プロジェクトで納期遅延が発生し、その納期遅延を挽回するためにたくさんの人が投入され、徹夜まで残業し、遅れをリカバリーしようと努力する、そんなプロジェクトである。
私が経験した炎上プロジェクトから、次のような炎上プロジェクトの特徴があげられる。
責任者（プロマネ）が無責任
上司である課長がプロマネを担当していたが、プロジェクトの実務をプロジェクトリーダーへ丸投げしており、プロジェクトの状況も確認しないといったプロジェクトだった。週に1度、顧客へ進捗報告を行う際に上司が同行していたが、問題に対して解決しようとせず、適当な言い訳をして、問題を後回しにするといったことがあった。
例えば、この作業アイテムの設計が未実施だがどうするのか？といった顧客からの質問に対して、QAの回答がきていないからこの作業は今はできない。回答がきてからやります、といった感じで後回しにしていた。実際には、QAの回答がなくても作業アイテムの半分ぐらいは進められるとしても、理由があれば問題ないといったスタンスで、何かしら後回しにすることが多かった。そういった行動の積み重ねから、問題が徐々に膨らんでいき、当初の計画から作業が大幅に遅延し、炎上プロジェクトになった。
プロマネは、リーダーに丸投げをしてはいけない。また、問題の先送りは炎上プロジェクトにつながるという教訓を得ることができた。
過少見積もりで工数不足
プロジェクトを始める前に作業見積もりを行うが、この見積もり工数が少ない方向で数字を出してしまうと、あとで工数不足で作業が遅れ、炎上プロジェクトにつながる。私が炎上プロジェクトを経験したなかで、一番多い遅延の理由がこの見積もり誤りである。
見積もりをした数値に関しては、根拠を説明するなど顧客との交渉もあり、なかなか大きな数字は出しにくいところではあるが、やはり必要な作業工数の確保ができなければ、作業遅延につながってしまう。
見積もりは、顧客との交渉の中でも最も重要なフェーズであり、ここでプロマネの腕が試されると自分は思っている。見積もりの手法は世の中でもいろいろ出ているが、見積もりは所詮概算見積もり程度しか出せないので、ここでいかにマージンをとった見積もりを出せるかがポイントになる。見積もりの数字が大きいときに、なぜこんな数字なのか？といった質問がくるが、筋の通った考え方を持った根拠を示すことで、相手も納得してしまうことが多い。交渉術も重要だろう。
直近で経験した大炎上プロジェクトでは、とにかく大規模なプロジェクトで、当初の作業見積もりが、開発規模：160Kstep、生産性：0.4Kstep/人月、開発期間が1年のプロジェクトだった。
当初のリソース計画では、20名程度から徐々に増員していき、30名～40名規模で製造・試験工程を行い、終盤に向けて収束していくようなプロジェクトとして計画をしていた。
ベースとなるソースはあるが、フルスクラッチに近く今回のプロジェクトで大幅な変更を見込んでいるプロジェクトだった。そのため、要件定義、設計を進めていくなかで、見積もりをできていない作業スコープが見つかっていた。しかしこのプロジェクトでは、見積もりの結果大規模プロジェクトになったが、当初のプロマネは小規模プロジェクトの経験しかなく、プロマネの力量不足で、顧客との交渉の中で、当初見積もり外の作業スコープも、作業スコープに含めてしまうことを合意してしまうといった問題や、そもそもの当初の見積もりが多く誤っており、作業規模がどんどん膨らんでいくといった問題が発生していった。
そのため、大幅な作業遅延が発生し、さらに大規模なプロジェクトだったこともあって、大炎上プロジェクトになった。私はこのプロジェクトでは火消し役での参入だったが、参入当時は急遽増員を行い、100名以上の体制でなんとかリカバリをするという散々なプロジェクトだった。
プロジェクトにおける見積もりは最重要。そして、契約の時に分割契約をするとか、要件定義後に再見積もりをできるようにするなど、開発をする際には有利な契約をすることも最重要。プロマネは、契約の知識も必要であることと、顧客との交渉力が必要という教訓を得ることができた。
プロジェクトの作業プロセスが不整備
作業プロセスというのは、いわゆるPMOがいるプロジェクトでは実施してくれるような内容で、さまざまなものがある。ドキュメントのフォーマット、レビューの帳票、品質データの取得といったドキュメント系のものだったり、設計、製造、試験の進め方といった開発のプロセスのやり方だったり、プロジェクトによって異なるが、統一して決めなくてはいけないもののことである。
成熟した組織では、SEPGといったチームがありプロセスを整備する専門のチームもあるが、それは限られた組織で、資金的にも余裕があるところだけだろう。
私の経験では、作業プロセスの不整備が直接炎上プロジェクトにつながったわけではないが、プロジェクトとして正しく整備されていなかったことが原因の一つになったと思うので、例として挙げた。
プロジェクトのサブチームが6つあるプロジェクトで、プロジェクトとして作業プロセスが正しく整備されていなかったことから、設計をやったらチームごとに設計書のフォーマットが異なり、品質データが正しく取れないといったことがあったり、試験をやったら試験のOK,NGにする基準がプロジェクトで統一されていなかったので、試験者の判断で品質が判断されていたりした。
こういった作業プロセスの不整備も、作業遅延につながったり、品質不良につながったりするので、とても重要であると感じている。
炎上プロジェクトが発生する理由
プロジェクトの経験が長いと、プロジェクトの開始時・プロジェクトの参入時にこのプロジェクトはヤバいぞ、という雰囲気がわかる。
①作業のスコープ（プロジェクトでやるべき作業範囲）が決まっていない
要件定義の作業工程で、プロジェクトとしてやるべき要件が決まっていない場合があてはまる。顧客とベンダー側で、要件を決めるために時間を要して、スケジュールが遅延する、というパターンがある。
この場合は、要件を決められず要件定義で日程遅延をした顧客が悪いケースになる。しかし、当初のスケジュールを見直さないプロジェクトが多いため、要件定義で遅延した分が実際に開発を行うベンダー側のスケジュールに影響が出てしまい、その遅延分を責められることがある。
②プロジェクトの終了日であるリリーススケジュールが決まっている
これは自分の経験でもよくあてはまるケースになるが、プロジェクトがはじまったときに、やれるかどうかもわからないまま、開発スケジュールが決められているケースである。本来は、作業見積もりを行って、どれだけの作業量があるかを把握し、どのような体制・スケジュールでプロジェクトを進めるかを判断する。しかし、炎上プロジェクトになりそうなプロジェクトは、はじめからプロジェクトのスケジュールが決まっていて、どうやってもその日程に間に合わないようなプロジェクトがあったりする。
③プロジェクトマネージャのスキルの問題
これは会社・組織として、プロジェクトマネージャを指名した人の問題にもなるが、単純に知識や経験や適性などもあり、プロジェクトマネージャとして、プロジェクトをコントロールできる能力が足りなかったケース。
プロジェクトマネージャに求められるスキルは多岐にわたり、一括請負契約であれば、プロジェクトが始まる前から仕事がはじまる。顧客との商談や、プロジェクトをどのような条件で契約をするか、といったプロジェクト運営ではない作業までも担当する場合がある。
炎上プロジェクトにつながるケースとしては、顧客からの要求を無理に受けてしまい、できるかどうかわからない作業をできると言ってしまう、といった場合もある。
④プロジェクトメンバーのスキルの問題
プロジェクトメンバーには、ある一定の生産性を期待して、1日かければこの作業が終わる、といった作業計画を立てるが、単純にその期待値を達成できないメンバーが多いと、スケジュールの遅延につながってしまう。
ただ、5人～10人程度の少人数のプロジェクトだと炎上プロジェクトににつながる可能性がある。しかし、一般的なもう少し人数の多いプロジェクトでは、プロジェクトメンバーのスキルが低いという要因は、特定の作業が遅延するといったケースがあるだけで、炎上プロジェクトにはつながりにくい。
プロジェクトメンバーのスキルの問題につながるところとして、はじめての分野のプロジェクトを行った場合がある。ノウハウや経験がないため、成果物の品質が悪く、テスト工程でバグの件数が爆発して、バグが収束せずに炎上といったパターンもある。
他に炎上プロジェクトにつながるケースは、開発に必要な設計スキルが不十分なメンバーが担当したプロジェクトで、設計不備、設計漏れが後工程で発覚し、バグが大量発生というケースがある。これも上記と同じように、後工程で品質問題が発覚し、バグが収束しないため炎上のパターンである。
⑤プロジェクト開始時の見積もりが大幅にミスしている
一番炎上プロジェクトになりやすい原因がこれ。プロジェクト開始時の作業見積もりをかなり少なく見積もってしまい、少ない人数でやることになってしまうプロジェクト。実際プロジェクトがはじまって、設計工程やそのあとの工程で作業量が多いことが判明し、見積もりミスに気づくが、既に手遅れ。各作業が納期遅延で炎上するといったケースがある。
3つのプロジェクトが同時に並行するプロジェクトで炎上
過去を振り返ると、なぜか炎上プロジェクトの火消し役として、プロジェクトに参入することが多い。今回は、はじめて炎上プロジェクトの火消し役で参加したプロジェクトのお話を書いてみる。
私が携わっているのは組み込み系の開発プロジェクトのため、開発した製品は一般顧客向けに販売される商品になる。あらかじめ、メーカーが製品の発売日を決めてからプロジェクトが発足するので、発売日までに開発をすることが既に決まっている。納期が大きな制約条件のプロジェクトとなり、日程を遵守することが重要になっている。
今回お話するプロジェクトでは、とある商品を五月雨で開発を行い、3種類発売することになっている。その3種類の商品は、基本的な性能は同じで、追加機能などで3種類の商品の差、および価格に差をつけて販売する予定となっている。ここでは、最初に発売する商品のプロジェクトから順に、A,B,Cプロジェクトと呼ぶことにする。
プロジェクトとしては、ベースとなるモデルがあり、そのモデルのエンハンス（性能アップ・改善）で次の製品を作るというものであるから、難易度はあまり高くないと考えられている。
開発スケジュールと現状
プロジェクトの概要スケジュールは次の通り。
Aプロジェクトは順調に進行し、現在品質保証テストの受け入れ試験を実施しているところである。Bプロジェクトは試験工程完了を予定していたが、現在進捗遅延をしており、試験工程で結合試験を実施中である。しかし、一部の機能ではコーディング作業が完了しておらず、製造工程の作業を実施している状況である。さらにCプロジェクトは、スケジュールでは製造工程完了を予定しているはずが、要件定義も完了しておらず、設計作業すら着手できていないという状況である。
A,B,Cプロジェクトともに、ユーザーとベンダー側で一緒に商品を作っていく方針を持っており、一括請負契約ではなく、準委任契約で作業をしている。
頻繁に発生する作業スコープの変更
商品の特徴として、開発の中盤になると、プロトタイプで動くものが出来上がってくる。それを見たユーザー側から、よりよい商品を提供したい、という考えから開発当初の要求仕様を追加または変更して、仕様変更を行い、機能の追加や変更を行う、といったことが頻繁に行われるプロジェクトになっている。
そのため、プロジェクトの途中で当初計画していた作業に対してさらに、要求仕様の追加および変更が多発し、作業スコープが変わるといった状況である。顧客も柔軟に仕様変更に対応したいため、ベンダー側とは準委任契約をしているという経緯がある。
追加作業が膨れ上がり炎上プロジェクトに
このような形で、常にユーザー側から追加作業が発生しており、当初の予定作業と仕様追加による追加作業が続き、作業者がさばききれない量になったことと、プロジェクトマネージャーが管理しきれなくなって、炎上プロジェクトになった。
問題の原因は、追加作業が多かっただけではなく、今回プロジェクトを担当したプロマネの経験が浅く、スキルも十分ではない人がアサインされていたことも、原因の一つであった。
プロジェクトの特徴と参画の経緯
このプロジェクトの特徴として、複数の機種開発を行うプロジェクトが同時に並行しており、その作業の管理と、追加作業が頻繁に発生するという、作業スコープの変更多発プロジェクトでとても難易度が高い。
過去には、別のベンダーが担当をしていたが、そのベンダーも撤退をしたプロジェクトであった。ユーザー側と縁があり、今回のプロジェクトをはじめることとなったが、上記の通り難易度の高いプロジェクトであり、当初アサインしたプロマネのスキルでは運営が難しくなり、私に応援してほしい旨の要求があって、プロジェクトへの参画となった。
炎上プロジェクトに入って立て直すためにまずやったこと
私がまずプロジェクトに入って確認したことをまとめると、次の通り。
- いま、全体スケジュールでどの位置にいるか？
- どのような体制でプロジェクトが運営されているのか？
- 作業フローや作業プロセスはどのような取り決めがなされているか？
- メンバーは現状について、どのような考えを持っているのか？（モチベーションは大丈夫か？）
- 現状どれくらい作業が残っているのか？直近まであと何をやらなければいけないか？
について確認を行った。
全体スケジュールについて
これは先ほど述べた通りで、Bプロジェクトが遅延、Cプロジェクトにいたってはほぼ手付かずな状況であった。
プロジェクトの体制
当初のプロジェクト体制は、プロジェクトマネージャ（プロジェクトリーダー）1名と、サブチーム(協力会社)が20名という体制のプロジェクトである。20名の中でサブチームが5つあり、サブチームの管理をサブチームリーダーがそれぞれ行っていた。
実際には、作業量増加に伴いプロジェクトで増員を行った結果、各チームに人が分散して、昔からいる有識者がサブチームリーダーになった、というような経緯である。そのため、プロマネからサブチームのリーダーとして任命されたわけではなく、なんとなくとりまとめをすることになっていた。
サブチームリーダーやメンバーとのヒアリングの結果あとからわかったことではあるが、サブチームリーダーの中には管理が苦手な人がおり、メンバーの管理作業が自分の作業ができなくなるくらい、大きな負担となっていたこともわかった。
プロジェクトの進捗管理方法
最近ではツールを使ってさまざまな便利なプロジェクトの進捗管理手法が出ているなか、顧客の体質もあって、Excelベースでの管理手法が行われている。
だいたいのイメージは以下の通り。作業アイテムのWBSがあって、担当者が割り振られていて、作業工数に応じた作業期間が割り当てられる、という一般的な作業の計画表になっている。これを進捗管理表と呼ぶようにしている。
作業フロー・作業プロセスについて
現状を整理してメンバへ確認したところ、作業プロセスが一番の問題点として浮き上がった。
作業プロセスの問題点①
プロマネからメンバーに対しては、作業アイテムについて進捗管理表の通り進めるように指示が出ている。メンバーはその指示に従って日々作業を進める。しかし、メンバーやサブチームリーダーから、問題・課題があって作業が進められなかったり、予定工数通り終わらない作業があった場合に、プロマネに相談や報告に行くが、プロマネが打ち合わせでほとんど不在になっており、相談がなかなかできずにいた。
作業プロセスの問題点②
追加作業が、毎日のように発生することや、計画した作業が予定通りに終わらなかったなどの作業遅延も重なり、進捗管理表の作業開始日と終了日が見直されず、既に過ぎている日付が計画として記載されたまま、プロジェクトが進行していた。
さらにせっかく計画を見直したとしても、追加作業が毎日のように発生する。しかも、現在の最新の計画よりも割り込みで優先度が高い作業が入ってきて、現在の作業を止めて、優先の作業を行うように指示が出ている。
そのため、進捗管理表の日付が、本当にできる日程なのか、またいつやるべき日程にしたらよいかが全くわからない状況になっていた。
作業プロセスの問題点③
すべての作業フロー・作業プロセス、開発ノウハウが、ドキュメントに残されておらず、経験者の頭の中にあり、典型的な属人化が進んでいるプロジェクトになっていた。もし、新しいメンバが入った場合は、こういったケースではどのようにしたらよいか？といったことを、経験者に対してすべて確認しなければ、問題が解決できないという状況になっている。
作業プロセスの問題点④
正常なプロジェクトと比較すると、プロジェクトとして必要なデータをとる仕組みができていなかった。例えば、製造工程での、レビューの時間、レビュー指摘件数、バグ件数。試験工程での試験項目数、試験実施の生産性など。
炎上プロジェクトの解決方法
まずは現場に入って、プロジェクトが炎上してしまった根本問題は何なのかを確認する。おそらくプロジェクトによってさまざまな状況があり、炎上にいたるまで複数の原因があるかもしれない。
抽出した問題を1つずつ解決するために、どのような対策をうって、どんな日程で進めていくかのストーリーを考える。大幅な日程遅延がおきている場合は、短期間での挽回はできないので、おおまかな目安でいうと、3カ月以上は必要になるケースが多い。
大体のプロジェクトでは、現状の人だけではダメなので、大量の要員（リソース）追加を行って、問題の解決をすすめる。※今回、私が入った炎上プロジェクトでも、大量のリソース追加で対策を行った。
最終的な結論としては、上記のような進め方を行って、日程遅延は挽回でき、炎上プロジェクトはなんとか火消しできた。
炎上プロジェクトの解決に重要なこと
立て直し役のプロマネが、プロジェクトメンバーとどのような計画で、どのように進めて、立て直しが完了するか、という道筋（ゴールまでの進め方）とゴールをしっかりと共有すること、これが一番重要です。
炎上プロジェクトは、プロジェクトメンバーのモチベーションが下がっているかもしれません。しかし、いつまでに立て直す！という計画をしっかり立てたら、今はスケジュール上のこの位置にいて、ゴールまで何を、あとどれくらいやればいいのか？というような、ゴールまでの残り作業・計画を、日々メンバーと共有します。そうすることで、みんなの意識が高まって、ゴールまで頑張るぞというような一体感が出てくるようになります。