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

このトークで話すこと

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

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

ターゲット

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

想定対象者

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

備考

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

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

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

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

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

株式会社LATRICOは2020年創業のヘルスケアスタートアップで、東京美肌堂というサービスをLaravelで開発・運用しています。
創業当時は業務委託を中心に開発を進めていましたが、2022年からエンジニア採用を始めて徐々に内製化を進めてきました。
そんな会社にCTO（二人目のエンジニア）として入社し、どのようにプロダクトを改善してきたかの泥臭いお話をさせていただきます。

トーク内容

• プロダクトの紹介、当時の問題の共有
• 開発ロードマップの策定
• 採用
• 実装方針の共有・レビュー体制の構築
• CI/CD整備
  -- phpcs, phpstan,PHPUnit整備
  -- ブランチ運用ルールの変更
  -- デプロイフロー変更
• サービス安定化
  -- DataDog, Sentry
• 監査対応
  -- 障害報告フローの整備
• そして脱PHPへ…

プロポーザル一覧をご覧ください！「10年もののコード」「20年続いた老舗の味」といった表現が出てきますよね。
何となく「ソフトウェアは経時的に劣化する」というのは広く知られているかのようです。
また、「今のリリースで出たバグ」と「5年前のコードの間違い」では、前者の方が虫退治が簡単である事が多いです。
これも「ソフトウェア-開発者-時間」の問題に思えます。

こうした文脈での「時間が経つ」とは何なのか？「"時間の経過"を遅らせ、進化を早める」ことは可能なのでしょうか。
このトークでは、「時間」を切り口にソフトウェア開発の難しさを考えていきます。
プロジェクト管理や品質に関して思いを馳せる土台になれば幸いです

主な参考書籍

• ワインバーグのシステム思考法
• ライティングソフトウェア
• レガシーコードからの脱却
• A Philosophy of Software Design

近年 DevOps の話題についてよく耳にするようになりましたが、私達のチームでも最近 DevOps のプラクティスの1つ「継続的デプロイ」を導入しました。
コード変更が発生する度に本番環境に自動デプロイを行うことで Four Keys の「デプロイ頻度」や「変更のリードタイム」の改善に直接的に寄与する一方、コードの欠陥がすぐに本番環境で発露するため、システムの信頼性を毀損するリスクも伴います。
私達のチームでは特に信頼性を損うことなく導入を進めることができたように思います。
振り返ってみると、サービスリリースから4年半の間に行った様々なデプロイ戦略の改善の結果、継続的デプロイ導入の下地が出来上がったのではないか、と考えるようになりました。

このトークでは過去に行ってきたデプロイ戦略を中心とした開発フローの変更と、それらがどのように継続的デプロイ導入に役立ったのかについて話します。

もっと技術的なチャレンジがしやすい環境を作りたい。

サービス全体の技術力を上げていくためには、そこに対して投資する姿勢や技術的なチャレンジがしやすい環境を作る必要があると考えています。
どうすればそんな環境を作ることができるのか。
まずは、早くて安定したリリースができる仕組みが必要であると考え、Four Keysで開発パフォーマンスを可視化し改善のためのアクションを繰り返しています。
このセッションでは、Four Keysを活用した開発パフォーマンスの改善をチーム全体を巻き込みながら進める方法についてお話しします。

【トーク対象】
・Four Keysをサービス改善に活かしたい方
・開発パフォーマンスを改善したい方
・チームを巻き込んで改善していきたいことがある方

ここ数年でコロナ禍ということもあり、リモートワークを活用する企業が大幅に増えました。
おかげで、毎朝辛かった満員電車からおさらばし、場合によってはワーケーションといった様々な労働スタイルが確立されていったように感じます。
一方で、失われていったものもあるのではないでしょうか？
特にリモートワークにおける、コミュニケーションは従来のオフライン時代に比べて格段に難易度が上がったように思います。
我々の仕事はナレッジワークなので、知識の定着や文化のためにコミュニケーションは必要不可欠です。
私自身、コロナ禍が始まった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の細かい話

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

トーク内容

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

想定視聴者

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

含まれないもの

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