プロポーザル

エンジニアとして成長したい！でもなぜか成長が頭打ち…そんな焦り、ありませんか？
僕も未経験〜５年目の今まで、成長したい一心で “正しそうに見える地雷” を踏み続けてきました。
今回はそんな僕がやって来た「働き方アンチパターン」をご紹介します

アンチパターン５選+α
・「設計後回しで突っ込む」病
・エラー/Warning無視」病（敵を味方にしない…）
・「思い込みで進める」病（きっと〇〇のはず！）
・「迷走して自分でも説明できない」病（木を見て森を見ず！）
・「無茶して英雄になりたい」病（持続不能、SDGSな働き方大事！）
＋
「努力の空回り」病（やるべきことをやらず、やらなくていいことをやる）
などなど…

これらは若手のあるあるかと思います
頑張っている”のに、実は遠回りになる典型的なアンチパターンです。

本トークでは、なぜそれが起きるのかと、明日から置き換えられる具体アクションを、実体験、先輩からの助言を踏まえ、現場あるあるで共有します。

成長は“努力量”より“努力の設計”で決まる。
皆さんも明日から、まずは「努力の設計」始めてみませんか？

楽観的UIは現在多くのアプリケーションで使われており, なおかつReact 19でuseOptimisticが導入されたことでフロントエンドエンジニアにとっても身近な存在となりました. ユーザーを待たせないUIはプロダクトにとって重要なUX上の利点となりえます. しかしそんな楽観的UIも使い方を間違えばフロントエンドとバックエンドの整合性に混乱を引き起こします. この発表では楽観的UIをきっかけにシステム全体のモデル設計について考えます.

この発表ではまず楽観的UIについて整理し, ユーザーを待たせないUIがもたらす利点や使ってはいけないポイントについて触れます. またReact 19で導入されたuseOptimisticを例に具体的な楽観的UIの導入方法についても紹介します.

実装を通じて楽観的UIはUI単体のテクニックではなくシステム全体のモデル設計にかかわることが見えてきます. このような楽観的UIがもたらすメンタルモデル: 投機的・冪等性・イベントに目を向けてフロントエンドからバックエンドまで一貫したモデリングを考えるためのきっかけを提供します.

「ゴール設定は大事」と分かっていても、実際の現場ではやっている割に効果を感じない、
結局タスク消化に戻ってしまう、そんなモヤモヤを抱えていないでしょうか。

本セッションは、ゴール設定にはスキルが必要であり、チームとして練度を上げていくことが重要だという前提に立ち、チーム全員が集中できるゴールを作るための考え方とコツを紹介します。

良いゴールが設定できるようになると、日々の会話が変わります。タスクを終わらせるかではなく、「ゴールに対して今どんな状態か」「次に何を打つべきか」という対話が中心になります。
その結果、

集中度が上がり、優先度の入れ替えや中止を冷静に判断できる
エンジニア自身が次の一手を提案しやすくなる

といった変化が生まれます。セッションでは、以下のポイントを実践的に扱います。

・チーム全員でゴールを作る理由
・自分たちも含めたステークホルダーのゴールを毎回イメージ
・SMART・ALIVE・FOCUSを使ったゴール設定の視点
・完璧なゴール（青い鳥）を追わず、手元から始める考え方

ゴール設定を「イベント」ではなく、チームで磨き続けるスキルとして捉え直したい方に向けたセッションです。

概要

TiDB は「NewSQL」と呼ばれる分散データベースで、
MySQL 互換のプロトコルを持ちながら水平スケールできるなんだかすごいやつです。

さてMySQL互換というからには、さぞ移行もしやすいことでしょう！
MySQLを利用している既存のLaravelのアプリケーションをローカル環境でTiDBに切り替えてみて、果たしてどこまで動くのか？
実際に切り替えてみてからの躓きからTiDBとMySQLの違いを掘り下げ、TiDB導入を検討する際の判断材料を持ち帰ってください！

ターゲット

• TiDB に興味はあるけど触ったことがない方
• RDBMS以外のDBも学んでみたい方
• MySQLの内部挙動に興味がある方
• DBが好きな方

お話すること

• TiDBの簡単な概要、特徴
• TiDBのローカル環境の構築方法
• Laravel アプリケーションを接続してみて実際に詰まったポイント
• MySQLとの挙動の違いとその理由

リアルタイム通信といえばWebSocketが採用されることが多いです。しかし反面、運用の複雑さや、HTTP/2環境では扱いが単純でない点など、実運用では多くの考慮事項が伴います。
対して一方、Server-Sent Events（SSE）という仕組みも存在します。SSEは仕組みがシンプルで、通知系などのユースケースでは有力な選択肢になります。
本セッションでは、SSEとWebSocketを、プロトコルの挙動・インフラ構成・バックエンド／フロントエンドの実装・運用負荷といった観点で比較・検証します。
どちらが優れているかではなく、バックエンドとフロントエンドの連携を軸に、要件から逆算して、より最適な技術を選ぶための判断基準を紹介します。

各技術のトレードオフを整理し、単なる実装に留まらない、現場で役立つアーキテクチャ設計の指針を提示できれば幸いです。

ユーザー体験を向上させるうえで、Webサイトの表示速度改善は重要です。そのためには、バックエンド・フロントエンド双方での最適化が不可欠です。
ただし、処理を改善してもネットワークやサーバー応答待ちがボトルネックになることがあり、とくにサーバーがHTMLを生成している間は、ブラウザ側で描画や重要リソースの取得が進みにくい「待ち時間」が発生しがちです。
こうした待ち時間を活用して重要リソースの取得を前倒しする仕組みが、HTTPステータスコード「103 Early Hints」です。

本セッションでは、サーバーがHTMLを生成している間にCSSやJavaScriptなどの重要リソースを先行してブラウザに通知する「103 Early Hints」の仕組みを解説します。
PHPでのヘッダー送信から、受け取ったブラウザがそれをどのように扱うのかまで技術的に深掘りします。
さらに、実プロジェクトにおけるLCP（Largest Contentful Paint）の変化など、実測データに基づく検証結果も共有します。
サーバーサイドとフロントエンドが連携して実現する、一歩進んだ高速化手法を共に考えましょう。

「技術はあくまで手段であり、目的ではない」本当にそうでしょうか？

振り返れば、通信速度の飛躍が人々のコミュニケーションの形を変え、AIという技術の登場が人間の思考のプロセスそのものを塗り替えています。これらは「手段」が「目的」を追い越したのではなく、「新たな技術の出現が、世界の前提を書き換えた」のです。

技術のポテンシャルを誰より、深く理解しているのは私たちエンジニアです。 ならば、「ビジネスの課題を解決するために技術を選ぶ」という受動的な姿勢はもう捨て、能動的なビジョンを提示し、責任を持ってそれを具現化していくべきです。

本セッションでは、フロントエンドやPHPというWebの最前線に立つ私たちが、技術的確信から逆算して「新しい当たり前」を創り出すために
・　 「技術が世界を定義する」というパラダイムシフト： 技術を手段に留めず、世界のあり方を規定する「前提条件」として捉え直す。
・　「見えている者」の責任： 技術の進歩がもたらす未来を予見し、それを事業やプロダクトにねじ込んでいくための覚悟。
・　技術の進化： 変化の渦中で「好きな技術」を使い続けることは、エゴではなく、未来を証明するための闘いである。

SPA フレームワークのひとつ、Blazor WebAssembly は、React、Angular、Vue、Svelte 等と同類の「コンポーネント指向」フレームワークです。その最大の特徴は「C# で実装する」という点です。これは C# を JavaScript にトランスパイルするのではなく、ビルドして生成された .NET のアセンブリ (.dll) を WebAssembly によるインタープリタで実行するという大胆な仕組みで実現されています。Blazor は認知度こそ低いですが、WebAssembly を利用して JavaScript 以外の言語で SPA 開発を行う成功例のひとつと言えます。このトークを通じて JavaScript 一辺倒の SPA 開発に一石を投じ、様々な言語の開発者の声を拾うきっかけになればと思います。
また、「ブラウザで C#/.NET が動く」という点だけでなく、SPA フレームワークとしての Blazor の特徴や設計思想についても、他ライブラリと比較しながら取り上げていきます。
普段とは異なる技術スタックに触れることで、技術者としての視野を広げる機会になれば幸いです。

SPA フレームワークのひとつ、Blazor WebAssembly は、React や Angular、Vue、Svelte などといったライブラリ/フレームワークと同じく、UI コンポーネントを組み上げてクライアント Web アプリケーションを構築する「コンポーネント指向」のフレームワークです。しかし最大の違いは「C# で実装する」という点です。しかも C# のソースを JavaScript にトランスパイルするのではなく、C#/.NET のアセンブリバイナリをそのまま WebAssembly によるインタープリタで実行してしまうという大胆なアーキテクチャです。さらに加えて、ただ実行できるだけでなく、ブラウザの開発者ツールウィンドウでのデバッグが可能です。つまり、開発者ツールでのブレークポイントの設定とステップ実行、変数ウォッチなどが C# ソースを対象に行えるのです。

ということでこの LT では、開発者ツールに JavaScript 以外の言語が表示される、そんな不思議な光景をライブデモでお見せします。

1ページ構成のWebサイトにおいて、タイポグラフィの質とパフォーマンスを両立させるための取り組みをご紹介します。

• フォントの選択
  • システムフォントでは代替できないNoto Sans JP Weight 100のデザイン性を重視
• パフォーマンスの制約
  • 日本語WebフォントのサイズによるLighthouseスコアの低下を回避したい
• 既存ツールの限界
  • 一般的なサブセット化ではカーニング情報が消失し、品質が維持できない

これらの課題を解決するため、ビルドプロセスを組み込みました。

• 静的解析
  • Astroのビルド済みHTMLをパースし、Weightごとに使用文字を1文字単位で抽出
• クエリ最適化
  • 抽出結果から、必要な文字のみを配信するためのクエリを自動生成
• 自動化パイプライン
  • Cloudflare Pagesを活用し、デプロイのみで最適化まで完結する全自動フローを構築

妥協のないタイポグラフィを、静的解析による抽出からCloudflare Pagesでの自動化へと繋げ、いかに全自動で最適化しきるか。そのアーキテクチャの全容をお話しします。

その角丸、本当に納得していますか？
Apple製品のアイコンやハードウェアの曲線がどこか「気持ちよく」感じる理由。それは単純な円弧（border-radius）ではなく、直線から曲線へと曲率が滑らかに変化する形状が使われているからです。こうした形状は一般にSquircleなどと呼ばれ視覚的な自然さを生み出しています

これまでWebでこのような角丸を再現するには、SVGマスクやclip-pathなどを用いた実装が必要でメンテナンス性に課題がありました
しかし現在CSS Backgrounds and Borders Module Level 4において、corner-shapeプロパティが提案されておりCSSネイティブで表現できる未来が見え始めています。

本LTでは以下の内容についてお話しします。

• なぜ border-radius の角丸は硬く見え、Squircleは「気持ちよく」感じられるのか
• 提案されているCSS仕様corner-shapについて

たかが角丸、されど角丸。
フロントエンドエンジニアのこだわりを、CSS がどこまで表現できるようになるのか。その一端を一緒に覗いてみませんか？

TypeScriptのファーストのスキーマ検証ライブラリであるZod。
「TypeScript バリデーション」で検索すると必ずと言っていいほど候補に上がってくるライブラリであることから、
入力フォームのライブラリで採用している方も多いかと思います。

それに加え、入力フォームの検証以外にもJSON.parseしたオブジェクトなどに利用することも有効です。
ですがTypeScriptのJSON.parseはある問題を抱えています。

本セッションははその問題を起点に複雑なネストを抱えたオブジェクトに対して、
どういうアプローチで型安全な実装をしていくかをお話していければと思います。

目次

1. Zodについて
2. JSON.parseの問題点
3. 複雑なネストを抱えたオブジェクトに対して、ユーザー定義の型や型ガードで対応するのじゃだめなの？
4. Zodの使用例

Obsidianとは、マークダウン形式のテキストデータをローカルで管理できるノートアプリケーションです。
デフォルトの設定で使っても十分に便利ですが、各種プラグインを導入して色々とカスタマイズすることも可能です。

そして実はなんと、Obsidianのプラグインは、フロントエンドの技術（TypeScriptなど）だけで簡単に開発できるようになっています。素晴らしいですね！

本セッションでは、Obsidianのプラグイン開発の基礎と、作成したプラグインの公開方法についてお話します。
また、サンプルとして私が丹精込めて作った謎プラグインをお出しします。

こんな人におすすめ

• Obsidianが好き
• Obsidianのプラグインを作ってみたい
• 謎機能が追加されてしまったObsidianを見たい

「クラスは一つの責務だけを持つべき」

SRPはこの一言で語られがちですが、この単純化された表現だけで理解しようとした場合、多くのケースでは原典の定義・観点とずれていきます。
「責務」とは何か？一つだけの「責務」を持つとは、どのような状態を指すのか？
その意味は、しばしば原典の定義や観点を省略して、日常語の範疇で理解されてしまい、結果として混乱を生み出していることがあります。

しかもSRPは、提唱者Robert C. Martin自身が2003年→2014年→2017年にかけて焦点を動かしています。
そのため、一通りの定義だけを知っていても、議論が噛み合わない危険があります。

本セッションでは、SRPの定義が「変更の理由」から「人々」、さらに「アクター」へ移る過程を原典（書籍・著者ブログ）から辿り、
なぜ日本語圏で「責任」が日常語化して混乱が起きるのかを解体します。

最後に、技術的関心と組織的関心を見分け、どの観点で分離を判断すべきかを実務の判断基準として提示します。

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

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

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

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

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

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

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

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

歴史のあるコード、いわゆるレガシーコードは直そうとすると壊れがちです。
また、IDEでは未使用に見えるのに、実はAPIやバッチで呼ばれていたコードを変更して障害になる事故も少なくありません。
最終的に、一度事故が発生した箇所に誰も触れなくなるという光景を目にしたことはないでしょうか？

このトークでは、リファクタリングやバージョンアップのような変更を安全に進めるため、変更に入る前に呼び出し元や依存関係の洗い出しについてお話します。そのなかで、コーディング支援ツールを調査役として使うコツも取り上げます。

ターゲット:

• 実務でレガシーコードの変更に不安がある人
• 影響範囲の調査にコーディング支援ツールを活かしたい人

皆さんは日常でどのようなコミュニケーションツールを使っていますか?
Slack, Microsoft Teams, Chatwork, Google Meet, Zoom, LINE etc... 挙げていけばキリが無いと思います。

コミュニケーションツールでよく利用するのが絵文字。皆さんも一度は「🙇‍♂️」や「:yoroshiku_onegaishimasu:」を使ったことがあるのではないでしょうか。
ところで、「👍」と「👎」ってこのようなツールだとよく並んでいますよね。誤って「👎」を押さないように、必死に「👍」の左端を狙っている日々を送っている方もいるんじゃないかと思います。

そこで、本セッションでは、何故上記のような押しミスが発生しやすいUIが作られがちなのかという疑問を解説します。
また、絵文字ピックのUIを提供する上でどのようにすると、ユーザーを幸せにできるのか勘所をお伝えします。

このセッションは、フロントエンドエンジニアや絵文字に興味がある方、絵文字の処理に苦しんだことのあるサーバーサイドエンジニアを対象としています。

フロントエンド技術が多様化する中、管理画面においても将来の拡張を見越してReactなどのSPA構成を選択するケースが増えています。
SPA構成では、フォーム項目やバリデーションといったUI構造をAPIとして表現する必要があり、そのたびにフロントエンドとバックエンドの調整が発生します。結果、小さな変更であっても、実装や保守のコストが膨らみがちです。
一方HTML+JSで構築するとUIの状態やロジックが分散し、仕様変更が続くにつれて全体を把握しづらくなります。
管理画面はビジネス側の要望を素早く反映することが求められ、変更のしやすさは重要な設計要件と言えるでしょう。

本セッションでは、Server-Driven UI(SDUI)という考え方に着目し、Laravel用のUIフレームワークであるLivewireを題材に、UI構造と振る舞いをサーバー側で一元管理することで、変更に強く開発速度を維持できる設計について解説します。
逆にSDUIが苦手でSPAが適している面なども合わせて説明します。
本セッションを通してSDUIの利点を知っていただけると幸いです。

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

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

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

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

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