手動で行っていたメールアドレスの登録を自動化！メルマガ配信サービスへのメールアドレス自動登録開発ストーリー

今回は6月に開発された「メルマガ配信サービスへのメールアドレス自動登録」に関して、エンジニアの小川さんに突撃インタビュー！

少し社外に出せるものが少ないのですが、手動化してたものを自動化するという、NoSchoolが大切にしている、「仕組み化・自動化」の体現するリリースだったので、技術的な面に関してお話を聞きました！

今回の開発の山場や工夫点、今後の改善につなげたい点など語っていただきました！

NoSchoolではエンジニア採用も積極的に行っているので、興味ある方は「話を聞きに行きたい」からご連絡ください！

-今回も小川さんにお話を伺います！今回リリースした機能の内容を簡単に教えて下さい！

新規ユーザーの会員登録時などに、メールマガジンを配信するサービス（以下「メルマガ配信サービス」）へ、その新規登録したユーザーのメールアドレスを自動でリストに追加するような処理を既存実装に追加しました。

背景として、マナリンクでは、サービスに登録しているユーザー宛に、新機能のリリース時などにメールマガジンを配信することがあります。

外部のメルマガ配信サービスを使用しており、これまで、ユーザーが新規登録をした際、その新規登録したユーザーのメールアドレスをメルマガ配信サービスの指定のリストへ「手動」で追加するという運用をとっていました。 今回、開発した新機能(追加実装)によって、ユーザーの新規登録時などに自動でメールアドレスがメルマガ配信サービスに登録されるようになり、これまで手動で登録していた作業が不要になりました。

今回はメールアドレス自動登録処理を追加したのみなので、皆さまに見せられる画像がないのが残念ですね....

‐あー。そうなんですね。でも手入力でしてたことを自動化するって素晴らしい！今手入力でミスが起きているサービスもありますもんね...開発を始める前に、技術的に一番ネックだと思ったことはなんですか？

ネックだと思ったところは、特定のメルマガ配信サービスに直接依存させないように設計する部分ですかね。

まず前提として、今回のメルマガ配信サービスへのメールアドレスの自動登録の対象となる箇所は、ユーザーの新規登録時や、先生の審査合格時など、複数箇所で行なう必要がありました。

今回のメールアドレス自動登録処理の対象となる箇所にひとつひとつ、直接外部サービスのAPIを叩くように実装することも勿論可能ですが、もし今後別のメルマガ配信サービスに移行するということが起きた場合に、改修する必要がある場所が多くなってしまうという問題があります。 そこで、メールアドレスの自動登録処理の対象となる箇所それぞれが、直接外部サービスに依存することがないように設計する必要がありました。

‐今回の機能の開発を初める前と開始後に、「技術的に一番ネックだったこと」にGAPはありましたか？

特になかったですね。

自分の仕事の進め方としてよく行なっていることであるため、あまり目新しいことではないのですが、上記項目についての設計をする段階で、大まかな実装方針についての壁打ちを上長と行ない、その合意を取った上で開発を進めるようにしていたため、大きなGAPが生まれるようなことはありませんでした。

‐小川さんの仕事のやり方や活きたということですね！ちなみに今回の開発の難しかった、苦戦したところはありますか？

さっきのGAPの回答と一緒になってしまうのですが、特定のメルマガ配信サービスに直接依存させないように設計する部分ですね。

GAPの部分でもお話したのですが、メルマガ配信サービスにメールアドレスを自動登録する必要がある複数の対象箇所で、外部のメルマガ配信サービスに直接依存しないような形で実装を進める必要がありました。

これに対しては、「メルマガ配信サービス用のインターフェース」を切り、各呼び出し元(メールアドレスの自動登録をする必要のある対象箇所)はこのインターフェースに依存させるように組むことで、外部サービスに直接依存させないようにするということを実現しました。 また、「メルマガ配信サービス用のインターフェース」の実装クラス内で特定のメルマガ配信サービスのAPIを呼び出すことで、今後別のメルマガ配信サービスに移行したいということになったときでも、この実装クラスの中身を改修するだけで移行が完了するなど、保守性の観点からも変更に強い形になりました。

‐今回の開発機能の技術的な工夫点はありますか？

３つありますね。

①特定のメルマガ配信サービスに直接依存させないように設計する部分

これまでのお話させていただいたところになりますが、ここは工夫した部分ですね。

② 剥がしやすいライブラリ選定

特定の外部サービスへの依存度合いは、インターフェースを切ることで既に大きく下がっているが、インターフェースの実装クラス内で使用しているライブラリ自身も、スター数や実装のシンプルさを重視して、できる限り薄いライブラリを選定しました。というのも、要件として実現したいことは「特定のメルマガ配信サービス内のリストへメールアドレスを登録する」というシンプルなものであったためです。

③メールアドレスの自動登録処理はトランザクション外に置いたこと

メルマガ配信サービスへのメールアドレスの自動登録処理は、ユーザーの新規会員登録時であれば、新規会員登録処理のトランザクション外に配置するようにしました。 今回のメールアドレス自動登録処理は、外部のサービスに依存していることもあり、外部サービスの一時的な障害の際に、メインの処理が落ちてしまうのは嫌だったため外出しするようにしました。

‐開発機能の技術的な工夫点はありますか？

先ほどもお話しましたが、事前の壁打ちで大枠の実装方針の合意を取った上で実装を進めるということに注意を払って開発を進めました。 設計周りは今後の改修の際にもどう設計されているかが大きく影響するので、この部分は丁寧に開発を進めるように意識しました。

‐今回の機能のリリース前とリリース後に「個人」として成長した部分はありましたか？

「開発の山場」のところでも書いたように、特定の外部サービスに直接依存することがないように、インターフェースを切ってその依存度を下げることができたのは、個人的な成長ポイントでした。 「インターフェースに依存させることで具体的な詳細への依存度を下げる」というのは、今後も多用することになる考え方だと思うので、今回実践することができて良かったです。

‐今回リリースした機能が80%の完成度だとして、残りの20％でどのように発展していきたいか教えて下さい。

今回のこの開発は、全体的に満足行く開発ができたので、妥協した点や甘かった点は個人的には殆どなかったですが、インターフェースの使い方に関してはもっとたくさんの実践を通してより知見を深めていきたいと感じました。