デスマーチ、炎上プロジェクトにアサインされた時に末端のエンジニアがやるべきこと

  • このエントリーをはてなブックマークに追加

こんにちわ。始発に帰って翌日9時に出社という生活を強いられていたこともある管理人の「ヒロユキ」です。

新卒で入社した会社はとにかく炎上が多く、私は研修が終わった翌月から「定時で帰ったことが一回もない」という状況でした。

なので炎上やデスマーチについては、同年代のエンジニアの方よりも経験は豊富だと思います。

そこで、 炎上やデスマーチに遭遇した時、末端のエンジニアはどう動くのが良いのかということを記事にしていきたいと思います。

PMやPL向けの情報は多いがメンバー向けの情報は少ない

炎上やデスマーチ で残業地獄になった時の対処方法を検索してみると、「PMがほぼ悪い」という論調が多いです。

そのため解決方法についてもPMなどのリーダー層がどうアクションを起こすかという内容の情報が多いです。

これについては、正しいと思っています。

プロジェクト炎上の原因としては、

  • 見積もりミス
  • 技術力のミスマッチ
  • 顧客のパワーに負けていいなりになる
  • 要件が決まらない

など開発者レベルはどうにもできないレイヤーの話が多いからです。抜本的な解決となると顧客や要員の調整は必須です。

しかし、開発者の立場としても炎上を鎮火させるために出来ることはやっていくべきだと考えています。

特に「このやり方は良くないな」というやり方をしてしまうと、管理者層がいくら頑張って調整しても進捗が回復しないということになりかねません。

私が、「炎上時にコレは駄目だろう」と思う行動と、その改善方法を挙げていきたいと思います。

【 NG 】都合の悪いことを報告しない

1つ目は、「進捗報告などで都合の悪いことは報告しない」です。

「そんなの炎上とか関係なく、やらなきゃ駄目だろ?」と思われる方もいらっしゃるかもしれません。

しかし報告すべき内容は案件のチームビルディングによって大きく変わります。

顧客やリーダ層との壁が高い時は、私も「嘘は絶対つかないが、都合が悪いことは報告しない」ということをよくやっていました。

そういった案件だと弱い自分を見せないことが重要であり、心配をさせてしまうことで更にタスクが増えることも多いからです。

一方でアジャイル開発などでチームがフラットな職場では、懸念点などを積極的に発言していました。

どちらが正しいとかはなく、案件や状況によって決まると思っています。

しかし、炎上中の場合は「都合の悪いことを含め、全てをさらけ出す」くらいの気持ちで報告すべきと考えます。

何故なら炎上中は自分のタスクがパンパンになっている事が多いので、「都合の悪いことを後でリカバリする」という行動が取れないからです。

そしてスケジュール的にもバッファなんてものはないので、火種はすぐにチームに共有し対策を練らなければいけません。

そこで激しく叱責されるようでしたら、PMはかなり不適格者と思われるので上の人に相談しましょう。


【 NG 】課題を丸投げしない

前の「進捗報告などで都合の悪いことは報告しない」というところで書いた内容と似ていますが、何か課題や阻害要素が発生した場合は、何も考えず丸投げすべきと考えています

本来であれば、1人で課題を解決出来る方が良いのですが、前述したとおりに炎上中は自分のタスクがパンパンな状態です。

その状態で、更に課題の解決策を考えていれば他のタスクにも重大な遅れを生じさせてしまいます。

とにかく「悩んでしまう事態になったもの」は全てリーダーに任せましょう。

それでリーダーが回らなくなるようなら課題解決を専門にする有識者のアサインが必要です。

【 NG 】 帰宅時間を進捗とリンクさせない

炎上中はとにかく残業が大量に発生します。(逆に異常残業が発生しないなら炎上ではないです。)

この時、マジで困るのが「21時になったら帰る」みたいな時間を区切りにして動いてしまう人です。

通常の状況でしたら、「今日は疲れたから帰って、明日以降でリカバリしよう」という考えは合理的と思われます。

炎上中は、明日以降のタスクも目一杯であるため、明日以降にリカバリをすることを考えては駄目です。

リスケしても更に遅れ始め再リスケになってしまうパターンは、このような思考の人が沢山いるプロジェクトです。

稀にWBSの管理すら放棄されていることもあります。その場合はチーム単位でスケジュールを提案し、進捗を遵守するように動きましょう。

【 NG 】 個人の対応範囲を明確にしない

炎上案件でやってしまいがちなNG行動としてよく挙げられるのが、「責任のなすりつけ合い」です。

皆ギリギリの状況であるため、作業範囲について個人で線を引きがちになってしまい、「私の対応範囲はここなので責任はない」などとなってしまいます。

私は、逆にこの「個人での線引き」は非常に有効な手段ではないかと考えています。

以前にテスト案件で炎上した時に思ったのですが、4人でテストを進めていく際に

  • 未着手のテストの好きな箇所を進めてもらう。 期日までに4人で終わらせる
  • 予め4人にそれぞれ担当箇所を割り振る。他の人の担当箇所は手伝わない

とした時、前者のほうが隙間なく作業を実施できるので良さそうかなと思ったのですが、実際には後者のほうが進捗が出ます。

おそらくですが「4人で終わらせれば良い」という条件だと他の人にやってもらえば良いという甘えが生まれてしまうからだと考えています。

炎上中は異常残業により疲労がピークになるので、こういうメンタル面の負の部分がモロに生産性に影響します

このような経験から「終わったら相手の作業を手伝う」というという行動をするのではなく、「私の作業はコレ」と意識して線引きを行うことが有効かなあって思いました。

隙間タスクをどうするかという問題については、リーダーに丸投げが良いかと思います。

【 NG 】 開発以外の作業をやろうとしている

炎上あるあるなのが、炎上するほど間接作業みたいのが入って開発ができなくなるパターンです。

自分が経験したのだと

  • 上司、営業などが進捗を気にしすぎていて、進捗報告がヘビーになる
  • 課題が次々に増えるので、メールなどが爆増する

というのがあります。

開発者からも進捗報告は簡素にしてもらえるよう頼んだり、メールは見る時間を決めるなどして、開発に集中する時間を伸ばす必要があります。

炎上した時に進捗管理が重要なのは言うまでもないですが、私は無駄な進捗管理でどんどん辛くなっていく経験が多いので、ここは意識して減らしていきたいところです。

まとめ

色々と書きましたが、特に意識したいのは

「自分の作業を線引きし、その作業は確実に終わらせる」

ことだと思っています。

これは、炎上していないときには当たり前に出来ることだと思います。

しかし、炎上した途端に

  • チームで作業を終わらせよう
  • 課題が見つかったけど放置しよう
  • 終わってないけど帰ろう

みたいなマインドになり、立ち行かなくなることが多くありました。そうならないように、心がけて行動すれば評価は上がりやすいと思っています。


  • このエントリーをはてなブックマークに追加

SNSでもご購読できます。

コメントを残す


日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)