ここでは、まーそのー……いわゆるひとつの世間様に最も一般的とみなされていると考えられているとされている
デスマーチにつきまして説明している項目です。はい。

漫画とテレビドラマにつきましてですがー、えー……DEATH MARCHをご覧ください。

朝霧麻衣の作る料理につきましてですがー、あーそうですねー……夜明け前より瑠璃色なをご覧ください。
デスマーチの実態　　仕様参照ユーモア欠落症患者のために、ウィキペディアの専門家気取りたちが「デスマーチ」の項目を執筆しています。

デスマーチとは、3Kである情報処理業界が趣味でしばしば行う作業の形態、もしくはそれを題材とした週刊少年ジャンプに掲載された漫画作品とこれを元にしたテレビドラマである。目次

1 概要

2 内容

2.1 受注

2.2 設計

2.3 コーディング

2.4 動作テスト

2.5 納品


3 その他のデスマーチ

4 関連項目

5 （真面目な）外部リンク

5.1 参考書籍


概要 「概算ですが、構造型DBをOracleに置き換える程度で、業務は変わりません。大丈夫です。6月末にはご提供可能です。」――営業課長(写真右)が、顧客に高らかに宣言する。同行の設計主任(写真左)はデスマーチの始まりを予感していた。他社製メインフレームのオープンマイグレーション案件にて。

デスマーチ（死の3月）とは、年度末に受注した仕事の際に、「どれだけ多くのプログラムコードを書き込んで組み上げ、それをきちんと動作させられるか」を競う作業様式である。一般に 6d9d は年度末＝3月の恒例行事であるためにこのように呼ばれる。なおこれを競技（エクストリームスポーツ）として見なす場合も多い。

なお3月中の行事ではあるが、これが3月31日以降にずれ込む場合は、特例的にカレンダー上には3月32日・33日・34日…という日付が発生し、プロジェクトグループはマイクロサザエさんワールドに突入、何故か1日8時間労働で、同じ日付を正確に3回ずつ経験することになる。

この場合、納入するプログラム製品の動作性は、商品であるために「少なくとも動く事」が必須条件となるが、これにどれだけ新規のルーチンを組み込んで仕様を満たすかが競われる。これらではAPIといった中身のわからないブラックボックスなんか利用せず、独自に設計から初めて組み上げたり、旧来から定型の処理があるところを、「車輪の再発明」と呼ばれる方法でゼロからコードを興して組み上げて、開発ステップ数の増大を目指す。なお仕様が絶対であるため、仕様に記載されない部分は全く考慮されず、また仕様に不備があったら「最もストイックな形で仕様どおりの設計とする」ことが求められる。

この様式は、主に情報処理業界関係者の忍耐力育成や、仕様を遵守してその通りに組み上げる事（仕様以上の製品を作ってもいけない）、あるいは病弱な業界関係者のリストラを行うために必要と考えられており、業務系や商業系、通信系といった大抵の情報処理業界で毎年のように行われている。
内容

様々な情報処理業界で行われているが、概ね以下の流れに沿ってこの開発作業様式は進められる。
受注


受注金額は安く！

納期は短く！

これらでは、特に仕様を煮詰めるための営業の手腕が試される。この際には「顧客の思い付きやわがまま」の他、営業の「シュールで人を韜晦するような表現」が仕様中に盛り込まれ、また開発期間は最初から多少は厳しくさせるのが目的であるため、営業によって予想される作業工程の70?50％の期間に収められるのが通例である。ある驚異的な事例では30％を割り込む例や、受注の時点で設計が完了し開発が既に順調に始まっている、という事例も報告されている。これに求められる対価は、割り引かれた開発期間にて算定されるため、顧客にとっても対費用面で非常にお得である。

なおこの受注の際であるが、間違っても融通の利かないシステムエンジニア（プロジェクトリーダー）を同行させてはいけない。彼らSEは、実際の作業工程を念頭に、その2?3割増程度の安全率を設定する事を主張するため、顧客に嫌われる事がある。また実際の作業工程を一々説明して、その主張の正当性を説こうとしたがる点で、折角のこの作業様式を台無しにしてしまう危険性があるためである。特にそのSEが、作業工程をすぐさま構築して、営業を差し置いて話し始めると、営業の面目丸つぶれとなりがちである。後学のために素直でおとなしい新入社員のプログラマーを連れて行くべきだろう。
設計


顧客からの仕様要求はあいまいでも気にするな！

設計書なんて形だけでOK！

この段階では、営業が顧客に説明したとおりの作業工程・開発期間で収める事が主な作業となる。この場合は、通常業務で推し量ってもいけないし、また実際の設計で予想される難航点も指摘してはいけない。工程の不足を指摘するなどもってのほかである。

この段階においては、仕様を如何により複雑なプロセスで処理するかという点が重視される。例えば商業系データベースで「顧客のうち売上上位10名をリストアップせよ」という処理では、一端全データを端末にダウンロードし、それらを全て変数に代入、その上で総当りによる比較を行って売上順序をソート、上位10個だけをテキストファイルに出力し、これを読み出して処理を続行するという手法がとられる。間違っても問い合わせ言語を使ってデータベースの機能でそのようなリストを作成するような手抜きをしてはいけない。そのような処理は（20年前に導入された）顧客側の大切な（＝老朽化した）データベースサーバーに負担を強いるためである。

この段階では全作業工程の3割の期間を費やす。ちなみに非常に繊細な作業であるため、関係者には十分な休息と余暇、あるいは就業中に漫画を読んだり2ちゃんねるへの書き込みで息抜きする事は、大目に見るべきである。関係者に精神的な負担をかけるのも望ましくないため、例え無断欠勤しても良いデスマーチの上では叱責してはいけない。

なおこの段階で顧客に連絡をとって、その手を煩わせてはいけない。これはデスマーチを行う上では最大のマナー違反である。
コーディング


進捗管理は自己申告で！

無能者によるバグコード歓迎！

失踪・体調不良による人員離脱は高得点！

この段階に入るといよいよ実際のプログラミングが行われる。この際、制作される関数は全て各々のプログラマーが自由に定めてよい。この関数名は付箋紙に書かれて関係者に閲覧される。プロジェクトリーダーは定時で帰っても良いし、アルバイトのコーダー（プログラムを入力する人）は社員の手を煩わせる権限は無いが、社内の参考書籍や資料、あるいはインターネット上のウェブサイトが自由に閲覧できる環境にあり、また仕様書にない事は独自解釈で作業を進めても良い。このような非常にリベラルで自由闊達とした作業環境で、主要な関数の8?9割が設計・開発される。

この段階まではデスマーチ導入部分の、いわば「凪ぎ」の部分なので、関係者も大変に余裕のある態度で作業が進められ、概ね作業工程の6割程度がこの期間に費やされる。
動作テスト


1つのバグを潰して新しいバグが2つ！

仕様変更！！！

次の段階では前2段階で消費された作業期間の残りの期間で、各々の関数をまとめあげて、いちど製品となるシステムの形にして見る。これを動かしてみて仕様通りに動かなかったら、いよいよデスマーチの幕開けである。まずこの段階では、仕様通りに一応動く状態にまで仕上げる。

この段階で顧客には、一度仕様どおりかどうか仮製品としてのシステムを見せた方が良いだろう。この段階で顧客に具体的な仮製品を見せて操作させてみることで、顧客も新たな要望を持つ場合もあるため、これを対価据え置きで実現してあげれば、喜ぶ事請け合いである。このため追加注文はおおいに受けるべきである。

なおこの段階では並行してバグの修正も行われる。プログラマーやシステムエンジニアなど、情報処理業界には夜型人間が多いため、作業効率も夜間遅い時間になるほどに向上すると考えられる。このため少々の残業は大目に見るべきだ。彼らは自発的に残業しているので、残業代も必要ない。中には徹夜をすることで凄い元気になる関係者も多く、よく深夜から早朝にかけて、けたたましい位の笑い声が職場から洩れる事もある。また稀にロープを持ってそれを首輪のようにして楽しんでいる関係者も居る。中にはあまりの仕事の楽しさに、羽目を外す関係者も少なくない。余った元気が股間に行くと証言する業界関係者もいるほどである。
納品


マジカルワード「運用でカバー」

納品とは、デスマーチにおける最大の儀式である。顧客は形式だけ整えられたテスト仕様書とエビデンスに一通り目を通し、納品物が如何に仕様を達成するべく製作されたかよりも、報告書の記載について些細な誤りを指摘する。開発行程で記録された様々な瑕疵や不具合の件数は時間に半比例して収束するが、納品の儀式に伴って信頼度曲線は一次関数となり急激な成長を見せる。多くの場合、エビデンスに記載されている記録が単体試験と同等のものであり結合試験として体裁を整えていない事が信頼度曲線を著しく成長させ、納品物は全く手を加えられていないにも関わらず、著しい信頼性の向上が見られる。

納品物は複数の協力会社から提出されたプログラムを結合し、一つのシステムとして動作を開始する。多くの場合、その試みは入力データが仕様を満たしてない事を発端にして失敗する。多くの人手によって入力データの修正が行われシステムに入力される。そしてシステムは、顧客が希望しない動作が起こり、大量のログファイル（あるいはコアダンプ）と共に停止する。システムが正しく動くかどうかは、次のプログラムによって求める事ができる。#include <stdio.h>#include <stdlib.h>#include <time.h>void main(){ char *project[2] = {"good", "bad"}; int result; result = srand((unsigned) time(NULL)) * 0 + 1; printf("project is %s\n",project[result]);}

こうして何百万行あろうとたった一行の演算式の挙動不振で大量破壊兵器と化するのは常である。笑えない。たけしの挑戦状の開発者は死にました。

不確定性原理に基づいて、システムの障害原因となった場所と、システムが障害を起こすタイミングは同時に決定できない。システムの障害原因を特定すべくログを残すなど観測行為を行ったが為に、システムのマルチタスク性が阻害され、例えば排他制御が行われていなかったが為に起きる不具合は全く観測不可能になる。逆に、システムに複数のデータを与えて障害が起きるタイミングを特定しようとすると、複数のモジュールが一斉に不具合を起こし、大量の問題とはならない情報のログファイルを残してシステムは停止し、障害原因がどのタスクで起きたのかを特性する事が困難となる。
その他のデスマーチ

このようなデスマーチであるが、中には戦争の期間中に捕虜に対する嫌がらせとして、兵隊にプログラム開発を強要する事がある。ただし兵隊は戦争するのが仕事で、プログラムを作るのには向いていないため、テクノストレスなどの問題も発生する。

このため戦時中の捕虜を使ったデスマーチは、戦争犯罪として問題視されている。

太平洋戦争中、フィリピンにおいて日本軍は、マッカーサーに見捨てられた兵士を捕虜として、ボーイズラブ系18禁ゲームの開発任務を強要したが、捕虜らが作り出すソフトはアメコミ絵のマッチョが絡み合う内容で、日本軍将校は内容の稚拙さに衝撃を受け、バターンと転倒する者が相次いだ。
関連項目

コアラのマーチ　

日産・マーチ

デスマッチ

デスマーチノート

DEATH MARCH

（真面目な）外部リンクユーモア欠落症患者のために、ウィキペディアの専門家気取りたちが「デスマーチ」の項目を執筆しています。この記事「デスマーチ」は何故か「DEATH MARCH」とネタや題材がダブっています。どちらが真実なのかは神のみぞ知ります。

⇒プロジェクトマネジメントスキル実践養成講座

⇒デスマーチの構造：プロジェクトは始まる前に失敗している

ブラック会社に勤めてるんだが、もう俺は限界かもしれない

参考書籍

『デスマーチ なぜソフトウエア・プロジェクトは混乱するのか』
エドワード・ヨードン著・松原友夫、山浦恒央訳（ISBN 4901280376）

更新日時:2018年10月30日(火)15:12
取得日時:2021/07/31 13:29