SmartHR開発組織の2023年振り返りと2024年の話

こんにちは、こんばんは。SmartHR VP of Engineering の morizumi です。

これは SmartHR Advent Calendar 2023 シリーズ1の25日目のエントリーです。つまりクリスマス。

昨年のアドベントカレンダーでは SmartHR開発組織のこれまで、これから〜2022クリスマスVer.〜と題して2017年から2022年までの振り返りと2023年の未来予想図を書きました。

今回は2023年の未来予想図がどれくらい実現したのか、2024年の未来予想図はどうなるのか、を書いていきます。

2023年の振り返り

それでは早速、

昨年書いた2023年の開発組織予想図です。

昨年のテックブログ記事では、

大きな変更点は黄色でハイライトして示しているのですが、箇条書きすると、

人材マネジメント系オプション機能がさらに増えます

プロダクト基盤チームが組成されます

なんらかの横串系プロダクトが開発されるでしょう

なんらかのイネーブリングチームも組成されるんじゃないかなあ

こんな感じです。語尾で確度を察してください。

と書いていました。では、実際どうなったのかを見てみましょう。なお、昨年に引き続き社内向けの言い訳を書いておきますが、わかりやすさ重視で実態とはやや異なる表記をしている箇所もありますがご了承ください。

人材マネジメント系オプション機能がさらに増えます

増えましたね。2023年は配置シミュレーションとスキル管理というふたつのオプション機能が増えました。また、「人材マネジメント」ではなく現在は「タレントマネジメント」と呼んでいます

プロダクト基盤チームが組成されます

組成されました。すでに権限基盤とデータ基盤の2チームで開発が行われています。

参考：マルチプロダクト戦略実現に向けて、プロダクト基盤チームを立ち上げました

なんらかの横串系プロダクトが開発されるでしょう

開発が進行中です。複数のプロダクトのデータを活用することで価値を生む、まさにマルチプロダクトの強みが活きるプロダクトを開発しています。

なんらかのイネーブリングチームも組成されるんじゃないかなあ

Developer Productivity Engineering ユニットを組成しました。現在はもっとも歴史が長い SmartHR 基本機能プロダクトの負債解消を支援しており、追々テックブログとして取り組みをご紹介できるんじゃないかと思っております。

予想図に書いていなかった内容

まず、新規アプリがふたつ増えました。どちらもこれまで SmartHR が主として取り組んできたものとは異なる領域のもので、今後の進展が楽しみです。

次に、VPoE 直下が増えました。DevRel / AI 研究室 / エンタープライズサクセスユニットの3つですね。エンタープライズサクセスユニット以外はテックブログで記事が出ているので、参考記事を貼っておきます

参考：SmartHRにDevRelを立ち上げます
参考：AIエンジニア0人の会社で、AI研究室を立ち上げる方法

エンタープライズサクセスユニットは、名前の通りエンタープライズ企業にサクセスしてもらうための開発を行うユニットです。ジェネリックな機能開発を優先すべき SaaS 事業において、ARR へのインパクトが（直接的にも間接的にも）大きいエンタープライズ企業の要望への対応が難しい、という課題を解決するために組成したユニットです。

最後に、職種間の関わりとして大きく変わった点として、QAエンジニア / デザイナー / UXライターが開発チームから抜けています。厳密に言うと、完全にチームから抜けているわけではなく、抜けているチームから所属したままのチームまでグラデーションがある状況なのですが、方向性としてはチームから抜ける方向で動いています。これは、チームの人数が増えてきたことによるコミュニケーションコストの低減や、マルチプロダクト化が進む中で各職種がよりよく横断的に貢献できるようになる、といったことを目的に行っているものです。

一言で言ってしまうと、職種ごとにストリームアラインドチーム / イネイブリングチームとしてどのようにプロダクト開発に関わるかを再定義した、ということです（突然チームトポロジーの用語を使いますが、ご容赦ください）。

2023年の振り返りのまとめ

まとめとしては、元々想定していたチームは想定通りに組成されて、プラスアルファで予期していなかったプロダクト開発チームや VPoE 直下のチームも組成された、というところでしょうか。2022年年末の予測よりも上振れたのはポジティブに捉えてよさそうです。

マルチプロダクト化が進行する中でプロダクト基盤の重要性も高まってきており、基盤への投資が進んだ1年でもありました。

ちなみに、2023年のプロダクトサイドスローガン（こういうことを意識していきましょうね、という標語）は「境界を越えよう」でした。

マルチプロダクト化が進んでいく中で、自身が担当するプロダクト単体だけではなく、マルチプロダクトの中のいちプロダクトであるという認識を持って、他プロダクトとの連携を前提として顧客への価値提供を考える
マルチプロダクトのベースとなる技術基盤を組織一丸となって、課題を共有しながら作り上げる

といった点を意識して、マルチプロダクト戦略の一歩目を着実に進めるためのスローガンでした。

2024年の開発組織予想図

振り返りは以上として、ここからは2024年のことをお話ししていきます。

注目ポイントは黄色でハイライトしています。変化が大きそうな部分を箇条書きしていくと、

SmartHR 基本機能が7チームの LeSS だったものを半分に分割します
タレントマネジメント系オプション機能をさらに増やします
プロダクト基盤を倍増させます
テクノロジーマネジメントの組織に SRE が加わります
新しい領域のプロダクトをさらに立ち上げます

という感じです。以降でそれぞれ詳しく見ていきますが、大枠の方針としては「マルチプロダクト戦略をさらにスケールさせる」という考えが前提となっています。

SmartHR 基本機能の分割

SmartHR 基本機能はリリース以来ずっと開発を続けているモノリシックで巨大な Rails アプリケーションです。コードベースが大きく、歴史も積み重なっており、データ量も多く、トラフィックも多い、というコアプロダクトあるあるな状態にあるアプリケーションです。今年、テックブログでもその開発の難しさが記事になっていました。

参考：入社してわかったSmartHR本体の難しさ

大きいものを大きいままに扱うのは難しく、開発スピードも遅くなってしまうので、SmartHR でもなんとか小さく扱えないかと苦心してきました。これまではドラスティックな変更をすることなく、なんとか乗り切ってきましたが今後のマルチプロダクト戦略を考えたときに、このままでは厳しいという結論に達しました。

SmartHR は、SmartHR 基本機能のデータを中心としてマルチプロダクトが動く構成になっているため、新規プロダクトを作ろうと思った際に SmartHR 基本機能側の開発が必要になると、そこがボトルネックになってしまう可能性があります。マルチプロダクト戦略を推し進めていくという前提に立ったときに、そのボトルネックを放置しておくわけにはいきません。

そこで、来年の頭から組織を分割するのと、並行してアーキテクチャ上も他のモジュールを意識しなくて済むよう小さく分割する方向で検討中です。もちろん一朝一夕には実現できないプロジェクトですが、この先10年の SmartHR の成長を考えると必要な取り組みと言えるでしょう。

複雑で大規模なプロダクトをシンプルで小規模なものに変容させていく（100億以上の ARR を稼いでいるビジネスを止めることなく）、という課題にワクワクするような方にオススメのプロジェクトです。

タレントマネジメント系オプション機能をさらに増やします

これは読んで字の如くという感じではあるのですが、タレントマネジメント系への投資は引き続き加速させていきます。

2020年時点では2つしかなかったタレントマネジメント系プロダクトですが、2023年時点では6つと3倍に増えています。タレントマネジメント領域は、評価やスキル、これまでの在籍部署など複数の情報をかけ合わせることで最適な人員配置を実現する、などマルチプロダクト戦略による恩恵を受けやすい特徴があります。

逆に言うと、プロダクト単体でのユーザーサクセスにフォーカスしてしまうと本当に顧客にとって必要なタレントマネジメントシステムは作れない、という難しさがあります。SmartHR では基本的に1プロダクト1チームで自己管理型のチームがそれぞれにプロダクトを開発していますが、そういった構造の中で働きながらも全体観を見失わずに、総体としてのユーザーサクセスを意識する必要があります。

タレントマネジメント、というまだ日本においてデファクトスタンダードが存在しない領域において、本当に価値あるプロダクトを探索しながら作る（それも複数プロダクトが連動する形で）、そういった課題に胸がときめくあなたにオススメの領域です。

プロダクト基盤を倍増させます

これも読んで字の如くという感じではあるのですが、倍増させます。倍増では済まないかもしれません。

冒頭で、大枠の方針としては「マルチプロダクト戦略をさらにスケールさせる」という考えが前提となる、と書きましたが、そのスケールを技術的に下支えするのがこのプロダクト基盤領域です。

現状は、ざっくり言うと権限基盤とデータ基盤（プロダクト間の相互データ参照など）の整備を中心に進めていますが、プロダクト基盤が作るべき基盤はこれだけにとどまりません。例えば、SmartHR は労務手続きにおける従業員側の ToDo だったり、評価業務における評価者 / 被評価者の ToDo だったり、ToDo 管理が必要になる場面がしばしばあります。その ToDo 管理を各プロダクトで実装するのは単に無駄がありますし、顧客の体験としても ToDo が分散してしまっているのはよろしくありません。そういった、基盤が必要な領域がいくつも SmartHR には存在しています。

マルチプロダクト戦略を実現する速度と、マルチプロダクトの質にもろに影響してくるため、2024年はプロダクト基盤への投資を大幅に加速させる予定です。

複数のプロダクトを裏から支え、開発者体験も顧客体験もどちらも最良のものを提供する、そんな基盤作りにゾクゾクくる方にオススメの領域です。

テクノロジーマネジメントの組織に SRE が加わります

2023年に新設したテクノロジーマネジメントグループですが、現在は DPE（Developer Productivity Engineering）ユニットしかありません。組織がスケールしていく中で、すべてのチームの開発生産性を高める、といった横断的にレバレッジを効かせられるポジションの重要性が増してきています（ちなみに、SmartHR のプロダクトエンジニアは今年ようやく100名を超えました）。

DPE が開発生産性にフォーカスした活動を行う一方で、SRE は（みなさんご存知の通り）信頼性にフォーカスした活動を行います。SmartHR では「自己管理型のプロダクト開発チームであること」を強く意識した組織づくりを行なっているため、DPE も SRE も開発プロセスの一部を請け負う、といった動きは行いません。あくまで自己管理型のチームの開発生産性や信頼性を高める支援（イネイブリング）を行います。

現状は SRE を増やすことだけが決まっていますが、プロダクト開発チームにおいて支援が必要な領域を特定し、さらにイネイブリングチームを増やしていく予定です。

テクノロジーマネジメントグループについては、技術力は当然のこととして、SmartHR の文化に合わせた支援活動の枠組みを作ることが重要と考えており、差し当たりは社内からの異動を通して組織づくりを行なっていく予定です。