【失敗事例】本当にあったSEの失敗談 システムの不具合でデータがシャッフルの巻

スポンサーリンク
IT関連雑談

今回は、これまでSEとしてITに関する仕事に携わってきて、私自身や身の回りで発生した仕事における失敗やトラブルを赤裸々に紹介していきます。

スポンサーリンク

ケース1 更新対象とは無関係なデータ全行が更新されてしまった話

私がSIer時代に経験した目も当てられない業務システムの不具合を発生させてしまった事例です。
不具合を出した結果、悲惨な状況になりましたが、原因は割りと誰でも起こし得る内容でした。
また、発生した被害とは裏腹に、顧客対応に関しては大事にならず事なきを得たというケースです。

トラブル発生状況

当時の私はとあるSIerのまだ駆け出しのSEとして、比較的小規模の業務システムの開発案件でプロジェクトリーダーとして立ち回っておりました。

問題のシステムは、顧客の企業内で使用します。
画像データ化された書類をシステムが読み込んで表示し、書類の記載内容に漏れや誤りが無いかを顧客内の専業部署で人がチェックする業務をするための業務システムです。
書類の画像データはステータス管理され、チェック作業が済むと、自動または手動でステータスが更新されます。
書類の記載内容に不備などがあれば、不備内容を登録します。

極端な短納期、且つ度重なる仕様変更でさんざん炎上したプロジェクトを何とか終息させ、納品後の本番稼働が始まったシステムに対して、本番稼働後に顧客から報告があった不具合を修正したり、運用を開始してから判明した細かい内部仕様の修正依頼を顧客から受けて、対応をチマチマとやりながら、システムの稼働開始から1ヶ月程度経ったある日、顧客から何気無い報告が私の有りました。

顧客:「今日はシステムがやたら遅いので調べてもらえますか?」

顧客からのシステムの修正要望を受けて、前日の夜間にその実装を本番環境に適用したところでした。

当時のメンバーは主に三人居て、設計メインの優秀なSE兼PG、若手で経験は浅いメインPG、設計と顧客対応がメインの私。

このところ、プログラムの修正作業は若手のPGにほぼ任せており、前日に適用したプログラムもその若手が対応したものでした。

システムが遅いと報告を受けた際に、近くに居たメンバーのSEにその事を報告し、今回適用したプログラムの修正内容をプログラムコードをもとに確認してもらうように依頼をしました。

調査を依頼して20~30分後、メンバーのSEが言いました。
メンバーSE:「これ、ステータスを更新する対象データだけじゃなく、全データに同じ更新が掛かっちゃってますよ…

トラブルの原因が判明

私:「えっ…」

詳しく内容を確認すると、前回のプログラムを改修した処理に不具合があり、本来一意の特定のデータと、それにまつわる関連したデータだけが更新されるべき処理に対して、関連するデータだけでなく更新条件に合うステータスの全データに同じ更新処理が実行されてしまう状態になっているとのことでした。

開発時には当然テストも実施していましたが、テストデータに対して今回実装した更新処理が行われることは確認しましたが、まさかそれ以外の無関係なデータまで同じ更新内容で更新されているということに誰も気づかず、そのままリリースされてしまいました。

処理が遅いという報告も、更新処理の度に本来更新対象ではない大量のデータに対して毎回更新を行っていたからというのが理由でした。
そりゃあ遅くもなりますね…。

その状態で数時間、数十人がシステムを利用していたことで、データは見事にシャッフルされていることが予想されます。

取り敢えず顧客には詳しい原因はいったん伏せて、何らかの不具合があり現在調査中なので、復旧するまでシステムの使用を停止してほしいと連絡し、まず当面の対応策を検討する時間を確保します。

被害状況の調査

今回のトラブルでは、顧客が不具合を抱えたシステムを使いだして1~2時間程度経過してから判明し、その後システムの利用を停止させています。
ただ、顧客側では少なくても10~20人程度の人数で当システムを使用しており、更新されたデータは大量であり、被害は甚大です。

ただ、当システムではデータを更新する際に、対象データのステータスの区分も条件に含めており、今回の不具合で更新されてしまったデータ群においても、このステータスは適切な条件で参照、判定されていた様です。
例えば、更新対象データのステータスの区分が1の場合、必ず2への更新しかされず、0や3への更新は発生しないといった仕様です。

これであれば、データが持っている更新日時の値を元に、当日に更新が発生したデータを絞りこみ、現在セットされているステータスの区分の値から逆算し、更新前の区分の値を推測して、あるべき状態に戻すことは可能そうでした。

私:「よしっ、今回は全力で誤魔化そう

徹夜のデータの復旧作業

不具合で更新されてしまったデータのうち、7~8割のデータは論理的に逆算し、あるべき状態へ一括して更新を掛けて、復旧させることができました。

ただ、残りの1000~2000件ほどのデータについては、データの値から逆算して一括更新はできず、人が目視で画像データを確認してあるべきデータに直していく必要がありました。

メンバーPG:「残りのデータはどうしますか?」
私:「今回の不具合はさすがに顧客には言えないし、しれっと収束させるには手作業で一つの一つデータを直していくしかないよね…」

タイムリミットは顧客が明日の業務を開始する時間まで。

まずはメンバーPGと共同作業をするにあたって、チェック対象のデータがバッティングしないように、またチェック対象のデータの取得や更新作業に誤りが発生しないように、簡易的な Accessアプリケーションをサクッと作成します。
データの参照と更新をするためのフォームを一つ作れば良いだけなので、凝った実装をしなければ30分もあれば作れます。
今回のようにインスタントアプリケーションを作る場合にAccessは大変便利です。

あとはこのアプリを介してひたすらデータをチェックして一つ一つ修正していくだけです。

その後、徹夜でこの作業を終わらせて、顧客にはプログラムの不具合を修正したと報告し、何事もなかったのように顧客は業務を再開しました。

その後チラホラと「データがおかしい」と顧客から報告が有りましたが、そこは真実の隠蔽と時間が解決してくれましたとさ。

おしまい。

最後に

今回の事例で大事な教訓は以下です。

システムテストの際には、対象のデータが仕様通り更新されていることを確認するとともに、対象外のデータに影響を与えていないかも注意する。

所謂「リグレッションテスト」の一部とも呼べるかと思います。

当然ながら、この件があってそれ以降は、システムテストにおいて上記の教訓は常に注意するようになりました。

物事は何でもそうですが、失敗やトラブルを多く繰り返し、それを乗り越えていくことで、その経験が糧となり、座学だけでは身に付かない実務的な技術や仕事のすすめ方を習得してベテランになっていきます。

ただ、実務経験が浅い人は、大きなトラブルに遭遇する機会も少なく、身をもってリスクを学ぶことが難しいです。
今回の記事がそういった人たちの参考になれば幸いです。