先日、2026年5月14〜15日に開催されたクラウドネイティブ会議に、SRE/インフラエンジニアの木村が現地参加しました。
本記事では、現地で参加して感じたことや印象に残ったセッションのレポートをお送りします。
イベント参加の背景
クラウドネイティブ会議は、CloudNative Days、Platform Engineering Kaigi、SRE Kaigiの三つのイベントが合同で開催したイベントです。
この3つは、いわばクラウド時代のシステム開発を支える「三本柱」です。クラウドネイティブ技術だけでは複雑さに飲まれ、SREだけでは開発者の生産性が追いつかず、プラットフォームエンジニアリングだけでは信頼性の担保が難しい。3つを体系的に理解し、組み合わせて実践することで、はじめて「品質高く、かつ生産性を高める」という、本当の意味でのイノベーションが可能になります。
この三種類の分野を組み合わせて品質や生産性の向上を目指す考え方は、まさにGENDAのSRE/インフラの方針と一致しています。
GENDAではクラウド環境を中心とした開発・運用を行っています。クラウドならではの強みを活かした効率的な開発手法や、クラウドだからこそ気を付けるべきリスクをキャッチアップし続ける必要があります。また、複数のグループ企業のプロダクトの信頼性や、それらの開発・運用に携わるチームの開発者体験を横断的に高めていくにあたり、SREやPlatform Engineeringのプラクティスも大いに役立ちます。
本イベントはまさに我々の業務に直結する内容が多かったため、情報収集を目的として現地参加するに至りました。
感想
イベント全体を通して
セッションを聴講したりブースや懇親会で交流するなかで感じたのは、参加者層の厚さです。大企業の方々からコミュニティの運営メンバーまで、多種多様な人と出会うことができました。イベント主旨の通り、領域を越えて集う“交差点”になっていました。
会場には、参加者の交流を促す創意工夫も随所にありました。
ジョブボードは多くのカンファレンスで用意されていますが、今回はそれだけでなく、自由に交流できるホワイトボードやノートも用意されていたのが新鮮でした。
ホワイトボードで「名古屋のおすすめの飲食店は？」「ここがオススメ」という情報交換が行われていたり、ノートに「CentOSの思い出を語るページ」が誕生していたのが印象的でした。
GameDay や 用語解説チャレンジ といった参加型の企画もあり、コンテンツが盛りだくさんで、暇を感じる時間が一瞬たりともありませんでした。
出展ブース
デジタルスタンプラリーが用意されており、五つのスタンプを集めるとランダムな景品と引き換えができるシステムになっていました。スタンプラリー形式は多くのイベントで取り入れられていますが、ブースに立ち寄って話しかける動機になるので個人的にはとてもありがたいです。
「このツールが便利」「こういうチームがあってこういう分業をしている」といった生の声を交えた情報交換ができたことは、現地参加ならではの体験でした。
いくつかの企業ブースでは参加型のボードが用意されていました。KINTOテクノロジーズさんのブースでは「誰にも言えないけど、手動でやり続けてること」というお題のボードがありました。クスッと笑えるものから、それは自動化したいよねと共感できるものまであり、面白いボードでした。
KDDIアジャイル開発センターさんのブースでは、有志で執筆したという冊子を無料配布していました。このうち「エモーショナル・レトロスペクティブ入門」という特集はとても興味深く、所属チームのレトロスペクティブにも取り入れられそうでした。
印象に残ったセッション
クラウドネイティブ、SRE、Platform Engineeringのそれぞれの観点で印象に残ったセッションをご紹介します。
「OSSがあるなら自作するな」はAI時代も正しいか — Build vs Adoptの新しい判断基準
まさに最近、GitHub Actionsのワークフローをレビューしていて「個人開発のActionを業務利用するのってどうなの？」という会話をしたばかりだったため、前提となるエピソードに共感しながら聴講しました。
本セッションでは、外部依存による影響を受けるリスクを「依存コスト」、保守・運用し続けるコストを「所有コスト」と呼び、Adopt（OSS採用）して依存コストを受け入れるのか、Build（内製）して所有コストを受け入れるのか、その判断基準が体系的に述べられていました。
AIの台頭により、内製のための実装コストは下がったものの、その成果物を長く使い続けるための保守・運用が楽になったかというと、必ずしもそうではない。だからこそ、なんでも自前で実装すればいいというわけではない。
この分析は、自分自身の体験と照らし合わせても納得感があります。一方で、「何を満たしたら内製が有力候補になりうるのか」という判断基準が自分のなかでも定まりきっていなかったため、本セッションでの知見は今後の技術選定において力強い物差しになると感じました。
特に印象的だったのは、「Buildコストは“作れたか”ではなく“次も扱えるか”で測るべき」という考え方です。AIで実装すると“作れた”ことに着目しがちですが、これからも続く運用を見越して“次も扱えるか”という問い掛けをするのはとても重要だと思います。
「わたしがやっていることは、果たしてSREなのだろうか？」〜負荷試験から始める、積み上げ式オブザーバビリティ〜
「わたしがやっていることは、果たしてSREなのだろうか？」
私自身も、SREという肩書きを持ちながら、同じ疑問を何度も抱いたことがあります。
本セッションでは、サービスの課題解決に日々取り組んでいくなかで、自然とオブザーバビリティの向上を積み重ねており、振り返ってみればSREと呼べる活動だった、というエピソードが紹介されました。
- DBのCPUが頻繁に100%に達するから、まずは負荷試験で限界を把握する
- 負荷試験ツールの結果だけではDB内部の問題が見えないから、自作のメトリクス収集スクリプトを作る
- 複数のメトリクスからインサイトを得るために、AIによる分析を試す
このように、課題に一つずつ向き合って解決を試みることで、結果的に信頼性の向上に貢献していたことが述べられていました。最終的に、メトリクスという目に見える形で性能が改善した成果には胸が熱くなりました。
この“積み上げ式オブザーバビリティ”は、一般的にイメージするSREの実践方法とは異なるものの、より現場に密着したSREの実践であると思います。現場の課題解決を粛々とこなす、その地道な積み重ねこそが、最終的に大きな価値を生むのだと感じさせられる内容でした。
Platform Engineeringはなぜスケールしないのか ― スコープ設計と責任境界の話
過去に自分自身でもうまくいかなかった体験が言語化されているようで、教訓の多いセッションでした。
本セッションでは、コッターの「変革の8段階のプロセス」のうち以下の三つに失敗要因があると述べられました。
-
- 危機意識を高める
-
- ビジョンと戦略を生み出す
-
- 短期的成果を実現する
多くの失敗は、一つ目の「危機意識を高める」に要因があるとのことでした。まさに自分自身もここで失敗してしまった経験があります。
「これがベストプラクティスだから、これをやるのはいいことだ」と信じ込んでいると、相手との目線合わせを疎かにしてしまいます。立場が異なれば価値観や優先順位も異なるため、その活動によって生まれる価値をきちんと説明できなければならないのだと、改めて考えさせられました。
また「ビジョンと戦略を生み出す」については、長期的な活動だからこその戦略の重要性が述べられました。「Kubernetesのポータルサイトを作ったけど使われなかった」という事例では、プラットフォーム利用者のペルソナ分析が不十分だったことが失敗の要因として挙げられていました。
同日の別のセッション「プラットフォームエンジニアリング、結局なにをすればいいのか？」でも「これがあれば良くなる“だろう”でプラットフォームを作ってはいけない」というエピソードがありました。Platform Engineeringの先駆者が口を揃えて「思い込みは禁物」という教訓を伝えており、利用者視点を持つ重要性をひしひしと感じました。
おわりに
非常に学びが多いイベントでありつつも、業務として参加していることをつい忘れてしまいそうな程、お祭り感があり楽しいカンファレンスでした。このような楽しく学べる場を作ってくださった運営の皆様に感謝いたします。
ここで得られた知見を業務に役立て、その成果をコミュニティに還元していきたいと思います。
Discussion