プロポーザル

DIを理解するのは難しいです。

経験の少ない開発者にとっては、コードが読みづらく感じて開発を遅くする原因となり、ベテランにとっても、メンバへの伝え方が難しいために導入を見送らざるを得ないということもあるかもしれません。

このトークでは、依存という概念を「使う・使われる」という、簡単な言葉で整理して、理解しやすくすることを目標とします。

話すこと

• 「依存している」とは「使っている」ということ
• 依存すると何が困るのか
• 依存を外から与える(注入する)メリット

小さくコツコツ手をつけておけばよかった…そんな気持ちになることもあるかもしれません。。
日々降ってくる、マイナーバージョン・パッチバージョンの更新を適応するのはとても大事です。

メジャーバージョンがあった場合はどうでしょう？？
依存パッケージ間の依存関係があるなど、マイナーバージョン・パッチバージョンの更新と比較して、複数のパッケージの同時更新が必要だったりもします。

・composer updateのおさらい
・composer updateで何ができるのか？何が起こるのか？
・パッケージ更新のはまりポイント
・コツコツパッケージを更新していくために…

パッケージを更新するコマンドであるcomposer updateを軸に、日々のパッケージ更新のヒントとなるポイントをお伝えできればと思います！

？？？「わかりました！頑張ります！！」
？？？「頑張らなくて良いんで結果出してもろて」

こんなやりとりがあった際にふと気がつくとわたしの心の中には「逃げ」の気持ちがあるなぁということに気付きました。

「頑張ります」って答える時って、なんとなくコンフォートゾーンから出るような、自分の中でパッと想像できないような類のなにかをお願いされた場合が多いです。

そしてもう、みなさん頑張ってます！！間違いなく！！！

なのであえての「頑張る」の宣言は不要で、求められた結果やアウトプットに対してどう考えるか？をより意識するようになりました。

当然、ある時点で不安なことに対して対処するのは重い気持ちにもなりますが、そのような事象に対する意識の向け方、コンフォートゾーンと向き合うための考え方のひとつとしてわたしの体験をお伝えできたらと考えています。

「toB SaaSでお客様企業のアカウントでいろいろ確認したいけど、企業ごとにサービス管理者用アカウント作るの面倒くさい...」

こういうことで困ったことってありませんか？ サービス管理者として複数の企業アカウントを行き来する必要があるとき、企業ごとにアカウントを作成して管理するのは本当に大変です。
このセッションでは、サービス管理者が1つのアカウントで複数企業のデータにアクセスできる仕組みを、実際のテーブル設計とコード例を交えて紹介します。

おしながき

• サービス管理者が企業ユーザー代理アクセスを実現する「代理セッション」テーブルの設計
  • 管理者が特定企業のユーザーとして活動する際のセッションを、通常のユーザーセッションと分けて管理します
• 「管理者操作ログ」テーブルの実装
  • いつ、どの管理者が、どの企業アカウントで何をしたのかを記録します

複雑なプロダクトコード、"匂い"や"雰囲気"でリファクタリングしていませんか？

プロダクトコードの技術的負債の解消や保守性の向上のため取り組んでいるリファクタリングのその実際の効果をどれくらい測れていますか？

このLTでは、コードの複雑さを可視化・数値化できるPhpMetricsを使い、実際にコード改善した事例を紹介します！😆

PhpMetricsはcomposerで簡単に導入でき、クラスやメソッドごとの複雑度や、バグが出る可能性など、さまざまな指標を数値化してくれる便利なツールです。
数値に基づくリファクタリングで、より健全で保守しやすいプロダクトコードを目指していきましょう！💪

苦労してソフトウェアを開発したのに使ってもらえなかったことや、リリースしてから致命的な問題に気づき作り直しが必要になったことはありませんか？

ソフトウェア開発プロジェクトの失敗のうち、要件定義における失敗が原因である場合は4割にも上るという報告もあります。アジャイル開発のような適応を重視する開発アプローチを採用していても、要求を獲得し分析することの重要性は変わりません。

そこで本トークでは、「要求工学」と呼ばれる分野から、ソフトウェアに求める振る舞いを定義し記述するための以下の知見を紹介します。
・要求工学を実践するプロセス
・利害関係者を明らかにする分析法
・現状を分析し課題を明らかにする手法
・要求を抽出するための手法
加えて、発表者が実際の開発案件にそれら手法を適用して得た学びを共有します。

Laravelで出来たアプリケーションの本番環境まだEC2使ってませんか？

OSのEOL対応、PHPのバージョンアップ、サーバ障害対応などEC2で管理していると保守するだけでも色々やらないといけない事が多いです。

Laravelアプリケーションをコンテナ化してECSにデプロイすることで、辛いサーバ管理から解放されましょう。
このトークでは、EC2で管理していたLaravelアプリケーションをECSに移行するために考える必要があるポイントや移行のために必要な手順、デプロイの仕組み、ECSで運用する際に便利だったツール（ecspresso）などをお話します。

想定聴講者は、EC2でLaravelアプリケーションを運用、移行検討してる方はもちろん、インフラとかよく分からないけど分かるようになりたいという方にもおすすめです。

ご自身の「真ん中」にあるものって、なんですか？

PHPカンファレンス名古屋の中心に据えられている価値観を見て、ふと考えました。
https://phpcon.nagoya/2025/#about

自分は5年前から個人事業を始めたのですが、「真ん中」にあったのは、とある事業会社でのPHPプロダクト運用を回してきた、という経験だけでした。
でも、それを頼りに、新規プロダクト開発に業務委託で参画し、そこから自動テストや自動デプロイの導入や IaC化、さらに複業で幅を少しずつ広げ、「じぶん領域」はフルサイクルと言って良いかなと思えるくらいのなかなかの大きさになっていると思います。

このトークでは、類い稀な広がり方をした「じぶん領域」に関して、参考にしてほしい面と反面教師にしてほしい面をご紹介します。

ご自身の「真ん中」にあるものって、なんですか？

PHPカンファレンス名古屋の中心に据えられている価値観を見て、ふと考えました。
https://phpcon.nagoya/2025/#about

自分は5年前から個人事業を始めたのですが、「真ん中」にあったのは、とある事業会社でのPHPプロダクト運用を回してきた、という経験だけでした。
でも、それを頼りに、新規プロダクト開発に業務委託で参画し、そこから自動テストや自動デプロイの導入や IaC化、さらに複業で幅を少しずつ広げ、「じぶん領域」はフルサイクルと言って良いかなと思えるくらいのなかなかの大きさになっていると思います。

このトークでは、類い稀な広がり方をした「じぶん領域」に関して、参考にしてほしい面と反面教師にしてほしい面をご紹介します。

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

• DB処理が大量に詰め込まれたサービス
• トランザクションスクリプトがひしめくサービス
• どこからでも誰からも呼ばれるサービス
• 複数のサービスと手を組み、仲良く連携するサービス
• ドメイン層を支えるサービス
• 周りに合わせてとりあえず作られたサービス

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

当LTでは、こうした多様なサービス層にわたしの独断と偏見で名前をつけ、メリット・デメリットをかたっぱしから語ります。

私たち開発者にとってログは非常に重要です。
開発時のデバッグやローンチ後の障害解析など、ログを出力していることで救われたシーンは多かれ少なかれあるのではないでしょうか？

そんな私たちを助けてくれるログですが、Laravelでは様々な設定やカスタマイズが可能です。
しかしどのような設定ができるのか理解するところまで手が回らず、デフォルトのまま運用してそのままという悲しいシーンを見ることも多々あります。

このトークでは実際にログ出力する際にLaravelのLogManagerがどのような処理を行なってログを出力するのか、各設定の詳細、Laravel10より追加されているLaravelPailを用いたログの限定出力のやり方等をお話ししますので、今後のログ運用の助けになれば幸いです！

WEBアプリケーションを安定的に運用する上で、考慮しなければいけない事が多くあります。
私たちのチームは、PHPアプリケーションをAWSクラウドインフラで運用しており、コスト削減とセキュリティ向上という課題に直面していました。

本セッションでは、これらの課題解決に向けての取り組みを、主に下記の内容についてお話します。
・コスト最適化のために検討したサービスや設定の変更点
・セキュリティを強化するための機能や具体的な設定方法

本セッションを通じて、明日から実践できる費用対効果の高い運用改善方法を見つけることができます。
普段クラウドインフラに関わる機会が少ない方でも運用への興味と関心が高まる機会になれば幸いです。

数学でよくわからない記号や公式で苦手意識はないでしょうか。
プログラミングにおいても計算量オーダーと呼ばれるO(n^2)やO(log n)といった表記が出てくることがあります。
パッと見で拒絶反応は出てやしませんか？
実際にコードでこれらの表記が何を意味しているか理解し、パフォーマンスの良いコードを書けるようになりましょう

お話すること
・時間計算量
・空間計算量
・良くないコードの実例
・改善案

対象者
・オーダー記法を理解したい方
・パフォーマンスへの意識を高めたい方

皆さん、どんなアーキテクチャで開発していますか？
私が最近参画した現場にはモジュラモノリスが導入されてから1年超開発が続けられているプロダクトがありました。
チームはモジュラモノリスならではの恩恵を受ける一方で、設計上の難しさや課題にも直面してきました。このトークでは、モジュラモノリスを体感してきたエンジニアたちから見た設計上の留意事項や課題ないし今後の展望を共有したいと思います。

※PHP製ではありませんが言語に依存する話は無いか少ない想定です。

皆さん、オンボーディングを実施してますか？
エンジニアの転職が盛んになってきた昨今、実施側ないし受ける側としてオンボーディングの経験を持つ人も多いのではないでしょうか。
実施側目線では、入社直前に準備でバタバタする、何度も同じ説明を繰り返したことがある、担当者の負担感が大きいなんて感じたことはありませんか？
受ける側目線では、インプットが多くメモが大変、取りこぼす、オンボーディングを消化して成果を出すまでに時間がかかり焦るなんてことがありませんか？
このトークでは、これまでにオンボーディングを受ける側、実施する側で助かったこと、ドキュメントの作り方や見聞きしてきたコツを思い出し、共有します。
新規参画者の早期戦力化のヒントになれば、あるいは、オンボーディングで助けられたハッピーな気持ち、あの時の初心を思い出し、カンファレンス明けのお仕事を”やっていき”な気持ちで迎えられたら幸いです！

皆さん、スプリントレビューを実施してますか？

• 興味があるんだけれどやり方がわからない。
• 周囲の共感が得られない（説得材料が欲しい）。
• やってるっぽいんだけど実はよくわかってない。
• やってるんだけど何か違う気がする、もっとうまくやりたい。
  など、悩みやモヤモヤがもしあれば是非話をさせて下さい！

私が所属するスタートアップでは週一でスクラムチームとステークホルダがレビューに参加するという運用を5年以上続けてきました。スクラムガイド、自社事例、他社公開情報を参照しつつ、スプリントレビューのやり方、コツ、現場が感じている価値をまとめてお届けします。
プロダクトの改善、アジャイル開発に興味がある方の参考になれば幸いです。

システムに何かあったとき、どのような通知手段をとっていますか？
私が現在関わっているシステムでは、slack通知するよう設定をしています。警告時、異常検知時、それぞれにあった通知を設計したつもりでした。
しかし、slack通知が多すぎて本当に必要なものが埋もれてしまったり、@channelだらけでミュートしたくてもできないチャンネルになってしまったり、実は通知が届いていたのに誰も対応できなかった、なんて事が発生してしまいました。
そんな状況を少しずつ改善していったアレコレをお伝えできればと思います。

新しいプロダクト開発は失敗が避けられませんが、リスクやコストを最小限に抑えてメンバーが納得する規模でリリースすることで、失敗する恐怖を抑えることはできます。
本セッションでは、ユーザーストーリーマッピングを活用し、『安価に失敗する』ためのプロダクト開発の進め方についてご紹介します。
実際にリリースしたプロジェクトを事例に、どのようにプロダクト開発を進めていったかお伝えします。

新しく加入したメンバーの皆さん、チームに馴染めていますか？
新しいメンバーを迎えた皆さん、メンバーに馴染めてもらえていますか？

一説によるとWebエンジニアの平均在籍年数はおよそ3〜4年だそうです
ということは、最初の半年〜1年である程度新しいメンバーを戦力化できないと、エージェントに支払う費用などを考えると企業としてはよくてトントン、悪いとマイナスになってしまいます

このトークでは「馴染む速さ」に定評のあるいち個人が最近の転職で経験した

• 「オンボーディングされる側」として意識していたことでうまくいったこと
• 自分が組織に馴染む速さを支えてくれた会社の文化
• 上記を２つを支えていると感じた社内の仕組み

についてお話させていただきます。

採用する側、される側双方にとってのヒントになれば幸いです

皆さんは『プロダクト開発者』と聞くと開発者をイメージをしますか？
『プロダクト開発者』と従来の『ソフトウェア開発者／エンジニア』の違いは説明できますか？
（これはおそらく一定答えられる人がいると思います）

あるいは『GLAD開発者』という語彙を聞いたことがありますか？
（おそらく聞いたことある人は日本ではほとんどいないと思います）

この新しい語彙はどのような開発者像を指すのでしょうか？
また、それは従来の『プロダクト開発者』や『ソフトウェア開発者』と何が違うのでしょうか？

このトークでは先日私が衝撃を受けるとともに、長い事悩んでいた

• 専門性を高めるべきか？それとも他の道を探るべきか？
• そもそも21世紀の開発者はどうあるべきなのか？

といった問いに対する一つの回答例となった（と感じた）アイディアを共有します