ない業務を作るということ〜採用管理システムの提供機能拡大への挑戦〜【プロダクトマネージャー勉強会/イベントレポート】

※この記事は、2026年2月に開催されたイベントでの発表内容をレポートしたものです。

今回の取り組みの紹介
- sonar ATS by HRMOSの進化
スタート時の状況　〜進めていくうちにわかった課題
- スタート時の状況
- ない業務を作るということ
解決策
まとめ

登壇者はこの方

増井悠太

Thinkings株式会社
Product Management Dept

新卒でThinkings株式会社に入社し、エンジニアとして採用管理ツールsonar ATSの連携機能開発を担当。その後、2024年よりプロダクトマネージャーを務める。

増井：本日は「ない業務を作るということ〜採用管理システムの提供機能拡大への挑戦〜」というタイトルで発表させていただきます。Thinkings株式会社でPdMをしている、増井と申します。経歴としては、もともとソフトウェアエンジニアとしてキャリアをスタートし、2年前からPdMとして採用管理システム「sonar ATS by HRMOS（以下、sonar ATS）」を担当しています。

弊社のメインプロダクトである「sonar ATS」は、2012年にサービスを開始し、累計2,400を超える企業や官公庁に利用され、成長を続けています。領域としては、採用管理システム（ATS）という形で機能を提供しています。また、直近では「sonar Connecter（コネクター）」というプロダクトも展開し、ATS以外の採用領域にも提供範囲を広げています。

今回の取り組みの紹介

sonar ATS by HRMOSの進化

今回の取り組みのテーマとして、ATSを起点とした「組織づくりを支援するプロダクト」への領域拡大を進める中で、一つの課題が生まれてきました。それは「リアルな求人情報を可視化したい」という社内のニーズです。

なぜ可視化が必要なのかという点ですが、採用領域において、求人や職種のリアルな業務要件、あるいは採用要件をデータとして扱える状態にすることが、組織づくりの基盤につながると考えたからです。採用業務において「どういった人が欲しいのか」という要件を定義する際、その前提として「実際にどのような業務が行われていて、それにはどのようなスキルが必要か」という実態を把握する必要があります。それらを踏まえて採用要件や評価基準を作っていくため、リアルな情報がなければ質の高い採用は実現できないのではないか、というのが今回の取り組みの出発点です。

こうしたリアルな情報を取得するため、まずは既存の業務を参考にしました。具体的には、外部の人事コンサルタントが実施していた業務ヒアリングやワークショップをベースに、それをプロダクト化することで業務情報を収集できるのではないかという仮説からスタートしました。

スタート時の状況　〜進めていくうちにわかった課題

スタート時の状況

プロジェクト開始当初に決まっていたのは「既存のセッションを参考にプロダクト化できないか」という点だけで、それ以外の詳細は何も決まっていない状態でした。まずは既存のセッションでどのようなことが行われているかをヒアリングし、プロダクトに落とし込む作業から始めました。

既存のセッションでは、人事コンサルタントが現場メンバーとのワークやヒアリングを通じて、業務内容や必要なスキルの把握、さらには上位のミッションや職責の把握を行い、それらを採用要件へと落とし込んでいく流れを実施していました。これをプロダクト化しようと進めた結果、現場のユーザーが自分の業務を対話的に入力・選択して構造化できるツールが出来上がってきました。

ない業務を作るということ

しかし、開発を進めていくうちに、改めて3つの大きな課題が見えてきました。

技術的な課題: シンプルに、人間が行っている業務をAIで安定して実現できるのかという点です。また、採用要件という正解がない領域に対して、どうゴールを設定し評価していくのが正しいのかという点が課題となりました。
市場的な課題: 海外ではジョブ型雇用が進んでおり、職務記述書（JD）が整備されているケースも多いですが、日本においては業務情報や採用要件を定義するプロセス自体が確立されていません。そのため参考になる事例も少なく、明確な業務フローも存在しないため、既存業務のDX化というアプローチでは実現が困難でした。
個人の課題: 私自身の課題として、これまでは「既存の業務や目的がある前提で、その不便を解消する」という形で企画開発を行ってきましたが、今回のように「ターゲットとなる業務フローが存在しないテーマ」に対し、どう取り組めばいいのかという葛藤がありました。

解決策

解決策① 広くためす ─ 技術的な課題

一つ目の技術的な課題に対しては、シンプルに「広くためす」ことにトライしました。 AIにアウトプットを任せる部分は、やってみなければわからないという側面が大きく、また初期段階では私たち自身も正解を定義できていませんでした。

そのため、多様な職種やペルソナで小さく試しつつ、様々なプロンプトや仕組みを検証しました。そこで得られた様々なアウトプットを比較しながら、徐々に外堀を埋めていくような形で、当初は見えていなかった正解の輪郭を定義していきました。

解決策② 高速に作って捨てる ─ 市場的な課題

続いて、2つ目の「市場的な課題」、つまり前提となる業務フローが存在しないという点への対応です。これに対しては「高速に作って捨てる」という開発手法で臨みました。

今回、前提となる業務フローが存在しないため、私たちが新しく業務フローを設計する必要がありました。これまでは人事コンサルタントという「人」が介在していたからこそ、強制力やインタラクション（相互作用）によって担保されていた部分を、いかにプロダクトだけで再現するかが重要でした。そのため、ユーザー体験（UX）には非常にこだわる必要がありました。

こうした、あらゆる要素が曖昧な段階では、緻密な要件定義に時間をかけるよりも、まずは小さく作って試す、そして自分たちで触ってみて検証するという決断をしました。幸い、プロトタイプを作る段階からAIを活用していたため、高速に作って捨てるというサイクルを繰り返すことができました。

具体的には、スライド右側の図（※一部加工しています）のように、いくつかのUIパターンを実装しました。実際に使ってもらい、フィードバックを得ては収束させていくという形で開発を進めました。

この手法は試行錯誤こそ多かったものの、机上で要件をあれこれ詰めるよりも、実際に動くものを使って改善ループを回せたことで、結果としてゴールにたどり着くのは早かったと感じています。また、自分自身で素早く思いついたアイデアを検証できたため、個別の課題で迷った際も納得感を持って判断することができました。

ここで重要だったのは、「あれこれ欲張らずにゴールを明確にし、柔軟にスコープ調整をすること」です。実際に動くものがあると、UIの細かい部分が気になったり、検証中に「ここも検討しきれていないのでは？」と新たな課題が出てきたりします。そのため、しっかりとゴールを定義しつつ、検討ポイントは適宜スコープを分けるなど、迷わないための調整が重要であると考えています。