以前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ではそのような課題を解決できます。

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

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

対象者

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

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

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

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

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

現在私が 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

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

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

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

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

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

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

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

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

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

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

本講では、

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

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

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

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

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

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

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

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