読者です 読者をやめる 読者になる 読者になる

プロジェクトマネジメントの話とか

「プロジェクトマネジメント」をはじめ、心理学・ライフハックの話を中心に、ビジネス全般について書いています


デスマーチ・激務に巻き込まれたアナタが取るべき12の対策【メンバー編】

ビジネス-仕事論 オススメ ライフハック コミュニケーション プロジェクトマネジメント ビジネス ライフハック-仕事術

 新社会人になろうとしているあなたが、「デスマーチ」(=不眠不休の連日徹夜の炎上プロジェクトを想定します)という激務の壁にぶつかったときに、当記事が何らかの参考になれば幸いです。

 私は約10年間、下流工程寄りの仕事に従事した後、上流工程へシフトしました。プロジェクト炎上の火消しにPL(プロジェクトリーダー)やPM(プロジェクトマネージャー・プロマネ)らが右往左往するものの、最終的なしわ寄せが「実装を担う開発現場」に来てしまう現実を、何度も目の当たりに、いや、実際に経験してきました。

 根本原因の解明が必要ではあるものの、一メンバーである個人の権限ではコントロールできない要素がほとんどだったりもするわけです。今回はメンバー側の視点として、デスマーチという激務のやり過ごし方、取るべき対処について考えてみましょう。もちろんIT業界以外の「絶賛激務進行中」なアナタもご一緒に!

スポンサーリンク

 

1.責任は「プロジェクトマネージャー」とその上にあり。ただし、自分なりに炎上した原因を分析・追及する

 プロジェクトが炎上した原因を自分なりに分析してみましょう。分析の方法は、あなたがどのポジションにいるかにも大きく依存しますが、コントロール可能な領域を見極めつつ「なぜなぜ分析」を繰り返し、根本原因を探ります。

 追求した結果、資金の関係で人的リソース・納期が圧倒的に不足し計画が破綻している、という身も蓋もないケースが多々あるわけですが、カイゼンの余地を探ります。
「PDCA」って言葉は正しいの?―全く回らない「PDC」とその対策。 - プロジェクトマネジメントの話とか

 そして、自分にアサインされたタスクを消化しながらも、PMがどのような手を打ち立て直していくのかを注視するのです。プロジェクトを構成する各要素を定量的に測定しているか?勝算もなく、むやみに人的リソースを追加していないか?

 方針が明らかに誤っている、時間ばかり経過するものの状況が全く改善されない場合は、周囲と協力してPMへ、話が通じないようであれば、その上へも進言する必要もあるでしょう。場合によっては、PMのクビを飛ばしにいく必要もあるわけです。プロジェクトを立て直し、自分の心身を守るためにも。

 自分はメンバーだが、全体を俯瞰して考える。この経験は、いつかあなたがプロマネになった時にも大きく役立ちます。


以降、メンバーが取るべき対応として、対処療法の観点から乗り切り方について考えていきます。

 

2.溢れそうなタスクはPL、PMへ投げ続ける

 人間が一人でさばけるタスクの量には限界があります。稼動を2倍に上げたところで、IQが2倍になるわけではないですし、アウトプットが2倍になるわけでもないのです。このままいけばタスクは溢れることが判明したタイミングで、早急にアラートを上げましょう。

 一番最悪なのは期限間近での報告です。マネージャー側からすると、ギリギリに報告されてもリカバリが効かないためです。早めの報告が必要なのは、デスマーチ中に限った話ではありませんが、炎上中は今まで以上に報告のスピードが求められるのです。

 そして、「受けられないものは受けられない」という毅然とした態度が必要です。自分はまだ駆け出しだ。「信用が欲しい!実績が欲しい!」その気持ちはよくわかります。しかし「できます」と宣言して実現できなかった場合に失う信用の大きさを認識しておきましょう。一度失った信用は簡単には取り戻せません。ビジネスとはそういうものです。

 そもそも考えてもみてください。誰もあなたのキャパなど、あてにしていないのです。自意識過剰です。本当に優秀な人間は、わからないことをわからない、できないことをできない、と明確に伝えられる人間なのです。

※下記の過去記事では、タスクを他メンバーに振ることも想定していますが、デスマーチ中はチーム内がカオスになっているため、きっちりマネージャー経由でタスクを整理してもらうことがベストかもかもしれません。
仕事を抱え込んでしまう理由と8つの処方箋。 - プロジェクトマネジメントの話とか

 

3.周囲との関係を常に俯瞰・意識して会話の量を増やす

 不思議なことに、どんなに稼動が跳ね上がったとしても、メンバー間の関係が良好な場合は、炎上プロジェクトであっても楽しく仕事を進められたりすることが往々にあります。深夜4時に馬鹿笑いしながらMTG。良くも悪くもお祭り状態です。

 逆に、毎日定時で上がれるようなプロジェクトであっても、人間関係が最悪の場合は心身の負担が大きくのしかかり、激しく疲弊することになります。短時間労働であるにも関わらず、この消耗の度合いは凄まじいものがあります。

 最終的に、仕事は「人」なのです。技術寄りの仕事であってもそれは変わりません。

 全メンバーが慢性的な睡眠不足に陥った場合、プロジェクト内の雰囲気が殺伐としてきます。他メンバーが犯した些細なミスに対しても、カリカリ反応してしまいがちです。デスマーチとはそのようなものです。

 せめて自分と自分の周囲だけは綺麗な空気でいたいものです。そのために会話を増やす。意識してバカな話をする。周囲は敵ではありません。戦友なのですから。

 

4.「ブルックスの法則」を無視して投入された追加メンバーとの「コミュニケーションコスト」を十二分に見積もる

 ソフトウェア開発の古典『人月の神話』にて、ブルックス教授は「遅延したプロジェクトへの人員追加はNG。メンバー間における、コミュニケーションコストの増大などの弊害があるため」と説いています。ごもっともです。

人月の神話―狼人間を撃つ銀の弾はない (Professional computing series (別巻3))

人月の神話―狼人間を撃つ銀の弾はない (Professional computing series (別巻3))

  • 作者: Jr.,フレデリック・P.ブルックス,Frederick Phillips,Jr. Brooks,滝沢徹,富沢昇,牧野祐子
  • 出版社/メーカー: ピアソンエデュケーション
  • 発売日: 2002/11
  • メディア: 単行本
  • 購入: 8人 クリック: 167回
  • この商品を含むブログ (176件) を見る
 

 しかし、実際の現場ではどうでしょうか?

 機能のシュリンク・スケジュールの引き直し。やれるものならやりたいものですが、お客様の了承はそう簡単に得られるものではありません。

 現実問題、単純な機能のコーディングや試験フェーズなど、力作業でこなせる作業を中心に、人員追加の人海戦術で乗り切っていくことも多いのが現状です。なぜなら「これはこれで有効に機能することもある」からです。(そうでないケースも多々ありますが……)

 そう。あなたのプロジェクトにも人員が追加されるのです。実装工程の開発現場であれば、初めてお目にかかる協力会社の人たちが突然やってくることも珍しくありません。彼らはスキルはあっても仕様を知りません。当該システムに過去、携わった経験のあるメンバーが呼び戻されることも多々ありますが、最新の仕様を知っているわけではないのです。

 つまり、あなたからメンバへの仕様説明という新タスクが追加されるのです。この負担をあらかじめ、スケジュールに積んでおく必要があります。また、この工数は新規メンバのスキル(仕様理解のスピード)にも大きく依存するわけです。はい。バッファも必要ですね。

 また、イチから信頼関係を構築する必要も出てくるわけです。この時間的コストを見積もる必要があります。

※信頼関係の重要性については下記記事を参考に。
「Win-Win」の大きな勘違い―Google社と7つの習慣【第4の習慣】から考える。 - プロジェクトマネジメントの話とか
なぜ人は相手の話を聴かないのか?―ゼロから学ぶ7つの習慣【第5の習慣】 - プロジェクトマネジメントの話とか
口下手なプログラマと体育会系SEの処世術―7つの習慣【第6の習慣】から考える。 - プロジェクトマネジメントの話とか

■カギは持続可能性(サスティナブル・sustainable

 瞬発力にモノを言わせ一時的にパフォーマンスを発揮しても、継続しなければ結果を出すことができないのは元より、デスマーチ中であれば生き残ることすらできません。一番のカギは「バテずに継続して走り続けることができるか?」この一点に尽きます。

 以下、続けて生活習慣の面からも考えていきましょう。

 

5.就寝前に入浴する

 帰宅してバタンキュー。朝はシャワーで済ませて家を飛び出す、というサイクルは非常に非効率的です。乳酸の除去、および体温の上昇→下降を目的に、可能な限り湯船に浸かりましょう。就寝前に入浴することで「睡眠の深さ」に歴然とした差が生まれるためです。睡眠の量が確保できなければ、質を高めて対抗するのです。

 

6.一日一回は瞑想をする

 なぜ人は体のメンテナンスには気をつかうのに、脳のメンテナンスは放置するのでしょうか?瞑想の目的、効果については、以下の過去記事を参照ください。睡眠時間が取れないのなら、瞑想で脳のダメージをカバーしましょう。日頃から習慣化しておきたいところですが、デスマーチ中は特に気を使いたいところです。継続することで、イライラ・心身の消耗度合いが改善されます。

 

7.休日に散歩をする

 「運動しろ!」と本当は言いたいところですが、疲弊しきっている状態では、なかなか体が言うことを聞いてくれません。

 ベストはジョギングや自分の好きなスポーツなどで有酸素運動を行うことですが、それが現実的でない場合には、せめて散歩だけでもしたいところです。これだけでも有酸素運動としての効果はあります。睡眠不足→心身の不調→運動不足→心身の不調→運動不足……という悪循環を断ち切るのです。

 

8.週に一日は長時間の睡眠をとる

 週に一度の長時間睡眠で、体はある程度回復します。睡眠の借金の負債を返済するのです。可能であれば土曜にこれを実施して日曜は普通に起床したいところです。土曜、日曜と続けて生活サイクルを崩すとみなさんご存知の通り、月曜に悲劇が訪れるのでご注意を。

 

9.食事(特に炭水化物)の摂取量を減らす

 食べれば当然眠くなります。人間は、食物を消化するのに多大なエネルギーを消費します。特にデスマーチ中は省エネモードで動きたいものです。特に、炭水化物を採り過ぎて良いことは何一つありません。完全に断つのも問題ですが。

 

10.隙を見つけてトイレなどで短時間仮眠する

 仕事の合間に携帯アラームを利用し、10分程度仮眠をとります。遠慮はいりません。仕事を効率化するために必要な作業です。机で寝るも何なので、迷惑がかからない範囲でトイレなどで寝ましょう。昼食後などのスキマ時間も同様に有効利用しましょう。

 

11.口角を上げて脳を騙す

 表情や空気は伝染します。アナタの暗い表情は他メンバーへ伝染します。他メンバーの暗い表情もアナタへ伝染します。なのでアナタがその負の連鎖を断ち切りましょう。とはいえ、心身が疲弊している中「常に笑顔でいろ!」などと言うつもりは毛頭ありません。

 試しに口角だけ上げてみましょう。目は死んでいても結構です。

 口角を上げると体(=脳)が騙されて「ん?何か楽しいことがあるな?アハハッ!」と少し元気になります。一説によるとセロトニンの分泌量が増えるとか増えないとか。あ、別にアヒル口にしなくていいから。気持ち悪いから。

 

12.最後に。バーンアウトする前に休め!どうしても無理ならその場所から逃げろ!

 炎上プロジェクトに巻き込まれ、一人で抱え込み、オーバーワークで壊れてしまう人が少なからず存在します。特にIT業界ではその傾向が顕著です。これはPM・PLに責任があるのですが、メンバとしても、自分が壊れる前にアラートを上げ、周知する責任があるわけです。

 評価が下がる?信用が失われる?自分がやらずに誰がやる?その気持ちは理解できます。しかし、ある日突然アナタが潰れてしまい、大きな穴が空いてしまった場合の方が、遥かに損失が大きいのではないのでしょうか?

 幸いにも、私は潰れたことはありませんが、多くのメンバが潰れていくのを目の当たりにしてきました。ある日突然、メンバーが会社に来なくなる。彼らはアラートを上げられませんでした。その気持ちがわかるからこそ言いたいのです。自分の限界が見えてきたら、上のマネージャーでなくてもよいので周囲メンバーへ相談してほしい。必ずタスクを巻き取ってもらえます。

 社会人には、仕事に対して真摯に向き合う義務がありますが、あなたが壊れてしまっては元も子もない、ということだけは肝に銘じておいてください。あなたが壊れることは、あなたにとっても会社にとっても莫大な損失以外の何ものでもないのですから。

 あなたにはプロジェクトを離脱する権利があります。会社に命を捧げる義務はどこにもありません。会社はアナタの人生を生涯保障してくれるわけではないのです。

 そして新社会人になる方々へ――。

 仕事は楽しいものです。楽しい分、厳しいものでもあります。本気で命がけで取り組む一方、「いざとなったら逃げ道はいくらでもあるのだから、気楽にいこう!」という前向きな逃げ道を意識しておいてください。

 雇われ人であっても、本質はいつだって自由なのです。あなたは奴隷なんかではありません。

 逆説的ではありますが、「適度ないい加減さ」を意識することで、IT業界をはじめ、日本が少しでも明るくなることを願っています。

 社会の荒波へようこそ!

 さあ、面白おかしく仕事していこうか!

 

人月の神話【新装版】

人月の神話【新装版】

 
デスマーチ 第2版 ソフトウエア開発プロジェクトはなぜ混乱するのか

デスマーチ 第2版 ソフトウエア開発プロジェクトはなぜ混乱するのか

 
ピープルウエア 第3版

ピープルウエア 第3版

 
クリティカルチェーン

クリティカルチェーン

 
 

photo by Philip Chapman-Bell

文章、画像等を含む全ての著作物の不正利用・転載を禁止します。
© 2017 プロジェクトマネジメントの話とか, ALL RIGHTS RESERVED.