レギュラートーク(20分)

7年経ったプロダクトにデザインシステムを導入!ゼロからの画面制作を卒業して開発効率アップ

halmin51g はるみん

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

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

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

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

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

話す内容

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

こんな方におすすめ

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

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

6
採択
2025/03/22 14:30〜
Track B
スポンサーセッション(20分)
スポンサーセッション

機能不全改善を目指したチームビルディングの実践

nagi125_dev 野末 敏

「Chatwork」はサービスが誕生してから今まで主要なところで PHP を利用し続けており、誕生してまもなくに書かれたコードも未だにメンテナンスし続けています。

私が所属しているチームは、そのメンテナンスに加えてEOL 対応やミドルウェアのアップデートなどを担当することが多く、長らくそれらをメインの業務としてきました。
また、その業務に加えてアラート対応やトラブル対応等のイレギュラータスクを多数対応する必要もありました。
チーム内では仕組み化や対応手法の標準化など、イレギュラータスクとうまく付き合いたい思いはあり様々な検討を行いましたが、今まではなかなか良い結果に繋がりませんでした。

このセッションでは上記のチームにおいて、自ら問題を認知して改善サイクルを回すことができるようになったプロセスやアクション、チームビルディングについてお話します。

4
レギュラートーク(20分)

レガシーコード改善の第一歩:まずはチームを改善してみませんか?

yu_mashirou 柚口ましろう

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

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

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

話すこと

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

話さないこと

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

想定聴講者

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

プロジェクトリーダーをやることになる/なった人におすすめしたい本を時間の許す限り紹介する

aki_artisan あかつか

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

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

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

紹介する本の領域

  • プロジェクトマネジメント系
  • リーダーシップ系
  • 開発組織系
  • 品質管理/テスト系
採択
2025/03/22 15:40〜
Track C
レギュラートーク(20分)

PHPから考える クレジットカードにおける3Dセキュア決済

theyoshida3 よしだ

ECサイトでのオンライン決済は当たり前の時代となっています。
オンライン決済の中でもクレジットカードでの決済を利用した方はかなり多いのではないでしょうか。
しかし今、クレジットカードの不正利用が問題となっており、経済産業省は2025年3月31日までに3Dセキュア2.0の導入を義務化しています。
3Dセキュア2.0とは何なのか、何を考慮すればよいのかをLaravelとStripeをサラッと使いながら軽く説明します。

6
レギュラートーク(40分)

PHPで物理エンジン(PHPysics)を作ってみた

aki_artisan あかつか

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

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

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

話すこと

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

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

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

採択
2025/03/21 16:20〜
Track A
LT(5分)

コードゴルファー道

m3m0r7 めもりー

皆さんはコードゴルフというe-スポーツ(※)についてご存知でしょうか。本来のスポーツであるゴルフはスコアを低くしていくことを求められるワケですが,コードゴルフも同様に短くコードを書くことが求められます。アルゴリズムやパフォーマンス,コードの視認性などは関係ありません。いかに短く書くかが重要です。
さて,そんなコードゴルフを楽しむために,本セッションではコードゴルフの基礎から,どのようにコードを短くしていくかテクニックを含めて,そしてあなたが将来のコードゴルファーとして一人前になれるように LT で解説していきます。

※ 筆者の見解であり,非公認です。

レギュラートーク(20分)

テストコードも仕様書もない20年モノのシステムを安全にリプレースできた方法論

aki_artisan あかつか

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

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

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

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

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

PHPerが語る、開発環境アンチパターン

theyoshida3 よしだ

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

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

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

レギュラートーク(20分)

チームパフォーマンスを改善するコードレビュー!プルリクエストのベストプラクティス

taclose 前田啓佑

トーク概要

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

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

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

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

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

話さない内容

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

想定読者

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

PHP スクリプトのメモリ内容を SQL で問い合わせる

sji_ch sji

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

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

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

6
レギュラートーク(40分)

技術的負債を解消する!モノレポからの脱却とLaravelへの移行事例

mikisoftworks yoji.miki

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

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

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

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

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

レギュラートーク(40分)

モダン PHP プログラミング 2025

sji_ch sji

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

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

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

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

採択
2025/03/22 16:15〜
Track A
レギュラートーク(20分)

20分1発勝負! 社内Webツールをライブコーディングするぞ!

rela1470 Jun Watanabe

今すぐ社内用のWebツールを作らなくてはいけなくなったので、いまからこの部屋で、20分だけ仕事をさせてください!

2025年現在、OpenID Connectが多くのIDプロバイダーに実装され、とても良い時代になりました。
PHPでのライブラリも多くあり、OktaやOneLoginなどを社内で使っている方なら、すぐに社員にアクセスを限定した簡単なWebサービスを作成可能です。

今回は、OpenID Connectで社員情報を認証、認可するところまでをBref(serverless on AWS Lambda)でライブコーディングし、
20分で社内Webツールが初心者でも簡単に作れるところまでを実践します。

みなさん、もっと気軽に会社のアカウントで認証認可、やっちゃいましょう!

3
LT(5分)

オンボーディング される技術

yamato_sorariku 足利大和

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

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

1
LT(5分)

PHPerからのキャリア変遷:意外な道のりで学んだ大切なこと

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

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

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

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

3
レギュラートーク(20分)

PHPerチームを育てる:採用力を高めるコーディング試験導入の舞台裏

kunikiya 原田裕介

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

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

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

採択
2025/03/23 16:35〜
Track A
LT(5分)

PHPStan をできる限り高速化してみる

zeriyoshi ぜり

非常に便利な PHPStan ですが、大規模プロジェクト、特に Laravel を採用したプロジェクトだとものすごく時間がかかってしまったりすることも多いかと思われます
そんな PHPStan を様々な手法を用いて高速化を試み、最終的にどうなったかをライトニングにお話してみたいと思います

8
LT(5分)

相手をやる気にさせるレビューコメント3選

unan

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

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

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

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

6
ルーキーズLT(5分)

何がわからないかを、わかる状態にする思考整理術

けんと

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

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

【概要】

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

【おすすめの人】

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