はじめに
こんにちは!Frontendチームの薄羽です。イタンジはRubyKaigiのスポンサーになるなど、Rubyに力を入れている会社だと思われていますが、実はフロントエンドも頑張っています!そこで、頑張りをみなさんに知ってもらうために、今回は「Frontendチームが取り組んでいること16選」を紹介します!
Frontendチームとは
イタンジのFrontendチームにはエンジニアとデザイナーが所属しており、「プロダクトUIを横断的に見ること」を目的としています。エンジニアはプロダクトUIを構築するコードとそれを守るテスト自体の品質管理、デザイナーはUXも含めたプロダクトのデザインを頑張っています。横断的に見る組織であるため、プロダクト開発自体はあまりしていません。
取り組んでいること16選
今回は各概要のみを紹介し、今後のテックブログで詳細に紹介します!
- テックブログの執筆
- デザインシステムの開発
- UIデザイン
- npmパッケージの開発
- Figmaプラグイン
- Backport
- コーディングルールの制定
- 技術検証
- イタンジフロントエンドラジオ
- コードレビュー
- E2Eテストの運用
- プロダクト開発
- 依存パッケージの更新
- セキュリティアップデートのアナウンス
- design2code
- 採用
1. テックブログの執筆
今月からテックブログの執筆を頑張ります。Frontendチームで行っている取り組みの中から個別の事例をピックアップして紹介していきます。また、後述するイタンジフロントエンドラジオで使っている原稿を「Frontendチームが今月気になったフロントエンドニュース」として紹介しようと思っています。
ちなみに、過去記事はこちらです:
2. デザインシステムの開発
デザイナーと協業してデザインシステムの開発をしています。デザイナーはスペーシングやレイアウトなどデザインシステムの基礎となるところから、どういったコンポーネントがプロダクトに必要かを考え、それをFigmaのコンポーネントやVariablesにしています。エンジニアはそれをReactのコンポーネントにしたり、後述するFigmaプラグインでFigma VariablesをTypeScriptのオブジェクトとしてexportしたりしています。イタンジには複数のプロダクトがあり、それらが横断的に使われるため、プロダクト間でUI/UXを統一することはかなり重要です。それをデザインシステムによって可能にしています。

3. UIデザイン
デザイナーは、上記のデザインシステムを使い、プロダクトのUIデザインを作成します。依頼の粒度は様々で、「フォームに要素を1つ追加したい」から「こことここの画面を丸っと変えたい」まであります。デザインシステムがあるものの、プロダクトのすべての画面がデザインシステムに沿っているわけではありません。そのため、今後の機能開発をしやすくするためや、体験の統一のためにデザインシステムを使って定期的にリプレイスしています。
4. npmパッケージの開発
最初はデザインシステムをReactコンポーネントにしたものだけだったのですが、今は itandi-frontend というモノレポになり、パッケージは5つも存在します!ざっくり以下です:
- プロダクトUI用のコンポーネントパッケージ(
itandi-bb-ui) - ブランディング用のコンポーネントパッケージ
- TSConfig / ESLint / Biomeの標準設定
- TypeScriptで使える便利関数群
- コンポーネントライブラリを安全に簡単に触れるPlaywright用のパッケージ

5. Figmaプラグイン
エンタープライズプランではないため、Variables関連のREST APIが使えません…。そのため、Figmaプラグインを作成し、VariablesをTypeScriptのオブジェクトにしています。また、Figma内のコンポーネントのラベルを校閲するプラグインを絶賛開発中です。
6. Backport
itandi-bb-ui にはCurrentバージョンとMaintenanceバージョンが存在します。プロダクトにクリティカルに影響を与えるバグが見つかった場合は、Maintenanceバージョンへbackportもしています。正直大変なのですが、ここを頑張ることでバージョンを上げやすくなっています。また、リリースフローは結構頑張っていると思うため、そのうちテックブログで紹介します。
7. コーディングルールの制定
ESLintとBiomeの設定をパッケージにしているものの、すべてを考慮できるわけではありません。また、コンポーネントの型だけでコンポーネントの使い方を守らせられるわけではありません(事情によってReactNodeになっていたり、このコンポーネントはこのコンポーネントの中で使ってくださいとかがあります)。そのため、ESLintとBiomeとは別にコーディングルールを設けています。ただ、コーディングルールを覚えて守ってもらうのはかなり大変です。なので、ルールをSkillにし(セマンティック itandi-bb-ui などが存在します)、VSCodeのCopilotから呼び出せるようにしています。
8. 技術検証
itandi-frontend では、積極的に新しい技術を試しています!たとえば、最初は単一のパッケージのみを管理していたためYarn v1だったのですが、モノレポにするときにv4にし、Workspacesも導入しました。ただ、使いたい機能がいくつか欠けていたため現在はpnpm workspacesを使っています。他にも速いと評判だったので bun test を使ってみたり、PrettierをBiomeにしたりしました。itandi-frontendで使ってみて、良かったものはプロダクトに還元する、というサイクルになっています。
9. イタンジフロントエンドラジオ
月1回、「イタンジフロントエンドラジオ」を薄羽、西野の2人で収録し、社内のみに展開しています。内容は今月個人的に気になったフロントエンドニュース(と言いつつ、Node.jsとかの話もしますが)やプロダクトで使えそうな技術紹介、React、Next.js、社内npmパッケージのアップデートの解説をしています。イタンジのエンジニアはバックエンドは得意ですがフロントエンドはちょっと苦手…という方が多いです。また、プロダクト開発をしながらフロントエンドの情報を追い続けるというのも難しいと思っています。そこで、「イタンジのフロントエンドを底上げしたい!」という思いから「イタンジフロントエンドラジオ」を始めました。それなりに好評だと思っています。

10. コードレビュー
半分以上のプロダクトのフロントエンドのソースコードはFrontendチームがコードレビューに入っています。プロダクトのロジックなどは深く確認しませんが、Reactの書き方だったりパッケージの使い方だったりを主にレビューしています。2026年2月は300件以上レビューしていたようです!
11. E2Eテストの運用
こちらの記事でも紹介しましたが、itandi-qc というモノレポがあり、そこのworkspaceの1つとして itandi-e2e があります。その運用をしています(E2Eテスト自体を書いているのは、プロダクトのエンジニアです)。詳しくは記事を見てください!
12. プロダクト開発
数は多くないですが、Frontendチームがプロダクトの画面を作ることもあります。プロダクト開発チームのリソースがひっ迫しているときに我々が速攻で納品します。
13. 依存パッケージの更新
こちらも数はあまり多くないですが、依存パッケージのアップデートや不要なパッケージを削除したりしています。itandi-bb-ui のコンポーネントは機能も種類もかなり充実してきているため、他のReactのパッケージを使わずに itandi-bb-ui のみで書けることがそれなりにあります。そういうときに itandi-bb-ui に置き換えることで不要なパッケージを削除します。
14. セキュリティアップデートのアナウンス
記事を書いているときもちょうどありましたが、Node.jsや依存パッケージにセキュリティアップデートがあった場合に、各プロダクトへの影響を調査し、対応方法をアナウンスしています。直近でもう1つ大きかったのは(プロダクトへの影響はほぼなかったですが)RSC周りのNext.jsのアップデートですね。
15. design2code
FigmaをそのままReactのコードにしたいですよね?それです、Skillにしました。セマンティック itandi-bb-ui やコーディングルールに基づきつつ、FigmaファイルをReactにします。FigmaとHTMLで仕様が若干違うところがあるのですが、それも吸収するようにしています。
16. 採用
そんなFrontendチームですが、絶賛採用中です!カジュアル面談もお待ちしています!