（2017/03/09）デスマーチは人を苦しめ疲弊させポンコツな製品しかできないことが一番の問題（2002年みずほシステムトラブル）
おはようございます。
2017年3月の筆者の体験に基づくシステム統合失敗プロジェクトに関するブログ配信記事です。
今日の記事は長くなります。
2000年代の初頭、筆者は某みずほ銀行という大きな金融機関（メガバンク）を誕生させるため、３つの銀行の勘定系システム（預金、内国為替、融資、外国為替や債券といった、銀行の本源的データを担う基幹系システム）を統合するというプロジェクトに参画できるという「栄誉」、いやもとい「刑期3年の懲役に等しい扱い」にあずかりました。
将来において、大規模システムトラブルの嚆矢として知られるようになるこのプロジェクトは、いわゆるＩＴ業界で敬遠されるデスマーチのはしりでもあったと思うのですが、ここで、歴史的デスマーチの最前列に従事したと自負する筆者から、デスマーチにおいては人が疲弊するという以上に起こりうるより悪い問題点について挙げたいと思います。
後進には誤った道を取ってほしくないと強く願っております。
改めて、デスマーチの定義
デスマーチとは、特にＩＴ業界において、ほとんど実現不能である納期的にも人員リソース的にも無理なスケジュールで突貫的に行われる作業プロジェクトのことを指します。
だいたい、人員の過剰酷使による深夜におよぶ残業（深夜と早朝の区別がなくなる）、休日出勤の連続（平日と休日の境目がなくなる）、人海戦術でほとんど役に立たない新人や別業務系統の協力業者の人々までが駆り出され（システムセンターは全国の方言のるつぼと化す）、終わりのないプロジェクトの完成にひた走るというものです。
プログラマーとして作業する者の目は死にそうになり、仕様を出す業務側やテスト工程のユーザーも同じくうつろな視線で疲弊しきっているという状況になります。
もう、3日風呂に入っていないとか、床で寝るのならプリンタや複合機のそばがエアコン切れた冬のオフィスでも暖かいよ、といった会話がなされます。
筆者もシュレッダーのごみを集めたビニール袋を布団代わりにして寝たこともあります。
ビニールですから汗を吸いませんし、寝苦しいのですが、意外にシャワシャワして気持ちよかった記憶が昨日のことのようです。
歯磨きは、横のトイレです。
早朝の、清掃員のおばちゃんにあいさつするのも慣れました。
デスマーチは人の心を蝕む
このような状況下において、人は自己防衛のため、うつろな目になります。
昼飯は5分で素うどんを書き込み、残りの昼休みに非常階段の屋上で寝るのも慣れます。
しかしながら人は疲弊し、一人また一人と強制的に退場になっていきます。
補充はされますが、３日もたてばこれまでのメンバーの仲間入りでございます。
しかし、デスマーチの真の問題は、人材が（それも有為な人材であればあるほど）壊れてしまうということ以上にあるのです。
それは、「ろくな製品ができずにポンコツが出来上がる」ということなのです。
ポンコツな製品とも言えないシロモノの出来上がり
もちろん、デスマーチにプロジェクト要員を追い込む外部環境要因はたくさんあります。
だいたい、システムの開発そのものとは全く関係ないところの、３行それぞれの個別行のメンツやよくわからない競争意識といったものが阻害要因として立ちはだかります。
例えば銀行番号。
３つがそれぞれの自分が使っていた銀行番号を推すものですが、何か一つに決めないとシステム的には進みません。
0001という一番わかりやすい番号を持っている、国立第一銀行由来の番号を使えばいいじゃないかと思っても、3行統合だから0003を使えという人が現れてまとまりません。
設定された納期だけが迫ってくるのに、基幹仕様が決定しないという、システムの開発期間はますます削られていくという状況なのです。
この設定された納期は、単にキャンペーン的に定めたり、世間や株主にとりあえず伝えた期日であるだけのことが多く、この日に正式なサービスが提供できるという本来の要素が考慮されることは「殆ど」ありません（最近は変わっているかもしれませんが）。
したがって、デスマーチにおける人心の疲弊は、こんな短期間にこれだけの仕様をプロとして構築してテストして自信をもってお届けできる、という自信を根底から覆すプロジェクトそのものの悪意であり、これによりプロジェクト要員の誇りを根こそぎ奪ったプロジェクトはデスマーチとなり、そして自信と誇りを失った夢遊病者のようなメンバーから生み出される、とても製品とは言えない品質のシロモノを生み出して社会に害悪をまき散らすということになるのです。
デスマーチの実際の形
デスマーチとは、同じ開発行為を、スケジュールを短縮して暦の上では短縮させることであると発注側は信じようとしていますが全く違います。
まず、開発行為自体が真面目にやっていても到底間に合わないので、内容が「省略」されたものに変容します。
要するに、品質目標が低く見積もられるのです。
そして、ろくでもないものをとりあえず作る、というプロジェクトに対するメンバーの忠誠心や誇りは粉々に砕かれるのです。
プロにとって、とりあえず動くだけのハリボテを作れと言われることくらい屈辱なものはなく、いいものを作ろう、作りたいという健全な精神は失われます。
これは、単純に作業が深夜に及んできつい、というものではないのです。
昔の、ソニーの研究室では確かに深夜までみな何か開発作業をしていました。
しかし、それはやらされてやっていたのではなく、世界を驚かせるものを作ってやりたいという技術者魂のなせる業だったのです。
こういう環境では人はそう簡単には倒れません。
倒れるのは、やっていることに意味を見いだせなくなった場合に顕著なのです。
こうしてハリボテが出来上がる
例えば銀行の決済系システムであれば、とにかくデーターベースにある決済を消し込む流れだけ、そのシステム的な実装のみに注力します。
エラーになった場合の処理など関係ありません。
なぜなら、ハリボテですから、異常なデータが投入されるのはユーザーのせいと割り切らないとやってられないからです。
異常なデータが投入されても異常であるとユーザーに知らせることができる異常系の処理や、そもそも異常なデータを受け付けず水際でエラーメッセージを出して排除するといった異常系の処理は、後回しにされたあげく実装されません。
すべては、エラーの時の仕様など決まっていない、ということで、意図的に外すのです。
こうして、将来このシステムが世に出たときに、必ず顧客を混乱させ迷惑をかけ、世間に悪い事例として知られる欠陥が積もり積もって内蔵されていきます。
時限爆弾のようなものです。
しかし、プロジェクトがデスマーチとなっている状況では、これら将来の禍根はまったく重視されないのです。
とにかくハリボテの期限のプレッシャーに追い回されており、その正常系期限厳守の圧力にかろうじて抗するだけで精一杯です。
そうして期限がやってきて、ポンコツなハリボテを納品して、そしてプロジェクトチームは解散となります。
こうして、世間で時限爆弾が爆発した時に再招集されるまで、この不幸な人たちのつかの間の休日が訪れるというわけです。
本来、みな有能な使いどころのあるメンバーが、このような流れの中、まともなシステムとは到底呼べない品質の適当なものを作ってしまうということがデスマーチの最もよくない効能ではないかと思うのです。
デスマーチの現象自体も問題だが、その中で生産される成果物の方がもっと問題だ、という問題提起でした。
長くなりましたが、かようなみずほシステム統合デスマーチの生き残りですのでネジが飛んでる筆者からは以上です。
（平成29年3月9日 木曜日）
▷▷次の記事は
（2018/12/06）山手線30番目の新駅「高輪ゲートウェイ駅」に対する庶民の違和感を表したツイートに日本人の侘び寂びを見た話です
おはようございます。 2018年12月の東京をぐるりと1時間で1周する山手線について述べ、日本人の感性まで論じようと試みる雑ですが意欲的な配信記事です。 筆者が山手線に…
≡ 
