今回はデスマーチの話です！
突然ですが、デスマーチって聞いた事ありますか？
もし、ご存じないのならIT業界は昔よりも平和になったのかもしれせん。
ITの世界では徹夜・終電は当たりまえの、残業が100時間/月超えるような、過酷な労働をよくデスマーチなんて呼びました。（略してデスマ）
ちなみに用語の使われ方の例としてはこんな感じです。
この様に日本では「デスマ」なんて愛称で呼ばれているデスマーチ。
今回もいつものノリで語りますよぉ！
これってそもそも日本の話？
徹夜とか残業が多いとかって、日本だけにありそうな話に思えません？
ところが、デスマーチはアメリカで生まれた言葉なんです。
エドワード・ヨードンの著書「デスマーチ：なぜソフトウエア・プロジェクトは混乱するのか」
実は、こんな著書がありまして「デスマーチ」はこの著者が作った言葉らしいのです。
アメリカでこの定義が生まれたというのは、意外じゃないですか？
ソフトウェアプロジェクトの問題は、割と世界共通の話っぽいすね。
デスマーチとは？
では「デスマーチ」ってどんな状況を指すのでしょう？
デスマーチを直訳すると「死の行軍」もともとは、戦場の捕虜などがやらされてるような過酷な労働を指します。
これがIT業界だと、どのように「死の行軍」になるかといいますと。
プロジェクトメンバーがいくら残業してもまるで終わりが見えない・・終わらない。
残業時間はどんどん増えていき、残業が100時間/月を超える事態に発展。休日もない。
そして体調不良の人、ある日会社にこなくなる人、突然会社を辞める人が続出し、まるで死に向かって進むような失敗プロジェクト・・。
ざっくり言うとこんな感じです。
デスマーチが起こる理由
では、そもそも何でこんな事が起きるのか？
エドワード・ヨードンの著書によると以下4つのどれかに該当する場合、デスマーチが起きると言ってます。
- 与えられた期間が一般の半分以下
- エンジニアの必要な人数が半分以下
- 予算が通常の半分以下
- 機能や性能などの要求が倍以上である
デスマ経験者の私は思ったのですが・・
マジでホントこれなんですよ・・
なのでデスマ経験者がこの本を読むと「あるある」視点で楽しめるのではないでしょうか。
では、何故でこうなってしまう事が多いのか？
今回は原因となる4つのうちの１つである、こちらにフォーカスしてお話したいと思います。
与えられた期間が一般の半分以下
ここからはエドワード・ヨードンが語ってる内容ではなく、私の経験を元にした視点でのお話しになります。
与えられた期間が一般の半分以下
まずこれは、いわゆる「納期の問題」なんですけど、よくあるのが・・
通常は半年かかるものを、お客が「2か月でやってくれ！」出来るなら御社に任せる！みたいな案件、たまにありませんか？
こういう案件がきたとき、会社や上司が以下の様な体質だと、無茶なスケジュールでも、そのまま進んでしまうケースが多いんです。
- 作業時間の割り出しをする文化がない
- 工数は残業ありきで考える
- 文句のある奴はトップダウンでヨシ！
- 4か月分くらいなら根性で埋まる
- 最強の言葉は「なんとかなる」
- 過剰なお客様は神様です精神
要は、この体質が原因で、誰が何をすれば良いかもよく解らないまま「やります！」と言ってしまう状況が多発していた訳です。
どうしてそんな事が起きるの！？よく考えれば解る事じゃん。バカなの？
外から見てる人はこの様に思うかもしれません。
では、どうしてこうなってしまうか？
ここからは実話をもとにストーリー形式で話します。
デスマーチに発展するストーリー
デスマーチの火種はこんな状況から始まっていきます。
お客様の目線
営業と経営者の目線
① この状況から、お客様・営業・経営側で「いっしょに壁を乗り越えましょう！」と気持ちが一体となる
② 予定通り納品できるかの可否なんてどうでもいい「会社としてやるしかない！」になる。
③ 当然、現場から「そのスケジュールでは出来ない」と声が上がる
④「これは会社としてのチャレンジだ！甘えるなよ？」という根性論がトップダウンで発動される。
⑤不足している作業時間をどう埋めるか？対策もないまま根性で作業を進めていました。
しかし、どんなに頑張ったところで、納期には間に合わない事が次第に解りはじめます。
⑥納期が近づいてくると、経営陣と営業がエンジニアに「早く終わらせろ！」と責め始める。
⑦不足した時間を埋める為、エンジニアも根性で徹夜を繰り返す。
⑧プレッシャーとストレスから、エンジニアが体調を壊して休職。もしくは耐え切れず退職する。
⑨別な人を無理やりアサインして、伝家の宝刀である根性論で無茶ぶりをする
⑩そして③～⑧を後任の人がまた繰り返す。
⑪結果、納期が守られるどころか、とうとう作業者もいなくなりプロジェクトが崩壊。
どうですか？まさにデスマーチ「死の行軍」ぽくないでしょうか？
嘘みたいな話ですけど、これ普通によくある話でした。
この教訓から解る事
誰がみても明らかにスケジュールが無茶な案件は、他の業者に頼んでも同じです。
根拠となる材料を集め、ちゃんと説明して「全部は無理だがここまでならできます」みたいな交渉の余地だってあったはずです。
プロジェクトとは、お客様が業者に丸投げをして夢をかなえる事ではありません。
大事なのは、お客様と一緒に考え仕組みを作る事。
売れなきゃ会社はつぶれますんで、営業や経営陣は間違っていません。
だからこそエンジニアも、もっと全力でリスクを伝えて戦うべきでした。
お客様も「業者がOKと言うならOKなんだろう」と思わず、もっと確認をすべきだったんです。
きっと・・それぞれが心のどこかで「誰かに丸投げすればヨシ！」「自分が見える部分以外は他人事」と思っていた。
だからデスマーチが起きたのではないでしょうか。
そして教訓はもう１つあります。
それは、自分のいる会社が、ブラックであるかどうかを判断できるという事です。
どんな企業にも失敗はありますし、チャレンジも必要だと思います。
しかし、こういった状況が多発しているにも関わらず、改善策を会社がまったく取っていない場合、それは明らかに異常です。
そんな会社で、成果や実績を残す事は無理です。きっと体を壊して、お・し・ま・い・Death。
最後に
という訳で、デスマーチ第一話はここまでとなりますが、いかがでしたでしょうか？
デスマーチについては、話を分割してお届けしたいと思っております。
何故なら・・デスマーチ系の話は伝えたい事がいっぱいあるので、1つの記事だけで書くと、ものすごい長くなってしまうからです。
最近は長いブログにならないように、文字数を意識して書いている事もあり、この作戦を思い付きました！
という訳で第二話をお楽しみに！
