会場は名古屋の中日ホール。広い会場で様々な立場の人が2日間に集まりました。参加申込者は1000人超えたらしいです！
はじめに
2026年5月14日（木）・15日（金）、名古屋・中日ホール&カンファレンスで開催された クラウドネイティブ会議2026 に参加してきました。
CloudNative Days・SRE Kaigi・Platform Engineering Kaigi——普段はそれぞれの領域で活動している3つのコミュニティが、初めて合同で開いたカンファレンスです。「クラウドネイティブ」「信頼性」「開発生産性」という、地続きになっているテーマが、ひとつの会場に集まりました。
今回は、印象に残ったセッションと、会場で得た「問い」をほんの少し整理してみました。これからクラウドネイティブ・SRE・Platform Engineeringに踏み出したい方の、最初の一歩のきっかけになれば嬉しいです。
2日間を貫いていたメッセージ——「小さく始める」勇気
2日間を通して、複数の登壇者から繰り返し聞こえてきたメッセージがあります。それは 「小さく始めて構わない」——いま立っている場所からまず一歩、いや、半歩でも進む、という姿勢でした。
完璧な体制を整えてから着手するのではなく、できるところから動かしながら整えて、社内やチームで味方や賛同する人たちを増やし進める。その過程で信頼関係を作り、プロダクトも育て、強いチーム、ひいては組織にしていく文化・行動指針です。
また、もう一つの流れとして、AIエージェント時代に人はどこに立つのか——AIエージェントを使ってリリースのスピードを早め、安全に修正するために、機械より早く「考える」こと、責任を取るのは人、という問いかけが多く聞こえてきました。
ここからは、特に印象に残ったセッションを、時系列順に紹介します。
印象に残ったセッション
1. 老舗IoTクラウドサービス組織の変革 ──クラウドネイティブをはじめよう──（パナソニックエレクトリックワークス／Day1キーノート）
Day1のキーノートは、パナソニックエレクトリックワークスのMasanori Maruokaさん・Shohei Konoさん、パナソニック株式会社のHodaka Tashiroさんによる「老舗IoTクラウドサービス組織の変革──クラウドネイティブをはじめよう──」です。
外部に依存していた組織が、自分たちで手を動かして主体的に動ける組織へと変わっていった——クラウドネイティブ化をキーワードに、IoTサービスの開発を経て、いまは全社直轄の新規事業をリードする立場に至るまでの道のりを、行き詰まったことや考え方の変化など、当事者の言葉で具体例を添えて語ってくれたセッションでした。
「クラウドネイティブ」という技術の話に見えて、本質は 組織のあり方を変えるための共通言語にする話、と感じました。SREやPlatform Engineeringの文脈ともつながり、「組織の強さの発揮」の好例だったと思います。
「Gitを入れること」が最初の関門になるあるある
特に共感したのが、推進方針の最初に 「GitLabを導入！」 と言及していたことです。
私が関わるエンタープライズの新規事業の現場でも、これまでソフトウェア開発を外部に委託してきた組織が内製化を始めるとき、Gitを入れること自体が最初の関門になることを目の当たりにしてきました。
外部委託やグループ会社に任せていた場合や、独自の変更管理システムがあるがGitHubやGitLabの環境が整っていない場合に、開発環境を整備しようとした段階でこの壁にぶち当たることになります。
私自身、GitHubの契約（大きな会社の場合Freeプランで始めることもできないため）を進めてもらうために、Git管理の安全性やGitLabやGitHubのSaaSサービスの比較・運用ルールの整備や費用を比較表で整理するのを手伝った経験が何度かありますが、ソフトウェア開発を外部に委託していた組織だと開発チームを立ち上げた段階で気づくこともあり、初手で苦労します。
Gitは導入済みとしても、開発チームが発足してから実は使えると思っていたサービスを契約してなかった（例えばDocker）など、予算・契約を使う段階で調整して結構苦労するのは開発あるあるじゃないでしょうか。
このような、ソフトウェア開発では「当たり前」の環境を整えるところから、クラウドネイティブ化の出発点としているのは、とても良いなと思って頷きながら聞いていました。
モノレポとマイクロサービス、AI時代の答えは？
もう一つ立ち止まったのが、モノレポからマイクロサービスへの分割の話です。ステートフルなモノリスのつらさ（スケーリング・可用性・Kubernetes との相性）自体は頷ける指摘でした。
ただ、このあと触れる Day2の Yuki Hattori さんのキーノートで「人間のサイロは AI のサイロでもある」と聞いたあとだと、チームの認知負荷と、AIエージェントが見渡せる範囲、それぞれの最適点はどこか——という問いとして頭に残りました。
組織によって、最適なモノレポ／マイクロサービスのバランスは異なります。いまはツールによってリポジトリサイズもデプロイ粒度も柔軟に変えられるので、システムや組織の特性に応じて調整するべきテーマ——として、自分のなかで考え続けたい問いになりました。
2. 境界を溶かすエンジニアリング─サイロを超える技術と文化のデザイン（GitHub Yuki Hattoriさん／Day2キーノート）
Day2のキーノートは、GitHubのYuki Hattoriさん（Staff Architect）による「境界を溶かすエンジニアリング─サイロを超える技術と文化のデザイン」。AIエージェントが日常的にコードを書く時代、組織の中の"境界"がどう変わるかを問うセッションでした。
一番刺さったのは、このフレーズです。
人間の体験するサイロは、エージェントが体験するサイロでもある
開発者が日々ぶつかっている「他チームのリポジトリが見られない」「経費承認のフローが煩雑」「ドキュメントが分散している」といった摩擦は、AIエージェントを業務に組み込んだ瞬間、そのままエージェントの摩擦になる。サイロは人だけの問題ではなく、AI時代のスケーリングそのものの問題なのだ——という指摘で、視界が一段クリアになりました。
Hattoriさんは「組織のエンジニアリング」として、3つの壁と処方箋を提示していました。
アクセスの壁：Permission Lessな組織を目指す
GitHubの場合、「ORG全員チーム」でPrivate Repositoryを運用し、Write権限をデフォルトにして、ブランチプロテクションで守る、という構成が紹介されていました。インナーソース化のライセンス整備にはInnerSource License Generatorが便利、という具体的な例も提示してくれました。
お金と税金の壁：正面突破はNG、バックドアから
会計に詳しい社内の味方をつける、リーダーのバックアップを得る、スコープと正当性を整理する、理論武装と代案を持つ——「正面のドアを叩けば『安全に倒す』ための力学が働く」という言葉で、過去の経験を思い出して、苦笑いしてしまったのは内緒です。
コンテキストの壁：ドキュメントはリポジトリ内/Issueへ
「Did You Read the FINE Manual?」——リポジトリの中にちゃんと書いてあるよ、と。ドキュメントを一つのアクセス権限で読める場所に集約する、というシンプルな原則です。
加えて、Sam AltmanがStripe Sessionsで語ったという引用も紹介されていました。
「データアクセスに関して、居心地が悪くなるほど寛容であること。これをやるべきでない理由は山ほどあるし、推奨とまでは言わない。でも『よし、ミーティングは全部録画して、AIにコードベースへのアクセスを与えよう、Slackもメールも何もかも全部アクセスさせよう、社員全員がそうやって使えるようにしよう』と腹をくくる」
そうすればAIは驚くほど情報を整理して事業を進めてくれる武器になる、とも。
言い換えると、心地よさのラインを越えて開放できるかどうかが、AI活用の分かれ目です。機密データやコンプライアンスの整備が進んだ大企業よりも、思い切れる小さなスタートアップの方が先に走れてしまう——AI時代の生産性格差は、こうした「踏み込み方の差」から生まれるのかもしれません。
複数のチームと現場を抱えながら開発を進めるとき、「組織自体をエンジニアリングする」という視座を持てているか——自分たちにも返ってくる問いだと感じました。
3. プラットフォームエンジニアリング、結局なにをすればいいのか？（Kazuto Kusamaさん／Day2朝）
Day2の午前、GitHubキーノートの後に聞いたのが、Kazuto Kusamaさん（PagerDuty Product Evangelist）による「プラットフォームエンジニアリング、結局なにをすればいいのか？」でした。
冒頭で示された定義が分かりやすかったです——プラットフォームとは 「開発者や運用者に役立つ機能（API・ツール・サービス・ナレッジ・サポート）を、魅力的な社内プロダクトとして整備した基盤」。それを「作り、育てる」のがプラットフォームエンジニアリング、と。空港のインフラを航空会社が利用する関係に例えると分かりやすい、という説明もありました。
「最も小さいプラットフォームは、ただのWikiかも」
なるほど、と思ったのがこのスライド。Team Topologiesの Thinnest Viable Platform（TVP） の考え方を引きながら、「プラットフォームに必要なものがWikiだけなら、Wikiだけで構成してもいい」と。専任チームを立てられなくても、Wikiから始めればPlatform Engineeringはもう始まっている、という背中の押し方が嬉しかったです。
「いっしょにご飯を食べに行きましょう」
このセッションで一番好きだったスライドが、これでした。
いっしょにご飯を食べに行きましょう
「プラットフォームチームは何をすればいいの？」の答えとして、まずは ランチで困りごとを聞こう、コラボレーションから始めれば、インサイトと信頼関係が同時に得られる——技術より先に「人との関係」から始まる、という話を真面目にしていてとても良かったです。
会場で無料で配られていた入門本でも、チームはもちろん、組織を超えて「コミュニケーションしよう」というメッセージが。
プラットフォームエンジニアリングとは、ベストプラクティスの集合体ではない
そして、このセッションで一番ぐっときたのが、
プラットフォームエンジニアリングは、ベストプラクティスの集合体ではない
自組織にとっての最適解を求め続けるための方法論
「これがベストプラクティスだ」と外から正解を持ってきても、本質を見失う、ということを直球で言われていました。
率直に答えはありません、と言われたことで正解はそれぞれの組織ごとに存在し、しかも時間とともに変わっていくことを感じ取れました。
また、社会的システム（人・組織）と技術的システムは不可分で、両者を同時に設計してこそ機能する——ソシオテクニカルという観点も紹介されていました（登壇者の肌感としては Socio 7：3 Technical くらい、とのこと）。
「正解を教えてほしい」という気持ちは現場にいるとよく分かるのですが、それを誰かに与えてもらうのではなく、自分たちで模索し続けるしかない、という姿勢が方法論の核なのだと持ち帰りました。
正直、突き放した言葉のように聞こえましたが、他にも、プロダクトを育てているという意識を持つことなど、当事者意識を育てる仕組みや文化づくりの話が前段にあったからこそ、この本質を見失わずに向き合う組織が強くなれるのだ、と確信を持てました。
同日午後の「信頼性か生産性か。」（SREキャリア論）も合わせて
Kusamaさんは Day2の午後にもう一つ、SREやPlatform Engineeringのキャリアに悩んでいる人に向けたセッション「信頼性か生産性か。キャリアに悩むみなさまに伝えたい、SREとプラットフォームエンジニアの選択肢」でも登壇していました。
印象に残ったのが、根っこに立ち返る問いです。
どうしてSREが必要とされたんだろう
流行り言葉に乗る前に、本当に SRE が必要なのかを立ち止まって考える。
「システムの複雑化」「安定性に対する要求」「クラウド化」「ベストプラクティス導入」——並ぶ仮説に、それぞれツッコミが入る構成。技術トレンドにそのまま乗らず、「自分の組織にとって、なぜそれが必要なのか」を立ち止まって考える——午前のセッションと通底するメッセージで、合わせて聞けたのは収穫でした。
4. 「うちにはまだ早い」は本当？─小さく始めるPlatform Engineering入門（アクセンチュア Haruka Sakiharaさん／Day2夕方）
Day2の夕方、アクセンチュアのHaruka Sakiharaさん（アソシエイトマネージャー）による「「うちにはまだ早い」は本当？─小さく始めるPlatform Engineering入門」を聞きました。Platform Engineeringというと、Kubernetesを使ったセルフサービス基盤を真っ先にイメージしがちです。
「Platform Engineeringを始めたい」となったときに現場がすぐぶち当たるのが、まさにこの 「Kubernetes じゃないとダメ」というイメージの壁——そして、この先入観こそが「自分たちには無理」という諦めを生んでいる、というのが出発点でした。
冒頭は「工数足りない問題」の生々しいあるあるから始まりました。
「Python 3.9のLambdaランタイムがEoLになる…うちはPython Lambdaばっかりなのに何てことしてくれやがったんだ（絶望）」
Python 3.9のLambdaのサービスを多く保守しているようなチームが、降って湧いたEoL対応などの「やらないといけない膨大なタスク」に追われて本筋の開発ができず疲弊している状況で、仕組みでどう向き合うか——という本筋です。
k8sなしでも作れる「画一基盤」
具体策として紹介されていたのは、
- 自作のAWS CDK Constructor を組織内で公開・importして使う
- サンプルリポジトリの提供（CI/CD設定や便利スクリプトが整ったものをforkして開発開始）
- AWS Config による組織ポリシー違反の自動検知・自動修正
「どこか一カ所に一律にまとめてくるオペレーションに対して統制を利かせる」——この発想は、Kubernetes に限らず、クラウド・SaaS全般に広げられそうだなと聞いていました。
自分たちだけでもできるPlatform Engineering
もう一つの柱が「自分たちだけでもできる Platform Engineering」。CNCFのPlatform Engineering Maturity Modelを引きながら、Level 0からLevel 1へ進むための小さな取り組みが紹介されました。
- Level 0「それぞれが好き勝手」 → Level 1「便利な設定を内部でシェアしよう」
- 積極的な自己開示——Daily Standup や夕会で、困りごとをチームに共有する
- 「XXXで困っているのは自分だけではない」という共通課題の発掘から始める
いきなり専任チームを作るのではなく、まず情報の集約から始めよう。Level 0から始められる、という前提が嬉しいセッションでした。
3つは連携して成熟する
そして、このセッションで一番持ち帰った言葉がこれです。
3つ（クラウドネイティブ・SRE・Platform Engineering）がばらばらに成長するのではなく、3つ連携して成熟するモデルです。どこかの成熟度Levelを上げたいのになかなかうまくいかないようなら、もしかしたら他要素がブロッカーかもしれません
クラウドネイティブ・SRE・Platform Engineeringは、それぞれ独立したテーマではなく、互いに足を引っ張り合うか、互いを引き上げ合うかの関係にある。これは、次の章で掘り下げます。
持ち帰った問い：自分たちはどこにいる？
ここまでのセッションを通して、頭の中に繰り返し浮かんだ問いがあります。
自分たちはいま、どのレベルにいるんだろう？
CNCFのPlatform Engineering Maturity Modelは、Level 1（Provisional）からLevel 4（Optimizing）までを定義しています。「小さく始めるPlatform Engineering入門」でアクセンチュアのSakiharaさんが示してくれたように、これは自社の現在地を振り返るための地図として使えます。
アクセンチュアさんのスライドでは、Platform Engineering だけでなく、CloudNative・SRE についても同じレベル感で並べて見せてくれていました。
| 領域 | Level 1 | Level 2 | Level 3 | Level 4 & 5 |
|---|---|---|---|---|
| CloudNative | Build：実装を理解し、開発・ステージ環境で試している | Operate：構築したシステムを本番環境に適用している | Scale：組織とシステムのスケールプロセスが定義されている | Improve & Optimize：ガバナンスポリシーを適用、決定をレビュー・再検討する改善プロセスが存在 |
| SRE | The FireFighter：障害対応にリアクティブに追われて本質的な改善には手が回らない | The Gatekeeper：本番デプロイの承認ロールを担う／ボトルネックになりやすい | The Advocate：SREの文化・プラクティスを組織内に啓発・普及する役割を担う | The Partner & Engineer：開発チームと対等な存在として設計段階から関与／組織全体にSREが定着 |
| Platform Engineering | Provisional：課題が生じるたびにアドホックに対応 | Operationalized：専任のチームによる共通化の促進 | Scalable：プロダクトとして認知され、利用者からの需要・FBが内発的に生まれ始める | Optimizing：使うのが当たり前でなくてはならない存在に |
出典: アクセンチュアさん「小さく始める Platform Engineering 入門」セッション資料より（Platform Engineering 部分は CNCF Platform Engineering Maturity Model を基にしている）
3つの領域を並べてみると、自分たちの組織の現在地が立体的に見えてきます。「Platform Engineering の Level 3 を目指しているけど、SRE はまだ The FireFighter だ」「CloudNative は Operate に来てるけど、SRE が Gatekeeper でボトルネック化している」といった見立てができます。
そして、「プラットフォームエンジニアリング、結局なにをすればいいのか？」のセッションには、この問いと重なる"あるあるネタ"も紹介されていました。
「『利用者のことを第一に考えていますか？』と聞くと、だいたい『あたりまえじゃないですか、開発者に役立つものをちゃんと考えて提供しています』と返ってくる。
『では、それはどこの部署の誰が言ってましたか？』と聞くと、『…』となるケースがとても多い」
利用者を考えているつもりが、社内の誰の声も聞けていない——これはクラウドネイティブ・SRE・Platform Engineering、どのレイヤーでも起きうる落とし穴です。
そして、アクセンチュアのSakiharaさんが投げてくれた問いとも重なります。
- 自分たちの組織は、本当に利用者を見ているか？
- ある領域で詰まっているとき、他の領域の成熟度がブロッカーになっていないか？
- Level 0→Level 1 の一歩を、止めているのは何か？
社内やチームの現状を鑑みるための糸口を持ち帰れたこと——それが今回の収穫でした。
会場の温度感
セッションの中身に負けず劣らず、会場の空気そのものも楽しかったです。
会場の中日ホール&カンファレンスは、名古屋テレビ塔を見渡せる街の真ん中。中日新聞社のビルの中にあり、入り口から中日ドラゴンズのマスコット・ドアラと目が合います。ちょうど新しい中日ビルが開業2周年とのことで、建物もまだ真新しくて、地方開催ならではの色が感じられる、良い空間でした。
会場の中日ビルは開業２周年！色んなドアラが迎えてくれました！
会場内では屋台が出店し、たこ焼き・おでん・おにぎりが配られ、コーヒーも振る舞われていました。なかでもコーヒーは、TECH WORLDさんの「うでコーヒー」プロジェクト——ロボットアームがハンドドリップでコーヒーを淹れてくれる初出展ブースで、いかにもクラウドネイティブ会議らしい仕掛けでした。
→ 後から調べると、Xでトレンドに入ったらしいです！
昼食やセッションの合間に時間を潰す場所があるのは長丁場のイベントではとてもありがたかったです！一人で参加していたのもあり、居てもいいと感じられる空間が用意されているのはたいへん助かりました。
そうそう、運営の方に聞いた話では、現場で「調理」する場合と、調理済みのものを温めるだけでは、必要な手続きのハードルがかなり違うようです。そういえばコンビニのスナックコーナーも、そういう仕組みのおかげで成り立っているんですね。
東京会場でも評判だったおでんが名古屋会場でも！
採用情報のホワイトボードはどんどん埋まり、メルカリ・Red Hat・Datadog・サイバーエージェント・PrimeNumber・ナレッジワーク・TDCソフト・Topotal・SHIFT・クラフトマンソフトウェアなど、コミュニティ内で広く採用が動いていることも面白かったです。
地元名古屋のコミュニティ「俺の勉強会」の”俺”とプリントされたTシャツ。目立ってます！開催地の技術コミュニティとも会えるのも地方開催の色が伝わってきます。
地元名古屋のコミュニティ「俺の勉強会」のブースや、技術書同人誌博覧会の立ち読みコーナー、Game Dayの実況など、企業ブース以外のコミュニティも参加されていて、運営と参加者とコミュニティの手で作られたイベントというのが伝わってきました。
懇親会も盛況でした。赤い法被の登壇者と、黄色い法被のスタッフが会場を行き交い、登壇者と参加者の境界が溶けていく時間でした。
スタッフの方は黄色い法被でした。イベント運営ありがとうございます！
懇親会ではクラウドネイティブ会議オリジナルラベルのクラフトビール（giftee 提供）もあり、セッション登壇以外にも、色んな企業の参加の仕方があるんだな、とびっくり。
会議オリジナルラベルのクラフトビール。giftee さんが懇親会スポンサーで、こんな形の関わり方もあるんだなぁと。
参加者の出身地マップを見ると、関東が圧倒的多数でしたが、近畿・中部や、九州・沖縄や海外からも人が集まっていました。「名古屋に、人・コミュニティが集まった」という感じがして良かったです。
参加者の出身地マップ。関東からが多いですが、色んな地域から集まってますね！
所感ですが、関東から来た人が多かったのはその通りで、私もその一角ですが、地域を離れて・日々の仕事を一度横に置いてイベントに参加するというのも、それ自体がいい振り返りの時間になったと思います。地元でのイベントではなかったこともあり、思いつきで来るのではなく、事前に調整して参加し、移動時間に情報整理する——その流れも含めて、とても良い時間になりました。
前日入りも含めて、テレワークの柔軟さがあるからこそ平日開催のイベントにも参加できました。所属している会社もワーケーションを推奨してくれているようで、こういう働き方を選べる時代の恩恵を改めて感じました。
おわりに：はじめの一歩を、一緒に
さて、2日間で出会ったセッションたちが、それぞれ違う角度から「小さく始めて構わない」と伝えてくれたように感じました。
- パナソニックエレクトリックワークス Masanori Maruokaさん・Shohei Konoさん・Hodaka Tashiroさん（Day1キーノート「老舗IoTクラウドサービス組織の変革 ──クラウドネイティブをはじめよう──」）：外部に頼っていた組織が、クラウドネイティブを共通言語にして、自分たちで動ける組織へ変わっていった軌跡
- GitHub Yuki Hattoriさん（Day2キーノート「境界を溶かすエンジニアリング ─ サイロを超える技術と文化のデザイン」）：「人間のサイロはAIのサイロでもある」——組織自体をエンジニアリングする、AI時代の視座
- PagerDuty Kazuto Kusamaさん（Day2朝「プラットフォームエンジニアリング、結局なにをすればいいのか？」、Day2午後「信頼性か生産性か。」）：プラットフォームエンジニアリングはベストプラクティスの集合体ではなく、自組織にとっての最適解を求め続ける方法論。午後の SRE キャリア論では「なぜ SRE が必要とされたのか」と原点に立ち返って考える話も
- アクセンチュア Haruka Sakiharaさん（Day2「『うちにはまだ早い』は本当？─小さく始めるPlatform Engineering入門」）：KubernetesがなくてもPlatform Engineeringは始められる、Level 0→Level 1への小さな実装
そして、もう一つの軸である「AI時代に人はどこに立つか」についても、2日間で受け取ったアンサーがありました。
- 境界を溶かす場所に立つ——AIエージェントは、人間が体験するサイロをそのまま体験する。だからこそ、組織の中の境界を見直し、サイロを溶かす視座を持つこと（Hattoriさん）
- 上流の意思決定と責任を握る場所に立つ——AIに任せられる作業は任せ、機械より早く「考える」こと、責任を取るのは人（Kusamaさん）
- 「小さく始める」場所に立ち続ける——AI時代でも、完璧を待たず、Wikiから、ランチから、READMEから半歩進む姿勢は変わらない（Sakiharaさん・Kusamaさん）
技術はAIで変わっていっても、「組織を変えること」「責任を取ること」「考えること」——この3つは、当面、人の領域として残るのだろうな、と感じました。
そして会場は、屋台・ドアラ・（登壇者・スタッフの）法被・出身地マップ・満杯の懇親会——技術カンファレンスの枠を超えた 「コミュニティのお祭り」 の熱気がありました。
そんな空気の中で——クラウドネイティブ・SRE・Platform Engineeringは、語られる文脈が大きいぶん、最初の一歩を踏み出すのに勇気が要る領域です。（推進しようとすると、ともすれば・大体は、組織に働きかけることになるので）このイベントに参加して、このハードルを少し下げてくれるメッセージに満ちていました。
- 完璧を求めず、Level 0からLevel 1へ
- 一人で抱えず、まず社内で共有する
- Permission Lessな環境を作り、半歩を踏み出しやすくする
- 自社の成熟度を、他の領域も合わせて立体的に見る
私自身も、そして、私が所属する組織も、まだ完成形にいるわけではありません。今回のレポートで紹介した問いは、そのまま自分自身に返ってくる問いでもあります。
むしろ、変化を楽しめる組織になれば、内向きにも外向きにも良い価値を発揮できるのだと思いました。そのためのはじめの一歩は、ちょっとしたドキュメントの整備——例えば、Readmeに今困っていることを書いてみる、いつものモヤモヤをチームミーティングで開示してみる——そんなあたりかもしれません。
今回の記事には書ききれませんでしたが、Day2のイオンスマートテクノロジー・Hikaru Saitoさん（DevSecOps Division/Director）による「1人目SREが開発組織のトポロジーを変えるまでの実践知」も強く印象に残りました。「組織を変える壁の多くは技術以外、対話と協働の積み重ねが鍵」「Win Session でお互いを褒め合う」というメッセージで、組織をマネージメントするポジションではない自分にも刺さる言葉がたくさんあり、推されていた Team Topologies を読み返したり、関連本を何冊か買い直したりするきっかけになりました。この感想は、別の記事でじっくり書こうと思います。
もし「はじめの一歩を踏み出してみたい」と感じてくださった方がいたら、どこかで一緒に話せたら嬉しいです。
最後に、運営の皆さま、登壇者の皆さま、そして会場でお話できた皆さま、ありがとうございました。またお会いできることを楽しみにしています。
Sun*は「誰もが価値創造に夢中になれる世界」をビジョンに掲げ、現在4カ国、6都市にて2,000名以上のエンジニアやクリエイターが在籍するデジタル・クリエイティブスタジオです。
Discussion