こんにちは、SmartHR プロダクトエンジニアの chanMisa と ushiboy です。 この記事では、SmartHR に入社したフロントエンドエンジニアの視点から、日々の業務や取り組み、開発体験を通して感じたギャップや魅力をお伝えします。 共同執筆者である私たち 2 人の掛け合いを通して、よりリアルな開発現場の様子をお届けします。 SmartHR で働くフロントエンドエンジニアの仕事について参考になれば幸いです。
多様なチームとフロントエンドエンジニアの役割
SmartHR におけるチーム構成やフロントエンドエンジニアの役割について解説します。
チームの構成
SmartHR では、プロダクトや機能ごとにチームが編成され、各チームに 1 名～ 2 名程度のフロントエンドエンジニアが在籍しています。 チーム規模は様々で、新機能開発初期のチームではフロントエンドエンジニアが不在の場合もあります。 フロントエンドエンジニアの総数は 30 数名ほどです。
フロントエンドエンジニアの役割
SmartHR のフロントエンドエンジニアはフロントエンド開発が主な業務ですが、バックエンドのコードを書くこともあります。 これはチームによって異なり、フロントエンドとバックエンドを分担しているチームもあります。 フェーズや個々の得意不得意に応じて、柔軟に役割分担されています。
chanMisa: 前職はフロントエンドエンジニアが多かったのでチームの構成はギャップがありました！ 少ないぶん主体的に取り組んだり、バックエンドエンジニアに技術を伝えるなどの動きがあって面白いと感じます。
ushiboy: 前職では何人くらいのメンバーがフロントエンド担当だったのですか？
chanMisa: 7 名くらいで、フロントエンドとバックエンドが完全に分かれていました。
ushiboy: 私も前職はチームが完全に分かれていて、メンバー 4 人程度のフロントエンドチームに所属していました。 今はチームに 1 名のフロントエンドエンジニアとして在籍している状況なので、その点は私もギャップがありますね。 チーム内でフロントエンドのコードもバックエンドのコードも相互にレビューしているので、知見の共有ができたりプロダクトコードに対しての理解が深まっていると思います。
chanMisa: プロダクトコードに対しての理解も深まりましたし、プロダクトそのものに対して解像度が高くいられるなと感じますよね。
開発環境・ライブラリなどの技術スタック
SmartHR で採用されている開発環境と主要な技術スタックについて解説します。
開発環境と技術スタック
SmartHR では、React と TypeScript を主要な技術スタックとして採用しています。 多くのプロダクトでは Next.js を採用しており、Pages Router または App Router を使っています。 テスト環境には Storybook、Playwright、vitest、jest などを活用し、E2E テストや VRT（Visual Regression Testing）なども積極的に行っています。 パッケージマネージャーは pnpm が主流になりつつあります。 スタイルについては、styled-components や tailwind CSS が利用されています。
各プロダクトで利用しているライブラリを比較するスプレッドシートがあり、他チームの状況を可視化し、技術選定の参考にすることができます。
chanMisa: テストの整備とかに（もちろん実装スピードとの天秤もありますが）しっかりとコミットできているのがすごいなと思います。 renovate や dependabot などを活用し、ちゃんとライブラリのアップデートを行っていっているのも良いなと感じます。
ushiboy: ライブラリのアップデート対応が早いですよね。 前職よりもたくさんの他チームのリポジトリやライブラリの状況を横断的に参照して実装や設計を参考にできるので、インプットし放題だなと感じています。 Storybook は VRT だけでなくヘルプページ用の画像取得のための活用などがあり、利用が活発だなと感じます。
chanMisa: VRT をヘルプページの画像取得に使おうという発想がすごいですよね……！ いろんな経験をされている方が集まっているからこそかなと感じました。
ushiboy: 古くからあるプロダクトでは React ではない画面もありますが、それらを React 化するプロジェクトが動いていて技術的負債の解消にも前向きだなと思います。
チーム横断の情報共有とアクセシビリティへの取り組み
SmartHR では、チームを横断した情報共有や協調的な開発体制が整備されています。
フロントエンド定例会と「フロントエンドこれだけはやっておけリスト」
週に一度、チームを横断したフロントエンドエンジニアの定例会を開催しています。 このミーティングでは、業務で得た知見の共有、技術的な課題の相談、モブプログラミングなどが行われます。 新しいプロダクトや取り組みで得られた知見は、この定例会で共有され、既存プロダクトのアップデートに繋がるなど、SmartHR 全体の技術向上に貢献しています。
「フロントエンドこれだけはやっておけリスト」と呼ばれるチェックリストがあり、各プロダクトの対応状況を共有し、定例会でリストの見直しも行っています。 このリストには、セキュリティ、パフォーマンス、アクセシビリティなど、フロントエンド開発において重要な項目が網羅されています。
技術顧問である koba04 さんにも相談できる体制が整っており、技術的な課題解決に役立っています。
chanMisa: 前職ではプロダクト横断の知見共有などがあまりなかったので、SmartHR で横断の共有やそれによる各プロダクトでの追随などができているのはすごいなと感じてます。 プロダクトが個々で独立しているのにある程度揃っているのは、共通で設定しておいた方がいい項目がこのような場でちゃんと共有されたり、共通で使えるようにパッケージ化されたりしているからだなと感じます。
ushiboy: 同じく前職ではチームを跨いだ知見共有は機会が少なかったので、定例ミーティングのおかげで頻度も多く横の連携が取れている感じがあります。 チェックリストの更新がボトムアップで行われるのも良い文化だと思います。 知見の共有や共通化の取り組みは活発な印象がありますね。最近印象に残ったものってありますか？
chanMisa: 私は最近新しいプロダクトを開発していて、VRT を導入しようとなった時にすでに VRT を実行できる GitHub Actions が共有されていて、サッと VRT を準備することができました。VRT のスナップショット数を抑えるための仕組みも入っているので無駄にコストをかけないようになっているのも良いなと感じています。
ushiboy: 私もチームのプロダクトに VRT いれるのに参考になりました！スナップショット数はコストに直接影響出るので良い仕組みでしたね。
アクセシビリティへの取り組み
定期的にアクセシビリティエンジニアとのミーティングを実施し、各プロダクトのアクセシビリティ対応状況を共有しています。 アクセシビリティエンジニアがプロダクトについてチェックしてくれる取り組みがあります。 各プロダクトには「アクセシビリティマスター」と呼ばれる担当者がおり、アクセシビリティの活動に取り組んでいます。 アクセシビリティ相談の Slack チャンネルがあり、そこで気軽にアクセシビリティについて相談できます。
chanMisa: アクセシビリティにプロダクト初期から取り組めるのはアクセシビリティエンジニアの働きや SmartHR の方針あってこそだなと感じます。
ushiboy: 前職ではアクセシビリティの考慮はできていなかったので、積極的にしっかりと取り組めている（やっているだけでなくて水準も高い）のはすごいなと感じています。 先日担当プロダクトにアクセシビリティチェックを行ってもらい、結果の共有で色々知見をいただけて良かったです。
chanMisa: 私もデザイン段階でもアクセシビリティチェックをしてもらい、デザイン上の致命的な問題がないか早めに見てもらえたので、安心して開発に入れました。 古いプロダクトでも少しずつメンバーがアクセシビリティの改善を進めていて素晴らしいなと感じます！
開発体験
SmartHR では、開発効率の向上とコード品質の維持に繋がる様々なツールや仕組みが整備されています。
SmartHR UI
SmartHR では、OSS として公開している UI ライブラリ（smarthr-ui）を使用しています。 このライブラリは有志のエンジニアとデザイナーによって開発・保守されており、アクセシビリティにも配慮した設計となっています。 一般的な UI コンポーネントであれば、このライブラリを利用するだけで、アクセシビリティやデザインガイドラインに準拠した開発を行うことができます。 まるでレゴブロックのようにコンポーネントを組み合わせて開発を進められるため、開発効率が大幅に向上しています。 このライブラリは活発に更新されており、ここ半年でバージョン 56 から 65 にアップデートされています。
ESLint
ESLint のルールは継続的に整備されており、ルールを遵守するだけで、アクセシビリティやデザインシステムのガイドラインに沿ったベストプラクティスを適用できます。 これも開発効率の向上とコード品質の維持に大きく貢献しています。
ボイラープレート
新規プロダクト開発時に、同じような設定や構成を毎回 1 から構築する必要がないよう、ボイラープレートが整備されています。 これは、フロントエンドとバックエンドの有志メンバーによって開発・保守されており、プロダクトの迅速な立ち上げを可能にしています。
プロダクトの多言語化対応については、現在の仕組みやプロダクトごとの対応による差異に課題感があり、ボトムアップのプロジェクトとして共通化し、ボイラープレートに追加する取り組みが進んでいます。
ushiboy: smarthr-ui とデザインシステムが共に公開されていることは入社前から知っていましたが、実際に利用する側に回って恩恵が多いなと思っています。 自分の担当している画面が比較的簡単なものであるというのもありますが、ガイドラインに従ってコンポーネントを置いていくだけである程度のところまで組み立てられています。 有志による開発が活発なことと実際に各プロダクトで利用されていることで、進化が速いのかなと思います。
chanMisa: コンポーネントを置くだけでアクセシビリティにも考慮した画面が作れるのはすごいですよね！このような取り組みもメンバー発案だったりするのでボトムアップで活動に取り組める環境だなぁと感じます。 ESLint ではかなりアクセシビリティ周りのチェックが入っているので「気づかずにアクセシビリティの低いものを作ってしまった！」というのが防げていて助かっています。
ushiboy: ESLint のルールがどんどん追加される文化もすごいですね。
chanMisa: 仕組みで解決しようという動きがすごいですよね。私も何かあったときは仕組みに落とし込めないか考えて開発していきたいです。
まとめ
この記事では、SmartHR に入社したフロントエンドエンジニアの視点から、日々の業務や取り組み、開発体験を通して感じたギャップや魅力について紹介しました。 SmartHR での働き方についてリアルに感じていただけましたでしょうか？各詳細については以前のブログで紹介していたりもしますので、ぜひ読んでみてください。
- Visual Regression Test を導入して、手間と時間を節約した話
- アクセシビリティを担保するために ESLint の独自ルールを作っている話
- SmartHR のフロントエンドの技術的変遷 ── 技術顧問の koba04 と語るこれまでとこれから
- エンジニアが挑戦できる、SmartHR のアクセシビリティへの取り組み
- jQuery を使ったレガシー画面の React 化
- SmartHR UI の 2024 年を振り返る
SmartHR ではこんな環境で働いてみたいな！という方を募集しています！！WE ARE HIRING！！
