締め日の赤いログ

給与計算サービスのサポート窓口で、瑞慶覧羽純は月末最後のチケットを開いた。

顧客は全国に店舗を持つ会社で、残業データの取り込みだけが失敗している。締め処理まで一時間。担当者は「サーバーが重い」と言い、再実行を七回繰り返していた。

契約上のSLAでは、重大障害なら十五分以内に技術班を招集する。だが同じ時間帯に他社の失敗はない。羽純は障害宣言を上げる前に、ログを一行ずつ追った。

赤くなっているのは、ある店舗の従業員番号だけだった。本来は「00127」だが、取り込み時には「127」になっている。担当者が表計算ソフトでファイルを開き、保存したとき、先頭のゼロが消えていた。

「元のファイルは残っていますか」

幸い、店舗から届いた添付ファイルがメールに残っていた。羽純はそれを開かずに保存してもらい、取り込み順を変更した。失敗したファイルを何度も再実行するのではなく、正常な店舗を先に確定し、該当店舗だけ原本から入れ直す。全社分を最初からやり直せば、締め時刻を越えるうえ、すでに確認済みの数字まで動く危険がある。

羽純は、番号を手入力で「00127」に直すだけの案内をしなかった。今月は直っても、翌月また別の店舗で同じことが起きる。原本を開かずに取り込む手順と、番号列を文字として扱う設定を顧客側のメモに残した。急場をしのぐ修正と、再発を止める変更を分けて伝えた。

処理は十二分で終わった。担当者の画面に、残業時間の合計が表示される。

「サーバーじゃなかったんですね」

「重かったのは、ゼロ一つの扱いです」

羽純は笑わせるつもりではなかったが、電話の向こうで小さく笑いが起きた。

チケットを閉じる前に、羽純は原因欄へ「表計算ソフト」とだけ書かなかった。どの操作で番号が変わったか、原本をどう残すかまで記した。翌月、別の担当者が同じ罠に入らないためだ。

締め時刻の三分前、完了通知が届いた。

羽純が夜食の包装を開けると、待ち件数がゼロから一に変わった。

件名は「賞与データが二倍になる」。

彼女は箸を置き、次のログを開いた。