危ないプロジェクトがたどるデスマーチへの道
危険な兆候
- 用語が一定しない、用語の使い方に誤りがある
- 担当者が思い入れすぎて機能を削れない
- いっぺんに作ろうとする
- 時間順があるものを同時進行させようとする
- テスト計画がなされていない
だいたいのプロジェクトは見積もりが甘くて、テストに関してみつもりがあまい。そして、時間がないからという理由で順序を飛ばしていろんなことを同時進行させようとする。デスマーチのスタートだ。
作業は一進一退になる。ちょっとプログラムを変えると複数の箇所に影響をしすぐ不具合が出る。優秀な人の数は限られているので、どんどん、特定の個人の仕事量が増える。金曜日報告だったものが月曜日報告になる。金曜日に作業が終わらないが、もともと、土日に作業することが前提になり始めるので、土日に作業をしても、月曜日の報告に後れを報告することになる。いや、だいたい報告されないか？正確に報告されればデスマーチにはなりにくい。
だいたいデスマーチの引き金は報告できない環境にある。
報告が遅れ/隠ぺいされ、不具合がいたるところで出始めると、上司は危機感を覚えるので、会議をすることになる。そして、会議のための資料つくりと、長い会議のために、さらに作業は遅れる。人の投入がなされるが、入ってきてもすぐに作業にかかれる人などいない。チームとしての連携が必要になり、さらに作業は遅れる傾向になる。
ここで運よく奇跡が起こることもある。致命的なバグの原因が見つかる。ある特定の人ががんばってモジュールの一部を書き上げる。こういうことがきっかけで、作業量が減ることがある。運が良ければ予算内でなんとかいけるかもという見通しがついてくる。
ここで運悪くアクシデントが起こる可能性もある。誰かがソースをクラッシュさせる。非論理的なバグを埋め込んでしまう。優秀な誰かが辞めてしまう、あるいは入院してしまう。予算が続かなければここでゲームオーバ。
場合によってはゲームオーバの方が幸福なことがある。奇跡もアクシデントも起こらず、淡々とプロジェクトが進み、致命的なバグには誰かが隠ぺいするようなソースコードを書いて暫定対処。見た目はうまく動いているように見える。ときどき、おかしい気もするが、みんな、ここまで「よくやったよね」と思っているからちゃんと調べようとしない。デスマーチの再スタートやゲームオーバが怖いのだ。
そして、90% くらいの出来で商品出荷。90% 位の出来で出荷するなんてことはよくある話だと思うので（というか優秀！！）、とりたてて騒ぐこともなかろうが、、、
問題は出荷した後に起こる。
突然、致命的なバグがお客さんの下で火を噴く。コンシュマー製品ならまぁ我慢する客もいるだろう。そいういえば、私の携帯電話のアラーム、時々ならない。そして、朝起きると電源がoffになっていることもある。だからといって、クレームは上げない（私は）。
特定の重要顧客に納品した後に、時限爆弾よろしく、致命的なバグが顕在化。突如として、工場のラインを止め、コンベアーの上にある製品をすべて破壊！！（20年以上前にありました。ガラス製品がすべて壊れました）ごくたまにしか起こらないのだけど、かなり致命的なバグ。
この手の「ごくたまに」の「バグ」。発生すると大きな発注元だと、まず、関係各社全員集合。それは名古屋かもしれないし、三鷹や仙台かもしれない。各社が状況に応じて問題報告。そして、夜を徹しての再現テスト。
運が良ければ、たまたま、優秀な人がいて自分の会社とか関係なくバグを見つけたり、重要な証拠を見つけたりする。こうして、１か月以上にわたる重大バグは解決していく。運用年数によってはずーと続くので頻繁にこんなことが繰り返される。
運が悪ければ、まったく手がかりがないまま１か月が過ぎる。そして、対処療法的な対策が考えらえる。できてた値が２倍になっているから２で割るみたいな感じで。そして、そのための検証資料、想定されるトラブルなどの資料をたくさん作ることになる。応急手当ながらも、バグ発生時の対策がなされる。
そして、あるとき、トラブル続きなので、バージョンアップを使用という話になり、デスマーチが繰り返される。
途中でプロジェクトがとん挫する方がましか？それとも出荷までいくほうがましか？どっちがよいかは比較できないが、、、
誰がこんなことを招くかって？代替はプロジェクト運営を知らない人がアイデアを出したり先頭を引っ張るとこうなるね。
