トーク

アプリケーションを開発し、長期にわたって運用するには、収益化が欠かせません。
ソフトウェアをサービスとして提供するSaaSモデルでは、月額や年額での定期的な請求（サブスクリプション）システムの組み込みが重要な要件となります。
しかしシステムの運用と同様に、サブスクリプションでは様々な運用課題がリリース後に発生します。
このセッションでは、サブスクリプションをアプリケーションに導入する際にのポイントについて紹介します。

紹介するポイントの例
・リリース後に発生する「運用課題」の例
・プランの種類と途中での契約変更
・使ってもらうための無料オファーの種類と使い分け
・プランとアクセス権の設計と割り当て

現在TechTrainというサービスを開発していますが、4人いる社員のうち全員が今までバックエンドをメインとして開発してきたエンジニアとなっています。そんなエンジニアたちがNext.jsとLaravelで開発しようとするとどうなるか？そうです。Next.jsの細かなことは調べながら開発することになります。そんな中でも生産性を出すためにこんなこと意識してるよという話をさせていただきます。

このトークで話すこと

• バックエンド中心の組織でフロントエンドのアーキテクチャ
• フロントエンドの実装とデザインの連携
• ちょっと失敗したなーと思っていること

2019年からエンジニアの教育サービスのTechTrainというサービスを作ってきました。
足掛け5年サービスを継続している中で、サービスのデザインリプレイスと技術的なリプレイス(Nuxt.js->Next.js)を何回か行っています。
そんな中、何が辛かったのか？失敗したことは何かなどをお話しします。
このトークでは、次の点をメインお話しします。

• リプレイスではどの単位で進めるのが良いのか？
• デザインリプレイスと技術のリプレイスを一緒に取り扱うのか？
• どうやってリプレイスを短期決戦にしていくのか？
• リプレイスとサービス特性をどう取り扱うのか？
• 技術的に辛くなりやすいところは何か？

機械的に手を動かして書き換えるだけのリファクタリング作業は、なるべく避けたいものです。
ひとつふたつ書き換えるだけであれば問題ありませんが、それが幾多にも及ぶと手に負えません。

codemod はそういった作業を代行してくれる強力なツールです。
一方で、このツールの実装には抽象構文木(以下、AST) の知識が必要なことから、敷居が高いという印象を持たれてしまいがちです。

このセッションでは jscodeshift という Meta 製のライブラリを用いた codemod の開発方法をご紹介します。
開発を通して、jscodeshift がベースとしている Recast という ASTパーサーへの理解を深めつつ、JavaScript と TypeScript の ASTをマスターし、面倒なリファクタリングを苦もなくこなす便利な codemod を作れるようになりましょう！

Next.js App Routerの安定版がリリースされてから1年以上が経過しました。Next.js Pages Routerのままでよいのか、App Routerに移行するか、あるいは他のフレームワークへ移行するか、皆さんも悩まれていることでしょう。

本講では、開発開始から2年半、運用開始から2年の実稼働アプリケーションである、10万行超のNext.jsプロジェクトを事例としてご紹介します。強く結合したPages Routerを、1年の構想と約1ヶ月の作業期間でApp Routerに移行した手順や、移行によるメリット、デメリットをお話しします。

さらに、App Router化と同時に行った大規模なバックエンドのインフラ変更の実態も併せて、現場の臨場感あふれるWebアプリケーション開発の波乱万丈をお見せします。

近年、フロントエンド開発の複雑性は増し続けており、サイトのホスティングだけでなく、データベースや認証機能など、バックエンド領域に関わる機能も必要不可欠となっています。
しかし、従来のAWS Amplifyでは、フロントエンドのコードとバックエンドに関する設定が分離されており、特にバックエンド開発に慣れていないフロントエンドエンジニアにとっては、習得にハードルがありました。

そこで今回ご紹介するのが、AWS Amplify Gen2です。Gen2では、待望のTypeScriptサポートが正式導入され、フロントエンドだけでなく、バックエンドの設定や開発も含め、全てをTypeScriptで統一して開発することが可能になりました。

本セッションでは、実際のコードやデモも交え、TypeScriptでパワーアップしたAWS Amplify Gen2の魅力を余すことなくお伝えします。

このセッションでは、OpenAPIを用いてフロントエンド開発におけるバックエンド依存の最小化する開発手法を紹介します。

OpenAPIはREST APIを記述する標準的なフォーマットであり、yamlまたはjsonファイルを用いてAPI仕様を定義します。

OpenAPIに基づき、バックエンドの実装を待たずにモックサーバを立ち上げます。これにより、フロントエンドの開発者は実際のバックエンド完成前にAPIにアクセスし、開発を進めることが可能です。バックエンドの実装とフロントエンドの開発を分離し明確にAPIを定義することで、迅速かつAPIの齟齬なく開発を進めることができます。

本セッションでは、上記で述べたOpenAPIをフロントエンド開発に利用する方法の詳細を紹介します。また、OpenAPIを効率的に共有し運用していく方法についても紹介します。

TinaCMSというヘッドレスCMSの概要やその特徴、利点についての話をします。
TinaCMSはGitベースのヘッドレスCMSで、Gitのバージョン管理がそのままコンテンツ管理に活かせたり、実際の画面をプレビューしながら、リアルタイムでコンテンツが編集できたりと、面白い特徴があります。

最近私の関わる周りではヘッドレスCMSを導入するプロジェクトも増えてきており、日本ではもっぱらmicroCMSの話をよく聞きます。この流れにのって、他の面白い特徴を持つヘッドレスCMSについても紹介できればと思います。

昨今において、フロント・バックエンドに限らずテストコードは必須のものとなりつつあります。
しかし、このように思ったことがある方は多いのではないのでしょうか？

『プロダクションコードの品質はテストコードが高めてくれるけど、テストコードの品質はどうやって高めればいいの？』

この疑問を解決し、定量的にテストコード品質を測定するための手法がMutation Testです。

このセッションではJestに対して、Mutation TestライブラリであるStrykerを用いて計測を行い、どのようにテストコードの品質を高めていったか？を実際の導入事例を踏まえながらお話ししたいと思います。

【概要】
このセッションでは、ブラウザ拡張機能の開発フレームワーク「Plasmo」と、Cloudflareを活用してChrome拡張機能を作成する手法をご紹介します。
ブラウザ拡張はフロントエンド開発の重要な一部ですが、まだあまり知見が共有されていないと感じます。
今回は、初めての方でも理解できる基本的な使い方を中心に、PlasmoフレームワークとCloudflare Workersの使い方を解説します。

【セッション内容】

• Chrome拡張の基礎知識
• Plasmoフレームワークの基本操作
• Cloudflare Workersの基本的な使い方
• サンプルアプリケーションのデモを通じたポイントの説明

優れた生成AI・LLMアプリケーションを開発するには、生成AI・LLMアプリケーションならではのUI/UXが求められることを実感します。

変動的なインターフェースはその一例です。ライティングツールJasperのDynamic TemplateやCognosysのRefine prompt機能では、
ユーザーの入力に応じてより精度の高い出力を得るための動的なフォームを生成し、入力を求める体験が実装されており、ユーザーの意図に対して柔軟なUI/UXが提供されています。
この仕組みは、ユーザーの意図に柔軟なUI/UXというだけではなく、生成AI・LLMプロダクトとして出力のレベルを保つ上でも重要な要素です。

本セッションでは、生成AI・LLMアプリケーションならではの課題や特徴を元に、生成AI・LLMならではUI/UXについてお話します。

Webフロントエンド開発のレビューやテストにおいてUIをコンポーネント単位で表示、実行できるStorybookは大変便利です。

この発表では、 エディタで開いたファイルからブラウザ上のStorybookを素早く開くことができるVS Code拡張機能「Storybook Opener」について、以下の内容などを紹介します

• 「Storybook Opener」を開発した経緯
• 初めてVS Code拡張機能を開発した中でどのように実現方法を探り知見を得たか
• 開発してどうだったか
  • レビューや実装など、作業が効率的になった
  • 900以上インストールされた
  • Storybookの内部がちょっとわかるようになり、アップデートを追えるようになったり Storybookや他OSSのコントリビュートにも繋がったりした

より多くの売り上げを上げるため、多くの企業はマーケティング施策やECサイトの滞在時間・回遊率などに予算とリソースを投入しています。
しかし顧客の購買行動をファネルで見た場合、最も重要なステップである「決済」への注目はあまり高くありません。
せっかく様々な取り組みによって、ユーザーが注文フォームまで到達しても、
システムのエラーやカード会社による意図しない支払い拒否などが発生すると、そこでユーザーは離脱してしまいます。

このセッションでは、Stripeが2022年に実施したオンライン決済フォームに関する調査レポート ( https://stripe.com/jp/newsroom/news/state-of-checkouts-2022 )などをもとに、
「決済フォーム・決済フローを改善することによる、コンバージョン率や売り上げを増やす方法」を紹介します。

「Webサイトを作りたいし、自分でも更新したい。では、CMSはどれをインストールしましょうか」というのは客先でありふれた光景です。納品物に、更新マニュアルも用意して、万全のサポート体勢！

けれど、一度、後ろを振り返ってみましょう。世間には、更新されなくなったWebサイトが溢れかえっています。場合によっては、CMSもインストールされたまま。PHPのバージョンが未だに5.6？！

私たちは、制作時にWebサイトの寿命を見誤っているのかもしれません。そう思い、2019年から、CMSのインストールをやめ、GitHubを中心にユーザの更新環境の工夫を行ってきました。本セッションでは、その工夫と、"ユーザの本当に欲しかったもの"について考えます。

[セッション内で触れる技術ワード]
GitHub/Angular/SSG/型安全性/継続的デプロイメント/Ionic/Capacitor

様々な側面で課題のあるフロントエンドプロジェクトを引き継ぎました。
どのような過程・方針でそのコードベースを改善していったかを以下のトピックで共有します。

• 技術 (ライブラリ、アーキテクチャ) 選定
• TypeScript の型エラー、 Lint エラー修正
• チームメンバー間のナレッジ共有
• これらの改善をどのように行うかのチームマインド醸成
• 現時点で気づいたプロジェクト初期に必要なチェック項目

以下がプロジェクトの概略になります。

• 2年ほど継続中プロジェクト (現在も継続中
• 現時点におけるプロジェクトのファイル数: 500ほど
• Vue.js, Vue Router, Vite を用いた Single Page Application

※ 本アプリケーションが実現している具体的なビジネスモデルやバックエンドの構成などは伏せさせていただこうと思います。