こんにちは！SmartHR でエンジニア採用担当をしている @mana です。以前、「SmartHRのセールス職についてエージェント説明会を実施したら好評だったので内容を公開します」という記事を公開しました。とても好評だったため、エンジニア編もお届けしようと思います！
今回は、下記3つのトークテーマで説明会を実施しました。SmartHR のエンジニアについて深く知っていただける情報が盛りだくさんです。少しでも興味がある方は、読んでいただけると嬉しいです。
- 「ここがすごいよ SmartHR」
- 「今だから面白い！SmartHR の魅力」
- 「SmartHR っぽい人ってどんな人？」
※エージェントさまが質問し、エンジニア（VP of Engineering 森住 / マネージャー陣）が回答する構成です。
トークテーマ(1) ここがすごいよ SmartHR
Q. どんな風に開発効率性をあげていますか？
主に2つあり、チームやプロダクトの分割と、技術スタックの統一です。
チームやプロダクトの分割ですが、SmartHR では比較的早い段階でプロダクトを分割しました。基本機能では従業員データベースとしての機能にフォーカスし、集まったデータの活用はオプション機能に任せるように分割したことで、コードベースが過剰に大きくなることを防ぎ、キャッチアップの大変さや技術的負債が溜まりにくい状況を作れました。
また、プロダクトの分割に合わせて開発チームも分割しているのですが、各チームに裁量を持たせることでチーム単位で新しい機能を考えて開発できる状況を作りました。少人数で素早く意思決定して素早く開発する土台となっていると考えています。
技術スタックに関して、SmartHR では Rails と React といった基本的な組み合わせは統一して開発を行っています。技術スタックを統一することで社内で知見を活かすことが可能となったり、共通機能を社内ライブラリとして共通化でき、いわゆる車輪の再発明を防ぎながら開発を進められるようになっています。
統一しているとは言っても、例えばフロントエンドのフレームワークは jQuery から React に移行していたり、最近では Next.js を導入していたりと常に最適なものを模索して少しずつカイゼンも行っています。
Q. どこまで現場で意思決定できるのでしょうか？どれくらいの期間で決められていますか？
ほぼすべてチームで意思決定をしています。
例えば先述したフロントエンドのフレームワーク変更に関して、知見が必要な場合は社内で広く情報を集め、チームの垣根を越えてメリット・デメリットを検討します。
しかし、集まった情報をもとに最終的にどうするかはチームが決めています。これは、フレームワークの検討という広義のメリット・デメリットだけではわからない、チーム単位の状況などを加味しているということもあります。
一方で、プロダクトによっては全体で目線を揃える必要も出てきます。例えば、基本機能の場合はプロダクトの規模もチームの規模も大きくなってきます。基本的にはチーム主導で決めているものの、最終的にはユーザーにとっての価値をベースに意思決定しています。
各チームの目標が局所最適にならないように、最終的なロードマップをどうするかは全社的に目線を揃えて定めていますが、役員や VP からの「こうしろ」という鶴の一声で何かが決まることは聞いたことがありません。
Q. 最速で開発したエピソードはどんなものですか？
当時、プロダクトマネージャー 兼 プロダクトエンジニアをやっていたメンバーが3ヶ月くらいで従業員サーベイ機能をリリースしたことがあります。
通常プロダクトマネージャーとプロダクトエンジニアは別々にアサインされるのですが、プロダクトマネージャーの業務内容に興味を持っていたエンジニアが兼務という形で担当しました。
「極力小さくリリースすること」「細かく仕様を詰めすぎないこと」を意識して開発していたと聞いており、コードも書けて仕様も自分で考えられる兼務の強みが出たエピソードなのかなと思っています。誰もが真似できることではないと思いますが、SmartHR が推進しているクロスファンクショナルを地で行った話だと考えています。
参考情報
- 最速で届け、ユーザーから学ぶ。チーム学習を鍵に創る新規プロダクト - SmartHR Tech Blog
- SmartHRにおけるクロスファンクショナル実践例 - SmartHR Tech Blog
- クロスファンクショナルを勘違いしていたよ - SmartHR Tech Blog
Q. 開発効率を上げるために、取り組んでいることはなんですか？
例えば、有料のエディタで開発効率が上がるならば、会社でライセンス費用を負担することを選択します。GitHub Copilot も早々に導入しています。現場のエンジニアがプライベートで試した結果を共有してくれて、「開発効率が爆発的に上がるため、早急に導入しないとイチエンジニアとしても会社としても世間においていかれる」と声をあげてくれました。
マネージャーと VP の決裁で導入に向けた意思決定はできるので、やりたいことに対して、ブレーキがかかることはほとんどありません。
Q. 意思決定の早さは会社のカルチャー？社長が元 CTO だから？
会社のカルチャーです。
創業者の宮田さんが「100の問題を、100人で1問ずつ解く」という考え方を大切にしてきたことから SmartHR にはそういったカルチャーが染み付いており、現場が意思決定できるように情報をオープンにしています。マネージャーしか知らない情報はあんまりないと思います。
参考情報
Q. 意思決定が早いことによって、周りのプロダクトに影響はないのでしょうか？
もちろん、影響はゼロではありません。
基本機能は認可や従業員DBとして他のオプション機能から使われているため、大きな変更が入る際は影響がないか相談したり実装時期を調整したりしています。ただし、APIを介した疎結合な設計になっているため、そこまで大変な調整は発生せずに開発できていると思います。
Q. SmartHR のキャリアに関する考え方について聞いてみたいです。
SmartHR のカルチャーとして、キャリアに対する柔軟さ・寛容さがあります。マネジメント、スペシャリストのどちらの道でもキャリア / 給与をあげられる環境が整っています。かつ、一度選択したら戻れないこともなく、一度マネジメントをしてみたがやはり開発をメインにしたいということでメンバー（スペシャリスト）に戻った人もいます。
また、他職能へのチャレンジにも寛容で、実際にエンジニアからプロダクトマネージャーにジョブチェンジをして挑戦しているメンバーもいます。
エンジニア組織では、クロスファンクションを目指しています。他の職能に興味・関心があれば手を伸ばせたり、自分のキャリアを模索しやすいのではないかと思っています。
トークテーマ(2) 今だからこそ面白い！SmartHRの魅力
Q. 今だからこそここが面白い！を古株メンバーに聞いてみたいです！
様々なフェーズのプロダクトとポジションに関わることができる環境だと思っています。2020年に入社して、SmartHRの基本機能の開発に携わってきました。会社の成長にあわせて、自分の役割もプレイヤーからプレイングマネージャー、マネージャーと変わっていきました。
プロダクトも小さなところからスタートして、今では10個以上のプロダクトがあり、今後も増やしていく予定です。基本機能では、40名のチームがあったり、7〜8年目のプロダクトもあったり、これから大きくなるプロダクトもあったり、ゼロイチのプロダクトもあったりします。
Q. アーリーフェーズを希望している方にはどんなお話をされていますか？
SmartHR のフェーズとして、組織立ち上げ経験はできないものの、事業は伸びているので、新しいプロダクトをつくって伸ばしていく経験はできることをお話ししています。なので、プロダクトの立ち上げは経験として提供できます。
技術選定に関しては、Ruby / Ruby on Rails を基礎としているので、イチから技術選定をし直す機会はないかもしれません。
Q. モダンな開発の経験は積めますか？
まずはモダンな開発がなにかを整理して考える必要があります。仮に「Rust や Go と言った言語が使えること」をモダンと定義するなら今の SmartHR では経験できません。
しかし、利用している言語やライブラリのバージョンに関しては各プロダクトでしっかりとアップデートに追従させており、言語やライブラリ単位での最新機能は常に利用可能な状態を維持できています。
また、ユニットテストがあって自動でテストが回り、一定の品質を担保した上でコードをマージできる、毎日デプロイできる、といったソフトウェア開発で良しとされているものが整備された環境になっています。
SmartHR の基本機能のように開発開始から8年以上経っているような大きなプロダクトにおいて、破綻せずにどう開発・設計するか、大人数でどう運用していくかといった「きちんとしたプロセスを経て開発していく」という経験を積める環境になっています。
SmartHR の経験が他社に通じないことはないと思っており、「当たり前」を実践するための基礎を学べる環境になっています。そういった意味ではモダンな環境だと考えています。
トークテーマ(3)「SmartHRっぽい」ってどんな人？
Q. どんな人が SmartHR っぽいと感じますか？
ひとことでまとめるのは難しいのですが、
例えば
- 手を動かすことが好きである
- 技術は、目的ではなく手段と考えている
- 内省的である（客観的に自分のことを見ることができる）
- 自分でよりよくしていこうと考えている
は共通点としてあります。逆に「俺がスターエンジニアだ！」という人はいません。
Q. SmartHR の「優秀なエンジニア」の定義はどういうものですか？
同一見解はないのですが、全社バリューのひとつに「自律駆動」を掲げており、自ら発見する力・解決する力があることを一つの指標としています。SmartHR ではやれることが幅広いので、自分で課題を見つけられると成果がでやすい環境です。より広く動けるエンジニアは非常に貴重だと思います。
あとは、変化に柔軟か、前向きに取り組めるかどうか、も大事な要素だと思います。自分の知識や経験に固執せず、成長に必要なことを考えることは、技術的なことにも通じると考えています。
Q. 入社されるひとはどういう志向性をもっていますか？
チームでジェネラリストとして活躍される人が多いです。
ただプログラミングをするだけではなく、逆算して設計・テストして一連のフローにコミットしたい、ユーザーのためになるプロダクトのつくりかたを学びたい人が目立ちます。
VP of Engineering 森住からのメッセージ
SmartHR は組織もプロダクトもすでに完成していると思われがちですが、決してそんなことはありません。現在 SmartHR が見据えている目標に対する進捗ですら 10% ほどです。
今はあくまで人事労務領域の課題を解決するプロダクトを提供していますが、ゆくゆくはバックオフィス全体の課題を解決するプロダクトへと進化させてゆくつもりです。
従業員データというバックオフィス業務におけるコアデータを押さえている SmartHR だからこそ解決できる課題は多いと考え、様々な新規事業領域を検討していますし、それらは今後現実のものとなってゆくでしょう。
十年後には、プロダクトも組織も、きっと現状からは想像もできないような姿になっていると思います。
僕が入社した5年前に70名ほどだった組織は、今では1,000名ほどになっています。SmartHR は、そういう会社です。
SmartHR では、ユーザーと近い距離で、フルサイクルに開発に関わることができます。ユーザーヒアリングやユーザビリティテストを行なったり、セールス / カスタマーサクセス / カスタマーサポートといった職種の方とお話しすることで、ユーザーや顧客を近くに感じながら開発しています。
フロントエンドはフロントの実装をやっていればよい、という考えではなく、バックエンドやインフラ、デザインやプロダクトマネジメントなど幅広く関わることを求められる環境に興味がある方がいらっしゃれば、ご推薦をお待ちしております。
