ここ数年でコロナ禍ということもあり、リモートワークを活用する企業が大幅に増えました。
おかげで、毎朝辛かった満員電車からおさらばし、場合によってはワーケーションといった様々な労働スタイルが確立されていったように感じます。
一方で、失われていったものもあるのではないでしょうか？
特にリモートワークにおける、コミュニケーションは従来のオフライン時代に比べて格段に難易度が上がったように思います。
我々の仕事はナレッジワークなので、知識の定着や文化のためにコミュニケーションは必要不可欠です。
私自身、コロナ禍が始まった2020年5月に現職に入社し、基本リモートで約2年半過ごしました。
今回のトークではその2年半のリモートワーク中心の働き方で、どのようなコミュニケーションの工夫をしたのか、今後どうしていくと良さそうかという観点で知見の共有をできたらと思います。

僕の配属先のプロジェクトではテストコードがほとんど存在しませんでした。

要因は様々かと思いますが、根源にある想いは「テストコードを書くのが面倒」という点と考えます。
僕は入社後、様々な施策を試みながら、僕の所属するプロジェクトにテストコードの文化を根付かせる行動を取りました。
入社して3ヶ月ほどで、「テストを書き終えるまでを自身のタスクにしよう」という弊プロジェクトのエンジニアの行動指針がディレクターにも理解され、テストコードを書くまでを機能開発の工数として確保することができるようになりました。

本講では、

• なぜテストコードを書くことが面倒なのか
• 重い腰を軽くするためには
• テストコードの重要性はどのようにすれば他職種の皆様にご理解いただけるのか

といった内容をお話できればと思います。

遠隔地、かつ母国語が違うチームとのやり取りには、普段と違うスキルが必要です。

オフショア開発の場合、文化やバックグラウンドだけでなくコーディングの知識や考え方にも差があるため、単純な開発や改善作業でもこちらの意図が伝わらない場合があります。
しかし、国内で設計を行い実装を依頼する場合、コーディング量はオフショア先メンバの方が多くなるため、コード品質をはじめとしたサービスの内部品質改善の中心はオフショア先のメンバとなります。

私が担当しているサービスはリリースから20年以上が経過しており、保守性が低いコードも散見される状態です。
そんなよろしくないコードを悪意なく増やしてしまう状態のオフショアチームに、どのようにしてよいコードを伝えてコード品質を改善しているのか、実際に行っている取り組みを通じてオフショア以外のチームでも活用可能なコード品質改善方法についてお話しします。

times。それは、社内チャット内で自身のチャンネルを作り、その人が自由気ままに投稿することのできるいわば社内Twitterのような文化のことです。

僕が入社した時、このtimesという文化は弊社にはほとんどありませんでした。
ほとんどというのは、以前チャレンジしようとしたけど結局やめてしまった形跡を見つけたためです。
僕の入社を機に、timesという文化が活気付き、業種を超えてディレクターの方々までも始めるようになりました。
また、times文化が活気づいたことを機に、エンジニアに向けたお悩み相談部屋（定期会議）を立ち上げ、部署を超えて全社のエンジニアのサポートをしていける状況としました。

本講では、timesを機にわかった弊社エンジニアの悩みや考え方、それ踏まえた僕の行動軌跡と今後の予定をお話できればと思います。

サービス開始から6年、初めてのLaravel、PHPバージョンアップを行なっています。これまでサービスの成長につながる案件に時間をつかってきたため、定期的なバージョンアップを実施できていませんでした。そんな中、どのような経緯でバージョンアップすることになったのか、進める中で苦戦していること、学びを共有します。

2013年から約20年近く続くサービスの運用開発をしていますが、サービスは過去にオンプレからAWS環境へのリプレイスや
サービス内の大幅な機能のアップデートなどを繰り返し行ってきました。
そんな中で、PHP（Laravel）やNodeなどのシステムバージョンアップは優先度を上げきれず
セキュリティサポートが切れるタイミングなどリスクが高まってからかなりの時間を費やして実施してきたという背景があります。
今回はそんなサービスのバージョンアップを採用技術のバージョンアップサイクルと大差なく行っていくための計画を立て、実施しているお話をします。
具体的には、最新バージョンへのアップデートそのものと、バージョンアップを効率よく行える環境へのリプレイスの大きく二つが求められる中で
どのような考え方でコンテナ環境へのリプレイスを先に実施することにしたのか、実施してみての効果などを交えながらお話します。

PHP Conference Japan 2021でお話しさせていただいた、『SymfonyとDoctrineで
簡単クリーンアーキテクチャ』。実はあのサンプルコードのユースケースクラスは実際のプロト開発の書き方ではなく、実際は"主語"と"述語"を意識した書き方をしていました。

前回の登壇では時間の都合上、泣く泣くカットせざるをえなかった、『"主語"と"述語"を意識したユースケースの作成』について、ご紹介していきます。

利用するフレームワーク

• Symfony

はなすこと

• "主語"と"述語"を利用したユースケースの作成について
• イベントによるユースケースの境界作成について

はなさないこと

• Symfonyの細かい話

チーム開発に欠かせないチームビルディング。
何となく雰囲気でやってませんか？
チームビルディングの目的や、よくある失敗例を混じえながら抑えるべきポイントについて説明していきます。

トーク内容

チームビルディングとはなにか
チームにおけるフェーズとその機能
チームビルディングでよくある失敗例と対策
メンバーのタイプと相性について
オススメのチームビルディング方法

想定視聴者

チームリーダーを任されたけど何から手をつければいいか分からない人
何となくチームリーダーをしてるけど、なんかうまく機能していない気がする人
メンバーだけどもっとチーム感を持って仕事がしたい人

含まれないもの

チーム生産性の話
スクラムなどの開発手法の話

Laravel8からInertia.jsを利用できるようになり、シンプルな設計でLaravelでSPAアプリケーションの構築ができるようになりました。
Laravel + Inertia.js + React.js + Vite + Typescript でアプリケーションを作った話をします。

• Viteを利用した初期設計
• 基本構文や便利機能
• Inertia的リダイレクト
• Inertia.js で苦戦した点
• PHPUnit・Vitestの書き方

【トーク対象】

• Laravelで開発している方
• PHPとSPAアプリケーションを開発運用している方
• Inertia.jsを知りたい方

PHP ParserとはPHPのコードをパースするライブラリです。これは静的解析やコードの操作等に用いられます。例えば、PsalmやPHPStanがこれを利用しています。

そんな言わばPHPを最もよく知るライブラリからPHPのことを学ぼうというのが本トークのテーマです。

本トークではPHPを構成する要素に着目します。PHP Parserはコードをパースし、ノードと呼ばれる単位に分解します。静的解析はノードを一つ一つ読み取り、コードを解釈します。ノードは170種類以上あるのですが、それはPHPが多様な要素から成ることを物語っているように思います。

ノードの定義を読み解くことで、PHPにおける文や式とは何なのか、どんなバリエーションがあるのか、PHPはどんなパーツから成り立っているのか等を確認したいと思います。（また、その過程でPHP Parserについても少し理解できると思います。）

PHPerの皆さんが大好きなLT会、開催していますか？
開催したい気持ちはあるけど実際にやるのは難しい。。という方も多いのではないでしょうか。

私たちは社内LT会を毎月オンラインで開催しています。
4〜5人で運営しており、「2週間前の準備・当日の準備/運営・振り返り」のサイクルで行っています。
このトークでは、毎月開催するための準備・運営でやっていること、実際にやってみて上手くいったこと/いかなかったことを詳しくお話します。
メインの参加者はエンジニアですが、事業部側の人たちも多く参加してくれているので、その様子もお伝えしたいと思います。
オンラインイベントを運営したい方の参考になると嬉しいです。

話すこと

• 参加者を集めるためにやったこと
• 様々なツールを使って開催したこと
• 開催してみて上手くいかなかったこと
• オンラインでも参加者全員が盛り上がれるために工夫したこと

「本にはこう書いたけど実は...」で始まるお話をしたいです。書籍はネット記事や論文と違って、いつまでも本屋さんに置かれる商品なので、考えることがいろいろあります。どんな手口で何をたくらんでいたのか、書いてないけど裏で考えてたことは何か、なんでアレをそう書いてコレはこう書いてないのか... ここでしか言えない (Twitter で漏らしてしまうかもしれないけど) ことを語らせてください。

皆さんが所属してるエンジニア組織の課題はなんでしょうか？
どの組織も何かしらの課題があるのではないかと思います。

弊社ではPHPで開発された複数メディアを運営し、
エンジニアの人数も増加しながら継続的にリリースすることで順調に事業を成長させてきました。

一方で、事業が成長するにつれて「スキル獲得に漠然とした不安がある」や
「他エンジニアと交流・切磋琢磨が生まれにくい」と言った声も聞こえるようになりました。

こういった課題に対して、エンジニアリングマネージャーやテックリードを中心に「技術推進委員会」という名の横断組織を爆誕させ、
メンバーで熱い議論を交わしながら課題解決の施策を考え、実施してきました！現在も実施中です。

このセッションでは、
横断組織の立ち上げから2年間の間で実施してきた多くの施策や施策を実施したことでの組織の変化について話します。

Symfonyドキュメントの日本語訳を進めています。
Symfonyは世界でも有名なフレームワークですが、最新バージョンに追従するドキュメントの日本語訳がないのが現状です。
日本語訳があるLaravelやCakePHPに比べると、初学者にとって難しいかもしれません。
そこで、Symfonyの学習を支援するために、公式ドキュメントの日本語訳を作成しています。
PHPerKaigi 2023にてこのプロジェクトの紹介と協力者の募集を行いたいと考えています。

また、日本語訳に協力していただける仲間も募集していますので宜しくお願いいたします！

PHPer界に光あれ！
Symfonyドキュメント日本語訳で輝く未来を切り拓きましょう！

例えば消費税や販売手数料等の金額計算をしなければならなくなったこと、ありませんか。
var_dump(0.1 + 0.2); が何を表示するかすぐに答えられるでしょうか。
このトークでは、PHPで任意精度演算を行って「正しい」金額計算を行う方法について説明します。
なんとなくintやfloatを使って計算するのは、もうやめにしてみませんか。

想定対象者:

• PHPで任意精度演算を今までやったことがない人
• 任意精度演算という言葉を初めて聞いた人

概要

このセッションは、自社での「データの民主化」の過程でうまくいかなかったことから得られた学びと、
その学びをどう生かしているのかという話をします。

「データの民主化」と調べると、データ基盤の構築や、BIツールの導入、ダッシュボードの構築などの話が多くでてきます。
これらは大事なことですが、しかしこれらを作っただけではデータの扱いに慣れていない方には一向に広まらず、
一部の人しか活用できてないという結果だけが残ってしまい、これだけでは「データの民主化」にはならないということを学びました。
この学びから、アプローチを変え再度「データの民主化」に挑戦していると話をします。

話すこと

• データ基盤構築の話(ちょっと)
• 最初の導入でうまく広まらなかった話
• データの民主化のための泥臭い取組

話さないこと

• 使っているツールについての説明

普段いつものようにphp-srcをソースコードリーディングをしているとき、配信しながらアバター姿でやってたり、
PHPのバグを見つけて報告するときもアバター姿で配信しながらやっています。
その際のノウハウやメリット・デメリットをトークします。
（アーカイブ残してるのでアーカイブ見るとわかりやすいです😁）

登壇する際にもアバター姿で登壇しています。登壇の方法は配信とちょっと違ってくるので、
どうやってやるの？というのもトークします。

PHPerKaigi 2021からアバター姿で登壇して2年になりますが、もっとアバター姿で登壇する人が増えると嬉しいです！

ちなみに、このトークの概要も、配信しながら作りました。
https://youtu.be/1r5CQ3u8GF8

開発組織の開発力、生産性を上げるために避けては通れないエンジニア一人ひとりの技術力アップ。
私がEMとしてここ数年考え実践してきたエンジニアの教育において必要な要素や考え方について整理して話します。

トーク内容

メンバーを教育する際に気をつけていること
エンジニア教育する際のマインド
レベルごとの教育スタンス（ティーチング、コーチングの使い分け）
教育にまつわる理論（認知特性やラーニングピラミッドを活用する話）

想定視聴者

組織のエンジニア教育にミッションを持ち悩んでる人
エンジニアとして今後の成長方針に悩んでる人
教育に興味がある人

含まれないもの

エンジニアに必要な個別技術の習得方法
エンジニアとしてどのような個別技術を学ぶべきか

PHP によって書かれた一般的な Web アプリケーションはリクエストごとに独立したプロセスによって処理が行われます。
そのようなアーキテクチャは ISUCON の参考実装が提供されている言語の中でも異質です。

RoadRunner は Go 製の PHP アプリケーションサーバで、リソースをリクエストをまたいで使い回すようにでき、他の言語と近いアーキテクチャを実現できます。
これによって他の言語と同じ土俵で戦うことができるのか、は気になるところですが、それ以前にそもそも RoadRunner に載せ替えることはできるのでしょうか？

本セッションでは ISUCON 12 予選問題の PHP 実装を RoadRunner で動作させるために必要なことと、RoadRunner に載せ替えたことによって変わることを説明します。

コードのレガシーさには計測できるレガシーさと計測できないレガシーさがあると考えています。
私自身、計測できないレガシーさをうまく察知し、それを「コードの不吉な臭い」として感じ取るのは得意ではありません…。
しかし、

• コードはどれくらい大きいか？
• 重複コードはあるか？
• コーディング規約が守られているか？
• 循環的複雑度は？
• コードにエラーはないか？
• etc

このような情報は各種ツールを利用することで計測できます。
計測した数値を活用することで「コードの不吉な臭い」が少しずつ見え、実際にどこに手を加えて改善・リファクタリングをしていくと効率がよさいか？という道筋が見えてきます。

本トークでは主にツールで計測できるコードのレガシーさに着目しながら、どのようにコードを改善していけるか？をお話しさせていただき、皆様のリファクタリング活動の一助となればと思っております。