トーク

社内向け管理機能はサービスのオペレーションを支える重要な機能です。一方で顧客向けサービスと比べ実装にかける労力は抑えられがちで、手軽な管理画面ライブラリが採択されることも多いと思います。

私の現場でも最初はその構成をとっていました。しかしテンプレートエンジンで提供できるユーザー体験に限界を感じ、RefineというFWを用いて別途SPAにリプレイスを採択。これにより2週間でAdminをリプレイスできた点は成功ですが、一方でFWの内部実装を参照しないといけないケースがあるなど、最良の選択肢かは検討の余地があります。

この発表ではリプレイスで得られた知見を元に管理機能フロントエンドに必要な要素を整理し、実装の選択肢とそのトレードオフをお話しします。「フルスクラッチは大変」という粗いADRを書いた私のような経験の浅いエンジニアの方に向けて、技術選定の視点を提供できれば幸いです。

現在、製造現場DXプラットフォーム、「Smart Craft」の開発を進めており、4人のエンジニアがフロントエンドからバックエンドまでを担当しています。
限られた人数で最大限の成果を出すために、私たちはGraphQLを用いたコードファーストアプローチに基づく開発を選択しました。
本セッションでは、2年間でやってきたことを通して、GraphQLを選択した理由やコードファーストアプローチに基づく開発で得た知見とメリット・デメリットについてお話し、GraphQLの活用を検討する方々への助けになれればと考えております。
主に話すこと

• 開発体制とGraphQLの選択理由
• Ruby/Ruby on RailsでのGraphQLのスキーマとドキュメントの自動生成
• Reactでの開発とTypeScript型定義の自動生成
• モノレポによるスキーマの共有
• 得られた知見とメリット・デメリット

ウェブ開発においてJS/TSを利用することが多い中でWasmを組み込もうとするとJS/TS以外の言語(RustやC++など)を利用するのが最初の選択肢になるのではないでしょうか?

JS/TS以外の言語がWasmへのコンパイルをサポートすることでウェブへ進出できるようになるのは喜ばしいものの，JS/TSを中心としたウェブ開発の中で他の言語を導入するコストをどう見るのか?

本セッションではJS/TSと比較した時のWasmのメリットデメリットを踏まえつつ，ウェブ開発の中でWasmを導入する時の最初の選択肢として「AssemblyScript（AS)」を紹介します．
ASはnpmで管理されているためにウェブ開発において手軽に導入でき，かつ書き慣れているTSをWasmにコンパイルできる技術です．
ASを用いたWasmの導入方法や現状できることを中心に話したいと思います．

デザインシステムの普及により、多くのフロントエンド開発者がコンポーネントライブラリを独自で実装するようになりました。
こうした独自でのコンポーネント実装において、様々なデバイスで機能するアクセシブルなUIコンポーネント実装を行うのは難易度が高く、実装コストが高くなります。

本発表では、そうした共通コンポーネントの実装において役立つヘッドレスコンポーネントライブラリであるArk UIとスタイリングライブラリであるPanda CSSを紹介します。
更にこれらのライブラリを用いて実装を行うことでデザインシステムのコンポーネント実装を加速させた事例についても紹介します。

株式会社 enechain では、デザインシステムを運用しています。

元々は社内プロダクトが新たに立ち上げられることが多かったフェーズにおいて、開発効率を良くするために、共通コンポーネントを使い回すためのパッケージとしての運用から開始しました。

そこから、デザイナーのジョインやチーム体制の変更により、正式にデザインシステムとして立ち上げることとなりました。

今や、「日本のエネルギーを担う」というとても大きな目標に向かってプロダクトを作っている我々ですが、その内製されている各プロダクト、ほぼ全てにおいて使用されているデザインシステムを、どのように運用を初め、どのように草の根活動を進めていき、どうやって社内で自分事にされるようになっていったかを、エンジニアの立場として、プロダクトオーナーとしての自分が、立ち上げ期から順を追って赤裸々にお話します。

HonoXはHonoベースで作られたフレームワークです。そしてHonoには、react-rendererというサードパーティーのmiddlewareがあります。
このHonoXとreact-rendererを組み合わせることで、HonoXでReactを使用することが可能になり、Reactベースのuiライブラリを使用しつつ開発を行うことが可能になります。

本セッションの詳細は以下の通りです。

• Hono/HonoXの説明
• HonoXとreact-rendererの組み合わせによる利点
• HonoXとさまざまなuiライブラリを組み合わせる

皆さんは、ユーザーの手元で起きたバグをなかなか再現できずエスパーで直した経験はないでしょうか。あるいは、ユーザーの動きを想像しながら機能の導線改善をした経験はないでしょうか。
そんな仕事を楽にするツールとしてSentryやDatadog、Fullstoryなどが、ユーザーの画面をそのまま見れるセッションリプレイ機能を提供しています。

さて、これはどのように実現されているのでしょうか。Webアプリの画面をmp4動画として録画することはもちろんできません。代わりにMutationObserverをはじめとしたWeb標準技術を駆使して擬似的な録画を実現しています。

本セッションでは、自作のセッションリプレイツールを3年間運用している経験を元に、それを支えるWeb技術と具体的な実装を解説します。実運用するためのプライバシー対応やサーバー側実装についても紹介します。

複数言語をサポートするwebアプリケーション開発において文言の国際化は常に付きまとう問題です。特に日付や数値の表記、文法規則などを考慮した国際化はその処理や管理で悩むことが多いと思います。

webフロントエンドにおいては、このような機能をJSの国際化APIであるIntlが担うようになってきています。一方、日付や数値など個別の国際化機能が充実していく中で、文言全体のフォーマットをどう定義しどう書式化するかと言う課題に対しては未だ答えが出ていません。

このような課題に対し、仕様レベルで文言のフォーマットやパース・書式化をサポートする「Intl.MessageFormat」という野心的な提案が現在Unicodeを巻き込んで協議されています。本セッションではこの提案について、その背景や概要、現在までの流れ、提案されているフォーマットを紹介し、標準化された後の文言国際化を考えたいと思います。

プロダクトにおいて、モバイルアプリとWebアプリのどちらも開発が必要な場合、どのような技術選定を行うかは非常に悩ましいところかと思います。

最近では、Expo Routerが、Next.jsのようなファイルシステムベースのルーティングを実現できるようになるなど、React Native・Expoを利用したモバイルアプリとWebアプリの同時開発が、有力な選択肢として頭角を表しているのではないでしょうか？

このトークでは、React Native・Expoで開発されたモバイルアプリのWeb版を、ReactやNext.jsを用いてイチから作るのではなく、"React Native for Web"や”Expo Router”によるモバイルアプリのコード資産を活用しながら開発することで感じた良かったポイントや苦しかったポイント等を共有できればと思います。

Webフロントエンドの自動テストをチームで無理なく継続するためには「軽やかなテスト」を書くことのできる開発環境と設計が極めて重要です。

本トークでは、開発から8年が経過したプロダクト開発チームでWebフロントエンドの自動テスト文化を醸成した経験をもとに、軽やかなテストを構築するための実践例とそれによって得られる開発体験について紹介します。

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

• 結合テストを支えるコンポーネント設計：Container/PresentationパターンとResult型を駆使することでテストのしやすいコンポーネントを構築する
• 単体テストとの付き合い方：ネットワークの入出力に着目した単体テストでカバレッジを広げる
• 開発体験：Storybook駆動で小さく精度の高いPull Requestを実現する
• +α：E2Eテスト・画像回帰テストとの付き合い方

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

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

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

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

コードベースに秩序をもたらすため各種 Linter を利用している方も多いのではないでしょうか？一般的なルールについては Linter 内蔵のものや既存の Plugin ですでにカバーできるでしょうが, 一方で事業ドメイン特化であったり UX/DX を向上させるための技術ドメイン特化なルールまではサポートし切れないケースの方が多いでしょう.

日経電子版においてもコードベースにそうした事業ドメイン, 技術ドメイン特化な制約が存在しています. こうした日経電子版特化な制約について日経電子版開発では属人的なレビューで弾くといったアプローチでなく, できるものは ESLint Plugin を開発してそれにより機械的に弾くアプローチをとっています.

本セッションでは事業, 技術ドメイン特化な ESLint Plugin を開発する利点や How To を具体例とともにご紹介します.

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

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

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

昨今、街歩きがブームとなり、歴史的な地図への関心が高まっています。
「れきちず」は昔の歴史地図を現代風のデザインにアレンジし、誰もが使いやすく読みやすい地図へと進化させました。
「れきちず」は見た目だけでなく技術面、フレームワーク・地図タイル・3D地形・データ変換のパイプライン…などなどがフロントエンド技術を中心としたユニークな技術スタックで構築されています。
このセッションでは「れきちず」のオモテ側のデザインを紹介しつつ、ウラ側の技術についても深堀します。

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

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

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

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

本発表ではレガシーなフロントエンド開発の経験しかないチームが、デザインシステムとコンポーネント指向を導入し、従来の開発プロセスをどのように革新したかを、実例を交えて紹介します

このチームはレガシーなコードの肥大化と複雑化に伴い、メンテナンス性と拡張性の問題に直面していました
新たなサービス開発を機にアトミックデザインをベースにしたデザインシステムの導入と、SPAフレームワークを用いたコンポーネント指向開発に挑戦しました

コンポーネント指向はUI の再利用性と組み合わせ性が向上させ、サービスを高品質に、なおかつ柔軟性をもたらしました
さらにデザインシステムの導入はチーム内のコミュニケーションと協業にも好影響を与えました
共通言語はデザイナーと開発者の連携がスムーズに変化させました

本発表を通して、コンポーネント指向に立ち向かう具体的なイメージを持っていただけると幸いです

大規模な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の特徴や利点について詳しく説明し、実際にどのように活用するかを示します。