入社してもうすぐ一年立つ。

大きな案件にも参加させてもらったが、社内テスト環境でのサーバーエラー
を起こしてしまうという大きなミスをして。修正対応はできたが、原因の特定に時間がかかってた。

この出来事から２点振り返りたいことがあった

• 「なぜミスは起こったのか」
• 「なぜすぐに原因を特定できなかったのか」

備忘録も兼ねてここに残したいと思う

事の発端は…

細かな修正が多く残っていて対応に追われ、目の前の作業に夢中になりすぎることが多々あった。

ある日、テスト環境への反映作業を行うことになった。

本来であれば本番と同様に、行った手順を後から振り返るために「手順書」を作成した方が良い。
過去の案件でも、作成した経験はあるのでその大切さは認識していた。

しかし、当時はタスクに追われ、「手順書を作成する」という考えが頭には無く
結局作成せずまた、チームのメンバーに手順を確認しないまま作業を行ってしまった。

その結果

やらかした。

間違った作業手順を行ってしまい、あとから気づいた私は急いで設定を修正した。

その後、エラー通知に気づいたメンバーからサーバーが止まっていたことを聞かされた。

「15分」サーバーエラーでテストサイトが止まっていた

エラー箇所の原因調査を依頼され、作業に取り掛かったが、

焦って行った当時の作業の内容を振り返るものを残していなかったので、調査に時間がかかった。

その後、原因をなんとかチームで特定。

開発真っ最中のプロジェクトメンバーに大きな迷惑をかけてしまった。
本番環境であればさらに大きな問題になっていたと思う。

そもそもの原因

なぜこんなことになったのかを振り返るために「なぜ起こったのか」「なぜすぐに原因を特定できなかったのか」のこの２軸で考えていこうと思う

1.「なぜ起こったのか」
　・自分で手順を振り返らなかった
　・手順を誰かに確認しなかった
2.「なぜすぐに原因を特定できなかったのか」
　・行った作業を振り返るものが何もなかった
　・行動の詳細をメンバーに共有していなかった

作業前に手順を振り返っていれば
　→　問題点に気づくことができたかも知れないし、メンバーに確認することで自分では気づけないミスにも対応できたかも知れない。
有事の際に作業を振り返られるものがあれば
　→　原因箇所の特定を素早く行えたかもしれないし、チーム全体での対応もさらに素早くおこなうことができたかもしれない。
　
つまりは、自分を含めたメンバー全員が、
作業内容を「事前に把握できる」「振り返ることができる」ものが必要だったのではないか。
と考えた。

これらを解決するもの　
それは「手順書」だった

これまでは漠然と作らなくてはいけないものとして作業的に作っていた。
しかし今回で、手順書の大切さを改めて実感し、また手順書を準備すればミスが起こる可能性を減らせると再認識できた。

当たり前のことだが手順書がなぜ必要なのか振り返ることができたので、この経験を成長の糧として日々邁進していこうと思う。