マネジメント層こそ読んで欲しい「ガバクラ」が言及するSRE
안녕하신게라！パナソニック コネクト株式会社クラウドソリューション部の加賀です。
皆様は、デジタル庁がガバメントクラウド（ガバクラ）におけるシステム整備の指針として公開している「政府情報システムにおけるモダナイゼーションへのアプローチ」をご存知でしょうか。
「お堅い政府のシステム仕様書だろう」と侮るなかれ。ここには、多くの民間企業が抱えるシステム開発や運用の「構造的な病」を根本から段階的に治療する、驚くほど実践的なSREの処方箋が詰まっています。
本記事ではこのガイドラインを起点に、「SREはどのような『組織の病』を治すのか」「マネジメント層は、自社という組織に対し具体的に何を『処方』すべきか」という観点で紐解きます。
単なる現場の技術論にはとどまらない、日々システムと向き合う最前線からの「SREのリアルな読み解き」としてお役立ていただければ幸いです。
※最後に、現場エンジニアとしての火力高めな個人の思い（ポエム）を含んでいます。
SREは「現場で完結する技術論」ではない
マネジメント層の皆様にまずお伝えしたいのは、SRE（Site Reliability Engineering）は最新ツールを導入し、現場に自動化スクリプトを書かせるような局所的な技術論ではないということです。
その真の目的は、システムの「信頼性」と「開発スピード」という相反する要求を両立させることです。そのためには「開発部門と運用部門がどう協力し、どう評価されるべきか」というルールそのものを再定義する必要があります。
つまり、SREとは、経営・マネジメント層がリーダーシップを持って推進すべき「組織構造の変革」に他なりません。
「開発」と「運用」の分割が生んだサイロ化
かつてのIT世界では、「システムを作る部門（開発）」と「システムを守る部門（運用）」を明確に切り分けることが、責任分界点が明確な正解とされていました。しかし今日、ビジネスの要求スピードが劇的に上がる中で、この「作る側と守る側を分断する体制」は最大のボトルネックへと変貌しているのが可視化されてきました。
その根本的な理由は、両者のミッション（評価軸）が真っ向から対立していることにあります。
開発の使命は「ビジネスの要求に合わせて、システムをスピーディに変更し続けること」。一方、運用は「障害を起こさないようシステムを極力変更せず、現状維持で安全稼働させること」です。
それぞれが与えられた目標を守ろうと真面目に働けば働くほど、必然的に激しい対立が生じます。
開発部門が「早く新機能をリリースしよう」と頑張るほど、運用部門にとっては「未知の障害リスク」が急増します。逆に、運用部門が「絶対にシステムを落とさないぞ」と厳しすぎる承認フローや手動テストを敷くほど、今度は「ビジネスの提供スピードを阻害する壁」となって跳ね返ります。
悪気なく自部門の正義を全うしようとするだけで、相手の首を絞め合う関係（サイロ化）に陥っているのです。この構造的ジレンマは、もはや現場の気合いやコミュニケーションによる個別調整で乗り切れないのは明らかです。そして皮肉なことに、サイロ化が生み出した摩擦熱で炎上し、その火消しに貴重なエンジニアのパワーがごっそりと浪費されているのが現実です。誰に向けて仕事しているのでしょう。
SRE体制へ移行するために必要な組織のアップデート
こうした構造的な課題を根本から見直し、SREという新しいカルチャーを組織にインストールするためには、マネジメント層の主導による意識変革とルールの切り替えが欠かせません。相応の時間も掛かることでしょう。
単なる現場の技術論に矮小化せず、組織のルールやカルチャーとして押し広げることこそが、マネジメント層に求められる「真のリーダーシップ」の形です。
現場からのボトムアップだけでは絶対に越えられない、マネジメント層にしかできない具体的な組織アップデートの鍵を3つ挙げます。
※急ぎ結論だけ知りたい場合、ポエムへお進みください。
「絶対無停止」の幻想を捨て、実利のためのSLOを合意する
「絶対にシステムを止めるな」と非現実的な稼働率（SLA）を顧客と握り、それをそのまま運用部門へ丸投げしていないでしょうか。システムの信頼性を100%に近づけようとするとインフラコストは指数関数的に跳ね上がり、ビジネスのROI（投資対効果）を劇的に悪化させます。
だからこそSREは、インフラ目線の単純な死活監視ではなく、「トップページの応答速度」や「エラー率」といった顧客にとって本当に重要な指標（SLI）を定め、「99%のユーザーに3秒以内に表示する」といった適正な目標値（SLO）をビジネス設計の段階で合意します。見せかけの絶対無停止を諦め、過剰投資を抑えることこそが正しいリスク管理戦略なのです。
ここでマネジメントの鍵となるのが、「エラーバジェット（失敗の予算）」の運用です。
SLOから逆算された「システム停止が許容される時間（＝予算）」を定義し、予算があるうちは新機能の開発スピードを優先。予算が尽きたら直ちに新機能のリリースを止め、全員でシステムの安定化（技術的負債の返済など）に注力するという共通ルールを敷きます。
ルールを作るのは簡単ですが、いざ「予算が尽きたから新機能のリリースを止める」となれば、事業側からの強い反発など必ず一時的な痛みが伴います。だからこそ、「誰がストップをかけるのか」を曖昧にしたり、部署間の力関係に委ねてはいけません。
エラーバジェットにおいて真のブレーキを踏む（リリースを止める手続きをする）のは、あらかじめ合意された「ルール」であり、それを執行する「現場のエンジニア」です。しかし、事業側から「どうしてもリリースしてくれ」と圧力がかかった際、現場のエンジニアを矢面に立たせるのではなく、経営・マネジメント層自らが防波堤となり「合意したルールに従い、今はリリースを止めて安定化を優先する」と現場のストップ判断を守り抜く必要があります。
信頼性とは、運用部門だけが押し付けられる十字架ではなく、全員で守るべきビジネス要件です。この「ルールを執行する現場」と「それを守り抜くトップの覚悟」のセットがあって初めて、エラーバジェットは組織にスピードと安定性をもたらす共通言語となります。
インシデントを「資産」として運用する専門チームの立ち上げ
システム運用において、障害対応を外部の運用ベンダーや保守担当部門に「丸投げ」しているケースは少なくありません。
SREにおいて、インシデントは「素早く後始末して隠すエラー」ではなく、システムを進化させるための「組織の貴重な学習資産」です。
障害対応をアウトソースしてチケットをクローズするだけの丸投げ体制は、この資産を日々ドブに捨てているのと同じです。だからこそ、ガイドラインにおいても「事業者に委ねるだけの従来体制からの脱却」が強く推奨されています。
まずは自社内に当事者意識を取り戻し、障害から得た知見をもとにインフラのコード化や自動化へ投資する。こうした実践の積み重ねが、やがて組織の信頼性を牽引するSRE専門チームへと育っていくのです。
資産は「ただ貯め込む」だけでは無意味です。一つのシステムで得られた教訓や対策を、他システムや別の開発チームへ「横展開」し、活用してこそ初めて全社的な価値を生みます。さらには、運用を特定チームに押し付けるのではなく、開発チーム自身も運用（障害対応）に参加し、システムの痛みを組織全体で共有する仕組みも重要です。
しかし、「教訓の横展開」や「根本原因を解決する自動化ツールの作成」といった活動は、目先の新機能リリースのように目立つ成果になりにくく、現場のボトムアップだけでは十分な工数を確保し続けることが困難です。
これを仕組みとして定着させるのがマネジメント層の役割です。「開発チームをリリースの数だけでなくシステムの安定性への貢献度でも評価する」「運用チームを定常稼働だけでなく教訓の横展開や自動化への投資で加点評価する」など、現場が安心して「資産づくり」に時間を使えるよう、人事評価や組織評価の軸を根本からアップデートし、後押ししてください。
「非難しない」ポストモーテムプロセスを公式ルール化する
最後は、見つけ出したインシデント（資産）を組織としてどう育てていくかです。
システム障害が起きた際、「誰がミスをしたか」という犯人探しを始めると、現場には保身と「隠蔽の力学」が働きます。事実をありのままに報告できなくなれば、エンジニアが持つ気付きや教訓という「一番の宝」を組織として回収できなくなります。
その結果、「無意味なダブルチェックの徹底」といった、サービス進化に比例して増え続け長期的に価値を生まない手作業（SREではこれを「トイル」と呼びます）ばかりが増えていきます。そして最終的には、個人の注意力に依存した精神論的な再発防止に頼るしかなくなります（それが効果を出さないことも経験として知っているはずです）。
だからこそSREは、「誰が」ではなく「システムのどこに不備があったか」に目を向ける「非難しない振り返り（Blameless Post-mortem）」を標準プロセスとします。「非難しない」とはエンジニアへの単なる配慮ではなく、根本原因を正確に抽出しシステムを進化させるための「属人性を排したシステマティックな再発防止策」なのです。
しかし、この「非難しない文化」は、現場の努力や歩み寄りだけで定着するものではありません。
いくら現場のエンジニア同士が「お互いを責めないでおこう」と口約束しても、最終的に賞与や昇進を決める会社の人事評価が「障害の原因を作ったから減点」のままであれば、誰もが保身に走ります。
「隠蔽しない土壌」を作る責任は、評価権限を持つマネジメント層にしか負えないのです。
政府のガイドラインでさえ、この非難しない宣言を振り返り会議の冒頭で都度読み上げるよう明記しています。現場が真因の究明に集中できるよう、経営・事業・マネジメント層自らが「ミス＝減点」という旧来の評価基準を捨て、このプロセスを一時的なスローガンではなく「公式の人事ルール」として制度化すること。それがマネジメント層に求められる最後の鍵です。
ありのままの事実が報告される土壌ができて初めて、先述した無意味なダブルチェックのような「トイル」を削減でき、エンジニアの頭脳を「自動化」や「新しいビジネス価値の創造」へと再配置できるようになります。
エンジニアが持ち帰った「教訓」という宝を、保身のためにドブに捨てさせるのか、それとも組織の資産として活かし、利益を生む源泉に変えるのか。その生殺与奪の鍵を握っているのは、他でもないマネジメント層の評価権限です。
犯人探しをやめ宝探しをさせる。すなわち、システムの根本改善と資産形成に向かって投資できるルールを作り、どう働くべきか促す。これこそが、高いROI（投資対効果）を生み出すための、経営の真のリーダーシップなのです。
ポエム「なぜ、リーダー不在では失敗するのか」
実は「開発と運用」と同じく「現場とマネジメント層」もサイロ化しており、お互いの仕事を全うすればするほど、互いの首を絞め合っていたのかもしれません。
乗り越えるため「もっと信頼して歩み寄ろう」なんていうド綺麗事でジレンマが解決するなら、これほど多くの企業や政府すらも苦労なんかせずに済んだし、SREがそもそも生まれることも無かったでしょう。
組織論は精神論や根性論では無く、本来もっとロジカルなはずです。
人間の曖昧な感情に頼らず、SLOやエラーバジェットといった「冷徹なデータと、誰もが忖度なしに従うべきルール」にすり替えるSRE。この仕組みを機能させるための「最後の1ピース」がリーダーです。
ツール導入、作業自動化、現場レベルでの非難しないチーム作り、私たち現場のエンジニアだけでも勝手に進められます。ただ、どれだけ現場が熱狂し、どれだけ先進的なツールを導入して局所的な成功を収めたとしても、権限を持つマネジメント層による「評価基準の刷新」や「全社ルールの変更」といった強力な後押しがなければ、その取り組みは「異端なチームの勝手な活動」として必ず組織の壁に阻まれ、失敗に終わります。現場がどれだけ枠を超えてルールを変えようと踏み込んでも、権限が伴わなければそれはただの「部門間の喧嘩」でしかありません。
タイトルにつけた「リーダー不在では失敗する」という言葉。これは、そんな異端チームを守ってほしいという生ぬるいお願いではありません。現場が泥臭く掘り当てた教訓という宝を、ただの部門間の言い訳で消費させるのか、それとも全社を巻き込むルール改善の武器として振るうのか。
その「決断を下すリーダー」という最後のピースがハマらなければ、SREは絶対に完成しないからです。
同時に、現場のエンジニアたちにも伝えたい。「上が変わってくれない」と愚痴をこぼして待つ暇はありません。リーダーが決断した瞬間に最速で動けるよう、日々の失敗から得た教訓という「宝」を集め、提案の刃として研ぎ澄ませておく責任が私たちにはあります。
お堅い政府ですら変わろうと発信している運用カルチャーを、自社に取り入れた先に見えるは如何なる景色か。
現場が持ち帰る「宝」と、マネジメント層による「宝の資産活用」のルール化。
この両輪が本気で噛み合ったとき、組織がどう変わるのか。試してみたいと思いませんか？
お断り
記事内容は個人の見解であり、所属組織の立場や戦略・意見を代表するものではありません。
あくまでエンジニアとしての経験や考えを発信していますので、ご了承ください。