日本のインフラにはどの地域にも利用できる公民館，あるいはそれに準じた公営施設が存在します．イベント開催側として利用したことはあるでしょうか？
　
日本には 1,741 の市区町村があり，それぞれの地域毎に異なるルールで運用される公営施設があります．特にすばらしいポイントは住民に開かれた施設であり，利用料が同様の民営施設に比べて安価，あるいは無料であることが挙げられます．一方で民営施設と異なるルールがあったり，技術系勉強会の開催においては不利になる設備状況であったりと，開催に踏み切るには心配な点があることも拭えません．
　
そこで，過去私が開催してきた公営施設での勉強会で感じた，様々な嬉しポイントや悲しポイントをふんだんに紹介します．みなさんが住まわれている地域の公民館に興味を持っていただき，安価に勉強会やカンファレンスを開催する一つの選択肢として感じていただけることをめざします．

うどん作りは大変で難しそうとのイメージが先行していませんか？
うどん作りに必要な原則を押さえ、実践に必要な情報を得ることで、ご家庭で「手軽に」「再現性を持った」「美味しいうどん」を作ることができます。
本トークでは登壇者の経験に基づいたうどん作りのための情報をお伝えします。

「カンファレンススタッフってどんなことをしているのだろう...」「当日スタッフに興味があるけど、私にもできるのだろうか...」
そのように感じている方もいらっしゃるのではないでしょうか？

私は2025年から約7回スタッフとしてカンファレンスに携わりました。
当日スタッフとしてカンファレンスに携わる中で、下記の2点を感じるようになりました。

・PHPカンファレンスにスタッフとして携わることも、PHPコミュニティに寄与する一つの方法である
・当日スタッフは「手軽に」コミュニティへ携わリ始めることができる

このLTでは、私のカンファレンスのスタッフ経験を通して、カンファレンスに当日スタッフとして携わることが、手軽にPHPコミュニティに寄与する手段の一つと考える理由をお伝えします。

⚪︎話すこと
・カンファレンスの当日スタッフとは何か
・私のカンファレンススタッフ経験
・当日スタッフが手軽にPHPコミュニティに寄与する手段の一つであると考える理由

このLTを通して、「カンファレンスに当日スタッフとして携わってみよう！」と思ってくださる方が一人でも増えてくださると嬉しいです！

※下記のLTをベースに内容を再構成、ブラッシュアップしたものを発表します。
https://speakerdeck.com/kousukeosanai/kanhuarensusutatuhuyatutemiyou

積極的に管理したいわけではない、出来るだけ手軽に管理したいサイトやサービスはありませんか？

そんな時にオススメなのが、Amazon Lightsailです。

Lightsailを使えば、定額で仮想サーバーを立てられます。様々なブループリント(初期状態)があり、PHPが予めインストールされたサーバーもあります。

EC2では1から必要なプログラムをインストールするのが大変、Lambdaでは結局いくらかかるか分からなくて心配、という方には手軽で安心な良い選択肢になります。

個人開発はデプロイできるとより楽しいものです。Lightsailでお手軽デプロイを試してみませんか？

本を読んでいますか？

良き本との出会いは一期一会であり、
もしかしたら次にあなたが読む本は、あなたの人生を強烈に変える1冊かもしれません。

本を読むためには、「買う」「借りる」「読み放題サービス等を使う」といった手段があります。
その前には、「探す」「出会う」といったステップがある訳です。
言い換えれば、必ず何かしらの「アンテナに引っ掛ける」アクションが必要です。それが、良書と出会う確率を高めるでしょう。

🌟LTのポイント①
では、どのように良さそうな本と出会うのでしょうか？
LTの話者自身が実践していること、周囲の人から聞いたことをベースにして
実践方法とポイントを共有します。

うまくアンテナを広げて引っ掛けられるようになると、「出会った本」「読みたい本」は増えていきます。
必然的に、「読みたい本と読めた本の比率」も変わるでしょう。
良き付き合い方を見つけてくいく必要があります。

大事なのは、「全ての本を、同じ濃度で読み切る必要はない」「途中で読み方を変えても良い」「将来また読み直しても良い」という点です。
これにより、「積読」を「不良在庫」化せずに、意味のある付き合い方を目指しやすくなるでしょう。

🌟LTのポイント②
その本を手にした動機があるはずです。
「じっくり読みたい」「ある事柄について知識を補いたい」「有名な言説の出自を抑えておきたい」など。
それに基づき、「読み方や使い方を変える」「読み出すタイミングを変える」といった戦術を実行します。

【対象】

• 技術書やビジネス書といった実用書を想定しています
  • 文芸作品等は対象外です

【話さないこと】

• 増えた本をどう収納するか
  • 研究中であり、今のところプラクティスと呼べるものが全く体得できていません

開発者は毎日ターミナルを叩いています。その中で「ちょっとしたコマンドの短縮」が積み重なると、驚くほど作業が楽ちんになります。
このトークでは PHPer が日常的に使うコマンドを中心に、 .bashrc / .zshrc などに登録しておくと開発効率が高まるエイリアスやコマンドを紹介します。
具体的には、よくある artisan や composer の短縮だけでなく、Git, Docker, PHP の実行環境など、日々の細かなストレスを減らす工夫を取り上げます。

想定対象者:

• 日常的に PHP を使う開発者
• ターミナルでの操作をもっと手軽にしたい方
• 小さな効率化の積み重ねを楽しみたい方

このトークから得られるもの:

• 今すぐ使える便利エイリアス
• 毎日の作業をちょっと手軽にする発想
• ストレス低減によりもたらされるモチベーション

近年、AI開発現場に深く浸透し、私たちの生産性を飛躍的に向上させています。
非エンジニアでもAIの助けを借りて開発に挑戦できる、まさに革新的な時代が到来しました。

​しかし、その便利さの裏には"予測不能な『AIの嘘』“という大きなリスクが潜んでいます。

​本セッションでは、私が実際に直面したAIの『嘘』、具体的には「AIが期待とは異なる出力を生成し、結果的にデバッグに膨大な時間を要した」経験について、実例を交えながらご紹介します。

​AIの『嘘』に引っかからないためのポイントを、5分という短い時間でポイントを凝縮してお伝えします。
この発表が、AIをより賢く、安全に使いこなすためのヒントとなれば幸いです。

日々の仕事や人間関係の中で、ふと傷ついた「言葉」って、案外ずっと心に残りませんか？
「言われてムカついた」「何気ない一言で凹んだ」
そういったモヤモヤを、トイレに流してスッキリする
Webサービスを作りました。

個人で気楽に作成し、Qiitaに記事を投稿したところ、想像以上に多くの人に使用してもらい、反響をうむ結果となりました。

このLTでは、

　・「心のトイレ」とはなんなのか
　・「心のトイレ」というアイデアをどのようにだしたか（筋トレが関係ある！？）
　・使用した技術と工夫
　・Qiitaに書いたことで得られた反響
　・個人開発の魅力や楽しさ

といったことをお話しします。

仕事と違い、個人開発は本当に気楽で最高です。
「ぱっと作って、すっとリリース」。
思いついたアイデアを、自分の好きなように形にできる楽しさをお伝えします。

そして、このLTをきっかけに、個人開発に挑戦する仲間が一人でも増えたら嬉しいです。

皆さんは、記事を書いたりLTをしたりといった「アウトプット」をしていますか？
僕はちょうど1年前まで、ほとんど何もしていませんでした。

そんな僕が、去年の2月からQiitaに毎日記事を投稿し始め、約1年でなんと160記事を公開しました。テーマはPHPやReactなど。学びの延長線上でアウトプットしました。

このLTでは、「アウトプット経験ゼロ」だった僕が、どのように気楽に始めて続けられたのか、そしてそこから得られた気づきをお話しします。

内容
• 投稿して感じられた小さなメリット
• ネタ切れやモチベ低下の乗り越えかた
• アウトプットを通じて自然と得られた成長
• 思いがけずバズった記事
• 工夫したこと

記事を投稿するのは最初は勇気がいると思います。
ただ実は、アウトプットは日々の学びを手軽に書き残すだけでも始められます。

このLTで「ちょっと書いてみようかな」と思ってもらえるきっかになれば嬉しいです！

2025年ももうすぐ終わろうとしていますが
お兄さんお姉さんだけでなく、おじいちゃんもおばちゃんお隣さんも、皆でMCPサーバーに夢中になった1年でしたね

Symfonyユーザーのために、symfony/mcp-bundle というbundleがあります。
これを使うと、簡単に

• Server-Sent Eventsを喋るための何か
• AIエージェントにToolを提供するための何か

を用意できます。

これって、普段のWebアプリケーション開発で、
「FWがやってくれる部分に任せて、やり取りする中身だけを気にしておけば、プロトコルやemitのタイミングなんて意識しなくてOKだよね」
って感覚に似ています。
触ってみると、「いつもPSR-7でやり取りしていた内容が、別のRequest/Responseに詰め込まれるだけだな！」という気持ちになれますよ

このLTでは、サンプルのWebアプリケーションを用意した上で、
「mcp-bundleを使ったら、Symfonyアプリケーションが簡単にMCPサーバーになった！」
という様子をお見せします。

概要

Web を支える重要なプロトコルのひとつ、HTTP。言語やライブラリ、フレームワークの下に隠蔽され、通信プロトコルを直接意識する機会は少ないと思います。そこで、PHP のソケット API を使って HTTP を解する小さなサーバを実装し、HTTP の理解を目指しましょう。

話すこと

• TCP/IP スタック
• HTTP の基本的なプロトコル
• HTTP を実装する
  • GET / POST メソッド
  • Cookie / Set-Cookie ヘッダ

実装を通して、初心者が抱きがちな次のような疑問を解消します。

• 「プロトコル」とは？
• GET と POST はどう違う？
• Cookie とセッションはどう違う？

対象

• Web サイトの通信がどのようにおこなわれているのか詳しく知りたい方

テストコードを書いたことがない人からすると、テストコードとは『コストをかけられる人が行う、高品質を目指すためのもの』という印象があるかもしれません。

しかしテストコードは全くもってバグを減らすためだけのものではなく、もっと手軽で日々の開発を楽に安全で効率的に進めるためのものでもあります。

「仕様がすごい変わるから付け足しのコードになるのは仕方ない」
「コードを変更するとバグが起きるリスクが高いし、コストもかかるので極力変更してはならない」
「できるだけコード追加で済むようにする」
「デッドコードなんじゃないかって？でも動かなくなったら嫌だしさ…」

――こうした“秘伝のタレ状態”のコードは、まさにテストコードがないことで生まれます。

本セッションでは、テストコードがないとチームやコードにどんな影響が出るのか、テストコードを導入したことで何が変わったのかを、実体験を交えて紹介します。
さらに、テスト文化のないチームでどのようにテストコードを広めていっているのかなどについても解説します。

テストコードを社内に広めたい方、チームでの導入に悩んでいる方、また既にテストを書いている方がその価値を改めて再確認する助けになれれば幸いです。

Setup PHP Actionは、テストに必要なPHP環境を手軽に設定できる、GitHub Actions用のアクションです。PHPの各バージョンに対応しているだけでなく、さまざまな拡張モジュールやツールを活用できます。さらに、マルチプラットフォームに対応しており、LinuxだけでなくWindowsやmacOS上でテストを実行させることも可能です。

本トークは、OSSに関心のある開発者やGitHub Actionsにおけるテストに興味のある方を主な対象としています。開発やテスト、OSSにコントリビュートする際に役立つ、Setup PHP Actionの使い方を紹介します。

Doctrineは、Symfonyフレームワークの標準の構成でも採用されているPHP製のORMです。

Laravel全盛の現代、Doctrineにはまったく馴染みがないという方も多いと思いますが、
いつSymfony案件にアサインされるかもしれません。備えあれば憂いなしです。
それに、普段と異なるパラダイムに触れることは学びの面でもとても有意義だと思います。

この機会にDoctrineを完全にマスターしておきましょう！

このトークでは、

• 「Active Record」と「Data Mapper」の違い
• Doctrineがデータを扱う仕組み（「Doctrineの世界」という感覚）
• エンティティマネージャー、Unit Of Work、リポジトリなどの要素概念

などについて30分で可能な限り詳しく、そして分かりやすく解説します。

近年、カンファレンスや書籍を通じて多様なソフトウェア設計の手法が広まり、私たちの選択肢はますます多くなっています。
しかし、リソースは有限です。すべてを全力で完璧に作り込むことは難しい場合もあります。
「どこに力を注ぐか」を見極めることも重要です。

事業の競争優位を支える核心領域には積極的に投資し、それ以外はあえて“手軽に”抑える。
判断を誤れば、逆に設計に振り回されて事業価値に結びつかないコストばかりが膨らんでしまう危険もあります。

ドメイン駆動設計の著者であるEric Evansはかつて、「最も才能がある人をコアドメインに割り当てること」と述べています。
そして現在では、メンバーの技術力やドメイン知識、内製・外注という判断軸に加え、"AI"という選択肢も広がっています。
これらの判断はどのように見極めればよいのでしょうか。

さらに近年では、コードや機能の「捨てやすさ」も注目されています。
手軽に「作る」だけでなく、手軽に「捨てる」ことも重要となってきました。

本セッションでは事業理解を基盤に設計・コーディングの「力の入れどころ」や「捨てやすさのデザイン」をどう考えるかをお話しします。
Kent Beckが提唱する"Optionality"などに触れながら、設計投資にメリハリをつける視点を紹介します。
また、私自身も過去に設計に投資しすぎてかえって無駄な複雑性を増やしてしまった失敗を経験してきました。
こうした自身の過去の失敗例も交え、理論と実践の両面から学びをお届けできればと思います。

事業価値を見据えつつ、どこに投資し、そしてどう捨てるか。
このセッションを通じて、その判断を明日から少し“手軽に”行えるようになるヒントを持ち帰っていただければ幸いです。