【MIIDAS Tech LIVE #4】を開催しました

こんにちはミイダス Tech Officeです。
ミイダス株式会社のテックチームが直近で開発した機能を現場のエンジニアから共有する「MIIDAS Tech LIVE」
第4回目の開催となる今回は3つのリリース情報をお届けしました。

採用マッチングサービス「ミイダス」は、独自の診断ツールで採用のミスマッチを減らす中途採用サービスです。メインの採用関連の機能に加え、診断や研修、組織サーベイの支援金の検索機能など、幅広い機能開発が行われています。

MIIDAS Tech LIVE #4 (2023/12/20 12:00〜)

本記事ではそのイベントの内容を書き起こし記事としてご紹介させていただきます。ミイダスの最新開発情報をぜひご覧ください。

---

永留：それではお時間となりましたので、始めさせていただきます。本日はご参加いただきまして、誠にありがとうございます。本日司会を務めますミイダス株式会社開発部Tech Officeの永留と申します。よろしくお願いいたします。
MIIDAS Tech LIVEと銘打つこちらのイベントは、ミイダス Techチームが直近で開発した機能に関して、現場のエンジニアから紹介を行う内容となっております。

私はミイダス株式会社開発部、テックオフィスの永留と申します。本日の司会を務めさせていただきますので、よろしくお願いいたします。無事に今年で4回目を迎えました。2023年の3月から始めまして、3ヶ月に一回で年4回の開催を目標に進めてまいりました。
そして無事に今年最後の4回目の開催となりました。何とか1年続けてこられて安心しています。今回もミイダス Techチームが直近で開発した機能などに関してご紹介ができればと思っております。どうぞよろしくお願いいたします。

オープニングでは、私からこのイベントの目的やミイダスTechチームの主な技術スタック、チーム編成などに関して説明をしていきます。本日は登録フローの改訂のフロントエンドとバックエンド、そしてMJMLの導入の内容について、現場のエンジニア3名から紹介させていただきます。最後にはMIIDAS NEWSということで、直近で起こった3つのニュースをお伝えして終了となります。早速ですが、オープニングを始めさせていただきます。

Opening

私たち「ミイダス株式会社」に関してご紹介させていただきます。独自の診断ツールを用いて採用のミスマッチを減らす中途採用サービス、ミイダスの企画・運営をしています。コンピテンシー診断やバイアス診断ゲームといった診断ツールを活用して、転職ユーザー向けにはより自分にフィットした適切なオファーを、企業向けには診断結果を基にしたフィッティング人材分析というものにより、自社でより活躍しやすいハイパフォーマーの採用を可能にするツールとしてご提供しております。

サービス開始からは約7年が経過し、8年目を迎えています。全体の従業員数は約550名で、開発部は約95名の規模感となっています。サービスのユーザー数は約100万人、企業登録数は約42万社です。採用マッチング機能はもちろんのこと、組織サーベイの機能や育成・研修支援金など、採用以外の機能も積極的に提供しております。

今回の「MIIDAS Tech LIVE」では、3つのTECHチームが直近で開発した機能を現場のエンジニアから共有させて頂きます。メインの採用関連の機能に加えて、診断や研修組織、サーベイ、支援金検索機能など、幅広い機能開発に関してお伝えしていきたいと思います。

本イベントの目的は、私達の取り組みを定期的に紹介していくことでミイダスのビジネスをより深く知って頂くことです。その中で、もしビジネスやちょっと働くことに興味があると思っていただけましたら、イベントの最後に採用に関するご案内をしますので、ぜひご覧いただけると嬉しいです。どうぞよろしくお願いします。

次に、ミイダスの主要な技術スタックについて簡単に説明します。フロントエンドではJavaScriptを主に使用しており、一部TypeScriptを導入しています。フレームワークはReactを使用し、Nextも部分的に導入しています。状態管理にはReduxを使用しています。バックエンドはGoで開発しています。

もしご質問や気になる点がありましたら、Q&Aやコメントでお知らせください。

続いて、ミイダスの開発組織の体制についてご紹介したいと思います。ミイダス開発部という部署には、大きく4つのグループが存在します。1つ目は「プロダクト開発グループ」で、ミイダスを開発するエンジニアたちが集まっています。実際に、開発部全体の約8割がこのグループに所属しています。
2つ目は「運用グループ」です。ミイダスの品質レポートやKPIレポートの検証、監視などを担当しています。
3つ目に「開発人事グループ」があります。ミイダスでは、職域ごとに人事が配置されているため、開発部には専任の人事がいます。このグループは採用、技術広報、評価、制度設計などの業務を担当しています。最後の4つ目は「開発システムグループ」と呼ばれるもので、PCやネットワーク、ツールの管理に加え、ミイダス社内のセールスチームが使用する営業支援システムの開発も行っています。

さらに多くのメンバーが所属している「プロダクト開発グループ」の中身に関しても説明します。ミイダスの開発には、大きく分けて採用関連の機能開発チーム、採用以外の機能開発チーム、そしてプロダクト全体の保守を行うチームの3つが存在します。

以上が、ミイダスの開発組織の大まかな体制となっております。これでミイダスの開発組織に関する簡単なご紹介を終わりにします。

続いて、リリースした機能の紹介に入っていきたいと思います。まずは登録フローの改訂、特にフロントエンド側での動きに関してですね。Nishiyaさんからの説明となります。

簡単にこの機能自体に関して紹介します。まず転職をしたい方がミイダスに登録をする部分の登録フローと言います。この登録フローでできるだけユーザーが離脱しないように、そしてたくさんの方が登録をしていただけるように、さまざまな工夫をしてきました。そして今回、この登録フローに大きな改訂が入りました。その内容に関するフロントエンドの部分について、Nishiyaさんから発表していただきたいと思います。それでは、Nishiyaさんよろしくお願いします。

登録フロー改訂 - フロントエンド -

Nishiyaと申します。今回登録フロー改訂のフロントエンド領域を中心に、全般的なプロジェクトの紹介をさせていただきます。

ミイダスのフロントエンドエンジニアとしてリクルーティングチームに所属してます。セールスエンジニアとしてキャリアを開始し、フロントエンドエンジニアとしてReactを5-6年間使っています。リクルーティングチームの中では、ここ1年間くらいはずっと登録フローの改訂に携わっています。

登録フローの突破率を上げる、これはどのサービスにも共通する大きな課題ですね。特に、ミイダスという転職サービスでは、転職者が登録フローで提供した情報を応募企業に提供する必要があります。さらに、企業側が求職者を探すためのツールとしても利用されるため、設問数を減らすのが難しい状況です。

今年、ミイダスでは方針転換がありました。企業と求職者のマッチング機会をより最大化し、採用プロセスを効率的に進めることが新たな目標です。この新方針のもと、設問数を増やすという要望も出ています。そうした中で、登録フロー改定の主な目的は、どうにかして突破率を高めることにあります。特に私は、登録フローの突破率向上に注力し、その点について発表を行いたいと思っています。

まず、開発期間について話します。登録フローにはv0、v1というように名前が付いていて、3月に始まり、現在はv2が終わりかけています。今は12月で、既に10ヶ月が経過しているんです。そして、これからv3の開発も予定しています。

実際に行ったことは多岐にわたります。登録フローの突破率を上げるため、設問の削減やSMS認証の廃止を行いました。また、求職者情報の充実にも取り組みました。例えば、求職者にプロフィールの情報を拡充してもらうためにメールを送ったり、アプリ上でも応募完了時にスカウトを得るためにプロフィールを充実させることを促すメッセージを表示したりしています。また、これまでは企業ごとに経歴を履歴書のように登録できる機能がありました。しかし、今はもっと柔軟に、例えば「フロントエンドエンジニアとして5-6年の経験あり」のように登録できるようになりました。本当に、多くの改善を行ってきました。体制としては、バックエンドエンジニアが合計で3人、フロントエンドエンジニアも少しヘルプを受けつつ3人で構成されています。そこにデザイナーや企画チームも含めた体制で取り組んでいました。登録フローの突破率向上のための施策について、いくつかピックアップして話したいと思います。

まず、SMS認証の廃止についてです。電話番号を聞くことが結構なハードルであり、SMS認証ができないという問い合わせも多かったんです。ミイダスではログイン後にトーク機能もあるため、電話番号の認証がなくても企業と求職者がトークできるという点も考慮しSMS認証の廃止を決定しました。

登録フローの中で、色々な情報を入力してもらう過程で、ユーザー操作の補助にも取り組みました。例えば、画像中央左側の部分に、希望する勤務地を選択する設問があります。どのような仕事を探しているか、そしてどの勤務地を希望するかという質問です。埼玉に住んでいる人の場合、埼玉県は最初から選択した状態にして、求職者に他の地区を選んでもらうような補助を行いました。また、希望する職種に関しても、求職者のこれまでの経験職種を基に、それに似た職種を提案するような形で、最初から選択しておくような試みをしました。さらに、設問の取捨選択においても、企業が欲しい情報を極力残しつつ、設問数を減らすという方針で取り組んでいます。

この登録フローの改訂を始める前と比較して、登録フローの突破率が約2倍になったんです。また、登録フローと直接関係があるかは定かではありませんが、効果があった試みとしてスワイプ型UIの導入を紹介したいです。これはマッチングアプリでよく使われるUIです。従来の画面では、ポジションカード右下に「気になる」というボタンがあり、求職者が興味のあるポジションを登録できるようになっています。

企画側の意向で、「気になる」の件数を増やしたいという要望がありました。これが応募につながるためです。ミイダスでは実験的にスワイプ型UIを導入し、その結果、非常に高い効果を見せました。そこで登録が完了した直後に全員をスワイプ型UIに遷移させ、「気になる」操作や詳細の閲覧がしやすいUIを提供しました。その結果、登録したばかりのユーザーに限っては、「気になる」の件数が約2倍に増えました。また気軽に「気になる」をしていいと理解されたためか、従来の画面での「気になる」件数も少し増え、大きな効果がありました。

以上で、登録フロー全般に関する発表を終えたいと思います。次のセッションでは、これらの内容の中からいくつかを選んで、さらに詳しい説明を行いたいと思います。

Nishiyaさん、ありがとうございました。ミイダスの登録フローは、試行錯誤の連続だったかもしれませんが、私たちの取り組みについて少しイメージを持っていただけたら幸いです。さて、Nishiyaさんが紹介してくれた通り、次に詳しい話に移りたいと思います。登録フローの改訂に関するバックエンドの詳細については、H.Sさんからの発表をお願いします。それでは、H.Sさん、よろしくお願いします

登録フロー改訂 - バックエンド - 

こんにちは、H.Sです。ミイダスでバックエンドを担当しているエンジニアです。本日はよろしくお願いします。

現在は採用機能の開発チームに所属し、この登録フローの開発に集中しています。システムエンジニアとして長い経験を持っていますが、このような大規模プロジェクトは今回が初めてです。日々、新しい発見があり、とても楽しい状況です。これまでPHPやJavaを主に扱ってきましたが、今回はGo言語を使用しています。Go言語に関しては、3年経ってようやく慣れてきた感じです。お酒が好きで、最近は社内の交流会も増えてきているのは嬉しいですね。Nishiyaさんが説明した内容に沿って、私からはバックエンドの視点で登録フローのプロジェクトについて説明させていただきます。

Nishiyaさんの説明とは異なる別の視点から、2つの案件を紹介します。一つは、メールアドレスの登録を登録フローの先頭に持ってきた時のことです。もう一つは、求職者に提供する情報の項目を追加した際の話になります。

開発体制の役割分担については、先程Nishiyaさんからの説明がありましたので、ここでは割愛します。登録フローのプロジェクトには、求職者が登録途中で離脱するという問題がありました。特に、市場価値診断の結果を見た後、満足してしまって離脱する方が多かったんです。私たちの目標は、より多くの求職者にミイダスを利用していただくことです。そのための一つの対策として、求職者にまず最初にメールアドレスを登録していただくことにしました。

変更前は、市場価値診断の結果がメールアドレス登録前に表示されていました。ランディングページから市場価値診断を行った後、多くのユーザーがそこで離脱してしまっていたんです。次の画面でメールアドレスを登録する段階になっても、多くが途中で離脱してしまう傾向がありました。市場価値診断の結果表示が、登録完了まで至らない大きな要因かもしれません。変更後は、まず最初にメールアドレスの登録を促す流れにしました。他のWEBアプリケーションでも、ユーザー登録から始まることが多いため、この流れには抵抗感が少ないと思われました。

もし最初に連絡先をいただければ、市場価値診断の結果を表示する前に離脱してしまう方々に対しても、「もうちょっと頑張ってみよう」というニュアンスの内容のメールを送ることが可能になります。これは新たなアプローチとして考えられ、開発に着手しました。途中で離脱した方々に対してメールでのフォローアップができるようになるのは、これまでになかったことです。この新しい試みに対する期待は大きかったです。開発においては、意外と設計面で既存の仕組みと合わせるのに苦労しました。特に、既存のユーザー登録の設計との整合性が問題でした。

登録フロー内で選択する一部項目がないと制約上登録できないという問題もありました。ユーザーテーブルは求職者の情報を保存するため非常に重要で、この問題を解決するために先輩方と相談しましたが、様々な意見があり、議論が活発になることもありました。この問題に対処するために、最初に登録したユーザーを「1次ユーザー」として別のテーブルで管理し、後で本ユーザーテーブルへ移行する設計を選択しました。この1次ユーザーテーブルから本ユーザーテーブルへの移行は、裏側でこっそりと行われるよう設計しました。この新しいシステムは、既存の機能とのバッティングがあり、その調整にはかなり苦労しました。

セッションの管理や、1次ユーザーテーブルと本ユーザーテーブルの管理を別々にする必要があったため、セッションの取り扱いにも細心の注意を払いました。実際にユーザーが本登録に至る際には、1次ユーザーから本登録へのセッションの受け渡しが必要で、ここにも気を配りました。この処理がうまくいかないと、登録完了後にユーザーが突然ログアウトされるなどの重大な問題が発生する可能性がありました。このような問題を回避するために、テストを入念に行いました。

しかし、1次ユーザーテーブルと本ユーザーテーブルでのメールアドレス情報の二重管理という新たな問題が発生しました。これはメールアドレスの変更や退会時の情報処理に影響を及ぼしました。この問題はリリース直前にテストチームによって発見され、修正してもらうと言った一幕もありました。

ミイダスの特徴として、メールアドレスを重複して登録できない設計になっています。今回の変更で1次ユーザー側と本ユーザー側でそれぞれメールアドレスを持つ必要が出てきて、これが二重化してしまいました。実装が想定以上に複雑になり、ユーザーがメールアドレスを変更した際に戻せなくなるなどの問題が発生しました。このため、かなりドタバタした状況でした。リリース後、実際に本登録達成率が大幅に落ちてしまい、約4割程度になりました。この結果を受けて、企画チームはメールアドレスの前倒しは失敗だったと判断し、翌週に元のシステムに戻すことが決定されました。この登録プロジェクトは大きな失敗でしたが、私にとっては大きな学びがあったと思っています。

また求職者の情報をより詳しく登録できるようにするプロジェクトに参加し、様々な取り組みを行いました。

例えば、運転免許の登録は「あり」「なし」のみでしたが、職種によってはマニュアル免許が必須であるため、オートマ限定の人が応募してしまうというマッチングミスが生じていました。これを解決するため、より細分化できるマスター項目を設定し、運転免許を「AUTO車限定」や「マニュアル車も運転可」といった形で拡張しました。同様に、TOEFLに関してはIBTとIPPという2種類が存在するにもかかわらず、登録できる範囲が4つに限られていたため、それを6つに拡張しました。また、大学の学生区分についても、元々30種類の区分がありましたが、存在する学部を再検討し、新たに6区分を追加するという変更を行いました。

最後に、専門学校区分というのがありまして、これは専門学校で教えている内容を登録するためのものでしたが、これまで存在しなかったため、新たに26区分を新設し、登録項目として追加しました。実際にどのような変化が起きたのかについては、画面を使って説明します。先ほどお話した自動車運転免許についての実際の登録画面では、求職者の画面には「AT車限定」と「MT車」という2つの項目が追加されました。

企業が求職者を検索する画面では、「あり」と表示されており、マニュアル免許を必須とするオプションがグレーアウトされています。この「あり」をクリックすると、マニュアル免許必須のオプションが活性化し、これにチェックを入れると、MT車が運転できる求職者として登録され、検索可能になります。マニュアル車を運転できる人は、AT車も運転できるという前提で実装されています。

TOEFLのIBDに関しては、右側の画面で、少しぼかしが入っていますが、6項目があることが何となくわかるようになっています。具体的な項目を画面に表示することは避けているため、このような形になっています。企業側の求職検索画面では、スコアに関する項目が1つ追加され、最大マスターの拡張が行われました。IAPの場合も、元々4項目から6項目への拡張が行われています。大学や大学院で学んだ内容を登録する区分に関しては、6項目が追加され、合計で36項目になりました。

画面に関しては細かい部分が多いですが、マッチングの精度を更に上げるため、企業側も利用できるような形になっていると思います。専門学校区分に関しては、これは新しいもので、今まで登録ができなかった内容です。専門学校で何を教えているかを求職者側に登録してもらい、専門学校卒の卒業生へのニーズが高まっている中で、具体的にどういう専門学校生であるかをより詳しくマッチングできるようになったと思います。

これらの項目を拡張したのは良いことですが、実際に利用されなければ意味がありません。そのため、求職者がログインした際に登録促進のポップアップを表示するように変更を加えました。例えば、免許「あり」と登録されていた求職者については、データマイグレーションで一時的に「AT車のみ」に変更していますが、MT車OKであるにも関わらず「AT車のみ」として登録が進んでしまうことがあるため、正しい情報を選んで再登録してもらうようにポップアップで案内しています。

このポップアップの表示・非表示は、一部のユーザーだけに限定されています。例えば、専門学校を卒業した求職者に対して、どのような学校だったかを専門学校区分として登録してもらうようお願いするものです。また、医療技術系や私立学校を卒業していて、これまでは医学部という選択肢のみだった方に対しても、改めて見直してもらうように促しています。その他学部を選択した人以外にも、このような細かいシナリオを考えて、特定のユーザーに対して表示するようにしています。

実際の実装で苦労した点についてなんですが、まずはマスター項目を追加するだけでは終わらないところです。ミイダスの中では求職者と企業っていうのはそれぞれDB的に独立しています。相手の情報っていうのも抱えているんですが、それはキャッシュとして抱えるようになっています。互いに追加や更新の情報をやり取りする為にAMAZONのSQSを使っているんですが、片側で更新された情報が相手側に正しく届くように気を使いました。求職者企業側ともに運転免許の構造が変わる形になってキャッシュの情報を大幅に更新しなければならないといった形で気を使っています。要は運転免許の有無を記載する配下に、AT車のみ、MT車も可、という2つの選択肢が追加されて、若干その構造が変わったという形になります。

全てのデータを洗い変えする形になるため、それについては結構な時間が掛かりました。小規模のアプリだと例えばそのマスター項目に新しい項目を追加するだけであれば、どうにかなるんですけれどもミイダスは実は結構大きいので、なるべく粗結合でアプリ同士を結ぼうという風な設計思想になっています。なのでお互いがお互いの情報を正しく更新できるように気を使いながら実装していきました。ポイントのその2です。市場価値診断・求職者検索サーバーの2つの存在というのがあります。対となるこの情報を扱うこれらの情報も正しく反映させる必要があります。要はこれらの2つというのはマイクロサーバー化されているんで、キャッシュを更新した上で、それを読み取らせなければいけないといったところで気を使う必要がありました。

市場価値診断サーバーについては、企業側の情報を持ちつつ、求職者側のアプリで使用されます。一方、求職者検索サーバーは求職者の情報を保持し、企業側で利用されるものです。これらの診断と検索機能は、先に言及したキャッシュを使用しています。

キャッシュが正常に更新されない場合、算出される結果に異常が生じる可能性があるため、これらの情報を適切に反映させる必要があります。つまり、マスター項目の登録や削除などの際には、予想外の要因を考慮しなければならない点が多く、これらの点に特に注意を払う必要があります。このような背景から、今回この話題を取り上げることにしました。

リリース後の影響に関しては、求職者側で多くの方が新しい項目を登録してくれているようです。特に運転免許の「MT車設定1」では、約58,000人の方がこの新しい設定に切り替えてくれました。また、学校区分と専門学校区分に関しても、約25,000人の方が新しい項目について登録していただいています。一方で、企業側については、新しく追加された項目を利用している企業はまだ少ないようです。企業が検索を行うための「ターゲット」機能を少し覗いてみたところ、新しい項目を見ている企業が少ないと感じています。これは、企業のポジションの属性によっても異なるため、新しい項目が良いことなのか悪いことなのかは一概に言えない状況です。ただし、新しい施策によって、企業側にもう少し設定をしてもらえるかもしれないと考えています。

少し長くなってしまいましたが、メールアドレスの前倒しや登録情報の拡張についてお話ししました。ありがとうございました。

H.Sさん、ありがとうございました。このマスター部分は、ミイダスにおいて他のサービスと比べても、詳細に登録できる点が優位な部分の一つです。時代の流れに応じて、この部分を増やしたり最適化したりすることをこれからも続けていくつもりです。また、大きな改訂があれば、このような場でお伝えできればと思っています。
それでは、次のリリース共有に移りたいと思います。続いては、MJMLの導入に関して、Sumiさんからの発表です。これはフロントエンドの保守チームで行われた施策です。ミイダスから企業様や求職者様へのメール配信に関して、大きな変更が行われましたので、その内容についてSumiさんがご紹介します。それでは、Sumiさん、よろしくお願いします。

MJML導入

Sumiと申します。現在、フロントエンドエンジニアとして保守チームに所属し、開発業務を行っています。

経歴としては、途中からエンジニアに転向し、WEBエンジニアとして従事しています。ミイダスには2021年に入社し、約2年半勤めていることになります。現在はフロントエンドエンジニアとして活動すると共に、新しく入社したフロントエンドのメンバーの受け入れ担当もしています。

導入の背景についてですが、先ほども少し触れられた通り、ミイダスでは求職者様や企業様向けに新しい仕事情報やメッセージの通知、新機能のPRなど、サービスを円滑に利用していただくためにHTMLメールの配信を行っています。その為、HTMLメールの新規作成や内容の見直し、修正が頻繁に行われています。しかし、この作業には時間と負担がかかることがあり、HTMLメールの実装にかかるコストや作業者の負担を軽減したいという背景がありました。HTMLメールはウェブとは異なり、異なるメールクライアントごとに表示が崩れることがあるため、それに対処する必要がありました。特に、ミイダスではOutlook系やAndoird系のメールクライアントにも対応するよう方針が決まっているので、表示の問題を解決するのは大変でした。

ウェブとは異なり、HTMLメールではモダンなCSSを使うことが難しく、テーブルレイアウトのHTMLメールが必須とされています。そのため、HTMLメールの修正時には適切なノウハウを見つけるのが難しかったり、苦戦することがありました。また、複数のメールクライアントを対象として確認作業を行う必要があるため、一つのメーラーで表示を修正しても、他のメーラーでの表示が崩れることがよくあり、これも負担となりました。そのため、シンプルなコーディングで表示の崩れを最小限に抑える開発環境の実現を目指し、MJMLというフレームワークの導入を決定しました。

開発の流れについては、昨年から技術選定とMJMLの調査を行いました。既存のフローに適合し、課題を解決できるかどうかを確認した後、HTMLメールのデザイン方針の見直しを行い、それに続いてABテストを実施しました。ABテストが終了した後、本格的に既存のメールをMJMLを使用したメールに移行する計画です。

役割分担については、多くの関係者が関与しました。開発の初期の予想以上に多くの影響範囲と関係者への相談が必要だったため、比較的長い期間を要しました。技術選定と事前調査に関しては、MJMLの導入はフロントエンドのエンジニアから提案されましたが、実際にMJMLを使用経験のあるメンバーが限られていたため、導入に関する懸念点も存在しました。

MJMLを実際に使用してみて、既存のHTMLよりも使いやすいかどうか、実際のコーディング体験を評価しました。HTMLメールのコーディングが複雑な理由について、特に2つの特徴に注目し、それに対するMJMLの効果を調査しました。

まず、テーブルレイアウトのタグ構成の複雑さが挙げられます。MJMLを使用することで、コンポーネントベースの構成を活用でき、複雑さが軽減されました。MJMLでは深いネストに対する制約があるため、インデントの深さに一部制限が生じましたが、全体として改善されました。

また、インラインCSSの記述量に関する検討も行いました。MJMLの利用により、共通のスタイルを定義し、出力時に自動的にインラインに組み込むことが可能となりました。これにより、スタイルの記述量を大幅に削減できました。参考画像をご覧いただくと、MJMLを使用したマークアップ（左側）とその出力結果（右側）が示されています。出力結果では、メールの崩れを防ぐために本来必要なコードが少なくなっていることが分かるでしょう。

その他に調査したこととしては、既存の実装フローやメールのデザインをMJMLで再現できるかどうかという点が挙げられます。具体的には、既存メールのデザインをMJMLで再現し、実装可能かどうかの調査を行いました。また、MJMLでコーディングした後に生成されるHTMLファイルを検証し、既存の実装フローと同様に対応できるかどうかも調査しました。

ただし、結果的にMJMLではデザインに制約があり、既存のデザインをそのまま再現できないことが判明し、デザイン方針の見直しやデザインデータの作り直しが必要となりました。一方、既存実装フローに関しては、バックエンドとの打ち合わせを経て、実装上の問題はないとの結論に至りました。コメントを挿入した箇所が勝手に消えるなどの懸念もありましたが、そのような事項は発生しませんでした。
表示崩れに対する懸念点も調査しました。多くのメーラーで表示が崩れないかを確認するために、メールの表示確認サービスを利用しました。結果として、MJMLが提供するコンポーネントを適切に使用すれば、表示崩れの問題はほぼ発生しないことが確認されました。

公式でこれはできないとされているものは除いてほぼ表示崩れは発生しなかったという感じです。ただし、デザインの制約と関連する部分では、MJMLが提供するコンポーネントを使用しない特定のデザインでは、生のHTMLを記述する必要があるため、表示崩れの懸念が存在しました。

既存のメールデザインをそのまま移植することが難しかったため、デザイナーと協力しながら新しいデザイン方針を策定しました。変更された主要な点は以下の3つです。まず、デザインの統一です。従来のメールでは、余白、文字サイズ、細かいサイズ感など、パソコンとスマートフォンで異なるデザインを表示するために細かく設定していました。しかし、MJMLではこのような出し分けは考慮されておらず、パソコンとスマートフォンでのデザインを統一する方針が採用されました。

2つ目は多層デザインの廃止です。これまでのメールデザインでは、1つのセクション内にさらに複数のコンテナがあり、その中にさらに項目ごとのコンテナが含まれるといった多層のデザインが一般的でした。しかし、MJMLではコンテナ内にさらにコンテナを入れるような多層構造は制限されており、この点を見直す必要がありました。その結果、基本的に多層的なデザインは採用しない方針となりました。

3つ目はメール全体のデザイン統一です。以前から類似したデザインが多く使用されていましたが、実際には微妙に異なる部分があることがありました。しかし、MJMLを使用する場合、ファイルをパーツごとに分割し、インクルードすることが可能で、またスタイル定義を別ファイルにすることもできるため、共通のデザインパーツを定義することが容易になりました。その結果、デザインに関してもスタイルガイドを作成し、厳密に共通化されたデザインを使用する方針に変更されました。デザイン方針が変わったことに伴い、既存のメールのデザインも一新されることになったため、これを企画サイドと共有しました。

移行する際にデザインの変更が必要になったため、ABテストを実施して、開封率やサイトへの流入率にどのような影響があるかを調査することが決定しました。具体的には、古いデザインと新しいデザインのメールをABテスト的に配信し、その結果を評価し、悪影響がないかどうかを確認しました。この結果、悪影響は見られなかったため、MJMLへの移行が正式に決定しました。

移行が正式に決定した後は、ユーザー側と企業側の両方に共通のヘッダーとフッターのようなデザインがあるので、これらの共通部分の実装を行いました。加えて、他のメンバーが作業を進める際のサンプルとして、第1弾のメールの移行が行われました。現在は、共通部分や第1弾のメールを参考にし、複数のメンバーが協力して、残りのHTMLメールの移行を進めています。実際の実装では、共通パーツの定義やスタイルの定義の共通化により、書きやすさと読みやすさが向上しました。また、崩れやすいメーラー、特にOutlookなどでも基本的に表示の崩れがないため、作業工数が削減され、実装者の負担が軽減されました。

今後、ミイダス内でさらに多くのメールを移行・実装する過程で知見を蓄積し、スピーディーな実装が可能になることを期待しています。日本国内外問わずHTMLメールの実装に悩む企業は多いと考えられるため、こうした技術が広まり、日本のユーザーにもこれらの知識が普及することを期待しています。

はい、Sumiさん、ありがとうございました。実際に現在も移行作業が進行中で、かなりの工数削減に寄与していると聞いています。Sumiさんもおっしゃった通り、国内での知識がまだ不足しているという現状もあるため、今回の発表が困っている方々のお役に立てればと考えています。Sumiさん、ありがとうございました。

こちらで現場のエンジニアからの発表は以上とさせていただきます。最後に、ミイダスニュースとして、2022年9月以降のミイダスの最新情報をいくつかご紹介し、クロージングに入りたいと思います。

MIIDAS NEWS

こちらの6つに関して、今回ご紹介させていただきます。左上から順にご説明していきます。まず、働く人ファーストアワードの開催に関してです。そもそもこの働く人ファーストアワードというものは、多様な働き方や働く人の声をしっかりと聞いて改善に努めることを大切にしている企業様を募りまして、その取り組みをご紹介したり、賞賛したりすることを目的に、ミイダスと朝日新聞社様の共同で開催するアワードです。ミイダスの働きがいサーベイというものがありますので、そちらを受けていただいて、その結果と各社の取り組みに応じて表彰を行っていくものです。
このアワードの応募は先日締め切りましたが、1227社という非常に多くの企業様にご参加いただきました。働く人ファーストアワードの詳細を知りたい方は、ご紹介のURLから詳細をご覧ください。

続いて、この働く人ファーストアワードの開催に伴い、2つの記事がリリースされています。一つは、富士通のCHROである平松様と、もう一つはテレビでもご活躍されているピアニストのハラミちゃんへのインタビュー記事です。この働く人ファーストアワードに関連して、様々な視点でお話をいただいていますので、こちらもぜひご覧いただければと思います。

では、働く人ファーストアワードに関して最後なんですけれども、このアワードについて、経済産業省からの後援がいただけることになりましたというニュースですね。こういった省庁の後援をいただくことは結構難しいと伺っておりまして、大変ありがたいとともにそのご期待に応えられるように、引き続きこのアワードを盛り上げていければと思います。
続いて4つ目ですね。ミイダスの交通広告の掲載に関してご紹介させていただきます。吊革広告が山手線、都営線、京王線、京王井の頭線で、今年の10月から来年の9月まで掲示されています。扉のステッカーはJR東日本、JR東海、大阪メトロ、JR西日本でも今年10月から来年3月まで掲示されています。もし、これらの路線を利用される方がいらっしゃれば、ぜひ探していただければと思います。

続いて9月29日金曜日に開催されたSRE NEXTにブロンズスポンサーとして参加しました。今回はランクがブロンズでしたので、ブースの出展やセッションは行いませんでしたが、私は実際に会場に足を運んで参加しました。この後で紹介する参加スポンサー企業のブース紹介記事などもありますので、興味がある方はぜひご覧いただければと思います。

最後に、こちらの5つの記事をリリースしました。左から新しい順になっています。1つ目はミイダスの社内勉強会レポートで、「ポストリモート時代のエンジニアの働き方とキャリア」というテーマです。10月に社外の方を迎えて社内勉強会を行いましたのでそのレポート記事です。

2つ目は「移住を見据えて知らない土地で仕事をする。ミイダスだからこそ実現できるワーケーションのスタイル」です。ミイダスは一定の条件を満たすことで、ワーケーションや自宅以外でのリモートワークが可能です。この制度を活用して、今回2名の移住体験者へのインタビュー記事をご紹介しています。

3つ目は、先程Sumiさんが発表されたMJML導入におけるメールデザインの効率化に関する記事です。こちらの記事でもご覧いただけますので、ぜひご確認ください。

また、SRE NEXT最速ブース紹介の記事もあります。最後に、前回のMIIDAS Tech LIVE vol.3のレポート記事があります。後ほど、これらの記事のURLをお送りいたします。

それでは、続いて現在のミイダスで募集中のポジションについてお知らせいたします。正社員として、バックエンドエンジニア、フロントエンドエンジニア、そして運用チームでのシステム運用のリーダーのポジションを募集しています。また、業務委託としては、フロントエンドエンジニアのポジションがあります。興味がある方は、ぜひご連絡いただければと思います。

イベントのアーカイブや記事に関する情報は、YouTubeやnoteで提供しております。また、イベントのお知らせについてはX(旧Twitter)やconnpassで行っていますので、今後のイベントに興味がある方は、それぞれのサービスをご覧いただければと思います。

以上で第4回のMIIDAS Tech LIVEを終了させていただきます。ご参加いただきました皆様、本当にありがとうございました。次回は2024年3月に開催予定ですので、またのご参加を心よりお待ちしております。それでは、こちらで失礼いたします。ありがとうございました。

ミイダス Techについて

ミイダスでは、定期的に技術イベントを開催しています。connpassやYouTubeチャンネルでミイダスのメンバーになった方には、最新の開催情報やアーカイブの公開情報が届きますのでぜひご登録をお願いいたします。

イベントページ：https://miidas-tech.connpass.com/
Twitter：https://twitter.com/miidas_tech

ミイダス Tech

ミイダス株式会社 エンジニア・デザイナー キャリア採用サイト｜ミイダス株式会社