こんにちは！ディップ株式会社で24新卒エンジニア兼DevRelとして色々やっておりますジャスティン(@j_t_wulf)と申します。

今回はPHPカンファレンス新潟2025に参加してきたので、その参加レポートを書きたいと思います！※本記事ではあくまでカンファレンス参加者目線としてのレポートとなります。ブース出展の振り返りは別記事で執筆予定です。

PHPカンファレンス新潟2025について詳細はこちらです。

セッション紹介

私が視聴したセッションについて、いくつか内容をご紹介したいと思います。

変化に強いテーブル設計の勘所（曽根壮大さん）

（PHPカンファレンス新潟2025公式Xより引用）

AIが進化する現代におけるテーブル設計の考え方についてのセッションです。

テーブル設計の本質的な部分は人間が担うべきであるというメッセージが印象的でした。AIは設計作業の"サポート"は可能ですが、ビジネスやドメインの理解や背景は分からない（プロンプト次第でどうにか出来るかも）ので、長期的に運用しやすい設計を実現するためには、生身の人間の知識や経験が不可欠であると感じました。

特に印象的だったのは、DBはアプリケーションよりも寿命が長く、変更に弱いという点です。例えば、本番環境で稼働中のDBに対してテーブル構造の変更を行ったらサービスがロックして停止してしまったり、カラム追加時に過去データへの対応が必要になったりと、DBの設計や運用には慎重さが求められることが具体的な事例とともに語られていました。

そのため、DBには「事実」のみを保存し、ビジネスロジックはアプリケーション側で管理することが重要であると説明されていました。（例えば、生年月日などの変わらない情報はDBに保存し、年齢のような可変かつ計算可能な情報はアプリケーションで扱う、といった感じ）

また、テーブル設計においては「簡単（easy）」ではなく「シンプル（simple）」を目指すべきであり、1テーブル1責務を意識することの大切さも強調されていました。AIはER図やDDLの生成、テストデータの作成などを効率化する上で有用ですが、設計の根幹部分はエンジニア自身が責任を持って取り組む必要があると再認識しました。

また、DB設計に関する資料として以下の著書をおすすめされていました

SQL実践入門
達人に学ぶDB設計徹底指南書
SQLアンチパターン
失敗から学ぶRDBの正しい歩き方（名著とのことです）

コードに語らせよう--自己ドキュメント化が内包する楽しさについて（nrsさん）

（発表の写真撮り忘れてしまいました土下座）

発表資料

陳腐化しがちなソフトウェアのドキュメントについて、「コードそのものが最高のドキュメントになる」という考え方が語られていました。

ドキュメントの問題点・あるある

プログラムから独立した存在であるため、古くなりやすい
そもそも存在しない場合がある
内容が信用できない場合がある

コードをドキュメント化するメリット

余計な資料を探す手間が省ける
コードとドキュメントの乖離が起きない
チームメンバーや未来の自分が喜ぶ

発表では、無口すぎて何をしているかわからないコードや、逆に説明しすぎてうるさいコードの話もあり、大事なのは「読む気になるコード」であることだと感じました。

↓無口なコード。コード読んだだけでは何したいのか分からん

function f($a, $b) {
    if ($a > 10) return false;
    if ($b == 0) return false;
    return true;
}

↓語り始めたコード。classやfunctionにコンテキストが含まれるので読めそう

class DiscountService {
    public function isEligibleForDiscount(int $age, int $purchaseCount): bool {
        if ($age > 10) return false;
        if ($purchaseCount == 0) return false;
        return true;
    }
}

また、伝える方法は実装やコードコメントだけではなく、ディレクトリ構造やファイルのグルーピングも大切だという話も印象的でした。特に、プロジェクトの規模が大きくなるほど、コードの構造自体がドキュメントとしての役割を果たす重要性が増していくという点は、大規模プロジェクトを経験した身として非常に共感できました。

エンジニアが組織に馴染むために勉強会を主催してチームの壁を越える（うーたんさん）

スライド

このセッションでは、自律的な組織で働くエンジニアが、いかにして社内外のエンジニアとの繋がりを深め、自身の活動を「可視化」していったかについて語られていました。

特に印象的だったのは、以下の3つのポイントです：

発信による可視化
- Slackでの技術ブログ共有やスライドの投稿
- スタンプやコメントを通じた相互理解の促進
- 自身の興味関心を発信することで、共通の関心を持つ人との接点作り
勉強会主催による繋がりの創出
- 尊敬する人への登壇依頼
- 社外イベントを参考にした企画立案
- 主催者としての立場を活かした交流機会の創出
社内外での積極的な活動
- スポンサーイベントへの参加
- 技術ブログを通じた情報交換
- 直接の会話を通じた深い人間関係の構築

「喋るのが苦手でも、行動で示すことで繋がりは作れる」というメッセージは、巨大なエンジニア組織を抱える弊社にとって、非常に重要な気づきだと思います。また、個人の成長と組織への貢献を両立させるWin-Winの関係性の築き方についても、具体的な事例とともに学ぶことができました。

UPDATEがシステムを複雑にする？イミューレタブルデータモデルのススメ（akshimoさん）

スライド

このセッションでは、データの不変性を保つことでシステムの堅牢性を高めるイミュータブルデータモデルについて解説されていました。

イミュータブルデータモデルは、データの不変性を保つことでシステムの複雑性を低減し、堅牢性と保守性を向上させるアプローチとのことです。このモデルでは、データは一度作成したら変更（UPDATE）せず、変更が必要な場合は新しいデータを作成します。また、データを「リソース」と「イベント」の2種類に分類することで、より明確な設計が可能になります。

イミュータブルデータモデルには以下のようなメリットがあります。

データの不整合やロストアップデートのリスクを低減
変更履歴の追跡が容易になり、デバッグや監査がしやすくなる
並行処理との相性が良く、複数の処理が同時にデータへアクセスする際の競合リスクが低減

また、イミュータブルデータモデルでは、データを「リソース」と「イベント」の2種類に分類して扱います。

リソース（Resource）は、状態が変化しうる対象（ユーザー情報、商品情報など）を指します。リソース自体を直接UPDATEするのではなく、新しい状態を表すイベントを記録し、そのイベントを集約して現在のリソースの状態を表現する。

イベント（Event）は、発生した事実や出来事（商品購入、ユーザー登録など）を表します。イベントは一度発生したら変更不可で、一つのイベントには一つの日時属性のみを持たせるのが原則。

実装においては以下の点に注意が必要です。

日時属性に注目してデータを分類し、リソースとイベントを適切に分離
NULLを避け、イベントの有無でデータの存在を表現
関連は交差テーブルで表現し、関連の発生自体をイベントとして記録
LaravelのEvent機能との連携を検討し、データベースへのレコード作成をトリガーとして関連処理を実行すること

（ちなみに今回が初登壇らしいです。初とは思えない発表ぶりで感銘受けまくりでした）

参加してみての感想

PHPカンファレンス新潟2025に参加して、技術的な学びだけでなく、様々な面で充実した時間を過ごすことができました！

新潟ならではの魅力

カンファレンス会場では、新潟の魅力を感じられる要素がたくさんありました！

会場内で提供されていた新潟の甘酒が絶品すぎました。すっきりしてて永遠に飲める。

あとMCTオイルを初体験しました。コーヒーに入れて飲むと風味がより豊かになって贅沢な味でした。

交流エリアでは新潟の特産品やご当地おかしが提供されており、地元の魅力を存分に感じることができました。

昼ごはんには新潟名物の「タレカツ」をいただきました（クソ美味かった）

みなさん登壇発表がお上手すぎる

スピーカーの方々は皆さん発表慣れされており、カンファレンス登壇未経験の私としては発表の観点でも学びが多かったです。5分程度のLTとは違い、20分以上の登壇では中弛みさせないための工夫が必要ですが、ひと笑いを挟んだり、内容を転換したりと、最後まで飽きずに視聴できる工夫を感じることがあり、個人的にとても感銘を受けました。

スポンサーブースでの交流

各社のスポンサーブースを回ってお話しできたことも楽しかったです。自社と同じ課題を抱えている話をしたり、他のカンファレンスでお会いした顔馴染みの企業の方とお話しをしたり、新潟に拠点を置かれている企業の方からは、地方企業ならではの悩みや楽しさについてお話しを伺えたりと、さまざまな話題で話すことができ、知見を広げることができたと感じます。