SmartHR社・執行役員 VPoEの森住卓矢氏
森住卓矢氏：こんばんは、よろしくお願いします。「SmartHRのセメとセメ」ということで、イベントの趣旨と真っ向から対立するようなタイトルにしてしまったんですが、整理するとやはり攻め続けているなと思ったのでこのタイトルにしています。
最初に自己紹介をします。SmartHR、VPoEの森住と申します。2018年8月にSmartHRにジョインしているので、だいたい4年半ほど在籍している人間です。
1年半ほどプレイヤーとして「SmartHR」の基本機能の開発に携わって、以降は1年ごとにプレイングマネージャー、マネージャー、VPoEと役割を変えて今に至っています。
今はプロダクトエンジニアグループとQAグループとUXライティンググループで、100名ちょっとぐらいを管掌するような立場として働いています。
最近は、夜な夜なホグワーツ魔法学校に通学して勉強に励んでいます。はい、ややウケですね。
（会場笑）
本日お話しすることとしては、SmartHRについて軽く紹介させていただいて、その後、2017年頃から現在までのSmartHRのお話と、最後にまとめをお話ししようと思います。
「SmartHR＝人事・労務業務を効率化するプロダクト」は昔の話
まず、SmartHRについてですね。「SmartHRは、人事・労務業務を効率化するプロダクトです」というのは嘘です。嘘というか、ちょっと昔の話なんですね。
SmartHRのことをご存じだった方は、こんなイメージを持っているんじゃないでしょうか。「SmartHRって、労務業務をペーパーレス化しているんでしょ？」とか、「健康保険・厚生年金保険被保険者資格取得届とかを、デジタルでできるようにしているんですよね」みたいな。
（スライドを示して）わからないと思いますが、これはみなさんが会社に入社する時に労務の方が必ず役所に出している書類です。こういうたくさんのスペースをがんばって手書きで埋めていって、役所の行列に並んで提出するというところを効率化していました。
あとは、例えば「基礎控除申告書兼配偶者控除等申告書兼所得金額調整控除申告書とか、そういったものを電子化しているんでしょう」。
これは、実はみなさんが知っているやつだと思います。おなじみの年末調整で書いている書類ですね。これもSmartHRのWeb上で完結できるようになっていて、わかりやすくて使いやすく、年末調整にかかるコストが87パーセント減（※）できますよとか、そういった労務業務の効率化は確かに祖業としてかなりがんばってやっていて、今でも成果を出しているところではあります。
※削減時間の数値はSmartHRをご利用中の企業のご利用状況、従業員構成比等を参考に、1,000名規模企業を想定して算出しています。
一方で、最近はそれだけではなくて、「人材マネジメント領域」にも足を踏み出しています。どういったものかというと、SmartHRでは、先ほどお見せしたとおり書類による情報を入力するので、従業員情報が溜まっていくんですよね。
その溜まったデータを基に、例えば人材配置の時に使う情報や評価情報を溜めていって、従業員のエンゲージメントを高めて、より気持ち良く働いてもらって定着率も上げてもらうという、そういったプロダクトも最近は展開を始めています。
これは今のコーポレートミッションです。「well-working 労働にまつわる社会課題をなくし、誰もがその人らしく働ける社会をつくる。」という方向の会社になっています。実は紙をなくすことが目的の会社ではなくなっているということですね。まぁ、もともとそうじゃなかったんですけど。
2017年頃は「攻め10、守り0」でリリースが最優先
ここから、2017年頃から現在までのSmartHRという話をしていきたいと思います。
まず2017年頃、今から6年前ですね。体制図としてはめっちゃシンプルで、SmartHRというプロダクトを開発しているエンジニア、ドメインエキスパート、プロダクトオーナーがいる、ただそれだけの体制でした。
プロダクトオーナーである労務領域のドメインエキスパートの方と、プロダクトエンジニアのみで開発をしていました。ドメインエキスパートの方に「労務業務ってこういう仕事をしているから、こういう機能が必要ですよ」みたいな話をしてもらって、エンジニアが「うんうん、なるほど」と言って、開発するみたいな、そういったやり方をしていました。
アーキテクチャは、Railsのモノリシックなアプリケーションが1つあるだけで、非常にシンプルなものでした。
リリース速度が最優先だったのですが、僕が（会社に）入って思ったのが、偉いなって……偉いなっていうのは偉そうな言い方ですが、きちんとユニットテストを書いていましたし、CI/CDの整備やライブラリアップデートを欠かさずやるみたいなところをきちんとやっている会社でした。当時はリリースが最優先だったので、攻め10、守り0みたいな感じですね。
2018年頃も“ガン攻めなリリース”で攻めと守りは10：0
次は2018年頃。僕はこの頃に入社したのですが、当時はSmartHR基本機能とREST APIでつなぐオプション機能が生まれてきた時代です。
みなさんは入社した時に雇用契約を結んでいると思いますが、先ほどお話しした年末調整や雇用契約をWeb上で完結できるようなオプション機能です。ユーザーから見ると1個のSmartHRというプロダクトですが、内部的には分かれていて、REST APIでSmartHR基本機能とつながることで動く仕組みになっています。
ここではオプション機能という概念が誕生して、リポジトリやインフラごとにアプリを切り分けることで、もともとあったモノリシックなRailsアプリケーションの肥大化を防止しました。
アーキテクチャとしては、SmartHR基本機能側にREST APIのエンドポイントを設けて、それを利用してオプション機能が動くというかたちに変化しました。組織デザインとしても、いたずらに1チームが肥大化するのを防止できたかなと思っています。
この頃も10：0ですね。今振り返ってもガン攻めなリリースをしていました。
一時的に負債解消チームが立ち上がった2020年頃
2018年から飛んで2020年頃ですが、急にいろいろなものが増えています。
まずSmartHR基本機能だと、LeSS、Large Scale Scrumという複数チームでの開発体制になったり、デザイナー、QAエンジニアみたいな職種がきちんと生まれていたり、あとは人材マネジメント系オプション機能もちょっとだけ生まれたりしています。
チーム内の職能が非常に多様化してきました。SmartHR基本機能の開発は、先ほどお話ししたとおり複数チームです。Large Scale Scrumで行われるようになりました。
人材マネジメント系のオプション機能が誕生して、SmartHR基本機能とAPIでつながるアプリケーションが増大し始めます。引き続きSmartHR基本機能の新機能開発とオプション機能の追加は行われていて、「セメの投資」を継続していたフェーズだなと思います。
ただ、この頃に実装した従業員情報の履歴管理機能というものがあり、これが後に、後にというか当時もなんですけど、大きな技術的負債となりました。
これはRailsをやっている方だったらお察しだと思いますが、「Active Record」を拡張するgemを作って履歴管理機能を実装したんですよね。かなりの早さでリリースはできたのですが、Active Recordの予期せぬ挙動が不具合の原因になって、いろいろ問い合わせが爆増しました。
それに対応するために、SmartHR史上初の負債解消チームが一時的に立ち上がる事態になりました。この時は約3ヶ月で負債解消チームを解散できるぐらいの事態だったなと思います。当時は負債解消チームがいたので、（攻めと守りは）7：3ぐらいかなという感じです。
「セメの投資」を継続している2023年
飛んで、2023年の今年ですが、だいぶいろいろと増えています。
SmartHR基本機能は、チームが1から6まである6チーム体制になっていて、オプション機能、年末調整、文書配付、届出書類、レポート、サーベイ、組織図、and more、みたいなものがたくさんあったり。
プロダクト基盤が真ん中あたりに生まれていて、これはSmartHRではかなり珍しいものです。SmartHRは基本的にプロダクトエンジニアという職種しかなくて、プロダクトにエンジニアをアサインして、プロダクトを作ってもらうという、本当にシンプルな体制だったので、横の連携というか基盤作りをあまりやっていなかったんですよね。
あと、（スライドの）左下に「SmartHR Plus」というプラットフォーム事業が加わっています。UXライターという職能も追加されたりしています。
チーム内の職能がさらに多様化されて、基本機能は6チームで開発されるようになりました。プラットフォーム事業が誕生して、オプション機能も追加され続けることで、SmartHR基本機能のREST APIとつながるアプリケーションは数十という規模になっています。
引き続きSmartHR基本機能は、新機能開発がガンガン行われています。たまにカジュアル面談で「保守されているの、大変ですよね」みたいな話をいただくのですが、保守もしていますが、新機能開発のほうが割合としてはぜんぜん多い感じですね。特に人材マネジメント系のオプション機能の追加がガンガン行われていて、いまだに「セメの投資」を継続しています。
全体のチーム数が18チームまで拡大しています。オプション機能アプリが増えたことで、各アプリケーションで体験が微妙に異なるという問題が発生し始めています。
先ほどお見せしたとおり、ユーザーから見ると1個のSmartHRですが、リポジトリも全部分かれている感じになっているので、権限の実装とかを各アプリケーションでやっていたりするんですよね。
こっちの権限はこういうUIなのに、こっちの権限は違うとか、そもそも権限の設計思想が違うとか。ロールベースだったり、個人ベースだったりということが起こってしまっているので、ちょっとなんとかしないといけないねという話をしています。
その対応をすることが、プロダクト基盤チームの組成につながっています。ただ、これは守りというよりは、個人的には「セメの投資」かなという認識をしていて、最後のまとめでそれを話せればなと思います。
Active Recordを拡張して実装している従業員履歴管理機能の技術的負債は、引き続き大きく、2022年の途中から3名体制の固定的な負債返却チームを組成しています。
SmartHR基本機能については、複雑化に伴ってモジュラーモノリスなどの選択肢を検討したのですが、現状はまだモノリシックなRailsアプリケーションのままです。
印象としては（攻めと守りは）7：3ぐらいだったのかなと思っていて、そんなに守りに入ったという意識はありませんでした。「ありませんでした」ではなく、現在進行形なので「ありません」ですね。
これからも「セメの投資」をして組織・プロダクトを拡大し続ける
まとめとしては、基本的にリリース以降ずっと「セメの投資」を継続していて、組織もプロダクトも拡大し続けています。
クリティカルな技術的負債に対しては、現状、固定的なチームを組成して対応していますが、これはあまり理想的ではないと考えています。ふだんの開発の中で解消できるぐらいの負債の重さにしていけるのがいいのかなとは思っています。
比較的初期において、いたずらにモノリシックなRailsアプリケーションを拡張し続けずにリポジトリもインフラも切り出したのは、マイナス面もありましたが、新機能開発を小さく行うことで機動性を高めることにつながり、今振り返ってもいい判断だったなと思っています。
初期から自動テストの実装、CI/CDの整備、継続的なライブラリアップデートなどを行ってきたことで、7年もののプロダクトとしては健全な状態を保てているんじゃないかなと思っています。
今後は複数プロダクトで、ユーザーに価値を提供できるコンパウンドスタートアップの姿を目指して、「セメの投資」を継続していこうと思っています。
この、「コンパウンドスタートアップの姿を目指す」ですが、プロダクトが複数ある今の状態で、それらがうまくシームレスに連携することでユーザーに価値を提供するという世界観を目指しています。プロダクト基盤チームを作って基盤を整備するのは、守りではなく「セメ」の動きだと思っています。
採用アピールのスライドを入れるのを忘れましたが、お手元の資料に採用ページへのリンクがあると思うので、興味がある方はぜひ覗いてみてください。ありがとうございました。
（会場拍手）
