トーク

PHPは裾野の広い言語です。WordPress、Laravelをはじめ、Web開発で広く使われており、コミュニティも非常に活発です。
そんな楽しげなコミュニティに異業種から転職したジョブチェンPHPerだって参加したい！

というわけで今年のPHPerKaigiからプロポーザルを送るようになり、先日無事福岡の地方カンファレンスで登壇デビューを果たしました！
このトークではその中で得られた知見についてお話させて頂きます。

これを機にプロポーザル送ってみようかな？という人が一人でも増えれば幸いです！

フロー効率という言葉を最近耳にしたことはありますか？
その対比としてリソース効率が用いられているのを目にしたことはありませんか？

このトークでは「フロー効率」と「リソース効率」という言葉をキーワードに

1. フロー効率が良くなると何が嬉しいの？
2. リソース効率を追求するとどうなるの？
3. 仕事をする上で２つの効率とどう向き合う？

という３つのテーマを使って、我々開発者を取り巻く環境における事例を交えながら人間にとって最も重要な資源である「時間」について深掘りしていきます。

タイトル見て共感した人、このトークのターゲットです。
データベースにおいてインデックスとは超重要な要素の1つです。
適切にインデックスを貼ることで処理を効率よく行うことができます。
「なんかよく分かんないけどじゃあとりあえず全部にインデックス貼っとくか」
これはアンチパターンです。
何故闇雲にインデックスを貼ってはいけないのか、適切にインデックス貼るとはどういうことか
実際に計測したデータを交えながらお話したいと思います。

開発していると何かと話に出る「具体と抽象」
何かを説明する時に抽象度ってとても大事だと思います。
例えばWebアプリケーションがどうやって動いているかを説明する際に、説明したい箇所や相手によって話す内容は異なるかと思います。
ネットワークの話が必要か？
Webサーバーの話が必要か？
内部で動いている言語処理の話が必要か？
これが理解できていないと、例えば営業の人にクエリの話を出してしまってポカンとされてしまう訳です。
逆に適切な抽象度で話ができれば人に説明するのがグンとうまくなります。

本LTでは抽象度についてお話したいと思います。

• コード書くの怖いな〜
• リリースするの怖いな〜
• このクラス触るの怖いな〜

こう思った経験、誰しもあるのではないでしょうか？
恐怖とはつまり「分からなさ」に起因していると私は考えています。
触った時の影響が分からないものは誰しも触りたくないと感じるかと思います。

本LTでは、そんな開発するうえでの恐怖にどうやって立ち向かっていくのか、お話できればと思います。

ブロックチェーンとは、一般的には、「取引履歴を暗号技術によって過去から1本の鎖のようにつなげ、正確な取引履歴を維持しようとする技術」とされています。
今回はPHPを使ってブロックチェーンのサンプルアプリを実装する話をします！具体的にはコミュニティに招待するとトークンが付与されるアプリを作る予定です。
本当にPHPでも実装できるの？と疑問を抱いている方は是非聞いてください！

これまで20年間にわたりPHPで開発したB向けのクラウドサービスを運営してまいりました。
現在はGMO医療予約技術研究所という会社で医療向けDXサービスを開発・運営しています。
今回は、PHPを利用した大規模クラウドサービス運営に関する工夫やノウハウを凝縮して発表したいと考えております。

＜コンテンツ＞
・アーキテクチャ
　→フレームワークの構成
　→インフラアーキテクチャ
　→セキュリティ対策
・キャパシティ管理
　→WEBサーバとメモリの関係、メモリの節約テクニック
　→転送量の対策（WEBブラウザ上のメモリや処理効率対策）
・エラー検知
　→プロセス実行時間や例外の監視と通知
・マインドセット
　→「トラブル時の解決速度」にフォーカス
　→ソースコードはラブレター

皆さん、「読みたいな」と思える本に出会えていますか？
私は「趣味は何ですか？」「はい、積ん読を増やすことです」と胸を張って答えられるくらい、ここ数年は家に本が増えています。

読書をしてインプットをする、知識を増やすというのは非常に大事なことです。
それと同じくらい、「自分を高めてくれそうな知識との出会い方」も大事なのではないでしょうか？

題して、「積ん読を増やす技術」です。
このLTでは、実際に体験したことをお伝えしながら
「どうやって本を買っているか、見つけるのか」「積ん読を増やすことで広がる世界」について、紐解いていきます。

話すこと

• 面白そうな本と出会うコツ
• 「家に本が沢山ある」という状況とどう向き合うか・活かせるか

話さないこと

• コスパ、タイパ
• 収納術

新しくツールやルールを整備する際に、導入したツールが全然使われてなかったり、ルールが浸透していないといったことがありませんか？
私たちのチームでは、新しくツールやルールを整備する際に、アンバサダーを任命して導入を主導して貰ってます。

本トークでは、アンバサダーとしてどのような活動をしてツールやルールの導入を進めているかを紹介します！

ディップでは、生成系 AI を全社的に活用しています。
開発チームでは開発の生産性向上のため、GitHub Copilotを導入し活用を進めています。

本トークでは、このような AI ツールの活用による開発生産性向上の効果を測定するための指標をどのように検討し、どのように計測しているかについて紹介します。
これから開発現場にAIツールを導入予定の方、またAIによる生産性向上の効果を測りたい方々におすすめのトークです！

私たちのチームでは、サービスのメトリクス監視やパフォーマンス可視化に New Relic を活用しています。
また、開発プロセスの改善や活動量からエンジニアを評価出来る環境作りのために、開発チームのパフォーマンスをNew Relicで可視化、活用しています。
最近では、AIを用いたツールやサービスを使用することで、チームの生産性がどう向上したかを測る指標も追加しました。

本トークでは、サービスのパフォーマンス可視化だけではなく、開発チームのパフォーマンス可視化も行えるNew Relicについて、弊社の活用事例を紹介します。
サービスや開発組織のパフォーマンスの可視化に興味のある方におすすめのトークです！

組織に属している人だったら大抵「3年後のキャリアビジョンと目標書いて提出して」と言われたこと、あるのではないでしょうか？
キャリアビジョンって言われても…って人多いと思います。
私は3年前の「3年後のキャリアビジョン」に「マネージャーになる」と書き、今期からマネージャーに就任しました。
がむしゃらに頑張った、のもありますがキャリアの描き方と目標の立て方が良かったのだと思っています。
本LTではキャリアビジョンと良い目標の立て方についてお話できればと思います。

Web開発をしているとChrome Devtoolsは欠かせないツールかと思います。
ただ多機能過ぎて何が何だが分からないという方、多いのではないでしょうか？
本LTではChrome Devtoolsについて私が知っている小技を可能な限り紹介しようと思います。
雰囲気で使っている方、是非本LTを聞いて明日からの開発にお役立てください！

複数のプロダクトやサービス事業を展開している企業で一度は言われる「共通基盤を作りたい」。
近年、エンジニア側も「よし、共通基盤だ！マイクロサービスを作ろう」と安易に呼応してしまうことがでてきました。このように始まったマイクロサービス開発では、往々にして失敗したマイクロサービスが負債として残り、エンジニアチームは「マイクロサービスはダメだ」という感想を持ってしまいがちです。

「共通基盤だ！」と言い出したとき、本当にマイクロサービスが必要だったのでしょうか？
前職で数年にわたってマイクロサービスを開発・運用し、PHPerKaigiでマイクロサービスを布教したこともある私ですが、現職では「共通基盤だ！」にNOを突きつけています。
共通基盤というマイクロサービスがほしくなる動機を解きほぐし、マイクロサービス採否ジャッジの基準、ニーズをマイクロサービス以外の方法で満たす方法についてもお話しします。

私見ですが、年金は破綻はしないけど、ここに老後を頼れないですよね。一方健康寿命はこれからの20年で10年延びる予想があります。
そして投資で増やしたり、貯金をためても、よほどの金額がないと、くつぶしていく可能性があります。
やはり必要なのは中高年になっても副業や起業で稼げる方法ではないかと思うのです。

もちろんエンジニアの方で技術力があれば食べていけると思うのですが、今と同じ見積方法で工数を見積もったり、時間給で金額をいただくのは、契約が途切れるきっかけが多く、常に営業行為が必要になることが多いです。安定した収入を得るためには、極論、営業をしないで稼げる方法が好ましいと考えています。（ネットワークビジネスの話じゃないですよ！）

そこでこのセッションではエンジニア向けに安定した副業や起業で収入を得られる考え方と私自身が成功した実例を解説したいと考えています。

Laravel に親しんで早ウン年…次のプロジェクトは CakePHP !?

• CakePHPの経験……ありません。
• ユニットテスト……ありません。
• E2Eテスト……ありません。

そんな状況から、どうにかE2Eテストを書くところまで至った課程と、
その間に直面した問題・解決策についてお話します。

会社でマネジメントをやっていまして、エンジニア組織におけるメンバーの目標制度などにも手を出しております
その中で、「ストレッチ目標を立てる」「自分が成長したい姿を意識する」というのを推奨しました。
参考: 過去に書いた記事

これは、組織全体のレベルアップを推し進めたいからであり、その重要なエッセンスである「個人」の成長も仕掛けたいと願ったからです。

実際にやってみて、どうだったでしょうか？
マネージャーでありメンターを担う自分の目線からの手応えや反省・課題と、
実際に目標を設定し取り組んだメンバーの結果(成果、評価)や本人インタビューを織り交ぜて、考察します。

良い点・上手く行かなかった点・難しかった点・合う合わないの話・もっと効果的にするには？のポイント、といったトピックで
実体験をベースに「見えてきたこと」をシェアします

PHP-FIGの定めるオートローディングに関する規約として、「PSR-0: Autoloading Standard」があります
これは、後から出てきた「PSR-4: Autoloader」に役目を譲るようにして、非推奨となりました

一体、なぜ求められ・何を解決し・何が「合わなく」なったのでしょうか？
PHPの言語機能と、PHP利用者のエコシステムの変遷の歴史が、ここにも詰まっています

PSRで扱われるオートローディングの話と、PHPにおけるパッケージ管理について話します

話すこと

• PSR-0の概要
  • PSR-4との比較
• PSR-0登場前夜
  • (set_include_path と require に頼らない)ファイル読み込みの奥義
• その後のPHPのパッケージ管理
  • どうしてPSR-4が出てきたのか、そして役割を交代したのか─

Tests as Documentation！皆さん、テスト書いてますか！書くより読む時間の方が長いですよね、きっと！

どうしたら、読みやすいテストコードになるか…？は、他人の時間を尊重する上で大事なことです
どうしたら、テストコードを思いつきやすくなるか…？は、自分の時間を尊重する上で大事なことです
両者を勝ち得るために、「ユニットテストのコードを書くための引き出し」を増やしておきましょう！

xUnit Test Patternsで紹介されているパターンの中から「理解容易性」「自己文書化」に関連が深いものを取り上げたり
自身の経験を踏まえたりしながら
テストコードを書く際の観点・tipsを紹介するトークです

しない話

• テストの保守性の上げ方
• テストしやすいコードの書き方

こんな人向け

• ユニットテストを書くようにはなったが、まだ難しく感じる場面が多い人

世の中にはエンジニアコミュニティに参加せず黙々とお仕事をしているエンジニアもいます。PHPカンファレンスの常連になっている皆さんは「もったいないな」と思っていることでしょう。
マネージャーをしていたときに私は2人の新人エンジニアをコミュニティに送り出す作戦を立てて実行し、今年になって成果が出たことを観測しています。
エンジニアがコミュニティに参加することにどんな意味があるかを改めて言語化したうえで、ベテラン側が具体的に何をすると彼や彼女をコミュニティに溶け込ませることができるかについてお話しします。