「デスマーチ」というものがあります。
「死の行軍」だとか、「死の行進」と呼ばれるものです。通称「デスマ」ですね。
無理難題なプロジェクト進行（特に納期）をこなすために長時間労働や休日出勤を重ね、スタッフの心身ともに蝕みながら遂行されていくプロジェクトの様をあらわす言葉です。
最近は割と、デスマが当たり前な状況というか、デスマの定義（特に納期的なもの）がわからないので、それがデスマなのかもわからないのですが、スタッフが優秀だと割と進行は早くなるし、能力次第なところもあったりもします。Wikipediaで見ると、一応定義はありますね。
「デスマーチ」という言葉を広めたのは、エドワード・ヨードンであると言われている。ヨードンは、その著書『デスマーチ：なぜソフトウエア・プロジェクトは混乱するのか』で、デスマーチの定義を「プロジェクトのパラメータが正常値を50 %以上超過したもの」[1]もしくは「公正かつ客観的にプロジェクトのリスク分析（技術的要因の分析、人員の解析、法的分析、政治的要因の分析を含む）をした場合、失敗する確率が50 %を超えるもの」[2]としており、具体的には以下のいずれかに該当するものと定めている。 参照：Wikipedia デスマーチ
で、このデスマーチにも色んな種類があって、4つに分類されるみたいなんで、興味の在る方は読んで見てください。
Contents
これもデスマーチになるのかな？
で、今回書こうとしたのはこのデスマーチではなく、これも一種のデスマーチなのかなぁ、ということ。
なにか、というと、このデスマーチは基本的には「プロジェクト」単位じゃないですか。で、このプロジェクトの枠を大きくしていくと、そこには会社経営なんかもあったりするのかなって。
制作会社やソフトウェア開発会社、ITだけにとどまらないかもしれませんが。
制作は入金が不確定
例えば、制作の場合ですと規模やその会社ごと、クライアントとの契約内容にも依りますが、凡そは「半金」というものをもらってプロジェクトを開始します。
数ヶ月に亘るプロジェクトですので、納品後に全金をいただくのではなく、費用の半分を最初にいただく、というものです。プロジェクトが途中で止まってもある程度の売上を保持したり、プロジェクト進行中の社員の給与などを支払うためですが、これはあくまで、納品出来て本来の費用がいただけるものなんですが、逆に言えば納品しない限りいつまで経ってもお金が入ってもないことを意味します（まぁ、当然ですけど。それに確定、不確定という話で言えば業界関係なく100％なんてものはあるわけなく、なんでも不確定ですが、制作はその可能性が高い、という感じでとらえていただければ）。
原稿が出ない、クライアントが忙しいなどで遅れる案件
問題なのは、その納品できない状況（制作側だけの要因でなかったりすることも多々あります）で本来予定していたタイミングで入金がないので、売上が安定しない、ということ。そのプロジェクトに携わってる外注さんとかへの支払いならまだ、納品出来てないから予定通りの支払いにはならない、で通用する場合もありますが、家賃とか税金とか給与とか定期的に支払わなければいけないものは多々あります。入金日と入金額が確定されないので、仮にその月は収入がなくても乗り越えられる、という体力（キャッシュ）がないと厳しいのです。（故にプロジェクトマネジメントをしっかりやって納期内終わらせるってことと、見立てはしっかりってとこなんですが）
デスマーチへの誘い
で、そうなるとどうなっていくか、というと、
- 予定したお金が入ってこない（＝プロジェクトは進行中もあれば停止中も）のもあり
- でも、次の仕事を取ってこないと会社が回っていかないor次の依頼が来る
- けどこんな状況だから外注に振らずに、若しくは外注に振っても少数で対応しようとする
- やはりどこかに無理があって、これも進捗が遅れる（本来の人員であれば回る規模なのに）
- この進捗が遅れることで、また入金の予定が崩れる
- ときには外注への支払いが遅れることで、外注が離れたり、同じ外注さん使いすぎて飛ぶことも
- そもそも外注費を削らないといけない、外注使えないとなると、社内でやるしかない
- ここで更にデスマが追加される
- トラブルや人員不足から納期が遅れる
- お金入ってこない
- 下手すれば次の仕事につながらない
- 別の仕事取ってくる
- 安くても確実にお金入ってくる仕事をたくさん取ろうとする
- もしくはもっと高いシステム開発案件を取りに行くが地雷案件の可能性高い
- 同じ理由＋要件定義などで時間がかかり複数のプロジェクトがデスマ化していく
といった感じで、どんどん経営悪化していきます。
そもそも、最初にしっかりとヒアリングとPMが出来ていて、クライアントコントロールと納期と予算の組み立てが合っていればこんなことにはならないのですが、なかなかそんな好条件が揃うことは難しく、結局スタッフに負担が行くことになりますが、会社や営業は数字を稼がないとそもそも給与の支払いも出来ないのでやらざるを得ない、でも制作・開発の現場は疲弊している、そんな状況ですよね。でもITだけでもないか、これは。メーカーさんの生産管理もこんな一面があるかもしれませんね。転職6回したけど、メーカー勤務はしたことがないのでわかんないですけど。
会社経営をプロジェクトとして捉えると、これもデスマーチなのかな、と
会社経営をひとつのプロジェクトとして捉えた場合、ひとつひとつのプロジェクトがタスクとなると、これもひとつのデスマーチなのかなぁ？と。経営デスマーチ？
自転車操業という言葉がありますが、これが近いのかな？Wikipediaで自転車操業を読んでみたけどちょっと違うような気もするし。デスマーチって技術者や技術不足が招く事象じゃなくて、PMを含む営業や経営サイド、管理側のクライアントとの力関係で起こることのほうが多いんじゃないかなって気がする。
じゃあ、対策は？っていうと・・・
そうは言ってもさ、というのが現状ではありますが。
これ、半金と残金というやり方が合っているのか？という気もする。プロジェクトにかかる日数分で均等割りしてもらったほうがいいんじゃないかな。
それか、進んだ分だけ、とか。請求業務の手間は増えますけどね。あと管理費とか。でもこれは制作側の言い分であって、クライアント側は多分こんなの許さないだろうしなぁ。工事現場とかだと、それだけ職人さんを拘束してますんで日当かかっちゃいますよって話だから、考え方はそれに近いはずなんだけどな。その作業にかかりきりってわけじゃないからだろうし、そこは見積もりのとり方にもよるか。人日計算とかはシステム会社とかだとやるけど、制作ではあまり見かけない。サイト制作でデザインモノなんかはデザインの質やデザインの得手不得手で変わってしまう気がするしね。デザインはページ数計算で、コーディングとCMSは人日計算がいいのかな、という気がしないでもないけど。わーこれ、答え出ないや。行き着く所はしっかりとPMやりましょうねってとこしかない。
エドワード・ヨードン著「デスマーチ―なぜソフトウエア・プロジェクトは混乱するのか
」