「情シスの仕事はできて当たり前、ミスれば戦犯」
まずは、プレッシャーの中で戦ってる情シスの皆さん、お疲れ様やで。
100回設定を成功させても、たった1回の「事故」で組織の信用はガタ落ち。最悪、情報漏洩や機会損失に繋がってまう。
今回は、そんな「事故」を未然に防いで、個人の頑張りやなくて「仕組み」で成果を出すための思考パターンについて、僕の実体験を交えて話していくわ。
対象読者
- 「一生懸命やってるのに、なぜかトラブルが絶えない」と悩む情シス担当者
- 手順書はあるのに、作業のたびに心臓がバクバクする人
- 属人化した運用から脱却して、チームとして安定した成果を出したい人
1. 事故を招きやすい「危ない思考パターン」
まず、事故を呼び寄せてまう「危ない考え方」を整理してみるで。これ、無意識にやってへんか？
- 「直感」と「慣れ」への過信
- 「いつもこうしてるから」「たぶん大丈夫やろ」という正常性バイアスやな。
- 「作業完了」そのものが目的化している
- 変更後の「影響範囲」を考えるよりも、目の前の「設定ボタンを押すこと」を優先してまう状態。
- 「戻せない」手順を平気で踏む
- 万が一の時に「切り戻し（ロールバック）」ができるルートを確保してへん「片道切符」の作業。
これらが積み重なると、いつか必ずデカい事故が起きるんや。
2. 【実録】あわや「メール不達」の大惨事
ここで、僕が最近「それはまずい」と感じた話しを1つ！
サーバー移管時のDNS設定ミス
ある時、メールサーバーの移管対応をしてたんや。
具体的には、DNSの MXレコード と TXT（SPF）レコード の書き換え作業やね。
その時、僕の頭に一瞬浮かんだ手順がこれ。
- 今の（古い）レコードを削除する
- 新しいサーバーのレコードを追加する
これ、めちゃくちゃ危ない思考やねん。
もし、先に古いレコードを消してしもうたら、新しい設定が世界中のDNSサーバーに浸透（プロパゲーション）するまでの間、そのドメイン宛のメールは「宛先不明」でバウンス（不達）になってまう。
もしそれが、会社の「大型問い合わせアドレス」やったら？
- 大切な商談メールが届かない（機会損失）
- 顧客からの信頼失墜
- 「あの会社のシステム、大丈夫か？」という組織的な信用失墜
一瞬の「消してから入れる」という安易な思考が、取り返しのつかない事故を招くって教えてくれてなかったら実行してた、アホです。。。
3. 「事故らない人」の思考アルゴリズム
じゃあ、仕事ができる情シスはどう考えるんか。答えはシンプル。
「自分（の集中力や判断）を一切信じない」ことや。
① 「壊れる前提」で多重の防波堤を築く
先ほどのDNSの例なら、こう動くのが正解やな。
- TTLを事前に短くしておく: 変更の影響がすぐ反映されるように準備する。
- 「追記」から始める: 古いレコードを残したまま新しいのを追加し、並行運用期間を作る。
- 監視: ログを確認して、新しい方にトラフィック(送受信されるデータの量や流れ)を見てから、慎重に古い方を消す。
② 作業の「透明化」を仕組みにする
「一人でこっそり作業しない」のも大事な仕組みや。
- ダブルチェックの徹底: どんなに簡単な作業でも、第三者の目を入れる。
- 作業実況: Slackなどで「今からこれ消します」「反映されました」と実況し、周囲が「おや？」と思える隙を作る。
仕組み化とは「誰がやっても同じ結果が出る状態」を作ること。
個人の気合に頼るのをやめたとき、初めて組織としての成果が出るんや。
4. 明日からできる「事故ゼロ」アクション
- 「手順の逆」を常に考える
- 「これ、元に戻すにはどうすればいい？」を手順書に必ず書く。
- 違和感をスルーしない
- 「なんか気持ち悪いな」と思った時は、手が止まってる証拠。そこが事故の分岐点や。
- ドキュメントを「未来の自分」への手紙にする
- 3ヶ月後の自分が読んでも理解できる手順を残すことが、最大の守りになる。
まとめ：情シスの成果は「平和な日常」にある
情シスの仕事は、派手な成果が見えにくいかもしれん。
でも、「事故が起きない仕組み」を作り、組織の信用を裏側から支えることは、何物にも代えがたい「攻め」の貢献やと思うねん。
「自分は大丈夫」と思わず、常に仕組みを疑い、アップデートし続けていこうや！
参考資料：