これは私が決済系のシステム開発に携わっていた時の話
個人や企業が特定されるような情報は伏せますが、数年前炎上の末にできあがった1つのシステムがありました。
それはそれはものすごいコードだったのです。
どんなコードだったのか
このシステムは画面で値を入力し、次々と画面を遷移させていったのち、最終的な画面で処理を完結させるというものでした。
ある条件のインプットを外部から入れると以下のような処理が走りました。
・画面１で入力した値は不要なので、メモリ上の値を外部インプットの値で上書きする。
・画面２での処理時にサーバから取得した値は不要なので、メモリ上の値を外部インプットの値で上書きする
などなど、様々なクラスを移動しながら、上書きに上書きを重ねていて、どの処理でどのような値を保持しているのか非常にわかりづらい状態になっていました。
そしてその時は来た
とある本番障害の対応でこの上書きに上書きを重ねた値に関連した修正を行うことになりました。
しかも本番障害ということで当日中の修正・テストが要求されていました。
修正範囲としてはたった1つの画面に1つ条件分岐を組み込むだけ。工数としても当日中のテストまでの対応は無事に完了しました。
本番リリースも無事に終わり、2・3日経過した後に他の開発ベンダーから、以下の質問が来ました。
「特定の条件で処理が正常に進まない。」
その条件を聞いたときに血の気の引くのがわかりました。
俺の修正した条件に一致していないか？
まさにその通りでした。
そこからは上層に詰められ、参画していたベンダーのリーダーも分析に追われと散々な日々でした。
このやらかしから得た教訓
・影響調査はちゃんとやろう。
→時間がないからと影響調査が疎かになっていたのかもしれません。時間の調整をしながら、正確に行うべきでした。
・自分の立場をちゃんと理解しよう
→これは自分が下の立場だからへこへこしようという意味ではなく、契約関係・指揮系統をちゃんと理解し、相応の動きをしましょうという意味です。
私は準委任契約でベンダーのリーダーの下で業務にあたっていました。
当時のPLは元請けの社員ではなく、他のベンダーのベンダーリーダーでした。
つまりは私がそのPLから直接指揮命令や業務の依頼を受けるような関係性ではなかったのでした。
「ベンダーのリーダーが忙しいから」「私がベンダーの中で比較的業務を理解しているから」ということで障害対応の会議などに参画して前線に立っていたのが、そもそもの誤りだったと思っています。