クラウドネイティブ会議出展レポート|登録者 約2,000名規模の大カンファレンス

こんにちは。Topotal の my-zt です。

2026年5月14日-15日に開催された、クラウドネイティブ会議@中日ホール & カンファレンスにブーススポンサーとして出展&参加してきました。

クラウドネイティブ会議 中日ホール&カンファレンス

初となる3者合同のカンファレンスであり、名古屋開催ということも影響してか、非常に熱気の高いカンファレンスでした。

クラウドネイティブ会議の概要については3月に公開したブログをご確認ください。

blog.topotal.com

開催前

名古屋開催ということで、一部メンバーは前入りし、せこせことブースの設営を行いました。

(個人的に、久しぶりの新幹線乗車ということもあり 仕事というよりも旅行に行く気分)

設営前
設営後

クラウドネイティブ会議、いよいよ開幕!

いよいよ、お祭り(クラウドネイティブ会議)の始まりです。

CloudNative Days、Platform Engineering Kaigi、SRE Kaigiの3コミュニティが合同開催したイベントの現地登録者数は約1,000人(オンライン視聴数 998人)とのことで、非常に関心度が高いカンファレンスだと伺えますね。

関東からの来場者も多いですが、名古屋開催ということもあって、中部・近畿地方の参加者も多い印象

どこから来ましたか?マップ

スポンサーブースの中央では、ご当地の名物料理も振る舞われていました。

おでん
肉団子

Topotal のブースでは、主にインシデントマネジメントSaaS「Waroom」でブース出展を行い、非常に多くのエンジニアの皆さまと会話させていただきました。 ご来場いただいた皆さま、誠にありがとうございます!

Waroom ブース

会話の中では、属人化や情報共有といった課題感の話が多い印象でした。Topotal が提供するインシデント管理SaaS「Waroom」は、サービスを支えるエンジニアの皆さまの属人化解消だけではなく、インシデント情報管理・社内各部門との連携にも力を発揮します。

日々お客様からのフィードバックをいただき、ものすごいスピードで機能アップデートを行なっておりますので、インシデント管理の体制見直しをご検討中の方はぜひお問合せくださいー!

waroom.com

また、Waroom 以外では、弊社の根幹とも言える 「SRE as a Service」についても、多くのエンジニアの皆さまと会話をさせていただきました。

弊社の SRE as a Service は、お客様社内のお困りごとをテクノロジーを駆使して解決するだけではなく、サービスの価値を最大限に引き出すためのエンジニアリングを提供しております。

  • 社内リソースが不足している…
  • 何から手をつければいいかわからない…
  • これから SRE 組織を立ち上げたいけどどうしたら良いのかわからない…

などなど、社内に SRE チームの存在有無に関わらず、ご支援可能ですので、こちらもお気軽にご相談ください!

(完全に個人視点ですが、「SRE」と聞くと ワードパワーが強すぎて「うちの会社(チーム)じゃまだ…」と思うかもしれません。)

ですが、Topotal は「よりカジュアルに SRE を実践できる状態」を提供いたします〜

topotal.com

ブースに来場いただいた、多くのエンジニアの方に、Topotal 採用ページの SREのスタイル診断 も 試していただきました🙏

もしご興味ある方は、以下の URL へアクセス👇 jobs.topotal.com

最終日の最後のセッションでは Topotal SRE の VTRyo による セッション🎉 

5/15 17:40 - SRE Track B

多くの方に視聴(オンライン/オフライン) いただき、大変感謝です!

以下より、アーカイブ視聴が可能ですので、ぜひご確認ください!

event.cloudnativedays.jp t.co

終わりに

Topotal として 初めて東京以外のブース出展でしたが、非常に多くのエンジニアの皆さんと会話でき刺激をいただきました。誠にありがとうございます!

そして、ご参加いただいた方、ご登壇いただいた方大変お疲れ様でした!

また、クラウドネイティブ会議を滞りなく進行いただいた運営の皆さまにも大変感謝です!

別のカンファレンスで Topotal を見かけたら お気軽にお声がけください〜

非エンジニアが読む『SREをはじめよう』第5章

はじめに

こんにちは。Topotal マーケティング担当のmy-ztです。

「SREをはじめよう」の第1章から第4章は、SREとは何か・どんな考え方をするのか、という 思想・文化 の話が中心でしたが、今回の第5章はいよいよ「じゃあSREになるために何が必要なの?」というSREになるための準備です。

章の冒頭で著者が言っていますが、この章は 必ずこれを全部知っていなければSREを名乗れないというチェックリストではなく、必要な要素を探していくための地図を示してくれる章だと。

それだけでも気が楽になります(私はSREを目指しているわけではないですが……!)。

技術的な深い話も多い印象のこの章。今回も非エンジニアの視点でブログにまとめていきます〜

📚SREをはじめよう を読み、営業視点で響いた3選

1. SREは 監視する人 ではなく、パズルを解く 探偵ぽい?

第5章の冒頭では、コーディングや計算機科学、システムの仕組みを知る重要性が語られています。 システムがどう作られているかを知らないと、どう壊れるかが理解できないからです。

障害対応は単純な原因究明ではありません。複雑に絡み合ったシステムから問題を見つけ出す探偵仕事のようなものだと感じました。

営業・マーケの立場から TopotalのSREが何者なのかを語るとき、ここを理解していないと伝わらないということ。また、アルゴリズムなどの計算機科学の知識は、SaaS系プロダクトの営業としてなぜパフォーマンスに差が出るのかを顧客に説明するシーンでも役立ちそうだと感じました。

(私にとってはかなりハードルが高く感じました...)

2. データとストーリーはエンジニア/非エンジニア関係ない共通の武器

統計・データの可視化 と ストーリーテリングは、個人的に印象に残る章でした。 著者はデータにはストーリーがあると言っています。

客観的なデータを使って会話すること、そしてそれをストーリーとして他者に伝えることの重要性を説いています。これって、エンジニア/非エンジニアであろうと関係なくデータがあっても、うまくストーリーに乗せて伝えられなければ相手からの信頼は得られないですね。

人間はストーリーを通じて情報を受け取るようにできているという言葉は、SREに限らずすべての仕事に通じる話だと思いました。

3. 大いなる力には大いなる責任がともなう

章の最後に 良い人であれ という項目があり、ここが最も印象的でした。 SREはプライバシー・倫理・平等について継続的に学ぶ必要がある。

なぜなら 私たちは地球上で最大かつ最も重要なシステムの運営を任されている から。 ここで「大いなる力には、大いなる責任がともなう」という言葉が使われています。技術書でこの言葉が出てくることに少し驚きと感動を覚えました。

SREという職種への敬意と責任感が伝わり、Topotalが大切にしている価値観(行動規範)とも共通するものがありそうです。👇 jobs.topotal.com

まとめ

第5章は 準備 というタイトルでしたが、技術的な知識にとどまらず、データを伝える力、人に語る力、そして倫理観といった プロフェッショナルとしての在り方 を学べる章でした。 SREではない私にとっても、日々のビジネスに活かせるヒントがたくさん見つかりました!

⏭️次回予告

次回は「SREをはじめよう_第6章」についてです。 第6章では、SREになるための一般的な出発点から、SREの世界に入るためのヒントが得られる?かもしれない章です。 非エンジニアにとっての学びがあるのか? を意識して引き続き書いていきたいと思います〜

夜も眠れないリリースを防ぐSREの知恵|トイル削減とPRR

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

Topotalの宮里 です。

先日、4月23日(木) に第 5 回目となる #SREの旅 Road 5 「トイルをなくしリリースを守る」のオンラインイベントを開催しました!

今回は、『SREの知識地図』 第 6 章・第 7 章の著者である 齊藤さんをゲストに迎え、書籍第6章「手作業を自動化し効率化する」 / 第7章「サービスのリリースを事前にレビューする」についてです。

ゲストショートトークで齊藤さんが投影した資料も合わせてご覧ください📁 speakerdeck.com

また、当日のゲストショートトークやパネルディスカッションの様子は以下のアーカイブをご確認ください🎥

www.youtube.com


1. トイル(Toil)とは何か?――その正体と計測の重要性

まず、永遠の課題とも言える トイル(Toil)についてです。

齊藤さんは、単に 面倒な仕事 すべてをトイルと呼ぶのではなく、以下の6つの特徴で見極めるべきだと強調します。

  • トイルの特徴:
    • 手作業
    • 反復的
    • 自動化可能
    • 戦術的(場当たり的)
    • 永続的価値がない
    • サービスの成長に比例して増える

まずは測ることから改善が始まる

「トイルを減らしたい」と思っても、感覚だけで動くのは危険であり、計測 こそが出発点だと言います。

  • 例えば、Jira などのチケット管理ツールでトイルラベルを貼る。
  • 例えば、Slack の問い合わせ対応を分類し、数を確認する。
  • 例えば、ストーリーポイントのうち、何割がトイルに消えているかを可視化する。

何にどれだけ時間を奪われているか?を数字で示すことができれば、組織としてこの自動化に時間を投資しようという意思決定ができるようになります。


2. PRR は関所ではなく、リリースを支えるセーフティネット

続いて第7章のテーマ、PRR(プロダクションレディネスレビュー)

これは、新しいサービスを本番に出す前に、運用面での準備ができているかをチェックするプロセスです。

ここで印象的だったのは、PRR はリリースを止めるための壁 にしないという考え方です。

  • Early Engagement(早期関与): リリース直前にダメ出しをするのは、開発者にとっても SRE にとっても不幸です。設計段階から SRE が関わり、「モニタリングはどうしますか?」と伴走するのが理想的な姿。
  • チェックリストの改善: 毎回パスする項目は自動化するか削除し、毎回ひっかかる項目があれば、それは 仕組み(プラットフォーム)で解決すべきサイン。

PRR の本質は、開発者の足を引っ張ることではなく、「本番に出した後に夜も眠れないような事態を防ぐ」ためのセーフティネットと言えるのではないでしょうか。


3. AI 時代の SRE ――「AI スロップ」という新たな敵への対抗策

後半のディスカッションでは、AI(LLM)が SRE の仕事をどう変えるかという熱い議論が交わされました。

AIがトイルを加速させる?

AI によってコード生成が簡単になった結果、AI スロップ(AIが生んだ質の低い成果物) が大量にプルリクエストとして飛んでくるという、新たなトイルが発生しているという興味深い指摘がありました。

変わらない 原理原則 の大切さ

齊藤さんは「AI 時代だからこそ、これまで積み上げてきたプラクティスをちゃんとやる以外に道はない」と語ります。

  • 可観測性(オブザーバビリティ)の整備
  • ユニットテストのカバレッジ担保
  • しっかりとしたレビュー文化

これら 基礎 が整っていない状態でAIを使っても、不要物を量産するだけになってしまいます。逆に、基礎があるチームが AI を使いこなせば、初動調査の自動化など、トイル削減を劇的に加速させることができます。


4. おわりに:SRE の知識は仕組みと寄り添い

今回のイベントを通じて、SRE のプラクティスは決して冷たいルールではなく、現場のエンジニアが安心して挑戦を続けるための 優しさの仕組み化 なのだと感じました。

『SREの知識地図』は、こうした現場の知恵が詰まった一冊です。エンジニアの方はもちろん、チームの生産性に悩むマネージャーの方も、ぜひ手に取ってみてはいかがでしょうか。


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