トーク

サイトにくるお問合せの約80%を若手エンジニアチームで対応奮闘中！！

"お問合せ対応はレスポンスの速さが大切"だと思っています。
そんな中、メールでお問合せを集めていると調査に必要な情報が記載されておらず、
まず認識のすり合わせからと調査開始までにかなりの時間を要していました。
また、メールの通知に気づかなかったり気づいてもらえなかったり。
同じお問合せ内容を何度ももらったりと、お問合せ側も対応する側もハッピーに慣れない日々...

そこで、メールのテンプレートで欲しい情報を記載し、送ってもらうことに！
しかし、テンプレートが普及せず結果変わらず。
次こそはと、slackのワークフロー機能を用いてお問合せを貰うように！対応開始までの時間や、やりとりもスムーズに変わりました。
ナレッジの貯め方、若手同士のサポートや先輩方との関わり、両者がハッピーになるように行った工夫などなどお話します！

オンプレだったPHPアプリケーションをコンテナ化してWEBとバッチをクラウド化（AWS）しました。
今まで全くインフラの仕事はしていなかったのですが、ずっと興味がありました。
そして機会があったため手をあげて、SREと協力しながら実現させました！

「普段アプリケーションをさわってるけど、インフラもやっていきたいんだよなあ・・・」と思っている人のはじめの一歩を
私が体験した作業を軸に「やわらかく理解」できるようにお話します！

◆ 想定する観客
1年前の「インフラ興味あるけどなんもわからん」と思っているアプリエンジニアの私向けに作ります
総合して初学者向けです

◆ 話すこと
クラウド化で発生する作業って？（ECS / Docker / デプロイ / … ）
実際のタスクを進める上での悩み・詰まりポイント
クラウド化後に起こった想定外だったこと

DX(Developers eXperience) という言葉を聞いたことはありますか？ Digital Transformation の略称として使われることも増えていますが、別物です。
IT エンジニアの需要が増加傾向にある昨今、「コーディング自体を助ける 『優れた開発者体験』 」が重要視されています。

このトークで話すこと

このトークでは、潤沢な Laravel エコシステムを活用して、 DX を最大化させ、効率的なアプリケーションの開発を行う手法を紹介します。

• ローカル開発環境(Sail)
• 静的解析, Pint と Pest
• ファーストパーティ認証システム
• React フロントエンドバンドル(JetStream+Inertia.js)

ターゲット

Laravel を用いて効率的で安全にアプリケーションを開発したいあなたに。

業務知識とコードがリンクしていないと、PdMやビジネスサイドと会話をした時に上手く噛み合わなかったり、ある業務に関するコードを変更した際に思わぬ副作用が出たり、ビジネスサイドからの機能要望に応えることが根本的に厳しい状況に陥ると自分は考えています。

トーク内容

新卒二年目の自分がやっている業務知識とコードを結びつけるためにやっていることをお話しします。

話さないこと

• DDDについて（意図せずDDDっぽいことを話すかもしれませんが、DDDについては全くの素人なので悪しからず

エンタープライズアプリケーションアーキテクチャパターン(以下P of EAA)は、有用ですがなかなか読み解きにくい本です。

このセッションでは、P of EAAのパターンに基いた構成になっているEloquentと関連付けることで、P of EAAのデータソースレイヤ回りのパターンの概要を、わかりやすいく説明します。

LaravelのEloquentはRailsのActive Recordを元にしていることはご存知でしょうか？
では、Active Recordは、P of EAAの「アクティブレコード」パターンを元にしていることは？

アクティブレコードパターン以外にも、Eloquentの構成には、P of EAAの各種パターンに基いた個所があります。

このセッションでは、Eloquentの構成を通してP of EAAのパターンを学んでいきます。また逆に、P of EAAのパターンを通して、Eloquentの理解も深めます。
難解なP of EAAも、普段から使っているEloquentを通して考えると、とてもスムーズに理解することができるはずです。

1995 年から 30 年近く進化を続けている PHP 。私はその歴史でも一つの大きな転機となった PHP 5.3 あたりから、 8 年ほど開発に携わっています。
ここ 5 年弱の PHP の変遷はめざましく、大きくその姿を変えています。 IT 業界が揺れ動く中でも安定した需要を見出しているのではないでしょうか。

このトークで話すこと

このトークでは、これらのことについてまとめています。

• これまでの私の知りうる限りの PHP の進化の過程
• 現在の PHP 8.2 時点で作れる堅牢なアプリケーションの作り方
• この先 PHP がどういった道を進むのかを RFC を見ながら想像

ターゲット

• これまでを振り返りたい方
• 今どう書くのがオススメなのか知りたい方
• 未来の PHP に期待している方々

PHP に関わるみなさんに聞いて欲しいと考えています！

「ユニットテストなんてダルいよなー」「疎通動確の方が速いよなー」
そんな方へお届けする「気張らないでやれる」「"プログラマにとって"有用・有益なユニットテスト」についてのお話です。

また、次の症状にお悩みの方にも有効です。
・ユニットテストはやってみたいけどPHPUnitの導入で挫折した
・PHPUnitほど高度ではなくて良いので、もうちょっと気軽にユニットテストしたい
・大分古いPHPからのバージョンアップを実施したい
・バージョンアップのたびに動かなくなるテストスイートってどうなの

情報共有には「正しい文章」もさることながら「図で示す」のも重要です。

手書きで図を描いたり作図アプリで記述しても良いのですが、ここでは PlantUML によるテキストベースで図を描く方法について注目していきたいと思います。

「UML」と聞いて「仕様や細かいルールがあって難しい・面倒くさそう」と思っていませんか？

全てのルールに従って「正しい UML」を書くことにはとても価値がありますが、一部のルールに従いきれていなくとも「図を示す」ことにも価値があります。

ここでは、PlantUML をがんばり過ぎずにふんわりと使った図の共有についてご紹介したいと思います。

想定対象者

• 図を使ったドキュメントの共有をしたい方
• 図の差分管理をしたい方
• Mermaid 以外の描画ツールを知りたい方

以前PHPカンファレンス沖縄2022のLTで発表では5分で概要だけお話したことがありますが、語りきれていないことが沢山あるため拡大版です。

現在国内最大級の規模であるInstagram分析ツールSINIS for Instagramは2019年2月〜2019年8月の約7ヶ月でにフルリプレイスを行いました。

リプレイス前のコードやインフラはどういう状態だったのか、どういう理由で今の技術選定を行い、どういう構成になったのかの技術的なお話はもちろん、エンジニア以外にどうリプレイスが必要なのかを説得したかといった技術のお話以外まで公開します。

また、リプレイス完了からしばらく期間がたっているので、今よかったなと思うことだけでなく、今振り返ると当時これやっときゃよかったな〜とかのしくじり部分のお話もさせていただきます。

会社で開発を続けると突然やってくるだろう「リーダーやってみる？」
コードを書くほうが好きだけど、何となくリーダー経験してみようと思い立ったエンジニアの1年の軌跡をご笑覧あれ。

▼想定ユーザ
同じくリーダーをやってる、やっていきたい方
困ってる人を見て楽しみたい方

▼話すこと
認識していた役割と実際とのギャップ
見えてくるチームの課題
何を武器にしてプロジェクトを進めるのか
メンバーとプロジェクト、組織との向き合い方
情報を集める方法と実践してよかった施策
等など

マネージャ「すぎやま君には後輩の成長支援をお願いしたいんだよね」
僕「僕もまだ成長したい側なんですが？」

突然、後輩の成長支援をすることになりました。いったい何をしたら良いのでしょうか？
後輩からエンジニアのキャリアパスについて聞かれた場合、どう答えることが適切でしょうか？
また、php-srcに詳しいような自分よりもハイスキルな後輩たちに対して支援することは可能でしょうか？

このトークでは、成長支援が必要になった背景、支援するための準備や工夫、気をつけていること、悩んでいること、
そして、成長支援を通して自分自身が成長したことなどをお話しします。

PHP5系を使い続ける社内システム。色んな制約があり、バージョンアップできないことよくありますよね？

本トークでは、そんなレガシーと呼ばれるシステムと向き合う時の注意点やそもそもの要件を探り当てる嗅覚の話ができればと思います。

昨今、マイクロサービスを始めとした分散システムの活用が当たり前になってきました。
その際にシステムで何がどのように起きたかを考える、Observabilityもの世の中になってきたように感じます。

一方でコロナ禍でリモートワークを始め分散した環境での労働が当たり前になってきましましたが、人に対するObservabilityは十分に足りているのでしょうか？
今回のトークでは人を分散システムとして捉えて、Observabilityという観点からどのような環境で、どのようなコミュニケーションをしていくと健全になっていくかを提示できたらと考えています。

PHP8系がリリースされたり、逆にPHP7系のサポートが切れたりしてきた世の中。更にコンテナを利用して開発環境を統一する世の中です。
そんな新しいものと関わっていきたいと思いますよね。ただ世の中にはそんな潮流に逆らうシステムは数多くあります。
新卒入社してから関わった古き良きシステムの自己流の向き合い方だったり、保守する際の観点の話ができればと思います。

みなさん、システム設計はしてますか？ どのように進めていますか？

このトークでは、私が Catlog （※1）のアプリケーションの新機能などを作る場合の設計時に考えていることや、利用しているツール、チーム内外に共有する手法などを具体例とともにご紹介したいと思います。

なお、ここでの「システム設計」には「ソフトウェア設計」も含まれますが、それだけでなくもう少し広い範囲での「設計フロー」を想定しています。

想定対象者

• システム設計に興味のある方
• 他人の設計のようすを垣間見たい方

備考

• ※1 https://rabo.cat/catlog/

皆さん振り返りしてますか？改善のために振り返りは欠かせないですよね。
振り返りにはいろんなフレームや考え方がありますが、私が提案したいのは時系列KPT（勝手に呼称）です。

言わずともしれたKPTですが、プロジェクトの振り返りなどに活用するにはプロジェクト期間が長かったりすると初期のころに何をしていたかなど忘れてしまい、有効に振り返れないという問題があります。
この時系列KPTではそのような課題を解決できます。

みなさん、 Rector は使っていますか？

近年 PHP を語る上で欠かせなくなりつつある各種静的解析ツールですが、中でも Rector は PHPStan に由来する静的解析のパワーを最大限活用し、コードを意図した形に変換してしまうパワフルなツールです。最近 PhpStorm も標準で対応するなど、盛り上がりを見せています。

今回はこの Rector を最大限活用し、実際にプロダクション環境の PHP を 7.4 から 8.1 にアップグレードしたときのお話をさせていただきたいと思います。

当時インターン生としてジョインした僕。
初手で与えられた仕事はPHPバージョンアップ。
PHPはHello Worldレベルなのに！
それも5.6を使ってるらしいじゃないですか。2022年やぞ！
そんなこんなで正式入社・配属を経て現在まで圧倒的キレ芸をかましながらレガシーと戦ってきました。
その結果いくつかのサービスはアップデートを成し遂げました。
ですがアップデートの仕事はそこで終わってはいけないはずです。

このトークではアップデートをするまでにやったこと、失敗したこと、ひいては戦略的塩漬け、社内への啓蒙活動、葛藤、闇落ち、それらを経て見えてきたPHPバージョンアップという仕事は何たるかについて新卒１年目が稚拙ながら赤裸々に語ろうと考えています。

対象者

• レガシーに疲弊してる方
• 若気の至りを眺めてキャッキャウフフしたい方

開発ではコードを書く時間よりも読む時間の方が長いと言われていますし、コードレビューを通してコミュニケーションをとることも日常茶飯事です。
そんなとき、このような経験は無いでしょうか？

• 何をしている変数なのか全然わからない
• メソッド名からは伝わらない実装のサプライズ
• コードコメントが実装を説明しただけ
• 何をどういう条件で検証したいテストなのか不明
• コミットメッセージが「指摘箇所修正」ばかり
• PRで実現したかったことがわからず本質的なレビューができない

命名であったり設計であったりコードレビューであったり分野は少し異なっているように見えますが、これらは全て書き手が選択した「言葉」を使って表現されているという共通点があります。

本セッションでは、「言葉」という共通点に注目しつつ、チーム開発において伝わる「言葉」とは何か、伝えるために必要なことについて発表します。