DMM.comの、一番深くておもしろいトコロ。

storybookでUIコンポーネントと同様にメールテンプレートを管理してみた

storybookでUIコンポーネントと同様にメールテンプレートを管理してみた

  • このエントリーをはてなブックマークに追加

storybookでUIコンポーネントと同様にメールテンプレートを管理してみた


はじめに

この記事は、DMMグループ Advent Calendar 2022の2日目の記事です。

こんにちは。VPoE室の飯田涼太です。

本日は、ユーザに送付するメールのテンプレート管理にもstorybookを導入してみたことについて書いてみます。

アドベントカレンダーのシーズンは読み物もたくさんありますので、ツール自体の紹介や細かい経緯は省いてコンパクトにお届けします。

次のような流れで紹介します。

  • 取り組み概要
  • 課題感について
  • 今回の解決策紹介
  • 改めて結果についておさらい
  • 最後に

取り組み概要

実施したことは、掲題のとおりですが、 解決のイメージを揃えたいのでイメージ図を共有します。

解決イメージ

UIコンポーネントと同様に、ユーザに送付するメールのテンプレートもstorybookで閲覧できるようにしました。

この取り組みの背景として、当時のメール本文を生成するテンプレート機構が現代に即した仕組みになっていないという課題がありました。課題感の詳細は後述しますが、メールの本文も全容も影響も、どれも把握が難しく、変更はおろか現状確認すら対応しづらい状態になっていました。(今回取り組むことになった経緯は割愛)

課題感について

ここからは課題感について具体的に書いていきます。

当時は次のような問い合わせがあっても、どうしても即時対応が難しい状況でした。

Q.「今ってどんなメール出してるんだっけ?」

A.「一覧出すのにしばらくお時間をください」

Q.「xxなケースの本文を変えたいんだけど...」

A.「影響範囲の確認にしばらくお時間をください」

これは当時のメールテンプレート機構が抱える3つの課題が原因でした。 具体的に次の3つです。

  • 本文の把握が難しい
  • 全容の把握が難しい
  • 影響範囲の把握が難しい

どうして難しかったのかを伝えるために、当時はどのようにメール本文を生成していたかを少し紹介させてください。

当時のメールテンプレート機構の特徴は次のとおりです。

  • プログラムで動的に本文を生成している
  • 大まかな機能ごとに1つのテンプレートクラスが定義されている
  • body()メソッドの呼び出しで本文を生成する
  • コンストラクタ引数の値で本文内の変数を置換する
  • コンストラクタ引数の値に応じて、部分的に内容を変更する

この大まかな機能ごとの区切りが大きすぎた点と、コンストラクタ引数で結果が変更できるケースも増加したことで、開発の足を引っ張るようになりました。

もう少し具体的に説明します。例えば、アカウント登録です。 実際に送付するメールには、メアドとパスワードによるのか、SNS連携によるのかという機能単位の違いもあります。また、正常系の登録時の認証メールや登録完了メールもあれば、異常系で複数の登録不可メールが存在します。これに加えて利用サービスや、PC/スマホといったUAの違いによった文言の切り替えもありました。

「登録」という安易な区切りの中に、数多くのケースが内包されてしまい、クラス内に記述された他の全てのケースのメールが影響範囲になっていました。

それにもかかわらず、preview用の仕組みはなく、自前でコードを書き、コンストラクタの引数を把握する必要がありました。

一言でまとめると、現状を把握するにも、変更するにもとにかく時間がかかってしまうメールテンプレート機構でした。

今回の解決策紹介

今回は、storybookとi18nextを採用してこの「時間がかかってしまう問題」の解決を図りました。

既存のUIコンポーネントもstorybookとi18nextの組み合わせで管理されていたため、テキストだけのUIコンポーネントができたようなイメージです。

mail_template/xxx_action/
├── en.yaml           - 英語テンプレート
├── index.stories.tsx - storybook
├── index.ts          - ロジックファイル
├── ja.yaml           - 日本語テンプレート
└── zh-CHT.yaml       - 繁体字テンプレート

工夫した点としては、storiesファイルの区切りです。

安易な区切りの中に、数多くのケースが内包される というつらみを繰り返さないために、アプリのルーティングベースで分けることにしました。 このため、テンプレートとurlが基本1対1でマッピングすることになり、どのページでどのメールが送られるか把握しやすくなり、今後メンバーが入れ替わり 前に倣え になったとしても、曖昧な区切りが生まれにくいようにしてみました。

改めて結果についておさらい

メールのテンプレート管理について、当時の仕組みが現行に即しておらず、現状の把握も変更するにもとにかく時間がかかってしまっていたという課題がありました。 私たちの事例では、storybookをメールテンプレート管理にも活用してみることで、これらの時間がかかってしまう問題を解決できました。

同様の課題を抱えている現場での解決の一助となれば幸いです。

最後に

今回はサーバサイドのエンジニアとしての一面を書かせていただきましたが、私自身は所属がVPoE室ということもあり、組織課題の解決も主務の1つとして担当しております! エンジニア経験をベースに組織課題に一緒に取り組んでくれる方の募集もしておりますので、ご興味ありましたらぜひご検討ください。

VPoE室サポートエンジニアの求人|採用情報|DMM Group

引き続きDMMアドベントカレンダー2022もお楽しみください。