SmartHRで一人目のMLエンジニアになった理由

初めまして！4月に入社したML(機械学習)エンジニアの井上耕太朗です。
MLとは何だ？メーリングリストか！いかがわしい職業ではないのか！？という方もご安心ください。この記事では、SmartHRで一人目のMLエンジニアとして入社した私が、SmartHRでのMLエンジニアとしての仕事、そしてMLエンジニアから見たSmartHRの魅力をお伝えしたいと思います！

簡単な経歴

SmartHRでは少ない？工学博士です。大学では光学、画像処理、機械学習を組み合わせた3次元計測や裸眼立体視(任天堂3DSのようなもの)の研究をし、論文を色々書きながら海外をふらふらとして気づいたら工学博士になっていました。

2021年からはアダコテックにMLエンジニアとして入社し、当時どこの馬の骨とも知れない新卒だった私に数多くのチャレンジの場をいただきました。機械学習モデルのアルゴリズムから、ドメイン特有の問題を解くためのハイパーパラメータチューニングの自動化、およびモデルの性能評価指標の工夫などの研究開発およびプロダクト実装をしていました。コアロジックレベルからバックエンド、フロントエンドとプロダクト開発に必要な一連のプロセスを経験し、今でもかけがえのない経験となっています。

2025年からは0x20歳(16進数でハタチ)というちょうどよい節目を迎え、新たなチャレンジを探していましたが、ちょうど言語モデルが賑やかなため言語系の先端技術に触れつつ、MLOpsなどにもガッツリ挑戦してみたいなという思いから、SmartHRでチャレンジしてみることにしました！

MLエンジニアから見たSmartHRの魅力

当初は「SmartHRってあれやろ、労務のペーパーレスやろ？」みたいなQVGA画質ぐらいの解像度でいたのですが、話を聞いていくうちにMLの適用可能性がかなり高いということに気づきました。

データの豊富さ1位、かつ新規参入は難しい

SmartHRは労務系SaaSとして日本で最も高いシェアを誇ります。つまりデータベースにある労務系データ量は国内最大級です。また労務システムという観点では、今日の晩ごはんを選ぶような気軽さで乗り換えるようなプロダクトでもないため、新規参入は非常に難しいと考えられます。 データ優位をしばらく維持できることは、文字通り日進月歩の機械学習領域において絶大なメリットです。

AIをプロダクト実装するための環境が良い

『なんかイケてる雰囲気の機能を思いついたけど、これホンマにウケるんやろか？』

プロダクト開発に携わる方は一度どころか毎日考えることと思いますが、その答えのヒントとなるのはドメインエキスパート(対象業務を熟知している人) やドメイン解像度の高いPM(プロダクトマネージャー)、そしてビジネスサイドの方々です。何だか強そうな名前ですが実際に強い方々で、ドメイン知識が豊富なエキスパートの存在はデータがあることより個人的に重視すべき要素と考えており、SmartHRには多数在籍しています。またユーザとの距離の近さも重要であり、ユーザー交流会などで実際にユーザーの声をいただける機会のあることも良いポイントです。

AIプロダクトはできることがふわっとしていて、対象業務のフローにどう適用していくのかエンジニアは想像しかできず、そこにドメイン知識ツヨツヨな方々のフィードバックがあれば、開発方針やリリース判断などあらゆる面でのバフがかかります。 Devinを右に置いたのなら、ドメインエキスパートは必ず左に置きましょう！

AI導入の戦略が良い

これはMLエンジニアに限らずエンジニア全員というドデカい主語で言えることと思いますが、エンジニアは性質上Howの部分、つまり手法を愛してしまうことが多く、新技術という言葉に失神して気づけばできることベースでのアウトプットが作られがちです。しかしこの手のアウトプットが事業課題を解決することは運が良ければ……ぐらいのもので、しっかりとした事業課題の言語化とマネジメントが必要です。

SmartHRでは事業の課題解決の順序を考慮したAI機能の導入、直近ではデータ入力の部分に焦点を当てて開発が進められており、これは優秀なPMの方の存在と、会社風土としても開発組織の運営がうまくいっているからこそ可能なことです。当たり前のようですが、なかなかきれいに回せている組織は少ないのでは？と思います。

私の仕事

MLエンジニアの仕事とは課題を解決するためのアルゴリズム/モデル構築、学習データ作成、パラメータチューニング、性能評価など様々ですが、この中で最も時間をかけるべき重要な仕事は何でしょうか？『24時間以内に実用的なAI機能をリリースしないと出られない部屋』に突如監禁されたとして、MLエンジニアが限られた時間の中で最も工数を割くべき仕事とは……！？

私の場合、答えは性能評価と学習データ作成です。一つだけに限定するのであれば性能評価が最も重要と考えます。アルゴリズムやモデルは課題とデータの性質によって自ずと選択肢が絞られますし、パラメータチューニングは性能がビジネスに与える影響が明確でなければ意味がありません。学習データの作成も重要ですが、データが大量にあればともかく、データが少ない場合はデータ取得のコンテキストを熟知していない限り打ち手が限られ、データ水増しなどの判断も性能評価が確かであることを前提に行うことになります。最終的に性能評価がAI機能開発の主軸となり、性能評価によってフロー全体の改善ポイントが明確になるだけでなく、どのような課題にどの程度適用できるかも見えてきます。特に後者はAI機能をプロダクトとして提供する観点では必ず確認しなければならない部分です。

ということで、現在私が取り組んでいるところはAI機能の性能評価基盤の構築です。 SmartHRではプロダクトとして提供中の機能にAI履歴書読み取り機能があり、開発の舞台裏でも触れられていますが、AI機能のリリースと改善には性能評価が欠かせず、このスピードが事業の課題改善スピードに繋がります。MLOpsやLLMOpsとも関連しますが、この領域はベストプラクティスがまだ確立されておらず、これらの基盤を構築することはとてもチャレンジングかつ面白さを感じて取り組んでいます！

他には半ば趣味的な話ではありますが、Slackの部活_機械学習勉強部という部活に参加し、毎日キャッチアップしているLLM関連の最新論文の要約を投稿しています。 SmartHRにはRuby界ツヨツヨの方々も多く、プロダクト開発面の文化は成熟している印象ですが、研究開発/サイエンス的な文化はあまり浸透していないように感じます。一緒にこれらの領域を牽引していける仲間も募集しています！

今後やりたいこと

労務はすべての会社で必須の業務でありながら、個人から組織というスケールまで繊細な気を配る負担の大きい業務です。一方でそれはある一つのソリューションが様々な会社への適用可能性があり、多くの労務担当者の負担軽減、そして究極的には日本のGDPを改善しうる可能性を秘めていると考えます。

私、MLエンジニアとしてもこの適用可能性の広さとインパクトの大きさは魅力に感じており、AIを活用したこれまでにないソリューションの実装、またそれがエンジニア以外の人でもできる基盤作りに挑戦していきたいと考えています！ SmartHRはこれからマルチプロダクト化でどんどん機能拡充もされていくため、MLエンジニアの採用というのはもちろんですが、ドメインの知識は豊富だけどAI開発なんて……という方でも機能が作れていくような仕組みが必要と考えます。私自身も日々キャッチアップしながらではありますが、目指すは日本最大の労務AI基盤です！