新たな顧客課題に挑む17年目の進化とモダナイゼーション / RAKUSTechCon2024_Haihaimail

by Rakus_Dev

Slide 1

Slide 1 text

新たな顧客課題に挑む 17年目の進化とモダナイゼーション大阪開発統括部ラクスクラウド開発部配配メール開発課　大塚正道大阪開発統括部ラクスクラウド開発部配配メール開発課　井上良太開発推進部フロントエンド開発1課　亀ノ上孝雄

Slide 2

Slide 2 text

登壇者紹介大阪開発統括部ラクスクラウド開発部配配メール開発課大塚正道 SIer等を経て2011年に株式会社ラクスへ入社。 BtoCサービスや北米向けサービスなどの新規事業の開発を経験した後、2015年から楽楽精算のスマホアプリなどを開発。2019年からは配配メールの開発チームのマネジメントに従事中。コロナ禍に始めたトレイルランニングが最近の趣味。 2 

Slide 3

Slide 3 text

新たな顧客課題に挑む17年目の進化とモダナイゼーション配配メールとは？ ● メール配信サービス ● 主にBtoB向け ● 累計1万社以上の顧客 ● 2007年サービス開始⇒17年目 ● 主な機能 ○ 簡単操作でメール作成 ○ 高到達率の配信技術とノウハウ提供 ○ 成果を可視化する効果測定 3 

Slide 4

Slide 4 text

新たな顧客課題に挑む 4 

Slide 5

Slide 5 text

新たな顧客課題に挑む顧客が成果を実感しづらい課題近年はMA（マーケティング・オートメーション）機能などを取り入れて、メール配信ツールからメールマーケティングサービスへ進化。顧客の成果に繋がるように、マーケティングのPDCAを回せる機能強化を行ってきた。しかし、PDCAを回して成果に繋げるのは顧客次第。成果を感じてもらえず、解約に至ることも… 5  P D C A リード育成① ・グループ化・ステップ設定リード育成② ・予約配信・メモリー配信追客・トリガーメール・フォローメール成果分析・効果測定・ホットリード検出・来訪検知

Slide 6

Slide 6 text

新たな顧客課題に挑む顧客の成果を支える価値提供を模索より直接的に顧客の成果を支える価値を提供するため、PDCAの入口と出口を強化。・リード獲得⇒育成するためのリードを生み出す・商談獲得⇒最終成果である受注に繋げる機会を生み出す 6  P D C A リード育成① ・グループ化・ステップ設定リード育成② ・予約配信・メモリー配信追客・トリガーメール・フォローメール成果分析・効果測定・ホットリード検出・来訪検知リード獲得・フォーム・ポップアップ商談獲得・フォーム

Slide 7

Slide 7 text

新たな顧客課題に挑む顧客課題の解決策 7  フォーム（問い合わせ）ポップアップ機能

Slide 8

Slide 8 text

新たな顧客課題に挑む既存のアーキテクチャを超える新たなテーマメール配信を軸として機能を提供してきたこれまでとは違った技術的アプローチが必要。 17年目の進化に向けた2つの技術的チャレンジ・レガシーシステムのモダナイズ・モダンなフロントエンド技術の導入 8 

Slide 9

Slide 9 text

レガシーシステムのモダナイズ 9 

Slide 10

Slide 10 text

登壇者紹介大阪開発統括部ラクスクラウド開発部配配メール開発課井上良太 2023年2月に株式会社ラクスに入社。前職はSIerで長年従事。配配チームのTECリードとして、システム設計から開発、技術推進を担当。現在は新機能に関するシステム設計・開発を中心に、機能実現の為、日々取り組む。 10 

Slide 11

Slide 11 text

従来のバックエンド技術サーバー構成配配メールのメール作成（主幹）サーバー ● Webサーバー、DB、アプリケーションが同居 ● DBはマルチテナント型 ● このサーバーが複数存在 ● メール作成サーバー同士の連携はなし 11 ユーザーZ ・・・ユーザーB ユーザーA

Slide 12

Slide 12 text

従来のバックエンド技術アプリケーション ● PHP 8.2 ● Ethnaベースの独自フレームワーク → MVC構成 ● Smarty ● データベースはPostgreSQL 15.6 12

Slide 13

Slide 13 text

フォーム機能を実現するための技術課題システム構成面での課題 ● 想定アクセスなどパフォーマンス要件が、メール作成サーバとは全く異なる ○ BtoCを想定したパフォーマンス要件がある ○ BtoB想定の既存のサーバーではパフォーマンス要件を満たせられない 13 アプリケーション面での課題 ● 一般ユーザーに向けたリッチなUIの実現が必要 ○ 現在はサーバーからHTMLを生成してレスポンスを返すオーソドックスな構成 ○ 既存の構成のままであればリッチなUIは実現しにくい

Slide 14

Slide 14 text

フォーム機能を実現するための技術課題既存のサーバー構成、アプリケーションのままでは機能実現は困難 14 ユーザーZ ・・・ユーザーB ユーザーA

Slide 15

Slide 15 text

フォーム機能の技術課題への対策アクション打ち出した方針 ● 一般ユーザー向けフォーム機能をサブシステム化しモダンな構成とする ● フロントエンド部分とバックエンド部分をREST APIを通じて連携させ、フロントエンドの開発自由度を高める 15 メール作成サーバーフォーム機能バックエンドフォーム機能フロントエンド API + FPM

Slide 16

Slide 16 text

フォーム機能の技術課題への対策アクションシステム設計面でのモダナイズ 16 チャレンジしたこと・一般ユーザー向けフォーム機能をサブシステム化・アプリケーションとDB（マルチコンテナ&複数サーバ）のマルチ接続・フロントエンドとバックエンドをAPIでつなぐアプリケーション構成

Slide 17

Slide 17 text

フォーム機能の技術課題への対策アクション一般ユーザー向けフォーム機能をサブシステム化 ● 主幹システムにとらわれないBtoC専用のアプリケーションとして構築が可能となる ● BtoCのアクセスを想定したアプリケーションとしてのサブシステム構成は、配配としては初 ○ データ集計やバッチ処理、ファイル処理等の業務のサブシステムは実績あり ● エラー解析システム ● データ集約システム ● 添付ファイルメール用ダウンロードシステム等など 17

Slide 18

Slide 18 text

フォーム機能の技術課題への対策アクションアプリケーションとDBのマルチ接続サブシステムと主幹システムが連携する上でのポイント ● サブシステムのサーバーは冗長構成とする ○ 多数のアクセスに耐えうる構成とし、アクセス増の場合はリソース追加で対応できるようにする ● フォームの設定情報、回答情報を、各テナントのDBに保持する ○ サブシステム側にDBを持つと巨大なモノリスDBになる＋主幹システム側の改修が複雑になる 18 サブシステムサーバーとメール作成サーバーの接続は 1：n の接続を可能とした

Slide 19

Slide 19 text

フォーム機能の技術課題への対策アクション 19 一般ユーザーフォーム管理者サブシステムサーバ Nginx PHP （フォーム機能）メール作成サーバ Apache PHP （フォーム設定） LB (Nginx) サブシステムサーバメール作成サーバ・・・・・・・・・アプリケーションとDBのマルチ接続サブシステムサーバ

Slide 20

Slide 20 text

フォーム機能の技術課題への対策アクションアプリケーションとDBのマルチ接続マルチな接続を実現する為に ● フォームの公開処理と同時にフォーム設定情報とDB接続先情報をJSONファイル化 ● JSONファイルをサブシステムが参照できる領域に共有 ● サブシステムがDB処理時にDB接続先情報を読み取り、目的のDBへ接続し処理する 20 全て今までのサブシステム化のノウハウが合ったからこそ実現できた ● 1サーバー→複数DB接続はエラー解析システムで ● JSONデータを用いたデータ連携処理は添付ファイルメール用ダウンロードシステムで

Slide 21

Slide 21 text

フォーム機能の技術課題への対策アクションフロントエンドとバックエンドをAPIでつなぐアプリケーション構成 ● リッチなＵＩを実現する為には、従来の方式（HTML生成+JS）では難しい ● フロントエンドを一種のSPA的な構成とし、サーバーサイドとREST APIで連携 ○ フロントエンド側の自由度が高くなる ○ バックエンド側もAPIに基づく制御のみで済むため実装が行いやすい詳細は、「モダンなフロントエンド技術の導入」パートで 21

Slide 22

Slide 22 text

フォーム機能の技術課題への対策アクションサブシステムのアプリケーションモダナイズ 22 チャレンジしたこと・Slimフレームワーク採用・DDDとオニオンアーキテクチャ・コンテナ技術を利用した開発環境

Slide 23

Slide 23 text

フォーム機能の技術課題への対策アクション Slimフレームワーク採用 ● 軽量、シンプル。オニオンアーキテクチャに沿った実装が行いやすい ● 過去のサブシステムでの採用実績あり ● Slimにない軸となるクラス群も過去のサブシステムで行われていたものを流用/拡張可能 23 過去ノウハウを活かして効率よく開発を進める

Slide 24

Slide 24 text

フォーム機能の技術課題への対策アクション DDDとオニオンアーキテクチャ ● オニオンアーキテクチャの考えに基づきクラス構成を設計 ● 4層に整理 ○ アプリケーション層（ユースケース） ○ ドメインモデル層 ○ プレゼンテーション層 ○ インフラ層 ● アクションクラス、ユースケースクラスはREST APIのエンドポイントと、基本 1対1 ● フォームの構成情報、回答情報、等をドメインクラスに分解 ● トランザクションはユースケースクラス内で開始/終了が管理できるように 24 Application Presentation Infrastructure UseCase Domain

Slide 25

Slide 25 text

フォーム機能の技術課題への対策アクション DDDとオニオンアーキテクチャ ● チーム内でもDDDやオニオンアーキテクチャの経験が浅い ● チーム内に展開する前に、一番の有識者が基本構成を設計 ● チーム内レビューを経て軸となるクラス群の枠組みを実装、各機能実装担当者へ展開 25

Slide 26

Slide 26 text

フォーム機能の技術課題への対策アクションコンテナ技術を利用した開発環境 ● サブシステムの開発環境をDockerを用いて準備 ● 詳細は、PHPカンファレンスでの発表をご覧ください。 26

Slide 27

Slide 27 text

フォーム機能の技術課題への対策アクションその他のチャレンジ ● バックエンドとフロントエンドチームは東京・大阪と物理的にも分離 ● 効率よく作業を進めるため準備（API設計書の事前準備、設計書をベースにモック作成） ● チャットベースで出来るだけ早いレスポンス行う 27 ・バックエンドとフロントエンドの完全分業・バックエンドチームとフロントエンドチームとの密なコミュニケーション

Slide 28

Slide 28 text

結果取り入れた技術 ● サブシステム化による段階的なモダナイゼーションの実施 ○ 一種のモジュラーモノリス化の促進 ● バックエンドとフロントエンドの分離 ● モダン設計思想によるアプリケーション開発 ● コンテナ技術を利用した開発環境 28  実現した顧客価値 ● 多くの一般ユーザのアクセスに応えるフォーム機能

Slide 29

Slide 29 text

残課題と今後の展望 ● 本丸のレガシーはそのまま ● レガシーの改善ロードマップを策定、本丸部分のリファクタリングプロジェクト始動 ● サブシステム構築でのノウハウを活かし、密結合となっているソースをリファクタリング ● モジュール化を促進し、将来のフレームワーク移設やサブシステム化が行いやすい状態を目指す 29

Slide 30

Slide 30 text

モダンなフロントエンド技術の導入 30 

Slide 31

Slide 31 text

登壇者紹介開発推進部フロントエンド開発1課亀ノ上孝雄 Webサイト制作会社を経て、マークアップエンジニアとして株式会社ラクスへ入社。入社後は配配メール専属のマークアップエンジニアとしてUI/UXの向上に注力し、次第に担当範囲をフロントエンド開発全般に拡大。現在は配配メールのフロントエンド開発を牽引しつつ、全社に向けたWebアクセシビリティの推進活動に注力している。 31

Slide 32

Slide 32 text

従来のフロントエンド技術 jQuery ● 配配メール開発初期はjQuery全盛期 ● jQueryの恩恵を受けて自作のjQueryプラグインを量産 ● 時代は命令的UIから宣言的UIへ ○ jQueryは衰退し、負債となっていった… 32 負債例 ● メンテナンス性・可読性が低い ○ jsで文字列結合したDOMをappend（挿入）している ● CSSが複雑化している ○ インラインスタイル、高い詳細度、!important

Slide 33

Slide 33 text

モダン技術を取り入れるチャレンジをしてきた実績を紹介従来のjQueryのアプローチでは実装難易度が高い複雑なUIの登場 33 ヒートマップ配信ペース

Slide 34

Slide 34 text

モダン技術を取り入れるチャレンジをしてきた実績を紹介 Vue.jsを採用 ● 他のレガシーシステム（MailDealer/ChatDealer）ではすでにVue.jsを導入した実績があった。 ● プログレッシブフレームワーク ○ 段階的に必要な問題解決を行うことができる。 ○ 今後別の画面でVue.jsを利用することがあっても、柔軟に対応できる。 ● 既存のHTMLファイル（テンプレートエンジン）にVueコンポーネントを提供する。 34

Slide 35

Slide 35 text

フォームでの技術課題と対策アクションの紹介フォームやポップアップを実現する上での課題とその対策 ● Webページ上で入力画面と送信画面の複数画面を持つSPAを実現する。 ● 要件を満たすためフロント側で動的な入力項目の生成が必要 ● アプリケーションが複雑化するので、jQueryでは不十分。 ● Vue.jsで開発したコンポーネントを提供する方針を決定し、開発を行った。 35

Slide 36

Slide 36 text

フォームでの技術課題と対策アクションの紹介エンドユーザー画面の開発をしたコンポーネントを配配メールの管理画面側で再利用 36 ● Vueコンポーネントを再利用することで、レガシーアーキテクチャで動く管理画面上に、モダンなコンポーネントを搭載し、リアルタイムにプレビューする機能を実現した。

Slide 37

Slide 37 text

成果取り入れた技術 37 ● Vue.js, ● Vuetify ● Vite ● Storybook ● Vue Test Utils 以前の技術スタック取り入れた技術 Vue Test Utils

Slide 38

Slide 38 text

実現した顧客価値リッチなUIの実現 ● モダンなデザイン ○ マテリアルデザインベース (Vuetify) ● ストレスを低減するUXの提供 ○ リアルタイム更新 ■ バリデーションチェック ■ フォーム更新データ取得 ○ 画面遷移時に、ページ全体を再読み込みしない (SPA) 38

Slide 39

Slide 39 text

実現した顧客価値 Webアクセシビリティ ● 静的解析ツール ○ eslint-plugin-vuejs-accessibility ○ @storybook/addon-a11y ● アクセシビリティチェックツール ○ axe DevTools 39

Slide 40

Slide 40 text

残課題と今後の展望 40 ● ライブラリのバージョンアップ運用方法策定 ○ ライブラリのマイナーバージョンアップであっても大変だったので、安定した運用を目指す。 ● 自動テストの拡充 ○ ユニットテスト強化 ○ ビジュアルリグレッションテスト導入 ● Webアクセシビリティ改善 ○ 目標とする達成基準を準拠できてないので改善していく

Slide 41

Slide 41 text

まとめ 41 

Slide 42

Slide 42 text

まとめ 2つの技術的チャレンジ・レガシーシステムのモダナイズ・モダンなフロントエンド技術の導入・顧客課題に向き合って解決手段を選別・段階的にモダナイゼーションを進行 42 

Slide 43

Slide 43 text

まとめ無事リリースし顧客へ提供開始 ● 顧客課題の解決策として検討したフォーム／ポップアップ機能を 2024年1月から順次リリース ● 新機能の問い合わせやセミナーの申し込みが増加中 43  https://www.hai2mail.jp/news/2024/20240110.php  

Slide 44

Slide 44 text

まとめ顧客課題に向き合い、さらなる進化へ ● リード獲得と商談獲得の価値提供を中心に据えた製品サイトへリニューアル ● さらなる進化に向けて機能強化と技術的チャレンジを継続中 ● モダンな技術からも目をそらさず、レガシーなサービスを進化させたい 44  https://www.hai2mail.jp/bridge/about/  

Slide 45

Slide 45 text

ご清聴ありがとうございました。 45 