日々のチーム開発のスループットを上げる取り組みを紹介していきます！

会社でのプロダクト開発では複数人のチーム開発で進めている方が大多数だと思います。
皆さんはチーム開発で何か課題を感じたり、もっと開発のスループットを上げたいと思ったことはありますか?

弊社ではスクラム開発を採用していますが自分が今いるスクラムチームでどんな課題があったのか、 それをどのように解決してスループットを向上させていくのか
試行錯誤して徐々に改善をしていった事を話します。

昨今のChatGPTをはじめとした生成系AIはますます盛り上がりを見せており、いくつもの企業が生成系AIを利用した事業の発展を宣言していたりします。
そんな中で、自分が携わるプロダクトでも生成系AIを導入したので、その背景や過程について共有していきたいと思います。
まず、なぜ生成系AIを導入しようと考えたかの背景や、その検証のさいに困ったこと、そして助かったことなどについて話します。
次に、生成系AIで利用したAzureのOpenAIサービスについて、できることを簡単に述べたのち、実際にどのように実装したのかについて紹介し、AIが生成するものの不確実性との戦いについても簡単に見ていこうと思います。
最後に、生成系AIを導入した結果どうなったかが表れていると思うので、その結果について共有しつつ、今後の生成系AIの発展についても紹介したいです。

「ユニコーン企業のひみつ」「チームトポロジー」の翻訳もあり、エンジニア組織の形態についての発信が増えたと感じます
主にはシニアテックリードやCTO・VPoEの視点からの、組織全体レベルでどうデザインするか？が多いですよね

コミュニケーションやチームに関する課題は、もっと卑近な単位でも発生します
仕事をうまく行かせるための大〜小の組織づくりについて、学んでみませんか？
「組織パターン」は、発売は10年ほど前ですが、組織に関する知見がパターン・ランゲージ形式で纏められた1冊であり、多くのヒントが得られるはずです

本トークは「ちいとぽよりも小さく、明日から使える組織づくり」を主眼に、書籍の内容・使い方を、実際の活用経験を交えて紹介します

対象

• 全体までは見ていないが、組織について考えている人
  • チームリーダーやEMなど

複数のテーブル構造を1つの集約として一括で取り扱うことができるRepositoryパターン。
Repositoryを呼び出す側からは複雑なテーブル構造などを隠蔽できるため、綺麗に実装できます。
ただし、当然ながらRepositoryパターンでは1オブジェクトに対して1回保存処理を行うので、クエリもオブジェクトの数だけ発行することになります。

画面から1つのオブジェクトを保存するだけであればパフォーマンスとかは気にしなくてもいいのですが、
例えば、CSVで一括登録する処理だったり、キューに溜まったものを深夜に処理するバッチのように、
大量のオブジェクトを登録する場合はクエリ発行回数が多くなってしまい、処理パフォーマンスは下がってしまいます。

そこで、本発表では、Repositoryパターンで綺麗に処理を書きつつ、一括保存をするためにやったことを紹介しようと思います。

勉強会とかカンファレンスに何回か参加しているとそのうち湧き上がってくる感情があると思います。
それは、自分も登壇する側に立ってみたい！

でも、
発表には憧れてるけど、発表することがない。
自分なんかが発表したって誰にも刺さらないでしょ？
発表したいけど発表ネタが浮かばないから、手を挙げられない。

その一方で、いつも登壇してる人がいるし、なんなら勉強会が決まった後にネタなんて考えればいいでしょ？って人もいるんです。
同じようにネタがないのに発表できる人と発表を尻込みしてしまう人、この違いはなんなんでしょうね？

そこで、ネタがなくて発表を尻込みしちゃっていた自分が、発表ネタを見つけるために心がけたことを話します。
同じように発表したいけど話すネタがなくて困ってる方の背中を押せたら嬉しいなと思います。

アプリケーションコードや運用保守などSQLを使ってクエリを書く機会は多々あります。
皆さんはSQLを使ってクエリを書くとき、どんなことを意識していますか？
「えーっと、まずはSELECT句から書いて…」
簡単なクエリを書く分にはそれでも良いですが、複雑なクエリを書かないと目的が達成できないような状況だったらどうでしょうか？

当LTでは複雑なクエリを書く上で必要な観点について話していきます。
具体的には以下のことについて解説していきます。

• ベン図を意識しよう
• 複雑なクエリは複数のクエリの塊なので、一つ一つのクエリを動作確認しながら進めよう
• SQL実行順序に沿ってクエリを書いてみよう

ある程度ゆるくコードがかけてしまうのもPHPの良さ。
しかし、キャリアを進めていけば必ずテストや静的解析で品質を担保する機会はやってきます。

「テスト書け！話はそれからだ。」「PHPStanのレベルは5以上な」
急に上司から命じられ、ゆるふわPHPerは愕然とすることでしょう。

本LTでは、テストを書くこと、静的解析がプログラムの品質にどうメリットがあるのかに加え、
それらがゆるふわPHPerの開発者としてのキャリアにもたらすメリットについてもお話しします。

結論、テストと静的解析はいいぞ、になるのですが、世の若手が
なるべく負荷なく自主的にテスト、静的解析したいぞ、となるLTにします。

対象者
PHPUnitやPHPStanをなんとなく触っている若手
全く触ったことない初心者
とりあえずテスト書けで終わらせちゃうシニア

話さないこと
細かいPHPStanやPHPUnitの書き方

PHPの配列（HashTable）は内部的には２つの実装で表現されています。１つはキーがそのまま添字となる配列、もう１つはハッシュ表を用いる連想配列です。
キーがそのまま添字となる配列（PackedArray）は、PHP8.2からzval構造体の配列となり、Bucket構造体が不要になりました。

このトークでは、PHP8.2におけるHashTableの解説と、HashTableからデータを探索する処理（zend_hash_lookup）、PackedArrayが通常の連想配列へ変換する処理（zend_hash_packed_to_hash）についての説明を行います。

対象者

• php-srcに興味がある人
• データ構造が好きな人

話さないこと

• PHP≦8.1の話
• 探索以外のHashTableの基本操作（追加・更新・削除）
• （パフォーマンスなど）実用的な話

みなさん、テストを“書かされて“いないでしょうか？

私は以前、テストコードに対する苦手意識が高く、テストコードも合わせてリリースするルールがあるから書く、という気持ちで書いていました。
約1年間抱いていた苦手な思い、なんと丸一日で（ほぼ）なくなりました！
やったことは、テストコードのペアプロです。

• ペアプロ中に意識して取得した知識
• 苦手意識がなくなったことで得たメリット

をお話しします！

皆さん開発を楽しめて進められていますか？
現在開発周りではCI/CD、テストコード、デプロイ自動化など多くの生産性を高める技術というのが多いと思います。
ただし、慣れてない方にとっては最初の一歩はとてつもなく大きいと思います。

本トークでは、そんな慣れていないときの最初の一歩を踏み出すための心構えに関して話したいと思っています。

▼対象者

・何かの改善をしてみたいが思いつかない方
・提案するのが怖い方

▼話すこと
日々の業務や開発プロセルに関して下記のようなことを話す予定です。

・どういうところに「カイゼン」ポイントがあるか
・改善する時の観点について

※諸事情により参加できなくなったため、プロポーザルを取り下げます。申し訳ありません。

Fiber は、PHP 8.1 から導入された stackful な coroutine です。
ここで一度、Fiber の実装を PHP の処理系レベルまで追いかけることで、Fiber が何であるか、そして、裏で何をしているのかを理解することにしましょう。

主な対象

• 非同期処理の内部実装に興味があるかた
• 言語処理系の内部実装に興味があるかた

話すこと

• PHP における「Fiber」とは何か
• PHP の VM (virtual machine) のおおまかな構造
• Fiber を実行・停止・再開・中断したとき、PHP VM に何が起こるか

話さないこと

• Fiber を裏で利用するライブラリやフレームワーク

※諸事情により参加できなくなったため、プロポーザルを取り下げます。申し訳ありません。

Garbage collection (GC) とは、確保したメモリ領域を適切なタイミングで解放する仕組みのことです。
メモリが比較的潤沢になった今でも、メモリ溢れによるサーバ障害は決して珍しくありません。
PHP における GC を理解し、メモリを意識したプログラミングをすることで、本番サーバを夜中に落とさないようにしましょう。

主な対象

• 普段メモリを意識してプログラミングしていないかた
• 言語処理系の内部実装に興味があるかた
• メモリ溢れで本番環境をダウンさせたことのあるかた

  話すこと

• PHP における GC のアルゴリズム
• 確保したメモリはいつ解放されるのか
• メモリ溢れを起こさないプログラミング

  話さないこと

• GC のパラメータをいじってチューニングする

REST API を利用したり機能追加するときに、こんなことを思ったことはありませんか?

・必要なリソースを取得するために複数の API を実行しないといけない
・機能追加に伴って API のエンドポイントが増えて管理が大変

GraphQL を利用すると、クライアントが必要とするリソースだけを 1 回のリクエストだけで取得できます。
さらに、 GraphQL のクエリに、クライアントが要求するリソースの情報が記載されているため、従来の REST API のように、必要と思われる分だけエンドポイントを用意する必要もありません。

本 LT では、 Laravel と GraphQL を使って、 API サーバーを構築する方法を紹介いたします。
GraphQL に興味があるけれど触ったことがない方々に、始めるきっかけとなれば幸いです。

不正アクセスが怖くて夜しか眠れない、情報流出のニュースを見るたび不安で寿司しか喉を通らなくなる、
Webエンジニアはこういった日々を過ごしていると思います。

このセッションではLinuxの機能 AppArmorを用いて、PHPアプリケーションのセキュリティを外側から強化する方法を紹介します。

自分達が書くPHPコード自体の脆弱性だけではなく、フレームワークやライブラリ、またHTTPサーバー自体の脆弱性もカバーできる便利な機能です。
OSの機能でアプリケーションに対してファイルシステム・ケーパビリティ等の制限ができ、設定ファイルを用意すれば使えるため採用の手間も大きく有りません。

お客様のデータを預かるWebサービスでは信頼が第一、まだ使われていない方も使おうと思えるよう、具体的な設定例も踏まえて説明できればと思います。

【想定対象】
バックエンドエンジニア、インフラエンジニア

皆さん！ 何かしらcomposerコマンドを叩いたことがありますか？
おそらくこの会場に足を運んでくださっている皆さまなら、何回も叩いたことがあると思います！

しかし、どうでしょう？
パッケージの導入や依存関係の管理をサポートしてくれる神ツールだと思いながら、特定のコマンドだけなんとなく叩いていませんか？
ComposerはPHPシステム開発現場において、大体どこでも導入されているが当たり前すぎてあまり普段気にかけてやれない、、、そんな技術だと思います。

このLTでは、Composerのすごいところ、良いところを5分間できる限り話します！
具体的にはこんな話をします。
・Composer単体でのinstallからパッケージ導入までの話
・Composerがおすすめパッケージを勧めてくれる話
・痒い所に手が届くComposerコマンドの話
・Composerへの感謝の言葉

「コードレビューが順調に進んだほうが、チームの生産性が上がる可能性が高い」ということについては、違和感なく思う人が多いのではないでしょうか。

「順調に進める」ためには、それを意識することだけでなく、レビューする側・レビューを依頼する側のそれぞれにテクニックが必要になってきます。

このトークでは、かつて、「おまえのプルリクエストは大きすぎてレビューできない（意訳）」と実際に言われたことがある発表者が、現在までにどのような工夫をして「分割プルリクエスト」にたどり着いているのかを共有したいと思います。

なお、このトークのタイトルは「リーダブルコード」にインスパイアされていますが、トーク内容については特に関係するものではありません。

■想定する対象者

• プルリクエストのサイズが大きくなりがちなかた

■話さないこと

• コード自体をどう読みやすく書くか、など

みなさん、commitで物語は書いていますでしょうか？私は書いています。

commitとは「読み手を意識して書くもの」、すなわち物語なのです。
commitは歴史に残る重要な資産と考えている私のcommitの積み方を聞いてください！
共感したら始めてみて欲しいです！

私がcommitを積む上で気にしていること

• 読者にとって不要な「物語（=commit）」は積まない
• 「起承転結」を意識する
• 「文脈」を的確に伝える

皆さん、毎日デプロイしたくないですか？＼ した〜い ／

私たちのチームではふりかえりをした結果「毎日デプロイする！」という目標を立てました。

そのためにタスク分解とタスクの順番を工夫し毎日デプロイする体制に変えました。
そうすることでチームの意思疎通が以前より楽にとれるようになりました。

本トークでは自分たちのチームでやっていた工夫・訪れた良い変化をお話しします。
毎日小さくデプロイする魅力をお伝えします！

「良いプロダクトを作るためにもっとエンジニアとビジネスサイドで協力していきたい！！」
その想いを胸に半年前からスクラムを使ってプロダクトを作っています。

それまではエンジニアとビジネスサイドが同じチームで深く関わって仕事をすることがあまりありませんでした。
スクラムを入れる上でコミュニケーションの取り方をガラっと変えたかったのですが、ちょっとハードルが高いかもな、、と感じました。

そのため最初は敢えて「不完全」な形式でスクラムを始めました。
スクラムの良さをチームで実感するにつれて、徐々に「完全」なスクラムになっていきました。
そして今は「チーム全員で良いプロダクトを作っている」という感覚があります。

本トークでは、どのようにスクラムの体制を改善していったのか実体験をベースにして紹介します。

このトークの対象

• スクラムに興味がある人
• 組織的な課題でスクラム導入に悩んでいる人

私たちは「はたらこねっと」という求人広告サービスを開発しています。
「はたらこねっと」は2000年からサービスを開始しました。サービス開始以降何度かリプレイスを行っていますが、レガシーなコードがまだまだ残ってしまっている状況です。
そんなはたらこねっとに残ってしまっている技術的負債やレガシーコードを、PHPInsightsで可視化する取り組みを開始しました。
本トークでは、PHPInsightsを利用してコードを解析し、技術的負債を特定する方法について紹介します。
技術的負債の可視化にご興味のある方におすすめのトークです！