PHPカンファレンス小田原2026に参加してきました（登壇あり）

conference php bpf

PHPカンファレンス小田原2026に参加してきました。

登壇タイトルは 本番でPHPコードに触れずに「使われていないコード」を調べるにはどうしたらよいか？ でした、長いですね。

speakerdeck.com

ツールのレポジトリはこちらです、Usageのところにリンクしています。試される場合はDTraceが有効化されていること（ php -i |grep -i dtrace で、確認）を確認のうえ、対象のプロセスで USE_ZEND_DTRACE=1 が設定するようにしてください。READMEにsystemdの設定例を記載してます。

github.com

登壇について

無限にeBPFの話をしていますが、特にPHPerの皆様向けにアピールしていきたいという思いがあります、主なモチベーションはスライド最後のこちらです。

簡単にいうと「そこに便利に使えるものがあっても使う人がいなければ利用できなくなってしまう、もったいない」というか「自分も使いたいのでなんとかしたいなー」という活動です、まあでももちろんこういうの使ったら楽しい、というのが一番です、Just for Funでやってます。

2025年のPHP Sessionless Conferenceのワークショップの際に、使い所を色々聞いた結果、やはりデッドコード検知みたいなのがいいよね、ということでその後ebpf_exporterでメトリクス出すものを作ったりしていたんですが、切り出してlibbpfを使って専用のシンプルなツールを作りました。その紹介と背景技術の話になっています。

今回はじめてデモというものをやりましたがやはりトラブルは多少あるもののどうにか時間ぴったりくらいに終わることができました。

多少あわあわしてるところもあると思いますが、動画が公開されたらよろしければチェックしてみてください（一応デモ失敗に備えたスライドもあります）。

そういえば今回Ask the Speakerもあり、はじめてちゃんとAskしていただけたのも良かったですね。

04/13追記、Ubuntu/Debianパッケージ状況について

セッション後半で触れましたが、Ubuntuは24.04 Nobleの提供バージョンでDTraceが無効化されていてその後のリリース（25.04 Plucky）から有効化されています。

今月新しいLTS（26.04 Resolute）が出るので、こちらも引き続き有効化されたバージョンが入ると想定しています。

UpstreamのDebianのビルドと差分が出ているのでこれに合わせて再有効化提案も上がっています、こちらが取り込まれてくれると良いのですが。

オリジナルのバグレポ

bugs.launchpad.net

Debianへの再有効化提案

bugs.debian.org

参加セッションなど

偏った雑なまとめ

自分と同じぼこトラックで一つ前のきんじょうさんの「PCOVから学ぶコードカバレッジ」をpcov is 何という状態で聞いてましたが、コードカバレッジの話でzend_execute_exを捻じ曲げる話でもあり、母数を定義して割合を出す話であってあれーなんかこれ微妙にネタかぶってるでは、と思いつつ楽しくきいていました。

最近PHPerKaigiのArthurさんの話でもみたばかりで当日Mackerelさんのベースにもこれがあったので zend_execute_ex はとても大人気ですね、という気分になりました。新しい計装用の拡張ははObserver API使っていこうな。

個人的には技術による課題解決の話も好きですが、様子のおかしい話もまた好きなのでルータ作ったりMP3プレーヤーを作る話などを公の施設！という雰囲気で聞きつつ大変楽しく過ごさせて頂きました、ありがとうございます、PHPでなんでもできますね。

それはそれとしてキーノートもあまりいい感じに言語化ができてないんですがとても良いセッションでしたね、オンラインながらインタラクティブなやりとりがあり、トークも経験に根ざした話を丁寧にして頂いているな、と感じました。テスティングフレームワークの信頼性と責務ということを考えると色々思うところがありますね。

カンファレンス全体

「小田原の地でつながる、気張らないカンファレンス」というフレーズで看板に偽りなしの圧倒的にローカルな雰囲気で変な技術話を聞ける良い空間だったと思います。BGMと会場の雰囲気が強かった説があります。

昨年は自身がカンファレンスチェアやっていたこともあり、PHPイベントへの参加をしたいと思いつつもなかなかできず、なんやかやとピセカから1年以上経過していましたが、久々に現実世界でお会いした方々や、Laravel Live JapanのHamasakiさんとも色々とお話できたのでこれもよかったですね。来月のLaravel Live Japan参加もより楽しみになりました（LTもやります）。

ランチマッチングで出遅れてあわやソロになるかと思いましたが、お店の予想以上の混雑により引き返してきた組と合流できて昼も交流に成功してことなきを得ました。

懇親会も話に全振りをしてご飯少なくなりがちみたいな話をまさにしていたわけですが、今回については圧倒的な懇親会ご飯（舟盛りがあるぞ・・）を前に珍しく交流もしつつ十分食べたなあ、という感じになっておりました、しかも風呂がある、すごいですね。

雰囲気は全体にゆるいものの進行やアタック、特にFBまわりは作り込まれてるしオンラインのつなぎこみなどもあり運営面でも強さを感じました、スタッフの皆様本当にありがとうございました！

DTraceの有効化状況調査2026

Debian 13

$ uname -a
Linux ip-10-111-17-182 6.12.48+deb13-cloud-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.48-1 (2025-09-20) x86_64 GNU/Linux

$ php -v
PHP 8.4.16 (cli) (built: Dec 18 2025 21:19:25) (NTS)
Copyright (c) The PHP Group
Built by Debian
Zend Engine v4.4.16, Copyright (c) Zend Technologies
    with Zend OPcache v8.4.16, Copyright (c), by Zend Technologies

$ php -i |grep -i dtrace
DTrace Support => disabled

Amazon Linux 2023

$ uname -a
Linux ip-10-111-17-229.ap-northeast-1.compute.internal 6.12.68-92.122.amzn2023.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Feb  9 10:43:10 UTC 2026 x86_64 x86_64 x86_64 GNU/Linux
$ php -v
PHP 8.5.1 (cli) (built: Dec 16 2025 15:59:07) (NTS gcc x86_64)
Copyright (c) The PHP Group
Built by Amazon Linux
Zend Engine v4.5.1, Copyright (c) Zend Technologies
    with Zend OPcache v8.5.1, Copyright (c), by Zend Technologies
$ php -i |grep -i dtrace
DTrace Support => available, disabled

Alma Linux 10

$ uname -a
Linux ip-10-111-17-81.ap-northeast-1.compute.internal 6.12.0-124.8.1.el10_1.x86_64 #1 SMP PREEMPT_DYNAMIC Tue Nov 11 11:41:04 EST 2025 x86_64 GNU/Linux
$ php -v
PHP 8.3.29 (cli) (built: Dec 16 2025 14:32:42) (NTS gcc x86_64)
Copyright (c) The PHP Group
Zend Engine v4.3.29, Copyright (c) Zend Technologies
    with Zend OPcache v8.3.29, Copyright (c), by Zend Technologies
$ php -i |grep -i dtrace
DTrace Support => available, disabled

2025

※年末なので振り返り自分語りエントリです、特に技術的に有益な情報などはありません。

似たような書き出しで前に書いたのがちょうど5年前で、これを振り返りつつ自分のために書いて参ります。

dasalog.hatenablog.jp

これみると我ながら同じことやってるな・・という気持ちと、お前それで5年後にSRE NEXTのチェアやって年末にはBrendanGreggが新橋でホッピー飲んでいる会に参加しているぞ、というとても自己完結した趣がありますね。

試しに以下大項目を揃えていってみる。

SRE NEXT

2020-2025でSRE NEXTは5回開催され、登壇4回、スタッフ2回でうち1回がCo-Chairとなりました。

2025の前半は完全にこのイベントにフォーカスして過ごしてきたので、さすがにやりきったなあ、という思いです。

このあたりは別途ブログを書いてるのでまあまあ蛇足というとこなんですが、Brendanさんのキーノートについて、やはりITの世界の歴史はまだ浅いし自分たちの考えるスーパーエンジニアも普通に活動していて、会って会話をすることができるのだ、というところですね。

コミュニティの力を使うことで達成できるというのも素晴らしいですし、なんとなく遠くの自分とは関係ない出来事みたいに捉えてしまうのは気持ちとしてはめちゃわかるがそれもなんだかもったいないことかもしれないよね、できることもありますよ、というのが提示できたという意味でもよかったんじゃないかなと思っています。

あと少し違う軸として、カンファレンスの規模をみても日本のSREコミュニティは世界的に見ても結構大きいんじゃないかと思っていて、このあたりの接続点がもう少し持てたらいいんじゃないかなあ、などとも思ったりしたところです。

（公開後追記）あとこれお金もそれなりにかかるし気軽に言う事ではないのだけど、SREconにエンジニアを参加させる日本のIT企業もう少しあってもいいんじゃないかなとも思ったりもしています、たとえばre:Inventにはかなり多くの日本の方が参加されてますし、予算がまったくないわけでもないよなあとか。（追記ここまで）

2026はスタッフとしては参加しませんし先のことはわかりませんが、SRE NEXTは5年を通して自身にとっても圧倒的に大事なコミュニテイとなったので、またいずれなんらかの形で関わりたいなあという思いはあります、まあでもいったん小休止です。

SRE NEXTではないけど今年最後にいつか行きたいと思ってたゆるSREにもなんとか参加できてこれもよかったですね、小規模なミートアップの密な感じはとても良い、なんらかジャンル問わず近場のなにかもいいかもなあ。

英語

2020年から色々やったが、なんやかやとレアジョブは継続していて本日時点のレッスン回数が1739回、レッスン時間は869.5時間となっている。どちらかというと維持するためにダラダラやっていて全然ストイックにはやっていないがトータル少しずつマシにはなってそうではある。

英語喋れる/喋れないみたいな二値に倒すときは自分は意図的にtrueで返していて、まあそれはいいのだけど、目指すべき状態に対しては明確に足りない（まあおもにListeningとかPhrasal Verbsみたいな言い回しのストックとか、根本的な語彙の不足とかそのあたり）というのはわかっており、レベル的にいうとCEFRでいえばだいたいB1の上かB2の下の方が現状でB2の上の方、C1はいらんやろ、くらいに思っている、けどそこの差分はまあまああるなーという感じ。

別に自分は字幕なしで映画がみたいわけでもなく、世間話もそんなにできなくてよくて、単に技術的なセッションやPodcastをストレスなく聞けてそれについて話せるとか、まあそういうジャンル特化なので引き続きやっていこうと思います。

しかしまあ会話がメインなので副産物として子育ての語彙とかは増えたなあ。あとフィリピン事情に少し詳しくなったのでいつか行きたい。

使い所としてはことしまあ所属先のおかげもあり、国際カンファレンスにもいくつか参加して（SREcon25 Americas、KubeCon + CloudNativeCon Japan 2025、Open Source Summit Japan）あともちろんSRE NEXT 2025とGrafana関連のイベントなどでまあまあ喋る機会があり、まあ良かったなと思うと同時にもうちょっとどうにかーという気分にもなり、という感じ、まあでも多少下手くそでもオープンな場でQAできるくらいのメンタル的な図太さができたのでそこはよかったでしょう。

自動翻訳の進化みたいな話もあるけど、特にSREConのディスカッショントラックなんかはそんなことしている余裕はまったくないので結局普通のテンポで普通に話ができるという価値はしばらくなくならないんじゃないかと思います、次の5年後、もう40後半に入ってしまうけどもうちょっとマシな状態がここに書けてるといいですね。

技術方面

2020年からめちゃくちゃ進歩したかというとまあそんなことはないが、コミュニティ運営に入ったこともありしつこくeBPFを続けたり今更ながらlibbpfと仲良くなろうとしていたり、オブザーバビリティとの接続点のところがはやり面白いのでOBIあたりを追ってみたりという感じで引き続きやっている。OTelは周辺技術ばかりみてきたけど、お仕事的にもまじめに取り組みはじめたので遅まきながらやっていきたいところですね。

子供が生まれて明確に可処分時間が減っているが、まあしつこくやるのが性なのでやっていきましょう。

その他

特に大きな病気はしていないがマイナーな不調が出てるので健康の優先度が一番高い、色々試みはしたものの一回崩れると立て直しにだいぶ時間がかかるようになったので、ここは本当になんらか取り組んでいく所存。

（特に関係ないどこかの写真で締め）

Grafana CloudとNASで自宅のインターネット速度を計測する

この記事は Grafana Advent Calendar 2025 の 4 日目になります。

小ネタですが空いていたのでやっていきます。

自宅はマンションで回線はフレッツ光ネクスト、プロバイダも固定で管理費込みといった環境なのですが、ある頃からPPPoEで通信しているv4側が耐え難いほど遅くなり、紆余曲折を経て現在はプロバイダを追加契約し、transix IPv4接続（固定IP）を利用しています。

元の状態からするとだいぶマシになったのですが、環境や構成の変更により結局どの程度速度が変化したのかを継続的に計測したいと思い、設置しているNAS（QNAPのTS-262）を使いGrafana Cloudに定期的にメトリクスとして送ることにしました。

Internet Speed Dashboard

https://egmc.grafana.net/public-dashboards/62f903fe5b2042e98410dac48e2c5854

予測値をいれてみたり一週間前の比較を入れてざっくり傾向をみたりしてます。

設定など

QNAPのNASにはContainer Stationというコンテナマネジメントが行えるソフト1が付属しており、Docker Hubなどの任意のコンテナレジストリからコンテナをpullして実行できます。

これを使って、speedtestを実行するexporter（speedtest_exporterでいくつかバリエーションがありますがいずれも Speedtest by Ookla - The Global Broadband Speed Test を実行して結果をメトリクスで返すもの）をコンテナで起動し、スクレイプ先のportに対して、別で立ち上げたPrometheusのコンテナからスクレイプします。

configはホスト側においてマウントし、Overrideして読むように

そしてGrafana CloudのHotsted Prometheusに対してRemote Writeする設定を入れればOKです。

global:
  scrape_interval:     1m
  evaluation_interval: 30s
scrape_configs:
  - job_name: 'speettest'
    scrape_interval: 35m
    scrape_timeout: 5m
    metrics_path: "/probe"
    params:
      script: [speedtest]
    static_configs:
    - targets: ['{local ip}:9469']
    metric_relabel_configs:
    - source_labels: [__name__]
      regex: "^(promhttp_|go_|process_|prometheus_|http_).+$"
      action: drop
remote_write:
- url: https://prometheus-blocks-prod-us-central1.grafana.net/api/prom/push
  basic_auth:
    username: {user}
    password: {pass}
  queue_config:
    min_backoff: 10s
    max_backoff: 8h

設定的には抜粋するとこんな感じで、speedtestをあまり叩きすぎるのもあれなのでscrape_intervalは適度に手加減しましょう。

この構成の良いところは、メトリクスの送信がRemoteWriteによるpushになるので、外部へのポート開放などが必要ない点です。

最近ネットワーク機器を諸々入れ替えたのですが、SNMP Exporterでメトリクスを取得したりOtelでLokiにログを送信するみたいなこともできるようになってきたので、自宅のネットワーク監視も同様にやっていきたいですね。

  1. 使ったことはないのですがSynologyのNASなどにも同様の機能がありそうです↩

Observability Conference Tokyo 2025に参加しました

conference

クイック参加記事（※技術的な話は特にない）です。

o11ycon.jp

個人的な背景として今年は前半カンファレンスの運営をやっていたために（あとまあ家庭的な話もあり）かなりそれに合わせて参加イベントを絞っていたので、このカンファレンスについては純粋に参加して楽しみたいという気持ちで朝から参加させていただきました。

結果的にセッション聴講を適度にしつつ、登壇者のQAやその他の会話で現地の体験をしつつなかなか満足度高く過ごせたなーという感想です。

セッション

Affordable Observability: Strategy to Implementation

Liz Fong-Jonesさんによるキーノート。

Observabilityの価値的な大枠の話から具体的なサンプリングの手法、組織への展開までの話がよくまとまっていて良いセッションでした。

QAの時間も充実していて、自身の質問（障害時にサンプル対象が増えた場合の対応的な話）も拾ってもらい大変よかった。

オブザーバビリティが育む開発者のシステム理解と好奇心

maruさんの、個人的今回のベストセッション。

開発、運用でのメンタルモデルの違いの話から、継続的な負荷試験の仕組み整備から組織へのデプロイ、アラートの話まで、全体として身も蓋もないが自分とこであまりうまくやれてなかったり半ば諦めたりした内容が詰め込まれていて、やらんとねえ・・という気持ちになったのが大きいですね。継続的なパフォーマンス計測というのをやりたい気持ちが再燃しました。

アラートのコード管理まわりは一応自社でもやってるので（よくできているかはさておき）、どこかで機会があれば書こうかなとは思います。

その他雑多に

サイン会とか

著者から翻訳者まで一気にサインしてもらえるというよく考えたら豪華な会でしたね。

個人的にLizさんは物理で見るのは3回目で2019年のSREcon19Amricas（Chairをしていた）、今年のSREcon25Americas（Observabilityのディスカッショントラックをホストしていた）、そして今回だったわけですが、短い時間ながらはじめて会話できてしかもそれが日本というのもなんだかすごいですね。

運営

今年自身も運営をやっていたのもあり、「3ヶ月で？スポンサー集めてCfPやって配信もNOCも翻訳もあり？キャラクターやグッズまで作って？」とよくわからないがすごくてすごい、全体としてスムーズに運営されていてすごいというかちょっと怖いなあという感想です、大変お疲れ様でした、ありがとうございました！

オブザーバビリティやっていかんとねえ・・、といいつつeBPFのOTel自動計装とかそういった方面をつい眺めがちでおります、ここは興味関心の接続点なのでちまちまやっていきたいですね（いやOTelもまずひととおりやるべきなのだが）。

SRE NEXT 2025でeBPFの話をしました

sre conference

登壇編です。

スタッフ、チェアやった編はこちら。

dasalog.hatenablog.jp

SREのためのeBPF活用ステップアップガイドというタイトルでお話しました。

speakerdeck.com

写真ありがたい。

2023チェアのぐりもお (@gr1m0h)さんに「チェアと登壇同時にやるとやばい」と聞いてましたがかつてなく準備がギリギリになって焦りましたがなんとかなりました。 娘がとあるモールの施設で妻と遊んでいる間にサイゼに籠もって作業するなどのフェーズを挟むことによりなんとか間に合いました。

今回初の30分枠で（自分たちでそう設計したからね・・）いつもより10分多いやったーと思っていたら前日ようやく出来たリハで3分オーバーしていて、しかし削るところはもうないしスピーカーノートを追加してなんとか喋りを間に合わせようとしましたが結局少しオーバーしてしまいましたというのが反省点です。途中息切れしてきて一息つくべきところを水飲んでる時間もないなーと思って無理やり進めたので最終的にめっちゃ息切れしたのも反省点です。アーカイブをみるのが怖い、聞き苦しくなかったかやや心配しております。

あと資料あげようとした段階でこれタイトル間違ってないか？ということに気づきました、これもアーカイブが怖い、活用が正しいです。

最終コミットの差分

発表について

内容自体は自分のやってきたeBPF関連のあれこれ全部のせという感じのものを難易度順に並べてステップアップガイドとして仕立てた感じになっています。

実際に使えた、使える事例にすることが優先事項で、事例自体はちょっと古めのものが入っているんですがなるべくコンテキストを追加して意味がわかるようにしようとしています（したつもりです）。

SRE NEXTにもeBPFの発表とか欲しいよね、と長らく思っていたのですが結局自分でやることになりました。

なんというかeBPFに関して自分よりももっと技術的に高度な話ができる人はたくさんいるので、SRE NEXTの場で話してもらうのもそういう人たちがいいんじゃないかと思ってたんですけど、昨年末からeBPF Japan Meetupの運営入りをしたり、流れでたまたまちょっとしたPRやバグレポを上げたりしてみた結果心境の変化があり、もっと認知や普及に取り組んだほうがいいんじゃないか、高度な事例じゃなくても現実にSREの役立つのだよ、ということを伝えていこうということで、この内容でProposalを投げました。

それこそBrendanGreggが話すのに自分がeBPFの話をする意味とは、というところなんですが考えてみればそれはSRE本があるのに無限にSREをしている我々と似たようなもので、現実世界での事例があれば解像度が上がりますし、Fast by Fridayの末端の一つの例くらいになればいいでしょう、という感じです。これスライドに書けばよかったですね・・。

当日

人の入りは割と心配してたんですが、おかげさまで（いや本当に）たくさんの方に聴講いただけました。

いくつか個人的にありがてえ、と思ったポストを貼っておきます。

あ、やっぱ利用って書いてますね・・。

死ぬほど詳しいガチ資料でおすすめです。

やっていきに繋がったらありがたい。

あとこれがめちゃ嬉しい、概要はこれみたらわかります。

Ask the Speaker

よく考えたら人生初のAsk the Speakerだったんですが、セッションに来てくれていたBrendanさんとそれに気づいて英訳を流してくれていた @inductorさんと（これもありがた） @logica0419 さんと4人でふつうに喋ってました。Askは一回もされてない。自分もまだ聞きたいことがあったのでAskしてました。よかったです。そういうのもあります。

ということで

eBPFの話でした。

そもそも自分がeBPFの存在を知ってツールを触り始めたのはBPF Perfomance Toolsを読んだからであり、半分は個人の趣味としてちまちまと続けてきた結果を少しまとめられたのはよかったのではないかと思います。

世は大コンテナ時代なんですが、ツールまわりもうちょっと整備したいですし、なにかがしかまた有用な事例が出せたらいいなあと思っております。

Photo by SRE NEXT Staff

SRE NEXT 2025でCo-Chairをやりました

conference sre

前回

dasalog.hatenablog.jp

書くことがたくさんある気がしていてどこから何を書いていいのかわからない。

普段あまりこういう事は書かないのですが、思った以上に良いカンファレンスになったな・・と思ってます。反省点は山程ありますし、やらかしもたくさんあるんですが、それでもこの良さは両立するな、という気分です。自分は何もうまくやっていないのに「なんか気づいたら想定以上の状態になっててみんなすごい・・」という感じです。すごいですね。

みんなという抽象度高すぎてなんだかふわっとしてしまうわけですが、スタッフ（コアスタッフ、当日スタッフ、NOCの皆様）だけでもないしスピーカーの皆様だけでもないしスポンサーの皆様だけでもないしイベントブースの方も来場者の方々も・・・となるともうみんなとしか言えないというのが学びポイントです。

BrendanGreggさんが来ました

BrendanGreggを呼んだ！というとなんだか自分がやったみたいな感じであれなんですが、もちろんそんなことはなく、こちらも協力頂いた皆様のおかげで実現しました、本当にありがとうございます。人生の目標が一つ達成されました。

基調講演で話して頂くだけではなく、自分含め参加者との交流を取っていただいてホスピタリティが素晴らしくありがたさに感動しました。

サイン会は電子書籍OKにしたのですが大半の人は物理本を持っていて、初版から原著までバリエーションがあり、こんなに様々な詳解システムパフォーマンスが一堂に会することは二度とないんじゃないかと思います、全部で何キロあったんでしょうね。自分は初版とBPF Performance Toolsをそれぞれ持って二版を紙で追加購入しました。

講演の内容、（単なるファン的な話はさておき）　SRE NEXTという場に呼ぶことの狙いについては一応少し思惑があり、現状のコンテナ隆盛の時代において複雑なパフォーマンスの問題の調査を素早く行うためにはこれ（ツール、メソドロジ）が必要である、という視点は良いディスカッションのもとになるんじゃないかと思うなどしていました。

ディスカッションイベント「Talk NEXT!」

インタラクティブなコンテンツやりたい、ワークショップとか、みたいな話をしていましたがこの形になりました。

一応形式的にはSREconのディスカッショントラックを参考にして、Breakout Group Discussionの形式を4テーマ同時にやろう、ということ説明スライドなどもせっせと作ったんですが（そして実際その通りに進行はしていただいたんですが）気づけば人はたくさん参加しているし、ルール説明もそこそこに練度の高い参加者自身がいい感じに進行していてなんだこれはすごいな、と感動しました。

netmark.jp

馬場さんがはやくもオブザーバビリティのところを書いてくださっております。

今回やや控えめな開催にしているのは意図していてカナリーリリース的な思惑もあったんですが、やってみた結果もっと踏み込んでも全然いけたな、と思いました。

スピーカーディナーイベント

公募セッション(30分)のスピーカー、ゲストスピーカーの方々を招いてコアスタッフとクローズドなディナーイベントを初開催しました。

実施タイミング的に正直負荷もあるものの、スピーカーの目線でもスタッフの目線でも持続性の観点で良いんじゃないかと思い今回初開催してみました。自分としては大変よかったと思っているのですが、参加された方の感想をきいてみたいなーと思います。

スタッフ

プログラムとディスカッションイベントのことを主にやりつつ、英語圏サポートを少しいい感じにする対応などをやったりしてました。

招待講演の方は川崎さんはじめチームメンバーのみなさんのおかげで、なんと打診させて頂いたみなさますべてに快諾頂き（調整ありがとうございます本当に）ました。

おかげさまで多様で豪華なセッションにになり最高でした。

zenn.dev

CfPは例によってめちゃ大変だったんですが、応募された方も大変だったと思います（ありがとうございます）。今回クロージングでも少しお話した通り大枠のフレームワークは踏襲しつついくつか変更を加えました。

地味にメール送信まわりを改善したり、受付のSlack通知を改善したりと多少コード書いて成果があがったのはよかったですね。

Co-Chair

人はチェアになったからといって急に練度があがるわけじゃないのだけど、ある程度ロールが人をつくるみたいなところもありますね・・、ということでなんとかやってた1年でした。

チェアとしての責務は意思決定が多めになるので、「SRE NEXT自体の持続性の観点ではどうか」を一つの基準としてアレコレ考えて判断する、わからんことは積極的におまかせしよう、方針はなるべく言語化しよう、のスタンスでやってきました。

おかげさまで（本当におかげさまで）2歳児（途中で3歳になったけど）がいてもチェアは一応できる、ということで実績解除したと思います（いやこれ皆それぞれ家庭の事情はありますし特段大変アピールするのもあれなんですが個人としてはそれなりにやはりいろいろありはするのでー、という）。

開催一週間前に胃腸炎が発覚した時は一瞬死を覚悟したけどなんとかなりました。よかったですね。

Co-Chairの部分は個人的にめちゃ重要でこれはちょっと一人は無理でした、前チェア陣からのフレームワークの受け継ぎと渡部さんとの分担でどうにかなりましたね。

人ってこんなに感謝の気持ちが出るだってくらい感謝の気持ちしかないです

ryuichi1208.hateblo.jp

いやそうなりますよね、と言いつついったん締め、登壇の話はまた別で書きます。