現在私が BABYJOB 株式会社で開発を担当している保活サービス「えんさがそっ♪」は、ドメイン駆動な設計スタイルで開発を行っています。
具体的には Laravel + オニオンアーキテクチャでの設計・実装を行っています。

私自身はこれまで単純な MVC 構成のアプリケーション開発経験のみで、ドメイン駆動な設計スタイルのアプリケーション開発を行うのは初めての経験です。

最近、ドメインの構造などについて再検討する機会があり、ドメイン駆動設計の戦術面への関心が高まりました。
技術的な調査を進めている中で、PHP でのドメイン層の実装戦術として Symfony（Doctrine）に興味をもち、入門してみることにしました。

この発表では Symfony（Doctrine）でのドメイン実装戦術について、Symfony に入門してみて分かったこと、分からなかったことを発表します。

名付け、してますか？ふと気付けば、常に名付けばかりしているのではないでしょうか。
できる限りわかりやすい名前を付けようと一日の稼働時間を潰した経験はありませんか？

日々当たり前のように名付けをしていますが、これは我が子の命名と同じくらい大切な行為です。

名前を付けることで何が起きるのか。「名付けできない画面」とはどういう状態なのか。
名付けに対しての意識を、今こそ改めて考える。そんなトークができればと思います。

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

トーク内容

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

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

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

主な参考書籍

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

Webサービスは生き物。
機能追加によって常に成長し、変化しています。
そんな日々の中で、機能追加する際のデータベースに対する変更はつきものです。
しかし何気ないデータベースの変更が障害の元になったり、機能追加の障壁になっていたりしませんか？

• 本番にALTERを流したらロックでサービスが死んだ
• 特定のカラムを毎回確認するifの列挙が辛い
• Viewで表示されるデータがSELECTしないとわからない
• 仕様追加の際にテーブル変更が怖い

そんな不安、心配を持っている皆様に明日からできるテーブル設計についてお話します。

対象者

• 正規化をちゃんと勉強したことがない
• MySQL、PostgreSQLを使っているけどなんとなくでテーブル追加、変更をしている
• 実行計画、INDEX、言葉は知ってるけどよくわからない

いつものようにデプロイしようとすると、突然落ちる CI ワークフロー。
Pull request の時点ではテストは通っていたはず…。
落ちたワークフローを確認してみると、 apt-get update が落ちている、だと…？

突然このような状況に陥っても慌てないようにするために、普段あまり意識することのない apt コマンドとリポジトリの関係について、そして最終的に何がエラー原因だったのか体験談を共有したいと思います。

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

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

昨今、WebAssemblyへの注目度や活用が盛んになってきています。Kubernetesへの利用 やdocker desktopで動作可能になったり、ブラウザ以外への利用も広まってきています。

特にPHPerから見ても実用性のある技術になってきていると感じており、wordpress-wasmを始め、ブラウザ上でPHPを動かすという世界観も現実味を帯びてきました。

そこで今回のトークでは、PHPをWebassemblyを用いてブラウザ上で動かす技術を紹介します。
デモとして実際に動かしてみて、そのために必要な技術や課題観を皆さんに共有できたらと考えています。

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

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

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

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

みんさんはLinterを導入されていますか？
・実装時のコーディング規約・ネーミング規約のチェック漏れが発生し、指摘対応・再レビューに工数がかかる
・コードレビュー時にコーディング規約・ネーミング規約の確認が面倒くさい
このような悩みを持たれている方は少なくないと思います。

「PHP_CodeSniffer」を導入することでそのような悩みを解決できるかもしれません！
そこで本セッションでは、「PHP_CodeSniffer」を導入したときの「実際にやって困ったこと」「やってみて初めて分かったこと」など
体験談を交えながら話していきます。

具体的には以下のような内容について話をする予定です。
・「PHP_CodeSniffer」とはなにか？
・「PHP_CodeSniffer」を導入するに至った経緯
・「PHP_CodeSniffer」を導入してみて

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

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

本講では、

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

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

PHPに存在する "魔法のような" メソッド「マジックメソッド」。
普段はあまり気にしなくても、フレームワークやライブラリのコードを読むときに、見慣れないメソッドが出てきて処理を追う手が止まってしまったことはありませんか？
一つ上のPHPerになるために、これを機にマジックメソッドについての理解を深めましょう！！
本セッションではいくつかのマジックメソッドについて、クイズ形式でその効果や利用方法を説明します。

海外チームとのオフショアでは、少し特殊なコミュニケーションスキルが求められます。

単純なタスクを依頼するだけではどちらにも悪意がなくても想定外の落とし穴にハマってしまい、なにかしらの手戻りが発生してしまうため、タスクの依頼以上の情報提供や、サポートが必要になります。

どのような状況でどんな問題や認識齟齬が発生するのか、またどのようなアクションを取ることで認識齟齬を回避できるのか...　オフショアチームとのやりとりを3年続ける中で得た知見を、NGパターンとOKパターンを提示しながらわかりやすくお話しします。

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

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

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

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

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

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

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

開発をしていると「この変数は何を表しているのだろう？」とか、「この関数は何をしているのだろう？」とか、一目見ただけでは何を伝えたいのかが分からない命名を目にすることがあります。
意図が伝わらないだけであれば調べれば済むかも知れませんが、時には命名が誤解を招き大問題に発展することもあります。
そんな不幸を呼び寄せる命名をあなたも知らず知らずのうちにしているかも知れません。
ここでは実際に私が見た「君はそもそも何をされてる方なの？」と言いたくなる命名の数々をご紹介し、命名の重要性を論じていきたいと思います。

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

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

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

利用するフレームワーク

• Symfony

はなすこと

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

はなさないこと

• Symfonyの細かい話