【2024年11月】今月の行動指針

こんにちは、エンジニアの内山です。ちょっと前まで半袖でいた気がするのですが、急に寒くなってきましたね。今は完全防備です。

11月はCocodaさん主催のイベントにデザイナーの戸谷さんが登壇しました!国内初のセキュリティ評価プラットフォームサービスというブランドを、どのように創っているのか、試行錯誤についてお話ししました。 connpass.com

また、1/8(水)にもCrossRelさん主催のイベントに戸谷さんが新規事業創りにおける「チャレンジ」についてLT登壇する予定です。 https://dezazome2025.peatix.com/

それでは、今月も行動指針を振り返っていきたいと思います。

楽しもうアドベンチャーメンター制度始めました (内山x日下)

先月、QAエンジニアの日下さんが新たにジョインしたのですが、スプリントの振り返りの際に日下さんからいくつか疑問点が上がってきたのと、僕達も日下さんが困っていることをキャッチアップできていないという課題が上がってきました。

僕がジョインした時を振り返ってみると、僕がScala未経験だったこともあり、1日30分でAssuredのコードを理解できるぐらいのScalaを学ぶという「Daily Scala」という取り組みをやっていました。この時間の中でScalaを勉強しつつ、日頃のちょっとした疑問や困りごとも気軽に解決できていたので、いい取り組みだったなということを思い出しました。

Daily Scalaの内容

そこで、試験的にメンター制度を始めてみることにしました。ここでいうメンターは以下の役割を指しています。

  • 日頃のちょっとした疑問や相談を気軽に話せる窓口
  • 情報やナレッジのインデックス
  • 人とのハブ

具体的には毎日30分時間を押さえて、その日のあったお困り事や疑問点を一緒に振り返り、メンターは必要な情報へのアクセスを手助けしたり、ナレッジを持った人との橋渡しをしています。

他にもドキュメントの整備が追いついていないなど、まだまだ課題はありますが、今後ジョインする方がスムーズにチームや組織に馴染めるよう、オンボーディング体制を整えていきたいと思います。

学びのティーチャーフロントエンド刷新の挑戦 (杉山)

Assuredでフロントエンドを担当している杉山です。

参画した当初からフロントエンド刷新の話は出ており、私の一つのミッションでした。

従来のAssuredの画面は、クラウドサービス利用企業様向け(client-web)・提供企業様向け(provider-web)・管理画面(admin-web)とあり、管理画面ではMaterial UI (以下、MUI)を、その他の画面では独自で作成したコンポーネントを使用して画面を構成してました。しかし、異なるUIライブラリを使用していたために、改修の際に開発者が混乱する場面が多く、特にMUIの利用がパフォーマンス上の課題を引き起こしていました。

今回のフロントエンド刷新の最終目的は、UIライブラリを新しく作成し、アプリ間で同じコンポーネントを使用して実装の一貫性を確保すること。同時にパフォーマンス改善を目指して、クラウドサービス利用企業様向け(client-web)・提供企業様向け(provider-web)で使用しているUIコンポーネントをEmotionから”ゼロランタイムのCSS-in-JS”に移行することです。

ゼロランタイムのCSS-in-JSとは、CSS-in-JSのアプローチにおいて、スタイルをインラインで定義する方法の一つです。 通常のCSS-in-JSライブラリ(例えばStyled-componentsやEmotionなど)は、スタイルをコンポーネントに適用する際にランタイムでJavaScriptを使ってスタイルを生成・注入するプロセスがあります。対して「ゼロランタイムのCSS-in-JS」は、スタイルがビルド時に静的に生成され、ランタイムのパフォーマンスコストを回避できるのが特徴です。 スタイルの定義や適用がランタイムで行われるのではなく、ビルドプロセスの段階で事前に計算・最適化されるため、実行時のJavaScriptの処理がほとんど発生しません。これにより、アプリケーションのパフォーマンスが向上し、特に初回のロード時間が短縮されます。

具体的には下記のような利点があります。

  • パフォーマンス: ランタイムでのCSS生成や変更が不要なため、アプリケーションのパフォーマンスが向上する。特にモバイルデバイスでの負荷が軽減される
  • 簡単なデバッグ: CSSが事前に静的に生成されるため、デバッグ時にスタイルを追いやすくなる
  • 小さなバンドルサイズ: 余分なJavaScriptを排除するため、最終的なバンドルサイズが小さくなる

上記の点を踏まえて選定をした結果、今回は”PandaCSS”を採用しました。 panda-css.com

自身が初めて行ったADRの提案から約半年刷新の第一段階として元々admin-webで使用していたMUIを廃止し、新たにPandaCSSを使って作成したUIコンポーネントを反映。デザインも、クラウドサービス利用企業様向けや提供企業様向けの画面に合わせてデザインを変更しました。

旧画面

新画面

まだ、クラウドサービス利用企業様向け(client-web)・提供企業様向け(provider-web)にも同じコンポーネントを使用して修正していかなければならないという課題も残っておりますが、管理画面の刷新は完了することができました。

今後も引き続き上記の改修を行なっていくとともに、パフォーマンスの向上や、フロントエンド改善を図っていき、Assuredの技術基盤の更なる進化を目指していきます!

未踏へのチャレンジャーメールの仕様をスナップショットテストとして生成する仕組みを作った (岩松)

Assuredでは様々なタイミングでシステムからメールを送信しているのですが、プロダクトの成長に伴い送信タイミングや送信先、条件が複雑化し、全容を把握しにくくなっていました。これによりお客様へ過剰に連絡してしまい、ご迷惑をおかけするケースもありました。そこで、この状況を改善すべくシステムメールのドキュメントを整理してみました。

今回の目的はシステムメールの仕様を俯瞰的に理解し、改善していくことなのでドキュメント化という手段を選びましたが、ドキュメントは管理されず陳腐化していくものです。システムメールの全容を把握したいというニーズも定常的に発生し得るので、更新され続ける仕組みにできないかと考えました。幸い、Assured開発チームでは

  • メール送信時に必要な情報は構造体(Scalaで言えば case class )にまとめるようにしている
  • ユニットテストを書く習慣がある
  • 開発者は要求(ユーザーは〜をしたい)単位で開発を進めているため、実装者が要件、仕様に一番詳しい

という状態だったため、Jestに代表されるスナップショットテストを参考に、ユニットテスト実行時にシステムメールの仕様をスナップショットとして生成するテストコードを用意し、開発者がテストコードを管理する仕組みにしました。

全体の流れは以下のようになっています。

flowchart LR
  Developer1(("開発者"))-->|変更を反映|UT1
  Developer1-->UT2
  Developer2(("開発者"))-->UT2
  Developer3(("開発者"))-->UT3
  UT1["ユニットテスト"]-->|自動作成|YAML1
  UT2["ユニットテスト"]-->YAML2
  UT3["ユニットテスト"]-->YAML3
  subgraph GA["Github Actions"]
    YAML1["YAML"]
    YAML2["YAML"]
    YAML3["YAML"]
    Spreadsheet
    YAML1-->|リリースごとに更新|Spreadsheet
      YAML2-->Spreadsheet
      YAML3-->Spreadsheet
  end
  Spreadsheet-->Reader(("開発者以外のメンバー"))

まず、システムメールを送信するバックエンド処理のユニットテストとしてそれぞれスナップショットテストを書けるようにしています。

"snapshot" in {
  import MailSnapshot._
  generate(
    mail = MailExample( // メール送信に必要な情報がまとまったClass (共通のtraitをMixin済)
      ...
    ),
    tos = Seq(Target.Admin.MailingList), // 誰に送信するか
    sendBy = "スナップショットを作成", // いつ送信するか
    canOptout = true // メールをオプトアウト可能か
    note = "XXXの場合、送信しない" // その他備考など
  )
}

このテストが実行されると以下のようなYAMLファイルがコードベースに追加されます。

module: "ADMIN"
name: "MAIL_EXAMPLE"
sendBy: "スナップショットを作成"
note: "XXXの場合、送信しない"
canOptout: true
subject: "[Assured] メールサンプルだよ"
from: "noreply@assured.jp"
fromName: "Assured"
to: 
  - "[Admin] メーリングリスト"
content: |
  このメールはAssuredのシステムから自動配信されています。このメールに返信はできません。
  -----------------------------------------------------------------------
  
  <企業名>
  <性> <名>様
  
  こんにちは!こんにちは!
  システムからメールを送るサンプルコードだよ。詳しくは以下URLを御覧ください。
  
  <URL>

これをシステムメール仕様のスナップショットとして保存し、リリースごとにこれらを集約したドキュメント(Spreadsheet)を更新しています。

どんなメールがいつ、誰に送信されているか俯瞰できるようにしています

現状Assuredで運用されているシステムメールはすべて表現しきれたので、これからメールの内容も改善していけたらと思います!今回のソリューションはあらゆる環境でも導入出来るものではないと思いますが、ドキュメント整理の参考になれば幸いです。

おわりに

今回は改善系のお話が多かったのですが、改善といえばエンジニアの岩松さんが出社日にオフィス周辺のキッチンカーの情報をSlackに投稿するボットを作ってくれました。いつも、今日は何を買いにいこうかなーとWebサイトを見ていましたが、ボットができてから今日はこれを買いに行くと即断できるようになりました!

スクショを取るためにライトモードにしたら眩しい、、!

最後に、私たちと一緒にプロダクトづくりを共にして下さる仲間を募集しています! 今回のブログを読んで、少しでも興味を持ってくださった方は、ぜひ採用情報をご覧ください。 careers.assured.jp