ここでは、まーそのー……いわゆるひとつの世間様に最も一般的とみなされていると考えられているとされている
デスマーチにつきまして説明している項目です。はい。
漫画とテレビドラマにつきましてですがー、えー……DEATH MARCHをご覧ください。
朝霧麻衣の作る料理につきましてですがー、あーそうですねー……夜明け前より瑠璃色なをご覧ください。
デスマーチの実態 仕様参照ユーモア欠落症患者のために、ウィキペディアの専門家気取りたちが「デスマーチ」の項目を執筆しています。
デスマーチとは、3Kである情報処理業界が趣味でしばしば行う作業の形態、もしくはそれを題材とした週刊少年ジャンプに掲載された漫画作品とこれを元にしたテレビドラマである。目次
1 概要
2 内容
2.1 受注
2.2 設計
2.3 コーディング
2.4 動作テスト
2.5 納品
3 その他のデスマーチ
4 関連項目
5 (真面目な)外部リンク
5.1 参考書籍
概要 「概算ですが、構造型DBをOracleに置き換える程度で、業務は変わりません。大丈夫です。6月末にはご提供可能です。」――営業課長(写真右)が、顧客に高らかに宣言する。同行の設計主任(写真左)はデスマーチの始まりを予感していた。他社製メインフレームのオープンマイグレーション案件にて。
デスマーチ(死の3月)とは、年度末に受注した仕事の際に、「どれだけ多くの
5fe
プログラムコードを書き込んで組み上げ、それをきちんと動作させられるか」を競う作業様式である。一般には年度末=3月の恒例行事であるためにこのように呼ばれる。なおこれを競技(エクストリームスポーツ)として見なす場合も多い。
なお3月中の行事ではあるが、これが3月31日以降にずれ込む場合は、特例的にカレンダー上には3月32日・33日・34日…という日付が発生し、プロジェクトグループはマイクロサザエさんワールドに突入、何故か1日8時間労働で、同じ日付を正確に3回ずつ経験することになる。
この場合、納入するプログラム 5bd 製品の動作性は、商品であるために「少なくとも動く事」が必須条件となるが、これにどれだけ新規のルーチンを組み込んで仕様を満たすかが競われる。これらではAPIといった中身のわからないブラックボックスなんか利用せず、独自に設計から初めて組み上げたり、旧来から定型の処理があるところを、「車輪の再発 5a8 明」と呼ばれる方法でゼロからコードを興して組み上げて、開発ステップ数の増大を目指す。なお仕様が絶対であるため、仕様に記載されない部分は全く考慮されず、また仕様に不備があったら「最もストイックな形で仕様どおりの設計とする」ことが求められる。
この様式は、主に情報処理業界関係者の忍耐力育成や、仕様を遵守してその通りに組み上げる事(仕様以上の製品を作ってもいけない)、あるいは病弱な業界関係者のリストラを行うために必要と考えられており、業務系や商業系、通信系といっ?
5a8
??大抵の情報処理業界で毎年のように行われている。 様々な情報処理業界で行われているが、概ね以下の流れに沿ってこの開発作業様式は進められる。 これらでは、特に仕様を煮詰めるための営業 なおこの受注の際であるが、間違っても融通の利かないシステムエンジニア(プロジェクトリーダー)を同行させてはいけない。彼らSEは、実際の作業工程を念頭に、その2?3割増程度の安全率を設定する事を主張するため、顧客に嫌われる事がある。また実際の作業工程を一々説明して、その主張の正当性を説こうとしたがる点で、折角のこの作業様式を台無しにしてしまう危険性があるためである。特にそのSEが、作業工程をすぐさま構築して、営業を差し置いて話し始めると、営業の面目丸つぶれとなりがちである。後学のために素直でおとなしい新入社員のプログラマーを連れて行くべきだろう。 この段階では、営業が顧客に説明したとおりの作業工程・開発期間で収める事が主な作業となる。この場合は、通常業務で推し量ってもいけないし、また実際の設計で予想される難航点も指摘してはいけない。工程の不足を指摘するなどもってのほかである。 この段階においては、仕様を如何により複雑なプロセスで処理するかという点が重視される。例えば商業系データベースで「顧客のうち売上上位10名をリストアップせよ」という処理では?
169f
?一端全データを端末
内容
受注
受注金額は安く!
納期は短く!
設計
顧客からの仕様要求はあいまいでも気にするな!
設計書なんて形だけでOK!
この段階では全作業工程の3割の期間を費やす。ちなみに非常に繊細な作業であるため、関係者には十分な休息と余暇、あるいは就業中に漫画を読んだり2ちゃんねるへの書き込みで息抜きする事は、大目に見るべきである。関係者に精神的な負担をかけるのも望ましくないため、例え無断欠勤しても良いデスマーチの上では叱責してはいけない。
なおこの段階で顧客に連絡をとって、その手を煩わせてはいけない。これはデスマーチを行う上では最大のマナー違反である。 この段階に入るといよいよ実際のプログラミングが行われる。この際、制作される関数は全て各々のプログラマーが自由に定めてよい。この関数名は付箋紙
コーディング
進捗管理は自己申告で!
無能者によるバグコード歓迎!
失踪・体調不良による人員離脱は高得点!
この段階まではデスマーチ導入部分の、いわば「凪ぎ」の部分なので、関係者も大変に余裕のある態度で作業が進められ、概ね作業工程の6割程度がこの期間に費やされる。 次の段階では前2段階で消費された作業期間の残りの期間で、各々の関数をまとめあげて、いちど製品となるシステムの形にして見る。これを動かしてみて仕様通りに動かなかったら、いよいよデスマーチの幕開けである。まずこの段階では、仕様通りに一応動く状態にまで仕上げる。 この段階で顧客には、一度仕様どおりかどうか仮製品としてのシステムを見せた方が良いだろう。この段階で顧客に具体的な仮製品を見せて操作させてみることで、顧客も新たな要望を持つ場合もあるため、これを対価据え置きで実現してあげれば、喜ぶ事請け合いである。このため追加注文はおおいに受けるべきである。 なおこの段階では並行してバグの修正も行われる。プログラマーやシステムエンジニアなど、情報処理業界には夜型人間が多いため、作業効率も夜間遅い時間になるほどに向上すると考えられる。このため少々の
608
残業 納品とは、デスマーチにおける最大の儀式である。顧客は形式だけ整えられたテスト仕様書とエビデンスに一通り目を通し、納品物が如何に仕様を達成するべく製作されたかよりも、報告書の記載について些細な誤りを指摘する。開発?
5a8
?程で記録された様々な瑕疵や不具合の件数は時間に半比例して収束するが、納品の儀式に伴って信頼度曲線は一次関数となり急激な成長を見せる。多くの場合、エビデンスに記載されている記録が単体試験と同等のものであり結合試験として体裁を整えていない事が信頼度曲線を著しく成長させ、納品物は全く手を加えられていないにも関わらず、著しい信頼性の向上が見られる。 納品物は複数の協力会社から提出されたプログラムを結合し、一つのシステムとして動作を開始する。多くの場合、その試みは入力データが仕様を満たしてない事を発端にして失敗する。多くの人手によって入力データの修正が行われシステムに入力される。そしてシステムは、顧客が希望しない動作が起こり、大量のログファイル(あるいはコアダンプ)と共に停止する。システムが正しく動くかどうかは、次のプログラムによって求める事ができる。#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]);} こうして何百万行あろうとたった一行の?
1691
?算式の挙動不振で大量破壊兵器と化するのは常である。笑えない。たけしの挑戦状の開発者は死にました。 不確定性原理に基づいて、システムの障害原因となった場所と、システムが障害を起こすタイミングは同時に決定できない。システムの障害原因を特定すべくログを残すなど観測行為を行ったが為に、システムのマルチタスク性が阻害され、例えば排他制御が行われていなかったが為に起きる不具合は全く観測不可能になる。逆に、システムに複数のデータを与えて障害が起きるタイミングを特定しようとすると、複数のモジュールが一斉に不具合を起こし、大量の問題とはならない情報のログファイルを残してシステムは停止し、障害原因がどのタスクで起きたのかを特性する事が困難となる。 このようなデスマーチであるが、中には戦争の期間中に捕虜 このため戦時中の捕虜を使ったデスマーチは、戦争犯罪として問題視されている。 太平洋戦争中、フィリピンにおいて日本軍は、マッカーサーに見捨てられた兵士を捕虜として、ボーイズラブ系18禁ゲームの開発任務を強要したが、捕虜らが作り出すソフトはアメコミ絵のマッチョが絡み合う内容で、日本軍将校は内容の稚拙さに衝撃を受け、バターンと転倒する者が相次いだ。
動作テスト
1つのバグを潰して新しいバグが2つ!
仕様変更!!!
549
納品
マジカルワード「運用でカバー」
その他のデスマーチ
関連項目
コアラのマーチ
日産・マーチ
デスマッチ
デスマーチノート
DEATH MARCH
(真面目な)外部リンクユーモア欠落症患者のために、ウィキペディアの専門家気取りたちが「デスマーチ」の項目を執筆しています。
d17
この記事「デスマーチ」は何故か「DEATH MARCH」とネタや題材がダブっています。どちらが真実なのかは神のみぞ知ります。
⇒プロジェクトマネジメントスキル実践養成講座
⇒デスマーチの構造:プロジェクトは始まる前に失敗している
ブラック会社に勤めてるんだが、もう俺は限界かもしれない
参考書籍
『デスマーチ なぜソフトウエア・プロジェクトは混乱するのか』
エドワード・ヨードン著・松原友夫、山浦恒央訳(ISBN 4901280376)
更新日時:2018年10月30日(火)15:12
取得日時:2023/01/24 19:43