トーク

開発初期段階で、社内だけにUIを公開して早期にフィードバックを集めるために、isProduction()を活用しました。
スプリントレビュー会前にUIや文言を改善できることで、リリース前の手戻りを減らし、開発スピードを向上させる具体的な方法についてお話しします。

課題:
UIや文言の修正がレビュー会後に集中してしまい、リリースが遅れることがありました。
実際の操作性の問題や細かいバグも見逃されがちで、後で修正することもありました。

解決策:
isProduction()を利用して、社内ではUIを早期に公開し、開発段階でも社内メンバーからフィードバックをもらい、リリースまでに改善することで手戻りを減少させました。

結論:
isProduction()を活用することで、早期にフィードバックを集め、リリース前の手戻りを減らし、開発の効率化を図ることができました。

Laravel 11 待望のリリース！
公式のアップグレードガイドを見るとこのような記載が。

『アップグレード見積もり時間：１５分』

・・・本当に？

公式が言うのであればそうなのでしょう。
幸い、えんさがそっ♪は PHP 8.3 / Laravel 10 と好条件が揃っている。
では 15分 でアップグレード完遂という高みに挑戦しようではないか。

外部システムと連携を行うときに、頭を痛めるのが ”APIでの連携” です。
API で機能連携を行う場合、みなさんも一度はこんな経験があるのではないでしょうか？

「レスポンスデータが扱いづらい」
「エラーレスポンスを適切にハンドリングできない」

私たちのチームでも同様の課題に直面しましたが、
API 呼び出し時に専用の Result 型 を用意することで、解消することができました。

これであなたも、API の仕様に惑わされない実装ができるようになります。

「実装は今日からです。仕様はまだ決まっていません。」
チームに告げられた計画はあまりに無謀で、誰もが炎上を覚悟した─────。

私たちのチームではスケジュールの都合上、仕様が確定する前に実装に着手する必要がありました。
この危機的状況を切り抜けるため、サービスで採用していた ”オニオンアーキテクチャ” の利点を最大限活かし、
ドメインモデルを中心として ”仕様が決まっているところから着手する戦略” を取りました。
この戦略により、仕様の確定を待たずに手を動かせたことによって、スケジュールの遅延を防ぐことに成功しました。

実際にオニオンアーキテクチャによって、開発がブーストした事例を紹介します。

LaravelのEloquetにはupsert関数があって便利だなぁ♪
あれ？updateOrCreate？
あれあれ？updateOrInsert？

一体どれを使えばいいんだーーー！！！

本セッションではこんな悩みを解決するために、それぞれの関数の説明とどう使い分けるかについてお話します。

さあリファインメントを始めよう
→適切なサイズに区切るには見積もりが必要だな
→見積もりの精度を上げるには何を作るかが明確じゃないと
→リファインメントが終わらない！！

リファインメントに時間がかかりすぎる我々のチームは、「リファインメントとは何か」を考え直すことにしました。
スクラムガイドの定義を調べ、実際にやっているリファインメントと比較した結果、
辿り着いた答えは「我々のリファインメントはリファインメントじゃない」でした。

このトークでは、なぜ我々のリファインメントはリファインメントではないのか、方針を変えたことでチームにどのような変化があったのかをお話しします。

さあリファインメントを始めよう

皆さんは、Laravelでの定期実行をどう実現していますか？？

我々のチームでは、サービスをECSにてデプロイしていることもあり、Laravelのタスクスケジュール機能を使わない選択をしました。

しかし、ECSのLaravelサービスに対して定期実行する方法には、以下のようなものがあります。
・ECSのスケジュールされたタスク
・Amazon EventBridge SchedulerからのECSタスクの実行
・Amazon EventBridge SchedulerとLambdaを使用したAPI呼び出し
この中から「早くて安くて安心な」手段を選ばねばなりません。
そこで、AWSのコストを抑えつつ、必要な要件を満たし、運用が簡単な方法を見つけるべく我々はアマゾン（AWS）の奥地へと向かいました。

そして冒険の果てに見つけた、最適な定期実行の方法をお話します。

DKIM、DMARC、SPF
これらを説明できるでしょうか？

2024年4月から本格的に始まったGmailのガイドラインに基づくメールの受信拒否設定によって、メールセキュリティの考慮は他人事ではなくなりました。
これは、非エンジニアにとっても同じです。
場合によっては、サービスの利用者にGmailガイドラインに対応するよう依頼する必要があるからです。

しかしながら、これらの知識はどうしても専門的な技術知識なしでは説明しづらく、非エンジニアにとってはなおさら理解しづらい分野です。
難しい専門用語を使わないよう注意しながら、非エンジニアの方に理解してもらおうと頑張って資料を用意して説明した方も多いのではと思います。

この発表では、非エンジニアの人にも伝わるよう、今押さえておくべきメールセキュリティについて解説します。

皆さん「学ぶ・勉強する」と聞くと「机に向かって本を読む」「カンファレンスに参加する」というようなことを想像しませんか？
実際それらは学びに繋がる大事なアクションなので間違ってはいません。
でも「毎日本を読む」「毎日カンファレンスに参加する」ってしんどくないですか？
私はしんどいと思っちゃいます。
「本を読んで学ぶ」は手段のひとつでしかありません。
日常のありとあらゆるものが学びの対象となります。
例えば日々行っている業務から学ぶこともあるでしょうし、漫画やアニメから学ぶこともあるでしょう。
そういった全てのことから学べるようになると頑張らなくても学べて成長できるようになります。

本セッションでは

• どういったものが学びの対象となりえるのか
• 私が個人的に日常から学んできたことの例
• どうやったら何からでも学べるようになるのか

などをお話できればと思います。

世の中にはたくさん便利な言葉があります。
その中でも開発に関わる便利な言葉において「今の場面においてはその言葉は逃げじゃないか？」というシーンが多く見られます。
私もつい便利に使って逃げてしまうことがあります。
具体的には以下のような言葉は、便利ではあるが使い所を間違えると逃げに繋がる言葉だと思っています。
認知負荷・属人性・技術的負債・心理的安全性・視座…etc

本セッションでは

• なぜこれらが「逃げ」なのか
• 適切な場面と、適切ではない場面はどういったものがあるのか
• 逃げないためにはどうすればよいか

このあたりを中心にお話できればと思います。

背景
あるプロジェクトでたくさんの障害を発生させてしまった。。。
障害はユーザーに迷惑をかけてしまうし、エンジニアのメンタルが削られるし、進行中のスケジュールを圧迫する。全然いいことがない。障害はこの世から無くなって欲しい。せめて減らしたい。。。
そんな思いから開発プロセスを見直す動きが社内で生まれました。

お話しすること
・そもそも障害と何なのか？障害と向き合う
・適度な障害予防コストのバランス
・プロセス確立までの道のり
・実際のプロセスや工夫を紹介

障害を少しでも減らしたい、自分のチームに見合ったプロセスをカスタマイズしたいと同じ悩みを抱えているPHPerの皆さんにお伝えできれば幸いです！

「コンフォートゾーンを抜けましょう」っていうフィードバックもらったことありませんか？
私はあります。
でも「そもそもコンフォートゾーンって何？」「抜けろって言うけどどうやって抜けるの？」って思いませんか？
私は思います。

本セッションでは

• コンフォートゾーンとは何か
• どうしてコンフォートゾーンから抜け出せないのか
• なぜコンフォートゾーンを抜け出さなければならないのか
• コンフォートゾーンを抜け出すには具体的にどうすればいいのか
  このあたりを中心にお話できればと思います。

皆さんCI/CD回してますか！
日々のルーチンワークを仕組み化して定期実行させるのは効率化の観点で非常に重要ですよね。
ローカルマシンでcrontab書いて手元のスクリプトを定期実行…みたいなことしてる人、いませんか？
それ、GitHub Actionsでできますよ！
本セッションでは

• GitHub Actionsで定期実行する方法
• 弊社での活用事例
  などを中心にお話しします！

静的解析は堅牢なPHPアプリケーションを作るための手段として広く認知、活用されるようになりました。
特にPHPStanは技術カンファレンスでも多く言及されており、PHPにおける静的解析のデファクトスタンダードとも言えるツールです。

PHPStanはそれ単体だけでも効果を発揮しますが、拡張機能を使うことでより精緻な解析ができます。
例えばLaravel向けの拡張であるLarastanを使うと、マイグレーションファイルのスキーマ情報により、EloquentモデルのDBカラムの型を解釈できるようになります。

本トークではPHPStanの拡張機能の読み方を紹介するとともに、実際の拡張機能がどのように実装・実現されているのかを見ていきます。
拡張機能のコードを読むことで静的解析の威力を知っていただき、より効果的に静的解析を活用していくきっかけとなれば幸いです。

あなたの社内にも「あの人になら相談しやすいな」という人はいませんか？
社内で頼られる人にはどのような特徴があるのでしょう。
エンジニア歴25年、8社を渡り歩いてきた私が
社内コミュニケーションにおいて心がけている、細かすぎるけど大切なことをお話します。

NeoVim IDE。
本セッションでは、VsCodeやJetBrains製品が提供する「統合開発環境」としての機能を、NeoVimとTUIを利用してTerminal内で表現する事であると定義します。
LSP、DAP、補完やGitにDocker操作等々のIDEとしての環境をNeoVimで構築するまでのステップと、その効率性について解説する内容になります。
皆さんに「こんな選択肢があるのか」と自分の開発環境を見直す機会になることがGoalです。

話すこと

• なぜTerminalで完結させているのか
• NeoVim IDEとIDE製品のPros/Cons
• Lua言語について
• Terminal周りのOSS事情と、Rust製の勢い
• 自分が大規模コードをNeoVimのみで編集できるようになるまでの四苦八苦
• PHPでのライブコーディング

弊社はPHPで自社サービスを提供しているスタートアップ。
エンジニアは超売り手市場でなかなか採用ができない。
毎日レジュメを眺め、スカウトメールを送る日々。
とある日、ようやく弊社事業に興味を持ってくれたエンジニアがカジュアル面談に来てくれた！
幸いにも事業関心も高く、マッチしそう！
ところが、弊社の採用言語がPHPであることを伝えると
「PHPはちょっと…」
え？
え？
そこで温度感下がってしまうの？

カジュアル面談でこんな状況に遭遇したら、どうすればいいでしょう？
このLTで採用担当のそんなお悩みを解決します。

とある機能を実装していたときのことです。その機能には、動的に作成・削除されるファイルの存在有無によって分岐する処理がありました。
検証環境でのテストも問題なく、満を持して本番環境にデプロイしたところ、なんと大量のエラーアラートが！
エラー内容を見てみると、どうやら削除したはずのファイルがなぜか存在すると判定されてしまっているようなのです。
調査の結果、PHPの意外な仕様が原因であることがわかりました。

上記の経験をもとに、あなたの知らない（かもしれない）PHPのファイル操作にまつわる仕様とその対策をお話しします。

私のチームでは最近GitLabからGitHubへと移行し、CIもGitHub Actionsを使い始めました。
せっかく移行するなら、単なる書き換えではなくGitHub Actionsならではの機能やベストプラクティスを取り入れたいと思い、いろいろと調査を行いました。

このLTでは、PHPアプリケーションのCIをGitHub Actionsで実装するにあたって得られた知見を共有します！

想定する聞き手

• GitHub Actionsをこれから使ってみたいPHPer
• GitHub Actionsの便利な機能を活用したいPHPer

話すこと

• PHPプロジェクトのCIの基本的な作り方
• PHPプロジェクトで使うと便利なGitHub Actionsの機能、ツール

話さないこと

• GitHub Actionsの基本的な機能、使い方

Next.jsを今年から触り始めたんですが、フロント側のテストって何を書いていいかわからない、UI部分のテストって書くのが難しそう、と思っていました。

そこでフロント開発（Next.js)の自動テストについて調べて、実際に作成した時、こんなライブラリやツールを使ってこんなテストをしたよ、っていうようなことを話したいと思います。

具体的には以下のような内容を話す予定です。

•自動テストのタイミング（コミット時、GitHubのプルリクを出した時、mainにマージされた時など）
•ESLintでの静的解析
•Storybookを使った自動テストの作成
•Jestを用いたテストの作成
•Chromaticを用いたUIの変更点のテスト作成
•Codecovを用いてコードカバレッジの取得