Photo by Grant Guarino
高村です。開発チームのエンジニアリーダーをしています。
私は前職でメーカー系の大手SIerに8年ぐらいいたのですが、よその炎上プロジェクトの助っ人に行くことがよくありました。
助っ人をするのは大変ではありますが、「優秀な人たちはどんな振る舞いや働きをして炎上をしずめているのか」「何が原因で炎上したのか、どの時点で何をしていれば炎上が防げたのか」などがわかって勉強になるし、次の仕事に生かせる知見が得られて非常に役に立ちました。今も役立っています。
というわけで今回は、「担当しているプロジェクトが炎上し始めたらやったほうがいいこと、逆にやってはいけないこと」について書いてみます。
（※炎上していなくても「そもそも日常的に気をつけておくべきでは？」って項目も多いですが、「炎上しだしたらさらに重要！」ってことで…。）
担当プロジェクトが炎上しだしたらやったほうがいいこと
スキマになっている工程を洗い出す、WBSを分解する
プロジェクトが炎上すると、とりあえず人が大量に投入されますよね。
そうなったら、まずPMはタスクの洗い出しと、それを投入された人たちで分担できるように改めてWBSを分解しなければなりません。新しく来た人・増えた人でも分担しやすくしないといけないので。
これはマネジメント層に限らない話ですが、炎上し出すとみんな結構責任のなすりつけ合いというか、タスクの線引きをしたがるようになります。「いや、私が担当するタスクはここまでだけですから」という感じで。ただ、それだと結局、火種になってる抜け漏れがあった部分を作る人がいなくなっちゃって、いつまでたっても炎上がおさまらないんです。
だからプロジェクトが炎上し始めたら、PM・PLだけでなく担当者も、わかる範囲で「これ、誰かがやらないと終わらないぞ！」というスキマになってる部分を洗い出して見える化してあげると、上の人は大変助かるかと思います。まあ、その洗い出した部分が自分の担当になっちゃう可能性も大きいから両刃の剣なんですけど、放置しとくとさらなる大炎上につながってしまうので……。
PM・PLなどのマネジメント層は自分の作業を工数に入れない
上の続きにもなりますが、炎上し始めると、ついPM・PLにあたる人たちも「自分たちも作業にあたって巻き返さないと…」と考えがちですよね。でも、実際はそれより計画の立て直しに専念すべきです。プログラマ出身の人はついやりがちですが、「自分も手を動かせば間に合う」前提で計画を立ててはなりません。
炎上してるってことは、そのプロジェクトは全然最初の計画通りに進んでいなくて、破綻しちゃってますよね。だから、計画を立て直して、タスクを分け直して、助っ人に来てくれた人も含めてそれを割り振り直すのが最優先です。
ちなみに、開発作業は分解すればするほど基本的に生産性は下がりますから（たとえば1人が10個の機能を作るよりも、10人で1個ずつ機能を作るほうがいろいろなすり合わせが発生しますよね）それも頭に入れてWBSを引き直しましょう。
有識者の投入
ここで言う有識者は、前のプロジェクトの担当者とか、新規に導入する技術やツールがある場合は、その知見を持っている人とかですね。
まぁ本当は最初からそういった人がいて当然で、有識者がいないプロジェクトは開始時点から見通しがあやしいわけですが…あとからでも入っていただくに越したことはありません。
全力で入ってもらうのが難しくても、たとえばレビューだけ入ってもらうとか、何かあったときに質問できるように有識者とのパイプをつなげておいていつでも聞ける状態にしておいたほうがよいでしょう。
メンバーから不安や課題感の声が上がりやすい状態にする
不安の声が上がらないってことは、チーム間に話しにくい空気が漂っている、風通しが悪い状態になっちゃってるんだと思います。「進捗問題ありません」と言うしかない空気が漂っている意味のない進捗報告会議とか…。
これはチームビルディングできていないPMやPLが悪いですね。
PM・PLはむしろ「現場でちょっとでも気になることがあれば何でも言ってね！」って空気を作るべきです。これができれば火種にも早い段階で気付けます。臭いものにふたをする空気感はダメですね、炎上し始めてからやっと問題に直面しても意味がないので…。
さらに言うと、メンバーが気になっていることを聞いた上で「その問題をどう扱うか」を判断し、伝えるのが重要です。「それはすぐに対応したほうがいいから大至急こんな対策をとるね」とか「今のところそれほど大きな問題ではなさそうだけど念のためこのタイミングになったらこんなアクションを起こすよ」とか。
ただ言ってもらうだけ、聞くだけじゃ意味がないですよね。解決や調査に向けた案を出して、メンバーに「言ってよかったな、これからも何か気づいたら言おう」と思ってもらわないといけません。
どうでもいい会議や進捗報告などの無駄を減らす
炎上を鎮めようとか思ったら、とにかくあらゆる無駄を省いて工数を確保する必要があります。
例えば最初に引いたスケジュールに余裕を持たせていた場合はそこを詰めたり、見栄えや使い勝手向上のためのちょっとした要素は後回しにして調整できないか検討しましょう。
また、おそらく回数や参加メンバーを減らしても構わない無駄な会議や打ち合わせがあると思いますから、それも検討する必要があります。切羽詰まっているときの無駄な会議は害悪でしかありません。
担当プロジェクトが炎上しだしたらやらないほうがいいこと
無駄なことをやめない、増やす
最悪なのが、プロジェクトに遅れが出ているのに
- ステップ数を計算させて毎日報告させる
- ステップ数に対するバグ数の多い・少ないを計算させて、見解を報告させる
- 一日の生産性をステップ数で計算して、達成していないとなぜ達成できないのか詰める
- 作っているプログラムの自動生成率にKPIを持たせて達成させる
…などですね。
無駄をやめないイコール優先度がおかしいってことですからね。さらに言うと「上の人も本当に今それをやるべきなのか疑問に思っていない」という問題があるんですが、大きな組織だと仕組み的にそうするしかない、どんなにがんばっても変えられない…といったケースもあるので、それはもう、転職してしまったほうがいいと思います。
進捗が出やすい部分から進めちゃう
遅れがあると、ついつい進捗が見えやすい（≒簡単にできる）部分から手をつけたくなっちゃいますよね。
でも、実際は調査が必要だったり、後工程への影響が大きかったりする、難易度が高くてリスキーな部分から手をつけるべきです。
それでしばらく調査工程になって進捗が出なかったとしても、トータルで見たらそっちのほうがいいはずですから。むしろ最初だけスムーズでも、最後めっちゃ大変な作業が残っていて全然工数足りませんって状態になっちゃうほうが問題です。目先の進捗にばかり目を向けないのが大事ですね。
責任の所在ばかり気にする
また優先順位の話ですが、炎上プロジェクトなら遅れを取り戻す、障害対応なら暫定対応でも一部でも復旧させる、とかが優先されるべきです。
誰が悪い、なぜ遅れているか、みたいに詰める進捗報告会は無駄に作業者を萎縮させるだけです。追求がどうしても必要なら、とりあえず炎上や障害が解決してから振り返り的にやったほうがいいですね。
前述もしましたが、必要なのは「遅れたら詰められる」ではなく、「ちょっとでも気になることがあれば何でも言ってね〜」って空気です。
PM一人でWBSを決めてしまう
各工程でやっておくべきことができていないプロジェクトは、テスト工程で大炎上＆手戻りになってしまいます。ただ、PMが最初から全てのタスクを割り出せるかといったら、それは難しくて、後から抜け漏れしていたタスクが必ずと言っていいほど発生します。
でも、最初の時点でPMがぎっちぎちのスケジュールを引いてしまっていた場合、後から発生した抜け漏れを割り振ろうとすると、誰かに無理をしてもらわなければならなくなる。「何で増えるんですか？できませんよ」と言う人も出てくる。プロジェクトにもよるとは思いますが、WBSはPMが決めるよりも、例えばエンジニアのチームが担当機能ごとにわかれているなら、チームごとにタスクを挙げてもらう。それを元にWBSを作った方がよいでしょう。
まとめ
炎上というのはよく見ていれば早い段階で火種が隠れているはずですから、何か火種っぽいものを見かけたら早めに声を上げたほうがいいですね。
PMなどのマネジメント担当者は負荷がかかってるところ見極めて分散させたり調整したりする、プログラマーなど作業者でもタスクを洗い出して協力したり、ときには上の役職の人に掛け合ったり、なるべく炎上を食い止めるためにできることはあるはずです。
助っ人として炎上プロジェクトに首を突っ込みまくった経験から言うと、炎上プロジェクトは前向きに向き合って解決できると、強力な経験＆スキルを得られるので、「この業種で、この会社でやっていきたい」という人は、楽しんで成長につなげられるとよいかと思います。（前職から転職して出てきた私が言うのもなんですが…）
ただ、あまりにも炎上前提なプロジェクトしか回ってこないような場合は、そもそもその会社に問題がありますから、さっさと転職を考えたほうがいいと思います…。
paiza転職は、転職時のミスマッチをなくし、エンジニアがより技術面にフォーカスしたやりがいある仕事を探せる転職サービスです。プログラミングスキルチェック（コーディングのテスト）を受けて、スコアが一定基準を超えれば、書類選考なしで複数の会社へ応募ができます。
「paizaラーニング」では、未経験者でもブラウザさえあれば、今すぐプログラミングの基礎が動画で学べるレッスンを多数公開しております。
詳しくはこちら
そしてpaizaでは、Webサービス開発企業などで求められるコーディング力や、テストケースを想定する力などが問われるプログラミングスキルチェック問題も提供しています。
スキルチェックに挑戦した人は、その結果によってS・A・B・C・D・Eの6段階のランクを取得できます。必要なスキルランクを取得すれば、書類選考なしで企業の求人に応募することも可能です。「自分のプログラミングスキルを客観的に知りたい」「スキルを使って転職したい」という方は、ぜひチャレンジしてみてください。
詳しくはこちら
