Sansan Tech Blog

Sansanのものづくりを支えるメンバーの技術やデザイン、プロダクトマネジメントの情報を発信

Vol.10 Bill Oneのフロントエンドを通じて学ぶモダンフロントエンド技術入門

Bill One 連載 フロントエンド

こんにちは。技術本部Bill One Engineering Unitの豊田（@helloyuki）です。Bill One 開発 Unit ブログリレー2024 Vol.10、Sansan Advent Calendar 25日目の記事です。実は1pxの微妙な画面上のズレが気になって仕方のないタイプです。

私自身はこれまでのキャリアでは、ほとんどバックエンドエンジニアとして過ごしてきました。正確にはバックエンドを主軸としつつ、多少のフロントエンド、クラウドインフラの構築、データエンジニアリングの経験も含みます。それぞれの領域に詳しい詳しくないは多少ありつつ、世間的にいうフルサイクルエンジニアとしてのキャリアを歩んできました。

Bill Oneでは各チームに配属後、ソフトウェアエンジニアは基本的にはフロントエンド、バックエンド、インフラ関係なく、すべての領域の開発を一通り担当します。私も最近機能開発チームに配属となったので、ご多分に漏れずすべての領域を一通り担当しています。

私自身にとっては、フロントエンド開発に本格的に参加したのは初めてのことでした。今までは管理画面に少し毛の生えた程度のものを実装したり、趣味で利用したりがほとんどであったため、業務中にフロントエンド開発を本格的に行ったのは初めての経験です。

バックエンドエンジニアがフロントエンド開発に参加すると、知らない概念や未知のツールとたくさん出会うことになります。今回は、私の理解の整理もかねて、そうした「未知との出会い」を記録しておきつつ、Bill Oneのフロントエンド開発の理解が深まるような構成で記事をお届けします。

目次

前提

技術の選ばれ方に関する記事を書くと、「こういう選択肢がある」という話があがりがちです。しかし、技術の選定というのはそもそも「その時点の、その組織におけるベスト」であり、何かのトレードオフを選び取った結果です。また、過去の技術選定を今現在という時間軸から論じる場合、時間の経過という問題もあります。この辺りを整理するために、簡単にBill Oneの前提をおさらいしておきます。

Bill Oneは、2019年ごろから開発を開始した請求書受領SaaSをメインとするプロダクトです。過去何回かモデルチェンジならぬピボットを行っており、うち1回はそもそもコードベースを丸ごと破棄しています。私が今開発しているBill Oneは、このコードベース破棄後のものになります。

開発組織体制においては、先ほども説明した通りマイクロサービス単位に分かれたチームが、フロントエンド、バックエンド、インフラ問わずオールラウンドに開発するスタイルをとっています。なので、必ずしもフロントエンドのエキスパートがチーム内にいるとは限りません。もちろんBill One全体で見れば、フロントエンドのエキスパートは何人かいます。

開発には数十名の日本のエンジニアと、さらに数十名のSGDC（Sansan Global Development Center, Inc.）と呼ばれるフィリピンの拠点に所属するエンジニアが参加しています。海外側のエンジニアが素早く開発に新規参画できるのは、開発スピードを高める上でひとつの重要なファクターになり得ます。英語でドキュメントを用意する必要がありますし、Bill Oneの画面それ自体も英語対応している必要があるというわけです。余談ですが、私自身はSGDC側のチームに所属しています。

加えて、時間経過というのはこの記事を読む上では重要なファクターになります。2024年現在からするとたしかに別の新しいプラクティスが開発され、そちらを利用した方が明らかに結果がよい場合もありえます。しかし、開発開始当時にそれらの多くはありませんでした。このあたりの歴史的経緯に関しては、以前同じくBill One Engineering Unitのチーフアーキテクトを務める加藤が2020年にまとめた記事があります。

言語、フレームワーク、付随するライブラリやツール

TypeScript

いつの間にやらフロントエンド開発で見ない日はなくなりましたが、TypeScriptを利用しています。

TypeScriptの場合、エディタを比較的自由に選択できる点がいいところだと思います。チーム的にはVS Codeの利用が推奨されてはいますが、私自身はNeovimやZedといったエディタで開発を試してみています。

React

Bill OneではReactを使ってフロントエンド開発が進められています。Next.jsは使用していません。が、実は以前は利用していました。移行の経緯はこの記事にまとめられています。また、社内にはADRがありその記録によると、SSRしたときに発生するいくつかの不可解な現象に苦しめられたものの、SSRを利用したい積極的な理由がとくに見当たらなかったことなどが記載されていました。

Semantic UI (React)

Semantic UI ReactはいわゆるUIコンポーネントライブラリです。これを利用することにより、フロントエンド開発のスピードを高めることができます。UIコンポーネントライブラリを利用すると、ある程度きれいにデザインされたコンポーネントを少ない手間暇で呼び出しできるようになります。とくに、バックエンドエンジニアがフロントエンドのコードも書くという環境下においては、この手軽さが生産性担保の鍵になります。これにより、CSSへの深い知識を要求せずともそれなりのクオリティのUIを構築できるというのが大きなメリットになりうるでしょうか。

Bill Oneは元々Material UIで画面を構築していましたが、ある一定のタイミングからSemantic UI Reactに切り替えています。切り替えのタイミングでのその他の選択肢はMaterial UIの続行やAnt Designなどもあったようですが、日本語での情報量などの観点からSemantic UI Reactが選ばれました。

ただ、社内のADRのふりかえりによると、2020年ごろ行われたこの選択自体はあまり成功だったとは思っていないようです。というのもSemantic UI Reactそれ自体のメンテナンスが現在は停滞気味なように見えるからです。アクセシビリティ面でも弱めと感じることは多いらしく、この辺りも今後の採用は難しいと考えているポイントのようです。

Bill One内部では現在、後述するOne UIコンポーネントに置き換えていく作業をしています。

Lingui

Linguiはいわゆる国際化対応（i18n）を行うためのライブラリです。Bill Oneはグローバル展開を目指していますし、また開発時に海外の開発者も参画していることなどから、画面の国際化対応は必須になっています。

Linguiの魅力の1つは、日本語メッセージをそのままJSXに記述できる点です。裏でこれをキーとして、翻訳先の言語に切り替えてくれる機能を持っています。翻訳先の言語側で翻訳文言を設定していれば、ほとんど何も意識せず切り替えします。

翻訳文言の管理はLokaliseというツールを利用しています。Lokaliseは翻訳文言の管理に特化したツールです。翻訳文言をGoogleスプレッドシートで管理している企業は多いかもしれませんが、Bill Oneは近年規模が爆発的に大きくなっているプロダクトなため、管理する文言も非常に膨大な数に及んでいます。

Lokaliseを利用すると、開発者は基本的に開発中に翻訳文言について意識することなく開発を進めることができます。Bill Oneは国内向けのプロダクトなので日本語をメインとしてフロントエンド側は実装されていますが、日本語から英語への翻訳はグローバル対応のために必要です。この翻訳作業はGitHub Actionsを通じて行われます。そのため、開発していても翻訳について意識することはほとんどないです。

pnpm

pnpmは、npmが抱えていたいくつかの課題を解消したツールです。Performant NPMの略称から来ているように、インストールが高速であったり、同じパッケージは繰り返し保存せずにプロジェクト間で共有させることにより、ストレージ利用が効率的であったりします。

元々Bill Oneではnpmを使用していましたが、今年に入りpnpmへ更改されました。

リンターやフォーマッター

最後にリンターやフォーマッターについておさらいしておきましょう。Bill Oneでは現状、ESLintをリンターとして使用しています。また、フォーマッターにはPrettierを利用しています。他のプロダクトでもこのような構成をとっているものは多いでしょう。

一方で、リンターやフォーマッターは別のいい乗り換え先があれば、乗り換える予定ではあります。とくにCIにかかる時間がそろそろ気になり始めています。この辺りは、Biomeをそもそも導入してしまうと劇的な改善を見込めるのではないかと考えています。

ただ、Biomeは現状ESLintのプラグイン部分にあまり対応していないなど、リンター側では乗り換えが難しい状況です。一方で、CIの時間でまずまず大きなウェイトを占めるのはPrettierの実行時間です。加え、PrettierのBiomeへの置き換えはすぐに作業を終了できそうです。そのため、まずPrettierからBiomeに変えてしまう可能性は十分にありえます。

開発手法やそれに類するツール

Atomic Design

Atomic Designとはコンポーネントの設計手法の1つです。フロントエンド開発をしていると、画面の中で「このコンポーネントは他の画面でも使いまわせるな」ということに気づく瞬間が幾度となく現れます。いわゆるコンポーネントを切る単位の認識を揃えておくと、その分開発効率の向上につながります。

Atomic Designでは、コンポーネントをAtoms、Molecules、Organisms、Templates、Pagesという単位に分けます。

Atomsは最も小さいコンポーネントです。代表的な単位としては、ボタンやテキスト、アイコンなどの最小単位のものをAtomsとして扱わせることが多いでしょう。

Moleculesは2つ以上のAtomsから構成されます。1つの単位として動作しうる最も単純なコンポーネントのグループです。代表的なものには、入力フォーム、ナビゲーション、カードなどがあります。

Organismsは、MoleculesないしはAtomsから構成されます。いくつかコンポーネントが複合的に組み合わされ、画面がどのように見えるかが決まり始めます。いわゆるヘッダーやフッターの実装、あるいは複数カードを管理するグリッドなどがあります。

Templatesは、複数のOrganismsの集合です。この辺りからいわゆるレイアウトが決まり始めます。ヘッダー、メイン、フッターを組み合わせたテンプレートがあります。

最後にPagesです。テンプレートに具体的な値を流し込み、コンポーネントを描画させます。最終的な成果物となる1ページ1ページがこれにあたります。

Bill Oneでは、Atomic Designの思想を反映したようなディレクトリ構成をしています。

アプリケーションが大規模化する中で課題になるAtomic Designの要素間の依存の治安の維持は、依存関係をチェックするリンターのルールを活用して今のところは乗り切っています。ただこのリンターは最近導入されたこともあり、導入時に一旦アノテーションをつけて回避している箇所があります。私自身も開発中に見つけては地道に依存関係を整理するパッチを投げてはいますが、まだまだ理想状態には遠いかもしれません。地道な努力が必要です。

Atomic Designについては次のサイトも参考になります。

ちなみにフロントエンドのエキスパートやチーフアーキテクトに聞いてみたところ、Atomic Designそれ自体は粒度の認識合わせが難しかったようです。また、再利用可能なコンポーネントのメンテナンスが難しいという問題点もあるとのことでした。私もどう切ったらいいかわからないなと思う場面は結構多いです。近年は、feature（機能）単位でUI・モデル・APIを切り分ける手法が使われるようになりつつあるようです。

Storybook

Bill Oneに入って初めて本格的に利用しているツールです。名前自体は知っていたのですが、具体的に何をするものかについては、使い始めるまではあまり知りませんでした。

Storybookは一言で言うと「UIカタログ」を閲覧できるツールです。自身の実装するアプリケーションで使用されるコンポーネントを、カタログをパラパラめくって見るかのように確認できます。

実務上のメリットとしては、コンポーネントのカタログ閲覧の他に、UIコンポーネントとページを切り離し、独立した状態でコンポーネントの開発を行えるというものがあります。フロントエンド開発をしていると、たとえば実はまだ実装中の部分のバックエンドが用意されていないことがあります。また、バックエンドからのレスポンスとは独立して、フロントエンド側でさまざまなデータパターンでの表示方法を制御してみたいというような気持ちになることがあります。こうした要望に答えるツールです。

私も開発中に実際、Storybookに何度かお世話になっています。特定のページの特定の箇所のコンポーネントを確認するには、フロントエンドのアプリケーションをローカルで立ち上げ、実際にコンポーネントを見にいくという方法が考えられます。あるいは、特定の条件下で特別な振る舞いをするコンポーネントを見たい場合には、その振る舞いになるようデータを投入したり、画面操作を何度かして再現させる必要が出てきます。ここには、バックエンド側のアプリケーションを立ち上げたり、データを投入して振る舞いを確認したりする手間が発生しています。

Storybookを使えば、Storybookを立ち上げて手軽にコンポーネントの表示を確認したり、コンポーネントの振る舞いを確認したりできます。データはモック用のライブラリであるMock Service Worker (msw) を用いてモックを用意しています。また、特定の条件下での振る舞いについては、Storybookは実装時に「どのような画面操作をするか」を定義しておくことができます。いわゆるレコーディングされたかのように、開くたびにその操作をし、コンポーネントの振る舞いを手軽に確認できます。便利です。

Bill Oneでは、Storybookに加えて後述するVisual Regression Testと呼ばれるテストが導入されています。Storybookの状況に応じて見た目に対するデグレードが起きていないかをCIで確認できるようになっています。

VRT

VRTはVisual Regression Testingの略です。私も初めてこの概念を知ったのですが、ツールを組み合わせると、なんと画面の表示崩れなどをある程度リグレッションテストできます。アプリケーションの画面を画像として保存しておき、画像同士の差分比較をすることにより、意図しない変更が混入していないかを確認するテスト方法です。

Bill OneではChromaticというツールを用いてこのVRTを実施しています。ChromaticのチェックではStorybookが利用されます。Storybookで定義したカタログを元に、Chromaticが差分検知をする仕組みとなっています。

Bill OneにおけるVRTの詳しい導入の経緯は、次の記事にまとまっています。この記事が書かれてから概ね1年くらい経ったのですが、コストは相変わらず悩みの種です。いくつかのコスト最適化施策を打って対応してきました。一方でVRTを活用したいために、不安な箇所はPages以外のコツコツ小さな粒度のコンポーネントのStorybookを追加しています。Chromaticのおかげで、Storybookを活用した開発手法の浸透は確かに進んでいると言えるかもしれません。

デザインシステム

フロントエンドエンジニアのみなさんの議論を見ていると時折登場する「デザインシステム」という単語は、なんとなくは知っていました。最近ではデジタル庁がデザインシステムを公開したことで話題になっていたことを思い出します。調べてみると、実はデジタル庁に限らず多くの会社がデザインシステムを公開していることに気づきます。目につく限りでは、たとえば次のような団体や企業がデザインシステムを公開しているようです。

弊社も公開しています。

Bill OneではOne UIコンポーネントと呼ばれるライブラリ群を自前で用意しており、これらを呼び出すことでデザインシステムに従った画面を実装できるように、仕組みづくりをしています。

元々Bill Oneでは、先述したSemantic UI Reactを使ってコンポーネントを設計し、実装・構築していました。この部分は置き換えを進めています。新しいコンポーネントではできるだけOne UIコンポーネントを使って実装したり、あるいはBill One全体の横断的な施策としてOne UIコンポーネントへの置き換えを実施しています。このように、デザインシステムで定義されたコンポーネントに置き換えていく作業が今後行われる予定です。

最後に

「未知との出会い」は、最初は当たり前ですが大変ではありました。もともと多少なりともフロントエンド開発の経験があったので、ライブラリ間の微妙な違いの差を把握すれば開発それ自体には追いつくことができました。しかしたとえば運用のことを考える場面において、StorybookやVRTなど多くの概念やツールに対するキャッチアップが必要になりました。

しかし、フロントエンド技術へのキャッチアップは我々にとっては義務なのではないかと思うのです。

請求書に関連するSaaSのプロダクトは、他の選択肢が多いです。いわゆる競合となるプロダクトが多い中で、「ユーザーの方にとって使いやすいUI」を維持し続けることは、競争優位性の担保につながります。使いにくいプロダクトからは簡単にユーザーは離脱します。今は選択肢が多いですからね。昔サイバーエージェントの藤田社長がインタビューの中で答えていたのを思い出しますが、最高のUIやユーザー体験を持つプロダクトが、これまで世界を席巻してきました。同じことはやはり、SaaSプロダクトであっても当てはまると思うのです。

そうした「使いやすさ」の競争優位性を担保するために、フロントエンド技術への積極的なキャッチアップは今後も欠かせないでしょう。今やBill Oneにはデザイナーも参画しています。彼らと会話していると日夜ユーザー体験と使いやすさ、わかりやすさを最大限考慮したデザインが上がってきます。フロントエンド技術へのキャッチアップとその適用や運用は、デザイナーの考案するコンセプトを最大限すばやく反映し切るために重要なことのように私の目には映っています。すばやく開発できればその分反映できるデザイナーの意図も増えます。

もう少し詳しい話を聞きたくなった方はぜひ、カジュアル面談でBill Oneのフロントエンドについてお尋ねください。カジュアル面談は下記よりご応募いただけます。

また、今後のBill One開発Unitブログリレー2024の更新情報は、引き続きXアカウント@SansanTechにて発信しています。ぜひフォローの上、今後の更新をお楽しみに！

© Sansan, Inc.