SmartHR Tech Blog

SmartHR 開発者ブログ

156億円でなにするの? エンジニアリーダーたちに聞いてみた

こんにちは! エンジニアマネージャーの森住(@t_morizumi)です!

今回はシリーズD調達を果たしたSmartHRのこれからをご紹介すべく、各事業領域のエンジニアリーダーにインタビューをしていきます。

それぞれの領域について、これまでどういう開発をしてきたのか、これからどういう開発をしていくのか、事業として今後どうしていくのか、といった部分を中心に各エンジニアリーダーに語っていただきます。

なお、本記事は以下の三部構成となっています。

  • 引き続き事業の軸となる「SmartHR本体」
    • エンジニアマネージャー : 鈴木 睦央
  • 新たな軸としての「人材マネジメント」
    • PdM兼エンジニア : 疋田 駿
  • 働くすべての人を支える未来に向けて「プラットフォーム化構想」
    • CTO : 芹澤 雅人

それでは早速、SmartHR本体のエンジニアマネージャーを務める鈴木さんからお話をうかがっていきます!

鈴木 睦央

29歳まで高等遊民として活動し、日々読書、昼寝などに勤しむ。ある日ふとエンジニアになろうと思い、白紙の職務経歴書を握り締め就職活動を開始。2社経験したのち2018年にSmartHRへ入社。2021年よりSmartHR本体の統括をするマネージャーに就任。

引き続き事業の軸となる「SmartHR本体」について

――まず最初に、「SmartHR本体」とはなにかをざっくりご紹介いただいてもいいですか?

鈴木:はい。SmartHRは従業員情報を集約したアプリケーションを核とし、それと連携する機能ごとのアプリケーション(編注:年末調整や文書配付など)を配置したマイクロサービス的な構成をとっています。その核となるのがSmartHR本体であり、社内で最も大規模かつ歴史の長いアプリケーションです。

――なるほど。歴史が長い、というお話がありましたが、シリーズC調達後の直近2年くらいに絞るとチームの規模の面ではどんな変化がありましたか?

鈴木:2019年当時、本体のチームは10名弱の1チーム構成で、スタンダードなスクラム開発をしていました。2020年には本体への新機能追加を加速させるべく、大規模な環境でスクラム開発をするためのフレームワークであるLeSSを採用し、1チームあたり4, 5名程度の編成で3チームを擁するようになりました。

2021年にはさらに人数が増え5つのチームから成り立ち、それぞれのチームにはエンジニアが5, 6名配置されています。

――2年でチーム数は5倍、メンバー数は2.5倍になっているんですね。規模の拡大に合わせて、組織構造に変化はありましたか?

鈴木:2年前はコンポーネントチームの色が強く、要件定義、デザイン、開発、QAと、いわゆる上流から下流へ流れてくるような開発フローでした。この体制に限界を感じ、2020年末あたりからはリードタイムの短縮、品質向上を狙い、企画からリリースまでのすべての機能をチームに内包すべくフィーチャーチームとして再編成しました。現在はPdM、デザイナー、QA、エンジニア、チームによってはUXライターと、様々な職種でチームが構成されています。

(編注:コンポーネントチーム = バックエンド / フロントエンド / デザイン / QA など特定の領域に責任を負うチーム。フィーチャーチーム = 企画からリリースまで、などやりたいことに対して必要なすべての領域に責任を負うチーム)

――体制に限界を感じた、というお話がありましたが、限界を感じた理由を聞いてみてもいいですか?

鈴木:ひとつはシンプルに、リードタイムの問題です。工程間が分断されていると、どうしても受け渡しコストや手戻りのコストが大きくなります。一つの工程がある程度仕上がるまで、その後の工程は動けない。さらに受け渡しのためのドキュメント作成や説明会の時間もいる。

また、途中で仕様変更やデザイン変更があった際に前の工程に戻すわけですが、そうすると再度前の工程が終わるまで待たなければいけないんですよね。透明性の問題もあって、チーム外のことだから、戻したものがどういうステータスにあるかもわからない。必然的にリリースまでの時間は延びていきます。

もうひとつは、なぜ、どうやって、なにをつくるのか、というところも希薄化、あるいはズレたりするんですね。いっしょに仕様検討やデザイン作成をしているわけではないから、どうしてもその背景の伝達にはロスが生じる。

そういうわけで、アジリティを担保したうえでリードタイムや品質も維持する、というのが難しくなってきました。チームや人数が大きくなれば、なおさらです。

リソース効率重視からフロー効率重視へ

――組織構造の変化に合わせて、開発の進め方に変化はありましたか?

鈴木:より早くユーザーに価値を届けたい、よりよいものを作るために仮説検証を高速にしたい、という思いから、リソース効率を重視した開発からフロー効率を重視した開発へシフトしました。

特定のチームが特定の機能群の開発・アウトカムに責任をもつというフィーチャーチーム体制にしたのもその一環です。いろいろな施策を行っていますが、例えばエンジニアやPdMがQAに代わってテストを行う、エンジニアがデザインをするなど、クロスファンクションの流れはこの半年ほどで大きく前進したところです。

――より早くユーザーに価値を届けるためにフロー効率を重視した体制に変化させてきた、と。ちなみに、その価値を届ける先である、ご利用いただいているユーザー層といった部分での変化は感じていますか?

鈴木:多様性がかなり増しました。数名規模のユーザーから数万名規模のユーザー、業種も違えば組織構造も様々、といった具合です。そういった多種多様なユーザーの課題を等しく解決しなければいけないところが、難しいところでもありやりがいのあるところでもあります。

――数万名規模のユーザーが増えてくると、パフォーマンス面でも問題が出てくるように思うのですが、そのあたりはいかがですか?

鈴木:今までになかったほど大きな規模のユーザーにお使いいただけるようになり、データ量に比例してパフォーマンスの劣化が散見されるようになりました。特に初期に作られた機能は、当時中小規模のユーザーをターゲットとしていたこともあり、処理時間が如実に延びていました。

期間限定の特命チームを組成し、集中して改善にあたることでかなり改善しましたが、今後も継続的にチューニングをし、どのような規模のユーザーにも快適に使っていただける状態を維持するよう努めていく必要がありますね。

組織をよりアジャイルな状態に

――シリーズD調達後のSmartHR本体の組織についてですが、今後はどういった組織にしていきたいですか?

鈴木:先にフィーチャーチームの編成について触れましたが、まだまだ成熟しているとは言い難く、土台を固めるのに多くのコストを払っている状況です。今後はフィーチャーチームとしての成熟を通して組織をよりアジャイルな状態にし、リードタイムの短縮や品質向上を目指していきます。

調達後は採用を加速させるのはもちろんのこと、人やチームが増えてもアジャイルな状態を維持できるよう本体チーム全体で成熟していきたいと思っています。

――今後のSmartHR本体の開発で課題になりそうなことを教えてください

鈴木:現在も多くの新機能を本体に追加開発していますが、そろそろ規模が大きくなりすぎたなという感覚があります。ソースコードの肥大化、影響範囲の拡大、データの複雑性などから、いずれアジリティの低下が始まると予想しています。

今後は本体に持たせる機能と切り出せる機能を精査し、追加開発や定期的なメンテナンスをアジャイルに行えるような、長期的な目線でのアーキテクチャの検討・実現が必要と感じています。

――それでは最後に、SmartHR本体の開発に向いているのはどんな人か教えてください!

鈴木:そうですねえ。

  • 泥臭く地道にプロダクトと向き合える
  • 新しいことや広い範囲のものごとを学ぶのに抵抗がない
  • なぜ、なにを、どうやって作るか納得してプロダクトを作りたい
  • チームで成果を出したい

といった点に共感できる人が向いていると思います。

――ありがとうございました!

* * * * *

それでは次に、人材マネジメント領域のエンジニアリーダーである疋田さんにお話をうかがっていきます。

疋田 駿@h1kita

SIer、不動産テックのスタートアップにてエンジニアとして複数のプロダクト開発を経験。2018年12月にSmartHRにエンジニアとして入社。文書配付機能の開発を担当し、2020年2月からはPdM兼エンジニアとして従業員サーベイの立ち上げを担当。現在は、新しいプロダクトの仕込みをPdM兼エンジニアとして担当している。

新たな軸としての「人材マネジメント」について

――人材マネジメント領域、正直に言うと僕はよくわかっていないのですが、知らない人向けに紹介するとどんな領域なんですか?

疋田:人材マネジメントは、簡単に言うと組織が経営戦略を実現するために、人を活かして、短期・長期的な視点で組織パフォーマンスを上げていくための活動や仕組み全般を指していて、具体的には採用や育成、評価や報酬、配置などがそれにあたります。

人材の流動性が高まり、採用が難しくなっている今、従業員が活躍し、自社を選び続けてくれる組織環境を作ることはより重要になってきています。

――なるほど、わかりやすい。そんな人材マネジメント領域ですが、SmartHRがその領域に進出しようと意思決定した背景はどのようなものだったんですか?

疋田:1つはユーザーニーズが強く、SmartHRの従業員DBを活かせ、さらに強化できる領域であったことかなと思います。

SmartHRはこれまで労務領域を中心にサービス展開をしていて、正確な従業員データを蓄積できる仕組みができていました。ここに人材マネジメント領域の評価や等級、報酬やエンゲージメントなどのデータを追加し、蓄めやすく活用しやすくすることでユーザーにこれまでとは違った新しい価値を提供できると考えています。

あとは事業的な側面で、SmartHRは国内の企業を対象としているサービスなのですが、国内企業には限りがあるので、将来的にどうしても成長は鈍化してきてしまいます。 今後も成長スピードを維持していくために、広げるだけでなく新たな価値を提供して領域を深めていけるような、第二の柱となる事業が必要になってきていたんです。

こういった市場ニーズと事業的な側面の背景があります。

――新たな価値を提供して第二の柱となる事業に、というお話があったかと思いますが、新しい領域に踏み出すにあたって特に意識したことはありますか?

疋田:人材マネジメント領域は、労務領域とはまた違う課題を抱えている領域ですし先行プレイヤーも多いので、我々はどのようなポジションで、どのようなサービスを提供していくのか、ユーザーはどんな課題を抱えていて、それはどれくらい深い課題なのかみたいなところはチームとして学習していけるように意識しています。

そのために、たくさんの仮説を検証していかなくてはならないのですが、より重要な仮説にフォーカスできるように仮説の影響度や不確実性を考慮して優先度を決めたり、開発チーム全体でユーザーヒアリングに参加したり、弊社人事にスプリントレビューをお願いするなどして学びを深めるような取り組みも行なっています。

人事担当者が従業員のことを考える仕事に集中できるように

――まだまだ不確実性が高いとは思いますが、人材マネジメントの今後についてどのような展望を描いていますか?

疋田:人事担当者の業務は非常に多岐に渡るので、重要とはわかりつつも十分な時間を割くことができなかったり、データが散在していていざ活用しようとしても難しかったり色々な課題があると思っています。

将来的には、SmartHRを使えば労務や人材マネジメント領域の業務が効率化され、人事担当者は従業員のことを考える仕事に集中でき、SmartHRを使っているだけで従業員やマネージャーからデータが勝手に集まり、人事戦略の意思決定や人員配置、育成などにデータを活用できるような世界観を作っていきたいと思っています。

――そういった世界観の実現に向けて、どのような開発体制を作っていく必要がありそうですか?

疋田:現在、人材マネジメント領域でも各ドメインごとにプロダクトやチームが分かれています。機動力高くスピード感を持って動けている反面、人材マネジメント領域全体としてユーザーに価値を届けていくにあたり、優先度付けやデータの分断、学習内容の違いなどは起こってきそうだなと思っています。

今後は、スピード感を維持しつつ、横のつながりや連携を強められるような開発体制を模索していきたいです。

――今後、人材マネジメント領域の開発を進めていくにあたり、出てきそうな課題はありますか?

疋田:各プロダクトから従業員データを貯めやすく、取り出しやすい従業員DBをどう作り上げていくかは課題になりそうだと考えています。

今内部的にはドメインごとにDBが分かれているのですが、データ活用や横断した分析を考えたときに、各プロダクトから別ドメインのデータも扱える必要がでてきます。

SmartHRの性質上、マルチテナンシーやデータのアクセス権限も考慮する必要があるのでデータを慎重に扱いつつ、取り出しやすいインターフェースやデータの持ち方、アーキテクチャの検討は今後向き合っていくべき課題と捉えています。

――ありがとうございます。それでは最後に、人材マネジメント領域の開発に向いているのはどんな人か教えてください!

疋田:人材マネジメント領域は、まだ立ち上がったばかりで、チーム一丸となって事業やプロダクトの仮説検証を高速にしていきたいフェーズです。ユーザーにとっての価値やビジネスとしての成長を考え、ロールに縛られずにプロダクトやビジネスを育てていきたいという人に向いていると思います。

また、初期フェーズにおける設計は将来的なスピードに大きな影響を及ぼす優位性になるものでもあるので、開発スピードを保ちつつ、拡張性や保守性を考慮した設計にチャレンジしたい人も楽しめるかなと思います。

――ありがとうございました!

* * * * *

最後はCTOである芹澤さんから、働くすべての人を支える未来に向けた「プラットフォーム化構想」についてお話を聞いていきます。

芹澤 雅人@masato_serizawa

新卒で社会人になって以来、Webエンジニアとしてのキャリアを歩む。SmartHRにはサービスリリース直後から参加し、開発業務のほかVPoEとしてエンジニアチームのビルディングとマネジメントに従事したのち、CTOに就任。現在はプロダクト開発・運用に関わるチーム全体の最適化やビジネスサイドとの要望調整を行う。

働くすべての人を支える未来に向けた「プラットフォーム化構想」について

――最初に、SmartHRにおけるプラットフォームとはどういったものなのか教えてください

芹澤:SmartHR上のデータを使って動くアプリケーションを実装し、配信するための基盤です。

SmartHRのプラットフォーム上でアプリケーションを作ることにより、SmartHRに保存されている様々なデータを活用できるほか、多くのバックオフィスサービスが共通して持つ従業員情報管理やログインといった機能の実装を省略することができます。

――プラットフォーム化については、芹澤さんは随分前からやりたいと話されていた印象がありますが、どういった背景があるんですか?

芹澤:SmartHRを基盤としたプラットフォームの展開は、2015年にSmartHRローンチ時のピッチを見たときからやりたいと思っていました。

理由は2つあり、1つはデータの鮮度です。役所へ提出する個人情報を管理する特性上、SmartHRに保存されているデータは常にアップデートされ続けています。その鮮度の高いデータをハブにバックオフィスサービスを展開することは、データメンテナンスコストの削減につながると考えました。

もう1つはデータの希少性です。バックオフィス業務を遂行するためには、従業員に関する様々なデータを取り扱う必要があります。名前や性別、生年月日のほか、住所や給与、評価、家族に関する情報など。これらのデータが体系的に管理されていることは非常に価値が高いと考え、また、それらを組み合わせることによって生み出される新しい価値にも可能性を感じました。

――2015年からということは、6年ほど前からすでに考え始めていたんですね。そんなプラットフォーム化の実現に向け、今はどういったことをされているんですか?

芹澤:前述の通り長いこと構想を続けていましたが、実際に動き出したのは実は昨年の12月からです。どんなに夢があってもビジネスにならなかったら意味がないので、まずは事業企画の方を中心にビジネススキームを考え、その仮説検証に向けて動いています。

――実際に動き始めてみて、見えてきた課題はありますか?

芹澤:技術的な観点だと、開発パートナーの参入を意識したインターフェースの設計などは、やはり難易度が高いなという印象です。SmartHRはまだまだ成長期のプロダクトであり、機能開発によってDBのスキーマが変更されることもよくあります。APIを公開すると後方互換性のない変更ができなくなるので、SmartHR本体の開発に制約や考慮点が加わることになり、どうしてもスピード感が落ちてしまいます。

一方でコアビジネスの成長は開発パートナーにとって魅力的なプラットフォームになるために必要不可欠なことであり、この両立をどうするか、非常に頭を悩まされています。

SaaSの弱点である「個別カスタマイズの難しさ」の克服

――技術的にもやりがいが大きそうな領域ですね。将来的にはどのような体制でプラットフォーム化を推進していく予定ですか?

芹澤:事業的には、コアビジネスを超える規模のエンジニアが求められるポテンシャルがあると考えています。

コアビジネスと違うのは、大小様々なアプリケーションをたくさん作ったり、開発パートナーとのやりとりをする必要があるということです。正直、今の時点ではどのように組織を大きくしていくかはまったく考えられていないのですが、そういった未来に向けて着実に歩みを進めていこうと思っています。

――プラットフォームとしてのSmartHRの将来像はどのようなものを描いていますか?

芹澤:プラットフォームを通してSmartHR本体では補えないような領域における機能提供をしていくことはもちろんなのですが、もう1つ実現したいことがあります。

それは、SaaSの弱点である「個別カスタマイズの難しさ」の克服です。SmartHR本体の1つ1つの機能を外部サービスから拡張可能な状態にしていくことで、個社ニーズにも対応していけると考えています。痒いところに手が届くような個別カスタマイズを通して、SmartHRをより多くのユーザーに快適に使っていただけるような状態にしたいですね。

――様々なアプリが連動することでSmartHRをユーザーにとってより快適なものに、というのは夢がありますね。最後に、プラットフォーム化を推進するチームに向いているのはどんな人か教えてください!

芹澤:プラットフォームはその性質上、難易度の高いインターフェース設計タスクが山盛りです。APIデザインに興味のある方はまず向いていると言えるでしょう。

一方、ビジネスとしてはまだまだ黎明期のフェイズです。ビジネスコンセプトのスピーディな検証が求められるので、じっくりと設計に時間を費やしすぎることもできません。そのようなバランスを見極めつつ、着実にビジネスを成長させていくことに楽しみを見出して行ける人が向いているでしょう。

――ありがとうございました!

まとめ

今回はシリーズD調達を経てSmartHRの各事業領域が今後どうなっていくのか、をエンジニアリーダーの方々にインタビューする形でご紹介しました。

156億円という大きなお金を投資いただくことには相応の社会的責任が伴います。

SmartHRは「働くすべての人を後押しするプラットフォーム」になるべく、これからさらに事業を拡大し、歴史に名を残すプロダクトをつくり続けます。

We are Hiring!

SmartHRでは歴史に残る模範的なソフトウェアを共に作っていく仲間を募集しています!

hello-world.smarthr.co.jp