発表者は電子工作をする訳ではないのですが、書籍『雑に作る』が大好きです！
「下手っぴでもいいから、自分なりに動くものを作るのは楽しいよ」と、ものづくりの初期衝動を思い出させてくれる一冊でした。

部品選びから始めてゼロから作るのが難しくても、 「100均の商品を分解して、中身を見てみよう！」「改造できそうなオモチャのパーツを取り出して使ってみよう！」と
簡単に取り掛かれそうなアドバイスが、とてもたくさん書かれています！

部品も既製品も、安全にさえ気をつければどう使っても良し。分解して特定の機能だけを動かしたり、組み立て直すのも楽しい。
色々なモノが動いている仕組みを、そうやって自分の目と手で理解していくことは大きな学びをもたらすでしょう。
本書ではコレを「テクノロジーを自分のものにする」と表現しています。

同じことをソフトウェアでもやってみたら、絶対に楽しいし力がつきそうですよね！
本トークでは、身近なツールを「分解」して、へっぽこガラクタを作って遊んでみた体験を共有します。

こんな人におすすめ

• 普段使っているツールに「詳しくなる」きっかけを探している
• 設計力や実装力などの地力を向上したい・勉強法を探している
• 何かおもしろソフトウェアを作ってみたいが、発明のアイディアがない!!

こんな話をします

• 分解してみる、ガラクタを作ってみるの楽しさ・学習効果
• 「やってみた」話
  • 最初はどこから読めばいいの？どう進めるの？の紹介
  • PHP製のいくつかのツールを例に、どんな「分解」「再構築」を進めていったか
• この学習方法<遊び>で、身につく力
  • コードリーディングの力
  • エッセンスを理解する、抽象的に捉える力

PHPマニュアルって、マジで、マジでめちゃくちゃ読みやすくないですか？
駆け出しだったときにありがたかったし、なんなら今でも本当に感謝するレベルだし。あの丁寧さのおかげで今の私があります。
そんなわたしですが、2024年、はじめてPHPマニュアルの翻訳作業に貢献することができました・・・！

このトークでは、PHPマニュアル翻訳のOSSコントリビューション物語を通じて、「きっかけの掴み方」や「得られたこと」についてお話しします。

• その機能を知るきっかけになり、自分のためになる
• 「このページの一部を作った」という嬉しさ
• さまざまな貢献の仕方があることを実感する

使うものから、みんなで育てていくものへ。
このトークがあなたの素敵な一歩の後押しになることを目指します！

仕様確認の遅れや認識のズレで開発が滞ってしまった経験はありませんか？

私は「エンジニア↔︎営業」と「営業→ユーザー」の2つのフェーズで課題に直面しました。
「エンジニア↔︎営業」間では、話し合いが後回しになっていたため、仕様確認の遅れや認識のズレが原因で開発が滞りました。
「営業→ユーザー」間では、エンジニアが思い描くユーザーへのアプローチ方法が営業でうまく使ってもらえず、ユーザーへ価値がうまく届いていませんでした。また、営業にリリースした機能の価値が十分に伝わっていなかったこともありました。

そこで、以下の取り組みを行いました。
・ 何を決めたい時間かがひと目でわかる会議名をつける
・ リファインメントやランチで関係を深める
・ リリース後のアプローチ方法を営業と一緒に決める

このトークでは、エンジニアと営業が協力し、リリース後の価値を最大化するための取り組みと、その結果生まれた変化を紹介します！

テストコードを書く中で、「モックとスタブの使い分けが分からない」「どちらを使うべきか迷う」と感じたことはありませんか？その原因は、テストコードの書き方そのものではなく、オブジェクト設計の曖昧さに起因している場合があります。

本トークでは、モックやスタブを「どう使うか」を直接学ぶのではなく、オブジェクト設計のアプローチを通じて、結果として自然に正しい使い分けができる状態を目指します。

具体的には、次のステップを通じてオブジェクト設計を進め、テストコードを構築する方法を解説します：

1. 依存するオブジェクトを明確にする
2. コマンドメソッドとクエリメソッドを明確に分離する
3. システム境界を超えるときにモックやスタブを使用する

これらのステップを経ることで、モックとスタブの選択が「意図した設計の結果」として整理され、テストコードを書く際に迷う必要がなくなる状態になるでしょう。

「ライブラリが古いせいでやりたいことが出来ない」なんて経験はありませんか？

古いライブラリは技術的負債であり、セキュリティリスクにもつながります。
本トークでは定期的なライブラリバージョンアップを続けている実体験をもとに、継続的バージョンアップのメリットや始め方についてお話します。

想定観客

• ライブラリのバージョンが古いせいで苦しんでいるかた
• セキュリティやパフォーマンスに敏感なかた

お話しすること

• なぜライブラリをバージョンアップするべきか
• バージョンアップ時に見るべきポイント
• 安全に上げるために整えている仕組み
• 継続的バージョンアップのはじめ方と文化作り

Laravelの魅力の一つであるORM「Eloquent Model」。
雰囲気でも動くものが書けてしまう反面、実は正しく動かなかったり、パフォーマンスの悪いコードを書いてしまう恐れがあります。

本トークではEloquent Modelを使うときにハマりがちなトラップを取り上げて、それらが「良くない理由」と「どうすれば良くなるか」をご紹介します。

想定観客

• 雰囲気でLaravelを書いている方
• 不具合が起きにくいコードを書きたい方
• パフォーマンスの良いコードを書きたい方

お話しすること

• そのメソッド、返り値nullableにつき
• 全件取得による富豪的プログラミングにご注意
• データベース泣かせのN+1問題
• 良くある間違いを仕組みで防ぐ (Laravel IDE Helper x PHPStan)

東京都が主催するオープンデータハッカソンは、プログラミングスキルがなくても誰でも参加できるイベントです。このLTでは、私がこのハッカソンに参加し、運良くファイナリストに選ばれた経験を共有します。

このハッカソンの特徴は、技術的なスキルよりもアイデアや実現性を競う点です。そのため、技術的な話題が中心となることが多いカンファレンスの中で、少しリラックスできるセッションになるかもしれません。

作品についての詳細は、以下のリンクでご覧いただけます:
東京都オープンデータハッカソン作品
https://odhackathon.metro.tokyo.lg.jp/collection/106/

テストを書くことにもだいぶ慣れてきましたが、いまだに嫌で仕方ないものがあります。それがデータプロバイダです。

データプロバイダを書くのは面倒くさい。本当に本当に面倒くさい。
というのもリリース恐怖症の私は、テスト対象のありとあらゆる条件やパスを通したくなります。
「いや〜書かなくても大丈夫だろうけど、怖いし一応書いとくか…」を繰り返すうちに、どんどんテストパターンが増え、データプロバイダが膨大になります。

ここでは、私をそんな無限コピペ地獄から救ってくれた「差分だけデータプロバイダ」をご紹介します。
こちらは【ツールなど使わず手動で】【データプロバイダに】【少しずつ値を変えて大量のパターンを対照実験する】ための方法です。
同地獄に陥っている方の一助となれば幸いです。

⁠対象者

• いつもデータプロバイダが太りがちな方
• ツールなど使わず手動で、大量のパターンをテストしなければいけない方
• データプロバイダを書くのが億劫で仕方ない方

スクラム開発において「振り返り」と「スプリントゴール」は、単なるイベント以上の意味を持ちます。これらを形骸化させず、しっかり活用することでチームのパフォーマンスは大きく向上します。

本セッションでは、振り返りを通じて課題を具体的な改善アクションに変える方法や、スプリントゴールを設定する効果を説明します。

これらを実現した現場での成功例や失敗例を交えながら、スクラムの本質的な価値を掘り下げ、明日から実践できる具体的な方法論をお伝えします。スクラム開発を採用してもしていなくても、このセッションを通じてチームの開発プロセスを改善することができるでしょう。

「オブジェクト設計スタイルガイド」は、オブジェクト指向プログラミング（OOP）の設計と実装におけるベストプラクティスを網羅した優れた書籍です。スタイルガイドという名前の通り、明日からすぐに実践できる内容であるため、オブジェクト指向の基礎を理解している開発者にとって有益な参考書です。

本セッションでは、まずオブジェクト指向設計の基本概念を確認し、その後に書籍の具体的なコーディングスタイルを紹介していきます。以下はテーマとコーディングスタイルのサンプルです（番号は書籍によるものです）。

・2.1 2種類のオブジェクト
→ サービス層とドメイン層の役割とその違い（オブジェクトを呼び出す側と呼び出される側）
・2.3 サービスロケータを注入するのではなく、必要なもの自体を注入する
→ 依存性注入（DI）

・4.1　エンティティ：変更を追跡し、イベントを記録する識別可能なオブジェクト
・4.2　バリューオブジェクト：置き換え可能、匿名、イミュータブルな値
→ エンティティとバリューオブジェクトの設計（ミュータブル／イミュータブルの設計指針を含む）

・6.7　クエリメソッドからはコマンドメソッドは呼び出さず、ほかのクエリメソッドのみを呼び出す
・7.5　情報を収集するためにクエリを使用し、その次のステップに進むためにコマンドを使用する
→ CQS（コマンドクエリ分離原則）の基本と実践

本セッションを通じて、開発者がOOPの原則を理解し、それを適切に活用する知識を提供することで設計力の向上を目指します。

なお、本発表は「軽量DDDはもういらない！ スタイルガイド本で OOPの実装パターンを学ぼう」という発表を、より PHPer 向けに深掘りしたものです。
https://speakerdeck.com/panda_program/no-more-lightweight-ddd

サービスを作る上で、維持費と収益を獲得できるかどうかは、非常に重要な要素です。
StripeのDeveloper Relationsとしてユーザーや社内のプロジェクトに関わった経験と、
前職や個人開発におけるマネタイズに関する経験と想いを元に、ウェブサービスを開発する際のマネタイズ手法や料金モデル、そしてリリース後に発生しがちな請求管理に関するアレコレを紹介します。

トピックの例
・初期フェーズで決済・サブスクリプション機能の開発をやるべきか否か？
・開発工数と売上は比例しない話
・本当にあった、サブスクリプション請求管理で頭が痛くなる話

近年、急速に"(コードの)質と(質の高さからくる開発)スピード"が注目されるようになってきました。

一方で「何故、"質とスピード"を求めるのか」に対するお話はあまり見かけません。

このトークでは「兵法」から見た「"ソースコードの質"や"開発スピード"は何のために必要なのか？」、「"ソースコードの質"や"開発スピード"は本当に必要なのか？」についてお話します。

日本でも著名な「孫子の兵法」から現代戦で重視される戦術論「リズムとテンポ」などの観点から「市場を支配するために必要な"質とスピード"」に迫ります。

このトークで得られる知見

1 あらためて考える「なぜ"質やスピード"が必要なのか」
2 "質やスピード"を求める場合の基準
3 組織人として組織を持続可能にするために考える事

このトークで話さない事

1 孫子の兵法をはじめとした戦略論・戦術論の詳解

オブジェクト指向を学ぶ私たちは、必ず一度は「SOLID原則」に触れる機会があると思います。
私も何度も学習を重ねる中で、その原則がもたらす恩恵や、守ることの重要性を徐々に理解してきました。

…ただ、「リスコフの置換原則（LSP）」だけは「これを守るとどう良いのか？」がいまいちしっくりきていませんでした。
「同じ気持ち！」なあなたに向けて、このセッションでは、以下のようなお話をします。

・LSPとは何か？よくある例と「なぜピンとこないのか」
・実際に私が遭遇したLSP違反の具体例
・LSPと"継承"の関係性をしっかりと理解する

「なるほどLSP完全に理解した！」といってもらえるようなトークにします！

エンジニアとして始めると必ず知る概念、それが「デザインパターン」です（諸説あり）。
私は新卒の頃、輪読会としてデザインパターンの本を読みました。そして、その知識を持て余したものです。
”デザインパターンを勉強しよう”で知ったデザインパターンは、その適用に失敗することの方が多いように感じます。
「道具として自然に出てくること」が大事であること、そして「道具としてもう使われないものもあること」を認識するのが大切です。
普段使用するフレームワークやライブラリに出てくるデザインパターンを参考に、今でもよく使われるデザインパターンを紹介していきます。

話すこと
・デザインパターンとの向き合い方（共通言語として”デザインパターン”を知っておく）
・フレームワークやライブラリに出てくるデザインパターン
・好んで使わないデザインパターン

※GoFのデザインパターンのことを指します。