トーク

私が携わったホスティングサービスでは、ユーザーがコントロールパネルからワンクリックで WordPress をインストールできる機能を提供しています。特定の契約者には、購入された WordPress テーマも同時にインストールできる機能も提供しています。

この機能の実現にあたって、テーマファイルを契約者のみにアクセス制御して配布することが重要な課題でした。この LT では、WordPress 簡単インストール機能の仕組みに触れた後、テーマを適切にアクセス制御して配布するための具体的な方法について、WordPress の制約を踏まえた解決策をお伝えします。

また、パブリッククラウドのオブジェクトストレージに保存されたテーマの転送コスト削減のために採用したキャッシュ戦略についても共有します。アクセス制御を維持しつつ、効率的な配布システムを構築するための工夫をお話しします。

皆さんは、PHPStanを使って開発していますか？
PHPStanは静的解析ツールであり、PHPの開発をサポートしてくれます。
例えば、未定義の変数のチェック、PHPDocの間違いの確認、型の確認などの機能があります。
これは、動的型付け言語であるPHPで開発していく中で、必ず役に立つ機能です。

さて、私が開発しているプロダクトは、20年前から存在します。
古いコードには型宣言がなかったり、クラスを利用しておらず、グローバル領域で書かれたコードも多くあります。
そんなプロダクトに静的解析を導入するまでの苦難の道程と、入れたらどのような警告が出たのかをLTでお話しします！

PHPStan苦手ですか？私は苦手でした。
苦手を克服するにはひたすら倒していくのが遠いようで近道です。
よく遭遇するパターンを5分で紹介できるだけ紹介していければと思います。

得られること

• PHPStanの苦手意識が少しでも和らぎます

DDD（ドメイン駆動設計）に興味があるけど、どの本から読めばいいか迷ったことはありませんか？数多くのDDD関連書籍をすべて読むのは大変ですが、安心してください！とりあえず、手に入る本は全部読んで見ました！本トークでは、どんな人がどのDDD関連本を読めばいいのか、独断と偏見で発表します！

dbt-coverageというツールをご存知ですか？

dbt-coverageとは、dbtのテストやドキュメントのカバレッジを計測するツールです。dbtはデータワークフローをSQLとYAMLで定義するソフトウェアで、dbt-coverageとはDBのテーブルに対するテストケースや、YAMLファイルにdescriptionの項目が書いてあるかを計測します。

一見するとよくあるツールに見えるのですが、コードの量が非常に少ない。実のところ、ソースコードが1000行ぐらいしかありません。この量では、とてもYAMLをASTに直し、構文解析することは不可能なように感じました。

本セッションでは、このdbt-coverageのソースコードを解説し、どのようにして短いコードで有用なカバレッジ計測ツールを実現していのかを解説します。

不確定な部分のコードを何度も修正する際、どこを変更すれば良いか迷ったり、実際に読んでみないと見積もりができない経験はありませんか？

そこで効果的なのがリファクタリングです。
私は以前、「とりあえず動く」コードを重視していましたが、設計感覚やドメイン知識が身についてくることにより、読みやすく変更に強いコードを書くことが楽しく感じるようになりました。変わらない部分と変わる部分を分離し、リファクタリングすることで、自分にも他者にも与えるポジティブな影響と、リファクタリングを楽しむためのポイントを話します。

話すこと

• リファクタリングが自分や他者に与える影響
• リファクタリングの手順やアプローチの具体例
• 意味のあるテストコードの重要性

皆さん社内で技術交流していますか？
私はしたいですが、できてません!!

現在は様々な会社でテックブログや勉強会、イベントの主催などで社内・社外でのエンジニア同士の技術交流が活発です。
ただし、全員が全員、活発な会社にいるとは限りません。

社内の技術交流を活発化できないかと、細々半年、本格的に活動を始めて半年が経過し、
どういう施策がダメ・よかったか、ダメだった施策の原因と対策など皆さんに共有できればと思います。

プログラマーとして生きていると、仕事をする中であるいは日々の生活の中で、ちょっとした自動化のためにスクリプトを書くことがあるでしょう。
そういったスクリプトはすぐに使い捨てるつもりだったり、あとで修正することもなかったりするかもしれません。

このとき、みなさんは「最低限の品質」をどこに置きますか？
いざ、ぱっと聞かれると返答に困るような質問かもしれません。

私のなかではある程度の基準があります。
本トークでは「ちょっとした自動化のためにパッと書いたスクリプト」をいくつかのレベルに分けて、どこまで作り込むかの観点と判断基準の一例をお見せします。

「生産性改善のために、コードレビューを最優先にやる」という言説を耳にしたことがあるでしょうか。

コードレビューをしている間は当然、自分が持っているタスクの進行が止まってしまいます。
それでもコードレビューを優先した方がいいと言われるのはなぜでしょう？

その問いに対し、本トークでは「我々の仕事とは／仕事を終わらせるとは何なのか？」という観点から答えていきます。

ちなみに「すべての職場や環境においてコードレビューを最優先にすべき」という主張ではありません。
これについても「我々の仕事とは／仕事を終わらせるとは何なのか？」という観点で説明します。

「パフォーマンスチューニングは複雑で手間がかかる」と思っていませんか？
実は、コードの大改修をせずとも、仕様変更と軽微な修正だけでも大幅な改善が可能です！

本LTでは、13時間かかっていたバッチ処理を、たった一部の仕様変更で5時間に短縮した実例を紹介します。パフォーマンスチューニングは難しくない！

対象者

• 10時間以上のバッチ処理を保守している人
• パフォーマンスチューニングに苦手意識を持っている人

MVCモデルのフレームワークにおいて、編集ファイルが多くなり、レビューが大変になったこと、ありませんか？
どうしても編集ファイルが多くなると、変更の意図が伝わりにくく、見落としも増えがちですすよね。
スケルトンコードを活用して学びを最大化しつつ、効率的なコードレビューを実現した方法を紹介します。

お話しすること：

1. MVCモデルでの変更の複雑さと課題
2. スケルトンコードについて
3. 実際の使用結果と得られた学び

何が得られるか：

• スケルトンコード活用法
• チーム全体の開発プロセス改善のヒント

こんな人におすすめ

• 若手エンジニア
• 育成に関わる人
• コードレビューの効率化に興味がある人

似たような経験をしたことのある方にとって、少しでも参考になれば嬉しいです！

MVCモデルのフレームワークにおいて、編集ファイルが多くなり、レビューが大変になったこと、ありませんか？
どうしても編集ファイルが多くなると、変更の意図が伝わりにくく、見落としも増えがちですすよね。
スケルトンコードを活用して学びを最大化しつつ、効率的なコードレビューを実現した方法を紹介します。

お話しすること：

1. MVCモデルでの変更の複雑さと課題
2. スケルトンコードについて
3. 実際の使用結果と得られた学び

何が得られるか：

• スケルトンコード活用法
• チーム全体の開発プロセス改善のヒント

こんな人におすすめ

• 若手エンジニア
• 育成に関わる人
• コードレビューの効率化に興味がある人

似たような経験をしたことのある方にとって、少しでも参考になれば嬉しいです！

PHPerの皆さんは自分が開発しているプロダクトへの愛を持っていますでしょうか？
エンジニアからプロダクトへの愛には「受託開発だから特に愛してない」から「自ら企画した自社サービスだから我が子のように愛してる」まで様々な濃度があると思います。
エンジニアが自らオーナーシップを持つために・エンジニアにオーナーシップを持ってもらうために、プロダクト愛の濃度別にできることを語りたいです。

弊社で開発しているサイボウズ Garoon は利用してくださるお客様のお陰で20年を超える長寿プロダクトとなりました。
当初はオンプレミス版での提供から始まりクラウド版を経て現在では多くのお客様で利用されています。
その中で私はお客様からの問い合わせに対応するバックサポートチームでエスカレーションエンジニアを行っています。
クラウドの障害対応はもちろんですが、Garoon はオンプレミス版も提供しているため多種多様なお問い合わせがあります。

このトークではエスカレーションエンジニアのご紹介と具体的な問い合わせや業務内容をお話します。

PHPは、エンジニア・案件ともに豊富となり、もはや習熟していれば使いどころに困らない昨今となりました。
一方で、copilotの台頭や経営層のIT解像度の深化等により、
エンジニアへ投資する目線もまたシビアになったと言えます。

そんな中で、より魅力的なプロダクト開発や優れたチームの構築へ、私たちを連れて行ってくれるものは何でしょうか？
競合に劣らぬ価値を発揮し、プロジェクトを牽引するには、何が必要とされるでしょうか。

本LTでは、業界、業種、業態(営業→開発、医療→エンタメ等)を問わず経験した話者の観点から、
「必要だったビジネススキル」「掛け算の重要性」を主題としてご紹介します。
技術に伸び悩んだ時どうすべきか。ビジネススキルとは何か。
具体・抽象を交え時間いっぱい詰め込みます。

本LTで新たな気づき・学びをご提供し、ご清聴賜りました皆様のエンジニアライフの一助となれれば幸いです。

令和の今日。性別関係なく、メイクを楽しめる世界になりました。
その中でも、爪を塗る（ネイルする）ことは開発生産性を上げる効果があると、私は考えています。

この5分で、ネイルによって得られるメリットをご説明します。

LaravelプロジェクトにおけるL5-Swaggerの活用方法と、それによるAPI開発プロセスの効率化について深堀りします。
L5-SwaggerはLaravelでSwagger（OpenAPI）ドキュメントを自動生成するツールであり、APIの設計、開発、テスト、そしてドキュメンテーションのプロセスを大幅に改善します。

ぺちこん参加回数2桁になっている私が、「ぺちこんは楽しいから、もっといろんな方に知って欲しい！参加して欲しい！」そんな思いで声をかけ、毎年初参加者を誘うことに成功しています。
ぺちこん自体を知らない方、名前は知っているけれど踏み出せない方、いろいろいらっしゃる中で、私が日頃から行っている声かけやお誘いポイントをお伝えします。

システム運用時にslack通知設定をしているシステムは多々あると思います。
私が関わっているシステムでも、日々様々な通知をslackに出しています。
しかし、slack通知が多すぎて本当に必要なものが埋もれてしまったり、@channelだらけでミュートしたくてもできないチャンネルになったりしていませんか？実は通知が届いていたのに誰も対応できなかった、なんて経験はありませんか？
そんな運用の苦労を少しでも減らす方法を、実際に運用してみて直面したケースを例にお話ししたいと思います。

■話す事
・slack通知NGパターン
・slack通知を誰が見るか
・slack以外の手段
■話さない事
・slack通知の設定方法

「PHPStanを入れましょう」「静的検査、型の世界をやっていき」といった時に、
必ずしも「レベルをどうするか」「baselineがどのくらいあるか」だけに限らずとも良い訳です。

自分たちのチームやプロジェクトにとって弱みになっている部分、基準としていきたい部分について
ピンポイントでルールを入れていく道があります。
そのために、「使えるルール」が増えると良いですよね。そのまま「静的検査の語彙」になります。

さぁ！！phpstan-strict-rules が来てくれました！！！
必ずしも「全部を有効にする」っていう使い方ではないでしょう、そういうものは本体に居るはず！！

5分で全部のルールを紹介します。
紹介には、「どんなコードを指摘してくれるルールなのか？」が含まれます。