トーク

開発組織の開発力、生産性を上げるために避けては通れないエンジニア一人ひとりの技術力アップ。
私がEMとしてここ数年考え実践してきたエンジニアの教育において必要な要素や考え方について整理して話します。

トーク内容

メンバーを教育する際に気をつけていること
エンジニア教育する際のマインド
レベルごとの教育スタンス（ティーチング、コーチングの使い分け）
教育にまつわる理論（認知特性やラーニングピラミッドを活用する話）

想定視聴者

組織のエンジニア教育にミッションを持ち悩んでる人
エンジニアとして今後の成長方針に悩んでる人
教育に興味がある人

含まれないもの

エンジニアに必要な個別技術の習得方法
エンジニアとしてどのような個別技術を学ぶべきか

先輩「この実装はどうしてこうなっているの？」
自分「ここは〇〇という理由でこうしています！」
先輩「了解です、その説明はコードコメントに書いておくとよいので追記お願いします～」
コードレビューを受けているとき、こんな経験はありませんか？

コードで表現できないことを説明したいとき、それを書く場所の候補はコードコメント、コミットメッセージ、プルリクエスト（説明欄やコメント）と多岐に渡ります。
「どこに書けばいいのかわからない！」そんなときの指針となるお話をします。

PHP によって書かれた一般的な Web アプリケーションはリクエストごとに独立したプロセスによって処理が行われます。
そのようなアーキテクチャは ISUCON の参考実装が提供されている言語の中でも異質です。

RoadRunner は Go 製の PHP アプリケーションサーバで、リソースをリクエストをまたいで使い回すようにでき、他の言語と近いアーキテクチャを実現できます。
これによって他の言語と同じ土俵で戦うことができるのか、は気になるところですが、それ以前にそもそも RoadRunner に載せ替えることはできるのでしょうか？

本セッションでは ISUCON 12 予選問題の PHP 実装を RoadRunner で動作させるために必要なことと、RoadRunner に載せ替えたことによって変わることを説明します。

テストコードの書き方について説明する資料等は世の中に充実しつつあります。
一方で具体的にテストコードを書いていく様子を説明、実演する資料というのはまだ数が限られています。

そこで今回はソフトウェアテストの領域でよく題材とされる「マイヤーズの三角形問題」の実装を取り上げ、
素朴な PHP コードからはじまり、テストコードを補いながら、ときにつまづきつつ、解くべき問題を捉えたコードへと洗練させていく過程を実演します。

本セッションで扱うテーマ

• テストファーストなアプローチによるコーディング、リファクタリング
• PHPUnit の基本的な使用法と data provider の活用

本セッションで扱わないテーマ

• テスト戦略やテスト設計について

PHP現場に放り込まれた、右も左も分からないジュニアエンジニアがどうサバイブすればよいのか…を偏見で語ります

• どの本・サイト・Youtubeをみるべき？
• 「『武器』は装備しなきゃ意味ないぜ！」
• 「『わからないこと』がわからないこと」に立ち向かう
• ちょっとまってその実装！実装前にまず設計(？)！
• コミット前、PR前に一息つこう
• 恐ろしい(？)レビューに落ち着いて対処
• Merge後に振り返り
• 忙殺(主観)や無力感(主観)を避ける

PHPエンジニア初心者が心がけるべき事を紹介します
「先輩」へのメッセージもあります

※ N個の現場経験を元にしており、特定現場の話ではない
※ もっと良い「先輩」がいればそちらを優先せよ
※ 「お前はそんな立派なの？」「自分を棚上げは『先輩しぐさ』の基本ですよ」

「 なんてこった！PHPウェブアプリ公開は何かと金がかかる！なんでかJS方面は無料が多いってのに！？」そんな嘆き声が聞こえてきます。どうですか？

「当たり前では？」と思いますが、やはり金はかけたくないと思う、リーンですよリーンスタートアップ。

あげく円安の時代、t2.microですら¥2000円弱/月かかる今、我々PHPerはどのように無料もしくは低料金でPHPを使えば良いのでしょうか…？
安くあわよくば無料でPHPウェブアプリを公開する縛りプレー(？？？)のテク紹介をしたいと思います。

副次的に、様々なPHP環境構築やサービスの紹介になる予定です。

• 保証をするものではなく、実践は自己責任です
• 規約的に多分グレーでも、「倫理」的にはギリギリな要素を含みます
• 初心者でもOKです、多分
• 「昨今のフロントエンド界隈、うらやましいなァ！」

DORAによる調査、State of DevOpsが定義し、書籍「LeanとDevOpsの科学」の広まりと共に浸透したFour Keysという指標は、ソフトウェアデリバリのパフォーマンスを示すだけでなく、組織そのもののパフォーマンスに因果関係があると知られています。

ところで、この「組織そのもののパフォーマンス」というのは一体なんのことなのでしょうか?
本トークでは、「組織そのもののパフォーマンス」を財務諸表の観点から眺めることでFour Keysとの関連性を考えてみようと思います。

「オレオレフレームワークは忌むべきもの」ですが、昨今はライブラリや”設計”の浸透、PHPエコシステムの進化も進み、私見としては「禁忌する理由が減ってきた」という実感があります。

過去様々なオレオレフレームワークを作ってきた私の「令和5年最新版オレオレフレームワーク(仮称)」の設計をご紹介しつつ、私がオレオレフレームワークに取り組む理由である「既存のフレームワーク」のペインポイントと私がもつ”疑義”についてトークします。

同時に、なぜ過去のオレオレフレームワークが禁忌されたのか、ベタープラクティス・アンチパターン、「オレオレフレームワーク実行犯」である私の見解(≒自己弁護)もお話します。

さあ、再びフレームワークを我が手に

対象聴講者

• 中級以上、たとえばDI程度の概念を理解しているなど

PHPerKaigiに参加される方の中には、またプログラミング経験がほとんどなく
これからPHPを勉強しようと考えているという方も多くいらっしゃると思います。

そんな方々へ向けて、Webアプリケーション開発に必須の知識である
データベースやSQLというものを、世界一分かりやすく解説します！！！

このトークのゴールは、
・データベースという概念をなんとなく理解すること
・簡単なSQLを自力で書けるようになること
です。

僕自身が初心者の頃にこういう説明をしてほしかった…と思うような
順序と言葉遣い、例示を用いて、初心者向けに本当に世界一丁寧に（当社調べ）解説します！
ぜひお楽しみに！！！

※データベース/SQLというものを全く知らない方に基本のキを腑に落としていただくことが目的のトークなので、
分かりやすさを優先して厳密さを多少犠牲にする場面があります。上級者の方はご注意ください。

LaravelではRepositoryパターンは使いにくいんでしょうか。
「Repositoryパターンはデータアクセスロジックとビジネスロジックを分離し拡張性と保守性を高めた実装パターン」であると研修で理解しました。
しかしLaravel上でこの実装パターンを用いたところ、以下のような悩みに直面しました。

• 肥大化するクラスがServiceからRepositoryに移っただけではないか？
• 必要以上にファイルの数が増えてしまっているのではないか？
• 一覧表示などではパフォーマンスが劣化するのではないか？

ここではこれらの悩みに直面した新卒PHPerが奮闘し、どのようにRepositoryパターンで実装したのかを紹介していきます。
もし「もっと良い方法があるよ！」と教えてくれる先輩PHPerがいらっしゃいましたら、ぜひ教えてください。。。

見知らぬコード、深いスタック、多様なクラスやメソッド・・・・
それらに立ち向かうのは、楽しくもあり大変でもあることですね！頭がパンクしちゃうこともしばしば！

どうしたら、少しでも効率よく・安心しながらコードリーディングを進められるでしょう。
ポイントは、「要点を掴む(=肝心でない所は脳みそからflushする)」「振り回されない(=コードを行ったり来たりしやすくする)」事だと思います。
それを実践するためのツールや技法を用意できると良いですよね。

脳内で補いきれない所は、「道具」で補って賢くやりましょう。
Xdebugのステップ実行と、ホワイトボードツール(Miro)の付箋とメモを活用することで、とっても効果的にコードの理解を進めることができます！

ある程度複雑なライブラリを例に、実際に「どうやったのか」をお見せします。

ソフトウェア開発の現場に限らず、あらゆる改善活動において「正確な現状把握」は必要不可欠です。
パフォーマンスチューニングはその代表的な例でしょう。
では、リアーキテクチャリングやリファクタリングなどの改善においては、どのように「正確な現状把握」を行えばよいのでしょうか??
本トークでは、アーキテクチャの「正確な現状把握」に役立つアーキテクチャメトリクスという概念をご紹介し、後半ではPHPのアプリケーションで使えるツールをご紹介します。

本トークでお話しすること

• アーキテクチャメトリクスの概要
• PHPのアプリケーションで使える計測ツールの紹介

DORAによる調査State of DevOpsが近年、注目を集めています。
開発組織のパフォーマンスを計測する Four Keys という指標を耳にすることが増えてきました。
この Four Keysですが、計測してみたはいいものの、実際にはどのように改善していけばよいのでしょうか??
DORAは調査の結果からFour Keysの改善効果が高いことが特定されている組織の能力をDevOps Capabilities (27のケイパビリティ)としてまとめ、報告しています。
本トークではDevOps Capabilities (27のケイパビリティ) について、1つづつピックアップし概要をまとめ、ご紹介します。

本トークで話すこと

• DevOps Capabilitiesの概要
• DevOps Capabilitiesの紹介
• 今後新しく追加されそうなCapabilitiesの紹介

PHP8がリリースされ、追加された関数の1つにあるmatch式。
多くの場合、大体比較されるのはswitch文ですが、if文も代替できることをご存知、または知っているでしょうか？

今回の発表ではmatch式の基本と応用、発展形や本題のif文代替ケースをご紹介しながらどれだけif文とさようならができるか挑戦します。

発表内容

• 改めてmatch式を理解する
• 基本形とよくある使い方
• 良くない使い方
• 応用な使い方
• 個人的にやる使い方
• （ひらめく限りの）本当に使う？とんでもmatch式

対象者

• ～中級者
• PHP8.0以上

みなさんは「共通化処理」をしたことはありますか？
したことがあるという方の大多数はきっとその「共通化処理」によって様々な課題に直面した経験があると思います。
ある時は特定処理を達成のためのif文を共通化処理に追加、ある時は汎用処理で叶えられないので継承して新しく作り直すなど……
本当に「共通化処理」というものは存在するのでしょうか？

数十年に渡る「共通化処理」という夢物語を現実世界に置き換えたときの振る舞いや実際の見え方など、そして「共通化処理」という言葉の裏に隠れる真の意味を私の強い視点からお話できればと思っています。

本トークで話すこと

• 共通化処理と呼ばれるもの
• ソフトウェアにおける共通化処理の実態
• 本当に言われてほしい表現と実現について

本トークはPHP勉強会で発表した内容をフルリプレースする予定です

2018年に「Laravel Collection の計算量を調べてみた」というタイトルで PHP勉強会で発表を行いました。
https://speakerdeck.com/hanhan1978/laravel-collectionfalseji-suan-liang-wodiao-betemita

あれから、5年。月日が流れて、Collection にはメソッドが追加され、ロジックにも変更が入りました。
というわけで、今、計算量がどうなっているのか測り直してみました。

PHP は、気軽にウェブアプリケーションを作れる言語として、初心者から熟達者まで、人気のプログラミング言語です。
一方で、せっかく作ったウェブアプリケーションも、開発を続けていくと複雑性が増して、扱いづらくなってきます。

今まさに、目の前で積み上がる負債を見て見ぬ振りをしながら、追加開発を行うのは精神的にも辛いです。
本トークでは、今の開発をキープし、難解な設計論を避け、どうやったらレガシーになりにくく、レガシーになったとしても何とかなるウェブアプリケーションが作れるかをまとめます。

本トークで話すこと

• レガシー化しにくくなる PHP ウェブアプリケーションの基本方針
• 明快で分かりやすい開発時の約束事
• 負債を生み出しにくい開発フロー・開発組織の仕組み作り

"Lean と DevOpsの科学" で有名になった Four Keys など、最近はメトリクスという言葉をよく聞くようになりました。
ソフトウェアの改善においては、まずメトリクスを計測し、KPI を定め、改善を進めるのが王道です。
ところで、PHP のウェブアプリケーション開発で使えるメトリクス計測ツールは、どれくらいあって、何の指標が測れるのでしょうか？
一通り目についた計測ツールを試してみて、その結果をまとめてみます。

本トークで話すこと

• ２０２３年３月現在の計測ツール一覧
• ソフトウェア改善で使えそうな "おすすめの計測ツール"

弊社は11月に新しいサービスをリリースいたしました！
約半年間という限られた期間の中で２つ目のサービスを開発することは、試行錯誤と学びの連続でした。皆さんも新サービス開発時にAPI設計や既存サービスとの棲み分けに頭を悩ませたことはありませんか？
この登壇では新サービスリリースまでに蓄積された開発ノウハウをご紹介できればと思います。

▼お伝えしたい開発ノウハウ

・新サービスAPIの設計、構築
・既存サービスとの棲み分け
　・ログイン、メール基盤
・その他
　・feature flag運用
　・リリース前後の準備

メソッドインジェクション、使っていますか？

Laravelではコントローラーのインスタンス化の際にコンストラクタに明示された依存クラスを注入してくれる「コンストラクタインジェクション」だけでなく、メソッド実行時に引数に明示された依存クラスをフレームワーク側が自動で解決してくれる「メソッドインジェクション」と呼ばれる便利な仕組みがありますが、この便利機能はどうやったら実現できるのでしょうか？

今回のトークでは簡易ルーティングライブラリを実装して、その大まかな仕組みを実演してみたいと思います！