こんにちは、エンジニアの nabeliwo です。
先日リリースされたカスタム社員名簿ではフロントエンドと BFF 層の開発を担当しました。かなりサクサク動くので機会がありましたらぜひ触ってみてください！
さて、表題の通りですがフロントエンドエンジニアの募集を始めました。
本記事ではその経緯について書いていきたいと思います。
僕が入社するまでのフロントエンド
SmartHR は2015年2月に開発が始まったプロダクトです。今ではたくさんの機能を備えている大きなサービスですが、リリース当時は行政手続きの簡略化に特化した機能のみを提供しており、全体の画面の8割以上が入力フォームや一覧画面でした。
この画像はSmartHR 2019年全社キックオフ資料からの抜粋ですが、3年間でどれくらいの機能が追加されたのかを物語ってくれています。
当時のサービスの価値はバックエンドのビジネスロジックがもたらすものに寄っており、フロントエンドも Ruby on Rails に乗っかったフォーム用ライブラリや jQuery に強く依存していたため、モダンなフロントエンド技術に追従しない代わりにバックエンド寄りのエンジニアが中心でも画面を作るのに困らない、という状態で3年ほどはやってきていました。 そのせいもあり、フロントエンドエンジニアの採用もレガシー / モダン両方のフロントエンド技術に精通していながら、バックエンド寄りのロジックを触ることに抵抗のない人物が対象という業界的にはかなり狭き門となっていました。
その結果、開発メンバーの専門性の比率はバックエンド 8:1 フロントエンドまで偏っている状態が続いていたところに、ようやく2人目のフロントエンドエンジニアとして入社したのが僕でした。
これまでの SmartHR のフロントエンド
僕が SmartHR に入社した2018年1月時点では、僕たちが「SmartHR 本体」と呼んでいるプロジェクトのフロントエンドを1人目のフロントエンドエンジニアである atsushim が、Rails のエコシステムからようやく切り離し終えたところでした。
入社した直後の僕がフロントエンドエンジニアとして最初に気になったのは、我々にとって非常に親しみのある Bootstrap 製のUI でした。
Bootstrap はフロントエンドの知識がなくても画面を爆速で作ることができる素晴らしいライブラリですが、以下の理由によりフロントエンドエンジニアや UI デザイナーからは疎まれがちです。
- 他のサービスと比較して UI が均一になり独自性が出せない
- いわゆる Bootstrap ぽさのため、ブランディングに影響することも
- Bootstrap の枠から外れる UI を作る際にカオスになりやすい
- 実際に独自のスタイル内で Bootstrap を打ち消す
!importantが多用されてたりしました
- 実際に独自のスタイル内で Bootstrap を打ち消す
- jQuery に依存している
- JS 側をモダン化して jQuery 部分をなくすことができても Bootstrap のためだけに jQuery を残しておかないといけない状態になってしまう
UI はサービスの価値(使い勝手など)や、ユーザからの親しみやすさ、ブランディングに直結する部分なので、 HR テクノロジーを牽引するプロダクトとして、ここは変えていかなければならないと強く思いました。
実際にいくつか手を入れてみたのですが、コードに触れる中でどんどん別の問題が見え始め、考えていた以上に重労働であることに気づいてしまいました。 DOM に食い込んでくる gem の存在、構造が見えない深さにネストされた Haml、影響範囲が見えない CSS や DOM に状態を預けた jQuery の処理など、それらの深淵を前に一度は手が止まってしまいました。
ところで弊社には SmartHR というプロダクトの他に SmartHR の従業員 DB を利用して開発・提供される SmartHR Plus アプリ というものがあります。
https://mag.smarthr.jp/guide/vision/detail/smarthr_2019kickoff_serizawa/
SmartHR Plus アプリは SmartHR のデータを「本体」の備える API 経由で利用するだけなので、既存のコードベースに依存せずにゼロベースでプロジェクトを立ち上げることができます。
そのプラスアプリの1つに昨年リリースされたオンライン雇用契約という機能があります。
巨大すぎる「本体」のコードベースからは一旦退却して、いつか同じような問題を抱えることになりそうなオンライン雇用契約を大きくしていきながらも細かく改善していくことで、あるべき姿の基準を作りたいと考えました。
こちらは特に問題なく改修が進み、 Sprockets の切り離し、TypeScript の導入、React の導入、 Storybook によるコンポーネント管理を行うことができました。
その資産を流用してさらに新しく作られた3つのプラスアプリはオンライン雇用契約プロジェクトで培われたノウハウを流用していずれも React + Redux による SPA で作られています。
さらに各プラスアプリケーションで共通で利用できるコンポーネントを smarthr-ui として切り出して今後の新規アプリケーションを高速で作るための準備が整いました。
また、まさに今計画が立ち上がった所ではありますが、2018年末に入社してくれたばかりの頼もしいデザイナー陣と共に、SmartHR のデザインシステムの構築やアクセシビリティ対応もやっていくぞというところです。
ここまでが現状の SmartHR のフロントエンドです。
プラスアプリのバックエンドは API 化されフロントエンドは Rails から切り離され、改善サイクルを早く回すことができる状態になりました。
しかし、プラスアプリが綺麗かつ快適になったことで、ユーザ目線でも開発者目線でも「本体」の負債が目に見えて浮き彫りとなってきました。
これからのフロントエンド
プラスアプリを土台としてスモールスタートがうまくいき、フロントエンド改善への道のりがある程度見えたところで、一度断念した「本体」のフロントエンド改善に本腰を入れて改修する機運が高まってきています。
具体的な改修案として、部分的に smarthr-ui のコンポーネントを入れて React 化する手法で最初に挙げた負債を少しずつ無くしていくやり方も検討しましたが、今回僕たちは フルリプレイス を選択することにしました。
バックエンドを含むプロダクトの技術指針として、本体の機能をマイクロサービス的に順次切り出してプラスアプリ化することで「本体」の持つ機能を従業員 DB だけが残るように削いでいき、メンテナンス性やコードベースを小さくしていく計画があります。そして、まさに今「本体」の機能の中で1番大きい機能をプラスアプリ化するプロジェクトが走り始めようとしています。
コードベースが巨大であるが故に一度断念した「本体」の改修も、適切なサイズで切り出すことに成功すれば、プラスアプリと同じスタックでフロントエンドを作り直すことはそこまで難易度の高い改修ではないと考えています。
更にその先の未来の展望を語るならば、「本体」の改修が完了した後に smarthr-ui を社外に向けてメジャーリリースすることで、SmartHR の備える API と smarthr-ui を使用して誰でも SmartHR の従業員 DB を利用したアプリケーションを簡単に作ることのできる世界観が実現できると考えています！
募集始めました！！！！
理想を語りましたが、フルリプレイスをすると言っても既存の機能改修や新機能開発を止めることはできないし、新しいプラスアプリの開発も始まっています。
現状4人しかいないフロントエンドエンジニアではとてもリソースが足りません…。
ということで募集します！！
フルリプレイス大好きとかでかいアプリケーションの運用大好きとか新規アプリケーション作るの大好きとか大歓迎です！
希望を聞いて適切なプロジェクトをお願いさせていただきます！
一緒に戦ってくれるフロントエンドエンジニアがあと5人はいたら嬉しいなという気持ちでおります！
詳細はこちら。
フロントエンドエンジニア募集ページ
とりあえず雰囲気を知りたいという方はカジュアル面談も体験入社もありますのでご活用ください🙏
SmartHR は現在2万社以上の企業に導入されています。そしてカスタム社員名簿を筆頭に、労務担当者だけでなく従業員にも利用されるアプリケーションへと進化しています。
面倒なバックオフィス業務に苦労する労務担当者はもちろん、年末調整や入社手続きなどの労務周りの煩雑な手続きに悩む従業員も、 SmartHR によって救うことができます。つまり SmartHR の UI/UX を改善することは2万社以上の企業の従業員の体験を変えることに直結します。
そんな社会へのインパクトの大きい事業を自らの手でスケールさせていきたい熱い思いのあるエンジニアを求めています。
ぜひご応募お待ちしております！
