本トークでは自己ドキュメント化をテーマに、それが内包する楽しさについて紐解いていきます。

自己ドキュメント化は開発者の知的好奇心を満たすプロセスであり、コードを通じて思考を整理し、意図を明確に表現する行為そのものが、新たな発見や学びをもたらします。それは単なる効率化の手段にとどまらず、創造性や知的満足感を生むプロセスであることに疑いはありません。

本トークでは自己ドキュメント化の具体例をPHPコードを用いて示し、その具体的な手法について解説いたします。さらに、自己ドキュメント化に楽しさを感じにくくなる場面にも注目し、その要因を分析します。そして、それを克服し、継続的な好奇心と満足感を支えるための環境づくりについても考察します。

この取り組みを通じて自己ドキュメント化に潜む楽しさをより深く理解し、開発が個人やチームにとって豊かで意義のある活動へと昇華することを目指します。

PHPではtry-catchを使った例外処理が一般的ですが、「この例外はどのレイヤーで処理すればいいのか？」や「どの場面で例外を使うべきなのかが曖昧だ…」と感じたことはありませんか？
例外の種類や扱い方が曖昧だと、混乱しますよね。
この課題に対するヒントとして、Rustなどの言語で採用されているResult型の考え方があります。

Result型は、失敗が起こり得るということを型として扱い、例外に頼らずエラーを管理する手法です。
これにより、エラーの種類や処理責任が明確になります。
このセッションでは、Result型をPHPに応用する方法を実装例を交えて解説します。

取り上げる内容：

• エラーの種類の整理方法
• Result型の基本的な考え方とPHPでの実装方法
• try-catch採用プロジェクトでも活かせる学び

エラー処理を改善するヒントをお持ち帰りください！

システムの成長とともにデータモデルが複雑になり管理が難しくなることはありませんか？
「モデリングの仕方が人によって違う」「モデリングがうまくいかず、システムの複雑性が増してしまう」
こんな悩みを持つエンジニアは多いはずです。

イミュータブルデータモデルはUPDATEがシステムの複雑性を増大させることに注目し、誰が行っても一定のルールに基づいたモデリングを可能にします。

トーク内容

• イミュータブルデータモデルとは？
• 実例を交えたイミュータブルデータモデルの実践
• イベント駆動と合わせたPHP & Laravelとの適用

イミュータブルデータモデルは特別な前提知識がなくても理解しやすい強力な手法です。
DBの基本を理解していれば設計のヒントを得ることができると思います。

「過剰なUPDATEをやめると、設計はシンプルになる」そう感じてもらえるトークをお届けします！

データベースの寿命はアプリケーションより長い。
では、どのようにデータベースの寿命を伸ばしていけばよいのでしょうか？
そのコツは 変化に強い データベース設計にすることです。

そこで10年以上のサービスの寿命に耐えられるようなテーブル設計の勘所をご紹介します

お話すること

• RDBMSを利用して正規化をするときに大切なこと
• デプロイでデータベースを壊さないコツ
• 変更に強い設計

話さないこと

• 正規化の具体的な方法
• 既存テーブルのリファクタリングのやり方
• RDBMS以外の設計の話

わたしは十数年間この業界にいますが、いろいろなサービス層を見てきました。

• DB処理が大量に詰め込まれたサービス
• トランザクションスクリプトがひしめくサービス
• どこからでも呼ばれてしまう「神」サービス
• 複数のサービスと手を組み、仲良く連携するサービス
• ドメイン層を支えるサービス
• 取り急ぎ作られた「なんちゃって」サービス

そこには、愛らしいサービスもあれば、目を背けたくなるサービスもいました。
そしてこう思うのです「人には人それぞれのサービス層がある」と。

なぜ、人はみなそれぞれのサービス層を作ってやまないのか謎に迫りつつ、

• サービス層とはそもそも何なのか、必要なのか
• 憎まれるサービス層、愛されるサービス層とはなにか
• 理想のサービス層とはあるのか

これらの問いに、SOLID原則、特にSRPを切り口としてサービス層について考察したいと思います。

「インターフェースって何」って聞かれたら答えられますか？

インターフェースの設計はプログラミングの醍醐味とも言える創造的な営みです
PHPには言語機能としてのインターフェースが存在しますが、もう少し広義に考えれば

1. プログラマが実装する各種関数／メソッドの引数や返り値
2. フロントエンドとの協業に欠かせないOpenAPIの定義
3. チーム内外とやりとりするための各種ドキュメント

なども立派なインターフェースといえます

このトークでは「契約による設計」の考え方を元に、実例を元にインターフェースをよりよく設計し、より価値の高い製品（システム）を作るために意識すべきことについてお話します

私たちが普段書いているPHPによるコードは、いくつかのステップを経て機械に分かるよう変換されます。
AST(抽象構文木)にOPCode(オペコード)は、その流れを理解する上で欠かせない存在です。

日常的に接しているはずなのに馴染みがない─
そんな存在に、自分の手と目を使って少し仲良くなるワークショップです。
あなたのコードが、どんな風に解釈されているのか？一緒に覗いてみましょう！

対象

• ASTやOPCodeなる単語を聞いたことはあるかも知れないが、よく知らないな！というphper

やること

• 簡単なソースコードを、AST表現やOpCode表現に変換して見てみる
• 微細な修正を加えつつ、それらがちゃんと対応しているのを実感する

形式

• 予め用意された題材を手元で動かす、小講義＋演習の形式
• 合間に、頭の体操として(クイズのような)練習問題を挟みます

古いコードベースを読み解く作業はしばしば「ソフトウェア考古学」と呼ばれます。
ソフトウェア考古学を通してサービスの歴史から当時の設計思想や変化の過程を知ることは、良い設計を体験し、学べる貴重な機会です。

本トークでは、新卒5年目エンジニアである私が、20年以上稼働し続けるWebサービスの改善に向き合う中で試行錯誤し学んだことをお話しします。

お話すること

• 古いコードベースを読み解き改善を行った事例とその課題
• 複雑なコードベースを効率良く理解するための「鳥の目・虫の目」の考え方・具体的な進め方
• ソフトウェア考古学の経験から学んだ理解しやすいコードを書くコツ・あると嬉しいドキュメントとは？

聴いてほしい人

• コードベースが古い環境で悩んでいる人
• 歴史のあるコードを改善したい人
• 複雑なコードベースを効率的に理解する方法を知りたい人

近年、急速に"(コードの)質と(質の高さからくる開発)スピード"が注目されるようになってきました。

一方で「何故、"質とスピード"を求めるのか」に対するお話はあまり見かけません。

このトークでは「兵法」から見た「"ソースコードの質"や"開発スピード"は何のために必要なのか？」、「"ソースコードの質"や"開発スピード"は本当に必要なのか？」についてお話します。

日本でも著名な「孫子の兵法」から現代戦で重視される戦術論「リズムとテンポ」などの観点から「市場を支配するために必要な"質とスピード"」に迫ります。

このトークで得られる知見

1 あらためて考える「なぜ"質やスピード"が必要なのか」
2 "質やスピード"を求める場合の基準
3 組織人として組織を持続可能にするために考える事

このトークで話さない事

1 孫子の兵法をはじめとした戦略論・戦術論の詳解

本セッションでは、同じ会社のメンバーに登壇依頼、カンファレンスのスポンサー窓口担当や共にカンファレンスの登壇や参加準備することで職能間の境界を越えて交流することができ、私の社内でのコミュニケーション量が増加してきた話をします。

私は、社内外で勉強会をいくつか企画し開催してきました。開催した勉強会のテーマはそれぞれ異なっており、私が開催したいと思った勉強会を勢いで開催しています。

しかし、最初は私が開催するとは思っていませんでした。私が所属している会社は職能ごとにチームが分かれており、プロジェクトによっては他の職種のメンバーと話すことがないこともあります。
しかし、今では職種が異なるエンジニアとも勉強会をきっかけに交流し、関係を継続することができています。

本セッションを通して、自身の技術領域外の勉強会を開催することで得られる職能間の境界を超える楽しさについてお話しします。

私は現在物流系の会社に所属をしており、ECサイトから注文情報や商品情報を取り込む外部連携部分の開発を行っています。
Shopifyや楽天市場など様々な外部連携先がありますが、各連携先ごとの仕様がバラバラです。
ShopifyのようなWebhook形式のものもあれば、楽天市場のようにAPI経由で情報を取得するパターンもあります。

日々大量のリクエストを送受信をしており、日々大量のJobを発火し正常に終了させています。
本登壇ではAWS SQSの機能の説明と、実際に工夫を凝らして運用して得られた知見を一部紹介します。

• 標準QueueとFIFO Queueなど基本的な機能
• SQSの可視性タイムアウトやメッセージンググループID
• リアルワールドで起きていること
  • e.g. Webhookが順序通りに飛んでこない

地方でPHPを活用する小規模チームがクラウドを導入するメリットとは何なのでしょうか
クラウドは大規模案件や大規模なチームでのみ利用させる技術と思われがちです

しかし実際はそんな事なく、予算の小さな案件や、小規模なチームに継続的に適用し続けることで大きな価値を発揮します

本セッションではAWSを例に従量課金モデルを最大限に活かしながら、
インフラ管理の手間を削減し、チームの生産性と連携を高める“チームアップ”の要点も具体的手法を紹介します
スケーラビリティと安定性を確保しながら無駄なコストを徹底的に抑える活用例を示し、始めやすく続けやすい形でのクラウド利用法をお伝えします

地方こそクラウドを利用して、継続的なコスト削減と効率的なチームアップを行いましょう

• 想定聴講者
  • クラウドを利用していないPHPer
  • クラウドを利用したいPHPer

PHPStanは簡単に使い始められる便利なツールですが、レベルを上げようとするとPHPStanの型付けの特性について学ばなければ効果的に型をつけることはできません。本ワークショップではブラウザから動かせるPHPStan Playground上で問題を解くことでPHPStanの型についての理解を進めます。

このワークショップではブラウザ上で動作するPlaygroundとPHPが動作するローカルマシンのどちらでも取り組むことができます。
(ローカル環境でのPHP開発環境について本編時間内ではサポートできません)

新卒から6年間所属した部署から大異動で全く別のチームに配属された先には鳴り響くアラートの日々が待っていました。
アラートについて見ていくと異動先のチームには、以下のような問題を抱えていました。

• アラートの詳細を詳しく見なければ問題がないことを判断できない
• アラートの判断は属人化している
• ほとんどのケースにおいて問題ないアラートが飛び続けている
• 最初に監視を設定した人はすでに社内におらず、意図がわからない
• メンバー間のアラートに対する認識齟齬

これらに対して、一つ一つ向き合って出してきた答えについてお話します。
聞いて欲しい方

• 新たに配属されたが、アラート対応ができなくて悔しいと思ってる人
• アラート対応に課題感を持っている人
• 一緒に見直していく仲間を増やしていきたい人

「テストがないコードはレガシーコードだ！」
Webアプリケーション開発においてテストコードが書かれることは一般的になってきました。

ですが、テストにかかる時間は適切でしょうか？ テストにかかる時間は開発スピードに大きな影響を及ぼします。
本トークでは自動テストを高速化するための考え方やテクニックについてお話します。

想定観客

• テストにかかる時間を短縮したい方

お話しすること

• Google提唱の「Test Sizes」を取り入れて、テスト対象をCIとローカルで変えるテスト戦略
• テスト実行の並列化 (Makefile, xargs, paratest)
• CIをジョブ分割して体感速度を上げる
• テスト時も割と効くXDebug無効化 & OPcache有効化

近年、PHP系カンファレンスが大流行していて、今後もその流れは続きそうです。
このトークでは過去に16回のカンファレンス主催をしてきた私が、これからカンファレンス主催したい方の最初の一歩に役立つであろう内容をお話します。

• カンファレンスをつくるのに必要な4種類の参加者
• 会場の探し方と選び方
• カンファレンス開催にかかるお金
• 管理する必要があるものとそのためのツール
• ノベルティや会場装飾の作り方
• カンファレンス準備カレンダー - いつ頃、何をするか

カンファレンス主催したい方だけでなく、スタッフとしてカンファレンスを作ってみたい方、カンファレンスがどうやって作られているかが気になる方にもお楽しみ頂けると思います。
このトークがカンファレンス主催したい方の助けになり、良いカンファレンスが開催されることを願っています。

概要
皆さんはPHPにおける型にはどのようなイメージをお持ちですか？
楽？バグの温床？そもそも気にしたことはない？
本トークではPHPを通じて「データ型とは何か」から躓きやすい「PHPの型の相互変換」などについてお話しします。

ターゲット
経験年数5年くらいまでのPHPer初級者 ~ 中級者の方
改めてPHPの型について基本を学びたい方

詳細
本トークでは「PHPの型」をテーマに、型の基本概念からPHP特有の型システムに至るまでを解説します。
具体的には以下の内容を取り扱います。

1. 型とは何か
2. 動的型付け言語と静的型付け言語の違い
3. PHPの基本的なデータ型
4. 複合型と特殊なデータ型
5. 型の相互変換
6. 型の確認・検証

上記を通じて、参加者はPHPの型を深く理解できるので、PHPと少し仲良くなれるかも知れません。

ソフトウェア開発では、仮説検証を繰り返す中で「作ったけど使わなくなった機能」が必ず発生します。
しかし、こうした不要なコードを削除するのは、稀によく後回しにされがちです。

• 消さなくても動作に影響がない
• 消したときの影響範囲が不明でリスクがある
• そもそもコードが整理されていないので、どこを消せばいいのかわからない

こうした理由からコードが積み重なり、開発スピードが落ちたり、認知負荷が上がったりしていませんか？

本トークでは「捨てやすいソフトウェア設計」をテーマに、

• 「10分で機能を削除できる」設計の考え方
• コードを整理し、機能単位で管理するディレクトリ構成
• チーム全体で「捨てる文化」を育てる方法

をお話しします！

仮説検証をスムーズに回し、変化に強いソフトウェアを作るために、「捨てやすさ」について一緒に考えてみませんか？

「カンファレンスは初心者にとってハードルが高い」「カンファレンスぼっち参加は心細い」
そんな風に感じたことはありませんか。

2024年、私は各地のPHPカンファレンスへ継続的に参加しました。
PHP歴半年、1人での遠征。最初は私も上記のような不安でいっぱいでした。

このトークでは、下記２つについて話します。
・私が不安を乗り越えてカンファレンスに参加するために持っていたマインド
・私がPHPコミュニティの熱狂へ飛び込んで得たもの

このトークを通して、勇気を持ってPHPカンファレンス新潟に参加した方が、またカンファレンスへ足を運んくださることを目指します。

【参考】
今年参加したPHPカンファレンスを振り返る
https://speakerdeck.com/kousukeosanai/jin-nian-can-jia-sitaphpkanhuarensuwozhen-rifan-ru

「コードを読むのになんだか時間がかかってしまう」、「上から読むのが非効率な気はするけれど、どこから見ればいいかわからない…」
このLTでは、コードリーディングの基礎を学び、そのコードが生まれた経緯を想像することで、コードリーディングをもっと楽しくする方法をお伝えします。

コードリーディングのポイント

• 構造を捉える
• 入出力に着目する
• 主人公を探す

コードが書かれた背景に思いを馳せる

• 開発者からのメッセージを読み解く
• 過去の状況に同情する…
• 初心者の頃の自分を思い出す

コードリーディングは、単にコードを理解するだけでなく、過去の開発者との対話であり、歴史を学ぶ旅でもあります。
プログラム修正のため・調査のためだけのコードリーディングから、歴史を紐解きレガシーコードの深淵をのぞく、一歩踏み込んだコードリーディングをしてみませんか？