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

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

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

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

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

【運営事業】オンライン家庭教師のマッチングプラットフォーム「マナリンク」（マナリンクHP：https://manalink.jp）【対象ユーザー】・オンライン家庭教師塾や家庭教師などで指導実績があり、「個人塾経営者」、「元証券マン」や「現役バレエダンサー」などさまざまなバックグラウンドをお持ちの先生が登録しています。オンラインでの指導のため、直接生徒のご自宅に行く必要がないため、「本業」「副業」さまざまな働き方の先生がいらっしゃいます。・「学びたい」生徒メインは小学生/中学生/高校生、「学びたい」理由はさまざまです。「中高一貫校に通っているけど、一部の教科が苦手」「英検を受けるために対策をしたい」などなど。さまざまな理由で学校に通えない方や海外在住の日本人の生徒さんもいらっしゃいます。 1割弱ですが「社会人」の生徒さんもいらっしゃいます。【マナリンクの特徴】 ①社会人の先生のみの「オンライン家庭教師」として登録可能家庭教師というと「学生」をイメージしがちですが、マナリンクは経験豊富な「社会人」の先生の登録のみ。指導実績豊富で熱意のある先生に出会えます。 ②「指導してもらえるオンライン家庭教師の先生」の様々な情報が見れる家庭教師業界の抱える問題の1つに「情報の非対称性」があります。マナリンクでは登録している先生の様々な情報を開示することで、学ぶ側が安心・納得して先生を選べるようにしています。例えば... ・先生の自己紹介動画（先生のしゃべっている雰囲気や指導理念が確認いただけます）・先生の指導実績・先生のコース料金（マナリンクでは決まった料金プランがないため先生によって指導時間/回数/料金が異なります）そのほかにも指導した生徒さんからの口コミ、「感謝の声」も見ることができ、実際に指導を受けた生徒さんからの生の声を覗くことができます。 ③専用アプリやWEBページを使って「指導しやすい」「学びやすい」環境を提供マッチングプラットフォームというと、「マッチングさせたらそれで終わり」というイメージが強いですが、「マナリンク」はマッチングされた後も、自社開発の専用アプリやWEBページを使うことで「学びやすい」「指導しやすい」環境を提供しています。例えばこんな機能があります！・授業時間外も「先生」とやり取りできる「チャット機能」・「授業日や時間を忘れてた！」を防止する「カレンダー機能」・宿題の出し忘れやお子様の学習状況を確認できる「宿題提出機能」

株式会社NoSchool

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

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

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

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

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

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

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

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

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

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

特になかったですね。

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

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

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

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

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

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

３つありますね。

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

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

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

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

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

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

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

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

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

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