ベンダーSE時代に味わった最凶の炎上プロジェクト⑤

数々の苦労を経て、ようやく辿り着いた本番リリース。

我々が担当するサブシステムは卸売業の中でも販売管理部分ですから、特に即時性が求められます。
つまり、得意先から受注データを受信してから、倉庫に出荷指示をし、トラックに商品を積み込むまでの時間をどれだけ短縮するかが問われるというわけです。

そんな経緯もあって、生命線とも言える「受注締め処理」は、10分に1回スケジューラから起動され、基本的に放っといても在庫引当や不足品の発注処理などがズンズン進んでいくような仕組みで設計されていました。

さて、そんな超重要処理の緊張の第1回目実行結果は ―

見事な異常終了。(苦笑)

そりゃそうだ。
一度も本番データ使ってテストしてないんだもん。
受注データに想定外の値が入っていたりして、もうバッチが落ちる落ちる。(泣)

おまけに、10分に1回起動される処理ですから、リカバリが遅れると、10分後、20分後の処理たちが溜まっていくんですよねぇ。。。
まさに、1分1秒を争って復旧しなければならない状態でした。
まぁ、このおかげで異常原因の特定やリカバリに関するスキルが身に付き、その後のプロジェクトや現在に至るまで、迅速なリカバリに役立っているわけですが・・・

もちろん、他のバッチ処理も、様々なところで不具合が発生しました。
外部システムからデータを取り込むような処理は、とりあえず落ちとけとばかりに、ほぼ全滅で異常終了。
また、逆にこちらから外部システムや取引先にデータ送信するような処理は、相手先でおかしな数字になってたり、受信エラーになったりと、もう散々な状況。

総合テスト以降の勢いそのままに、明らかにユーザー側の責任と思われるような問題も全てバグとして片付けられ、無償かつ即対応でプログラム改修を行うハメに。

メンバーはプロジェクトルームから帰宅することもままならず、数日間泊まり込みで対応するような状況でした。
なんせ、夜間にどれだけプログラムを修正しても、次の日の日中には新たな不具合がどんどん発生するんだもん。(泣)
もちろん、日によっては夜間バッチや朝バッチで不具合が出ることも珍しくなく、うちのPMやPLはもう意識が朦朧とした状態で旗振りをしていました。
正直、この人達死ぬんじゃないかって思ったことも・・・

これ、しかも一番取引件数が少ない、本番切替1拠点目の話ですからね。
なのに、こんな状態が1ヶ月ずっと続き、ようやく多少は不具合の発生件数が減少傾向になってきました。
まぁ、それでも毎日何かしらのバッチが落ちてましたが。(苦笑)

スポンサーリンク


その後、改修が終わり切らないまま、2拠点目・3拠点目・・・、そして全面切替について、稼働判定で順調にゴーサインが出続けました。
ホントに、判断基準は一体何なんだろうか?

切り替わる拠点数が増えるに従い、使われる機能が多くなり、かつ1日あたりの取引件数も増加していきました。
そして、それに比例するかのように、不具合の件数もうなぎ登り・・・

※あるときは、過去半年間に売上計上した伝票明細データの消費税について、端数処理方法がバグっていたことが分かり、1億件近くのレコードを数日に分けてパッチした・・・なんてこともあったり。

もう助けて下さい、マジで。(死)

運用テストの頃から、プロジェクトルームはH社が用意したとある雑居ビルの一室になったのですが、ここが実は私の自宅から徒歩15分の距離でした。
電車もタクシーも不要で、チャリ通勤できていたのでラクかと思いきや、、、
近いため、夜間や休日にバッチが落ちると、真っ先に呼び出されるという、まさにSEとしては最悪の立地条件。

夜間バッチは深夜2時頃まで動きますし、朝バッチは朝6時頃から始まりますから、寝る時間は大幅に削られ、気も休まりません。
私だけでなく、嫁も当然ロクに寝られないため、夫婦喧嘩が絶えない日々。。。
(離婚の一歩手前までいきました・・・)

全面切替から数ヶ月経過した後も一向に夜間・早朝バッチの異常終了が収束せず、夜中や休日に電話やメールが鳴る度に胃がキリキリ痛み、嫁に怒鳴られながらチャリンコでリカバリに行くというブラック極まりない労働状況でした。

でも、周りもみんなそうだったせいか、これが当たり前だと思ってたんですよねぇ。。。

結局、全面稼働してから次のプロジェクトに異動になるまでの約2年半の間、他のメンバーが次々と抜けていく中、しんがり状態でこのシステムのお守りをさせられました。
そして、同時にこの間は、ボーナスの査定が非常に高かったのを覚えています。
何でも、過酷な状況にも関わらず、献身的にプロジェクトの維持に貢献し、H社からの評価も高いというのがその理由だとか。

その頃は、収入が多かったからすっかり騙されてましたが、冷静に考えるとホントおかしいですよね。
だって、外部設計をちゃんとやってなかったからこうなったわけで、言うなれば自作自演乙って感じです。
炎上するのを指くわえて見ていただけなので、むしろ評価が下がって然るべき。

ところが、評価基準が、
 ・残業を人よりしまくったから
 ・夜間も休日も呼び出しに応じ、リカバリ作業を行ったから

なんていう点が優先されるというのは、以前の記事でも書いた通り、普通に考えれば異常です。

これはSI業界全体に蔓延している悪習のようですが・・・

それにしても、プロジェクトスケジュールを優先するあまり、外部設計工程を杜撰な状態で完了させたことが、最後の最後まで尾を引く結果となりました。
多少遅延してでも外部設計書をちゃんと記載し、ユーザーと合意を取り付けておけば、内部設計工程以降の炎上はかなりな部分避けられたはずです。

この反省は、一応次のプロジェクトでは活かされましたが、そのまま社内SEに転職してしまったので、現在はあまり活かす場面が無かったりするのが切ないところです。(苦笑)
あんなに苦労して得た教訓なのに・・・

全5回にわたってご紹介してきた炎上プロジェクトですが、いかがでしたでしょうか。
ベンダーSEの方で、もし少しでも参考になるような内容があり、今後の炎上プロジェクトを1つでも減らせることができれば、幸いです。

もちろん、ユーザー側である我々としても、炎上を未然に防げるベンダーさんが増えてくれると助かりますしね。

還元率の高いポイントサイトで、ハイペースでポイントが貯まります ポイントサイトのポイントインカム

獲得ポイントの高いアンケートサイトで、効率的にポイントが貯められます infoQ新規会員登録

コメントの投稿

非公開コメント

管理人のみ閲覧できます

このコメントは管理人のみ閲覧できます

Re: タイトルなし

元メー子さん

ありがとうございます。
共感して頂ける方がいて、とても心強いです。(笑)
私もベンダーでの経験があったからこそ、社内SEに転職して良かったと感じられているのだと思います。
業務部門や経営者にイラっとくることもあるかと思いますが、社内SEとして一緒に頑張っていきましょう。
プロフィール

Author:たみおと
36歳にして社内SEに転職しました。
ベンダーSE・社内SEどちらの方が記事を読んでも、ご参考になる体験談をUPしていきたいと思っていますので、宜しくお願い致します。

検索フォーム
ブログランキング
よろしければ、ポチっと一押しお願いします。m(__)m

ブログランキング・にほんブログ村へ
カテゴリ
よく読まれている記事
最新記事
おすすめ書籍
[商品価格に関しましては、リンクが作成された時点と現時点で情報が変更されている場合がございます。]

なぜ、システム開発は必ずモメるのか? [ 細川義洋 ]
価格:2160円(税込、送料無料) (2016/11/7時点)



[商品価格に関しましては、リンクが作成された時点と現時点で情報が変更されている場合がございます。]

絵で見てわかる RPAの仕組み (絵で見てわかる) [ 西村 泰洋 ]
価格:2786円(税込、送料無料) (2018/7/30時点)



月別アーカイブ
リンク