トーク

LaravelでのStripe APIの統合方法、特にサブスクリプション機能の管理とテスト手法にフォーカスし、実用的な実装例を紹介します。
またStripeのAPIを統合して課金を実装する内容を分けて説明します

1. CustomerPortalを利用する場合
2. CustomerPortalを利用せず、課金を実装する場合
3. Webhookをどう活用していくのか

このセッションは、以下の方を対象としたセッションになります。

• LLMとの付き合い方に悩んでいるPHPer
• 開発生産性を上げたいPHPer
• LLMを使った開発効率向上に興味があるがセキュリティ的な問題で導入に悩んでいるテックリード

GitHub Copilotを使ったコード補完や自動生成による開発効率化に加え、現在のリポジトリのコードを分析・説明するためのLLMの活用方法についても言及します。さらに、ローカルにLLMを導入し、開発環境内での活用方法・困りごとについても具体的な手法を解説します。

皆さんゴールデンパスという用語はご存知でしょうか？
ゴールデンパスとは「迅速なプロジェクト開発に役立つ巧みに統合されたコードと機能のテンプレート構成」になります。
凄く端折った説明としては開発プロセスのベストプラクティスを詰め込んだテンプレートリポジトリのことになります。
いざ新規プロジェクトを立ち上げようとした場合に使用するライブラリやテスト、開発環境、CI/CDなど多岐にわたり、考えることがあります。
登壇者が、いま現時点で考えているゴールデンパスの要素の数々を紹介いたします。

サーバーレスはサービスの基板側にてスケールが想定されているため、
パフォーマンスがでやすいアーキテクチャだと考えます

しかしサーバーレスを採用しているからといって、
必ずしもすべてのアプリケーションが高いパフォーマンスを発揮するわけではありません

利用するのはもちろんPHPで、環境はAWS
サーバーレスにおけるパフォーマンスチューニングについて計測と分析を行い、
結果を元に改善する流れの実践法についてお話します

サーバーレスのパフォーマンス最適化のための実践的な知識を共有することで、
パフォーマンスチューニングを実践できるようになる手助けができれば幸いです

• お話する内容

  • AWSリソースの最適化戦略
  • コードプロファイリングと分散トレーシング

• 対象の聴講者

  • サーバーレスに興味がある人
  • パフォーマンスチューニングが好きな人

話者は普段PHPをBrefというOSSを利用してAWSにデプロイしています。

一方で第三者が構築しているアプリケーションに対する不安を感じる方もいるはずです。

そこで今回はAWSが構築を行っているAWS Lambda Web Adapterを利用します。
この手法によりPHPerの皆様がサーバーレスの利点を享受しつつ、
従来のWebアプリケーションをシームレスに移行する手法を身につける事が出来ます。

AWS Lambdaの可能性を広げるWeb Adapterを利用した
サーバーレスPHPの普及に助力出来れば幸いです。

• お話すること

  • AWS Lambda Web Adapterについて
  • Laravelのデプロイ手順

• 想定聴講者

  • サーバーレスPHPに興味がある方
  • AWSを利用してPHPを利用している方

プログラミング界の十徳ナイフ、正規表現を使いこなせていますでしょうか！
正規表現は文字列処理において多くのタスクをこなせ、テキストエディタなどPHP以外の場でも利用できる汎用性の高い道具です。

しかしながら正規表現を自信をもって使えるようになることにハードルを高く感じる初心者も多く、曖昧なまま使い続ける中級者も多い技術でもあります。

このトークでは初心者向けの正規表現入門から、中級者にも役立つテクニック、Unicodeとの関連と正規表現の罠まで含めて、基礎を固めて使いこなせるようになるヒントをお伝えします。

登壇経験ありません!

新卒エンジニアとして、まずは新人研修でLaravel 11をゼロから学び、実践的なプロジェクトを通じて必要なスキルを養いました。
その後、初案件では環境構築や画面設計、メインコーダーとして開発業務に挑戦しました。

技術者としてだけでなく、見積もりや顧客とのミーティング、要件定義、PMやチームメンバーとの認識の共有など、多岐にわたる業務を経験し、コミュニケーション力や調整力を大きく伸ばすことができました。
さらに、課題解決に向けたコミュニケーションやスケジュール管理、プレッシャーへの対応を通じて、プロジェクト完遂に必要なスキルを幅広く習得しました。

当日は、研修で取り組んだ内容から、初案件で直面した課題やそれをどう乗り越えたかについて、具体的な事例を交えてお話しします。
これからLaravelに挑む方や新卒エンジニアにとっても役立つリアルな体験談をお届けします！

約2年の間、私は新規プロダクトの開発責任者としてプロダクトの完成を目指してマネジメントを行っていました。

チームの発足当時、社内には該当プロダクトに関するドメイン知識がほとんどなく、「そもそもプロダクトとして成立するのか？」といったところの検証から繰り返しながらの進行となりました。

そのくらい不確かな出発点ですので様々なハードルに見舞われます。
増えゆく要件、進まない開発、ぶれるプロダクトの定義......。

しかし蓋を開けてみれば、特に本番リリースまでの半年間の間、社内の既存のどのプロダクトよりも生産性（ここではリリース頻度を指します）高く開発をすることができていました。

一体何が功を奏したのか？

本発表ではその要因となった考え方や具体的な取り組みを、新規プロダクト開発の試行錯誤の中で得た知見とともにお届けします。

みなさん、PHPのテストを書くときに「他のクラスや依存関係のせいでテストが難しいな…」と思ったことはありませんか？
そんなときに役立つのが、PHPのモックフレームワーク Mockery です！

Mockeryを使えば、依存するクラスやインターフェースの動作をモックして、テストをもっとシンプルに、効率的に進められます。このトークでは、Mockeryの基本的な使い方から実際の業務で役立つテストケースまで、具体例を交えて解説します。

取り上げる予定の内容はこちら！

モックを使ったメソッド呼び出しの検証方法
高度な引数の比較を使った柔軟なテスト
実務でのテストケースの実例紹介
Mockeryを使えば、テストのストレスが軽減され、もっとスマートにテストが書けるようになります！ぜひ参加して、PHPのテストを楽にする方法を学んでください！

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

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

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

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

• サービス層とはそもそも何なのか
• 憎まれるサービス、愛されるサービスとはなにか
• 理想のサービス層とはどんな姿をしているのか

について、SOLID原則、特にSRPを切り口として理想的なサービス層について考察したいと思います。

みなさん、モックは好きですか？わたしは好きです。
外部依存から隔離してテストの実行を容易にしたり、テストを高速化できるからです。最高。

ですが、わたしが観測している限りどうやらモックというのはテストが壊れやすくなるので、なるべく使わない方がいいという風潮も耳にします。
ではテストが壊れにくければモックは使っていいのでしょうか。モックを使うとテストが壊れやすくなるのでしょうか。善いモックというのは無いのでしょうか。

そういった疑問を解消すべく、果たしてモックは悪いのか、善いモックというのはあるのか、モックの使い方はどうあるべきかをお話できればと思います。

キーワード

• 壊れやすいテストとは何か
• 実装の詳細が漏れるとは何か
• ロンドン学派vs古典学派
• アウトサイドインvsインサイドアウト
• モック、スタブ、スパイ
• モックとしての振る舞いとスタブとしての振る舞い

本セッションは、Laravelを使って現場でCIをぶん回すエンジニアを対象に、CI/CDパイプラインのベストプラクティスを紹介します。

PHPUnitとParatestなどを活用し、テスト時間を短縮しつつ、GitHub Actionsでコストパフォーマンスを最大化する方法を具体例とともに解説します。

⚪︎ CIの高速化
⚪︎ 効率的なリソース管理
⚪︎ カードで必要な変更

を交えつつポイントを共有します。

みなさん、ドメインイベントって使っていますか？

このトークでは、ドメインイベントを使ってPHPコードをリファクタリングする方法についてお話しします。ドメインイベントは、ビジネスドメインで発生する「出来事」を表現するモデルで、これをうまく使うことで、副作用をわかりやすく整理し、システムをシンプルにできます。

ドメインイベントを導入してみると、「あ、こんな風に設計すれば良いんだ！」と新しい発見があるはずです。リファクタリングを通じて、どうやってドメインイベントを設計し、活用するのか、その具体的な手法をお伝えします！

話すこと

• ドメインイベントって何？
• リファクタリングでドメインイベントをどう導入するか
• システム間の連携を簡単にするイベントの使い方

OOP はクラスやオブジェクトというものを前提としています。また、「抽象化」や「一般化」「共通化」というような用語がプログラミングでは普通に使われます。
OOPの設計・実装では「こう書けば後からうまくいく」式の解説ばかりですが、その実OOPの本質に立ち向かったものは少ないのではないでしょうか。

本発表では、西洋哲学の知恵を借りてOOPという営みを捉え直すというチャレンジをします。
最初に「クラスはプラトンのイデア論に似ている」というOOP界隈で真っ先に言及されるこの命題が真か偽か考察することから始めます。
プロポーザル執筆時では、プラトン、アリストテレス、カント、ウィトゲンシュタイン（後期）には言及する予定です。
なお、アラン・ケイの考えていた本当のオブジェクト指向にも言及する予定です

■ 発表内容
「オブジェクト設計スタイルガイド」という書籍の良さについて熱弁します。

スタイルガイドという名前がついているものの、その実はOOPの設計のベストプラクティスを集めた設計・実装集です。
この本は頭から一つずつ書き方を見ていくだけで、自然と以下の重要概念が身につく優れた書籍なのです。

・サービス層とドメイン層の違い
・SOLID原則
・クリーンアーキテクチャ
・CQS（コマンドクエリ分離原則）
・エンティティ・バリューオブジェクト（もちろんミュータブル・イミュータブルの考え方も）
・ドメインイベント
・DI
・リファクタリング

OOPのベストプラクティスを学ぶことができる新時代の「リーダブルコード」と言っても過言ではないでしょう

チームでこの本の読書会を実施しているので、そこで出てきた「現場の意見・疑問」もお伝えします（発表時には終了予定）

　PM Aさんこれから一緒にプロジェクト頑張ろうね
私は初めてプロジェクトに参画することになった
　PM じゃあ次Aさん進捗どうですか？
進捗を聞かれてもいつでも答えられるし、開発はスケジュール通り開発できている。何も問題はない。
　PM Aさんいつもオンスケで助かるよ。お陰でプロジェクトも順調だよ。次この機能開発してくれる？
プロジェクトのことはよくわからないけど、プロジェクトも順調らしい。
「あれ？でも、この機能って前にやった機能といっしょに開発したほうが早かったな。それに前カンファレンスで聞いた〇〇って技術使えばもっといい感じにできたかもな。」
「でもテックリードでもPMでもないし、機会が回ってきたときでいっか」
本当にそれでよかったのでしょうか？
本セッションでは、メンバー目線での情報がプロジェクトの成功にいかに重要であり、メンバーだからこそ貢献できるテクニックを話します。

現代において、エンジニアの仕事は常にチームで行われます。
チームで仕事を進める以上、他人との「意思疎通のスピード」が、チーム力に直結してしまいます。

チーム力を上げるために、組織ではさまざまな施策が実施されているかと思いますが、エンジニア個人でできる意思疎通のテクニックについて考えたことはないでしょうか？
チームで行われているコミュニケーション施策に乗るだけでなく、自らコミュニケーションを円滑に進められるよう能動的に動くことで、チームの力をもっと上げることができます。

本発表では私が仕事で実践している内容をもとに、明日から使えるチーム力向上を目指したコミュニケーションのテクニックと考え方をお伝えします。
これを聞けば、明日チームメイトから「ちょっと変わったね」と言われること間違いなし！

我々はのチームはつい最近結成されたら新チームです。チームも未熟でありながら何を作るかも決まっていませんでした。
そんなチームが顧客の要望に応えたい気持ちはあるものの人手も多いわけではないのでできることは限られます。

しかしこのチームが爆速にプロダクト開発をしています。
どんどん動くものができており、スプリントを進めるたびに機能は増えていき、スプリントレビューで改善のフィードバックをもらっています。

どのように開発を進めているのか、意識していること、テクニック、秘訣を教えます！

新しいチームやプロジェクトに参加した際には、まずシステム全体を大まかに理解することが重要です。これはすべてのコードを理解するわけではなく、システム全体の構造やその役割を把握することです。全体像を理解することで、自分の担当機能がどのようにシステム全体に影響を与えるかを見通せるようになり、自信を持って開発に取り組むことができます。この知識は、バージョンアップ対応やパフォーマンス改善、アーキテクチャ変更など、システム全体に影響するタスクで特に重要です。

本セッションでは、初見の PHP アプリケーションの全体像を掴む方法を紹介します。

このセッションでは、以下の内容を含む予定です。

• ビジネスにおけるアプリケーションの立ち位置
• PHP、拡張、パッケージの把握
• Xdebug デバッガでの追跡
• アプリケーション IO を見る

ソフトウェア開発において、顧客理解や問題発見は、しばしばPOやデザイナーの役割とされます。しかし、私たちのチームは「解くべき課題について誰も具体的なイメージがない」という状況に直面し、チーム全員で顧客への理解を深めることを選択しました。

本セッションでは、PO1名とエンジニア2名で構成された新チームが、全員でペルソナを考え、ユーザーインタビューを実施し、プロトタイプを作成・検証するプロセスを共有します。そして、この取り組みを通じて、素早いアウトプットの重要性を再認識できた経緯について、エンジニア目線でお伝えします。

主な内容：

• チーム全員で顧客理解を深めるための具体的な進め方
• エンジニアが顧客理解を深めることの意義と効果
• 素早いアウトプットを出すために私たちができること

本セッションを通じて、エンジニアが顧客理解を深めることの意義について考えるきっかけになると嬉しいです。