プロポーザル

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

お話しする内容:

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

PHPでの開発に慣れてきた若手エンジニアが次に直面するのは、「何をどう学べばいいのか分からない」という壁です。MVCフレームワーク、リファクタリング、SOLID原則、ペアプロ、ユニットテスト、アジャイル開発といった開発に関する考え方や実践はどこから生まれ、なぜ今も大切にされているのでしょうか？

本セッションでは、ケント・ベック、マーティン・ファウラー、ボブおじさん、DHHといった人物を中心に、それぞれの技術や手法が生まれた背景、当時の課題、そしてそれらがPHPを含む現在の開発スタイルにどう影響を与えてきたのかを、歴史の視点から紹介します。

こうした知識は本来「デキる先輩」が後輩に伝えてきたものでした。しかし、周囲にそのような先輩がいない場合もあると思います。このセッションでは、現場の課題を解決するために必要なことを効率よく学ぶための「知識の地図」を提供します。

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

皆さんは、ご自身が書いたコードがPHPによってどのように解析され、有効な構文として認識されているか気になったことはありませんか？
この発表では、構文解析の理解を深め、文法ファイルを読み解くスキルを身につけることで、
PHPの文法をより深く知るきっかけにしたいと思います。

話す内容は以下のことを予定しています：

• パーサーとパーサージェネレーターの基礎知識
• 文法ファイルとbison/yacc形式のBNFの読み方
• 実際の文法ファイルのBNFを眺めながら実際に読む

この発表の対象者は、PHPの構文解析のしくみに興味を持つすべてのPHPerです。
この分野の知識がない方でも理解できる内容にします。

構文解析器の分野は非常に興味深く、言語設計の奥深さを知る入り口となります。
この発表を通じて、少しでも多くの方がこの分野に興味を持っていただけることを目指します。

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

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

「オブジェクト設計スタイルガイド」は、オブジェクト指向のパワーを引き出し、クリーンなコードを書きたいPHPerにとって必読の書籍です。本セッションでは本書の内容を紹介しつつ、チーム全員の目線が揃うアプリケーション設計やクラス設計に役立つ考え方を紹介します。

本セッションで紹介すること
・Service、EntityとValue Object、DTOの使い分け
・クエリメソッド・コマンドメソッド・モディファイアメソッドの違い
・インターフェースの作成基準

本セッションを通して理解できること
・MVCフレームワークから疎結合なアプリケーションとは何か
・サービス層とドメイン層という言葉が意味すること

本セッションに参加された方が現場に持ち帰って実践できること
・クリーンなコードを書くこと
・レビュー時にコードの良し悪しを言語化できること
・AIが出力するコードを採用するか判断できること

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

PHPでResult型（クラス）を再現してみるセッションです。
Result型とは、処理結果を「成功（Ok）」または「失敗（Err）」のいずれかの値として表現し、例外を使わずにエラー処理を構造的に記述するための手法です。

本セッションでは以下について話す予定です。
・Result型（クラス）の説明
・PHPでResultを実現するとどんな感じになるのか（コード例を交えて解説）
・自分なりに考えるPHPでResult型（クラス）を使うメリット・デメリット

多くのレガシーな PHP コードベースでは、インスタンスクラスを使わず、静的メソッドを関数のように扱うスタイルが一般的に採用されてきました。

しかしこの設計は、特にユニットテストの観点から見ると、静的メソッドのモックが難しいという課題があります。一般的なテストフレームワークでは静的メソッドのモックがサポートされておらず、そのため開発者は StaticMock のようなライブラリに頼る必要があります。

ただし StaticMock では、モック対象のメソッドが静的解析されないため、IDE のコードジャンプ機能が効かないといった不便さがあります。

そこで注目したいのが、PHP 8.1 から導入された「第一級 callable」構文です。これを使えば、静的メソッドをクロージャとして渡すことが可能になります。

本トークでは、この新しいアプローチとその実践的な活用方法について紹介します。

本LTではAWS Lambdaを題材にLambdaで開発したアプリケーションにおけるセキュリティリスクの1つの解説し、そのリスクをみなさんにも体験していただきます。
お手元に用意いただくのはスマートフォンのみです。

5分でセキュリティリスクを体験してみましょう。

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

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

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

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

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

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

対象者

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

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

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

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

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

ジョシュアツリーの法則って知ってますか？
「名前を知ればそれを認識できるようになる」「名前を知らないと認識できない」といった現象のことです。

我々エンジニアの身の回りには様々な現象があり、中にはみんなが経験したことがあるものも多数存在します。
そんな「現象」や「事象」の中にはあまりにも名前が付けられ、事象の解消や共有が行われているものがあります。
名前を知ることは認識すること！
この発表を聴いてそんな""あるある""の名前を知り、事象を正しく認識して、次に生かしましょう！

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

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