プログラマー回顧録(10)

~ エンデベッドシステム開発経験を回顧する ~

後処理は果てしなく続くのである

旧モジュールでの安定稼働を見守る。

時刻は14時を過ぎていた。

「食事に行こう。」

2次請負企業のプロジェクト責任補佐に声を掛けられた。

システムは復旧した。

だが1年前の状態に戻しただけである。

これからもう1度、最新の状態にしなければ終わらない。

最新モジュールを再度リリースする。

この過程がどれほど大変か。。。

ビルを出て近くの牛丼屋に入る。

「すみませんでした。」

謝る俺に補佐はこう言った。

「起きてしまったものは仕方ないさ。今できることをやろう。」

急いで牛丼を掻き込み、足早にビルに戻る。

ビルに戻ると事象の原因について議論されていた。

今回の事象の発生原因が判明したのだ。

原因を要約すると以下となる。

システムは起動時にサーバーから制御情報を受け取っている。

切り替え当日以降、制御情報に新機能のサービスのON/OFFの指示が追加で設定されることになっていた。

そして、システムのメイン機能はその情報を使用しない。

使用しないのだがメモリへの格納を許容することにしたのだ。

これが問題だった。

実はその格納していた値を見ている機能がいたのだ。

それがメイン機能の一機能である媒体管理機能だった。

媒体管理機能は制御値ゼロを期待していたが、サービスONが設定された結果、期待値ではなくなり、制御不能となったのだ。

そもそもメモリの参照など機能改修時の最も考慮すべき点。

なぜ見落としていたのか?

それは問題となった媒体管理機能が変数参照ではなく、キャストによるメモリ参照をしており、設計担当者は参照されないことに気付かなかったのである。

(これはこの後もう少し掘り下げて書いていこうと思う。)

これで原因は特定された。

この後何をするのか。

目に見える影響はあった。それ以外に影響はないのか?

同じような間違いをしている箇所はないのか?

被害を受けたユーザーはどれほどいたのか?

どう改修するのか?

幾つも挙げられる課題に対し、チーム編成され、課題に取り掛かる。

時間が過ぎていった。

旧モジュールに切り替えて以降、問題は発生しなかった。

終電が近づく。

「君はもう帰りなさい。」

2次請負企業のプロジェクト責任補佐に声をかけられ、帰宅することとなった。

夜勤として出社してからの稼働時間は26時間になろうとしていた。

これは個人的体験談を元にした回顧録です。企業名、人名などは架空の名称です。
毎週日曜日更新。
随時、加筆、修正を行います。

投稿日2022.03.27更新日0000.00.00