はじめに
こんにちは、HERPで開発組織の責任者をしている佐々木 
id:taketo957 です。
2025年に公開した HERPで技術責任者になってから1年半を振り返る では、組織を「守り」から「攻め」へと移してきた話を書きました。あれから半年強。HERPの技術組織は、守りを一定形にしつつ、いまは「攻めを可能にする組織能力の向上」に重心が移っています。
このフェーズの転換は、これまでで一番面白く、そして難しい局面だと感じています。「やらなきゃいけない」を片付けるフェーズから、「どこに賭けるか」を組織として一緒に考えるフェーズへの移行。その途中で見えてきた課題を、ここで一度整理しておきたい、というのが本記事の動機です。
本記事では、いま取り組んでいる重要技術課題を8つと、それらを貫く立場表明（AI時代のマニフェスト）を紹介します。スマートバンクさんの Technological Challenges 2026 を参考にしました。
- はじめに
- 本記事の構成
- HERPがいま立っている場所
- 【Part 1】データとAIを武器にする
- 【Part 2】ドメインとプロダクトを支える設計
- 【Part 3】守りと攻めの両立
- 【マニフェスト】AI時代に、HERPが選ぶ立ち位置
本記事の構成
8つの課題は、3つのパートに分けて整理しました。
- 【Part 1】データとAIを武器にする — AI時代における「攻め」の実装
- 【Part 2】ドメインとプロダクトを支える設計 — その「攻め」を支える土台
- 【Part 3】守りと攻めの両立 — 両方を持続させる仕組み
前回記事で書いた「守り→攻め」の延長線で、いまHERPがどこに賭けているか・その賭けはどんな土台の上に立っているか・両者をどう両立させていくか——という視点で並べています。
HERPがいま立っている場所
技術課題の話に入る前に、HERPがどんな立ち位置でこれらに向き合っているかを整理しておきます。
HERPはミッション「採用を変え、日本を強く。」、ビジョン「すべての採用における意思決定を、その次の挑戦を生み出すものに。」を掲げています。これらを実現するための手段として、現在、以下の2軸のアプローチで5つの事業を走らせています。
- 採用管理SaaSとして、企業の採用業務を効率化する（HERP Hire / HERP AI Recruiter）
- マッチングプラットフォームとして、企業と求職者をつなぐ（ジョブミル / HERP Career / 面談オファー）
そしてこの2つを横断するレイヤーとして、データ基盤を含むプラットフォームがあります。この基盤の上で、採用ドメインのデータを活用して新しい価値を生み出すことに、いま試行錯誤しています。
開発組織（PDT、約30名）の正式な構成は下図のとおりです。
製品事業を担う Company 系列（HERP Hire / HERP AI Recruiter）と Matching 系列（HERP Career / ジョブミル など）、横断基盤を担う Platform 系列（開発生産性の DevPlatform、データ基盤の DataPlatform）、そして組織戦略・技術戦略を担う Engineering（他社でいう CTO 室にあたる役割）で構成されています。各章で言及する「取り組んでいる人」のチーム名は、この組織構造のいずれかに属しています（セキュリティ・コンプライアンスは Platform 系列を中心に横断的に動くファンクションです）。
そしてこれらの事業群と組織は、HERPがこれまで採用ドメインに向き合い続けてきた中で形になってきたものです。HERP Hire の累計3,000社以上の導入で蓄積されてきた採用ドメインの知識、それを実装し改善し続けてきたメンバー、すでに複数プロダクトを同時に走らせている事業ポジション——これらが土台にあるからこそ、AI時代に新しい価値を生む仕事に踏み込めるのだと感じています。
これらの交点で立ち上がる課題を、「採用を自分ごとにできる開発組織」で解きに行きます。これがHERPで働く面白さだと思っています。
『採用を自分ごとにできる』とは、エンジニアが採用ドメインを自分の仕事の核として理解し、設計し、意思決定できる状態を指します。詳しくは記事末尾のマニフェストで書きますが、これがHERPの組織像の中核にあります。本記事の8課題は、すべてこの交点から出てきたものです。
【Part 1】データとAIを武器にする
1. マッチング精度を進化させるデータ基盤を構築する
取り組んでいる人: DataPlatform、マッチング系プロダクトチーム
HERP Hire は累計3,000社以上の採用企業に導入されており、求人を中心とした、さまざまな採用アセットが蓄積されています。これらをプロダクト横断で活かし、マッチング精度につなげること。これが今期の最重要テーマのひとつです。
具体的に動いているのは、
- プロダクト横断での、求人を中心とした採用アセットの共通化(共通アセット化)
- マッチング系プロダクト(HERP Career / ジョブミル)で、意味ベクトル検索(pgvector + Cohere embed-v4)と BM25+ ベースの独自エンジン という異なる技術スタックでマッチングを実装中。これらのレイヤをどのように他の事業に活かすかという検討が進行中。
- アセットを横断的に活かすための権限設計やプライバシー設計
スキーマ設計・権限設計・プライバシー設計・モデル管理が一筋に絡み合い、ひとつの設計判断が事業の上限を左右します。データに関するエンジニアリングが事業構造の設計に直結する段階に、HERPのマッチングプラットフォームはいま入りつつあります。
2. 生成AIを採用プロダクトに組み込む
取り組んでいる人: HERP AI Recruiterチーム、各プロダクトチーム
採用領域には、履歴書・職務経歴書・面接の会話ログ・評価コメントなど、従来のシステムでは構造化しづらい非構造データが大量にあります。HERPの各プロダクトでは、生成AIを使ってここに切り込んでいく取り組みが進んでいます。
中心となっているのが HERP AI Recruiter で、面接の文字起こしとAI要約、AIチャットによる対話型アシスタント、ワークフローに沿った自動処理（トリガー）など、採用業務のあちこちで生成AIが動いています。これに加えて、HERP Hire やマッチング系プロダクトでも、それぞれの業務文脈に合わせた生成AIの組み込みが個別に進行しています。
ここでは、HERP AI Recruiter で実装している技術的なチャレンジを中心に紹介します。
- 構造化出力の型強制：LLMの出力を機械検証可能なスキーマで縛り、形式に合わないものは下流に流さない設計
- ツール呼び出しによる工夫：候補者・面接・求人といったエンティティをLLMに直接書かせず、内部API経由で取得した実データを根拠にだけ生成させる
- LLMは Amazon Bedrock 上の Claude を中心に、面談周辺は音声認識・ミーティングボットなど複数の外部基盤を組み合わせて実装
- プロンプト・評価データの継続改善サイクル
- 人のフィードバックを #1 のデータ基盤に還して、マッチング精度向上につなげる仕組みなどは模索中
LLMを用いての出力に関して、なぜその出力が正しいと言えるのかという部分には、業界全体でまだ確立途上の方法論しかないと思ってます。HERP AI Recruiter はここに、採用という説明責任の重い領域から向き合っています。
3. 開発プロセスそのものをAIで変える
取り組んでいる人: DevPlatform、全エンジニア
HERPでは、社外向けにAIプロダクトを作るだけでなく、社内の開発プロセスにもAIエージェントを組み込んでいくことを組織方針として掲げています。
狙いは、開発プロセスそのものを「改善可能な対象」として扱い、改善のフィードバックサイクルを高速に回すことです。既存のプロセスを固定の制約として受け入れるのではなく、プロセス自体を書き換えながら開発できるようにする、というスタンスです。
- Cursor / Devin / Claude Code などのAIツールを業務に組み込み、各自が試した活用パターンを共有している
- Linear を中心に既存事業の業務プロセスの型を整え、AIが動ける土台を作る
- AIがコードレビューなどに参加できる仕組みを検討中
- 今後は、開発業務に閉じないAI活用（採用オペレーション / データ分析 / 意思決定支援）へ広げていく
「社外向けAIプロダクト（HERP AI Recruiter）」と「社内向けAI運用」が連続していること、これがHERPの強みになります。社内で得た知見がプロダクトに、プロダクトの学びが社内に還ります。この循環を回していきたいです。
【Part 2】ドメインとプロダクトを支える設計
4. HRドメインの複雑性を技術で解く
取り組んでいる人: 各プロダクトチーム
採用管理システムは、外から見ると定型化された業務システムでは？と思われがちですが、実際にコードを書きはじめると、ドメインモデリングの腕がそのまま試される領域だと思います。
- 標準業務フローが存在せず、企業ごとに選考ステップ・評価軸・オペレーションが大きく違う
- 法的制約（個人情報保護 / 職業安定法 / 労働関連法）や景気動向といった外部要因が変わる
- 求人票・履歴書・職務経歴書・面接ログなど、扱う情報の中心が非構造データ
- 採用企業(人事 / 現場採用担当) / 求職者 / エージェントと、ステークホルダーが多い
加えて、採用管理SaaS（HERP Hire / HERP AI Recruiter）はN=1の候補者体験を重視するプロダクト思想で設計されてきました。一人ひとりの候補者にとって最適なフローを届けるため、データスキーマもフロー設計も柔軟性を最大化する方向で組まれています。一方、マッチング系のプロダクト（HERP Career / ジョブミル / 面談オファー）では、求職者と求人を意味的に近づけるための別軸のドメイン課題が立ち上がります。同じHRドメインでも、向き合う複雑性のかたちは段違いです。
「パターンにはまらないことがパターン」という逆説的な世界観だと思っています。ここに対して、ドメイン駆動設計と、生成AIを活用して「非構造データを構造化して扱う」アプローチを組み合わせて向き合っています。「どこを変動する点として残すか」を設計判断で決め続けるこの仕事は、ステークホルダーが多くドメインが変動し続ける採用領域のSaaSの面白さのひとつだと思っています。
そして、SaaS逆風と言われるこの時代こそ、HRドメインのように複雑性が高くAIだけでは構造化しきれない領域では、SaaSの役割はむしろ広がっていくと考えています。業務の型を提供するだけのプロダクトから、業務のなかで生まれる非構造データを構造化して資産化する基盤、そしてAI時代の意思決定を支える基盤へと変わっていきます。HERPはこの可能性を、HRドメインで形にしていきたいと思っています。
5. マルチプロダクト戦略におけるアーキテクチャ
取り組んでいる人: Platform / 各プロダクトチーム
HERP Hire / ジョブミル / HERP Career / HERP AI Recruiter / 面談オファーと、いま複数のプロダクトが同時に走っています。マルチプロダクト戦略には独特のアーキテクチャに関連する課題があります。
- 扱うドメインがプロダクト間で一部重複している(求職者・求人は最終的にどのプロダクトでも出てくるなど)
- 新規事業を最短で立ち上げるための共通基盤が必要(開発運用 / 認証などの共通部分など)
- 共通化と機動力のトレードオフ
具体的には、開発運用基盤の構築・共通認証基盤検討・求人アセットの切り出し・データ基盤の構築・マッチングシステムの整備が動いています。特徴的なのが LandingZone と呼んでいる新規事業立ち上げ用の仕組みです。新サービスを始めるときに必要な AWS アカウント・Datadog・CD などの初期セットを、まとめて1パッケージで立ち上げられるようにしたもので、事業が増えていくことを見越して整備してきました。
「ガバナンスと自由度のバランス」というありふれた言葉の裏には、どのレイヤを共通化し、どのレイヤを各事業に任せるかという設計判断が無数にあります。マルチプロダクトのSaaS企業に普遍的なこの設計問題に、HERPは事業の最前線で向き合い続けています。
6. コンポーネント境界を引き直す — HERP Hireの分散モノリス解消
取り組んでいる人: HERP Hireチーム
長く運用してきたプロダクトで何度も向き合うことになるのが、コンポーネント境界の引き直しです。HERPでもこの設計仕事は複数のテーマで並走していますが、いま中心になっているのが HERP Hire の分散モノリス解消です。
HERP Hire は、長年の進化のなかでマイクロサービス的に分割されてきましたが、結果的に分散モノリスになっています。
- 認証をはじめとする基盤コンポーネントが Haskell で書かれている
- 複数サービス間の依存が絡み合い、独立デプロイがしづらい
- デリバリ速度を上げるには、Haskell資産を活かしながら、複雑化したコンポーネントの境界と依存関係を引き直す必要がある
経緯と現状認識は、HERP Hireチームの reimaru が書いた以下の記事に詳しいです。
このほかにも、散在した通知・イベントコンポーネントの整理など、同じ構造の「境界引き直し」課題が並走しています。マイクロサービスの分割粒度をめぐる「分けすぎた / 足りなかった」は、いまや業界全体の論点です。それに対して、自分たちで答えを出していく仕事が、HERP Hire ではいま動いています。
そしてこの仕事の成果は、後述する #8 の Four Keys 指標をはじめ、#1 のデータ基盤など様々な部分に効いてきます。
【Part 3】守りと攻めの両立
7. マルチテナントSaaSのセキュリティと日常的コンプライアンス運用
取り組んでいる人: Securityチーム、DevPlatform
採用情報は、究極に機微な個人情報（PII）です。HERPはこれをマルチテナントのSaaSで扱っているからこそ、セキュリティとコンプライアンスを「後から追加するもの」ではなく「設計段階から組み込むもの」として運用しています。
- PII暗号化・保管期間ポリシーなどの日常運用の徹底
- ISO27001 / 27017 取得済。準拠のプロセスを開発フローに組み込み年単位で改善している
- 外部の専門ベンダーによる脆弱性診断の定期実施
- 法務・セキュリティを開発の早い段階から巻き込む体制を模索中。とくにデータの扱いについては、機能要件・設計の段階から法務と協働する開発フローを作っていきたい
漏洩は即、事業終了レベルのリスクです。守りを開発スピードとの両立前提で実装できているかが、そのままプロダクトや会社の信頼につながると考えています。採用情報という重要なPIIを扱う事業特性のため、地味に見える運用の積み重ねが、HERPの事業継続性を支えています。
ブログに書ける範囲は限られていますが、普段の開発で実践している運用は多くあります。気になる方は、ぜひカジュアル面談で質問してください。
8. 開発生産性の可視化と、事業責任者との目線合わせ
取り組んでいる人: DevPlatform、全プロダクト開発チーム
前回記事でも触れた DORA / Four Keys の取り組みは、全事業で「数字が出せない状態」から「数字が出せる状態」までは一通り持ってこれました。次のフェーズは、出てきた数字の中身を良くしていくことです。「計測」から「意思決定への接続」へ進んでいます。
- 全事業（HERP Hire / ジョブミル / HERP Career / HERP AI Recruiter / 面談オファー）で Four Keys（デプロイ頻度 / リードタイム / 変更失敗率 / MTTR）を可視化
- 事業責任者と開発チームが同じ指標で議論できる文化づくり
- 直近は HERP Hire の指標改善に集中投資（#6 のアーキテクチャ刷新で、HERP Hireの数字改善などの成果が出てきている）
- Cursor / Devin / Claude Code などAI投資の効果を、生産性指標で確認する
HERP Hire では、DevPlatform と HERP Hireチームが連携して始めた「プロジェクト管理ツールを睨む会」を起点に、Linear でプロジェクト粒度・マイルストーン・非機能要件チェックリストを整備し、Four Keysのデプロイ頻度を1ヶ月で2倍まで伸ばしました。その経緯は azoson が以下の記事にまとめています。
もうひとつ大事なのが、HERP Hireチームが日々積み重ねている技術的負債の返却が指標に効いてきていることです。プロセス改善と地道なコード改善、その両輪を回すことで実際に数字が動いています。
次は計測すること自体ではなく、計測を意思決定につなげる文化を育てていることを目指しています。
【マニフェスト】AI時代に、HERPが選ぶ立ち位置
ここまで8つの技術課題を並べてきました。最後にひとつ、課題ではなく立場表明として書いておきたいことがあります。
AIによって、コードを書く・設計する・レビューするといったエンジニアリングの基礎動作は、急速にコモディティ化していくと考えています。一定水準のアウトプットを誰でも出せる時代に、ソフトウェア企業の差別化要因はどこに残るのでしょうか。
現状のHERPなりの答えは、「ドメイン理解の深さ × 組織の自律性」です。AI時代に何で勝つのか——開発組織の責任者になってから考えてきた問いに対する、現在の答えがこれです。
採用ドメインはAIで構造化しきれないほど複雑で、企業ごとの違いも外部要因の変動も大きい領域です。ここで勝ち続けるには、採用ドメインを深く理解しているエンジニアが、自律的に意思決定し続けられる組織であり続けるしかありません。この組織像を、私たちは「採用を自分ごとにできる開発組織」と呼んでいます。
そしてこの組織像は、組織側の取り組みだけでは実現できないと考えています。エンジニアが自律的に意思決定し続けるためには、ドメイン理解を深める時間、意思決定を高速に検証できる開発環境、計測と判断を結びつける指標などの基盤——それらを可能にする技術的な土台が必要になります。だからこそ私たちは、これを「組織投資の対象であり、同時に技術投資の対象」だと捉えています。
これはHERPがAI時代に勝つための戦略上の中核だと思っています。具体的には、以下のような実装を進めています。
- エンジニアが事業や市場・ユーザーの課題を肌で感じる機会としての採用関与（ノルマではなく、価値創出の活動として設計する）
- エンジニアの面接で「その求人で解決したい問題を抽象化した環境や設定」をつくるなど、実際の課題に基づいた選考体験の設計
- 自分たちの採用業務を、自分たちのプロダクト（HERP Hire / HERP AI Recruiter など）で実行する。ドッグフーディングそのものが、プロダクト品質と採用成果を両立させる仕組みになっている
技術投資と組織投資を分けて考えるのではなく、技術投資によって組織の行動様式を変えていく試みだと思ってます。AIが書けるコードの量は増え続けます。それでも残るもの——ドメインへの深い理解と、組織として自分の頭で意思決定し続ける力——を、HERPは技術で支え続けたいです。
ここまで並べた8つの技術課題は、すべてこのマニフェストにつながる実装だと思っています。
おわりに
ここで紹介した8つの課題は、それぞれ独立して見えても、根底には「採用を自分ごとにできる開発組織」という組織像があり、互いに絡み合っています。ひとつ解いて終わり、という性質のものではありません。
だからこそ、HERPで活躍するエンジニアには、コードを書く力に加えて、ドメインを設計する力、事業とつなぐ力、組織を動かす力が同時に求められます。逆にいえば、それらを総合的に伸ばしたい方にとっては、よい環境だと思っています。個人的にも、いま採用というドメインで、この組織と仕事できていることが、純粋に楽しいです。
ここまで読んでくださってありがとうございました。 8つの課題のなかで、ひとつでも「もう少し詳しく聞いてみたい」と引っかかるものがあれば、ぜひ以下のHERPのエンジニアとカジュアル面談からお気軽にご連絡ください！
id:susisu
id:wtatsuru
id:ikesyo
id:taketo957
id:masayoshi