ユーザーと編集者の満足度を両立する？ プレイド片居木氏が挑んだノーコードエディタ開発

【B-5】ユーザー体験と編集体験を支えるビルドアーキテクチャ

　プレイドではCX（顧客体験）プラットフォーム「KARTE」を提供している。サイト訪問者に働きかけるためのポップアップやシステム連携などの仕組み（ここでは「アクション」と呼ぶ）を、HTMLだけではなくJavaScriptでも開発できる。また、プレイドではこうしたアクションをノーコードで編集するエディタも開発している。本セッションではウェブ接客リニューアルプロジェクトのリードを担当する片居木誠氏が、サイト訪問者のユーザー体験とアクションを開発するノーコードエディタの編集体験の両方を支えるビルドアーキテクチャを解説した。

KARTEを支える2つのビルドプロセス

　KARTEは、サイトやアプリの訪問者の行動や感情をリアルタイムに解析し、一人ひとりに合わせたアクションを表示、CX向上を目指すプラットフォーム。

株式会社プレイド アクションエディタ開発チームリード 片居木 誠氏

　KARTEの基本的な仕組みとしては、Webサイトにタグ（スクリプト）を貼っておくと、サイト訪問者の閲覧をきっかけにスクリプトが実行されて、どのページが参照されていたかなどの情報がKARTEの解析サーバーに送信される。過去の閲覧履歴なども合わせて解析することで、サイト訪問者に合わせたアクションが実行される。

配信アーキテクチャ

　このアクションのためのコードは「KARTEアクションエディタ」で編集される。エディタのGUIでアクションの見た目を編集して保存すると、変更されたソースコードがビルドサーバーに送信され、そこで実行コードに変換された後に、アクションストレージ（CDN）に保存される。ユーザー体験の最適化という視点では、ビルドした実行コードがエンドユーザー（サイト訪問者）のブラウザで素早く表示されることを優先している。

　またアクションエディタにはアクションの挙動のプレビュー機能もあるため、ビルドはエディタが動いているブラウザ内でも行われている。編集するたびにエディタでビルドしてプレビューを更新することになるため、ここでのビルド時間が長いと編集体験が悪くなる。そのため編集体験の最適化という視点では、ビルドにかかる時間を短縮することが重要になる。

　アクションエディタには、同じソースコードをもとにした実行用とプレビュー用で2つのビルドステップがあり、それぞれビルドの生成物が異なる。このビルドステップでは、「TypeScriptをトランスパイルしてJavaScriptにする」「インポートしているパッケージをnpmから取得する」「ファイルをまとめて1つの実行可能なファイルにする」「サイズを減らすためのminify処理」などの工程も含まれる。こうしたステップにおいて、アクションエディタではrollup.jsを使用している。

　ユーザー体験と編集体験の両立を図るなかで、ポイントとなるのがソースコードの作り方だ。エディタで編集するコードは配信ごとに変わるものだが、ポップアップ表示などで共通で利用できるコードも多くあり、そのようなコードはSDKとして分離してビルドすることで、最適化が可能となる。

　ビルドフロー全体をあらためてまとめると、コードの中から共通するものはSDKとして分離し、後続処理のために実行用とプレビュー用それぞれでビルドしてある。また、エディタで編集されるソースも実行用とプレビュー用でそれぞれビルドされる。先述の通り実行用は実行速度の最適化を重要視しており、プレビュー用はビルド時間の最適化を重要視している。

ビルドフロー全体