IT業界が外部の人間から敬遠される理由の一つに﹁デスマーチ﹂がある。

ほとんど実現不可能に思える無理なスケジュールで、深夜におよぶ残業、休日出勤の連続、人海戦術でほとんど役に立たない新人までが駆り出され、終わりの見えないプロジェクトの完成にひた走る、これがデスマーチである。

 

そこではプログラマは一人また一人と過労に倒れ、うつろな目でキーボードを叩き続けるプログラマの連続勤務時間は20時間を優に超える、といった光景が見られる。

このようなデスマーチについて、人材の疲弊やそれに伴う退職など、ITベンダー側の不利益が語られることは多いが、クライアント側の不利益、もっといえばプロジェクトの成果物自体がデスマーチで台無しになってしまうことはあまり知られていない。

 

デスマーチのきっかけ

営業の無謀な受注、仕様の調整不足などで、システムの実装行程が確保できず、どうやっても通常の開発体制ではシステムの完成がおぼつかなくなった時、ベンダーとクライアントで納期を延長するかそのまま強行するか、という話し合いがもたれる。

設定された納期にはキャンペーンの開始や、製品の出荷など、システムの開発そのものとは直接関係のない事情が関係している場合が多い。

もし納期を遅らせる、という判断をすれば、クライアント自身が各方面との調整することを余儀なくされるだろう。

 

一方、納期をそのままに、デスマーチを敢行するという決断をベンダーが下した場合、それが失敗した時のリスク、成功する確率や成功したとしてもどれほど人材が疲弊するかといった、ベンダー側にかかるコストはその時点では未知数である。

ベンダー側の営業やディレクターは一般的に、不明確なコストに直面した時、﹁今回は︵あるいは今回も︶なんとかなるだろう﹂と楽観的になる傾向があるし、彼らにとっての誠実さの結果として﹁なんとかしなくてはならない﹂という意識が強くなる。

 

またクライアントは納期を延ばした時に発生する調整の難しさは容易に想像できるが、デスマーチによって納品を強行することが、どのような結果をもたらすかについては知らない。

このような楽観的なベンダーと無知なクライアントが話し合うと、

﹁なんとか間に合わせてもらわないと困りますよ﹂

﹁そうですね。なんとかしましょう！﹂

といった調子で、デスマーチが強行されることになる。

 

デスマーチの実際

デスマーチとは、作業時間を増やして通常の開発スケジュールを暦上で短縮させるという行為であると、ディレクターやクライアントは信じようとしている。

だが実際は、通常のスケジュールで予定された開発作業と、デスマーチで行われる開発作業は質的に同じではない。むしろその目的も、工程も全く異なると言っていい。

 

強いプレッシャーの中で、かき集められたプログラマ達は要求仕様を見直して優先順位を決める。そして特に明確に仕様が定められた正常系のフローに注目する。

例えばECサイトなら﹁商品をカートにいれて決済ボタンを押し、クレジットカード決済を行い、注文データをデータベースに書き込む﹂といったような、正常なユーザー操作の流れだけに注目して、その実装に注力するのである。

なぜならクライアントやディレクターがまずチェックするのは、﹁そのシステムが正常に動作しているか﹂だからだ。

 

肝心なのは、結果として、正常でない﹁異常な操作＝異常系﹂、中でも仕様が不明確なフローが後回しにされることである。

例えば、クレジットカード番号が間違えていて、与信トランザクションが失敗したとか、決済のタイミングで商品の在庫が切れていたとか、そういった例外処理は、その取り扱いについて明確な仕様が定まっていない時︵そして大抵定まっていない︶ひとまず、プログラマの視界から意図的に外される。

これは異常系の処理が重要でない、という意味ではない。

データベースの不整合など、運用上の︵時には回復困難な︶大きなトラブルの原因が異常系の取り扱いを誤ったことにあることも多い。

 

しかし、デスマーチという特殊な状況下では、これらを重視することができない。

なぜなら悠長にそれらを実装していては、他の正常系フローの実装が全て完了するかわからないし、不明確な仕様をクライアントに確認する時間がないからだ。

期限のプレッシャーに追い回される恐怖を前にして、仕様が定かではない異常系の処理は提出前日の早朝に意識があれば対応しよう、というところまで、後回しにされる。

 

正常系の実装、またはテスト工程をある程度通過できる実装がほとんど終わりかけた早朝、プログラマはキーボードに突っ伏したまま、意識を失う。

薄れいく意識の中で、クライアントの検収時や、テスト工程、または運用開始後(!)に不具合が見つかり、無骨なエラーメッセージが画面に表示された時のことをプログラマは想像する。

だが、疲労の極地で、自暴自棄になったプログラマは、﹁それは想定外でした。すぐに修正します﹂と言い訳すれば良いのだ、と考えて、眠りに落ちる。

そして彼が長い眠りから目覚めた頃、ソースコードはクライアントに提出されるのである。

 

意図的にしろ、偶然にしろ、彼らがデスマーチで作っているものは、クライアントやディレクターが軽くチェックした時に﹁ちゃんと出来ているじゃないか﹂と言われるようなハリボテである。

彼らは本来無能ではないが、結果的に、デスマーチは彼らを思慮のない、ただ手が早いだけの無能な働き者のように振る舞わせてしまう。

ジェリー・ワインバーグは、プログラマにとってのデスマーチがどのようなものかを端的に説明している。

人は、期限通りに仕事をするために多くの残業をするのではなく、仕事が期限通りにできそうもないことがわかったときに、非難から身を守るために残業するのだ。 *1

 

デスマーチの本当の問題

これまでデスマーチの語る上で、最も多く喧伝されているのは劣悪な労働環境がもたらす、人材の疲弊というテーマだ。

しかし、デスマーチの問題はそれだけではない。

 

一つは、本来有能で、仕様の調整もでき、完全なシステムを構築できたプログラマの能力を意図的に落として、システムとは到底呼べないような不完全な﹁何か﹂を作らせることだ。

これは、プログラマのプロフェッショナリズムと誇りを失わせるし、何よりも制作部門全体に日常的なモラルハザードを引き起こさせるきっかけになる。

 

もう一つは、デスマーチの﹁奇跡的﹂な成果を成し遂げた結果、システムに未対応の例外や、隠された仕様の不備といった、﹁技術的負債﹂が大量に残ることである。

この技術的負債の代償はベンダーもクライアントも、運用開始後のクレーム対応、臨時改修などで、相応に払わされることになるし、某銀行のATMトラブルのようにエンドユーザーにまで被害が及ぶこともある。

 

総じて、デスマーチにベンダーの体を張った﹁言い訳﹂以上の価値はない。

 

もしこのようなデスマーチの実態が広く社会に知られれば、デスマーチを宣言した営業やディレクターは本当の意味での誠実さを疑われても仕方ないし、それを許可したクライアントも自ら騙されに行ったようなものだと社内で非難されるだろう。

 

だが、彼らはデスマーチの結果とその意味について理解していない。

むしろ、積極的に興味を持たないようにしているのではないか、とさえ思える。

自らのマネジメントの失敗を認めることなしに、また重大な決断をする勇気を持つことなしに、プロジェクト進行の体裁を保つのに、デスマーチほど便利な手段はそうないからだ

 

こうして、今日もデスマーチは繰り返される。そしてそのコストは社会全体に、静かに、確実に積もっていくのである。