トーク

ヘッドレスCMS「Storyblok」を使用したプロジェクトにおいて、エンジニア、デザイナー、ライターという三つ巴の天敵となり得るメンバーたちがどのようにコミュニケーションの問題を解決してきたかを解説したいと思います。
Storyblokの特徴であるビジュアルエディターは、デザインの変更がリアルタイムで確認しながら編集が可能で、非技術者でも直感的に操作できます。また、ブロックライブラリにより、再利用可能なコンポーネントを簡単に管理し、プロジェクト全体で一貫性を保ちながら効率を向上させることができます。
これを導入することでフロントエンドとバックエンドを完全に分離し、メンバーが同時進行できる部分が多くなります。導入初期のトラブルを共有します。また機能をどのように活用すれば、チームのリソースを最大限に活用できるか、初心者がつまずき易いポイントも紹介します。

React Nativeは、JavaScript（TypeScript）でiOS・Android対応のクロスプラットフォームアプリを素早く開発できることで知られています。

その一方で、メンテナンス性が悪くなりやすいデメリットがあります。
特に、React Nativeのアップグレードには、iOS・Androidの設定ファイルやコードの変更、さらにはサードパーティのJSライブラリやネイティブモジュールの更新が必要なケースもあり、とても大変です。

しかし、Expoが提唱している、「Continuous Native Generation(CNG)」というコンセプトを取り入れることで、スケーラブルでメンテナンス性に優れたクロスプラットフォームアプリ開発が可能になります。
このトークではCNGの概要、CNGを取り入れたExpoアプリ開発のプロセス、導入事例ついてお話しできればと思います。

Web アプリケーションを開発する中で, 同一アプリケーション内の他ページや別アプリケーションへのリンクを纏めた Global Navigation をヘッダーやフッター部分などに横断的に配置したくなるケースがあるでしょう. 事業の成長に伴って Global Navigation の内容も進化していくものですが, 一方でアプリケーションのリポジトリやサービスが分散されているとその更新やデプロイコストが高くなってしまいます.

日経電子版においてその更新コストに Platform Engineering でどのようにして立ち向かってきたか, そしてチームを跨いで利用される Platform Service の管理やコミュニケーションをどのようにして行なってきたか, を紹介し Web Frontend における Platform Engineering を行なっていくための知見をご紹介します.

React コンポーネントライブラリ Mantine をプロダクトで使うにあたり、どんな課題に直面しどう解決を図ったかについてお話します。
例えば以下のような課題です。

• デザイン上のフォントサイズ粒度と Mantine で設定可能な粒度が異なる
• 様々なスタイリング方法が提供されており、柔軟な反面、実装においては複数の方法が混在することを避けたい

Mantine との向き合い方の一例をお話し、UI コンポーネントライブラリを利用した開発の参考になれば幸いです。

関連する複数のアプリやパッケージをまとめて管理するため、ポリレポではなくモノレポにすることがあると思います。
この LT では、初めてモノレポを構築した自分の経験談を話します。
例えば、

• モノレポ構成を取るにあたり、どういった観点で何を検討したか
• 検討事項に対して、どういった決定をしたか
• モノレポを構築するにあたりどんなことをしたか

などについて話し、モノレポ構築において参考になる情報を少しでも提供できれば幸いです。

Remix を使ったアプリケーションにおけるコンポーネントの単体テストでは、 @remix-run/testing パッケージで提供されているスタブを利用すると思います。
しかしこのスタブは useRouteLoaderData を利用しているコンポーネントではうまく動きません。
このように、 Remix 公式から提供されているスタブではカバーできることとできないことがあり、公式ドキュメントには特に記載がありません。
この LT では、

• RemixStub がカバーしていることとしていないこと
• useRouteLoaderData hook を使っているコンポーネントの単体テストをどうやるか
• remix-typedjson を使っている場合に発生する別の課題とその解決方法

などについて話し、Remix を使った開発を行っている方々の助けとなる情報を届けられれば幸いに思います。

チームで開発をしていると、こういうコンポーネントが存在してるかを確認するためにStorybookを見る、どういうAPIが生えているのか確認するためにSwaggerを見るということを頻繁に行うと思います。
その際にいちいちnpm run storybookなど別プロセスで実行して確認するのも実際少し手間ではありますし、devブランチに入っている最新版のAPIを確認しようにもgit pullしないとかぁ…という状況もしばしば。
むしろgit pullのせいでコンフリクトが発生してstorybookが気づかずにエラーで止まっちゃってたということも…
エンジニア以外にも簡単にコンポーネント一覧見てもらうには…などなど。

そこでVercelを活用することによってチームに所属している人間のみが簡単にブラウザ上で見れるような環境を用意できる、そういう方法を発表したいと思います。

shadcn/uiはRadix UIをベースとしたUIコンポーネントライブラリです。コピペして使えることで有名ですが、実際にコンポーネントの中身を見ていくとコンポーネントを設計する上での気付きや発見があります。

そんな気付きや発見を紹介するLTです。

発表内容

• cvaを使った関心の分離
• プリミティブではないコンポーネントがどういう設計になっているかみる（Formコンポーネント）
• コンポーネントがどう振る舞っているか

ChatGPTの発表以来、生成AIを活用したサービスが数多く登場しています。これらのサービスにおいて、生成AIとユーザーをつなぐ重要な役割を担っているのはフロントエンドを担当する私たちです。
私の取り組んだ「わたしの現代新書」も生成AIを取り入れたプロジェクトです。このサービスでは、ユーザーが入力した書籍のタイトルをもとにAIがキャッチコピーを生成し、vercel/ogを使って書影画像をつくります。
この企画を作るにあたって、生成AIを利用する際にユーザーが待ち時間を感じないようにするデザインの工夫と、素早く高品質な画像を生成するエンジニアリングの工夫を行っています。その結果、多くのXユーザーに利用されるものになりました。
本セッションでは、デザインとエンジニアリングをどのように組み合わせたか、具体的な取り組み内容について詳しくお話しします。

この発表では、サイボウズが提供する製品「サイボウズ Office」における、フロントエンド (Next.js App Router) の監視基盤について紹介します。

React Server Components や Server Actions のようなサーバーの存在が前提となっている機能の登場によって、フロントエンドにおいてもサーバーを運用する必要性が高まってきました。このセッションをきっかけとして、フロントエンドの監視に関する知見が広がることを目指します。

詳細は以下の内容を予定しています:

• フロントエンドサーバーにおけるオブザーバビリティデータの収集方法
• Next.js での OpenTelemetry 対応の詳細とユーザー側ですべきこと
• Grafana Faro を利用した Real User Monitoring の実践

大規模なBtoBサービスにおける段階的なシステムリプレイスを実施しています。JSPで構築されているシステムのフロントエンド部分をNext.js（Pages Router）とGraphQL（Relay）にリプレイスしています。
フロントエンドチームのリーダーとして関わり、開発を開始してから約2年が経過し、初期リリースからは約1年が経過しました。
これまでの経験から、リプレイスを進める中で良かったこと、大変だったこと、技術選定の振り返り、今後気をつけたいことなど、これからフロントエンドリプレイスを検討している方々に様々な知見を共有したいと考えています。

本セッションでは、スキーマ駆動開発に焦点を当て、その中でもConnectを利用した開発について話します。

このセッションでは、まず、スキーマ駆動開発でのIDLであるOpenAPI、Protocol Buffers、GraphQLの中で、Protocol Buffersが記述のシンプルさと柔軟性において優れている点をお伝えします。
次に、Connect-Webを活用したスキーマ駆動開発の方法について解説します。Connectは2022年に公開された、 gRPCやgRPC と互換を持ったHTTP APIを作成するためのライブラリです。 Protocol Buffersを活用したAPIの定義から、クライアント側のコード生成をシームレスにサポートします。Connect-Webの特徴や利点について詳しく説明し、実際にどのように活用するかを示します。

クリーンアーキテクチャのWebフロントエンドへの適用は、クラスとの相性やフレームワークが前提とする処理の流れと違うといった課題があり、そのままの適用が難しいことはこの数年で徐々に認識されてきたことと思います。しかし、クリーンアーキテクチャを1つのアーキテクチャとして捉えるのではなく、いくつかの設計のパターンとして捉えることでフロントエンドにも活用できる学びがあると考えています。

本セッションでは、Vue.jsでクリーンアーキテクチャの導入を試し、その後のReactへの移行に際して、良い設計を部分的に適用する中で得られた知見について紹介します。

• なぜフロントエンドにクリーンアーキテクチャは不向きか？
• types, reducers, utils を使ったエンティティの表現
• 外部インターフェイスを抽象化していたことで、Vue.js→React移行がスムーズに

ウェブフロントエンドでサイズの大きいPDFを表示しようとしてパフォーマンスやユーザビリティに悩んだことはないでしょうか？
本セッションではサイズの大きいPDFを可能な限り高速にブラウザ上で表示するための工夫と、フロントエンドでcanvasにPDFをレンダリングする方法と比べたときの実際のパフォーマンス差についてお話させていただきます。
ちなみに今回ご紹介するPDFの高速表示方法は特許を取得済みです！
https://prtimes.jp/main/html/rd/p/000000038.000063428.html

プロダクトと組織の成長に伴って複雑化していくコードベースやお客様からのご要望に「Feature Flag」という武器で立ち向かいます。
UIだけでなくバックエンドAPIとのつなぎ込みやTesting（VRTやE2E）とのインテグレーションなど、Feature Flagの活用方法は多岐にわたります。
この一年間Feature Flagと向き合い続け、酸いも甘いも（？）理解した僕が、Feature Flagを使った開発が変化に柔軟で価値検証速度を高めることができる理由とFeature Flagを使う際の注意点をお話させていただきます。

Next.jsのApp Routerでは、React Server Components（以下RSC)を活用した実装になっています。
RSCのServer Componentsは、名前の通りサーバー側でレンダリングされるコンポーネントです。
ここで既存のSSRも似たことをする技術ですが、RSCとの関係性・違いはどのようなものでしょうか？
本トークでは、SSR・RSCの生成物を確認しながら機能・仕組みの違いを調査します。

仕組みの違い：https://qiita.com/karintou8710/items/28dee39c5cb82bd1775d

Vue2の時代には、Reactと並んで、大人気なフロントエンドフレームワークであったいわゆるVue系。Nuxt3はリリースが遅れてしまったことに加え、大規模かつ多数の仕様変更があったこと、そしてインフルエンサー層がこぞってNextに鞍替えしてしまったことなどから、そのユーザー数は大きく減ってしまった。特に、難度が上がった仕様変更の一つとして、Fetcherの使用方法が挙げられる。

Nuxt2まではaxiosを用い、ラッパーとしてasyncDataを用いれば概ねヨシ！といった形であったが、Nuxt3からはuseFetch. useAsyncData + $fetch, useLazyFetch, useLazyAsyncDataなどを使い分ける必要性が出てきた。フレームワークへの依存性を減らしつつ、利便性があり、SSRでも活用できる、そんな理想のFetcherを求める戦いが今ここに始まる。

一時はバズワードにもなったメタバース。バーチャル世界で活用される主たる技術はUnity, Unreal、Vket Cloud、OSSのGodotなどに代表されるゲーム開発エンジンであったり、複数エンドポイント間の高速通信を可能とするRTC(Real Time Communication)技術であり、それらを支えるバックエンドやインフラである。しかしながら、フロントエンド技術が不要であるという話ではない。メタバースまでの導線として、PRの一環として、あるいはWeb VRの世界であれば、ゲームエンジンとWeb APIとのインターフェースとして、フロントエンド技術は多分に活用されているのだ。

本トークでは、VR法人HIKKYにおける、フロントエンド技術の活用例やアーキテクチャ例を紹介するとともに、一般的なWebサービスとの差異、そしてバーチャル世界におけるフロントエンドのこれからを解説する。

Next.jsアプリケーションをひとつのモノリスアプリケーションとして立ち上げたところから、拡大に伴いコンパウンド戦略を実現するマルチアプリケーションとして分割するところまでの4年間の変遷と移行ステップを紹介します。

フェーズによって最適な構成が異なることがわかってきたので、創業期〜拡大期におけるチーム構成や人数感の変遷を共になぞりながらお話しします。

以前Zennに投稿した以下の記事のその後の話でもあります。

• SPA Componentの推しディレクトリ構成について語る: https://zenn.dev/knowledgework/articles/99f8047555f700
• フロントエンドアーキテクチャの話: Resource Setの紹介: https://zenn.dev/knowledgework/articles/91a3dd575f99a2

生成AI・LLMの登場において、多くの領域で変化を訪れようとしています。
開発者であればGithub Copilotを代表にコード自動生成・開発支援の進化を如実に実感していることでしょう。

そんな状況の中、私が個人的に注目しているのが「生成AI・LLMをUI/UXの改善に利用することはできないか？」ということです。
実際に生成UI(Generative UI)というAIシステムがユーザーのニーズやコンテキストに合わせて、動的にインターフェイスが生成される概念も提唱され始めています。

本セッションでは、生成AI・LLMによって生まれるかもしれない新たなUIの可能性やそれを実現するためのライブラリとしてVercel AI SDKをご紹介します。