【入社エントリ】13年目のベテランエンジニアから見たHRBrainは、開発体験がとても良い👍️会社だった件
はじめに
株式会社HRBrainの鈴木 泰斗です。2024年8月より株式会社HRBrainにJoinし、バックエンドエンジニアをしております。
入社して約半年経ち、社内の仕組みやチームの文化も理解できるようになり、視野が広がってきたと感じています。
ということで、本記事は入社エントリーとなります。自己紹介と半年間で実感したHRBrainの開発体験の良さ👍️をご紹介したいと思います。バックエンドエンジニア視点ですが悪しからず…
自己紹介
経歴
新卒から7年間は大手でサーバー運用とデータエンジニア(Hadoopとか分散処理システムとか)をしてました。オンプレミスのサーバーの保守、監視、構成管理、ETLシステムを開発していました。
この頃(2018年ぐらい)からAWSやGoogle Cloudといったクラウドインフラを使って個人開発を始めました。「なんだ、個人でもWebサービス作れるじゃん」という自信(過信？)から、Webサービス全体を見渡せる立場で仕事をしたいと思うようになりました。大手では難しかったため、Webアプリケーションエンジニアとして、50名ほどのベンチャー企業へ転職しました。
そこから6年間は役割に縛られずにWebアプリケーションエンジニアとして働いてきました。バックエンドを主軸にクラウドインフラ、SREあたりを見つつ、必要であればフロントエンドを書く要員として、必要であればチームをリードする立場として、広く浅い経験を積み重ねてきています。
HRBrain入社まで
HRBrainへ入社する前は、困りごと解決おじさん(職歴10年エンジニア)として、開発チームをリード(？)する立場で仕事をしていました。期日に向けてチーム一丸となって頑張る毎日は刺激的で楽しいと思う反面、What(何を作るか)やHow(どう作るか)について、しっかりと考える機会は少なく、Webアプリケーションエンジニアとしては少し物足りない日々が続いていました。
ということで、転職活動を進めていたのですが、はじめのうちはBtoB向けのSaaSで絞り込んでおり、SaaSがHR領域であるかどうかはあまり気していませんでした。面接などで説明を聞くうちに、いまHR業界が伸び盛りでありHRBrainとしてもプロダクトを増やして組織を大きくしていくフェーズと聞き、なんか面白そう、と思ったことが入社への大きなキッカケでした。
入社後やったこと
入社直後はHRBrainタレントマネジメントの開発保守運用に携わりました。現在、主には組織診断サーベイを開発保守運用するチームに所属しています。会社も順調に大きくなっており、忙しい日々楽しい日々を送っています。
タレントマネジメントと組織診断サーベイで必要とされるドメイン知識やアーキテクチャ特性は、けっこう違ってたりします。この違いには四苦八苦させられることもありますが、良いコラボレーションをするためにはどういったアーキテクチャにすればよいか？を正解がない中で考えるという意味では、面白さもある部分だと思います。
HRBrainに来てから、プロダクト開発知識周りについての学びの量は半端なく多いです。マルチテナントのSaaSを支えるバックエンド、プラットフォーム周りの濃ゆい技術的な積み重ねを日々体感しております！
HRBrainの開発体験の良さ👍️
堅苦しい自己紹介は忘れて半年間で実感していることは、HRBrainの開発体験の良さ👍️です。これを少しご紹介し、本記事を締めたいと思います。バックエンドエンジニア視点からHRBrainの雰囲気を少しでも伝えることができれば幸いです。
モノレポ👍️
HRBrainのプロダクトのソースコードは1つのレポジトリで管理されています。プロダクト数が40に近い現状において、このモノレポ構成はとても合理的です。むしろもしマルチレポジトリだったら現在の生産性は出せていないのではないか？と思います。
自分的には、後述する開発体験の良さ👍️の多くは、このモノレポ構成の恩恵によるものであると思っています(いくつかの開発体験の良さ👍️は、モノレポ構成じゃなかったら実現できなかったと思われます)
ディレクトリ構成が似てる👍️
プロダクト毎のディレクトリ構成が似通っていることです。どこに何が保存してあるのか？の見通しが効くようになるため、「他チームのソースコードのこの部分を参考にする」といったことが容易にできます。
ディレクトリ構成のチラ見せ
ほとんどのプロダクトで app/、front/、schema/ というディレクトリは存在しており、それぞれのディレクトリにはBackend、Frontend、OpenAPIのYAMLファイルが保存されています。
# レポジトリのルートには、プロダクト間で共通して利用される設定ファイルがあります
Tiltfile
dockercompose-tilt.yaml
# "hoge"、"fuga" はプロダクト名
# appsディレクトリ配下にプロダクト毎のソースコードがあります
apps/
apps/hoge
apps/fuga
apps/foo
apps/bar
...
# プロダクト毎のディレクトリが、更に分割されています
apps/hoge
apps/hoge/app # Backend(主にGo. go.modなど)
apps/hoge/front # Frontend(主にReact. package.jsonなど)
apps/hoge/schema # OpenAPI yamlファイル
# プロダクトによっては上記以外のディレクトリがあったりもしますさらにBackend(app/配下)のディレクトリ構成も似通っています。
apps/hoge/app/go.mod
# apps/hoge/app/cmd/
# ディレクトリ配下にAPIサーバー、マイグレーションプログラムのソースコードがあります
apps/hoge/app/cmd/migration/
apps/hoge/app/cmd/grpc/
apps/hoge/app/cmd/http/
...
# apps/hoge/app/batch/
# ディレクトリ配下にバッチ処理のソースコードがあります
# バッチ処理のソースコードがcmdディレクトリ配下にないのは謎...歴史的経緯?
apps/hoge/app/batch/rotate/
apps/hoge/app/batch/refresh-view/
apps/hoge/app/batch/trigger/
...
# Goのソースコードは大体こんな感じのディレクトリ構成です
# (実際には、名前にゆらぎがあったり(infrastructuresがinfraだったり)
# internalディレクトリ配下にあったりなかったりといった
# 細かい差異はあります...)
apps/hoge/app/domain/
apps/hoge/app/usecases/
apps/hoge/app/libs/
apps/hoge/app/handlers/
apps/hoge/app/infrastructures/自動デプロイ👍️
本番リリース作業は、モノレポのGitHub Actionを実行し、Slackへ通知される承認ボタンを押下するだけです。デプロイ後の本番環境での動作確認以外に手動による作業はありません。デプロイへのハードルがとても小さいので、小さな改善を適用し易い点が嬉しいです。
プロダクト毎に独立した開発を可能とするアーキテクチャ👍️
プロダクトは基本的にはサービスベースアーキテクチャを採用しています。プロダクト間のソースコードの依存関係、デプロイの依存関係はほぼありません(一部、テナントの基本的な情報を保持しているプロダクトだけが他プロダクトとの依存関係を持ちます)。
これによりそれぞれのチームが独立して開発案件を進めることができるようになっています。1週間で様々なプロダクトの機能が次々(一昨日はタレントマネジメント、昨日は人事評価、今日は組織診断サーベイのリリース、、、明日はなんだろう？)にリリースされています。
Tiltによる、ローカル開発環境構築の手順👍️
新しいチームへ所属直後、憂鬱になる一大イベントといえば「ローカル開発環境の構築」ですが、HRBrainのローカル開発環境の構築は簡単です。下記のコマンドを実行するだけだからです。
# "hoge" はプロダクト名
# プロダクトとは、社員名簿、組織診断サーベイ...などを指します
# 外部へ公開していないプライベートなプロダクト(所謂マイクロサービス)も
# 基本的に、プロダクトごとに1つの`tilt up`コマンドを実行します
tilt up hoge
# 複数のサービスを同時並行でローカル環境上に立ち上げることも可能です
tilt up hoge fugaTiltというローカル環境のコンテナ管理ツールを用いることで実現されています。ローカル環境の設定はGitHub上のTiltfileとDockerfileによってコード化されているため、環境の透明性が非常に高く保守性にも優れています。
Tiltについては過去の記事でも紹介されています。
Google Cloud Workstationsによる、リモート開発環境構築の手順👍️
ローカル開発環境上で複数のコンテナを立ち上げるとPCのリソースを圧迫し、PCが重くなるという問題があります。HRBrainの1つのプロダクトをローカルで起動するためには、そのプロダクト自体の他にいくつかのプロダクト(外部へ公開していないプライベートなプロダクト。例えば、認証や認可機構を担うプロダクトなど)を起動する必要があるためです。
でも大丈夫。なんとHRBrainでは、ローカル開発環境をリモートで稼働させられるようになっているのです！これによりリモートのリソースを利用して開発を進めることができるため、PCが重くなるという問題からは解消されます。
しかも、HRBrainの全エンジニアが容易にこの機構を利用できます。社内のPlatformチームへ「リモートマシンの準備」をしてもらうだけです（それ以外は、前述の「Tiltによる、ローカル開発環境構築の手順」とほぼ同じ）。一人も取り残すことなく良い開発体験を実現するぞ！という徹底ぶりが凄いです。
この取り組みについては過去の記事でも紹介されています。
最近、弊社CTOがModern Apps Summit ’25にて、この取り組みについて発表しています。
ブランチデプロイ環境👍️
GitHubのPullRequestにて /deploy とコメントすると、PR環境へのデプロイが開始されます。PR環境とはPullRequest毎に作られる開発環境です。1つのプロダクトにおいて複数の開発を同時並行で進めながら、開発環境を奪い合うことなくGoogle Cloud上において動作確認を進めることができます。
ブランチデプロイについては過去の記事でも紹介されています。
↑の「👍️」がほぼ全プロダクトで共通している👍️
ここまで開発体験の良さ👍️を紹介しましたが、HRBrainでは👍️が部分的にではなく、ほぼ全プロダクトに対して適用されています。これは凄いと思います。
最後に
どうでしょう？刺さる開発体験の良さ👍️はありましたでしょうか？HRBrainの雰囲気伝わりましたでしょうか？
少しでも興味を持ってもらえたら、ぜひカジュアルにお話しましょう！ ということで
We're hiring!
株式会社HRBrainでは、一緒に働く仲間を募集しています！
興味を持っていただいた方はぜひ弊社の採用ページをご確認ください！
HRBrain文化を一緒に作っていきましょう！
https://www.hrbrain.co.jp/recruit/
最後まで読んでいただきありがとうございました！
