採用DXの事例｜既製品が合わず、逃げた先はもっと重かった。制作会社の内製ツール

採用DXという言葉は、たいてい「良さそうなツールを選んで入れる話」として語られます。ですがGrowGroup株式会社が自社の採用業務をDXしたとき、実際に起きたことは、それとはずいぶん違うものでした。

私たちはまず、既製の採用管理システムを導入して、実際に使っていました。合わなかったので、そこを離れてドキュメントツールに移りました。そしてその先が、もっと重かったのです。最終的に自社で作ることになりました。

この記事は、その内製ツール「GrowATS」の記録です。製品として売っているものではありません。お伝えしたいのは機能ではなく、「採用という業務をどう分解し、何のために作り、何を作らないと決め、何を作ってから捨てたか」という判断のほうです。結果として何が変わったのかも、最後に書きます。削減時間は測っていません。それでも、変わったことは2つあります。

そして最初に、いちばん大事な前提を書いておきます。私たちが欲しかったのは「採用を上手に管理できる状態」ではありませんでした。欲しかったのは、応募してくださる方の母集団を増やし、その質を高めることに時間を使える状態です。管理は、そのために払わされているコストでしかない。採用DXの目的を「管理の効率化」に置いた瞬間、たぶんこの話は違う場所に着地していました。

背景：既製品が合わず、逃げた先は、もっと重かった

順を追います。GrowGroupの採用は、いきなり内製から始まったわけではありません。三段階の経緯があります。

ここは、はっきり書いておきたいところです。私たちは既製品を「検討して却下した」のではありません。買って、入れて、使ったうえで、合わなかったのです。カタログ比較の話ではなく、運用してみて初めて分かったことでした。

「合わない」の正体は、機能不足ではない

既製の採用管理システムは、よくできています。機能が足りないから困ったのではありません。困ったのは自社の選考フローと形が合わないことでした。

採用のやり方は、会社ごとに驚くほど違います。誰が最初に見るのか、どの段階でマネージャーに渡すのか、どういう場合に「保留」にして、その保留はいつ誰が拾うのか。製品はどこかの標準に沿って作られていますから、標準からずれている部分は、人間が運用で吸収することになります。そして吸収しきれないぶんは、製品の外に漏れ出します。表計算に控えを作る、チャットで補足する、頭の中で覚えておく——こうして「管理システムを入れたのに、管理システムの外に本当の情報がある」状態ができあがります。

だから私たちは、そこを離れました。自由に形を作れるツール、つまり汎用のドキュメントツールへ。当然の判断だったと思います。合わない型に業務を押し込むより、自分たちの形に道具を合わせるほうが正しい、と。

自由の代償は、管理コストだった

そして、逃げた先が、もっと重かった。

汎用のドキュメントツールは、たしかにどんな形にもできます。ですが「どんな形にもできる」は「形を維持するのが全部あなたの仕事です」と同じ意味でした。項目を足すのも、状態を更新するのも、整合を保つのも、全部人間の手作業です。製品なら製品側が引き受けてくれていた雑務が、まるごとこちらに戻ってきます。

結果として、管理コストの手間が、非常に高くなりました。しかも、この重さは目に見えません。1件あたりは数分ですから、誰も問題として報告しないのです。

この経緯には、多くの会社に当てはまる構図があると思っています。既製品が合わない → 自由なツールへ逃げる → 自由の維持費を払い続ける。そして維持費を払っている自覚がないまま、年単位で時間が溶けていきます。

4つの場所を、人間が行き来していた

内製に着手した時点の運用を、要件定義書は「4系統の横断」と表現しています。

要件定義書の一文が、負荷の正体を言い当てています。「データが分散し、転記・調整の手作業が負荷の中心」。

ここが重要です。重かったのは、採用の判断ではありませんでした。誰を通すか、誰に会うか、どうすればもっと良い方に来ていただけるか——そういう本来やるべき仕事ではなく、4つの場所を人間が行き来して、同じ情報を打ち直して繋いでいる作業が、負荷の中心を占めていた。

しかも、この体制を担っていたのは人事総務を兼任しているごく少人数のメンバーです。専任チームがあるわけでも、採用だけを見ていられるわけでもない。それでいて応募エントリーは年間で1,000件を超える規模に達していました。片手間で回すには、明らかに量が多すぎたのです。

私たちが解こうとしたのは、この「人間が糊になっている状態」でした。

課題：選考の状態が「14個のチェックボックス」になっていた

ただ、転記の多さは症状であって、原因ではありませんでした。要件定義の調査で、もっと根の深いことが判明します。

選考の状態を管理していたドキュメントツールのデータ構造が、壊れていたのです。

• 選考のステータスが、14個のチェックボックスで表現されていた。「書類選考中」「一次面接済」といった状態が、択一の項目ではなく、独立したチェックの束になっていた
• 候補者の一覧が、複数並存していた。どれが正なのかが決まっていない
• 「辞退」の定義が整理されていなかった。本人が辞退したのか、こちらが見送ったのか、連絡が途絶えたのか——同じ扱いになっていた
• 結果として、歩留まり・通過率・辞退率といったKPIが、そもそも集計できなかった

チェックボックス14個は、一見すると柔軟です。運用しながら項目を足していけば、自然にこうなります。誰も間違ったことはしていません。しかしチェックが複数同時に立ち得る構造では、「この候補者は今どの段階にいるのか」という問いに、機械が答えられません。人間が目視で解釈するしかない。だから集計できないし、集計できないから改善もできない。

これが、先ほどの「自由の代償」の正体です。汎用のドキュメントツールで業務を回すと、最初は速い。しかし業務の状態を表現する構造は、足し算を繰り返すうちに必ず壊れます。そして壊れたことに気づくのは、たいてい「数字を出そうとしたとき」です。母集団を増やしたい、質を上げたいと思っても、どこで落ちているのかが分からない。手の打ちようがない。

負荷を解消すべき3領域と、死蔵していたデータ

要件定義では、最初のバージョンで解消すべき負荷を、3つに絞っています。

1. 入力作業——メールから応募データを手打ちで転記している
2. 書類選考時の判断——グレーゾーンの人間判断に、何の支援もない
3. 書類選考通過後の報告作業——マネージャーへ伝えるために、別ツールへ書き写している

この3つは、いずれも「採用の質を上げる仕事」ではありません。①と③は完全な事務であり、②だけが本来の仕事です。本来の仕事が、事務に挟まれて薄くなっている——これが解くべき形でした。

もう一つ、開発中に見つかった課題があります。「気になる」「興味あり」といった段階のリード（まだ応募には至っていない接触）に、まったくアプローチできていませんでした。母集団を増やしたいという話をしているのに、すでに手元にある「あと一歩の人」に触れられていなかったわけです。

しかも正確に言うと、AIによる分類そのものは「これは興味段階だ」と判定できていました。ところが、その判定結果がどの画面にも表示されていなかった。データは存在するのに、誰の目にも触れないまま死蔵していたのです。

「AIに分類させる」ところまでやって満足し、「その結果を人が見る導線」を作り忘れる——AIを業務に入れるときの、非常にありふれた失敗です。私たちも普通にやりました。

目的：管理をラクにするためではない。母集団と質のためだ

ここが、この記事の背骨です。

三段階の経緯を並べると、「管理がうまくいかないので、管理ツールを作った話」に見えます。違います。私たちが内製に踏み切った理由は、応募者の母集団を高めることと、その質を向上させることに、重きを置きたかったからです。

言い換えれば、「管理に時間を取られている場合ではない」ということでした。

この違いは、実務上とても大きい。目的を「管理の効率化」に置くと、判断基準は「作業が速くなるか」になります。すると、細かく便利な機能をいくらでも足したくなる。一方、目的を「母集団と質」に置くと、基準はこう変わります。

• それは、担当者が母集団づくりに使える時間を増やすか？
• それは、応募してくれた方への向き合いの質を上げるか？
• それは、良い方を取りこぼす確率を下げるか？

この3つに「はい」と言えないものは、どれだけ便利でも作らない。そして実際、この基準のせいで、作ったのに捨てた機能がいくつもあります。後述します。

「一元化する」と「構造に合わせない」

実装レベルの目的は、要件定義に一文で書かれています。「採用業務を一元化・自動化する。ドキュメントツールとタスク管理ツールは採用業務から廃止し、GrowATSで完結させる」。「併用する」でも「連携する」でもなく「廃止する」と書いてあるのがポイントです。逃げ場を残すと、情報は必ずそちらに漏れます。

そしてここで意識的に選んだのが、「既存の構造に合わせない」ことでした。壊れた14個のチェックボックスを、そのまま新ツールへ移植することもできました。移行は楽です。しかしそれでは集計できない構造ごと引っ越すだけです。だから選考プロセスとして正規化し直すと決めました。それまでの運用を、あえて尊重しないという判断です。

面白いのは、これが第1段階の既製品と同じことを、自分たちにやっている点です。既製品は「標準の型に業務を合わせろ」と言ってきて、私たちは合わせられなかった。今度は自分たちで型を決めて、そこに業務を合わせにいく。違いは、型を決める権利が自分の側にあることだけです。ですが、その違いがすべてでした。

過去の応募者データも移行していません。進行中の選考は旧環境で終わらせ、新しい応募から新しい仕組みに流す。古い水が抜けるのを待つ方式です。移行を完璧にやろうとして頓挫するくらいなら、明日から新規だけでも乗せ替えるほうが早い——業務システムの入れ替え全般に言えることだと思います。

「作る＝一気に、出す＝安全に」

リリースの方針も、明文化されています。「作る＝一気／出す＝安全に」。全工程を実装しきったうえで、有効化は段階的なフラグで制御し、危険な箇所は最後まで人を残す、という考え方です。

裏返しとして、「一部の工程だけを先行リリースしない」とも決めています。理由が実務的です。先行リリースをすると、担当者は新ツールと旧ツールを併用することになる。効率化のために作ったものが、併用期間中はむしろ手数を増やす。すでに管理コストで潰れている相手に、さらに二重運用を強いることになる。それなら全部揃うまで出さないほうがいい、という判断でした。

AIの役割にも、最初から線が引かれています。「AIは判断を代行しない」。AIが出すのはスコアと、その根拠と、推奨アクションまで。それを優先度順に並べて人に見せる。決めるのは人です。自動での見送り処理もありますが、「確定済み」「人事が確認済み」「高信頼度でAIが抽出した」場合にのみ発火する安全装置を噛ませています。

817コミットの大半は、作り直しだった

GrowATSは817コミットで、自社開発ツール9本のなかで最大になりました。しかもそのうち801コミットが、約2ヶ月弱に集中しています。

コミット数を出したのは、開発量を誇るためではありません。この山の中身が何だったのかを見たとき、採用DXの本当の姿が見えたからです。

先に結論を書きます。この作り直しは、迷走ではありません。目的（＝良い方を取りこぼさず、母集団と質に時間を使う）に照らして、手段のほうを捨てていった記録です。

5月に作った仕組みを、6月に全部捨てた

最大の作り直しは、応募データの取り込み方式です。

5月時点の設計は、サーバー側で求人媒体の管理画面を自動巡回して、データを取ってくる方式でした。開発着手前に検証（PoC）まで実施し、「行ける」と結論して要件定義に反映しています。もちろん実装もしました。

そして6月、全6媒体ぶんを、まとめて退役させています。代わりに採ったのが、採用担当者のブラウザで動く拡張機能です。担当者が普段使っているブラウザ、普段のログイン、普段のネットワークからデータを取る。全6媒体で実機検証を終えたうえで、サーバー側の自動巡回は本番から撤去されました。

設計としては、拡張機能は「薄い転送層」に徹させ、判断や加工の頭脳はすべてバックエンドに置いています。手元のブラウザに賢さを持たせない、という切り分けです。

ここで捨てたのは、コードだけではありません。「完全自動で取り込む」という理想そのものを捨てています。開発中、当然のように「そもそも各媒体を完全に自動化して取り込めないのか」という話は出ました。その答えが「無い」ではなく「その方向に張るのをやめる」だった——ここが判断の芯です。完全自動化は、達成できれば美しい。ですがそれは母集団の質に一切効かない。効くのは「取りこぼさないこと」だけです。

作っては捨てた、6つの記録

並べると、たしかに迷走に見えます。実際、迷走した部分もあります。

ただ、この記録から学べることは「迷走するな」ではありません。むしろ逆です。要件定義の段階で正しく決めきることは、できなかった。PoCまでやって「行ける」と判断した方式が、実装して運用に近づけた瞬間に崩れました。一度「やらない」と決めた連携が、条件を見直したら成立しました。

つまり設計が正しかったかどうかは、作って動かしてみるまで分からない。そしてAIコーディングによって、「作って確かめて、間違っていたら捨てる」のコストが劇的に下がった。817コミットの正体は、その回数です。

逆に言えば、捨てられる前提で作らないと、この速さは危険です。「せっかく作ったのだから」で残した機能が、後から全部を縛ります。作り直しの記録がきちんと残っている（何を、なぜ捨てたか）ことが、速く作ることの唯一の安全装置でした。そして捨てる判断ができるのは、目的が一行で言えるときだけです。目的が曖昧なままだと、作ったものは全部「一応あったほうがいい」に見えてしまいます。

精度への投資をやめ、「見落とし回避」に資源を集中した

作り直しの連続に、一本だけ通っている軸があります。設計メモの言葉を借りれば、「壊れ得るコンポーネントの出力を、信用境界にしない」という思想です。

具体的には、こういう話です。当初、未処理の受信トレイを「AIが『これは応募ではない』と判定したものは、トレイに出さない」設計にしようとしていました。ノイズが消えて、担当者は本物だけを見られる。合理的に見えます。

ですが、事故のシナリオを書き出すと、こうなります。本物の応募をAIが高い確信度で「応募ではない」と誤判定する。その応募はトレイから消える。誰も見ない。しかも取りこぼし防止のために入れた重複チェックが「これは処理済み」と判断するので、再取り込みでも復活しない。結果、気づく方法がどこにも存在しない。

安全装置どうしが噛み合って、逆に事故を隠す構造です。

そこで採った結論は、候補者として登録されていない受信メールは、分類が何であろうと必ず人に見せるというものでした。ノイズは人が消します。その手間は1日あたり数十秒。対して見落とすコストは、応募してくださった方の信頼を、永久に失うことです。設計メモには、この非対称性がはっきり書かれています。だから常に、見落とし回避のほうに倒す。もっと直接的な言い方も残っています——「見落とし＝採用担当が二度と使わない＝致命的」。

そして、ここがこの記事でいちばんお伝えしたい部分です。

この結論が出たとき、普通の発想なら「では分類の精度を上げよう」となります。AIを使っているのだから、モデルを良くし、プロンプトを詰め、判定を賢くしたくなる。私たちはその逆をやりました。トレードオフの記録には、こうあります。

• 媒体の完全自動化を諦めた
• AI分類の高精度化への投資を諦めた
• その資源を、すべて「見落とし回避」に集中させた

理屈は単純です。分類の精度をどれだけ上げても、100%にはなりません。99%にしても、残った1%が見落としなら、致命傷の大きさは変わらない。精度への投資は、致命傷の確率をわずかに下げるだけで、構造は変えない。一方「全部人に見せる」は、見落としの経路そのものを消します。ノイズという代償と引き換えに。

ここでも効いているのは、目的の置き方です。目的が「管理の効率化」なら、ノイズを人に見せるのは明確な後退です。作業が増えるのですから。ですが目的が「良い方を取りこぼさないこと」なら、1日数十秒は安すぎる保険料になります。同じ設計判断が、目的次第で正解にも不正解にもなる。だから目的を先に決めるのです。

この結果、AIの役割は「判断者」から「どこまで自動で埋められるかを決める係」に降格しました。AIが抽出した内容は確定情報ではなく、「ヒント」として表示されるだけです。

同じ思想は、他の設計にも一貫して出てきます。権限の判断をAIにさせない（誰が何を見られるかは、データベースへの問い合わせの時点で構造的に強制する）。候補者の氏名をAIに改変させない。正本は常にGrowATSで、通知ツールは「お知らせと入口」に徹する。そして「網羅性」の定義そのものを、「全データを渡す」ではなく「必要なデータに到達できる」に置き換える。

すべて「賢くする」のではなく「壊れても致命傷にならない形にする」方向です。

作らないと決めたもの

同じ理屈で、作れたのに作らなかった機能があります。内製の落とし穴は、まさにここです。既製品なら「その機能はありません」で諦めますが、内製には歯止めがありません。自分で引くしかない。

「AIを増やすほど衝突リスクが上がる」は、AI導入の実務でとくに効く指摘だと思います。AIの出力を業務に足すたび、「AIの意見」と「人の意見」の食い違いを誰かが裁く仕事が増える。効率化のために入れたものが、判断コストを増やす。だから「同じ対象に、2つ目のAIの声を出さない」と決めました。

逆に、あえて承認ステップを置かなかったところもあります。面接記録の自動添付です。理由が実務的でした。承認ステップを置くと、添付一覧に埋もれて必ず漏れるため。形だけの承認は、安全装置のふりをした形骸です。守っているつもりで、実際は誰も見ていない。それなら置かないほうが正直だ、という判断でした。

AIの採点基準（ルーブリック）も、検証して選び直しています。甘い基準では★3が77%を占め、厳しい基準では★1が75%を占めました。どちらも役に立ちません。とくに厳しい版の問題は深刻で、候補者の質ではなく「提出資料の情報量の薄さ」を罰してしまうことが分かりました。これは母集団の質を上げる目的と、正面から衝突します。だから中庸の基準を採っています。

成果：2つの課題が、2つとも消えた（ただし時間は測っていません）

先に、書けないことを書きます。GrowATSによって採用業務が何時間減ったのか、私たちは測っていません。削減率も、処理件数の改善も、社内の記録のどこにも存在しません。だから書きません。

そのうえで、変わったことが2つあります。そしてその2つは、この記事の前半で挙げた2つの課題と、そのまま1対1で対応しています。

1つ目。転記がなくなりました。応募のメールを開いて、名前と連絡先と経歴を別の場所に打ち直す——あの作業が、日々の業務から消えています。何分減ったかは測っていませんが、「もうやっていない」ことは、時計がなくても分かります。

2つ目。歩留まりが見えるようになりました。どの段階で何人が抜けているのか。以前は、14個のチェックボックスを人が目で数える以外に方法がなく、事実上、誰も数えていませんでした。いまは構造として集計できます。

この2つ目のほうが、私たちにとっては大きい変化でした。採用DXの一段目は、時間の削減ではなく「測れるようになること」です。母集団を増やしたい・質を上げたいと言っても、どの段階で、どれだけ落ちているのかが見えなければ、打ち手が決められないから。時間削減は分かりやすい成果ですが、それは二段目です。一段目を飛ばして二段目の数字を出そうとすると、たいてい根拠のない削減率が生まれます。そして実際に手応えとして返ってきたのも、「速くなった」ではなく「見えるようになった」のほうでした。この記事の主張は、後付けの理屈ではありません。作った結果、そう感じているという話です。

もっとも、「見えるようにした」で満足してよいわけではありません。測るための計器そのものは実装済みです。AIの抽出を人がどれだけ修正したか、AIの推奨と人の判断がどれだけ一致したか、自動処理がどれだけ発火したか——これらを見る画面はあります。計器は積んだが、まだ真面目に読んでいない、というのが現状です。ただし「後から測れる形にしておくこと」と「測らないまま作ること」は、まったく違います。数字で効果を語れるようになるのは、これからです。

数字のうち、検証できた技術的な事実は書けます。

最後の行が、先ほどの2つ目にあたります。14個のチェックボックスでは何も集計できなかったところから、歩留まりが見える構造になりました。表の上の5行——突合の速さも、名寄せの正確さも、拡張への転換も、テストの結果も——すべては、この最後の1行を成立させるための足回りです。データが正しく・漏れなく・決まった形で入ってこなければ、歩留まりは測れません。転記をなくすことと、歩留まりが見えることは、別々の成果ではなく地続きでした。

稼働してから見つかった、3つの間抜けな話

そして、動かしてから判明した問題です。ここがいちばん役に立つと思うので、隠さずに書きます。

1. 誤って取り込まれたデータを削除しても、翌朝また復活する。原因は、「このメールは取り込み済み」という目印を、削除処理が物理的に消していたこと。つまり「削除」が「未処理に巻き戻す」と同義になっていた。そして毎朝の再取り込みが、善意で復活させる。すべての部品が設計どおりに正しく動いた結果のバグです。しかも設計規約の冒頭には最初から「業務レコードは論理削除。物理削除は原則しない」と書いてあり、削除処理だけがそれを破っていました。規約は、書いただけでは守られません
2. 面接の「実施完了」を記録する手段が、UIのどこにも無かった。だから完了ステータスが永久に立たず、それを前提にしたタスク一覧・ホーム画面・KPI集計のロジックが、事実上ずっと眠っていました。コードを検索したら、呼び出しがゼロ。動いていないことに、誰も気づいていませんでした
3. 承認の順序が、逆順だった。

2つ目が、この記事の主張を裏から証明しています。データを分類する仕組みは作った。集計するロジックも作った。しかし「人が完了を記録するボタン」を作り忘れたので、全部が空回りしていた。先ほどの「AIが判定したのに、どの画面にも出ていなかった」死蔵リードと、まったく同じ構造です。

業務ツールで壊れるのは、たいてい賢い部分ではありません。人と機械の接点です。AIの分類も、KPIの集計ロジックも、テストは通っていました。壊れていたのは「人がボタンを押す場所」のほうでした。AI活用の失敗は、AIの性能不足として現れないのです。

ちなみに、一度は捨てた会議記録ツールとの自動連携が6月末に復活したのも、この接点の話です。面接のWeb会議が終われば、文字起こしは自動で入ってくる。ならば「実施完了」も自動で立てられるはずだ——つまり、人が押し忘れるボタンを、そもそも無くしにいったわけです。「自社で作った道具どうしなら、繋げばいい」。既製品を組み合わせていたら出てこない発想でした。内製の本当の効き目は、1本のツールの性能ではなく、ツールとツールの間にあるのかもしれません。

御社の業務に、そのまま移せること

採用の話として読んできましたが、ここまでの判断は、採用に限った話ではありません。整理すると、こうなります。

• 「管理をラクにする」を目的にしなかった。目的は、本来やるべき仕事（母集団と質）に時間を戻すこと。管理は目的ではなく、払わされているコスト
• 既製品が合わないとき、汎用ツールへ逃げると維持費を払い続ける。自由には、形を保つ手間という値札が付いている
• 負荷の正体を、判断ではなく「転記」に定めた。人が糊になっている場所を探す
• 状態が集計できない構造は、移植せずに作り直す。楽な移行は、壊れた構造ごと引っ越すだけ
• 壊れ得るものを、信用の境界線にしない。AIは必ず間違えます。問題は間違えることではなく、間違えたときに誰も気づけない構造を作ること
• 精度への投資を諦め、致命傷の経路を消すほうに資源を寄せた。99%は100%ではない
• 「作れる」と「作るべき」を分けた。内製には歯止めがないので、自分で引くしかない
• 形だけの承認ステップを置かなかった。埋もれて誰も見ない承認は、安全装置ではない
• 捨てる前提で作り、なぜ捨てたかを残した。速く作れる時代の、唯一の安全装置

もし御社に「情報が複数の場所に散らばっていて、人間が転記して繋いでいる業務」があるなら、それは採用と同じ構造です。請求でも、進捗管理でも、問い合わせ対応でも変わりません。そして「数字を出そうとすると出せない」なら、それは構造が壊れているサインです。

もう一つ。「既製品を入れたのに、なぜか表計算やチャットに情報が漏れ出している」——これも同じ症状です。製品が悪いのでも、現場が悪いのでもありません。業務の形と、道具の形が合っていないだけです。そのとき選択肢は「業務を製品に合わせる」「道具を業務に合わせる」の二つしかなく、どちらが安いかは、業務の重要度で決まります。採用は、私たちにとって合わせにいく価値のある業務でした。

私たちはWeb制作会社です。ですがサイトを作ることも業務ツールを作ることも、「課題を捉えて、最適な形に設計し、実装する」点では変わりません。会議・提案・育成・問い合わせ・アクセス解析・採用——社内の業務を、ひとつずつ自分たちの手でDXしてきました。ツールを売る立場からではなく、実際に作り、運用し、直しながら使い続けている立場からご提案ができます。

よくある質問

GrowATSは購入できますか？

いいえ。社内専用ツールで、販売していません。それどころか要件定義の時点で「再販は完全にスコープ外。マルチテナント化・用語の汎用化は行わない」と明記しており、他社で使える形にしないことを、意図的に選んでいます。お伝えしたいのは製品ではなく、採用業務をどう分解し、何のために作り、何を作らないと決めたかという考え方のほうです。

なぜ既製の採用管理システムを使い続けなかったのですか？

使いづらく、自社の選考フローと合わなかったからです。機能が足りなかったわけではありません。製品はどこかの標準に沿って作られているので、自社の選考の形とずれた部分は、人間が運用で吸収するか、製品の外に漏れ出します。そこで汎用のドキュメントツールへ移りましたが、今度は管理コストの手間が非常に高くなりました。合わない型に業務を押し込むコストと、自由な道具の維持費を、両方払ってみたうえでの内製です。

AIに書類選考をやらせていますか？

やらせていません。要件定義に「AIは判断を代行しない」と明記されています。AIが出すのはスコア・根拠・推奨アクションまでで、優先度順に並べて人に見せるところで役割が終わります。決めるのは人です。採点基準も、甘すぎる版（★3が77%）と厳しすぎる版（★1が75%）を実際に検証したうえで、中庸のものを選んでいます。厳しすぎる版は候補者の質ではなく提出資料の薄さを罰してしまうため、母集団の質を見るという目的に反していました。

応募の見落としは防げるのですか？

「絶対」とは書きません。私たちがやったのは、AIの分類を信用境界にしないことです。候補者として登録されていない受信メールは、AIが「応募ではない」と判定しても、必ず人に見せます。ノイズは人が消す（1日あたり数十秒）。見落とすコストは信頼の永久喪失で、まったく釣り合わないからです。そのために、分類精度を上げる投資のほうを諦めました。

どれくらいの工数が削減できましたか？

時間としては測っていないので、書けません。削減時間・処理件数・削減率のいずれも、社内の記録に存在しません。測るための画面は実装済みですが、まだ真面目に読んでいないのが正直なところです。数字がないのに「大幅削減」と書くことだけは、しないと決めています。そのうえで、確実に変わったことが2つあります。応募データの転記がなくなったことと、これまで集計すらできなかった歩留まりが、見えるようになったことです。この2つは、始まりにあった2つの課題とそのまま1対1で対応しています。採用DXの一段目は、時間削減ではなく「測れるようになること」——実際に手応えとして返ってきたのも、そちらのほうでした。

採用DXは、まず何から始めればいいですか？

「人が転記している場所」と「出したいのに出せない数字」を、書き出すことです。転記は判断ではありません。判断でない作業に人を使っているなら、そこが最初の候補です。そして数字が出せないなら、ツール選び以前に業務の状態を表す構造が壊れています。採用DXは、システムを選ぶことから始まるのではなく、転記を数えることから始まります。

まとめ：採用DXの目的は、管理ではない

GrowATSの発端は、技術的な野心ではありませんでした。既製の採用管理システムを使ったら、自社の選考フローと合わなかった。汎用のドキュメントツールへ移ったら、管理コストの手間が非常に高くなった。逃げた先が、もっと重かったのです。

そして負荷の中心は、選考の判断ではなく4つの場所を人間が行き来して同じ情報を打ち直す作業でした。その下には、選考の状態が14個のチェックボックスになっていて、何一つ集計できないという、もっと根深い問題がありました。いまは、その2つとも消えています。転記はなくなり、歩留まりは見えるようになりました。何時間減ったかは測っていません。それでも、解こうとした2つの問題が解けたかどうかは、数字がなくても分かります。

だからツールを作りました。ただし目的は「管理を上手にすること」ではありません。応募してくださる方の母集団を増やし、その質を高めることに時間を使うためです。管理に時間を取られている場合ではない——それが出発点でした。817コミットの大半が作り直しだったのは、この一行に照らして、手段のほうを捨て続けた結果です。

いちばん効いた判断は、これでした。壊れ得るものを、信用の境界線にしない。AIの精度を上げる方向への投資を諦め、見落としという致命傷の経路を消すことに、資源を集中させた。AIは必ず間違えます。問題は間違えることではなく、間違えたときに誰も気づけない構造を作ってしまうことです。

「採用業務が兼任者の片手間からあふれている」「既製品を入れたのに、情報が製品の外に漏れている」「汎用ツールの維持に時間を取られている」「数字を出そうとすると出せない」——そうした課題があれば、ぜひ一度ご相談ください。自社の業務をひとつずつDXしてきた実務の経験から、御社の業務に合わせてご提案します。現状をお聞きしたうえで、最適な進め方を無料でご提案します。ご相談・お見積りはこちら

無料ダウンロード資料

GrowGroup株式会社の制作事例・料金がわかる資料を配布中

会社概要・制作実績・料金の目安をまとめた資料です ／ PDF

資料をダウンロード