トーク

コシがあるプログラマになるぞ！！と想像してみると、研鑽やインプットが欠かせない気がしますよね。
インプットとして分かりやすい手段に、技術書やビジネス書といった実用書の読書があります。

「本を読みたいと思うものの、なかなか進まない」「これまでの人生で読書の習慣があまり無くて、苦手」なんて人もいるでしょう。
人間が処理できる情報量には限りがありますし、活字や座学に対する向き不向きといった特性は人それぞれに差があります。
とはいっても、手段の1つとして「本を読めるようにする」が使えたら、成長機会が広がる事は間違いありません。

昨年のPHPカンファレンス香川で「読書」に関連したLTをした際に、
ちらっと触れた「本の読み方」「一字一句読むことに拘らない、寧ろ読み流し方を覚える」という点に、
共感や驚きといった反応をいただきました。
そこで、このトークでは、
「本の読み進め方のスタイル」「読み流すとは・どうやるのか」について
簡単な演習のようなものを含みつつ、紹介します。

話すこと

• 本の読み方について考える: いくつかの読書のスタイルについて
• 精読・乱読・積読
• 本の出会い方・選び方

持ち帰れるもの

PHPカンファレンス香川2026が5月前半。
そこから、今年が終わるまでに6ヵ月半。
もし「1日に3冊」や「1週間で10冊」を読めるようになれば、
「今年あと50冊」は全く不可能ではないですよね。
(50っていうと、なんか凄くないですか？)

全くもって「たくさん読めばエラい」なんてことはありませんが、
「もしアナタがそれを望むなら、それができるようになる」というトークを目指します

プログラミングや設計には「抽象化が大事だな」と言ったり、言われたりする事が多くあります。
今でこそ私も「なるほど」と思えるようになったものの、プログラミングを始めての何年間かは「何が・なぜ、抽象？」とピンと来なくて聞き流して過ごしていました。

このトークは、そんな 「まだ自分の感覚として理解できていない」人を中心的なターゲット として、 「どうして良いのか」を整理 して提供することを目的としたものです。
「抽象」といってもInterfaceやAbstract Classに限らず、メソッドをどう定義するか・変数名はどうするか、といった考え方の土台となる視点を提供します。

主なキーワード

• 抽象: 情報を削ぎ落としたり切り出したりして、簡単にしたもの
• 具体: 抽象に対して、現実との繋ぎ込みのための内容や形を備えたもの
• 構造: 目的に対して機能と形式を備えたもの
• 名前: 「それは何なのか」を(抽象的に)したもの

なぜ、それらのキーワードが大事なのか

このトークでは、「抽象」と向き合うことが「理解を助ける、思考(努力)を楽にする」 ために大事である、という態度を中心に据えます。

自分的にHTTPSの中で一番のコシであるTLSをPHPで実装してみた話をします。

TLSは、HTTPSなどで普段使用する際に暗号化を担っている技術ですが、私自身、「HTTPSの裏側でいい感じに暗号化してくれるやつ！」くらいの漠然とした理解しか持っていませんでした。

そこで、TLSを理解するために、TLS 1.3プロトコルをPHPで実装することに挑戦しました。

このトークでは、TLSの基本的な仕組みについて説明し、どのようにTLSを実装したか、そのプロセスと得られた知見についてお話しします。

話すこと

• TLSの仕組み
• PHPでの実装アプローチ
• 実装を通じて得た知見

「AIに任せると人間が育たない」
その不安は、AIを単なる「手抜き道具」として使うからです。

AI生成コードは一見動きますが、
長年の運用で培われた設計思想やドメイン知識といった「コシ（芯）」が欠落しがちです。
それは将来の変更に耐えられない「伸びきったうどん」のようなものです。

この「コシ」を注入するには深い理解が必要ですが、
歴史あるサービスの重厚なコードを前に、新参者が即実践するのは困難です。
そこで私は、AIを「書く道具」ではなく「読むための専属メンター」として使い倒し、
この壁を突破しました。

本セッションでは、2011年のリリースから15年以上続くサービス（Chatwork）の、
10年選手である独自フレームワークや巨大なレガシーPHPと向き合う現場で私が実践している、
「AIに読ませて、人間が育つ」ための具体的な技術論をお話しします。

【主なトピック】

「読解」の高速化:
複雑怪奇なレガシーコードをClaude Codeに解説させ、ロジックの要点（出汁）を瞬時に掴む「AIリーディング」。

「作法」のコンテキスト化:
チーム独自の規約やレビュー指摘を CLAUDE.md に蓄積し、AIに「チームの流儀」を継続的に学習させる。
その設定ファイル自体が「生きた新人教育マニュアル」となり、人間も自然とルールを内面化するサイクル。

説明責任の徹底:
「AIが書きました」は禁句。人間が完全に腹落ちし、自分の言葉で説明できるまでPRを出さない「鉄の掟」とその効能。

AIは人間をダメにする甘やかし装置ではありません。
正しい使い方をすれば、経験の浅いエンジニアに「熟練の視座」を授ける、最高の教育エンジンになります。
AIという強力な「こね機」を使いこなし、私たち自身が最高の職人になるための生存戦略を共有します。

JetBrainsのMPSは、外部DSL(ドメイン固有言語)を作成するためのIDEです。
DSLの文法自体を定義し、それをターゲット言語に変換するための仕組みを用意できます。
つまり、「独自の使いやすい文法で書いてもらって、PHPのコードに変換する」ことが可能です。

DSLの利用は、あなたのチームの開発の効率を高めるかも知れません。
余計なことが出来ない・無駄なことを考えなくて良いように、「必要なことにだけ集中する」ための強力なガードレールとして機能します。

必ずしも「独自の文法」を利用する必要はなく、JSONやYAMLを利用したり、あるいはPHPの文法の範疇で書かれた内容でも、多くの場合は事足りるでしょう。
とはいえ、「もっと良い方法」の引き出しがあるに越したことはありません。例えば、非開発者とのコラボレーションの手助けにもなりえます。
(・・・一度はやってみたくなりませんか？)

そして、MPSは普段使っているようなIDEとはかなり様子が違った、
悪く言えばクセが強い、よく言えばクセになるようなIDEです。
公式ドキュメントの表現を借りると、
「テキスト形式を避けることによって他の多くの言語ワークベンチとは一線を画しています。あなたのプログラムは常に AST で表されます。」
と記述されています。ちょっと面白そうだな、と感じませんか？
この独自の世界観を、ちょっと体験できるようなトークをします。

話すこと

「素朴なDSLの作成」を題材としてウォークスルー的に追体験しつつ、MPSとその基本的な概念について紹介します。
今後ふとした時にちょっと便利な武器になるかもしれない、そんな知識を持ち帰ってください。

あなたも Laravel 用のパッケージ（composerライブラリ）を作って公開しませんか？

実際に作成したパッケージを例に、アセットの公開、config や migration の活用、オーバーライド可能な view など、開発者にとって使いやすいライブラリを作るための勘所をご紹介します。