デスマーチについて考える前にデスマーチの経験を書く

これは某サイトで書いた日記()の転載です。

その昔、とあるプロジェクトがものすごいことになっていて、猛烈な勢いでスケジュールが遅れているのに、仕様がまったく決まっておらず「とりあえず」作ったモノを現地にブチこんで、そのあと燃え上がるであろう事態を収めよという命のもと、テスタとして放り込まれたことがある。

まずお客さんがいいかげんだった。もともと現行システムがあるので「仕様は現行と同じでいい」と言いながら、思いつきで「新しいシステムだからこんな機能も欲しい」という、失敗するならそれ! ということを頻繁に行った。
受けたSEもいいかげんだった。お客さんが「このボタンを押すと計算結果が出る」というと、仕様書には「ボタン押下により計算結果が出力される」としか書かなかった。その計算はどのデータに基づいてどのような式で行われるのかは書かれなかった。もしそれをお客さんが(幸運にも!)教えてくれても、それが議事録に書かれることはなかった。
受けたプログラマもいいかげんだった。「この計算はどこのデータを見るんですか?」と質問したところ、SEは「うーん、とりあえずここだと思う」と言うので、それに対するエビデンスを残すことなく実装した。
そして、それらはだれかに検証されることなく現地に持ち込まれた。

そこに仕様のわからない私がやってきた。

お客さんとは話ができない。
SEに聞くと「詳細はプログラマに聞いて」と言われる。
プログラマに聞くと「言われたとおりやったんです」と言われる。
とりあえずわからないので画面をピコピコを触るとダイアログが出て落ちる。それをプログラマに伝える。「直しました」といわれる。「何が原因だったんですか?」「変なデータが入ってたので消しました」データベース仕様書を見る。「そういうデータはありだと思うんですが」「でも、そういうデータはないと言われましたよ」分散している資料の中から必死で業務フローを探し出す。「○○業務から△△データが入力されたときは、そういうデータがきますよ」「でも、そんなの想定した作りになっていません」
SEに聞くと「詳細はプログラマにまかせたから」と言われる。
こうして、なぜか他業務とI/F調整をするテスタになる。

とりあえず情報収集につとめ、あるべき仕様のイメージを作り、さんざんプログラマとやりとりをし、ロジック修正しまくった結果、ボタンを押すと計算結果が出るところまで持っていった。その画面を見て、SEが「ふーん、こんな表示になるんだ」といった笑顔が忘れられない。なぜあんたが知らないんだ?

ある日マネージャが、X月X日にリリースになったので、それまでにリリースしてね。といった。
無理だ。正常ケースはままうまくいくのだが、ちょっとでも変なことをしようものならいきなり死ぬプログラムである。そもそも正常ケースも全部通ってない、というか全部で何ケースあるのか、いまだに聞いても回答がない。
「こんな状態なので、そのスケジュールでリリースは無理です」「そんなの困る。この前の会議でリリースすると報告してしまったから」血管が50本ぐらい切れそうになる。

そこで偉い人たちの会議が始まった。明らかにまずいモジュールをリリースしたら、お客さんからどんなクレームがくるのか(自分達の責任になるのか)、どこなら許してもらえそうか。
「この機能はなんとか動かしてくれ。この機能は次回リリースにまわす」お、結構まともな答え。「この機能もやばいんですが、次回リリースじゃないんですか?」「たぶんお客さんはそれ使わない」じゃ、なんでリリースするんだよ。

というわけでお客さんにリリース。リリースはお客さんの業務に支障の無いように土曜日の深夜から開始し、日曜日の朝に終わる。
他社さんたちは、モジュールを入れて基本画面を表示させて軽く操作してOKといって帰っていった。
我々テストチームは、お客さん環境で自社のモジュールの業務フローが全て通るまで、プログラマを待機させた。朝までかかって、いくつかの問題をその場で修正し、全てのフローが通ることを確認した。

週が明けて月曜日。仕事場に来た私の机(ちなみにこのシステムは人海戦術をとっていたので、机がない人間が少なくなかったことを考えると、私はそれなりに大事にされていたらしい)には、お客さんからの「バグ票」がてんこもりになっていた。
内容的には

  • 「決定ボタンを押すと落ちる」とか
  • 「この色は趣味じゃない」とか
  • 「この画面とこの画面で動きが違う」とか

「色」は、お客さんに「具体的にどのようなものがお好みでしょうか?」
「仕様」についてはSEにこの挙動が書いた仕様とか議事録とかないよね? と悲しい確認をしたり。
その他は、とりあえずプログラマなみなさんに配りました。

「直しました」というのでテストしてみました。が、動きません。「すいません、別のへんな動きになったんですが」ごそごそごそ「どうやってテストしました?」
「いや、当然新規の件名作ってそこから業務フロー動かしてその画面まで遷移させて決定ボタン押したら落ちなくなったけどデータ消えた」「そこまでやるんですか?」やるだろ普通。DBに都合のいい値を書き込んで、動いたからOKにしたらしい。一方、他社さんはプログラマがOKと言ったモジュールは、テストすることなく、リリース環境にほうりこまれていった。結果、うちの会社は他社さんに比べてバグ率が1桁少ないという評判をいただいたきました。うちのプログラマさんはリリースする前に私が徹底的にチェックするので、すぐ指摘されるけど、お客さんからのクレームはなかったので、その面では平穏だったようです。

こういう日々が続き、なんとかメインフローが通るようになってきたので、これからは異常ケースを試験すればいい感じになりそうだなー。と思いながら出勤してみると。
「来週から仕様追加やります」
ってマジですか? だれが? バグでたらだれが直すの? 変な操作したときの防御は?
「だって先週の会議でそうきまっちゃったんだもん」

Y月Y日。運用開始予定日です。システムに関わるいろんな人が完成を待っています。
でも、できてないものは、できてません。

この期におよんで、お客さんからのバグ票の出力ペースが上がってきました。会社からも「未処置バグ数をへらすように!!」と厳命が下りました。

このへん、うわさでは、お客さんとしては「某社が全然できてないんだから、まともに金払いません」とか言ってて、その口実に使われないように、こっちサイドはなんとしても残バグ数を減らせ、ということだったようです。結局このお金がどうなったかは知りません。

と、ここまで書いて力尽きましたが、実は私が書きたいのは「デスマーチの中で演じるべきは火消しではなく…である」ということで、この「…」にあう言葉が見つからなかったので、とりあえず今回は私のデスマーチ記録のみとし、次回「…」の招待正体を突き止めたいと思っています。

つづく

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください