Photo by Steven Cooper
高村です。
誰だって炎上プロジェクトにはかかわりたくないですよね。
私は前職で、自分の担当プロジェクトが炎上したり、よその炎上プロジェクトの助っ人に行ったりすることがよくありました。そんななかで「プロジェクト炎上の前兆」がわかってきたので、書いてみたいと思います。
炎上プロジェクトを避けるための参考になればと思います。
1.プロジェクト開始後、やけにスムーズに進捗が進んでいく
もちろん、プロジェクトがスムーズに進むのはよいことです。
ただ、こういうプロジェクトはスケジュールの序盤に簡単で進捗が出やすいタスクを置いて、難しいことや確定していないことは後回しにしているだけ…なケースが非常に多いです。
夏休みの宿題で、手をつけやすい漢字ドリルから始めて、進んでいるように見えるけど、自由研究や読書感想文は何を題材にするかすら決まってない状態…みたいなもんですね。
最初はよく見えるのですが、不確定要素が多くて後回しになっているタスクや時間がかかりそうなタスクは、結局あとのほうで火種になってしまいます。
これはスケジュールの引き方を改めたほうがいいですね。たとえば、不確定要素が多い部分は「この日までに調査する」とか「この日までに明確にする」みたいなスケジュールを前々から組み込んでおくべきです。
2.発注側の担当者の決断がやたら早くてスムーズ
1.と似ていますが、担当者が「それいいですね、そうしましょう！」などとやけに即断即決してくれて、「今回の担当者は話がわかる人でよかった…」と思ってたら、その人には全然決裁権がなくて、後からひっくり返ってしまう…みたいなケースです。
担当者が若くて経験が浅いとか、配属が変わったばかりで決裁のフローを理解していないという場合にありがちです。
走り出してからひっくり返ってしまうのは本当に最悪なので、「この人、本当に理解してOK出してるのかな…？」と不安になる場合は、発注側のフロー（≒誰に決裁権があるのか？）を確認しておいたほうがよいですね。
3.既存システムに関する有識者がいない
既存システムのリニューアル案件などでは、発注側も受注側も、そのシステムに関する有識者が絶対に必要です。
そのシステムがどう作られているのか、どんな中身になっているのかがわからないと、リニューアルや大幅な機能追加や変更なんてできませんからね。有識者がいない場合は、調査する時間（とお金）が必要になります。
発注側に開発系の知識がないと、「イチから作るより、既存のリニューアルのほうが簡単でしょ～」と勘違いされがちです。（実際はイチから作るほうがずっと簡単なときも多い…）
そのまま有識者もいない、調査する時間もない…な状態で走り出さざるを得ないプロジェクトだと、まあうまく進んでいかないと思います。
4.要件を聞く前から金額と納期だけが決まっている（≒ゴールが決まっていないまま走り出さねばならない）
ウォーターフォールで進めるプロジェクトでは、炎上を防止しようと思ったら、まず最初の段階でどれだけ正確に見積もれるかというのが非常に重要です。でも、ゴールが決まってないと見積もりようがない。
たとえば「病院でカルテを管理するシステム」ってだけだと、お医者さんが使うのか、看護師さんが使うのか、医療事務の人が使うのか、どこまでの処理をシステムが担当して、どこまで作業は人力でやるのか、最低限の機能を実装すればよいのか、実際の運用が進んだ段階がゴールになるのか……みたいな情報を誰も把握してない状態で、先に見積もるなんて到底無理です。
ほとんどの場合、最初の見積もりよりも要件は増えますし…。
5.契約の都合で情報がオープンにならない
たとえば、三次請けはあくまで二次請会社と契約していることになっているので、一次請けの持っている情報が直接降りてこない…みたいな状態です。
契約のせいで末端が上に直接質問できない…というのがボトルネックになってしまいます。
この場合、たとえばチームリーダーが間に立って質問や課題の報告を上げたり戻したりしないといけなくなってしまいます。私が過去に助っ人しにいった似たようなプロジェクトでは、チームリーダーに負荷が集中するわ、末端の生産性は上がらないわで大惨事でした。
これはそもそも契約の段階で問題があり、現場の担当者がどうこうできる話ではないので…それっぽい臭いのするプロジェクトはなるべく避けるしかないですね…。
6.偉い人の肝入りで始まった戦略的な受注案件
ここで言う「戦略的な受注案件」とは、たとえば「今後の継続的な受注や次以降の大型案件の受注のために、あえて通常より安い金額で受注して始まってしまった」みたいな案件のことです。
上からしてみれば戦略なのかもしれませんが、現場にとってはたまったもんじゃありません。
そもそも通常より金額が安い＝必要な人数を投入できない…という可能性が高いので…。
社内政治が絡んでいる場合も多いし、これも避けられるものなら避けたほうがいいですね…。
7.メンバーから不安や課題感の声が上がらない
開発業務に限らずですが、チームメンバーの誰もが不安や課題や懸念点を一切感じないような仕事ってめったにないと思います。
むしろ不安の声が上がらないということは、チーム間に話しにくい空気が漂っている、風通しが悪いケースがほとんどです。「進捗問題ありません」と言うしかない空気が漂っている意味のない進捗報告会議とか…。
これはチームビルディングできていないPMやPLが悪いですね。
PM・PLはむしろ「現場でちょっとでも気になることがあれば何でも言ってね！」って空気を作るべきです。これができれば火種にも早い段階で気付けます。臭いものにふたするような空気はダメですね、炎上し始めてからやっと問題に直面しても意味ないので…。
8.現場と関係ない人がひっかきまわしてくる
ひっかきまわしてくる人は、発注側の担当者の上司とか、受注側だとPLの上司とかが多いですね。あるいはコンサルの人がいるケースもあるかもしれません。
現場がちゃんとステップを踏んでひとつずつタスクを進めているのに、上の人が急に来て、進捗フェーズ無視で思いつきの提案や自分の過去の成功体験を押し付けてこられると最悪です。そこでPLが「たしかに～」とか言って取り入れちゃう人だと、やることが増えたり、巻き戻りが発生したりして本当に本当に最悪です。
プロジェクトが走り出している以上、何か追加しようと思ったら、今あるタスクを減らす必要があります。
誰かが何か言ってきた場合、それを受け入れるか、受け入れないか、受け入れるなら既存タスクをどう削るか…をPLが適切に判断できないとダメですね。
9.会議があってもアジェンダや議事録がない
アジェンダがないと会議で何を決めるかが明確でないので、意味のない会議になってしまいがちですし、議事録が残らないと、言った言わないでトラブルになりがちです。
トラブルを避けるには、こっちで作るしかありません。たとえばアジェンダは先に作って共有しておく、議事録は会議中に作って終わったら整えてすぐに共有する…としたほうがよいですね。
またアジェンダは、ブレストのための会議とかでない限り、たとえばイエスかノーで答えられる議題にしておくとか、案1・案2・案3のうちどれかを決めたい（もしそれ以外にもっとよさそうな選択肢が出てくるようであれば仕切り直す）とか、「何を決める会議なのか」と「期待する答えの例」を共有しておけば、いきなり会議に入るよりはずっとスムーズに進むはずです。
■まとめ
以上、炎上プロジェクトに多い兆候を挙げてみました。
すでにプロジェクトがある程度進んでからの話もありましたが、炎上というのはよく見ていれば早い段階で火種が隠れているはずですから、何か火種っぽいものを見かけたら早めに声を上げたほうがいいですね。
また、「プロジェクトは炎上して当然」で麻痺してしまうと、そのうち自分が潰されてしまうので危険です。
あまりにも炎上前提なプロジェクトしか回ってこないような場合は、そもそもその会社に問題がありますから、さっさと転職を考えたほうがいいと思います。
paiza転職は、転職時のミスマッチをなくし、エンジニアがより技術面にフォーカスしたやりがいある仕事を探せる転職サービスです。プログラミングスキルチェック（コーディングのテスト）を受けて、スコアが一定基準を超えれば、書類選考なしで複数の会社へ応募ができます。
詳しくはこちら
まずはスキルチェックだけ、という使い方もできます。すぐには転職を考えていない方でも、自分のプログラミングスキルを客観的に知ることができますので、興味がある方はぜひ一度ご覧ください。
詳しくはこちら
