【協賛・登壇情報】 クラウドネイティブ会議へ協賛!弊社SREによる公募セッション登壇も決定しました

みなさん、こんにちは。 Topotalでマーケティングを担当してる@miya_wata1017です。

この度、Topotal は クラウドネイティブ会議のブーススポンサーとして協賛いたします。

目次

  • クラウドネイティブ会議とは
  • 登壇情報
  • ブース情報
  • 最後に

クラウドネイティブ会議とは

クラウドネイティブ会議は、CloudNative Days、Platform Engineering Kaigi、SRE Kaigiの3大テックカンファレンスが初めて合同開催する大規模イベントです。 クラウドネイティブ技術・Platform Engineering・SREという、現代のシステム開発・運用を支える3領域が一堂に会し、分野を横断した学びと交流の場を提供します。 講演・ワークショップ・ハンズオン・ブース展示など多彩なプログラムが用意されており、若手エンジニアから熟練者、製造業からIT企業まで幅広い参加者を対象としています。

kaigi.cloudnativedays.jp

開催概要

  • 日時: 2026年5月14日(木)〜 15日(金)10:00〜18:30(予定)
  • 会場: 愛知県名古屋市中区栄4-1-1 中日ビル6F 中日ホール&カンファレンス
  • 参加費: 無料(事前申込制)
  • 形式: オンライン+オフラインのハイブリッド

登壇情報

Day2にあたる2026年5月15日(金)のセッションでは、17:40-18:10 Track Bにて「そのSLO99.9%、本当に必要ですか? 〜優先度付きSLOによる責任共有の設計思想〜」というタイトルで、TopotalのSRE @VTRyo が発表します。

event.cloudnativedays.jp

ブース情報

展示ブースでは「つらいインシデント対応を楽に、学びに、そしてゼロに。」をコンセプトに、生成AIを活用したインシデントマネジメントSaaS Waroom のデモンストレーションを実施いたします。

また、ブース展示のWaroomに加え、SREの実践支援を行うエンジニアリングサービス SRE as a Service についてもご紹介いたします。

Webサービスを支えるSRE、プラットフォームエンジニア、アプリケーション・インフラエンジニアの皆さまにお役立ていただける情報をご提供いたしますので、ぜひお立ち寄りください!

最後に

クラウドネイティブな環境における信頼性向上は、多くのチームが直面する課題です。

今回、初となる3者合同開催のカンファレンスで皆さんと議論を深められることを願っています。 会場で見かけたら、ぜひお気軽にお声がけください!

営業が学ぶ『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でフォローをお願いします〜