トーク

皆さんはリリース後に文字化けが発生して、道頓堀に飛び込みたくなったことはありますか？
私はあります(※)。

PHP8.2の下位互換性のない修正の1つにmb_detect_encodingの文字コード検出の仕様変更があります。

私が担当しているメール共有サービスのメールディーラーで、バージョンアップ後に一部の受信メールが文字化けをしました。
原因は受信したメールのエンコード時に、前述のmb_detect_encodingを使っていたことです。

下位互換性がないPHPの仕様変更だったため、文字化けを回避することができず、
メールヘッダに文字コードの指定がないメールまで対応することになり、その対応に述べ約7人日かかりました。

メールディーラーのテクニカルリーダである私が、顧客対応で泣きをみたことを中心に苦労した経験をお話しいたします。

※実際には飛び込んでいません。

事業の成長スピードに追いつくためにスピード優先で開発した結果のコードに、このような特徴がありました。

• DBとの接続や外部サービス通信、業務ロジックなどすべてが詰め込まれている
• 何が業務ロジックで何がそうでないかが判断しづらい
• データに型がなくすべてがarrayである
• テストがない

あるとき、機能追加に伴いコードの保守性が低いことに危機感を感じてリファクタリングに踏み切り、業務ロジックの切り出しなどユニットテスト可能にしていく対応を行い、非常に扱いやすくすることができました。

このセッションでは、リファクタリング活動について、修正前コードと修正後のコードがどのように変化したのか、安全にリファクタリングを行うためにどのようなテストを用意したのか、リファクタリング活動を通して気づいたこと/学びについてお話します。

障害が起こった時には全力で対応しますよね。
障害が起こった後の再発防止までちゃんと検討してますか。

このセッションでは、再発防止のアイディアを捻り出すための方法と、それを実行に移すためのチームルールについて共有します。

例えば、アイディアを捻り出す方法には、こんなステップを踏んでいます。

1. ロジカルシンキングで原因を網羅的に洗い出す。
2. 原因を解釈する。
3. 事実や解釈に対応する再発防止策を考えてみる。
4. 良いものが出なかったら突飛なアイディアも出してみる。
5. ロジカルシンキングでマッピングして、よりアイディアを抽出する。
6. ROIを考えて実行するものを決める。

PHPフレームワークにおける「ミドルウェア標準化に関するガイドライン」であるPSR-15は、主にフレームワークの内部で使用される技術であり、普段の開発では意識する機会が少ない部分です。

しかし、PSR-15はリクエストの処理とレスポンスの生成に直結する部分であり、この概念を理解することでフレームワークがどのように動いているかを知る手助けになります。また、PSR-15を用いれば簡単なフレームワーク作成も視野に入るかもしれません。

本LTでは実際にコードを見ながら、「5分で理解するPSR-15」と題してお話ししたいと思います。

皆さんにとって、最もお気に入りのPHPフレームワークは何でしょうか？私はFlowです。

昨年秋に新しいプロジェクトに配属され、初めてFlowに触れる機会を得ました。
以来、約一年間、業務を通じてFlowを利用してきました。Flowを触る度、直感的でわかりやすい設計と豊富な機能に心が躍り、気が付けばドはまりしていました。

しかし、GitHubのスター数は150ほどであり、LaravelやSymfonyのようなメジャーなフレームワークと比べると知名度が低いのも事実です。
今回のLTでは、Flowの良さを少しでも知っていただけるよう、私の感じたFlowの魅力を皆さんにお話ししたいと思います！

話すこと
・Flowの特徴
・個人的なFlowの好きなところ

話さないこと
・他FWとの比較

Select2というライブラリを使ってサジェスト機能を導入しようとしたものの、PrototypeJSとのコンフリクトや、データ量が多い環境でのパフォーマンス問題に直面しました。最終的にライブラリを使わず1から独自に実装した結果、パフォーマンスが大幅に向上し、機能を完成させることができました。この5分の発表では、その経験から学んだライブラリ選定の課題と、バックエンド処理を使ったサジェスト機能の実装方法を紹介します。

PHPStanは静的解析ツールとして、日々の開発で多くのエラーや警告を教えてくれます。今回の発表では、私が独断と偏見で選んだPHPStanのエラーをできるかぎり紹介し、そのエラーがどのような状況で発生するのか、また具体的な修正方法を一挙に発表します！

PHPStanのエラーを理解して、あなたも今日からPHPStanをあなたのより良い同僚の一人にしましょう！
そして開発品質を上げていきましょう！

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

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

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

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

外部システムと連携を行うときに、頭を痛めるのが ”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で定期実行する方法
• 弊社での活用事例
  などを中心にお話しします！

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