トーク

現代において、エンジニアの仕事は常にチームで行われます。
チームで仕事を進める以上、他人との「意思疎通のスピード」が、チーム力に直結してしまいます。

チーム力を上げるために、組織ではさまざまな施策が実施されているかと思いますが、エンジニア個人でできる意思疎通のテクニックについて考えたことはないでしょうか？
チームで行われているコミュニケーション施策に乗るだけでなく、自らコミュニケーションを円滑に進められるよう能動的に動くことで、チームの力をもっと上げることができます。

本発表では私が仕事で実践している内容をもとに、明日から使えるチーム力向上を目指したコミュニケーションのテクニックと考え方をお伝えします。
これを聞けば、明日チームメイトから「ちょっと変わったね」と言われること間違いなし！

我々はのチームはつい最近結成されたら新チームです。チームも未熟でありながら何を作るかも決まっていませんでした。
そんなチームが顧客の要望に応えたい気持ちはあるものの人手も多いわけではないのでできることは限られます。

しかしこのチームが爆速にプロダクト開発をしています。
どんどん動くものができており、スプリントを進めるたびに機能は増えていき、スプリントレビューで改善のフィードバックをもらっています。

どのように開発を進めているのか、意識していること、テクニック、秘訣を教えます！

新しいチームやプロジェクトに参加した際には、まずシステム全体を大まかに理解することが重要です。これはすべてのコードを理解するわけではなく、システム全体の構造やその役割を把握することです。全体像を理解することで、自分の担当機能がどのようにシステム全体に影響を与えるかを見通せるようになり、自信を持って開発に取り組むことができます。この知識は、バージョンアップ対応やパフォーマンス改善、アーキテクチャ変更など、システム全体に影響するタスクで特に重要です。

本セッションでは、初見の PHP アプリケーションの全体像を掴む方法を紹介します。

このセッションでは、以下の内容を含む予定です。

• ビジネスにおけるアプリケーションの立ち位置
• PHP、拡張、パッケージの把握
• Xdebug デバッガでの追跡
• アプリケーション IO を見る

スクラム開発されている皆さん
ストーリーポイントによる見積は相対見積で、時間見積ではないとされています。
とは言っても様々な種類のタスクがある中で同じ基準で比較はなかなか難しいなと思います。

自分たちのチームは便宜上時間見積に近い形を取っており、
今回は実際にどのように進めているのか簡単に紹介してみようと思います。

私はコンピュータサイエンスの学位も海外留学の経験もない普通のエンジニアです。
そんな私が今年6月にLaravelのコアチームに加わり、グローバルなチームのなかで尊敬するメンバーたちと共に日々開発に携わっています。
このセッションでは、私が2014年にLaravelに出会ってからコアチームに加わるまでの経緯や、グローバルなLaravelコミュニティでどのような活動をしてきたか、そしてコアチームに加わってからの活動についてお話しします。
特別な経歴がなくても、行動することで可能性が大きく広がるということを、私の経験を通じてお伝えできればと思います。

このトークでは、OPcodeを読み進めていたはずが、気づけばPHPのソースコードを読み込むことになった体験を共有します。

当初はパフォーマンスや最適化を目的にOPcodeを読んでいましたが、調べるうちに言語の内部構造にまで興味が広がっていきました。
そのプロセスを具体例とともに振り返りながら、技術的な知識に加え、その過程で得た学びや気づきについてお話しします。

Laravel 11アップグレードに伴うCarbon2から3での変更について、実際のプロジェクトで発生した修正点を例を交えながら紹介します。

話すこと
・Laravelだけでなく各ライブラリのガイドを確認することの重要性
・Carbon3での変更により実プロジェクトで起きた修正例
・Github Codespacesによる開発環境構築が作業の助けになったこと

このコード、この機能、今も使われているの？
ある機能を削除したいけど影響範囲が分からないので怖くて手を出せない...

システムの機能削除は影響範囲が広く、ハードルが高いものです。
しかし避けているとシステムに不要なコードやファイルが残り続け、実装の妨げになりシステムの保守性が下がります。

そこで、本トークではシステムから不要機能を削除するためのポイントをご紹介します。
不要機能との向き合い方はシステムに左右されますが、皆さんにとってベストプラクティスを見つけるきっかけになれば嬉しいです！

【話すこと】
・不要機能がシステムに残るデメリット
・不要機能ってどこまで削除するの？削除の範囲を決めよう
・機能削除でエンジニア完結の判断は禁物、ビジネスサイドと連携しよう
・不要コードを生み出さないためにできること

ソフトウェア開発において、顧客理解や問題発見は、しばしばPOやデザイナーの役割とされます。しかし、私たちのチームは「解くべき課題について誰も具体的なイメージがない」という状況に直面し、チーム全員で顧客への理解を深めることを選択しました。

本セッションでは、PO1名とエンジニア2名で構成された新チームが、全員でペルソナを考え、ユーザーインタビューを実施し、プロトタイプを作成・検証するプロセスを共有します。そして、この取り組みを通じて、素早いアウトプットの重要性を再認識できた経緯について、エンジニア目線でお伝えします。

主な内容：

• チーム全員で顧客理解を深めるための具体的な進め方
• エンジニアが顧客理解を深めることの意義と効果
• 素早いアウトプットを出すために私たちができること

本セッションを通じて、エンジニアが顧客理解を深めることの意義について考えるきっかけになると嬉しいです。

【概要】
認証処理は一度実装されると変更が少なく、日常的に触れる機会が少ない分野です。
普段当たり前の様に使われている機能ですが、システムに必須かつ複数のサービスから使われるケースも多いため、システム全体の要と言っても過言ではありません。
そのため普段認証システムを触らない人でも、最低限の仕組みやフローを理解しておくことは重要です。

そこで、認証システムを触ったことがない人に向けて、事前に知っておくと便利なポイントをまとめました！
認証はハードルが高い分野ですが、トークをきっかけに認証システムに興味を持ち、日々の業務やトラブル対応に活用していただければ幸いです。

【話すこと】
・システム固有の知識+認証固有の知識を知ろう
・ユーザーの種類は？SNSログインは使うの？認証システムの仕様そのものを知ろう
・ウチの認証システム、どの認証フローを使っているの？
・認証についてもっと知りたい！

【概要】
ドキュメントを作ってチームに情報共有したぞ！これで属人化解消！と思ったら未だに自分宛に問い合わせが来る???こんなはずじゃなかったのに...皆さん、このような経験はありませんか？
せっかくドキュメントを用意しても、チームに読んでもらえない・理解してもらえないのでは作った意味がありません。
本トークでは、日常的な個人メモの取り方やそれをドキュメントに成長させる方法、さらにドキュメントを通じて業務の属人化を解消する方法をお伝えします！

【対象者】
・業務の属人化を解消したい人
・個人メモ・ドキュメントの作成が苦手な人

【目的】
・個人メモ・ドキュメント作成のポイントが分かる
・ドキュメントを通じた属人化解消

【話すこと】
・まずは個人メモから！記録のコツ
・個人メモとドキュメントはどこが違うの？
・ドキュメントを成長させるために必要なこと
・属人化解消のメリット

ご存知の通り、レビューとは「講評」「批評」という意味です。
そのためコーディングにおけるレビューも、どうしてもレビュワーから実装者への一方通行コミュニケーションになりがちな側面を持っています。

しかしレビューとは、実装者とレビュワーが解釈をすり合わせる場であり、
双方向のコミュニケーションをしてこそ、漏れなく効率的なすり合わせができると私は思っています。
今回は私がPRレビューを双方向コミュニケーションの場にするためにしていることを、3つお話しします。

• 些細な違和感を逃さない[Q]と[MEMO]
• レビュー修正者を迷わせない効率的レビュー
• チームメンバーの癖を把握した、メンバー特化型レビュー

テストを書くことにもだいぶ慣れてきましたが、いまだに嫌で仕方ないものがあります。それがデータプロバイダです。

データプロバイダを書くのは面倒くさい。本当に本当に面倒くさい。
というのもリリース恐怖症の私は、テスト対象のありとあらゆる条件やパスを通したくなります。
「いや〜書かなくても大丈夫だろうけど、怖いし一応書いとくか…」を繰り返すうちに、どんどんテストパターンが増え、データプロバイダが膨大になります。

ここでは、私をそんな無限コピペ地獄から救ってくれた「差分だけデータプロバイダ」をご紹介します。
同地獄に陥っている方の一助となれば幸いです。

⁠対象者

• いつもデータプロバイダが太りがちな方
• ツールなど使わず手動で、大量のパターンをテストしなければいけない方
• データプロバイダを書くのが億劫で仕方ない方

郵便番号とは、当たり前に都道府県・市区町村が特定できるものだと、そう思っている人はいませんか？
まさか「複数の都道府県にまたがる郵便番号」なんてあるわけない、そう思っている人はいませんか？

そんな罠にはまった私が、郵便番号に関する実装知見をクイズ形式で紹介します！

連想配列に全てを詰め込んで旅をさせるのは良くないとは分かりつつ、
今まで巨大な連想配列をゴリゴリ実装していたチームが、配列からの脱却への一歩に挑戦しました。
完全な配列脱却は難しかったものの、バランスをとったリアルな挑戦ができたのでお話しします。

話すこと

• 配列で書いていた時代の実例、課題、デメリット
• ファーストクラスコレクションとは
• 配列からの脱却に⁠ファーストクラスコレクションを採用した理由
• ファーストクラスコレクションに感じたメリット/デメリット
• デメリットをカバーするために生み出した、ファーストクラスコレクション亜種

Laravelに標準搭載されている対話シェル、tinker。
PHPの組み込み関数・Laravelのファサードの動作確認などなにかと利用シーンは多いかと思います。

今回のトークではもう少し踏み込んだtinkerの利用法や、
利用することによって得られる副作用をご紹介できればと思っています。

トーク目次

• tinkerの概要
• tinkerの使い方
• 設計面での副作用

本セッションでは、ADHDを持ちながら10年以上働いてきた視点から、どのように職場で適応するかについてお話しします。

テーマ

• ADHDを持つ本人が仕事をする上でやるべきこと
• ADHDを持つ本人が職場でのサポートを受ける方法
• 同僚がADHDを持つ（ように見える）時のサポート方法

「バージョンアップは大事だとわかっているけど、後回しにしてしまう…」そんな経験はありませんか？

ビジネスでは直接利益を生まないバージョンアップはつい優先順位が低くなりがち。
しかし、Web開発ではプログラミング言語やフレームワークなどのバージョンを常に最新を保つことが必要不可欠です。

このライトニングトークでは、限られたリソースや時間の中でも効率的にバージョンアップを進めるための心がけ5選を紹介します。
特定のツールに依存せず、汎用的に使える内容なので、すぐに実践できます！

今年の春、障害者差別解消法が改正され、SNSなどで注目を浴びたWebアクセシビリティ。

PHPではWebサービスやWebサイトに関係することが多いので、一度は言葉を聞いたことがあるでしょう。
あなたのチームではどの程度Webアクセシビリティを意識していますか？
自分のチームには専門家がいなくて...
などという消極的な理由で避けてはいないでしょうか？

私はWeb標準に興味があり、そういったコミュニティをやっていたこともあるのと、Webアクセシビリティが身近になってきた感覚があり、数年前より積極的に学習/啓蒙しています。
今年上記法改正があったこともあり、自社の中でWebアクセシビリティのワークショップを開催しました。そういった経験から専門家がいなくても始められるポイントなどを簡単にご紹介します。

本セッションでは、同じ会社のメンバーに登壇依頼、カンファレンスのスポンサー窓口担当や共にカンファレンスの登壇や参加準備することで職能間の境界を越えて交流することができ、私の社内でのコミュニケーション量が増加してきた話をします。

私は、社内外で勉強会をいくつか企画し開催してきました。開催した勉強会のテーマはそれぞれ異なっており、私が開催したいと思った勉強会を勢いで開催しています。

しかし、最初は私が開催するとは思っていませんでした。私が所属している会社は職能ごとにチームが分かれており、プロジェクトによっては他の職種のメンバーと話すことがないこともあります。
しかし、今では職種が異なるエンジニアとも勉強会をきっかけに交流し、関係を継続することができています。

本セッションを通して、自身の技術領域外の勉強会を開催することで得られる職能間の境界を超える楽しさについてお話しします。