SREという概念を知らずにキャリアを積んだ結果、振り返ったら 信頼性・インシデント・標準化・ガバナンス を一貫して扱っていたことに気づきました。
AWS セキュリティ / 改ざん検知（STAMP+KMS）/ リスク診断CI/CD / 組織ガバナンス を主領域に、現在は Security SRE / Governance SRE として稼働してます。
- 「構造の欠陥」を特定し、技術で仕組み化し、再発させない
- 個人ミスの切り捨てをせず、プロセスと組織に真因を求めるインシデント文化
という感じで、SRE を役割ではなく「考え方」としてやってきたという記録です
■ キャリアを棚卸ししたら、全部 SRE の原則だった
SRE という職種が一般化したのはここ数年ですが、キャリアを棚卸ししたら、全部 SRE の原則だったと気づきました。
最初は気づかなかったのですが、カジュアル面談でエンジニアのリーダー層の方々と話しているうちに「あれ？」という感じです。
- 信頼性の定義
- インシデント→RCA→恒久対策→水平展開
- 自動化とToil削減
- 組織構造の欠陥を修正する
- ガバナンスと文化の改善
このあたりが自然とずっと軸になっていた。
軸というか、仕事ってこういうものでは？と無意識に思っていたというか…
■ 現在やっていること（Security SRE / Governance SRE）はこんな感じ
- AWS（CloudTrail, KMS, Lambda, EventBridge, GuardDuty, IAM, S3, CDK）
- 改ざん検知（STAMP + KMS署名 / RSA-PSS / MANIFEST生成）
- リスク診断自動化（CodeBuild + CDK + GPT API）
- ISO27001準拠の証跡モデル設計
- インシデント対応（AWS / セキュリティ）
- 組織のガバナンス・プロセス整備
- 業務自動化（Slack連携 / LambdaベースのOps削減）
でもそれより前から、というより最初から 「名乗ってなかっただけでずっとSREの思考様式で働いていた」 というキャリアの振り返りを実例とともにまとめます。
■ ① 経理：ガバナンスと標準化
最初はエンジニアではなく経理でしたが、やっていたことはガバナンスSREです。
- 業務エラーの原因分析（RCA）
- テンプレ化・標準化
- 伝票・精算フローのゼロベース設計
- ソフト導入による自動化
手作業がソフトに置き換わったのを見ていたら 「人ではなくフローの設計不足」 が根本原因 という視点がわいてきました。
■ ② 基幹システム開発：信頼性思考
ここでSREの中核である「Incident → RCA → 対策 → 文書化」が固まります。
- バグ再現調査
- 影響範囲分析
- 恒久対策
- 水平展開
- ISO20000準拠の品質管理
今思うとSREの信頼性エンジニアリングの原型です。
バグが出たらバグフィードバック票を書いて根本原因なども書く必要があったのですが、これが楽しかったので、そのあともバグが出たらどの現場でも必ずやります。一人ででもやります。楽しいからです☺️
■ ③ プロジェクト事務：プロセス改善・品質標準化
派遣のITプロジェクト事務の仕事だったのですが、親会社のシステムだけを作っていた会社が初めて外部の仕事を請け負ったから「うちはバグ票もないし書き方もわからない」ということで…
- バグ票のテンプレート作成（もちろん大好きなフィードバック票も）
- 書き方を標準化
- テスター教育を主導
- 認識齟齬をなくすコミュニケーション設計
SREの 「運用の品質管理」と「手順の標準化」 ですね。
■ ④ Web系保守：Toil削減・構造化の徹底
WordPress保守・改善業務で強く身についたのがToil削減 と 非エンジニアでも扱える構造化。また小さな会社で社長直属だったこともあり、経営層との話し方（できますか、と聞かれて現状だと無理だなと思ったら「できない」ではなくて、できるための条件を提示する会話の方が意味があるな、とか）をここで学んだのもこのあとのキャリアのガバナンス提言につながったのかな、と思います。
- テーマ化
- 更新フローの整理
- データ分析自動化
- 運用の手作業排除
■ ⑤ 一人エンジニア：ガバナンスSRE / SecOps
AWSのインシデント対応を通して、すごい面白かったので「この仕事ってなんだろう？」と思い、やったことをChatGPTに聞いたら「それはSREだよ」と教えてもらった。あとSlackで閉じがちなタスクをAsanaに書いてナレッジをためましょうとかも言ってました。
■ SESキー漏洩インシデントでやったこと
- ログベースの公平な調査
- 真因を「AWS管理体制の長年の不在」と定義
- オフショアとの信頼再構築
- Secrets Manager移行の恒久対策
- ガバナンスの提言（CEOへ共有）
- S3監査→通知→保全→是正提案のプロセス構築
■ ⑥ フリーランス：Security SRE と Reliability Governance
前職の経験を通して「こういうのあると開発環境が整う」と思ったものをツール化していった。
- 改ざん検知（STAMP+KMS）
- 証跡生成の仕組み化
- リスク診断CI/CD化
- Lambda・CDKベースの自動化基盤
結果Security SRE / Governance SRE / Reliability Governance Engineerという職種に自然と収まった感じです。
■ SREは構造化・信頼性・再発防止の思考
Google SRE本にもあるように：
SREは本質的に「問題をエンジニアリングで解決する文化」である。
SREは職種でもあるけど文化とか考え方でもある。だから私の場合だと
-
個人責任 ではなく → 「構造問題」
人を責めると防衛的になる。防衛的になると現状がわからない。現状がわからないと、根本原因が解消されないから自然にそうしてました。 -
作業 ではなく → 「仕組み」
同じことを2回やる＝人力＝ミスが出る。それに効率的じゃないからツールにする、マニュアル化する。 -
火消し だけじゃなく→ 「恒久対策」
今だけなんとかしてもまた同じことが起きるならそれは二度手間。とにかく同じことを何回もやるのがいや（笑）
という考えが根底にあるから、たぶん最初からSREだったといっていいかな？！と思いました。
そして今はSecurity SRE / Governance SRE / Reliability Governance Engineerがしっくりきています。
というか、部屋が散らかると「なぜ散らかるんだろう？」と考えて片付け方を設計してしまうし（でも引き出しのなかはカオスでいいとか、どこかに”遊び”を担保する。あと家族が息苦しくなったら家としては本末転倒なので、そのバランスは重視）なんか胃がもたれるななと思うと「なぜもたれるんだ？」と原因を追求し「胃薬でごまかしたら再発する」と生活習慣を見直して恒久化対策を設計してしまうので、生まれつきSREかもしれないです😆
Natural Born SREってなんかかっこいい感じ…おおう…