トーク

もし何かの間違いで採択されてしまったら
https://www.youtube.com/watch?v=F71zTEPwy5c
これのPHPerバージョンを頑張って作ってLT会場を温めます！出順はトップバッターでお願いします！

どうも、要件ヒアリングに自信ニキです。
私はフリーランスエンジニアとして受託開発のお仕事をよく頂くのですが、お客さんとの対話・ヒアリングを割と得意としています。

お客さんはシステム開発のプロではないので、説明が的を射ないことも多く、複雑なシステム要件のヒアリングには根気と体力を要しますよね。
そればかりか、なかなか合意や結論に辿り着けずいたずらに時間が奪われた挙句、結局失注して悲しみ、といった経験はないでしょうか。

私はよくお客さんから「1しか言ってないのに100のアウトプット出てくるんやが」「話が早すぎてもはや笑える」などと言われます。
一体私はお客さんとの対話中に何を考え、どんな手順でヒアリングを進めているのでしょうか。

このLTでは、お客さんとの対話中の私の頭の中身をまるっと皆さんにシェアします。
明日からのお客さんとの対話・ヒアリングに少しでも役立てていただけると嬉しいです！

Macユーザーの皆さんにはお馴染みのHomebrew。
Macの初期設定時のみならず、日々新たに便利なコマンドを見つけてはbrew installしていることと思います。
そんなお馴染みのHomebrewですが、裏側はどんな仕組みになっていて、コマンド自体はどこからダウンロードされているのかはご存知でしょうか？

実はこれ、とても簡単な仕組みになっていて、誰でも自分のGitHubリポジトリを通して自作のコマンドをHomebrewで配布することができます。

このLTでは、実際にPHPでCLIツールを作ってHomebrewで公開するまでの流れをお話しします。
自作のコマンドをHomebrewで公開して、世界に羽ばたきましょう！

Macで複数バージョンのPHPを使い分けるのって意外と難しくないですか？
Docker経由でしかPHPを使わないみたいな猛者スタイルで行ければいいのかもしれませんが、
パフォーマンスや開発体験の問題からローカルのPHPを使いたい事情もあると思います。
phpenvやsymfony-cliと.php-versionファイルを併用すればディレクトリごとに使用するPHPバージョンを指定することもできますが、
この辺はいざ導入しようとするとYak Shavingの嵐が待っていて（実体験）非常に面倒だったりします。

というわけで、このLTでは私がMacのローカル環境で複数バージョンのPHPを楽に使い分けるために実際にやっていることを5分でサクッとお伝えします。
実際に運用していてまったくストレスを感じていない方法なので、ちょっとでも困っている人には明日からすぐにお役立ていただける内容だと思います！

SPA全盛の時代ですが、凝ったUIを必要としない社内システムなどでは、
まだまだ古き良きMPA（Multi Page Application）構成を採用することは普通にあります。

MPAだとビューのテストは基本的にフレームワークが提供してくれる結合テスト基盤を使って行うことになると思いますが、
結合テストで検証できるのはあくまでHTTPレスポンスの内容までで、その後ブラウザ上で行われるJavaScriptの処理はテストすることができません。

MPAでも一部の画面にだけちょっとしたDOM操作や非同期処理が必要になるケースは多く（例えばいいねボタンとか）、
このようなJSの処理は上記の理由から自動テストがサボられがちです。

このトークでは、こういったMPA上のJSの処理をe2eテストによって楽にテストする方法を、Laravelにおける実装例をもとに解説します。

API Platformは、SymfonyをベースとするPHP製のオープンソースAPIフレームワークです。
Symfonyアプリケーションにアトリビュートを1行追加するだけで一瞬でREST APIとOpenAPIドキュメントを生成できてしまう優れもので、
Symfonyのエコシステムにおいてはすでに決定版と言える存在となっています。

このトークでは、API Platformの導入方法から、State Provider・カスタムコントローラ・State Processorといった重要な基本機能の概要までを、
実際に動作するデモをお見せしながら丁寧にご紹介します。

皆さんにAPI Platformの概要を知っていただき、少しでも興味を持っていただければ幸いです！

令和になっても相変わらず紙の書類の需要は大きく、Webアプリ開発においても帳票印刷機能は多くの案件で要求されます。
しかし、これがとにかく面倒くさい。

• 複雑なレイアウトの帳票をHTML/CSSでデザインするのが地獄
• かといって超微細Excel方眼紙でデザインするのはもっと地獄
• しかもPDFに変換するときに微妙に見た目が崩れてどうにもできない

帳票印刷機能を実装したことのある方には強く共感していただけると思います。

そんな面倒で難しい帳票印刷ですが、実は私は既に数年前に最強無敵のソリューションを編み出し済みです。

• ピクセル単位で細かく帳票をデザインできる（しかも簡単に）
• 帳票デザインの保守性が高い（修正が容易）
• 印刷時に見た目が一切崩れない

という条件を満たせる唯一（当社調べ）の方法です。

このトークでは、この至高のソリューションを具体的に解説します！

SPA全盛の時代ですが、凝ったUIを必要としない社内システムなどでは、
まだまだ古き良きMPA（Multi Page Application）構成を採用することは普通にあります。

MPAだとビューのテストは基本的にフレームワークが提供してくれる結合テスト基盤を使って行うことになると思いますが、
結合テストで検証できるのはあくまでHTTPレスポンスの内容までで、その後ブラウザ上で行われるJavaScriptの処理はテストすることができません。

MPAでも一部の画面にだけちょっとしたDOM操作や非同期処理が必要になるケースは多く（例えばいいねボタンとか）、
このようなJSの処理は上記の理由から自動テストがサボられがちです。

このトークでは、こういったMPA上のJSの処理をe2eテストによって楽にテストする方法を、LaravelおよびSymfonyにおける実装例をもとに解説します。

API Platformは、SymfonyをベースとするPHP製のオープンソースAPIフレームワークです。
Symfonyアプリケーションにアトリビュートを1行追加するだけで一瞬でREST APIを作れてしまう優れもので、
Symfonyのエコシステムにおいては既に決定版となっています。

しかし、ある程度複雑なことをしようとすると途端にフレームワークについての深い理解が求められたり、
痒いところに手が届かず強引なワークアラウンドが必要になったりするという面もあり、入門と実戦の間には大きな隔たりがあります。

このトークでは、API Platformの導入方法から基本機能の概要、さらには実践投入に向けた各種ワークアラウンドや実装テクニックを、
実際に動作するデモをお見せしながら丁寧にご紹介します。

API Platformの実戦投入、あるいはその検討の一助になれば幸いです！

コミュニケーションにおける「パス」について、「コミュニケーションパス」がまず頭に浮かぶと思います。

いわゆる、1対1のコミュニケーションがどれだけ発生するか？というコミュニケーションパスとともに、チーム間を跨ぐ場合に誰を経由してコミュニケーションするか？という経路としてのパスもあります。

個人的に、直接のコミュニケーションにおけるやりとりも「パス」(pass)することだと考えていて、相手にいいパスを出せるか？というのもチームコミュニケーションにとって大切な要素ではないでしょうか。

本トークでは、

• コミュニケーションパスの数
• 1対1のコミュニケーションにおける対話（パス交換）
• チーム間のコミュニケーション経路

というような、チームコミュニケーションにおける「パス」に着目して、私が大切にしている考え方を共有させていただきます。

ある日、「手動オペレーションに定評がありますね！」（意訳）と言われたことがあります。（全然ネガティブな文脈ではないので安心してください！！！！！！！！！）

特にプロダクトの初期フェーズにおいては、プロダクト自体の機能や価値提供のために、管理画面の開発などの優先順位が下がることがあると考えています。

運用フロー、提供フローが定まっていないうちに画面を作り込んでしまうなどが、「早すぎる最適化」になってしまうこともあるでしょう。

そのような事態を避けるためにも、作り込めるポイントがくるまで、安定した手動オペレーションを行うことはチームにとってもプロダクトにとっても大切なことなのかもしれません。

本トークでは、手動オペレーションを行う際に私がどのようなことを心がけているのか？という話を中心に、作り込めるポイントをどう判断しているのかをお話ししてみたいと思います。

コードの問題点は見た目には分かりにくいことがあります。

知らず知らずのうちに悪いコードが増え、気付いた時には『レガシーコード』と呼ばれるような状態になっているかもしれません。

そこで、問題点に気付くための1つの方法として、コードを計測する方法があると考えています。コードの計測によって得られる情報は多岐にわたり、コードのサイズ、重複コードの有無、コーディング規約の遵守状況、循環的複雑度、エラーの有無などが含まれます。これらの情報を分析することで、コードの状態を知ることができます。

ただし、計測した数値は必ずしもそれ単体で問題点を示す訳ではありません。そのため、他の数値と組み合わせたり、実際にコードと対比して判断・行動することが重要です。

本トークでは、特にコードをツールで計測することによって得られる結果に着目し、コードの改善にどのようにアプローチするかをお話しします。

コミュニケーションにおける「パス」について、「コミュニケーションパス」がまず頭に浮かぶと思います。

いわゆる、1対1のコミュニケーションがどれだけ発生するか？というコミュニケーションパスとともに、チーム間を跨ぐ場合に誰を経由してコミュニケーションするか？という経路としてのパスもあります。

個人的に、直接のコミュニケーションにおけるやりとりも「パス」(pass)することだと考えていて、相手にいいパスを出せるか？というのもチームコミュニケーションにとって大切な要素ではないでしょうか。

本トークでは、1対1のコミュニケーションにおける対話（パス交換）に着目して、私が大切にしていることを共有したいと考えています。

アプリケーションのパフォーマンス改善を行う場合、適当に手を動かしてもうまくいかないことが多いと思います。

少しでもよいカイゼンを行うためには「事実」を把握するために「計測」するというアクションが大事です。

ツールを使ってコードのメトリクスの取得するのも1例です。
コードのサイズ、重複コードの有無、コーディング規約の遵守状況、循環的複雑度、エラーの有無などコードに対する「事実」を把握することができます。

把握できた色々な「事実」を元に、どこがアプリケーションの改善点なのか…？何がアプリケーションにとって最適なのか…？？プロダクトにもっとも寄与するためには…？？？を考え「判断」し、「行動」に繋げていきたい。

このトークではどのように考えてカイゼンのための行動をとっているのか？をお伝えしたいと思っています。

モブプログラミングを始める際は、業務コードを書き始めるのではなく実験的なコードから入るのが良いとされています。
そのためには実験用のリポジトリが必要です。

しかし、下記のような問題でリポジトリ作成ができず、モブプログラミングを始められないケースが考えられます。

• Organizationにリポジトリを作る権限が無い
• リポジトリの作成申請にとても時間が掛かる
• Organizationに参加していないメンバーが参加する

このセッションでは、GitHubリポジトリにあるCollaborators機能を用いて、手軽にモブプログラミングを始めるためのリポジトリを準備する方法を紹介します。

このセッションでは、並行処理のパラダイムシフト、アクターモデルの探求とその魅力に焦点を当てます。
基本的な概念から実践的な利用まで、アクターモデルがPHPの開発者にどのような新たな視点と可能性を提供するかを掘り下げます。
アクターモデルの基本的な概念やダイナミックな特性などを解説、
並行処理の挑戦にどのように対応するのかを理解し、
なぜマイクロサービスアーキテクチャやES+CQRSで協力なサポートを得られるのか、
などなど皆さんの開発へのヒントになるような内容をお届けします。（もちろん失敗談なども）

PHPだけで実現するのは難しいものですが、並行処理の新たなパラダイムであるアクターモデルを理解し、
適材適所に組み込むための手引きとなることを目指します。
アクターモデルが新たな視点と刺激を提供し、PHPによる開発が新たなレベルに達する一助となることでしょう！

「マイクロサービスは銀の弾丸なのでは・・！？」以前の私はそう考えていましたが、現実は甘くありませんでした。

今回のトークでは、PHPやRailsでゴリゴリにモノリシックな開発に飽きつつあった私が、ゴリゴリにマイクロサービスな開発をする環境に移ってどのような学びを得たかをお話しします。

・経験の前後でマイクロサービスに対して感じたギャップ
・今更感じる、マイクロサービスの長所と短所
・運用の難しさ（複雑性やトラブルシューティング） ※特にフォーカスしたい箇所

これらのテーマに添いつつ、今の会社に移ってから肌で感じた「マイクロサービスアーキテクチャによるプロダクト開発のリアル」を共有し、お互いの学びの場になればと考えています。

※本トークでは、特定のプログラミング言語やライブラリ、フレームワークを深掘りする話はしませんが、私のさじ加減で組織・チームの話は入るかもしれません。

2人月くらいの工数がかかる機能開発を1人で担当することがあります。
納期のプレッシャーに追われながら必死にコードを書いた結果、気づけば1回で80ファイル分の変更がある地獄のような巨大プルリクが出来上がっていました。

レビューをすり抜けたバグが障害を発生させてしまい、どげんかせんといかん！となった時に改善を行ったことで、リリースを細かくできたり、障害の発生が抑えられたりと良いことづくめで開発品質を上げることができるようになりました。

このLTでは、PRを分割した方法や分割することの大事さについてお話します。
PRを小さくしてみんなで幸せな開発ライフを送りましょう。

プロダクト開発激化時代において、より魅力的で競合優位性のあるプロダクト開発をしていくために開発組織の育成は必要不可欠です。
開発組織の開発力、生産性を上げるために避けては通れない、エンジニア一人ひとりの技術力アップをどのように推進していけばよいのでしょうか。
私がEMとして、ここ数年考え実践してきたエンジニアの教育において必要な要素や考え方について、理論を具体例をおり混ぜながら話します。
（なお、本セッションはPHPカンファレンス福岡と沖縄で話した理論と実践の話の再編になります）

トークの流れ

最初に組織において育成がなぜ重要なのかについて話します。
「個への育成」と「組織への育成」へフォーカスを移し、それぞれへの育成理論や1on1などで使える具体例を紹介します。
最後に弊社で組織での教育の仕組みづくりをどのようにして行い、どのように変わったのかを話します。

俺は普通のPHPer。今日もそれなりのコードを書いて普通にGitを使ってチーム開発をしている。

「(git add / git commit / git push)」
「プルリクエスト出したので確認お願いします！」

これはいつもの日常だ。

俺も入社したての頃よりはGitコマンドにも慣れて開発出来るようになってきたな。

そういえばこの前、git rebaseやgit cherry-pickとかいう便利そうなコマンドのことを先輩から聞いた。

でもなんだか難しそうだし、今は困っていないからいつか調べてみよう。

LT内容

私も以前はこのPHPerと同じでしたが、ブランチやコミットを整理してレビューしやすいプルリクエストを作ることで、チーム開発がスムーズに進むようになりました。
このLTでは、時間が許す限り、発展的なGitコマンド・オプションの使い所をお伝えします。