トーク

歴史的にコーディングツールは、高機能なIDE(統合開発環境)とシンプルなテキストエディタに大別されます。
コンパイルが必要な複雑な言語と対比して、PHPのようなスクリプト言語はシンプルなテキストエディタでも開発できる単純な言語と考えられていましたが、昨今ではPhpStormのような複雑なIDEの機能も求められています。

本トークではPhpStormなどがどのような機能を備えているか、EmacsやVS Codeといったツールでどこまで肉薄できるかを追求します。

Gitの仕組みについて解説しつつ、git addとgit commitするまでをPHPのコードでどう実現するかを話します。

話す予定
・Gitでファイルを保持する仕組み（Blobオブジェクト・Treeオブジェクト・Commitオブジェクト）
・git addをPHPで実現するには
・git commitをPHPで実現するには

本セッションではMatthias Noback 氏が著者の「オブジェクト設計スタイルガイド」を通じて、ドメイン駆動設計での手法について入門する発表になります。
まずは、「オブジェクト設計スタイルガイド」を通して学べる「意味あるオブジェクトの作り方」や「ふるまいを持つクラス設計」の考え方を振り返り、そこからドメイン駆動設計で登場するエンティティや値オブジェクト、ユビキタス言語といった基本概念とのつながりを解説していきます。
具体的には以下の内容を通じて、現場での活用方法について紹介します。

• 小さな設計改善が、どうやってドメインモデリングにつながるのか
• PHPでの具体的なコード例（ValueObject、Entityなど）
• 「まずどこから始めればいいの？」という現場向けアドバイス

PHP-Parserを利用すると、PHPのコードを抽象構文木 (AST) に変換したり、逆にASTをソースコードとして出力したりすることができます。

ASTの一部を書き換えることもでき、たとえばRectorはこれを利用してソースコードの書き換えを行います。

この技術を利用すると、PHPコードをminifyすることも可能です。
minifyはソースコードの空白の除去や変数名の短縮などにより、ソースコード全体のサイズを圧縮することです。JavaScriptやHTML、CSSでは、ブラウザ↔サーバー間の転送量削減のためによく行われます。

WASMを使いブラウザ上でPHPを動かす事例も増えている昨今、PHPコードをminifyしながらASTの力を感じてみませんか？

想定観客

• 抽象構文木を知らない人
• ASTが何の役に立つか分からない人
• PHPをブラウザで動かしている人

「このAPIエンドポイントは絶対に個人情報を返さない」…
そのはずが、ある日、意図せず個人情報を含むレスポンスを返してしまっていた。
考えただけでも恐ろしいこの事態は、残念ながら実際に起こりえます。
本セッションでは、私たちが経験した「個人情報を返してはいけないAPI」から、予期せずそれが返却されてしまったインシデントの事例を共有します。
気づくことができなければサービスが潰れかねませんでした。なぜそのような設計・実装上の欠陥が見過ごされたのか？ どのようにして問題を発見し、インシデントとして対応を行ったのか？
そして最も重要な、具体的な再発防止策として何を導入したのか（テスト戦略の見直し、静的解析、コードレビュープロセスの強化、監視アラート設定など）を、原因分析から得られた教訓と共にお話しします。
対岸の火事ではない情報漏洩リスクに対し、明日から実践できる防御策のヒントを提供します。

Laravelでの検索実装、「全文検索」と「セマンティック検索」の選択に迷っていませんか？
それぞれに利点があり、プロジェクトの特性に合わせた最適な選択が求められます。

本セッションでは、Laravel Scoutによる使い慣れた全文検索と、Typesenseなどを用いた高精度なセマンティック検索と検索のテスト手法についてお伝えします。
具体的な実装パターン、気になるパフォーマンスの違い、導入から運用までのコスト感を、コード例を多めに交えながら比較検討します。
「結局、自分のプロジェクトにはどちらが合うのか？」その疑問に明確な答えを出す、実践的な選択ガイドラインとインデックス戦略や関連性チューニングといった、導入後の運用で直面しがちな課題と具体的な対策も共有します。

AIコーディング、興味はあるけど「月8万」「金が溶ける」なんて話ばかりで尻込みしてしまう…。実際ちょっとコードを書かせただけで数ドル請求される…。

でもゲームも買いたいし焼肉も食べたい…、学生ならそもそも収入がない…。

そんなあなたに届けたい！ お金をかけずにAIで遊ぶサバイバル術！

お金は節約したいけどAIコーディングを使いたい人のために、安くAIと戯れるための抜け道・裏道・けもの道を紹介します。
仕事でそのまま使えないけど 未来を感じてもらいます!

同時に、LLMやAgentといった用語なども解説予定です。

金をかけずにどこまでAIと遊べるのか？
お金をかけない代わりに、何を差し出すのか？（ヒント：創意工夫、時間、あるいは電気代？）
ご期待ください！

※ 日々進化する話題なので、内容は変わるかもしれません。完全無限無料AIがきてたらどうしよう。

PHPのコードをほとんど書いたことがないPHP初心者の私が、ひょんなことから「PHPでGoogleTVを制御しよう」と思い立ち、悪戦苦闘する(?)様をお話しします。

お話しする内容:

• GoogleTVをPCから制御する方法
• PHP初心者がハマったところ

「不確実性コーン」という概念を知っているでしょうか？これは、ソフトウェア開発における不確実性を象徴する理論で、プロジェクトの企画段階で見積もられた工数が、最終的にその4倍から1/4に変動する可能性を表すものです。アジャイル開発の文脈において、開発の複雑性と、開発プロセスの柔軟性を支える理論として広く引用されています。しかし、この「不確実性コーン」という概念は本当に正しいでしょうか？あまりにもエンジニアに都合がよすぎるのではないでしょうか？
　本発表では、この「不確実性コーン」の歴史的背景を紐解きます。この「不確実性コーン」は誰がどのような形で発表したのか。この「不確実性コーン」を描くために、どのようなソフトウェア開発が参考にされたのか？
　「不確実性コーン」を現代の視点から再確認します。そして、古典的なソフトウェア開発の見積りについて再考してみます。

スクラム開発において「振り返り」と「スプリントゴール」は、単なるイベント以上の意味を持ちます。これらを形骸化させず、しっかり活用することでチームのパフォーマンスは大きく向上します。本セッションでは、振り返りを通じて課題を具体的な改善アクションに変える方法や、スプリントゴールを設定する効果を説明します。

これらを実践した現場での成功例や失敗例を交えながら、明日から実践できる方法論をお伝えします。また、もしスクラム開発を採用していなくても、このセッションを通じてチームの開発プロセスを改善する手がかりが得られるように紹介します。

最近、「なぜ動くか説明できないコードをプッシュしていた」自分に気づかされました。
レビュワーの指摘を受けて初めて「この中ってこうなってたのか」と気づいたり、それをスラッと追う先輩への驚きを感じたのを覚えています。
そこで、自分なりに「ちゃんと読めていない」原因や改善策、コードを書く上での行動を振り返りました。
結果として、バリデーションの中身を理解した上で既存コード修正→マージまで持っていくことができたので、
本トークでは上記を通じて見つけた、以下手法についてお話しします。

• 「読めたつもり」を防止する読み方
• 「説明責任を果たすコードが書けたか？」を問うセルフチェック方法

ぜひ聴いていただきたい層

• 自分のように「感覚で読んでいる」「読めたつもりが起こる」といった悩みを抱えた初学者
• 後輩や新人とコードを読む／レビューする立場の先輩やベテラン

ブログであれば『下書き』や『公開』、『承認待ち』など、様々な状態を持っているデータがあります。
その状態はサービスの至るところで更新する機会がありますが、思ってもいない状態に遷移して
開発後に頭を悩ました経験がないでしょうか？

そんな"状態遷移"に悩まされた経験談と、それを一元管理する『ワークフロー』の導入と開発、
それによって得られた恩恵についてお話しします。

かつてLaravelプロジェクトにドメイン駆動設計（DDD）を導入したものの、
期待した効果が得られず、プロジェクトは思うように進みませんでした。

その当時は以下のような課題がありました。

• いわゆる軽量DDD的なものにならざるを得なかった
• 開発工数が増えるばかりで効果を実感できなかった
• チーム内での理解が進まなかった

このセッションでは、DDDがうまく機能しなかった理由や直面した課題を振り返り、
改善のためにどのようなアプローチが有効かを考察・共有します。

さらに、Kent Beck氏の著書『Tidy First?』が、私の経験を言語化し理解を深めてくれたことについても紹介します。

本セッションはDDDを否定するものではなく、実践の中で得た教訓と再挑戦のヒントを共有することを目的としています。
DDDを活用するための一助となれば幸いです。

約10年間事業を支えてきたLaravel製のシステムを関数型スタイルでリファクタして得られた知見を話すセッションです。

「背景」
事業とともにシステムが成長していくなかで技術負債も多く抱えることになり、その結果システムの認知負荷が高まってしまいました。
そんな現状を改善するため、「関数型ドメインモデリング」の要素を取り入れて一部リファクタリングを実施しました。
本セッションでは、その活動のなかで得られた知見をお届けします。

「注意点」
PHPで関数型を再現する訳ではなく、関数型プログラミングの中でPHPで取り入れられる要素を使ってリファクタリングを行っています。

■背景
決済プロダクトのバックエンドエンジニアをしています。
これまでずっとJavaで開発をしていましたが、プロダクトの面白さに惹かれてPHPを技術スタックとしている会社に転職しました。

■テーマ
今では転職して約1年が経ちます。
別の技術スタックからPHPをベースとしたシステムの開発現場に入るとどんな大変さがあって、それをどう乗り越えてきたかを経験からお話します。

■ポイント
・コードを読んでアウトプットする
・ローカルルールを学ぶ
・テストコードと向き合う
・PHPの良いところ
・Javaの経験が活きた場面

知らず知らずのうちに技術的負債が溜まっていませんか？機能追加のたびに修正箇所が広範囲に及び、テストもままならない……。その原因の一つは、 SOLID原則への理解不足や誤解にあるかもしれません。

SOLID原則はソフトウェア開発において保守性の高いコードを書くための重要な原則の一つですが、難しい言葉が並んでいて理解が難しかったり、誤解されやすい面があります。

本トークでは、SOLID原則についてアンチパターンやPHPでの実践例を交えながら解説し、その活用方法やメリットについてお話しします。このトークを聞けば、より変更に強く、テストしやすい、自信を持てるPHPコードを書くための第一歩を踏み出せるはずです。

対象者

• SOLID 原則？何それ知らないよ！って人
• SOLID 原則は聞いたことあるけどよくわからん、って人
• SOLID 原則、完全に理解したけど実践できていない人

仕事の内容をドキュメント化することで得られるメリットはたくさんあります。

多数の人に内容を共有できる
言った言わなかったの議論にならない
後から見返して経緯がわかる
しかし、実際にドキュメントに起こそうとすると面倒に感じ、なかなか実行に移せていない人も多いのではないでしょうか？
また、チームメンバがなかなか仕事内容をドキュメントに起こしてくれず、困っているマネージャーもいることでしょう。

たしかに、物事をドキュメントに起こすことは面倒です。
しかし、逆にドキュメントへ起こさないことによってどのような問題が発生するかを知ることができればドキュメントに起こす気になるのではないでしょうか？

この発表では、仕事内容をドキュメントに起こさないことで発生するデメリットとその改善方法の具体例を示し、なぜドキュメント化をする必要があるのかを説明します。

ローンチから2年が経ち、最低限の機能が一通り揃ったプロダクトにおいて、次に取るべき行動は何か...

プロダクト立ち上げ直後は、ユーザへ価値を提供できる最小限の状態を目指して開発を進める必要があります。しかし、その後はどうすればいいでしょうか？
私が担当する保育園探しのプロダクト「えんさがそっ♪」では、立ち上げ当初に予定していた機能が大体揃い、次に進むための検討を始めたところでした。
これにより、次の一手をビジネスチームと一緒に考えることになりましたが、ビジネスサイドからの要求を実装することがメインの仕事であった開発チームが主体的に動けるようにするためには、いくつかの仕掛けが必要でした。
複数のサービスを運営する組織の中で、率先してプロダクトを次に進めるチームをつくるために行ったこととその考え方をお話しします。

レイヤードアーキテクチャをはじめとした多くのレイヤ化アーキテクチャでは、依存の逆転を用いてレイヤレベルで技術的な関心を分離しています。
なぜこれがアーキテクチャとして好ましい構造につながるのでしょうか？

このセッションでは、技術的関心を分離することが実利に結びつく理屈を変更コストや優先順位、認知負荷などの観点から全力で考察し、いわゆるインフラ層についての理解を深めることを目指します。

概要

DevinはCognition AI社が開発した自律型AIエージェントです。
使いこなせれば便利なのは想像がつくけれども、ついつい自分で書いてしまう癖が抜けない。
このままでは全く習得できず、変化に適応できない焦りから、とあるAPI実装をDevinでやりきる意思を持って挑んでみました。
果たしてその結末やいかに。

ターゲット

• Devinに興味はあるけど、手を出せていない方
• Devinの実際の使用事例を知りたい方

お話すること

• Devinに依頼したタスクの概要
• Devinがうまくやってくれたこと
• Devinが苦手なこと
• Devinが生み出した成果
• 今後のDevinとの付き合い方