概要：技術の問題はだいたい組織の問題と表裏一体。
「AWSキー漏洩」というインシデントを通じて、技術的な修正（What）だけでは永遠に問題が解決しない構造に気づき、組織のガバナンスと意思決定権限の変革（How） まで踏み込んだSRE的活動の記録です。
1. インシデントの裏で発覚した「組織の詰み」
-
情報の遮断と早期収束:
AWS認証情報漏洩インシデントが発生。ほとんど調査していない状況で、経営陣には「ベンダーのオペレーションミスが原因と思われる」という初期レポートが提出されました。そのため調査の前から外部ベンダーに焦点が当てられていて、その後の調査方向もそちらに傾いていました。
しかし実際フラットな視点で調査してみると、原因は単なるオペレーションや設定のミスではなく、認証情報のS3保管やログ体制の不備など 「クラウドガバナンス不在」 という根本的な欠陥だと判明しました。実際そういったレポートを作成したのですが、経営陣には届いていない様子がうかがえました。
↓これは調査したときの記事
そこで私は”組織として「早期に納得解を得たい」という意識が根底にある？問題は技術ではなく組織の設計にあるのでは？”と考えました。
-
根本の構造分析:
本当のボトルネックは、システム管理の責任が非技術部門の管理職に集中している組織体制による「役割の歪み」ではないか。インフラとマーケティングなど無関係な部門を兼任する上層部の「情報サイロ」が発生してリスク報告に影響（これは後で知りましたが、まさに「コンウェイの法則」の機能不全）しているのでは？「誰が悪いか」ではなく「組織図」のせいで問題が起きている、つまりこれを放置すれば、またインシデントが起きる…そういう結論にいたりました。
2. リスクの翻訳：「ヨガスタジオと基礎杭」でCEOを動かす
この構造的な問題を技術知識のないCEOに理解してもらうため、私はリスクを「事業継続」に直結するアナロジーで翻訳しました。
「当社の『オンラインヨガレッスン』事業に例えるなら、現在のビジネスの信頼性は、ヨガスタジオを地盤改良も基礎杭もない裸の地面の上に建て、その構造検査をマーケティングマネージャーが行っているようなものです」
これは個人批判ではなくて 「構造設計上の失敗」 が引き起こした組織というシステムのリスクです。そして「責任追及」ではなくて「事業存続」のため「このままではインシデントは必ず起こります。どうかクラウドセキュリティを見られる人材を検討してください」と、構造議論が必要だと提案しました。
3. 提言と組織の変革：権限の再設計こそがSRE
CEOはこの提言を理解してくれて、すぐに役員との面談がセッティングされました。役員に対し私が提言したのは以下の2点です。
- リソースの追加（What）: クラウドガバナンスとベンダー管理経験を持つ専任のITプロを採用する。
- ガバナンスの変更（How）[最重要]: 新しいプロを採用しても、最終的なシステム権限が非技術系マネージャーに残るなら意味はないです。ボトルネックとなっている権限の構造そのものを変更する必要があります。
役員会では「会社が整ったら戻ってきてほしい」という言葉をいただきました（少し前に契約終了を伝えていたため）。また後日、会社にアドバイザーとしてかかわっている他社CTOから「誰かCTOができるひとはいないかと、役員さんから聞かれた」と聞いて、提言が経営層に届いた、と思えました。
まとめ：システムの信頼性は「コード」より「組織図」から生まれる
この経験を通じて「システムの信頼性や継続性は 組織の構造、情報伝達の透明性、そして意思決定権限の適切な設計 から生まれる」という学びをえました。
SREが行うべき最も重要な仕事は、システムをコードで書くことだけではなく 事業成果に影響を与える組織の構造的欠陥を分析し、それを経営層が理解できる言語で翻訳すること でもあるな、と思います。
※この記録は、特定の組織や人物を批判する意図ではなく、実体験をもとに学びを抽象化したものです。