デスマーチのお話 ~第一話~

 

今回はデスマーチの話です!


突然ですが、デスマーチって聞いた事ありますか?

 

もし、ご存じないのならIT業界は昔よりも平和になったのかもしれせん。

 

ITの世界では徹夜・終電は当たりまえの、残業が100時間/月超えるような、過酷な労働をよくデスマーチなんて呼びました。(略してデスマ)

 

ちなみに用語の使われ方の例としてはこんな感じです。

 

この前、A案件やってた開発リーダーの〇〇飛んだらしいぞ

 

まじか!それデスマの始まりじゃん!

 

この様に日本では「デスマ」なんて愛称で呼ばれているデスマーチ。

 

今回もいつものノリで語りますよぉ!


 

これってそもそも日本の話?

 

徹夜とか残業が多いとかって、日本だけにありそうな話に思えません?

 

ところが、デスマーチはアメリカで生まれた言葉なんです。


 

エドワード・ヨードンの著書「デスマーチ:なぜソフトウエア・プロジェクトは混乱するのか」

 

実は、こんな著書がありまして「デスマーチ」はこの著者が作った言葉らしいのです。

 

 

アメリカでこの定義が生まれたというのは、意外じゃないですか?

 

ソフトウェアプロジェクトの問題は、割と世界共通の話っぽいすね。

 

デスマーチとは?

 

では「デスマーチ」ってどんな状況を指すのでしょう?

 

デスマーチを直訳すると「死の行軍」もともとは、戦場の捕虜などがやらされてるような過酷な労働を指します。


 

これがIT業界だと、どのように「死の行軍」になるかといいますと。

 

プロジェクトメンバーがいくら残業してもまるで終わりが見えない・・終わらない。

 

残業時間はどんどん増えていき、残業が100時間/月を超える事態に発展。休日もない。


 

そして体調不良の人、ある日会社にこなくなる人、突然会社を辞める人が続出し、まるで死に向かって進むような失敗プロジェクト・・。

 

ざっくり言うとこんな感じです。

 

デスマーチが起こる理由

 

では、そもそも何でこんな事が起きるのか?

 

エドワード・ヨードンの著書によると以下4つのどれかに該当する場合、デスマーチが起きると言ってます。

 

  • 与えられた期間が一般の半分以下
  • エンジニアの必要な人数が半分以下
  • 予算が通常の半分以下
  • 機能や性能などの要求が倍以上である


 

デスマ経験者の私は思ったのですが・・

 

マジでホントこれなんですよ・・


 

流石エドよくわかってるぜ!

 

なのでデスマ経験者がこの本を読むと「あるある」視点で楽しめるのではないでしょうか。

 

では、何故でこうなってしまう事が多いのか?

 

今回は原因となる4つのうちの1つである、こちらにフォーカスしてお話したいと思います。

 

与えられた期間が一般の半分以下

 

ここからはエドワード・ヨードンが語ってる内容ではなく、私の経験を元にした視点でのお話しになります。

 

与えられた期間が一般の半分以下

 

まずこれは、いわゆる「納期の問題」なんですけど、よくあるのが・・

 

通常は半年かかるものを、お客が「2か月でやってくれ!」出来るなら御社に任せる!みたいな案件、たまにありませんか?

 

こういう案件がきたとき、会社や上司が以下の様な体質だと、無茶なスケジュールでも、そのまま進んでしまうケースが多いんです。

 

  • 作業時間の割り出しをする文化がない
  • 工数は残業ありきで考える
  • 文句のある奴はトップダウンでヨシ!
  • 4か月分くらいなら根性で埋まる
  • 最強の言葉は「なんとかなる」
  • 過剰なお客様は神様です精神


 

要は、この体質が原因で、誰が何をすれば良いかもよく解らないまま「やります!」と言ってしまう状況が多発していた訳です。

 

どうしてそんな事が起きるの!?よく考えれば解る事じゃん。バカなの?

 

外から見てる人はこの様に思うかもしれません。

 

では、どうしてこうなってしまうか?

 

ここからは実話をもとにストーリー形式で話します。

 

デスマーチに発展するストーリー

 

デスマーチの火種はこんな状況から始まっていきます。

 

お客様の目線

半年かかる案件だけど2か月以内に完了しないとヤバいよヤバいよ・・

営業と経営者の目線

この案件を俺は取る!!!

 

① この状況から、お客様・営業・経営側で「いっしょに壁を乗り越えましょう!」と気持ちが一体となる


 

② 予定通り納品できるかの可否なんてどうでもいい「会社としてやるしかない!」になる。


 

当然、現場から「そのスケジュールでは出来ない」と声が上がる


 

④「これは会社としてのチャレンジだ!甘えるなよ?」という根性論がトップダウンで発動される。


 

⑤不足している作業時間をどう埋めるか?対策もないまま根性で作業を進めていました。

 

しかし、どんなに頑張ったところで、納期には間に合わない事が次第に解りはじめます。


 

⑥納期が近づいてくると、経営陣と営業がエンジニアに「早く終わらせろ!」と責め始める。


 

⑦不足した時間を埋める為、エンジニアも根性で徹夜を繰り返す。


 

⑧プレッシャーとストレスから、エンジニアが体調を壊して休職。もしくは耐え切れず退職する。


⑨別な人を無理やりアサインして、伝家の宝刀である根性論で無茶ぶりをする

 

⑩そして③~⑧を後任の人がまた繰り返す。


⑪結果、納期が守られるどころか、とうとう作業者もいなくなりプロジェクトが崩壊。

 


どうですか?まさにデスマーチ「死の行軍」ぽくないでしょうか?

 

嘘みたいな話ですけど、これ普通によくある話でした。

 

この教訓から解る事

 

誰がみても明らかにスケジュールが無茶な案件は、他の業者に頼んでも同じです。

 

根拠となる材料を集め、ちゃんと説明して「全部は無理だがここまでならできます」みたいな交渉の余地だってあったはずです。


プロジェクトとは、お客様が業者に丸投げをして夢をかなえる事ではありません。

 

大事なのは、お客様と一緒に考え仕組みを作る事。

 

売れなきゃ会社はつぶれますんで、営業や経営陣は間違っていません。

 

だからこそエンジニアも、もっと全力でリスクを伝えて戦うべきでした。

 

お客様も「業者がOKと言うならOKなんだろう」と思わず、もっと確認をすべきだったんです。

 


 

きっと・・それぞれが心のどこかで「誰かに丸投げすればヨシ!」「自分が見える部分以外は他人事」と思っていた。

 

だからデスマーチが起きたのではないでしょうか。


そして教訓はもう1つあります。

 

それは、自分のいる会社が、ブラックであるかどうかを判断できるという事です。


 

どんな企業にも失敗はありますし、チャレンジも必要だと思います。


 

しかし、こういった状況が多発しているにも関わらず、改善策を会社がまったく取っていない場合、それは明らかに異常です。

 

そんな会社で、成果や実績を残す事は無理です。きっと体を壊して、お・し・ま・い・Death。

 

最後に

 

という訳で、デスマーチ第一話はここまでとなりますが、いかがでしたでしょうか?

 

デスマーチについては、話を分割してお届けしたいと思っております。

 

何故なら・・デスマーチ系の話は伝えたい事がいっぱいあるので、1つの記事だけで書くと、ものすごい長くなってしまうからです。

 

最近は長いブログにならないように、文字数を意識して書いている事もあり、この作戦を思い付きました!

 

という訳で第二話をお楽しみに!

 


フォロー待ってます!
シェア大歓迎!

コメントを残す

メールアドレスが公開されることはありません。