以下の内容はhttps://blog.topotal.tech/より取得しました。


営業が学ぶ『SREをはじめよう - 第4章』|信頼構築とコミュニケーション術

今回もエンジニアではない私が、SREをはじめようを読んでの感想をブログにまとめました。 前回第3章のブログは下記をご確認ください!

blog.topotal.tech

第4章となる今回は、技術の話かと思いきや、実は自分たちの価値をどう周囲に伝え、信頼を勝ち取るかという、営業やマーケティングにも共通するコミュニケーション戦略の章でした。

非エンジニアだからこそハッとした、3つの気づきをシェアします。


その1. 何をやっているかではなく “相手がどのドアを開けたいか” で語る

この章で印象に残ったことは、SREの定義を「ドア」に例える話です。

つい私たちは、自分たちの商品を説明するとき機能の凄さを一方的に語りがちです。でも、本書では相手にキーワードを選ばせることで、相手が信頼性?持続性?に困っているのかを引き出しています。

これって、マーケティングでいう顧客インサイトの深掘りそのものですよね。SREの提唱とは、ただの説明ではなく、組織内の「困りごと」に対するコンサルティングなんだと改めて理解しました!

その2. ヒーローはいらない、という究極のブランド管理

かつての営業の世界では「寝ずに頑張って受注しました!」という根性論が美談になりがちな印象もありましたが、SREの世界ではそれは組織の失敗だと断じられます。

また、本書の中では30時間戦ったヒーローを称賛する文化は、持続可能性を壊すともありました。

(個人的には30時間戦った方がいたら、まずは称賛したい)

これ、チームマネジメントとして非常に健全でかっこいい考え方だと思いませんか? 属人的な頑張りに頼るのではなく、誰がやっても同じ高い品質(信頼性)を提供できる仕組みを売る。これこそが、顧客が本当に求めている安心感というブランド価値の本質だと痛感。

その3. 発生していないトラブルの価値をどう言語化するか

マーケティングで最も難しいことの一つが予防や現状維持の価値を伝えることかと思っています。

大きなトラブルが起きなかったのは、裏で誰かが適切に設計していたから。このマイナスをゼロに抑え続けている価値を、コントラストを使って可視化するテクニックは、無形商材を扱うセールスにとって大きなヒントになります。


まとめ

第4章を読んで分かったのは、SREは単なる守りのエンジニアではなく、組織を動かし、信頼という名の資産を最大化させる、高度なコミュニケーション能力を持った戦略家だということです。

また「エンジニアの話だから」と敬遠するのではなく、相手のニーズに寄り添い、感情を揺さぶるストーリーを語り、持続可能な仕組みを作る。

そのマインドセットは、職種を問わず、プロとして働くすべての人に必要な「武器」になるのではないでしょうか。

ポストモーテム活用とオンコール改善で障害対応を組織化する方法

『SREの知識地図』の著者を招いてお送りするSREの旅 Road4

Topotalの宮里です。 2026年2月に開催したオンラインイベントのレポートをブログにまとめました。

今回は、SREの知識地図の著者・渡部龍一さん(@ryuichi_1208)をゲストにお招きし、書籍第4章「障害を学びにつなげる」 / 第5章「障害対応のプロセスや体制を作る」についてのオンラインイベントを開催しました。

深夜のアラート対応でメンバーが疲弊していく、ポストモーテムが反省文になってしまう、再発防止策が誰も実施しない。こういったお悩みを持ったことはありませんか?今回のトークはそのモヤモヤを解消するヒントが詰まっていました。内容をギュッとまとめてお届けします!


2つの章で伝えたかったこと

渡部さんがこの章を書いたのは、「現場で本当に困ることって、難しい技術的課題よりも人と組織の問題の方が大きい」という経験からだそうです。

  • 深夜3時に誰がどう判断すればいいか分からない
  • 乗り越えた障害をすぐ忘れて、同じ障害を繰り返してしまう
  • エンジニアの頑張りで回そうとして、組織が破綻していく

「障害対応を個人のスキルに依存せず、誰がやっても再現できる形に落とし込むことがテーマです。4章は文化、5章は制度という側面からアプローチしています」


オンコールと燃え尽き症候群 - なくせないけど、減らせる

燃え尽き症候群は完全になくせるのか?という問いに対して、渡部さんの答えは...

「なくせないとは思っています。でもどうにかして減らしていきたいというのはずっと思っているところで」

燃え尽きの主な原因はアラートの大量発生。また、オンコール自体が辛いというよりもいつ呼ばれるか分からない状態が辛い、という声も紹介されています。そういった場合は1on1でローテーションからの一時離脱を提案するだけで効果があったとのことです。

オンコールを誰が持つべきかという話では、最終的にはアプリケーションエンジニアも含めた全員で対応することが良い、という考え方が紹介されました。ビジネスロジックに踏み込んだ障害になると、SREチームだけでは対応しきれないケースが多いためです。

ただし、慣れていないメンバーに急に渡すのではなく、ツールの使い方からトレーニングする、SREと一緒にランブックを整備する、しばらくはダブルアサインするといった段階的なオンボーディングが重要とのこと。


障害対応を “楽しめるよう” になるには

渡部さんご自身は、楽しんで障害対応をするタイプと仰っていましたが、最初からそうだったわけではないとのこと。緊張をほぐすためにやっていたのが あらゆる障害に顔を突っ込む でした。

「100本やりましょうみたいな話になっちゃうんですけど(笑)。緊張を緩和して早く対応できればユーザーが幸せになるんだって思いながら取り組んでいたら、楽しめるようになっていきましたね」

また、定期的な障害対応訓練も有効です。渡部さんの会社では、今の開発状況を見てヤバそうなポイントを仕込んでステージング環境で訓練するシナリオベースの方法を採用。参加者から「障害対応が怖いものという印象が変わった」という声が上がっており、狙い通りだと感じているそうです。過去のポストモーテムを再現する訓練は新メンバーのオンボーディングにも効果的とのことでした。


ポストモーテムは反省文じゃない

第4章の核心テーマです。渡部さんが特に伝えたかったのはこの一点でした。

「ポストモーテムは誰かを責める作業ではありません。なぜそのミスを防げなかったのか、なぜ後から気づけなかったのかを分析するプロセスです。未来の障害を減らすための設計図であり、組織の記憶に変えるものです」

うまく書けない・書かれないという課題に対してはモブポストモーテムが効果的だと紹介されました。対応した人たちを集めて、画面共有しながら一緒に書き進めるモブプロ形式です。1人に任せると書かれないことが多いので、場ごと設計してしまうのがポイントとのこと。

AIで書かせた経験もあったそうですが、自動生成されたものは読まれなくなったという反省も。タイムラインなど時系列整理はAIに任せて、再発防止策など「人間が本当に考えるべき部分」は人間が担うハイブリッドが理想だという話でした。


再発防止策 ”やらない勇気” を持つ

最後に出てきたのが、一番難しいテーマかもしれない再発防止策が実施されない問題です。渡部さんが最近意識しているのが やらない勇気を醸成すること。

「発生確率が年1回で、復旧に20分しかかからないものを防ぐために2週間かかる対策をやるみたいな話は、リスクを許容してやらないと決める。エラーバジェットを許容するというSREの考え方にかなり近いと思っています」

合わせて紹介されていたのが放置されたタスクを自動クローズする仕組み。1ヶ月ほど動きのないタスクは自動でクローズされる運用で、塩漬けタスクが溜まらない状態を作っています。

「やらないんだったらないのと一緒。バックログに大量に残っているのは精神衛生上も良くないので」


まとめ

今回のオンラインイベントを通じて、渡部さんが伝えていたことはこの3つです。

ポストモーテムは未来への投資: 過去の犯人探しではなく、組織を強くするためのもの

オンコールの大変さは個人の問題じゃない: 鳴り止まないアラートはシステムからの「改善してくれ」という悲鳴。人の頑張りで蓋をしてはいけない

決断のコストを下げる: Runbookで迷いを減らし、やらないことを決める勇気を持つ。それがエンジニアを守り、サービスの信頼性を守ることにつながる

「あの人がいれば治る」「みんなで徹夜すればなんとかなる」という状態から抜け出すためのヒントが、書籍の第4章・第5章にぎっしり詰まっています。ぜひアーカイブ動画と合わせてご確認ください。

終わりに

SREの知識地図 第4章と第5章のアーカイブ動画は以下よりご確認ください〜

🎥 アーカイブ動画はこちら

📩 次回のイベント通知を受け取りたい方はConnpassでフォローをお願いします〜

監視とオブザーバビリティの違いとは?失敗パターンから学ぶ正しい導入方法

『SREの知識地図』の著者を招いてお送りするSREの旅 Road3

Topotalの宮里です。

だいぶ遅れましたが….2025年12月に開催したオンラインイベントのレポートをブログにまとめました。

今回は、SREの知識地図の著者・小林良太郎さん(@ryota_hnk)をゲストにお招きし、書籍第3章「システムの状態を観測する」についてのオンラインイベントを開催しました。

「監視とオブザーバビリティって結局何が違うの?」「オブザーバビリティツールを導入したのに全然使いこなせてない…」という声をよく耳にしますが、今回のトークはそのモヤモヤを解消するヒントがたくさんありました。そのオンラインイベントの内容の一部をお届けします!


監視とオブザーバビリティ、何が違うの?

まず、この2つの概念の違いです。似たようなデータ(CPU使用率・ログ・トレースなど)を使うのに、何が異なるのか?

  • 監視(モニタリング) は、「今、システムがおかしくないかをチェックし続ける行為」です。エラーレートが上がってないか、スループットが跳ね上がってないかなど、状態変化を継続的に見ていくものですね。
  • オブザーバビリティ はその一歩先で、障害が起きたときに、どのAPIが原因なのか・どのコードでバグが起きたのかまで調べられる組織の能力です。

「ベテランが深夜に気合いでログをgrepするんじゃなくて、最近入ったメンバーでも適切なツールを使えばどこまでたどり着けるか、そこを目指してほしいんです」

さらに書籍では書ききれなかったと言っていたのが、どのユーザーへの影響だったかまで追えることの重要性。障害が起きたとき、どのユーザーやB2B企業に影響が及んだのかを、気合いや経験値ではなくツールで把握できる状態が、オブザーバビリティの到達点の一つ、とのことです。


シグナルはバラバラに見るのではなくつなげて見る

書籍でも紹介されているUSEメソッド・REDメソッド・4 Golden Signalsの話もありましたが、強調していたのは「シグナルを関連付けて見ること」でした。

たとえばこのようなイメージです。

  • メトリクスにAWSのリージョンやアベラビリティゾーンをタグとして付けておく
  • その上で動いているアプリケーション名もメタデータとして紐付ける
  • トレースにユーザーIDを含めておく
  • そのトレースからログに飛んで、最終的な原因を特定する

これができると「ユーザーからの問い合わせ→関連トレースを確認→ログで原因特定」という流れがUI上でできるようになります。以前だとリクエストIDでgrepして…という作業が、クリックのみで終わる世界です。

「どのシグナルを見るかよりも、シグナル同士をつなげて見られる土台があるかどうかが大事。OpenTelemetryのセマンティック規約に沿ってメタデータを付けていくと、自然とつながりやすくなりますよ」


やりがちな失敗 - アンチパターン TOP3

ここが今回のトークで一番盛り上がったところで、小林さんがベンダー目線・現場目線の両方から「これは本当によく見る」という失敗パターンを3つ教えてくれました。

❌ その1:インフラチームだけで突き進む

SREやインフラチームが「オブザーバビリティやるぞ!」と旗を立てて、アプリチームを巻き込まずに進めてしまうパターンです。

DatadogやNew RelicのAPMを入れようとすると、アプリ側にトレース取得のコードを書いてもらう必要があります。でもアプリの人からすると「仕事が増える」。

コスト負担の話でもめることも多く結果として、全然進まないというのはよくある話だそうです。

そのため、 早い段階でアプリチームを巻き込み、「こんだけ見えるようになりますよ」を実際にデモして見せること。百聞は一見にしかずです。

❌ その2:ツールは変えたけど運用スタイルは変わってない

クラウド移行や監視ツールの乗り換えをしたのに、以前と全く同じ監視・運用をしているパターン。

「オープンソースツールでやってた時と同じことをやるだけなら、投資に見合った効果が得られない」

特に「全メトリクスに閾値を設定してアラートを全部入れる」設計は要注意。アラートが鳴りすぎて現場が疲弊するだけです。まず、ユーザーがどんなエラーに直面しているか?を優先的に見る運用スタイルへの転換が必要です。

❌ その3:ツールを導入することをゴールにしてしまう

これはベンダーの人が言うのは変かもしれないけど….と前置きして小林さんが仰っていたことは

「ツールを入れたから、はいオブザーバビリティ完了!ではないんです。エンドユーザーに何が起きているかを説明できる運用スタイルになっているか、それが問われる」

高機能なツールを導入しても、使い方や文化が変わらなければ宝の持ち腐れ。ツールはあくまで手段であって、目的は「組織の観測能力を上げること」です。


まとめ

今回のトークを通じて、小林さんが一貫して伝えていたことはシンプルでした。

オブザーバビリティはツールではなく、組織の能力。

その能力を高めていく方向は「開発者が楽になること」と「ユーザーが幸せになること」の2つ。ツールを入れたその先に、どんな運用の変化を起こすかが本当の勝負どころなんだと、改めて感じさせられたオンラインイベントでした。

終わりに

次回は、SREの知識地図の第4章「障害を学びにつなげる」、第5章「障害対応のプロセスや体制を作る」についてのオンラインイベントの内容をブログにします! SREの知識地図 第3章のアーカイブ動画は以下よりご確認ください〜

🎥 アーカイブ動画はこちら

📩 次回のイベント通知を受け取りたい方はConnpassでフォローをお願いします〜




以上の内容はhttps://blog.topotal.tech/より取得しました。
このページはhttp://font.textar.tv/のウェブフォントを使用してます

不具合報告/要望等はこちらへお願いします。
モバイルやる夫Viewer Ver0.14