近年、プロダクトや機能のライフタイム全体に責任を持つフルサイクルエンジニアを目指そうという考え方が普及しています。フルサイクルエンジニアとしてのスキルを拡張するために、バックエンドエンジニアがフロントエンドを学ぶ必要性が増しています。ただ、いきなりフロントエンドに挑戦するハードルは高いと感じる方も多いでしょう。

しかし、発表者はPHPを6年、React・Vueを5年書いてきた経験から、適切なメンタルモデルを身につけていれば両者の行き来は難しくないと感じています。

本セッションはオブジェクト指向プログラミング（OOP）の考え方を土台に、フロントエンドの「コンポーネント指向」を解説することで、バックエンドエンジニアがフロントエンドを学ぶ基礎を作ろうというものです。内容は私が執筆したReactの考え方の解説記事を、バックエンドエンジニア向けにアレンジする予定です。

「React を深く知るための入り口」
https://zenn.dev/panda_program/articles/deep-dive-into-react

まず、OOPの「クラス」「オブジェクトグラフ」「MVC」と、Reactの「コンポーネント」「UIツリー」「Flux」の違いや共通点を比較します。例としてブログ記事を題材に両者の設計や振る舞いを整理した後、Reactの基本的な機能と考え方を紹介します。

・状態があるコンポーネントと状態がないコンポーネント： React Hooks の useState と状態遷移
・状態管理とイベントハンドラ：ユーザーアクションへの対応と、UIの動的な更新の仕組みを解説
・プレゼンテーションロジック：フロントエンドとバックエンドのHTML描画の違い（JSX）

Reactの基本を押さえつつ、OOPの視点を活かしながらフロントエンド特有の設計思考を身につけましょう。

OSSへのコントリビュートは敷居が高いと感じていませんか？「何から始めればいいのかわからない」「自分のスキルでは貢献できない」といった壁を感じる方も多いでしょう。
しかし、自分のプロダクトのPHPのバージョンアップ作業をきっかけに、自然とOSSにコントリビュートを始めることができます。

本セッションでは、以下の内容をお話しします：

PHPのバージョンアップで直面した課題とその解決方法
バージョンアップ作業を通じてOSSプロジェクトにフィードバックを返す方法
初心者がOSSコントリビュートに取り組むための具体的なステップ
実際の体験を交えながら、どのようにOSSコントリビュートを「ハードルの高いもの」から「身近なもの」に変えられるのかをお伝えします。PHPのバージョンアップは単なる技術負債解消にとどまらず、コミュニティ全体の改善に貢献する第一歩でもあります。
初心者でも始められるシンプルな方法を知り、開発者としての新たな一歩を踏み出しませんか？

私はEM1年生。 2024年4月に新規プロダクトをリリースし、現在はそのプロダクトをなんとか成長させていくべく邁進しています。

新規プロダクトのリリース、そしてその後のグロースにあたってはさまざまな進行上の課題がチームに襲い掛かりました。

・ スクラムを解釈した開発イベントがなぜかうまくいかない
・ 社内や社外からのフィードバックが集まらない
・ プロダクトマネージャーとタスクの温度感がすり合わない
・ プロダクトの課題が無限に積まれ、さばいてもさばいてもなくならない
......

これらの課題が発生した背景には、新規プロダクト開発においてはフェーズごとに求められる立ち回りが大きく変化するというものがありました。

本セッションではそのような状況に対応するため、繰り返し見直し、変更・改善してきた開発手法の変遷について、良かった点と反省点の両軸から振り返ります。

「どのような開発手法を採用すればいいか分からない」、「なぜだか現状の開発手法がしっくりきていない」といったお悩みを抱える方へ、
実践的な改善方法やそのヒントとなる知見をお伝えできたら幸いです。

みなさんテスト駆動開発（TDD）を試したことはありますか？
このLTでは新卒1年目の僕が先輩と一緒にTDDに初挑戦した際の学びや気付きをお話しします！

今回はテストコードがない既存機能に、新しい機能を追加することになりました。
テストコードがない状態からでも、テスト駆動開発を用いることで手戻りコストが大きくなる前に不具合を早期に発見できることや、テストコードを仕様書のように使えるので楽に実装できることを学びました。

このLTがTDDに初挑戦する方の助けになれば幸いです！

「個人主義が根付いたチームをどう変えればいいのか？」
そんな悩みを抱えるリーダーに向けて、一匹狼だった新米リーダーのチーム改善の記録をお届けします。

リーダとして任されたコスト削減プロジェクトは、50%の未達により暗礁に乗り上げ、一時は先が見えない状況に。
追い詰められた中で「毎日の朝会」を導入し、チームの力を結集することで最終的に117%以上の削減に成功しました。

このセッションでは、一匹狼のリーダーが、個人では解決できなかった課題をチームの知恵と協力で克服した具体的なプロセスをお伝えします。

「どうやってチームメンバーの力と知恵を借りて、目標を達成するのか？」そのヒントが見つかる内容です。
チーム運営に悩むリーダーにこそ聞いてほしい、新米リーダーの泥臭い改善の記録です。

画面開発で、こんな悩みを抱えていませんか？

• 画面ごとに統一感のないデザイン、曖昧なレビュー基準に振り回される
• 開発のたびにゼロからデザインとコーディングを繰り返す
• CSSの保守性が低く、改修のたびに手間がかかる

例えば、新しい画面が追加されるたびに微妙に異なるUIが作られたり、レビュー時に明確な基準がないことでデザインの決定が長引いたりした経験はないでしょうか。こうした課題が積み重なると、チーム全体の開発効率やモチベーションが著しく低下してしまいます。

これらの課題に対する解決策として、「デザインシステム」を導入しました。

今回のトークでは、既存のデザイン案を基に、FigmaやStorybookなどのツールを活用しながらデザインシステムを整備し、プロダクトへの導入を進めた一連の取り組みをご紹介します。

話す内容

• デザインシステムとは何か
• 導入に向けた具体的なステップ
• 導入前の課題と導入後に得られた効果
• 導入が進まなかった要因と成功に繋がった工夫

こんな方におすすめ

• 画面開発で課題を感じているエンジニア、UI/UXデザイナー
• レガシーなフロントエンド構成に悩んでいる方
• デザインシステム導入に興味がある方

トークを通じて、みなさんの開発現場でも役立つヒントをお届けできればと思います。

世の中には大小様々な企業があり、多様なチームが存在すると思います。
カンファレンスに参加されているみなさまはよいチームビルディング、よいチームを形成しているところに所属されていることが多いのではないでしょうか？

しかし、「よいチーム」とは現時点でも氷山の一角であると、現実で直面する場面は多いのではないでしょうか？
私も様々な現場を歩いてきた身として、多くの「よいチーム」「わるいチーム」というのを見てまいりました。
そういった現場では良いも悪いも関係なく、レガシーコードと向き合う機会が必ずやってきます。
さて、ご自身のチームはレガシーコードに立ち向かうことはできる「よいチーム」となっているでしょうか？

今回私がご提唱するのは、レガシーコードに取り組むのであれば、最初にチームを改善することで何が変わっていくのか、というものでお話をさせていただければと思います。

話すこと

• レガシーコードコードとは
• 「よいチーム」ってなに？
• 会社は「文化」、チームは「規約」
• 本題（レガシーコードの前にチームを改善する）

話さないこと

• 詳細なコードの事例とか

想定聴講者

• チームに不満を持っている人
• 昇格したチームリーダー、マネージャー
• レガシーコードにこれから立ち向かおうとしている方

ある程度タスクがこなせるようになったジュニアエンジニアが、次に任せられがちなプロジェクトリーダー(以下、PL)。
やることは組織やプロジェクトによって違いはありますが、プレイヤーをやりつつマネージャーのもとでメンバーのタスク管理や実装方針の決定などをすることが多いと思います。

このLTでは初めてのPLをやってみて、役に立った本、拠り所になった本を時間の許す限り、10冊程度紹介します。

プロジェクトの成否を左右することになるPLの仕事を、うまく進めるためのヒントをお伝えできればと思います。

紹介する本の領域

• プロジェクトマネジメント系
• リーダーシップ系
• 開発組織系
• 品質管理/テスト系

物理エンジンは、物体の運動のシミュレーションに用いられ、ゲームや学術研究など様々な用途のある技術です。

その動作原理を少しでも理解すべく、PHPで簡単な物理エンジンを作りました。
https://phpysics.net/

本トークでは、物理演算をプログラムに落とし込むための理論から入り、デモを交えつつ、具体的な実装方法の一部までをお話しします。

話すこと

• 物理法則をプログラムに落とし込む過程
  • 物理エンジンがやっていること
  • 位置の計算
  • 力の計算
• デモ
  • 引き合う2物体のシミュレーション
  • 振り子の運動
  • バネの運動

あなたも、自分で作ったプログラムの中で物体を動かして遊んでみませんか？

※PHPカンファレンス沖縄のトークのブラッシュアップ版です

本セッションでは、仕様書がなくテストコードもないシステムのLaravelへのリプレイスプロジェクトで、安全にリプレイスを行えるようになった方法論を紹介します。

プロジェクト初期は、仕様書がないこともあり、網羅的なテストが行えない状況でした。その結果、結合テスト時に不具合が多発してリリース延期を余儀なくされたり、プロジェクト期間の延長が発生していました。

そこで、移植方針やテスト方法の見直しを行った結果、オンスケでプロジェクト推進ができるようになりました。

以下のトピックを扱います。

• 仕様書のない中で安全に移植を行うための方針
  • 移植方針の見直し
  • 網羅的なテストケースを作る方法
• 計画を推進するためのマネジメントの方針

皆さんは普段、下記のような環境で開発をしていますか？

• コンテナ化され本番とほぼ同じ開発環境
• 手厚いソースコードレビュー
• 整備されたCI/CD
• 充実したテスト
• 安全な運用ルール

しかし、世の中にはこのような整備された安全な環境でない現場もあります。
では、何がよくないのでしょうか。
このセッションでは、開発環境のアンチパターンをもとに、何がよくないのかを解説していきます。

トーク概要

いつものようにコーヒーを片手にミックスナッツを食べながら、今日もコードレビューの時間がやってきました。

プルリクエストを眺めながら、こんなことを思ったことはないでしょうか？

• 差分でかすぎる...これ正しくレビュー出来る人いる？
• ここまで実装進んでから指摘しにくいなぁ...
• フィードバックするのはこれで何度目だろうか...

恥ずかしながら私の部署でも、このようなことはよくありました。

このセッションでは、コードレビューの存在意義とは一体何なのか？を改めて考え、私たちの部署で普段行われているコードレビューやプルリクエストに対するガイドラインをご紹介します。
このセッションが終わる頃には、明日からのコードレビューが楽しみになる事間違いなしです！（カリッ）

話さない内容

• 具体的なGitHub ActionsのCIの組み方
• GitHubの設定

想定読者

• コードレビューという作業でもやもやを感じる人
• レビュー指摘に対してモヤモヤを感じる人
• チームのパフォーマンスを改善したい皆様

任意の時点の PHP プロセスのメモリ状態のスナップショットをとり、SQL で「一番大きな文字列」「あるクラスの全インスタンスにおける特定プロパティに格納された配列の平均サイズ」「前回取得時のスナップショットから生き残り続けているオブジェクト」といった情報を自由に取り出せるとしたら、とてもおもしろいと思いませんか？

え、何の役に立つのかって？そりゃ何かの役には立つでしょう。何かの役に立つという確信はありますが、しかしそのような実用一辺倒の観点でものごとの価値を決めつけていくのは、あまり豊かな生き方とは言えません。役に立とうが立つまいが、とにかくスクリプトの状態を SQL でクエリするのです。

このトークは自作のメモリプロファイラ Reli に、登壇駆動開発で機能追加をするための枠です。採択されトークが行われることで、世界中の PHPer がメモリリークの心配なく long running な PHP スクリプトを安心して作ったり動かしたりできる、そんな夢のある世の中へ一歩近づくこともできます。
トーク内容そのものは PHP 処理系の内部状態をどう RDB のテーブル構造で表すかというマニアックな話が延々続くこととなります。
PHP スクリプトによる大道芸に興味のある方には、大道芸として面白く聞こえるかもしれません。
聞く人がほぼ全員置いてけぼりになるけれど喋ってる本人は妙に熱量が高いという、その温度差を眺めて苦笑いしたり、運が良ければ「こんな変なことやっていいなら俺も/私も変なことをやるぞ」と妙な熱量が伝染したような気持ちになることもできるかもしれません。

15年以上にわたり、社内の売り上げを支え続けてきた基盤システムが存在しました。
このシステムは、事業ドメインの変遷に合わせて不断に拡張され、事業の成長を支えてきました。
しかし、その結果として、巨大なモノリシックレポジトリ、仕様書の欠如、1ファイルに集約されたJavaScript、そして無数のマジックナンバーという問題に直面しています。
これにより、不具合の発生頻度増加、開発生産性の低下、追加開発の難易度上昇といった「技術的負債」が無視できない状況になりました。

本トークでは、これらの課題を解消すべく、fuelPHP（PHP version 7.3）から社内で標準的に利用されているLaravel（PHP version 8.2）へのリプレイスを実施した事例についてお話しします。

具体的には以下のトピックについて詳しくお話しします。

• リプレイスに際して最初に決定した事項とその理由
• プロジェクトの実現可能性を高めるために考慮したスケジューリング
• 開発環境の技術選定プロセスとその選定理由
• 基本的なアーキテクチャ設計のアプローチ
• リリース時に行った対応策
• リプレイス後に得られた具体的な効果

PHPに関する深い技術的な議論は難しいかもしれませんが、技術的負債を抱える皆様にとって役立つ情報を提供できれば幸いです。
ぜひ、このセッションを通じて、皆様のプロジェクトの成功につながるヒントを得ていただければと思います。

PHP は 1995 年から続く Web 向けプログラミング言語であり、30 周年を迎える今、技術の進化が著しい中で、PHP も大きく進化を遂げています。

PHP がこの世に生まれた頃、私はまだ 10 歳くらいの少年でした。
PHP が 30 周年を迎える今、世の中の何もかもがもはや当時とは違っています。もちろん私も 40 歳のオッサンになりました。

このトークでは以下のようなトピックへ触れつつ、2025 年の PHP プログラミングの現況を雑多な観点からまとめて紹介していきます。
・エディタをはじめとした開発環境
・今の言語機能を活かした典型的なコードの姿
・コードの部品分割方法、構成方法
・パッケージシステム
・静的解析や自動リファクタリングなどの周辺エコシステム
・実行環境の選択肢
・フレームワークの選択肢
・かつて PHP では不可能・不得意とされていた非同期処理や OS とのインタラクションなど

このトークを通じて、PHP 4 や PHP 5 の時代しか知らない人からすれば信じられないような、PHP 7 が出た 10 年前を知っている人が見ても少し意外に思うような PHP の現在の姿を知ることができるでしょう。またこれまで PHP をあまりつかったことがない人向けには、どういった言語機能やツールを前提に言語を使っていけばよいかを古い情報に惑わされずひと巡りできるような、簡単な手引となることを目指します。

私は2024年11月から新しい環境で仕事しています。
そして2024年12月現在、絶賛オンボーディング の真っ最中です。

ここで進めているオンボーディングを通して良かった点、改善したほうが良いとフィードバックした点などをお話しして、聞いてくださった皆さんがオンボーディング する時、される時に活かしていただきたいなという想いでお話しします。

私のエンジニアとしてのキャリアは、予想外の展開をたどってきました。皆さんのキャリアも、同様に多様な道を歩んでいるのではないでしょうか。

私がPHPerとしてキャリアをスタートさせたのは約4年前のことです。その後の道のりを以下に示します。
1年目
└既存サービスの運用開発（PHPerとしての開発）
2年目
└SREチームに所属し、コンテナ化や新規サービス立ち上げを経験
3年目〜現在
└新規サービスの立ち上げメンバーとして、インフラ〜アプリケーション開発を経験
└クライアントへのサービス導入アポイントメントに同席

このキャリアの道筋は、当初の予想とは異なるものですが、その中で得た「エンジニアとしての基礎技術」の重要性についてお話ししたいと思います。

特に、キャリアの選択に迷っている若手エンジニアや、新しい分野に挑戦したいと考えている方に、このトークはぜひお聞きいただきたい内容です。

CTOとして内製開発チームをゼロから立ち上げ、現在では社員・業務委託を含め約20名の規模にまで成長させてきました。このチーム拡大の過程では、採用難が叫ばれる時代の中、スキルやマインドを見極め、自社にフィットする人材を見つけることに真剣に向き合ってきました。
その一方で、採用活動ではさまざまな課題にも直面しました。理想の人材と巡り合えないことや、採用後に感じるミスマッチなどの試行錯誤を繰り返してきた中で、一つの有効な手法としてコーディング試験を導入しました。この取り組みによって、候補者の技術力や考え方をより深く理解し、チームに適した人材と出会う手ごたえを得ることができました。
本セッションでは、コーディング試験導入の背景や実際の運用方法、そこで得られた成果や課題、そしてそれを通じて得た学びを共有します。同じように採用の課題に直面している方々にとって、実践的なヒントとなれば幸いです。

◆対象者
・エンジニアの採用に関わるエンジニア
・新規の開発チーム立ち上げをしている人

◆話すこと
・なぜ採用プロセスを改善しようと思ったのか？
・PHPer採用の課題感
・技術力を客観的に評価する必要性
・テスト内容の作成
・実施してみた結果
・候補者の反応やフィードバック
・実施したうえでの改善
・どのようなポイントを評価したか
・採用プロセスにおける成果
・コーディングテストの有効性

皆さんはコードレビューしていますか？

コードレビューするとき、レビューイの気持ちを考えることはできていますか？
日々の業務に追われる中でコードレビューを行うとだんだんと相手の気持ちを考えることができなくなり、
時には厳しい言葉だけを投げてしまう状況になってしまい、レビューイのモチベーションを奪いかねません。

本LTでは、そんな忙しいあなたでも最低限のワーディングで相手をやる気にさせるコメントを厳選して紹介します！

「なぜこのコメントが良いのか」の解説も交えながら消化しようと思います！

案件や開発について相談する際に、何に困っていて、何を相談したいのか、
頭の中が混乱してしまう経験ありませんか？

このセッションでは、実際の案件でどのような開発メモを活用し、思考の整理に繋がったかご紹介します。
ここでの「開発メモ」とは、単なる作業記録ではなく、現在の状況や課題、解決策を明確にするための記録方法です。

【概要】

• 何がわからないのかわからないが続き、相談できず、失敗・苦労した経験
• 相談する際に、何に困っていて、何を相談したいのか思考をまとめる方法
• 思考を整理する際に、活用した開発メモの項目
• 実施後の変化

【おすすめの人】

• 新卒エンジニア
• エンジニア初学者