トーク

PHPは、バージョンアップを重ねるごとに新機能や改善が追加されています。
普段使っているPHPですが、サクッとバージョンアップだけしていると気がつかないうちに増えた便利な機能などを覚えないことも…

そんな「いつの間にか入っている」機能に焦点を当てたライトニングトークです。
今回は面白い機能をサクッと紹介し、実践でどのように役立つかを具体的なコード例とともに解説します。

2024 年，各地で PHP カンファレンスが開かれ，2025 年の下準備として PHP 勉強会を小規模に開催する都市もありました．しかし，小さな街で開く PHP に対象を絞った勉強会では，十分に人が集まらず，存続不能になってしまうことも少なくありません．
　
第一に守るべきは PHPer リーチャブルな空間をつくることです．勉強会の形式やテーマを絞っている場合ではありません．PHPer と会えて，話ができ，情報交換できることが肝要です．Slack こそありますが，情報を欲する全員がそこに自力で到達できるわけではありません．そこに連れていく PHPer が必要なのです．
　
そこで，ここに来たみなさんが日本の 1,724 市町村※のどこにいても技術系勉強会が開けるよう，そして維持できるよう，どんな小さな街でも勉強会を続けられる最小のノウハウをお話します．
　
※ 北方領土の 6 村を含める

サービスにおいてAWS SESを使ってメールの大量送信を行うと、直面する課題としてバウンス率、苦情率が増加し、メール送信が止まってしまう危機があります。
本セッションでは、AWS SESを利用してメール送信システムの苦情率増加と抑えるために実施した具体的な対策について共有します。

主なトピック:

• AWS SESにおけるバウンス率、苦情率の概念について
• 苦情率が増加してしまった原因について
• 具体的なAWS SESを使ったメール配信の苦情率増加を改善した手法について

最近サーバーレスPHP流行ってますよね？

私は全国でサーバーレスPHPの利用がもっと広がって欲しいと思って活動をしています
広がって欲しいなら方法を示すべきです

それでは「5分で」サーバーレスPHPをデプロイするデモをしてみましょう
5分でデプロイ出来るなら、みなさん試してくれますよね？

このデプロイのデモを動画ではなくみなさんの眼の前でデプロイすることで、
「本当に5分で出来るならやってみるけど...」 -> 「サーバーレスPHPすごい！簡単！やっていくぞ！」
と感じてもらうのが目的です

スライドは「タイトル」と「自己紹介」と「デモ」と書かれたセクションだけです
その後、すぐデモに入ります

私自身のデモの練度を上げることで、制限時間の中で出来る事を増やして、
みなさまの手を動かすきっかけになれれば幸いです

※AWSアカウントの作成が済んだ状態で始める事は許容してください

受け持っているプロジェクトの進行と新人教育の両立は、多くのエンジニアが直面する課題です。
この課題を解決するために、PHPの研修を自動化する方法を思いつき実践してみました。

どのようにしてPHPの研修を自動化し、新人が自己学習を進められる環境を整えたのかを共有します。
具体的には、問題を作成し、自動テストで答え合わせを行うことで、新人が自己ペースで学習を進められる環境を提供しました。

この方法により、研修のが簡単になり新人の教育を効率的に行うことができました。

みなさんPHPStanを使っていますか？ PHPStanはオープンソースで開発されているので誰でもソースコードを読んで仕組みを学ぶことができ、理に適った提案であれば取り入れてもらうこともできます。

本トークでは私がこれまでPHPStanに送信したPull Request(※トークプロポーザル時点で未マージ含め43件)について分類して紹介します。

• 取り入れられた提案
• マージされたPR
• マージされなかった
• マージされたが後にrevertされた提案
• 投げ出してしまって完成していないPR

SOLID原則・凝集性・結合度・関心の分離・DDD・クリーンアキテクチャ...
設計を考える際、学ぶべき原理や手法が多すぎて圧倒されてしまうこともありますよね。

しかし、これら設計原則は、実は私たちがよく知っている「英語の文法」にヒントが隠されているかも...?
英文法の基本的なルールに着目することで、仮に設計原則を知らなくても、シンプルで明確な設計ができるようになるかもしれません！

このトークでは、SVO・SVOCなど基礎的な英語文法がどのようにコード設計に応用できるかを具体的に解説します。
例)

• S(主語)やV(動詞)の明確化が単一責任原則の遵守に繋がること
• 「S(主語)がV(動詞)した」とクラス設計を考えることの恩恵
• コード上での形容詞・副詞の在り方

想定聴講者

• 設計詳しくないけど興味がある人
• 設計に原理・手法多くてなかなか手を出せないでいる人

人生初プロポーザル提出です！
登壇経験ありません！

Laravel 11 がリリースされて半年以上経ちましたが、皆さんの会社では、技術力向上のためにどのような取り組みをされていますか？

弊社では、7月から「Laravel 11 公式ドキュメント輪読会」を実施しています。
ざっくり進める会ですが、初心者には理解が難しいことも多く、Slackでの共有内容も後から見返すのが大変です。

そこで新卒エンジニアである私が考えました！
「参加していないメンバーや後から振り返るメンバーにも役立つ資料の作り方」を提案します。

公式ドキュメントを活用し、メンバーが知見を追加できる資料作成の手法を提案します。
これにより、輪読会の参加者だけでなく、後から参照するメンバーとも知識を共有できます。

当日は、この資料作成の方法や活用方法を実例を交えて紹介します。

昨年7月から11月にかけて、49歳で約25年勤めた会社を退職してソフトウェアエンジニアとして転職活動を行い、PHPを書ける会社に転職しました。
比較的高齢なおじさんがどのような気持ちで転職活動をおこない、その結果どうなったのかをできるだけ赤裸々に且つスピーディにお話しします。

開発しているときにこんなことはありませんか？
「プロダクションコードをきれいに書きたいけど、なかなか書く時間が取れない・・・。」
「ここを触る前にリファクタリングしたいけど、納期的にそんな余裕はないしなぁ・・・。」
「// TODO: いつかキレイに直す」

リファクタリングしたい気持ちはありつつも、機能開発の事業価値とリファクタリングによる事業価値を天秤にかける必要があります。
しかし、リファクタリングによる事業貢献度を算出するのはなかなか難しく、なかなかここを説得力のある数字を出しながら進めていくのは骨が折れます。

本セッションでは、このリファクタリングによる事業貢献度を算出するための考え方と、
PhpMetrics( https://www.phpmetrics.org/ )を使い 開発的にも、事業的にも 効率よくリファクタリングをしていく方法について話します。

パフォーマンス改善してますか？スロークエリ改善してますか？

Amazon RDSには便利な機能としてPerformance Insightsというスロークエリなどを分析して可視化してくれる機能があります。
しかし、この機能はt2およびt3, t4gのmicro, smallインスタンスでは利用することができませんし、RDSを利用していない場合には使用することができません。
この場合、スロークエリのログ出力設定を行いファイルに吐き出して、手動で解析すれば改善することはできますが、とても手間がかかってしまいます。
そこで便利なのが、MySQLの機能であるPerformance Schemaを使って簡単に可視化し改善していく方法を紹介したいと思います。
想定聴講者は、スロークエリ改善をしたいができていない方、なにから手をつければわからない方、お手軽にスロークエリ分析をしたい方におすすめです。

開発効率を向上させたいけど、大規模な自動化は難しそうと感じていませんか？
実は GitHub Actionsを使えば、小さなことから少しずつ気軽に自動化の仕組みを作ることができます！

このLTでは、自動化のアイデアの見つけ方から GitHub Actionsでの実装までをわかりやすく紹介します。
設定ファイルの管理やライブラリのアップデートの自動化など、私が実際に作成した身近な例を通じて、自動化の楽しさと手軽さを体感していただけます。

このLTを聞けば、明日から自動化への第一歩を踏み出す自信がつくはずです！

このLTを聞いて欲しい人

• 自動化に興味があるけれど、どこから始めれば良いかわからない人
• GitHub Actionsを使って効率的に作業を進めたい人
• 個人またはチームの開発プロセスをもっと楽しくしたい人

スクラム開発されている皆さん
ストーリーポイントによる見積は相対見積で、時間見積ではないとされています。
とは言っても様々な種類のタスクがある中で同じ基準で比較はなかなか難しいなと思います。

自分たちのチームは便宜上時間見積に近い形を取っており、
今回は実際にどのように進めているのか簡単に紹介してみようと思います。

このトークでは、OPcodeを読み進めていたはずが、気づけばPHPのソースコードを読み込むことになった体験を共有します。

当初はパフォーマンスや最適化を目的にOPcodeを読んでいましたが、調べるうちに言語の内部構造にまで興味が広がっていきました。
そのプロセスを具体例とともに振り返りながら、技術的な知識に加え、その過程で得た学びや気づきについてお話しします。

Laravel 11アップグレードに伴うCarbon2から3での変更について、実際のプロジェクトで発生した修正点を例を交えながら紹介します。

話すこと
・Laravelだけでなく各ライブラリのガイドを確認することの重要性
・Carbon3での変更により実プロジェクトで起きた修正例
・Github Codespacesによる開発環境構築が作業の助けになったこと

このコード、この機能、今も使われているの？
ある機能を削除したいけど影響範囲が分からないので怖くて手を出せない...

システムの機能削除は影響範囲が広く、ハードルが高いものです。
しかし避けているとシステムに不要なコードやファイルが残り続け、実装の妨げになりシステムの保守性が下がります。

そこで、本トークではシステムから不要機能を削除するためのポイントをご紹介します。
不要機能との向き合い方はシステムに左右されますが、皆さんにとってベストプラクティスを見つけるきっかけになれば嬉しいです！

【話すこと】
・不要機能がシステムに残るデメリット
・不要機能ってどこまで削除するの？削除の範囲を決めよう
・機能削除でエンジニア完結の判断は禁物、ビジネスサイドと連携しよう
・不要コードを生み出さないためにできること

【概要】
認証処理は一度実装されると変更が少なく、日常的に触れる機会が少ない分野です。
普段当たり前の様に使われている機能ですが、システムに必須かつ複数のサービスから使われるケースも多いため、システム全体の要と言っても過言ではありません。
そのため普段認証システムを触らない人でも、最低限の仕組みやフローを理解しておくことは重要です。

そこで、認証システムを触ったことがない人に向けて、事前に知っておくと便利なポイントをまとめました！
認証はハードルが高い分野ですが、トークをきっかけに認証システムに興味を持ち、日々の業務やトラブル対応に活用していただければ幸いです。

【話すこと】
・システム固有の知識+認証固有の知識を知ろう
・ユーザーの種類は？SNSログインは使うの？認証システムの仕様そのものを知ろう
・ウチの認証システム、どの認証フローを使っているの？
・認証についてもっと知りたい！

ご存知の通り、レビューとは「講評」「批評」という意味です。
そのためコーディングにおけるレビューも、どうしてもレビュワーから実装者への一方通行コミュニケーションになりがちな側面を持っています。

しかしレビューとは、実装者とレビュワーが解釈をすり合わせる場であり、
双方向のコミュニケーションをしてこそ、漏れなく効率的なすり合わせができると私は思っています。
今回は私がPRレビューを双方向コミュニケーションの場にするためにしていることを、3つお話しします。

• 些細な違和感を逃さない[Q]と[MEMO]
• レビュー修正者を迷わせない効率的レビュー
• チームメンバーの癖を把握した、メンバー特化型レビュー

テストを書くことにもだいぶ慣れてきましたが、いまだに嫌で仕方ないものがあります。それがデータプロバイダです。

データプロバイダを書くのは面倒くさい。本当に本当に面倒くさい。
というのもリリース恐怖症の私は、テスト対象のありとあらゆる条件やパスを通したくなります。
「いや〜書かなくても大丈夫だろうけど、怖いし一応書いとくか…」を繰り返すうちに、どんどんテストパターンが増え、データプロバイダが膨大になります。

ここでは、私をそんな無限コピペ地獄から救ってくれた「差分だけデータプロバイダ」をご紹介します。
同地獄に陥っている方の一助となれば幸いです。

⁠対象者

• いつもデータプロバイダが太りがちな方
• ツールなど使わず手動で、大量のパターンをテストしなければいけない方
• データプロバイダを書くのが億劫で仕方ない方

郵便番号とは、当たり前に都道府県・市区町村が特定できるものだと、そう思っている人はいませんか？
まさか「複数の都道府県にまたがる郵便番号」なんてあるわけない、そう思っている人はいませんか？

そんな罠にはまった私が、郵便番号に関する実装知見をクイズ形式で紹介します！