トーク

ピープルマネジメントは「感情労働」と言われたりもしますが、その要因の1つは「色々な他人と真剣に個人対個人で向き合わなければいけないこと」だと思います。
共感し寄り添う必要がありつつ、「一緒に怒る」「一緒に焦る」という風にグラグラしていては身が持たない…という面もあります。

真面目に話を聞く！しかし適度に自身を安定させる！
その両立は、どのように可能となるのでしょうか？

リーダーシップ論を学んだり、コーチングのトレーニングを受けた事は、「自分の感情を保護する」のにも役立っていると感じます。
それらも踏まえ、自分自身がマネジメントに携わり2年ほどで、学んだ知識や実践の中で磨いてきたものを共有します。

触れたいこと

• 2種類の共感と共感的理解
• 自分と他人を区別する
• 評価と事実を切り分ける
• アサーティブなコミュニケーションを心がける
• 他人の価値観に目を向ける

皆さんはPHPStorm、Xdebugを使いこなしているでしょうか?
メソッドジャンプや、単純にテストを実行するだけで使ってないでしょうか?

このトークでは基本的なセットアップ方法から解説し開発チームが
PHPStorm + Xdebugを使って効率的にかつ、素早くデバッグを行えるTipsを紹介していきます。

・PHPコードの実行フローを追跡して、バグの原因を特定する。
・変数の値を監視し、変数の値や状態を確認する。
・ブレークポイントを設定して、特定のコード行で停止し、デバッグを進める。
・ステップ実行や式の評価を使用して、コードの動作を詳細に調査する。
・デバッグ時の便利なツールや機能を活用して、生産性を向上させる。
・Dockerを使ったリモートデバッグの設定と実行
など...

「チームでふりかえりをしている」という組織は多いと思います。
どんなふりかえりをしていますか？あるいは、何の為に行っていますか？

実際には、「出来事や結果を共有する」「その再発防止や改善について話し合う」ものになっている事が多いかも知れません

良いふりかえりは、「上手いやり方を学ぶ場」を超えて「チームが学び方自体をアップグレードして行く場」に成り得るはずです！
チーム自体の進化を促したり実感できるふりかえり、できていますか？
そうでないのであれば、何ができていて・何が足りていないのでしょうか。

「学習する組織」のコンセプトをヒントにして、ふりかえりについて改めて考えていきます

はなすこと

• ふりかえりの基本
• なぜ学習が大事なのか
• 個々人の意見出しからチームの相互作用へ

関連するキーワード

• 学習する組織
• 体験学習・わかちあい
• 自律的な組織づくり

アジャイルサムライの中では「概算見積もりは当てずっぽう」と書かれ、相対見積もりを推奨されています。
スクラムではストーリーポイントという名前を使って単位の意味合いを曖昧にすることで時間やお金に対する「約束」という概念から遠ざけています。

しかし、プロダクト開発をするうえではプロダクトロードマップがあり、それを達成することで事業成功を牽引する開発チームがあります。
プロダクトロードマップを作成するにも概算見積もりはあったほうが立てやすいですが、それが「約束」となって開発チームへの「呪い」ともなるケースもあります。
そんなPdMとエンジニアの狭間で、見積もりに対する考え方を言語化しチームに伝搬していこうとする話です。

みなさんライブラリを公開していますか？ PHPのサポートバージョンをどうやって決めていますか？

原則論で考えればEOLを迎えてサポート終了したバージョンや、極論をいえば自分が使っているPHPのバージョン以外はサポート継続する義理はないわけですが、技術者としては可能な限り古いPHPでも使えるように互換性を保ち続けたいというのは人情ではあります。

このトークでは個人的な興味でメンテナンスを継続しているPHPライブラリでいかにして後半なPHPバージョンをサポートしているか、そして開発体験を落とさずに古いバージョンへのサポートを維持するために考えられるテクニックについて紹介いたします。

アスペクト指向プログラミング（AOP）は、アプリケーションのコードベース全体に横断的に影響を与える部分（Cross-cutting concern）を効果的に管理するためのプログラミングパラダイムで、
オブジェクト指向プログラミングには無い新たな視点を提供します。

本トークでは、まずAOPの基本概念や利点について確認します。
その後、PHPで実装されたAOPライブラリを紹介し、どのように実装されているのかをライブラリによる違いや共通点に着目して深掘りします。
最後に、AOPを導入・活用するにあたってのポイントなどを紹介します。

本トークを通じて、AOPの基本概念を知り、PHPでどのように実現されているかを知ることができます。

「テストがないコードはレガシーコードだ！」
Webアプリ開発においてPHPUnitなどでテストが書かれることは一般的になりました。

ですが、テスト完走までにかかる時間は適切でしょうか？
テストにかかる時間は生産性に直接的な影響を及ぼす重要な要素です。早ければ早いほど良い。
本トークでは、PHPUnitで書かれているテストを高速化するテクニックについてお話します。

対象観客

• テストが遅いと感じる開発者
• チームの生産性を上げたいと考えている人

お話すること

• 目指すべきテスト時間
• phpunit-speedtrapプラグインを使って遅いテストを検出する
• Laravelで良く使われがちなDatabaseMigrations Traitは出来るだけ使わないほうがいい話
• "make -j" やparatestを使った並列化

セキュアなアプリケーションを実装することはとても大事なことですよね。
しかし、開発者だけで様々なセキュリティ対策を施すのは限界があります。

そこで本セッションでは、GitHubが提供する機能を活用することで「セキュリティ対策の仕組み」を構成する方法について解説します。

また、GitHub Actions＋クラウドサービスで実装可能なDevSecOpsについても解説を行う予定です。

ソフトウェアをソフト（変更容易）に作るって、めっちゃ難しくないですか？
私はずっと難しいと感じていて、設計のスキルを伸ばすのに苦闘しています。

そんな私にとって、2022年12月に発売された『ちょうぜつソフトウェア設計入門』（ちょうぜつ本）は非常に学びが大きい一冊でした。
躓いていた概念が（かわいい挿絵の力もあって）スルスルわかり、設計に関する知の高速道路と感じています。

このトークでは、設計スキルで壁を感じている方向けに、ちょうぜつ本や『Clean Architecture』を参照して、理解が深まったポイントを（使い慣れた）Python🐍のコード例を交えて共有していきます（PHPのコードは書籍をどうぞ！）。

トピック
・Clean Architectureとは
・オブジェクト指向 「鍵は抽象！」
・SOLID原則
・私見：一発でソフトに設計できるほど強くないと割り切る戦略

話者は前回のPHPカンファレンスにて「RFC911*から振り返るHTTPの仕様」という話をさせて頂きました。

その中で特に新しい仕様である「RFC 9114 - HTTP/3」を読んでインターネットの未来を感じました。

今回はHTTP/3に焦点を絞ってRFC 9114からの仕様を理解した後に検証を行い、これまでのHTTPとの違いを体験します。

PHPerとは切っても切り離せないHTTPの次世代プロトコルを体験することでその価値に触れ、
HTTP/3採用のモチベーションになれば幸いです。

• 想定する聴講者
  • HTTP/3に興味がある方
  • HTTPの仕様は知っているけど、HTTP/3について知らない方
  • HTTP/3に関する検証をしたことがない方

Webアプリケーション開発でデータストアとして良く使われているRDBMS 「MySQL」。
大きなシェアを誇るMySQLですが、ご存知の通り2023年10月に5.7系はEOLを迎えます。
安全のためにもMySQL 8へのバージョンアップが必要となりますが、メジャーバージョンアップとなると押さえておくべきことがたくさんあります。

本セッションでは、MySQLを8へバージョンアップするに当たって押さえておくべきこと、省力化する方法についてお話致します。

対象観客

• MySQL 5.7以下を運用されているみなさん
• MySQL 8に上げたけど痛い思いをしたので傷を舐め合いたいみなさん

お話すること

• 基本的なバージョンアップの流れ
• MySQLバージョンアップにおいて留意するべきトラップ
• バージョンアップ検証作業の省力化に使えるツールたち

PHPerの皆さまは今日もPHPを何処かの環境で動かしている事だと思います。

様々なクラウドベンダーの上にはPHPを動かす選択肢がいくつもあるのですが、
実際にどの環境で動かすのが良いのか迷ってしまいます。

今回はクラウドベンダーをAWSに絞り、
現在稼働させることのできるPHP実行環境の比較を行います。

より良いPHP環境を選択して、コスト効率よくPHPを運用しましょう。

• 想定する聴講者
  • PHPの実行環境に興味がある方
  • PHPの実行環境に興味がないのだけど選択を迫られている方
  • AWS初心者〜中級者の方

フレームワークは偉大です。
共有済みの知見を共有しながらスピーディーに開発を行えます。

今回その中身について深く知りたくなりフレームワークの気持ちを知るために
ある目的に合わせたフレームワークを作成することにしました。

その目的とはPHPをサーバーレスに動かすためのフレームワークです。
BrefというOSSと組み合わせながら、AWS Lambda上で快適に開発を進める事を目標に
フレームワークの作り方を学びながら、機能を再履修します。

OSSのコードリディングと手を動かすことにより、フレームワークの世界へDeepDiveしましょう

• 想定する聴講者
  • フレームワークの自作に興味がある人
  • サーバーレスに興味がある方
  • Brefが好きな人、気になる人

グローバルプロダクトを作ろうとすると、避けては通れないのが多言語化対応です。
データベースに保持される情報の多言語化はどうするのかが悩ましいところです。
そして、考えた先に思いつた EAV（エンティティ・アトリビュート・バリュー）という方法。

しかし、EAVは様々な理由によりSQLアンチパターンに含まれています。
その理由と照らし合わせて、実際どうなのかを考えた話

主な対象

• マスターデータの多言語化でお悩みの方
• SQLアンチパターンに興味ある方

■ あらすじ
今明かされるサイボウズGaroon開発チームの学生向けインターンシップの裏側。
以前開催されたのは2018年。
5年の沈黙を破り、開催されるインターンシップ。

ノウハウ乏しく、格闘するチームメンバー。
何を準備すればいいのか。
何をすれば学生は喜んでくれるのか。
最後に我々はこのインターンで何を得ることができたのか。

このトークは、そんなインターンシップの裏側で奮闘した者たちの、半年間の記録である───

■ 話すこと

• 優秀すぎる学生たちからどのように選考したのか
• インターン生の受け入れ準備で何をやったのか
• インターン生が求めるコンテンツと実際に一緒にやったこと
• インターンをやってみて得られたこと

■ こんな方向け

• インターンシップをやってみたいと思っている方
• インターンシップの進め方や内容に困っている方
• 学生との関わり方を模索している方

MySQLなどに代表されるRDBMSには、トランザクションをはじめとする排他制御が実装されています。 複数人から同時に使われうるWebアプリケーションにおいて、信頼できるデータストアとして十分な機能が備わっています。

一方で、RDBMS外のデータストアには、それと比較して柔軟な排他制御の機構を有しているとは限りません。 例えばオブジェクトストレージのAmazon S3などでは、占有ロックをとって書き込みを制限することはできません。

MySQLに備わる排他制御には、レコードやテーブル単位ではなく、任意の文字列でロックをとることのできる、ユーザレベルのロック操作(GET_LOCK関数)があります。 本セッションでは、この GET_LOCK関数を用いた排他制御と、それをオブジェクトストレージのデータ移行に適用した実例を紹介します。

私が担当するLaravelアプリケーションは、DBマイグレーションの問題、テストフレームワークの不在、CI/CD環境の欠如といった荒野のような状況でした
以下の改善策を実施し、アプリケーションは徐々に成長し、品質と開発効率が向上しました

• DBマイグレーションの問題に対処、スキーマの変更やデータの整合性を改善
• PHPUnitを導入し品質保証を強化し、テストカバレッジを向上
• CI/CD環境を整備し、自動化されたテスト、デプロイのパイプラインを構築

荒野のような状況から始まるLaravelアプリケーションの成長ストーリーを通じて、「PHPUnitの導入と開発環境最適化」がアプリケーションの品質と開発効率をどのように向上させたのかをお伝えします
参加者には、類似の課題に対する解決策と効果についての具体的な知識を提供し、自身のプロジェクトに応用できる洞察を得ることができれば幸いです

かつて登壇者の懇親会で、「いまどきテスト書こうなんて当然の話をトークしてもねぇ」みたいな話が出たことがあって、確かに！と思ったものです。
しかし、今でもテストを書いていない現場の話は聞きますし、テスト書くの大変という話も聞きます。
そこで、テストを書く意義をあえてしっかり言語化しておくことで、あらゆるエンジニアがテストを空気のように書くのが当たり前にしたいと思います。

まず、テストがあることで、本当の意味で実装が完了するということを、持続的な開発と実装のゴールの証明という観点で意義付けします。
また、その中で「カバレッジにこだわる必要はない」というある種の勘違いについても言及しておきます。
さらには、テストを書くことが、本質的にはどれも同じであり、習得コストが低いながらも効果の高いものであることを話していき、みんなでテストを書いて、エンジニアの価値を上げていきたいと思います。

みなさんは開発の際に用語集をつかっていますか？
人によって指す言葉が異なり混乱した経験はありませんか？
そんな悩みを、情報設計とユビキタス言語の定義を行うことで解決してみましょう！

最近、私が所属するチームで新規機能開発をすることがありました。
その際に、情報設計を行いユビキタス言語の定義を、エンジニア、デザイナー、ディレクターのみんなでやってみました。
その結果とても良い効果が得られたので、是非多くの人にそのノウハウをシェアしたいと思います！

本トークでは、実際の新規機能の開発においておこなった、情報設計やユビキタス言語の定義のやり方や進め方、それがその後のアプリケーション開発にどのように寄与したかについて話します。

IDはある要素を一意に特定するものです。まさに識別子です。
みなさんはID（の生成方法）をどのように決めていますか？
WebアプリケーションにおいてはMySQLのAUTO_INCREMENT属性やPostgreSQLのSERIAL型といったデータベースの機能を使った採番結果をIDとする方法がよく知られています。しかし、時にはデータベースによる採番では機能要件を満たせないことがあります。

IDひとつをとっても要件があり設計があります。

最近、私は2つのIDを決める場にいました。
1つはプロダクト内で使うID、もう1つはOSSのツールの中で使うIDです。
どちらも数値の採番では要件を満たせないと判断し、改めてIDの生成方法の検討をしました。
本発表ではそれぞれの事例でどのような課題があり、解決したのかを紹介します。

IDというみなさんに馴染みのある要素で、設計の楽しさを感じてください。