はじめに
みなさんこんにちは。祈織（いのり）と申します。
本記事は「本番環境などでやらかしちゃった人 Advent Calendar 2025」の23日目の記事となります。
前職で常駐していた現場での話となる為、具体的なシステムや会社名や詳細な構成などについては伏せた形で記載いたします。
当時の立場
- 某SES企業から某サービス事業会社の社内情シスへ常駐
- 常駐メンバー内では2年超と歴は最長
- 同じ作業を担当するのは私、プロパー社員がメインで、当時はもう1人の常駐メンバーへ作業落とし込みのタイミング
本題となるシステムについて
私が常駐していた先では提供サービスのスケジュールがきっちり決まっており、それを作成する専用のシステムが存在しています。
スケジュールは各店舗月に1回公開されるものです。
スケジュールを公開するために、月の半分ほどはこのシステムに対する保守作業を行っていました。
この作業は別チームから情シスへ移管されたもので、移管後は試行錯誤しながら対応している状況でした。
バッチやJSONファイルといった資材を扱う作業で、資材作成・検証・レビューを行います。
検証とレビューは別の担当者が対応する体制でした。
私はこの「レビュー」作業中にやらかしてしまいました。
当時の状況・業務影響
当時はもう1人の常駐メンバーへ作業の落とし込みをしており、その方が資材作成・検証をして私がレビュー担当という担当割をしていました。
私は手順書を見ながら（この手順書も自分で作成し、他者のレビューを挟みつつも不完全なものであった）、資材のレビューを実施していました。
レビューは資材の前月分との差分を比較するもので、前月分の資材作成・検証担当は私が対応していた為、前月分の資材は自分のローカルに存在しているものを使用して確認をしていました。
先月分のバッチの中身を「右クリック → 編集」で確認しようとした際、
一瞬黒い画面が表示されたような気がしましたが、当時は見落としてしまっていました。
数時間後、とある店舗から「スケジュールが作成できない」という問い合わせが入りました。
システムの状態を確認すると、店舗スタッフが操作できない状態になっていたため、
DB を操作して編集可能なフラグに戻す対応を行いました。
その後、別の店舗からも同様の問い合わせがあり、同じ対応を実施しました。
後から移管元チームより、私のUser_IDで時間割が操作された形跡があるとの連絡がありました。
DBを確認すると、資材レビューを行っていた時間帯と一致していました。
前月分の資材を確認していたため、結果的に自分のUser_IDが記録されていたようです。
また、ローカルに配置していた資材でしたが、バッチの向き先が本番環境を指していた可能性がありました。
当時はその点まで意識が及んでいなかったことが、今回の要因の一つだったと考えています。
結果的にほぼ全ての店舗で一時的にスケジュールが作成できなくなるという業務影響を出しました。
リカバリ対応
その日の夕方からリカバリのための検証とエビデンス取得、本番適用を実施しました。
自分1人で対応可能な作業ではなかった為、移管前のチームの方よりフォローをいただき、当日の21時半頃に復旧作業が完了しました。
復旧作業の内容は簡単に言ってしまうと、ほぼ全店舗のスケジュールのステータスを作成できる状態にフラグ変更をすると言う内容でした。
自分のやらかしにより、遅い時間まで多くの人にご迷惑をおかけしてしまいましたが、対応のフォローをいただいたことは本当に感謝しています。
自分の反省点・学び
例え本番環境に直接配置されているものでなくても、
バッチの向き先が不明な場合は、より慎重な確認が必要だと痛感しました。
また、違和感を覚えた時点で即座に報告しなかったことは、大きな反省点です。
今後は「やらかしたかもしれない」と感じた時点で、速やかに共有することを心がけたいと思います。
この経験を通して、
「インシデントは起こらないものと考えるのではなく、起こり得る前提で考え、未然に防ぐための対策を取る」
という意識を持つようになりました。
再発防止策として、恒久的に対応ができそうなものとして自分が検討したものは
- バッチに対話式のスクリプトを入れる
- 資材出力時にバッチとjsonだけでなく、バッチと中身が同様のテキストファイルを出力する
という内容でした。
資材はマクロで出力をしていた為、そこでバッチとjsonが出力される仕組みだった為、同じ内容のテキストファイルがあればバッチに触れなくても良いのでは、という点と、万が一バッチを触ってしまった際に即時実行されないようにしたい、という点で、とにかくできる限り危険因子（バッチ）には触れたくないという思いで検討しました。
当時の自分は、作業内容を客観的に残すためのエビデンス取得を十分に意識できておらず、この出来事をきっかけに「自分を守るためにも必要なもの」だと考えるようになりました。
現在は、可能な限りエビデンスを残すことを意識しています。
当時の運用面で感じたこと
レビュー時は、資材の中身を「右クリック → 編集」で確認し、内容をコピーして差分確認するという手順でした。
この方法では、操作次第でバッチを実行してしまう可能性があり、慎重さが求められる運用だったと感じています。
今回の件は、個人のミスだけでなく、運用上のリスクが顕在化した事例だったとも捉えています。
先述した再発防止策については検討しましたが、実際にどこまで恒久対応として反映されたかは把握できていません。
今回の経験を通して、「誰かがやらかしてから考える」のではなく、事前にリスクを洗い出しておくことの重要性を強く感じました。
おわりに
長々と当時のやらかしについて書いてきましたが、この出来事は、自分の未熟さと向き合う大きなきっかけになりました。
やらかした時は「怒られるのが怖い」と感じてしまいがちですが、報告を遅らせることで、結果的に影響が大きくなることもあります。今回の経験を通して、速やかに共有することの大切さを身をもって学びました。
同じような立場の方が「自分だけじゃない」と感じたり、本番環境を扱う際の意識づけの一助になれば幸いです。