プロポーザル

Reactは登場から10年以上経ち、コミュニティに広く受け入れられるとともに、React自体も進化を続けています。

私もReactに関する情報発信を多く行ってきました。
また、去年終わり頃からはAIの進化によるコーディングスピード向上に助けられ、Reactに関係する実験的で小さなライブラリをいくつかFUNSTACKシリーズとして開発してきました。

私は発信するときや何か作るときは新規性を重視しており、新しい知見や斬新なソリューションを重視します。
その私を2026年になってもまだ楽しませ続けてくれる、いまだ新規性の宝庫であるReact。これはとんでもないことです。

Reactに対するこの情熱を共有するべく、
FUNSTACKを中心に最近の活動とその成果についてお話しします。このトークを通じて、私がReactのどういうところに楽しみを見出して、どうやって新規性の種を見つけ、それを育てているのかをお伝えします。

フロントエンド開発では、コンポーネント分割やフレームワークの使い方が設計そのものとして語られがちです。
しかし、状態遷移や操作の連鎖を扱う現代のフロントエンドは、すでに一つの「アプリケーション」です。

本セッションでは、Vue / React / Svelte で同一のアプリケーションコアを共有する TODO アプリの実装と、
過去に作成したサンプルが 5年後に view 側ライブラリを刷新してもコア部分には一切手を付けずに済んだ という経験を手がかりに、
フロントエンド設計における境界の引き方を考察します。

このように UI の外側に知識と振る舞いを固定する設計は、流行やツール変更に耐えるだけでなく、
型と振る舞いが明示された構造として AI を用いた開発とも相性が良い という側面を持つ、というお話も含みます。

テクニックではなく、「何を UI とみなし、何をアプリケーションの知識として扱うのか」という設計上の態度を共有します。

近年、カンファレンスや書籍を通じて多様なソフトウェア設計手法が広まり、選択肢は増え続けています。
しかしリソースは有限であり、すべてを完璧に実装することは困難です。
力を注ぐべき箇所を見極めることも重要になってきています。

事業の競争優位を支える核心領域を見極めそこに積極的に投資する。
判断を誤ると逆に設計に振り回され事業価値に結びつかないコストばかりが増える危険もあります。

さらに最近では、コードの「捨てやすさ」も注目されています。
「作る」ことの判断だけでなく、「捨てる」ことの判断も重要となってきました。

本セッションでは、KentBeckの“Optionality”などの考え方に触れつつ、設計投資にメリハリをつけ設計・コーディングの「力の入れどころ」や「捨てやすさのデザイン」をどう考えるかお話します。
また、私自身の過去の失敗例も交え、理論と実践の両面から学びをお届けできればと思います。

事業価値を見据え、何に投資しどう捨てるべきか。
判断のヒントとなれば幸いです。
※本セッションはPHPカンファレンス香川2025の講演内容をベースに設計判断部分によりフォーカスしてブラッシュアップしたものです。

𠮷 ← これは何文字でしょう？
当然、1文字と答えますよね？

では、JavaScriptで'𠮷'.lengthで測りましょうとすると罠に落ちます。
2が返ってくるためです。このときの正しい測り方は何でしょう？

PHPならこんなことにはならないぞ、だってmb_strlenは正しく1を返すぞと反論するとします。
では、 🇯🇵 をmb_strlenで測ってみてください。2と返ってきますよね？
邉󠄀でもいいかもしれません。2と返ってきますね？

本トークでは文字とはなにか、フロントエンドとバックエンドで揃えるときどうするべきか、
そのときに必要になる書記素クラスターの存在を解説していこうとおもいます。

「なぜNginxなどのWebサーバーが必要になるのか」
PHPerが一度は疑問に思うことランキングの上位だと(勝手に)思っています。

このトークでは、NginxになりきってPHPと話してみることで、WebサーバーとPHPがそれぞれ何をやっているのか、を理解することを目指します。

話すこと

• FCGIでPHPと通信し結果を得る方向
• NginxなどのWebサーバーの役割
• 他の言語ではどのようにWebアプリケーションをホストしているのか

他の言語との違いを知ることで、よりPHPの理解を深めることができます。自信を持ってPHPの特徴を説明できるようになりましょう。

現代のソフトウェア開発者で「技術的負債」という言葉を知らない方はほとんどいないでしょう。一方で「技術的負債とは何か」を正しく理解し、自信を持って説明できる人はあまり多くありません。相手が非エンジニアであればなおさらです。

技術的負債についての理解が不十分なことから「技術的負債＝悪」というイメージを持ち、無謀なリファクタリングを行う例や、逆に放置しすぎてビジネス面でのリスクが顕在化してしまう例は今なお後を絶ちません。

PHPはその長い歴史から、フロントエンドは流行の移り変わりの速さから技術的負債とは切っても切れない関係にあります。本トークでは「技術的負債とは何か」を言語化した上で、バックエンド・フロントエンドの両方に深く関わってきた経験、さらにAIによって大きく変わりつつある現代の開発環境を踏まえつつ、双方に共通する技術的負債との向き合い方や付き合い方をお伝えします。

ifを減らしたい、複雑さを抑えたい、オープン・クローズドの原則に沿った変更に強いコードを書きたい。
しかし「どう設計すれば良いか分からない」と感じたことはないでしょうか。
本セッションはそんなエンジニアに向けた内容です。

分岐が多く保守が辛いコードの多くは、
複雑なロジックを「使う」側で分岐させていることが原因だと考えています。
この設計では機能追加や変更のたびにifが増え、
可読性が低く、テストが辛い、変更に弱いコードになってしまいます。

本セッションでは、
複雑なロジックを「使う」側で分岐するとなぜ辛くなるのか、
「どう使うか」ではなく「どう作るか」で分岐すると、設計がどう変わるのかを整理して解説します。

その上で、「作る」と「使う」を分けることで複雑さを適切な場所に閉じ込め、
オープン・クローズドの原則に沿った変更に強いコードにつながる理由を実践的な題材を通して説明します。

必ず盛り上げます！！！よろしくお願いします！！！