しがないプログラマの雑記帳

冴えないおじさんの、備忘録な雑記

フロントエンドカンファレンス名古屋 2026 に参加してきました

参加レポート

2026/5/9 に開催された フロントエンドカンファレンス名古屋 2026 に参加しました。
この記事では、一般参加者の目線で、当日の感想を書きます。

当日の様子

聴講したセッション

今回のフロントエンドカンファレンス名古屋 2026 では、以下のセッションを聴講しました。

本記事では、特に印象に残ったセッションについて記載します。

F8キーだけがバグる話 〜日本語IMEとフォームバリデーション設計〜

概要

ある日、クライアントからカタカナを入力すると文字が二重になるというバグ報告を受けたそうです。
実際に調査してみると、「ああ」を F8 キーで変換すると「ああアア」や「あア」のような変換の不具合が確認できたとのことでした。

まず前提知識として、日本語 IME やファンクション変換キー、変換の未確定状態 (composition) という概念とブラウザの composition イベントについて解説されていました。
また、 F8 キーで変換される半角カナと文字コードの歴史的な経緯についても説明されていました。

そのあと、バグ報告されていた現象がどの層によるものか、原因の切り分けをするためにログをとって調査されていました。
ブラウザのイベントログからデータの状態を確認して IM が原因と特定した後、どのような手順で再現されるかも調査して特定されていました。

最後には対処方法も紹介されつつ、 IM 起因によるものなので完全な対応は困難と結論付けられていました。
さらに、今回の調査結果から、 F8 キーだけがバグの原因ではなく、 IME の状態管理とブラウザの仕様と実装のギャップが根底にあるとのことでした。

感想

ファンクション変換キーに起因する日本語 IME のバグという、滅多に聞くことのないケースの話を聞けてとても良かったです。
そもそもファンクションキーを使って日本語を変換する機能があること自体を知らなかったので、良い学びになりました。

変換バグがどの層で起こっているのかという問題の切り分けをしっかり行われていたのも良いと感じました。
ブラウザのイベントログなどを確認しながら内部状態がどのようになっているか、そしてどのようにしてバグが再現できるのかを追っていく過程がとても興味深かったです。
このバグに限らず、奇妙なバグの原因調査をする上で、まずどの層が原因なのかなどの、問題の切り分けを自分でも行えるように意識していきたいと思いました。

また、デジタル庁が半角カナの利用を非推奨としていることも初めて知りました。
とはいえ、全銀データは半角カナを利用しており、簡単になくならないのは世知辛い話だと思いました。

発表全体の構成や話のつなげ方なども上手で、面白くて非常に引き込まれる発表でした。
今回のイベントで聴講したセッションで最も印象強く残りました。

「小さいVue.js」を30分でつくる

概要

30 分のセッション内で、実際に動く小さな Vue.js を作れることを実践されたトークセッションでした。
Vue.js の理解を促進するための文献として、 The chibivue Book というものがあり、このセッションでも参考にされていたとのことでした。

30 分で作る 小さい Vue.js は、以下の要素を実装する内容でした。

  • Vue インスタンスを作成するための createApp() 関数の実装
  • 仮想 DOM の定義
  • リアクティブ監視を実現する reactive() 関数の実装
  • Vue の template compiler の実装
  • Vue の SFC をコードに変換する処理の実装
  • Vite で自作の小さい Vue.js を動かすためのプラグインの実装
感想

小さい Vue.js を実際にトークセッションの時間内で作って動かせるところまで実演されていて、自分でも試してみたいと思えました。
筆者自身は chibivue の存在自体は知っていたのですが、手を付けられずにいたので、これを機に少しずつ手を付けてみたいと改めて思えました。

今回の発表では、必要最小限の構成要素だけでも単純な Vue.js のプログラムを動かせることを実演されていたのがとても良いと思いました。
Vue.js が内部でどのように動いているかの基礎を学ぶきっかけにもなりました。
Vue のプログラムをコンパイルするだけでなく、 .vue ファイルを扱っている点も良かったです。

全体を通しての感想

一日通して、色々と興味深いセッションを聞けて、とても勉強になりました。
ひとことにフロントエンドといっても、 Web 標準の仕様とブラウザの実装から、 JavaScript のフレームワークの話と非常に幅広い領域だとあらためて思いました。
初めて知る技術についての話や、ニッチな事例の話などを聞けて、とても良い刺激となりました。

また、名古屋の人にも、名古屋以外の人にも名古屋名物を食べてもらうために名古屋名物のお弁当を配るのもとても良かったです。
遠方から参加されている人にとっては手軽に名古屋名物が食べられるし、地元の人も地元の名物を食べる良い機会になったと思います。
ちなみに、筆者は名古屋コーチンのとりめしをいただきました。
とても美味しかったです。

外装のパッケージの写真お弁当の中身の写真
お弁当のとりめし

フロントエンドカンファレンス名古屋は今年が初めての開催となりましたが、非常に盛り上がっていると感じました。
去年は PHP カンファレンス名古屋が開催されて、今年はフロントエンドカンファレンス名古屋と、名古屋の IT コミュニティも盛り上がってきているような気がします。
愛知出身なので、名古屋のコミュニティも盛り上がっていくことを願っています。

最後に

フロントエンドカンファレンス名古屋 2026 の開催準備から運営までに携わられたスタッフの皆さんにこの場をお借りして御礼申し上げます。
登壇者の方々やスポンサーされた企業様ならびに出展されていた方々に御礼申し上げます。

皆様のおかげで、とても良いイベントに参加させていただけたと思います。
改めて、感謝申し上げます。

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

参加レポート

2026/4/11 に開催された PHPカンファレンス小田原2026 に参加してきました。
この記事では、会場の様子や感想などについて記載します。

聴講したセッション

レギュラートークは 3トラックの同時進行で、 LT は 1トラックでした。
本記事では、印象に残ったトークについて紹介します。

Webアプリケーションエンジニアにも知ってほしい オブザーバビリティ の本質

概要

Futoshi Endo さんによる発表で、最初に オブザーバビリティ とはどのような概念なのかを説明されていました。
ソフトウェアにおける定義としては、システムがどのような状態でも どれだけ理解して説明できるか を示す尺度とされています。

オブザーバビリティを実践する上では、以下が重要です。

  • システムに問題が発生する前からモニタリングし、問題発生時に原因をすぐに把握できる
  • システムの状態を誰でも把握できるようにシステム化されている

監視ツールのダッシュボードやシステムログが記録されていても、どのような状態になっているかが特定の誰かに依存していたら、オブザーバビリティを実践できているとは言えないとのことでした。

最近では、生成 AI がコードを生成することができるようになり、システムがどのように動いているかの仕組みを深く理解していなくても動かせるようになりました。
しかし、問題が起きた場合に、仕組みを深く理解していないことで原因の特定が困難になります。

AI を使いつつオブザーバビリティを意識した開発をするためには、人間と AI がそれぞれ得意なことの境界を明確にわけることが重要です。
特に、システムの状態を調査する上でどのようなデータが必要かの判断は人間がする必要があります。
オブザーバビリティの観点から実装やコードレビューをする際には、本番で失敗したときに、原因を詳細に把握できるかを意識することが重要とのことでした。

感想

オブザーバビリティがどのような概念なのか、本質をしっかり理解できて、とても良い発表でした。
OpenTelemetry のような監視ツールの名前を耳にする機会が多くなってきたので、興味があって聴講しましたが、そもそものオブザーバビリティの本質を理解することが重要だと感じました。

特に、システムの状態を 誰でも 把握できること、特定の人物に依存しないことがオブザーバビリティで重要という点がとても勉強になりました。
監視ツールを導入してダッシュボードを設置したり、ログをどれだけしっかり記録しても、それらを見て状況が把握できなければ意味がないことが自分の中で意識付けできそうです。
また、特定の人しか障害を解決できないと、その人が抜けた際に対処できなくなってしまうので、誰でも把握できることも重要だと共感しました。

レガシーPHP転生 〜父がドメインエキスパートだったのでDDD+Claude Codeでチート開発します〜

概要

登壇者 (プログラミングをするパンダ さん) のお父さんにソフトウェア開発を頼まれたことをきっかけに、実際にどのように開発を進めたのかについての発表でした。

まず開発を進めるにあたって父親にシステムに関する質問をしたところ、かなりしっかりとした仕様の返答をされていたそうです。
仕様だけでなく、その業務のドメイン知識もしっかり把握されていたため、実際の現場の業務フローも把握できたそうです。

当初は既存のシステムの改修と考えられていましたが、新規で作り直しでも良いということで、ゼロからの開発を AI を使って行うことにされました。
実際にやってみると、最初は開発スピードが速かったものの、段々と問題が発生して、理想とする開発にたどり着くのに苦労したようでした。

感想

登壇者の父親がドメインエキスパートだったというのがとても興味深かったです。
身内からソフトウェア開発を依頼されて、かつシステムの仕様やドメイン知識をしっかり説明できるというのがすごいと思いました。

また、発表全体としても聴講者が面白く聞けるように構成などを工夫されていて良いと思いました。
しっかりとした仕様が返ってきたときや、 AI を使って開発する上でぶつかった障壁など、ストーリーがしっかり構成されていて聞き入っていました。

全体を通しての感想

全体を通して、とても盛り上がっていたと思います。
2024 年、 2025 年の開催時も参加していましたが、今年も変わらず盛り上がっていて凄いなと思いました。
実行委員長の熱量を感じました。

今回の基調講演では PHPUnit の作者である Sebastian Bergmann さんがオンラインで登壇されていて、招待できたのがとても凄いと思いました。
また、スポンサーの人たちも聴講できるように時間を調整されていて、配慮が行き届いていて良かったです。

今回はスポンサーとして参加して、スポンサーブースで参加者の方々と話したり、トークを聴講したりと充実した一日になりました。

最後に

充実した一日を過ごせたのも、ひとえに運営スタッフの皆様のおかげです。
準備から当日の運営まで、お疲れ様でした。
この場でお礼申し上げます。

フロントエンドカンファレンス関西 2025 に参加してきました

参加レポート

2025/11/30 に開催された フロントエンドカンファレンス関西 2025 に参加しました。 この記事では、一般参加者の目線で、当日の感想を書きます。

フロントエンドカンファレンス関西の入口にあった看板の写真

当日の様子

セッション

基調講演

基調講演は「なぜフロントエンド技術を追うのか？なぜカンファレンスに参加するのか？」というタイトルで Sakito さんが講演されました。

概要

前半では、フロントエンド技術の流行を追うのではなく、「流れ」を楽しむことが肝要だと述べられていました。
現在フロントエンド技術で流行っている技術がなぜ誕生したのか、過去の課題とその解決策の歴史を追うことで、どのような課題を解決するための技術であるかを把握しやすくなります。
これまでの流れから課題を把握して、 課題にあった技術を選定する ために、フロントエンド技術を追いかけることが大切です。

後半ではなぜカンファレンスに参加するかについて述べられていました。
インターネット上に豊富な情報がある昨今でカンファレンスに参加するモチベーションは、ただ聴講するだけでなく、登壇者や参加者同士で登壇内容について議論できることが挙げられていました。
ドキュメントには「どのように使うか」については記載されていますが、 技術を現場に落とし込む「問い」について議論できる ことが、カンファレンスならではの魅力といえます。

所感

今回の基調講演を聞いて、フロントエンド技術を追う姿勢はとても参考になりました。
フロントエンド技術の進歩は非常に速く、流行をキャッチアップするのは大変ですが、なぜその技術が開発されたのかという経緯も把握することで、現在フロントエンド開発者がどのような課題を持っているのかを知る良い手段になりそうです。
過去と現在の流れを読みながら、フロントエンド技術の変遷を楽しめたら良いなと思います。

カンファレンスに参加するモチベーションについても、あらためて認識できたと思います。
カンファレンスだけにとどまらず、勉強会にも活かしていきたいと思います。

トークセッション

レギュラートークは 2トラックの同時進行で、 LT は 1トラックでした。
特にレギュラートークは、同じ時間帯でどちらも聞きたいと思えるほど興味深いセッションが盛りだくさんでした。

本記事では、最も印象に残った なぜ僕たちのNext.js導入はうまくいかなかったのか (登壇者: 奥山 聡 さん) というトークについて紹介します。

概要

現在携わられているプロダクトは PHP の巨大なレガシーコードで構成されており、フロントエンドは Laravel の blade を利用しており、開発に苦労することがあるとのことでした。
そのため、フロントエンドの開発体験を改善するために Next.js の導入に挑戦することにしました。

まずは影響範囲の小さいところから Next.js への置き換えからスタートされました。
ログイン画面など、最初のうちはうまく置き換えが進められていました。
しかし、 Next.js への置き換えを進めるにつれて、バックエンドの複雑さがフロントエンドに影響を与えてしまい、置き換えがうまく進まなくなっていきました。

今回の Next.js の導入がうまくいかなかった原因は、そもそもプロダクトとしてアーキテクチャの全体像が不安定なことだったと述べられていました。
まずはデータベースやインフラなどの全体的な土台をしっかり改善させることが重要とのことでした。

セッションの終わりには、今回の失敗経験から、以下が重要だと述べられていました。

  • フロントエンドをバックエンドの「蓋」にしないこと
  • 「開発体験」と「価値」を混同しないこと

今回の失敗から得た学びをもとに、まずはプロダクトのアーキテクチャを見直すところから始めることになったようです。

所感

自分が現在携わっている案件も、レガシーコードで構成されたプロダクトなので、とても興味深い内容でした。
特に、バックエンドの複雑さが起因して Next.js への置き換えを進めるのが困難になっていったことが、レガシーシステムをモダンな技術に載せ替えるのがいかに難しいかを実感しました。

プロダクトそのものの全体像がいびつな構造をしている場合は、可能であれば全体のアーキテクチャなどを抜本的に見直すことが大切そうだと感じました。
とはいえ、新規機能開発や既存機能のバグ修正など、優先すべきこともたくさんあるので、プロジェクトの都合に左右されるのも否めないのが難しいところですね。

スポンサーブース

受付の真正面にスポンサーブースが設置されていて、参加者が自然とスポンサーブースに訪れるような導線になっているのが工夫されていると感じました。
オープニング開始前から、すでにたくさんの人でスポンサーブースが賑わっていました。

昼休憩の間にスポンサーブースを一通り回って、スタンプラリーの景品抽選に参加したら、まさかの当たりを引きました (笑)
意外にも、最初の当たりクジが出たとのことで、スタッフの方もやっと当たりが出て一安心と言われていました。
自分もまさか当たりを引くとは思ってもいなかったので、とても驚きました。

全体を通しての感想

魅力的なトークがたくさん聞けて、非常に満足度が高かったです。
一口にフロントエンドといっても、 HTML や CSS のモダンな機能についてや、 JavaScript フレームワークなど、様々なトークを聞けて、とても良い刺激になりました。
フロントエンドという領域の広さを実感し、そして色々な技術について知ることができて良い機会でした。

イベント全体としても、とても盛り上がっていました。
たくさんの参加者がトークの聴講やブースでの交流などをしていて、とても多くの方々が今回のフロントエンドカンファレンス関西を楽しめたのではないでしょうか。

懇親会では、フロントエンドの勉強のために高知から参加しに来た大学生さんもいて、とても驚きました。
しかも、自力で開催情報をキャッチして、自主的に参加してきたとのことだったので、将来有望ですね。

過去にも関西でフロントエンドカンファレンスは開催されていたのですが、コロナ禍の影響もあり、一旦中断してしまいました。
今回は、新生フロントエンドカンファレンス関西としての出発点となったと思います。
開催テーマで掲げられていた「出会いが共鳴し、次の誰かを動かす」が参加者に響いて、今後にも繋がっていき、関西の技術コミュニティが盛り上がっていくことを願います。

最後に

フロントエンドカンファレンス関西 2025 の開催準備から運営までに携わられたスタッフの皆さんにこの場をお借りして御礼申し上げます。
また、登壇者の方々やスポンサーされた企業様とブース担当の皆様に御礼申し上げます。

VueFes 2025 に参加してきました

参加レポート

2025/10/25 に開催された VueFes Japan 2025 に参加しました。
この記事では、一般参加者の目線で、当日の感想を書きます。

当日の様子

まさかの寝坊

前日入りはせず、当日の朝に Keynote に間に合うように新幹線の予約をしていたのですが、まさかの 寝坊 をしました...
7:09 新大阪発の新幹線に乗るはずが、起きたら 7時でした...
幸いにも、 Smart EX で予約の時間をずらすことはできましたが、 Keynote には間に合わない時間でした。

目覚まし時計をかけたつもりが、設定が 1日分ズレてしまっていたようで、鳴っていなかったようでした。
去年は起きられたから大丈夫と油断したのが良くなかったですね...

聴講したセッション

Keynote には間に合わなかったものの、その後のスポンサーセッションの開始時間には間に合いました。
今回の VueFes Japan 2025 では、以下のセッションを聴講しました。

本記事では、特に印象に残ったセッションについて記載します。

webpack 依存からの脱却！快適フロントエンド開発を Viteで実現する

概要

開発のスピードを上げる上でボトルネックになっていたのが、開発サーバーの起動やビルドなどに時間がかかることが挙げられていました。
この課題を解決するために、 Webpack から Vite に移行 しました。
Vite の開発モードでは esbuild を使用しており、必要なモジュールのみが動的に配信され、高速に動作します。

Vite を採用する上で、公式で推奨されている Backend Integration を利用したとのことでした。
Backend Integration を利用するための設定について、コード例を交えて説明されていました。

Vite を導入したことで、ビルド時間などを大幅に短縮できたとのことでした。
具体的には、 Webpack では 90秒ほどかかっていたビルド時間は Vite では 12秒ほど に、開発サーバーの起動に至っては Webpack では約 90 秒かかっていたのが Vite では約 2~3 秒程度 までに短縮されていました。

感想

Vite が話題になり始めた時に、特徴の 1つとして高速であることが挙げられていましたが、今回の事例を聞いて 本当に速いことを実感 しました。
特に、 Webpack のビルド時間と Vite のビルド時間の比較結果は非常に大きな差で驚きました。
開発サーバーの起動やビルドを待たなければいけないのは非常にストレスなので、 Vite を導入してこれらの時間が短縮されて開発者のストレスもかなり緩和されそうだなと思いました。

アプリケーション開発を中心に携わっていると、ビルドツールなどの設定を意識することは少ないと思いますが、ビルドの仕組みやその設定についての知識はあった方が良いと感じました。
私自身は開発環境に関する知識が乏しいので、少しずつ学んでいきたいと思います。

Vueのバリデーション、結局どれを選べばいい？ ― 自作バリデーションの限界と、脱却までの道のり ―

概要

Vue のバリデーションを自作した場合、既にバリデーションルールが存在するかを知るには、バリデーションルールの実装を確認する必要があります。
しかし、バリデーションルールの数が増えれば増えるほど、調査に時間がかかってしまいます。
また、既存のバリデーションルールを活用できず、同じロジックの再実装が増えるといった問題点も挙げられていました。

そこで、バリデーションライブラリを導入することで上記の問題点を解決することを考えられていました。
Vue のバリデーションライブラリを導入する上で、候補を列挙した後、選定基準に基づいて導入するライブラリを絞り込んでいました。

必須条件となる 技術的前提条件 をクリアしているか、ライブラリの比較の上で重視する 評価指標 を定義し、ライブラリの選定が行われました。
結果として、 Vee-Validate を採用することになったそうです。

Vee-Validate を導入した後も課題は残っているようでした。
例えば、 Vee-Validate ですでに定義されているバリデーションルールが、自作のバリデーションルールでも重複して実装されていることがあります。
そのため、今後運用していく上で Vee-Validate のルールと重複して実装しているルールを見つけたら削除し、使用するバリデーションの実装で迷わないように徹底していくとのことでした。

感想

導入候補や選定基準をしっかり設けて導入するライブラリを決定していたのがとても良いと思いました。
候補を絞り込む際にも、 明確に基準を設けた上で絞り込んで おり、そこからさらに 選定基準も設定 されていて、しっかり検討されていました。

このセッションを聞いて初めて名前を聞いたものもあったので、とても勉強になりました。
また、選定基準に基づいてライブラリを比較することで、それぞれのライブラリがどのような特徴を持っているのかも知ることができました。

バリデーションライブラリの導入後も課題があったことから、問題解決は一筋縄ではいかないという現実も感じさせられました。
運用方針を定められていたので、徐々に課題も解決されていくように思いました。

オーディオアプリケーションをWebでつくる

概要

Web で音声を鳴らす方法として、 HTMLAudioElement を使う方法と Web Audio API があります。 音声ファイルを再生するだけであれば HTMLAudioElement だけで事足りますが、細かな制御を行う際には Web Audio API を利用します。 Web Audio API を使った制御の例として、 low-pass filter の実装例の解説とそのデモをされていました。

AudioWorklet を利用することで、ビルトインの制御だけでなくカスタムの音声処理も実装できます。
AudioWorklet の処理は音声処理用の別スレッドで動作するため、メインスレッドの処理の影響を受けません。
ただし、 AudioWorklet の処理を起動するためには、メインスレッドから addModule() が実行される必要があります。

また、 AudioWorklet で WebAssembly を活用することで、複雑な音声処理のパフォーマンスの向上が期待できます。
活用例として、 JUCE という音声アプリケーションの開発フレームワークを Web で利用する juce_emscripten などが挙げられていました。

感想

Web Auido API という音声を扱うための API の存在を初めて知ることができました。
具体的にどのようなことが出来るのか、デモで聞くことでより面白さが倍増しました。
私自身は音声処理については門外漢なので、 low-pass filter などの処理の知識はないですが、それでも触ってみたいと感じました。

Web Audio API の基礎概念である node については、実際に触ってみることで理解が深まりそうだと思いました。
また、 AudioWorklet が別スレッドで動くという部分については、 JavaScript のスレッドについてしっかり理解を深めないといけないと感じました。

全体を通しての感想

色々と興味深いセッションを聞けて、とても勉強になりました。
実際の活用事例を聞けたり、初めて知る技術についての話など、とても良い刺激となりました。
Keynote を聞き逃してしまったのが、本当に惜しいことをしてしまったなと思いました。

Vite をはじめとした、開発環境まわりのエコシステムなどについての知識がかなり浅いので、この辺りも徐々に学んでいきたいなとは思っています。
Rolldown や Oxc など、耳にしたことはあるけれど、それらがどういった役割を果たすかなどの知識がないので、話の内容を理解する上でも必須な知識をちゃんと身につけたいです。

英語のセッションも聴講しましたが、自分の英語の能力が足りないこともあり、ついていくことが難しかったです。
画面上に同時翻訳のテキストも出てはいたのですが、座った位置が悪かったのと、字を読むスピードが遅くて間に合わなかったので、次こそは聞き取れるように英語の勉強を頑張りたいと思います。
(英語のセッションを聞くたびに、毎回同じ感想を持っているような気もしますが...)

VueFes 2025 の会場も非常に盛り上がっていると感じました。
天気はあいにくの雨でしたが、セッションルームも立ち見になることがあるほどの盛り上がりで、熱量がすごいと感じました。
スポンサーブースも大盛況で、もっと部屋が広ければ良いな、と思うくらいどのブースもとても盛り上がっていました。

チケットが販売されていることに気づいたのが 9月頃で、その頃にはすでに懇親会チケットが売り切れになってしまっていたのが少し悔やまれました。
とはいえ、一般参加用のチケットの購入には間に合いましたし、参加して良かったと思いました。
今回の VueFes 2025 も大成功だったのではないでしょうか。

最後に

VueFes 2025 の開催準備から運営までに携わられたスタッフの皆さんにこの場をお借りして御礼申し上げます。
登壇者の方々やスポンサーされた企業様ならびに出展されていた方々に御礼申し上げます。

皆様のおかげで、とても良いイベントに参加させていただけたと思います。
改めて、感謝申し上げます。

PHPカンファレンス関西2025 のスタッフをしてきました

参加レポート

2025/7/18 ~ 2025/7/19 に開催された PHPカンファレンス関西2025 にスタッフとして参加しました。
この記事では、スタッフ目線での当日の感想を書きます。

前日祭

準備

前日祭の 7/18 は 13 時ごろに会場に集合して準備を開始ました。
平日 (金曜日) にも関わらず、コアスタッフと当日スタッフの 10 人以上が準備に参加していました。

主な作業は次の通りでした。

  • 参加者用トートバッグへの配布物封入
  • PHPer シールのケース詰め
  • スピーカーと個人スポンサー用の T シャツの配布準備
  • 前日祭トークルーム準備
  • 受付準備

前日祭の受付開始が 16 時からということもあり、準備に使える時間がタイトでしたが、 15 時ごろには参加者への配布物の準備は終わっていました。
かなりスムーズに準備が進められたのではないでしょうか。
そして、みんなでワイワイ作業してて楽しかったです (笑)

会場はかなりエアコンが効いていて、自分には寒いくらいでした。
上着を持ってきて正解でした (笑)

受付開始

前日祭は受付開始からそこそこ賑わいをみせていました。
金曜日とはいえ、平日の夕方だったので集客面が不安でしたが、杞憂に終わって良かったです。
セッションルームの様子を廊下から覗いた際には、そこそこ席が埋まっているように見えました。

準備とセッションルームで使っていた 3階はエアコンが寒いくらいに効いていましたが、 2階はエアコンが入っていないようでした。
冷えた体を温めるのも兼ねて、受付の様子を時々確認していました (笑)

前日祭終了

特に大きなトラブルもなく前日祭を終えられて一安心でした。
最低限の片付けをしたあと、会場近くで自分を含めて 6 名程度のスタッフで夕飯を食べに行きました。
そして、いよいよ明日が正念場だなとも感じました。

当日

受付準備

前日祭では、当日に使う部屋が一部抑えられなかったため、それらの部屋は当日の朝に準備が必要でした。
スタッフの集合時間は 朝 8:30 でしたが、私は宿を取らなかったため、 7:20 には家を出る必要がありました。
朝起きれるか非常に不安でしたが、ちゃんと起きられて良かったです。

一般参加者の受付開始が 9:30 からだったので、 1時間程度しかありませんでしたが、スタッフみんなで協力して、大きなトラブルはなく準備できました。

受付開始

受付開始直後は名札作成スペースでの滞留が少しあったものの、概ねスムーズに受付が進んでいたと思います。
特に大きなトラブルは起きていないようでした。

今年は前日祭を設けたこともあり、多少受付の負担を分散できたのかなと思います。
また、受付でのチェックインと PHPer シールの配布などの役割を分担することで、人が停滞する時間を少なくできたように思います。
そして、去年の経験をもとに、シール配布の改善も施されていたことも効いていたと思います。

午前中

杉本啓 さんの基調講演がオープニングの直後に行われるということもあって、午前からたくさんの参加者の方々が来場していました。
基調講演は今回の目玉企画のひとつだったので、たくさんの人に聴講にしてもらえて安心しました。

午前中最後のセッションのうち、 1つのトークルームでプロジェクターがなかなか映らないトラブルの対処が結構大変でした。
最終的には映ったものの、 25 分遅れての開始になってしまいました。

なかなか開始できなかったので、運営側では時間枠をずらすか相談していました。
運営本部とルームの状況を共有しながら、判断を待っていましたが、画面が映る方が先でした。
幸いにも、午前中最後のセッションで、 25 分遅れなら午後のセッション開始に影響しないので、そのまま進めることになりました。

トークの開始を待つ間、当日スタッフの こいほげ さんが場をつないで、ルームを盛り上げるアイスブレイクとなりました。
この日の一番のビッグファインプレーだったと思います。

ランチセッション

思ったよりたくさんの人が聞きに来られて、盛り上がりをみせていたようで安心しました。
また、ランチセッション用の軽食が結構豪華でびっくりしました (笑)
軽食の提供準備が少し大変でした。

昼休みにランチマッチングの企画が競合してしまっていたので、ランチマッチングの方は盛況とはいかなかったようです。
同じ時間帯に競合する企画を設定してしまったのは反省点ですね。

何はともあれ、ランチセッションは無事に盛況で終わって良かったです。

午後

午後は特に大きなトラブルもなくセッションが進められました。
並列 4 トラックでセッションが進行していましたが、特にトラブルもなかったように思います。

15 時半ごろから、スタンプラリーの景品交換も開始しました。
スタンプラリー企画にどの程度の人が参加するのか少々不安ではありましたが、多くの人にに参加していただけたようです。
景品交換の抽選も結構盛り上がっていました。

懇親会

本編の最中は運営業務でバタバタしていて、参加者の方々と話す時間があまり取れなかったので、懇親会ではたくさんの方とお話できて良かったです。
初めてお会いした方々にも、 PHPer シールをきっかけに話したりできたように思います。

時間が限られていたこともあって、ご挨拶できなかった方々もいたので、また別の機会にお声がけしたいなと思います。

全体を通しての感想

無事に開催できて良かったというのが大きな感想です。
そして、去年に比べて終わってからの疲労感もかなり大きかったです。

当日まで運営側では結構バタバタしていた印象でしたが、 X でイベントのハッシュタグを追ってみていた感じでは、イベントは成功と言えそうな感じでした。

開催に向けての準備でも直前まで結構慌ただしかった印象が強かったので、当日うまくイベントがうまく回らなかったらどうしようとやや不安でしたが、なんとか成功に収められて良かったです。
今年は、去年の開催ノウハウがあるから準備にそこまで苦労しないと思っていましたが、世の中そんなに甘くはないですね (笑)

午前中の映像トラブルはすごく焦ったこともあって、今回の運営で一番印象に残りました。
スタッフで貸し出せる PC を持っている人がいないか走り回ったのですが、 PowerPoint が入っている PC を持っているスタッフを探すのが意外と大変でした。
最初に声をかけた 4, 5 人くらいは MacBook で PowerPoint が入っていない環境でした。

これだけスタッフいて、「そんなことある?」ってなっていました (笑)
いや笑い事じゃないんですがね...

なんとか映像が映って開始できる状態になったときは本当にホッとしました。

開催準備も含めて、色々と反省点は多いので、しっかり振り返って来年に活かせられればと思います。

謝辞

今回の PHP カンファレンス関西 2025 の開催にあたって、忙しい中でも時間を割いて開催準備にあたっていただいたコアスタッフの皆さんに感謝いたします。
また、当日の運営の手伝いに参加していただいた当日スタッフの皆さんに感謝いたします。

今回のイベントのために登壇準備をしていただいた登壇者のみなさまに感謝いたします。
また、本イベントに向けてのプロポーザルを提出していただいたみなさまに感謝いたします。

イベントを開催する上で運営費用のサポートやブース出展の準備などにあたっていただいた個人スポンサーおよび企業スポンサーのみなさまに感謝いたします。

本イベントに興味を持っていただき、多くの方々にご参加いただきました。
イベントを盛り上げていただいた参加者のみなさまに感謝いたします。

最後に、運営開催に向けてスタッフを引っ張ってきた実行委員長の あかつか さんと、副実行委員長の かほ さんに感謝いたします。
そして、委員長のサポートに回っていただいた かのう さんに感謝いたします。

この場を借りて、今回のイベント参加者みなさまへの感謝を申し上げます。
ありがとうございました。