人材紹介・HR Techのシステム開発外注｜業界要件と発注準備

人材紹介会社や HR Tech スタートアップが自社の基幹システムを外注する場面は、他業種のシステム開発とは根本的に異なる難しさを抱えています。求職者・求人企業の個人情報を大量に扱い、職業安定法や個人情報保護法の制約下でマッチングを回す業務は、汎用の開発会社にとって前提知識のないブラックボックスになりがちだからです。

「業界向けのシステム開発会社12社」といった羅列型の記事を読んでも、どの会社を選べばいいかの判断軸は得られません。むしろ問題の本質は、発注先を選ぶ前に「自社の業務要件を業界特有の観点で言語化できているか」「法規制をシステム要件に翻訳できているか」にあります。ここが曖昧なままだと、どんなに評判の良い開発会社に発注しても、要件のすれ違いによる仕様変更・過剰スペック・法令違反リスクが顕在化します。

本記事では、発注準備の段階で押さえるべき業界特有の要件チェックリスト、職業安定法・個人情報保護法をシステム要件に落とし込む観点、SaaS 導入とスクラッチ開発を分ける判断軸、発注先選定で見るべき「HR Tech ドメイン適合度」の 5 観点、費用相場と見積比較の前提条件、社内体制の作り方まで、体系的に解説します。システム開発外注そのものの基本を押さえたい場合は、事前にシステム開発の外注ガイドも参照してください。

読み終えたときには、外注先候補に対して同じ物差しで比較検討できる状態になり、業界のドメイン知識がある開発会社を選び抜くための実務準備が整っているはずです。

人材紹介・HR Tech業界のシステム開発外注が難しい理由

人材紹介・HR Tech 業界のシステム外注は、EC サイトや業務システムの発注と本質的に異なる構造を持ちます。まずはこの「なぜ他業種と同じ方法では失敗するのか」を言語化しておくことが、後続のすべての判断の土台になります。

汎用開発会社が業界特有の要件を汲み取れない構造

人材紹介の業務フローは、求職者からの相談受付、キャリアヒアリング、求人票のマッチング、書類選考、企業への推薦、面接調整、内定・入社フォロー、企業への請求という多段階の連鎖で成り立っています。この一連の流れは、キャリアアドバイザーが暗黙知として保持しているケースが多く、外部の開発者が業務ヒアリングだけで把握するのは困難です。

汎用の開発会社に依頼した場合、「求職者テーブル」「求人テーブル」「マッチング履歴テーブル」といったオーソドックスなデータモデルは提案されますが、両手取引（同一エージェントが求職者と求人企業の両方を担当する形態）と分業モデル（RA と CA が分担する形態）の違い、求人票の非公開・公開切替、複数エージェントによる情報の重複防止、成功報酬の返金規定（早期退職返金）といった業界特有の要件は、明示的に伝えない限り実装から抜け落ちます。

一度リリースしたシステムに後から業界要件を追加するのは、テーブル設計の変更・データ移行・既存機能への影響調査を伴うため、初期開発の何倍ものコストがかかります。ここが業界特化型の開発発注が難しい第一の理由です。人事労務領域のシステム開発と比べても、人材紹介・HR Tech は業務ロジックの独自性が高く、汎用パッケージへの適合度が低い傾向があります（人事労務系の発注勘所は人事労務システム開発の基礎を参照）。

職業安定法・個人情報保護法という「システムに組み込むべき制約」の存在

人材紹介事業には、他業種にはない法規制の制約が入り込みます。職業安定法では、労働者の募集業務等の目的達成に必要な範囲内でしか求職者の個人情報を収集・保管・使用できないと定められており、目的外利用の禁止・要配慮個人情報の収集制限・保管期間の制約が課されています（求職者等の個人情報の取扱いについて（厚生労働省 群馬労働局））。

さらに、求職者の個人データを求人企業に開示する行為は個人情報保護法上の「第三者提供」に該当するため、原則として事前の同意取得が必要です（個人情報の保護に関する法律についてのガイドライン（第三者提供時の確認・記録義務編）｜個人情報保護委員会）。同意取得の証跡が残らないシステム設計になっていると、監査対応や紛争発生時に事業継続リスクが顕在化します。

改善命令に違反した場合、6か月以下の拘禁刑または30万円以下の罰金が科される可能性もあり（厚生労働省 通知資料）、これらの制約はシステム設計時に「あとから機能追加」で済むものではありません。データベース設計・画面遷移・アクセス権制御・ログ保管の全レイヤーに横串で反映する必要があります。

パッケージSaaSでは対応しきれない業務フローの多様性

「それなら市販の SaaS ATS を使えば足りるのでは」と思われるかもしれません。しかし人材紹介業の実際の業務では、独自のスカウトメール文面テンプレート、キャリアアドバイザー個別の評価軸、成功報酬計算ロジック（返金規定・分割払い対応）、複数の求人媒体との情報同期といった要件が絡み合います。

汎用 ATS のマスタ設定範囲を超えるカスタマイズを求めると、追加開発費が積み上がるか、SaaS 側で対応不可となり、結局部分的にスクラッチ開発する必要が生じます。この判断を発注前に整理せずに進めると、SaaS を導入した後に「業務が回らない」ことが判明し、二重投資になるパターンが散見されます。

外注前に整理すべき業界特有の要件チェックリスト

ここからが発注準備の実務です。開発会社に見積依頼を出す前に、発注者側で以下の項目を言語化しておくと、複数社の見積を同じ土俵で比較できるようになります。

求人票・求職者データの管理粒度と項目定義

求人票と求職者データの項目は、汎用ATS の標準スキーマでは業界の実態に追いつかないケースが多いポイントです。以下の観点で自社の粒度を整理しましょう。

• 求人票の必須項目・任意項目（勤務地・雇用形態・年収レンジ・必須スキル・歓迎スキル・想定年齢層・語学要件など）
• 非公開求人・公開求人の切り替え可否と、非公開情報の閲覧権限
• 求職者データの項目（希望条件・スキル・職務経歴・語学・資格・面談メモ・企業推薦履歴）
• 同一求職者を複数エージェントが担当する場合の情報の可視範囲

これらは業務フロー図とセットで開発会社に提示することを推奨します。項目名だけでなく、「なぜその項目が必要か」「どの業務で使うか」を添えると、後の要件変更を減らせます。

マッチングロジック（キーワード / スキルタグ / スコアリング）の実装方針

マッチング機能は HR Tech の中核ですが、実装方針の選択肢は幅広く、費用と精度のトレードオフが大きい領域です。

• キーワード一致方式（求人票のフリーワード検索）
• スキルタグ・カテゴリマスタによる構造化マッチング
• スコアリング（重み付けアルゴリズム）による優先度表示
• 機械学習・埋め込みベクトルによる類似度計算

多くの中小人材紹介会社にとっては、「スキルタグ + シンプルなスコアリング」の組み合わせで十分な精度が得られます。いきなり機械学習を選ぶと、教師データの整備・モデル運用の負担が発生し、費用対効果が合わなくなりがちです。マッチング精度への期待値を発注前に自社内で議論し、「どのくらいの精度なら人手のフォローで十分か」を決めておくと、過剰スペックを避けられます。

求人媒体・ATS・CRM 等の外部連携要件

多くの人材紹介会社は、独自システムだけで業務が完結せず、Indeed や リクナビ NEXT などの求人媒体、あるいは既存の ATS・SFA との連携を必要とします。連携方法によって開発工数が大きく変わるため、以下を整理しておきましょう。

• API連携（媒体側が公式APIを提供している場合）
• CSVエクスポート・インポートによる非同期連携
• 媒体側のフォーマットに合わせた求人票の自動配信

Indeed PLUS 連携 ATS のように、複数媒体への同時配信を前提とした設計もあります（Indeed PLUS連携ATS（採用管理システム）比較（アットカンパニー））。自社が連携したい媒体のリストと、それぞれの連携方法（API可否・データ項目の対応関係）を発注前に確認しておくことで、後工程での仕様変更を防げます。

求職者コミュニケーション（メール・SMS・LINE・チャット）と通知設計

求職者との連絡手段は、メール中心から LINE 中心へ変化しつつあります。連絡チャネルごとに、送信履歴の一元管理・テンプレート管理・オプトアウト対応・監査ログの要件が変わるため、以下を整理しておきましょう。

• 使用するチャネル（メール / SMS / LINE 公式アカウント / 独自チャット）
• 一斉送信・個別送信の運用フロー
• 求職者からの受信・返信の記録管理
• 誤送信防止（テスト送信・宛先確認・キャンセル猶予）

特に LINE 連携はメッセージ API の利用料金や API 仕様変更への追従が発生するため、初期開発と保守運用の両方でコスト計上が必要です。

面談調整・書類選考・オファーまでのワークフロー

面談調整から内定までのワークフローは、業界内でも会社ごとに大きく異なります。以下の観点で自社の運用を書き出しておくと、開発会社に業務を正確に伝えられます。

• 面談日程調整（求人企業の空き時間 / 求職者の希望 / エージェントの立ち会い有無）
• 書類選考の結果登録と求職者への通知フロー
• オファー提示・内定辞退時の対応フロー
• 入社日確定・成功報酬計算・請求書発行までの一連の連携

「Excel でやっている手順を、そのままシステム化する」だけでは業務の非効率が固定化されます。発注前に業務フローを見直し、システム化に合わせて簡略化できる部分を切り出しておくと、開発費と保守費の両方を圧縮できます。

職業安定法・個人情報保護法をシステムに落とし込む観点

法規制対応は、業界特化型システムで最も差が出るポイントです。汎用の開発会社に発注する場合でも、以下の観点を要件として明示し、実装可否を確認しましょう。

求職者データの目的外利用防止（利用目的の明示・同意取得フロー）

職業安定法では、求職者の個人情報を「募集業務等の目的達成に必要な範囲内」でしか使えないと定められています。したがってシステム設計上、以下の要件を組み込む必要があります。

• 求職者登録時の利用目的の明示（画面上での提示と同意取得）
• 収集した情報を目的外に使えないように、機能単位でアクセス権を分ける
• 目的外利用のリスクがある操作（一括ダウンロード等）のログ保管と管理者承認フロー

これらは実装するかしないかで、監査対応や事故発生時の説明責任が大きく変わります。設計初期から要件として明記しておきましょう。

第三者提供（求人企業への情報開示）の同意管理

求職者の職務経歴書・レジュメを求人企業に開示する行為は、個人情報保護法上の「第三者提供」に該当します。第三者提供は原則として事前の同意取得が必要で、同意の記録も義務化されています（個人情報保護法ガイドライン（第三者提供時の確認・記録義務編））。

システム側で以下の要件を実装しておくと、同意取得の証跡が自動的に残ります。

• 求人企業への推薦操作の前に、求職者から個別または包括的な同意を取得する画面フロー
• 同意取得の日時・対象求人企業・情報項目の記録
• 求職者が同意を撤回した場合の即時反映（提供停止フラグ）

同意取得のフローを紙・メール・システムに分散させると管理が破綻します。システム内で完結する設計を初期段階から要件化しましょう。

個人情報の保管期間・削除・アクセス制御

個人情報保護法・職業安定法では、収集した個人情報の保管期間の明示と、期間経過後の適切な削除が求められます。システム要件として、以下を組み込みましょう。

• 保管期間の設定（例: 最終接触日から3年間）と期間経過後の自動アラート
• 削除操作の履歴保管（削除者・削除日時・対象データ）
• 権限別のアクセス制御（キャリアアドバイザー / 管理者 / 経営層で閲覧可能項目を切り分け）
• 特定の求職者データにアクセスした履歴の記録

保管期間ロジックは、後付けだと過去データの再整理を伴うため、初期開発時に確定させておくのが賢明です。

監査ログとインシデント発生時の追跡可能性

万一、個人情報の漏洩・目的外利用・誤送信が発生した場合、原因調査と関係者への説明のために、詳細な監査ログが必要になります。以下の要件を発注時に明示しましょう。

• 誰が・いつ・どの求職者データにアクセスしたかのログ保管
• 求人企業へのデータ提供操作のログ保管
• メール・LINE 等の送信履歴のログ保管
• ログの改ざん防止と、一定期間のアーカイブ保管

汎用の開発会社は、監査ログを「後で追加できる機能」として軽く扱いがちです。しかし人材業界では、監査対応の一次資料になるため、初期設計から要件化することを強くお勧めします。

SaaS導入・パッケージカスタマイズ・スクラッチ開発の判断軸

要件の輪郭が見えてきたら、次は開発方式の選択です。SaaS / パッケージ+カスタマイズ / スクラッチの 3 方式を、事業フェーズと予算から選ぶための判断軸を整理します。

SaaS導入で足りるケース・足りないケース

汎用 ATS・CRM を活用する SaaS 方式は、初期費用が抑えられ導入も速いのがメリットです。以下の条件がすべて当てはまる場合は SaaS で十分なケースが多いです。

• 求職者・求人票のデータ項目が標準的（業界特殊な項目が少ない）
• マッチングは全文検索やタグ検索で十分（独自スコアリングは不要）
• 求人媒体との連携は Indeed / リクナビNEXT など主要媒体で対応可能
• 個人情報の同意取得・監査ログが SaaS 側で標準機能として提供されている

一方、SaaS の標準機能で対応できない業務が多い場合、カスタマイズ費用が積み上がり、結果としてスクラッチ開発と同等の費用になるパターンもあります。事前に SaaS ベンダーへ「自社の要件で、標準機能内で何割カバーできるか」を確認しておきましょう。

パッケージ+カスタマイズが有効な事業規模と論点

パッケージ製品にカスタマイズを加える方式は、業界特化型のパッケージ（人材紹介向け ATS など）が存在する場合に有効です。以下の観点で判断しましょう。

• 業界特有の業務フローが標準搭載されているか
• カスタマイズ範囲が明確に区分されているか（追加テーブル・追加画面の可否）
• パッケージのバージョンアップ時にカスタマイズが引き継がれるか
• 法改正時のアップデート対応がパッケージ側で提供されるか

パッケージ+カスタマイズは中規模の人材紹介会社に適した選択肢ですが、パッケージのロードマップと自社の事業戦略が乖離すると、後から乗り換えコストが発生します。中長期の事業計画とパッケージのロードマップの整合を確認しておきましょう。

スクラッチ開発を選ぶべきタイミング

以下のような条件がある場合、スクラッチ開発を選ぶ合理性が高まります。

• マッチングロジックそのものが競合との差別化の源泉になっている
• 独自の業務フロー（両手取引の切り替え、複数エージェント協業など）を密に組み込む必要がある
• 求職者データ量が数十万〜数百万件規模で、汎用 SaaS の性能限界に達する
• 自社独自の求人媒体連携やスカウトメール自動化を実装したい

スクラッチ開発は初期費用と保守費用が最も高くなる方式ですが、事業成長に応じてシステムを進化させられる柔軟性があります。ただし、初期リリース以降の運用体制（保守・機能追加・法改正対応）まで見据えて発注する必要があります。

3方式のTCO比較（初期・運用・保守・法改正対応）

3 方式の費用感を、初期費用と運用費用に分けて見ておきましょう。あくまで一般的な相場観であり、要件によって大きく変動します。

• SaaS: 初期 0〜数十万円 + 月額数万〜数十万円（利用ユーザー数・機能により変動）
• パッケージ + カスタマイズ: 初期 数百万〜1,500万円 + 月額数万〜数十万円 + カスタマイズ保守費
• スクラッチ開発: 初期 600万〜数千万円 + 月額数十万〜数百万円（保守・機能追加により変動）

SaaS 型の開発費用相場については、基本機能で 150〜350 万円、複雑機能を含む場合は 350〜650 万円という試算もあります（SaaS開発費用の相場まとめ（Walker-s））。スクラッチ開発は 600 万〜2,000 万円、規模によっては 1,000 万円超が一般的です（スクラッチ開発の費用相場（発注ラウンジ））。

3 方式を数字で並べて比較し、5年間のTCO（総所有コスト）を試算すると、意思決定の精度が上がります。

発注先選定で見るべき「HR Tech ドメイン適合度」5観点

方式が決まったら、次は発注先の選定です。汎用の開発会社選定の基本論点は開発会社選定の基本フレームにまとめていますので、本節ではそれと重ねて確認したい業界特化案件でこそ必要な5観点に絞ります。同じ観点で複数社を評価すると、比較の物差しが揃います。

人材業界の実装実績と扱ったデータ規模

過去の人材紹介・HR Tech 案件の実績を、公開可能な範囲で確認しましょう。以下の観点で聞くと具体的な情報が引き出せます。

• 過去 3 年以内の人材業界案件数と、そのうちの類似規模案件数
• 扱った求職者データの規模（数千件 / 数万件 / 数十万件）
• 実装したマッチング機能の内容（キーワード / タグ / スコアリング / 機械学習）
• 稼働後のシステムを保守した経験の有無

「実績があります」という営業トークだけで判断せず、案件規模と機能内容を具体的に確認するのがポイントです。

法規制対応（職安法・個人情報保護法・APPI）の理解度を確認する質問例

法規制の理解度は、以下のような質問への回答内容から判断できます。

• 「求職者から求人企業への第三者提供の同意取得は、どの画面フローで実装しますか」
• 「求職者データの保管期間を過ぎた場合の削除運用は、どのように設計しますか」
• 「監査ログはどの粒度で保管し、改ざん防止をどう担保しますか」
• 「要配慮個人情報（健康情報・信条など）の収集を防ぐバリデーションはどう組みますか」

これらの質問に、具体的な設計案を提示できる会社が「業界のドメイン知識がある」と判断できます。抽象的な回答しか返せない場合は、要件定義段階で発注者側が主導的に法規制要件を出せる社内体制を整える必要があります。

求人媒体・ATS・SFA との連携経験

外部連携は業界特化案件で確実に登場する要件です。以下の観点で確認しましょう。

• Indeed / リクナビNEXT / dodaなどの主要求人媒体との連携経験
• API 仕様変更時の追従経験（媒体側の仕様変更は年数回発生する）
• 既存 ATS・SFA との CSV・API 連携経験
• スカウトメール送信ツール（LINE・SMS 含む）との連携経験

連携経験の有無は、開発工数の見積精度に直結します。未経験の媒体連携が多い場合は、その分の追加見積を確認しておきましょう。

保守フェーズでの法改正対応体制

個人情報保護法・職業安定法は、数年おきに改正が入る可能性があります。保守契約の中で法改正対応がどう扱われるかを、事前に確認しておきましょう。

• 法改正に伴う要件変更は、保守費用の範囲内か・別見積か
• 法改正のキャッチアップ体制（社内の法務担当・顧問弁護士との連携）
• 過去の改正時に、既存クライアントに提供した対応内容の実例

「開発だけして保守は別会社」というパターンだと、法改正対応時に前開発会社の設計意図が伝わらず、追加調査費用が膨らむことがあります。開発と保守を同じ会社で担うか、少なくとも設計ドキュメントを引き継ぎ可能な形で残す契約にしておくと安全です。

プロジェクト体制（PM・エンジニア構成・稼働率）

最後は体制の確認です。以下の観点で、同じ物差しで複数社を比較しましょう。

• プロジェクトマネージャーの経験年数と業界案件経験
• エンジニアの人数・稼働率・スキル構成（フロント / バック / インフラ）
• コミュニケーション頻度（週次定例の有無・進捗共有の粒度）
• 契約形態（請負 / 準委任 / ラボ型）と、変更時の対応柔軟性

体制の詳細を確認せずに発注すると、実際は経験の浅いエンジニアが担当となるケースがあります。契約書のレベルまで踏み込んで、担当者の割り当てを明確にしておきましょう。

見積比較で失敗しないための費用相場と内訳

複数社から見積を取る場合、同じ前提条件で比較しないと数字の意味が変わってしまいます。システム開発全般の費用相場・内訳の考え方はシステム開発の費用相場ガイドにまとめています。以下は、そのうえで人材紹介・HR Tech 特有の観点に絞って揃えるべき前提条件を整理します。

3方式ごとの費用レンジ

改めて、3 方式の費用レンジを整理します。

• SaaS 型（初期＋月額運用）: 初期 0〜数十万円、月額数万〜数十万円
• パッケージ+カスタマイズ: 初期 数百万〜1,500万円 + 月額保守数万〜数十万円
• スクラッチ開発: 初期 600万〜数千万円、月額保守数十万〜数百万円

いずれも、要件範囲・データ量・連携数・監査ログ要件の有無で大きく変動します。まずはこの相場感を持った上で、自社の要件でどこに位置するかを開発会社と擦り合わせましょう。

費用が大きく変動するドライバー

見積に大きく影響する費用ドライバーは、以下のとおりです。

• 外部連携数（求人媒体・ATS・SFA・チャットツール等の連携本数）
• マッチングロジックの複雑度（キーワードのみか / スコアリングか / 機械学習か）
• 求職者データの規模（データ量とマッチング応答時間の要件）
• 監査ログ・アクセス権制御・同意取得画面の実装粒度
• 画面数・帳票数（見積書・請求書・レポート等）

見積書の「開発費用一式 XXX 万円」という記載だけで判断せず、これらのドライバーごとに内訳を出してもらうと、複数社の比較精度が上がります。

見積比較時に3社で揃えるべき前提条件

3 社に見積依頼を出す際は、以下の前提条件を統一しましょう。

• 対象範囲（マッチング / ATS / スカウト / 請求管理のうちどこまで含むか）
• ユーザー数（同時アクセス数・登録アカウント数）
• データ量（初期データ件数と 3 年後の想定件数）
• 求人媒体連携の対象媒体リスト
• 個人情報保護要件（同意取得・保管期間・監査ログ）
• 想定リリース時期と保守期間

前提条件を統一しないまま複数社の見積を並べると、「安いが業界要件が漏れている見積」と「高いが監査ログまで含む見積」を単純に金額比較してしまい、判断を誤ります。見積依頼書（RFP）に前提条件を明記して、同じ条件で答えてもらう運用にしましょう。

発注者側の社内体制と成功パターン

業界特有の要件を扱う以上、発注者側にも一定の社内体制が必要です。開発会社に丸投げする姿勢では、業界特化のシステムは完成しません。

プロジェクトオーナーとサブリーダーの役割

プロジェクトオーナーは、経営層または事業責任者クラスが担うのが理想です。役割は以下のとおりです。

• 事業戦略とシステム要件の整合を最終判断する
• 予算・スケジュールの意思決定を担う
• 部門横断の調整を主導する

サブリーダーは、業務詳細を熟知した現場マネージャーが担うのが適任です。日々の要件確認・仕様レビュー・現場ユーザーとの調整を担当します。プロジェクトオーナーとサブリーダーの 2 名体制で、開発会社とのコミュニケーション窓口を一本化するのが失敗を防ぐ基本形です。

個人情報取扱責任者との連携ポイント

人材紹介事業では、個人情報取扱責任者の設置が求められます。システム開発プロジェクトでも、以下のタイミングで個人情報取扱責任者との連携が必要です。

• 要件定義完了時: システムが扱う個人情報の範囲を確認する
• 基本設計完了時: 同意取得フロー・アクセス権制御・監査ログの設計を確認する
• 受入テスト時: 個人情報保護法・職業安定法の要件が実装されているかを検証する
• リリース直前: 運用ルール・インシデント対応手順を確認する

これらのタイミングを開発計画に組み込んでおくと、法規制違反を予防できます。個人情報取扱責任者のレビュー時間を、開発計画のマイルストーンに明示的に確保しておきましょう。

現場ユーザー（キャリアアドバイザー・営業）を巻き込むタイミング

現場のキャリアアドバイザーや営業担当を、いつどう巻き込むかも成功要因です。

• 要件定義段階: 業務フローと現状の課題を吸い上げる
• 画面設計段階: ワイヤーフレームで操作感を確認する
• 受入テスト段階: 実データに近いテストデータで実運用シミュレーションを行う
• リリース後: 運用開始 1 週間・1 か月・3 か月の各時点でフィードバックを収集する

「使うのは現場」ですので、現場を巻き込まないと、リリース後に「使いにくいから前の Excel に戻す」という結末になりがちです。開発会社が現場ヒアリングを支援してくれるかも、発注先選定の重要な観点になります。

まとめ｜HR Tech / 人材紹介の外注準備を1週間で終える手順

ここまでの内容を、1 週間で実行できる発注準備アクションに落とし込みます。明日から着手できる粒度で整理しました。

• 1日目: 業務フロー図を書き出す（求職者登録から入社まで、部門横断で 1 枚にまとめる）
• 2日目: 業界特有の要件チェックリスト（本記事の「外注前に整理すべき業界特有の要件チェックリスト」）を自社に当てはめて洗い出す
• 3日目: 職業安定法・個人情報保護法の要件をシステム要件に翻訳する（本記事の「職業安定法・個人情報保護法をシステムに落とし込む観点」を参照）
• 4日目: SaaS / パッケージ / スクラッチの 3 方式のうち、自社の要件と予算に合う方式を仮決めする
• 5日目: RFP（見積依頼書）を作成し、前提条件を統一した上で 3 社に送付する
• 6日目: 発注先選定の 5 観点（本記事の「発注先選定で見るべき『HR Tech ドメイン適合度』5観点」）を評価シートに落とし込む
• 7日目: 経営会議で発注方針を確認し、面談日程を確定する

この 1 週間の準備が、業界特化案件の失敗確率を大きく下げます。「時間がないから、まずは開発会社に相談してから決めよう」という進め方では、開発会社の得意領域に引きずられた要件になりがちです。発注準備は自社が主導し、開発会社を「業界要件を正しく実装できる技術パートナー」として選ぶ姿勢を持ちましょう。

人材紹介・HR Tech 業界のシステム開発外注は、業界特有の要件と法規制の理解が成否を分けます。発注準備の段階から「業界特化案件」として扱い、要件チェックリスト・法規制翻訳・発注先選定の 5 観点を揃えれば、少なくとも 3 社の見積を同じ物差しで比較できる状態を作れます。焦らず 1 週間の準備を終えてから、次の一手に進みましょう。