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

◆イベント名
RAKUS Tech Conference 2024
https://techcon.rakus.co.jp/2024/

◆発表タイトル
新たな顧客課題に挑む17年目の進化とモダナイゼーション

◆登壇者
大阪開発統括部 配配メール開発課 課長　大塚正道
大阪開発統括部 配配メール開発課　井上良太
開発推進部 フロントエンド開発1課　亀ノ上孝雄

Transcript

1. 新たな顧客課題に挑む 17年目の進化と モダナイゼーション 大阪開発統括部 ラクスクラウド開発部 配配メール開発課　大塚 正道 大阪開発統括部 ラクスクラウド開発部 配配メール開発課　井上 良太 開発推進部 フロントエンド開発1課　亀ノ上 孝雄
2. 登壇者紹介 大阪開発統括部 ラクスクラウド開発部 配配メール開発課 大塚 正道 SIer等を経て2011年に株式会社ラクスへ入社。 BtoCサービスや北米向けサービスなどの新規事業の開発を経験した後、2015年から楽楽精算の スマホアプリなどを開発。2019年からは配配メールの開発チームのマネジメントに従事中。コロナ 禍に始めたトレイルランニングが最近の趣味。 2

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

4. 新たな顧客課題に挑む 4

5. 新たな顧客課題に挑む 顧客が成果を実感しづらい課題 近年はMA（マーケティング・オートメーション）機能などを取り入れて、メール配信ツールからメール マーケティングサービスへ進化。顧客の成果に繋がるように、マーケティングのPDCAを回せる機 能強化を行ってきた。しかし、PDCAを回して成果に繋げるのは顧客次第。成果を感じてもらえず、 解約に至ることも… 5
 P D C A リード育成① ・グループ化 ・ステップ設定 リード育成② ・予約配信 ・メモリー配信 追客 ・トリガーメール ・フォローメール 成果分析 ・効果測定 ・ホットリード検出 ・来訪検知
6. 新たな顧客課題に挑む 顧客の成果を支える価値提供を模索 より直接的に顧客の成果を支える価値を提供するため、PDCAの入口と出口を強化。 ・リード獲得⇒育成するためのリードを生み出す ・商談獲得⇒最終成果である受注に繋げる機会を生み出す 6
 P D C A リード育成① ・グループ化 ・ステップ設定 リード育成② ・予約配信 ・メモリー配信 追客 ・トリガーメール ・フォローメール 成果分析 ・効果測定 ・ホットリード検出 ・来訪検知 リード獲得 ・フォーム ・ポップアップ 商談獲得 ・フォーム
7. 新たな顧客課題に挑む 顧客課題の解決策 7
 フォーム（問い合わせ） ポップアップ機能
8. 新たな顧客課題に挑む 既存のアーキテクチャを超える新たなテーマ メール配信を軸として機能を提供してきたこれまでとは違った技術的アプローチが必要。 17年目の進化に向けた2つの技術的チャレンジ ・レガシーシステムのモダナイズ ・モダンなフロントエンド技術の導入 8

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

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

11. 従来のバックエンド技術 サーバー構成 配配メールのメール作成（主幹）サーバー • Webサーバー、DB、アプリケーションが同居 • DBはマルチテナント型 • このサーバーが複数存在 • メール作成サーバー同士の連携はなし 11 ユーザーZ ・・・ ユーザーB ユーザーA
12. 従来のバックエンド技術 アプリケーション • PHP 8.2 • Ethnaベースの独自フレームワーク → MVC構成 • Smarty • データベースはPostgreSQL 15.6 12
13. フォーム機能を実現するための技術課題 システム構成面での課題 • 想定アクセスなどパフォーマンス要件が、メール作成サーバとは全く異なる ◦ BtoCを想定したパフォーマンス要件がある ◦ BtoB想定の既存のサーバーではパフォーマンス要件を満たせられない 13 アプリケーション面での課題 • 一般ユーザーに向けたリッチなUIの実現が必要 ◦ 現在はサーバーからHTMLを生成してレスポンスを返すオーソドックスな構成 ◦ 既存の構成のままであればリッチなUIは実現しにくい
14. フォーム機能を実現するための技術課題 既存のサーバー構成、 アプリケーションのままでは 機能実現は困難 14 ユーザーZ ・・・ ユーザーB ユーザーA
15. フォーム機能の技術課題への対策アクション 打ち出した方針 • 一般ユーザー向けフォーム機能をサブシステム化しモダンな構成とする • フロントエンド部分とバックエンド部分をREST APIを通じて連携させ、フロントエンドの開発 自由度を高める 15 メール作成サーバー フォーム機能 バックエンド フォーム機能 フロントエンド API + FPM
16. フォーム機能の技術課題への対策アクション システム設計面でのモダナイズ 16 チャレンジしたこと ・一般ユーザー向けフォーム機能をサブシステム化 ・アプリケーションとDB（マルチコンテナ&複数サーバ）のマルチ接続 ・フロントエンドとバックエンドをAPIでつなぐアプリケーション構成
17. フォーム機能の技術課題への対策アクション 一般ユーザー向けフォーム機能をサブシステム化 • 主幹システムにとらわれないBtoC専用のアプリケーションとして構築が可能となる • BtoCのアクセスを想定したアプリケーションとしてのサブシステム構成は、配配としては初 ◦ データ集計やバッチ処理、ファイル処理等の業務のサブシステムは実績あり • エラー解析システム • データ集約システム • 添付ファイルメール用ダウンロードシステム 等など 17
18. フォーム機能の技術課題への対策アクション アプリケーションとDBのマルチ接続 サブシステムと主幹システムが連携する上でのポイント • サブシステムのサーバーは冗長構成とする ◦ 多数のアクセスに耐えうる構成とし、アクセス増の場合はリソース追加で対応できるようにする • フォームの設定情報、回答情報を、各テナントのDBに保持する ◦ サブシステム側にDBを持つと巨大なモノリスDBになる＋主幹システム側の改修が複雑になる 18 サブシステムサーバー とメール作成サーバー の接続は 1：n の接続を可能とした
19. フォーム機能の技術課題への対策アクション 19 一般ユーザー フォーム管理者 サブシステムサーバ Nginx PHP （フォーム機能） メール作成サーバ Apache PHP （フォーム設定） LB (Nginx) サブシステムサーバ メール作成サーバ ・・・ ・・・ ・・・ アプリケーションとDBのマルチ接続 サブシステムサーバ
20. フォーム機能の技術課題への対策アクション アプリケーションとDBのマルチ接続 マルチな接続を実現する為に • フォームの公開処理と同時にフォーム設定情報とDB接続先情報をJSONファイル化 • JSONファイルをサブシステムが参照できる領域に共有 • サブシステムがDB処理時にDB接続先情報を読み取り、目的のDBへ接続し処理する 20 全て今までのサブシステム化のノウハウが合ったからこそ実現できた • 1サーバー→複数DB接続はエラー解析システムで • JSONデータを用いたデータ連携処理は添付ファイルメール用ダウンロードシステムで
21. フォーム機能の技術課題への対策アクション フロントエンドとバックエンドをAPIでつなぐアプリケーション構成 • リッチなＵＩを実現する為には、従来の方式（HTML生成+JS）では難しい • フロントエンドを一種のSPA的な構成とし、サーバーサイドとREST APIで連携 ◦ フロントエンド側の自由度が高くなる ◦ バックエンド側もAPIに基づく制御のみで済むため実装が行いやすい 詳細は、「モダンなフロントエンド技術の導入」パートで 21
22. フォーム機能の技術課題への対策アクション サブシステムのアプリケーションモダナイズ 22 チャレンジしたこと ・Slimフレームワーク採用 ・DDDとオニオンアーキテクチャ ・コンテナ技術を利用した開発環境
23. フォーム機能の技術課題への対策アクション Slimフレームワーク採用 • 軽量、シンプル。オニオンアーキテクチャに沿った実装が行いやすい • 過去のサブシステムでの採用実績あり • Slimにない軸となるクラス群も過去のサブシステムで行われていたものを流用/拡張可能 23 過去ノウハウを活かして効率よく開発を進める
24. フォーム機能の技術課題への対策アクション DDDとオニオンアーキテクチャ • オニオンアーキテクチャの考えに基づきクラス構成を設計 • 4層に整理 ◦ アプリケーション層（ユースケース） ◦ ドメインモデル層 ◦ プレゼンテーション層 ◦ インフラ層 • アクションクラス、ユースケースクラスはREST APIのエンドポイントと、基本 1対1 • フォームの構成情報、回答情報、等をドメインクラスに分解 • トランザクションはユースケースクラス内で開始/終了が管理できるように 24 Application Presentation Infrastructure UseCase Domain
25. フォーム機能の技術課題への対策アクション DDDとオニオンアーキテクチャ • チーム内でもDDDやオニオンアーキテクチャの経験が浅い • チーム内に展開する前に、一番の有識者が基本構成を設計 • チーム内レビューを経て軸となるクラス群の枠組みを実装、各機能実装担当者へ展開 25
26. フォーム機能の技術課題への対策アクション コンテナ技術を利用した開発環境 • サブシステムの開発環境をDockerを用いて準備 • 詳細は、PHPカンファレンスでの発表をご覧ください。 26
27. フォーム機能の技術課題への対策アクション その他のチャレンジ • バックエンドとフロントエンドチームは東京・大阪と物理的にも分離 • 効率よく作業を進めるため準備（API設計書の事前準備、設計書をベースにモック作成） • チャットベースで出来るだけ早いレスポンス行う 27 ・バックエンドとフロントエンドの完全分業 ・バックエンドチームとフロントエンドチームとの密なコミュニケーション
28. 結果 取り入れた技術 • サブシステム化による段階的なモダナイゼーションの実施 ◦ 一種のモジュラーモノリス化の促進 • バックエンドとフロントエンドの分離 • モダン設計思想によるアプリケーション開発 • コンテナ技術を利用した開発環境 28
 実現した顧客価値 • 多くの一般ユーザのアクセスに応えるフォーム機能
29. 残課題と今後の展望 • 本丸のレガシーはそのまま • レガシーの改善ロードマップを策定、本丸部分のリファクタリングプロジェクト始動 • サブシステム構築でのノウハウを活かし、密結合となっているソースをリファクタリング • モジュール化を促進し、将来のフレームワーク移設やサブシステム化が行いやすい状態を目指す 29
30. モダンなフロントエンド技術の導入 30

31. 登壇者紹介 開発推進部 フロントエンド開発1課 亀ノ上 孝雄 Webサイト制作会社を経て、マークアップエンジニアとして株式会社ラクスへ入社。 入社後は配配メール専属のマークアップエンジニアとしてUI/UXの向上に注力し、次第に担当範囲 をフロントエンド開発全般に拡大。 現在は配配メールのフロントエンド開発を牽引しつつ、全社に向けたWebアクセシビリティの推進 活動に注力している。 31
32. 従来のフロントエンド技術 jQuery • 配配メール開発初期はjQuery全盛期 • jQueryの恩恵を受けて自作のjQueryプラグインを量産 • 時代は命令的UIから宣言的UIへ ◦ jQueryは衰退し、負債となっていった… 32 負債例 • メンテナンス性・可読性が低い ◦ jsで文字列結合したDOMをappend（挿入）している • CSSが複雑化している ◦ インラインスタイル、高い詳細度、!important
33. モダン技術を取り入れるチャレンジをしてきた実績を紹介 従来のjQueryのアプローチでは実装難易度が高い複雑なUIの登場 33 ヒートマップ 配信ペース
34. モダン技術を取り入れるチャレンジをしてきた実績を紹介 Vue.jsを採用 • 他のレガシーシステム（MailDealer/ChatDealer）で はすでにVue.jsを導入した実績があった。 • プログレッシブフレームワーク ◦ 段階的に必要な問題解決を行うことができる。 ◦ 今後別の画面でVue.jsを利用することがあって も、柔軟に対応できる。 • 既存のHTMLファイル（テンプレートエンジン）にVueコ ンポーネントを提供する。 34
35. フォームでの技術課題と対策アクションの紹介 フォームやポップアップを実現する上での課題とその対策 • Webページ上で入力画面と送信画面の複数画 面を持つSPAを実現する。 • 要件を満たすためフロント側で動的な入力項目 の生成が必要 • アプリケーションが複雑化するので、jQueryで は不十分。 • Vue.jsで開発したコンポーネントを提供する方 針を決定し、開発を行った。 35
36. フォームでの技術課題と対策アクションの紹介 エンドユーザー画面の開発をしたコンポーネントを 配配メールの管理画面側で再利用 36 • Vueコンポーネントを再利用する ことで、レガシーアーキテクチャで 動く管理画面上に、モダンなコン ポーネントを搭載し、リアルタイム にプレビューする機能を実現し た。
37. 成果 取り入れた技術 37 • Vue.js, • Vuetify • Vite • Storybook • Vue Test Utils 以前の技術スタック 取り入れた技術 Vue Test Utils
38. 実現した顧客価値 リッチなUIの実現 • モダンなデザイン ◦ マテリアルデザインベース (Vuetify) • ストレスを低減するUXの提供 ◦ リアルタイム更新 ▪ バリデーションチェック ▪ フォーム更新データ取得 ◦ 画面遷移時に、ページ全体を再読み 込みしない (SPA) 38
39. 実現した顧客価値 Webアクセシビリティ • 静的解析ツール ◦ eslint-plugin-vuejs-accessibility ◦ @storybook/addon-a11y • アクセシビリティチェックツール ◦ axe DevTools 39
40. 残課題と今後の展望 40 • ライブラリのバージョンアップ運用方法策定 ◦ ライブラリのマイナーバージョンアップであっ ても大変だったので、安定した運用を目指す。 • 自動テストの拡充 ◦ ユニットテスト強化 ◦ ビジュアルリグレッションテスト導入 • Webアクセシビリティ改善 ◦ 目標とする達成基準を準拠できてないので 改善していく
41. まとめ 41

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

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

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

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