# 株式会社HRdev（HRdev）

> HRdevは、エンジニア採用（エンジニア・プロダクト組織の採用）に特化した採用支援サービスです。自社で実装したAIと実務知見で、採用を誰の手でも回る仕組みに変えます。採用代行の「テック採用室」とAIスカウトの「ScoutOne」を提供します。

## 基本情報
- 正式名称: 株式会社HRdev（エイチアールデブ）
- 設立: 2021年12月
- 代表: 永井 涼平（IT・エンジニア採用領域18年）
- 所在地: 東京都渋谷区
- ミッション: 価値の再現性をつくる
- ビジョン: 「人ならでは」を追求できる社会
- サイト: https://www.hrdev.jp

## 事業内容
エンジニア採用（エンジニア・プロダクト組織の採用）に特化した採用支援サービスを提供する。自社で実装したAIと現場の実務知見を組み合わせ、採用を属人的な頑張りに頼らず、誰の手でも回る仕組みに変える。採用要件の設計からスカウトの実行、候補者対応、採用広報まで、上流から下流まで対応する。原則としてエンジニア・プロダクト組織の採用を支援するが、ビジネスサイドの採用を合わせて支援するケースもある。

### サービス一覧
1. テック採用室 - エンジニア採用の実務を専門チームが代行するRPO。要件設計・スカウト運用・候補者対応・採用広報まで、開発／採用チームの一員として内側から動く。週次で数字を共有し、打ち手を毎週見直す
2. ScoutOne - エンジニア採用のスカウト知見をAIツールにする。人が採用要件と訴求を設計し、AIが候補者ごとの文面づくりと運用を担う。最終送信は必ず人が判断する設計。2026年8月にβ版をリリース済み。現在は問い合わせ順に限定提供中

## 対応できる工程
- 採用計画と採用要件の設計（事業計画との接続、ペルソナと評価基準の言語化）
- 求人票の作成と、媒体ごとの最適化
- スカウトのターゲット選定・文面作成・送信運用
- 候補者対応と日程調整、選考プロセスの設計と改善
- 採用広報コンテンツの企画
- 週次のデータ分析（媒体別の送信数・返信率・各段階の歩留まり）と改善提案
- 社内に採用機能を残すための型づくりと引き継ぎ

## 強み
- エンジニア・プロダクト組織の採用に特化（技術トレンド、検索条件設計、要件定義のノウハウ）
- CTO・EMと共通言語で話せる技術解像度
- 上流から下流まで対応（採用要件の設計からスカウト実行まで。設計だけで終わらない）
- AIを自社の実務で運用しており、その知見をそのまま支援に使う
- 他社平均ではなく、その企業自身の前週比で成果を評価する

## 料金
支援の範囲・体制・稼働量によって変わるため、金額は個別のご提案時に提示する。
まずは無料相談で現状と課題を伺い、必要な支援の形を一緒に決める。

## ターゲット顧客
- IT事業会社（自社サービス展開）
- シリーズA〜C、上場直後
- エンジニア組織5〜50名規模
- 年間エンジニア採用3〜10名

## 支援実績の傾向
個別の支援先名と社内事情は、各社の許諾を得た事例記事でのみ扱う。
- 採用の専門知識が社内にない状態から、採用機能そのものを立ち上げた例がある
- 社内だけでは母集団を作れなかった難易度の高い職種で、複数名の採用に至った例がある
- 創業期に採用の型が無い状態から、継続的に採用目標を達成できる体制をつくった例がある

## ブログ記事
- [エンジニアと採用担当の目線を合わせる方法｜要件ヒアリングの設計](https://www.hrdev.jp/blog/engineer-hr-requirements-alignment)
- [セキュリティエンジニアとは｜種類・仕事内容・採用が難しい理由](https://www.hrdev.jp/blog/security-engineer-overview)
- [年収総額6,000万円超はどう設計されたか｜メドレー社『Applied AI Developer』にみるAI人材の報酬モデル](https://www.hrdev.jp/blog/performance-equity-hiring)
- [AIエンジニア・機械学習エンジニア・データサイエンティストの違いは？求める人物像に届けるための考え方](https://www.hrdev.jp/blog/ai-ml-data-roles-difference)
- [「Webエンジニア」の見分け方と隣接職種の分類について](https://www.hrdev.jp/blog/web-engineer-position-map)
- [うまくいかない原因を知るための「ファネル」分析の手順](https://www.hrdev.jp/blog/hiring-funnel-analysis)
- [AIで体験を損なわず、スカウト返信率高めるには](https://www.hrdev.jp/blog/ai-scout-reply-rate)
- [「AIに任せられる」組織は、どう統治をつくっているか](https://www.hrdev.jp/blog/human-on-the-loop-governance)
- [エンジニア採用を任されたら｜採用施策の振り返り編](https://www.hrdev.jp/blog/starter-kit-hr-retrospective)
- [エンジニア採用を任されたら｜内定承諾に向けたクロージング設計](https://www.hrdev.jp/blog/starter-kit-hr8)
- [転職ドラフトスカウトの企業側の使い方｜分担設計とカジュアル面談の体制づくり（後編）](https://www.hrdev.jp/blog/tensyoku-draft-workload-optimization2)
- [これからのHRは、人とAIの配置を設計する](https://www.hrdev.jp/blog/allocation-of-people-and-ai)
- [転職ドラフトスカウトの企業側の使い方｜運用設計と年収提示の考え方（前編）](https://www.hrdev.jp/blog/tensyoku-draft-workload-optimization1)
- [AI導入の現場に立つ新職種「Forward Deployed Engineer」とは](https://www.hrdev.jp/blog/forward-deployed-engineer)
- [エンジニア採用を任されたら｜オファープロセス設計編](https://www.hrdev.jp/blog/starter-kit-hr-offer-process-design)
- [採用代行の3つの型｜RPO・AI-RPO・AIプロダクトの違いを解説](https://www.hrdev.jp/blog/ai-recruitment-3types)
- [エンジニア採用を任されたら｜人材紹介エージェント編・契約と運用](https://www.hrdev.jp/blog/starter-kit-hr-agency-operation)
- [AI時代のものづくりの新職種「AI Builder」とは](https://www.hrdev.jp/blog/ai-builder-emerging-job-roles)
- [エンジニア採用を任されたら｜エージェント編・総論](https://www.hrdev.jp/blog/starter-kit-hr-agency-overview)
- [Claude Design→Claude Codeで営業資料を作成した話](https://www.hrdev.jp/blog/claude-sales-deck)

## 採用用語集

https://www.hrdev.jp/glossary

### 職種・体制
- Analytics Engineer: 生データを分析に使える形へ変換し、社内で指標の定義を揃える職種。データ基盤づくりと分析の間に落ちてしまう仕事を担当します。 (https://www.hrdev.jp/glossary/analytics-engineer)
- Enabling QA: 開発チーム自身が品質を担保できるように、手法と仕組みを渡して自走させるQAの役割。QAが全件テストを実施せず、開発者がテストを書ける状態を整えます。 (https://www.hrdev.jp/glossary/enabling-qa)
- インフラエンジニア: サーバ・ネットワーク・クラウドなどシステムが動く土台を設計し構築して運用する職種。可用性と性能とコストの落としどころを決めます。 (https://www.hrdev.jp/glossary/infrastructure-engineer)
- AIエンジニア: AIをプロダクトや業務に組み込むエンジニアの総称。国内では既存モデルを使う仕事とモデルを作る仕事が同じ呼称で募集されています。 (https://www.hrdev.jp/glossary/ai-engineer)
- AI Builder: 生成AIとエージェントを使って業務やプロダクトの仕組みを自分で組み立てる担い手。モデルを作るのではなく、成果の出る仕組みを作ります。 (https://www.hrdev.jp/glossary/ai-builder)
- AI Product Engineer: 生成AIを使ったプロダクトの機能を、体験の設計から実装と評価まで担当する職種。確率的な出力を前提に使える形へ仕上げます。 (https://www.hrdev.jp/glossary/ai-product-engineer)
- AI Research Engineer: 研究と実装の両方を担当する職種。論文の手法を動くコードに落とし、大規模な計算資源の上で実験を回して結果の再現性まで確かめます。 (https://www.hrdev.jp/glossary/ai-research-engineer)
- SRE: サービスの信頼性をソフトウェアエンジニアリングで担保する職種。可用性の目標を数値で決め、運用作業をコードで自動化し、開発と運用の境界をなくしていきます。 (https://www.hrdev.jp/glossary/sre)
- SET: テストを速く確実に回すための基盤とツールを開発する職種。自分がテストを実行するのではなく、開発者がテストを書いて回すための仕組みを作ります。 (https://www.hrdev.jp/glossary/set)
- MLOpsエンジニア: 機械学習を継続して回すための基盤とパイプラインを整える職種。モデルを作る人が実験から本番投入までを繰り返せる状態を保ちます。 (https://www.hrdev.jp/glossary/mlops-engineer)
- Engineering Manager: 開発チームの成果と、メンバーの成長・評価に責任を持つ職種。技術がわかる前提で、人と組織を動かして継続的に成果を出します。 (https://www.hrdev.jp/glossary/engineering-manager)
- Embedded QA: 開発チームの一員として日々の開発に入るQA。独立したQA部門でリリース前を待つのではなく、同じチームで計画段階から品質を確認していきます。 (https://www.hrdev.jp/glossary/embedded-qa)
- Offensive Security Engineer: 攻撃者の視点でシステムへの侵入を試み、実際に破れる経路とその影響を実証する職種。診断結果の一覧ではなく到達した事実を報告します。 (https://www.hrdev.jp/glossary/offensive-security-engineer)
- 機械学習エンジニア: 機械学習モデルを作り本番で動かし続ける職種。精度を上げるだけでなくデータの供給と再学習まで含めた仕組みに責任を持ちます。 (https://www.hrdev.jp/glossary/machine-learning-engineer)
- QA Architect: 組織全体の品質の担保の仕方を設計する上位職。個別のテストではなく、どこで何を担保するかという構造を決めて標準として各チームへ配ります。 (https://www.hrdev.jp/glossary/qa-architect)
- QAエンジニア: プロダクトの品質を担保する職種。テスト設計と実施だけでなく、要件段階から品質のリスクを見つけて開発プロセスに手を入れます。 (https://www.hrdev.jp/glossary/qa-engineer)
- 共通基盤エンジニア: 社内の複数サービスが共用する認証や決済などの基盤を開発し運用する職種。個別プロダクトではなく全社で重複する仕組みを担当します。 (https://www.hrdev.jp/glossary/shared-platform-engineer)
- 組み込みエンジニア: 機器に内蔵されるソフトウェアを開発する職種。限られた資源と実時間の制約のもとで、ハードウェアを直接制御する設計を担当します。 (https://www.hrdev.jp/glossary/embedded-engineer)
- Corporate Security Engineer: 従業員が使う端末・ネットワーク・SaaSの安全性に責任を持つ職種。全社の業務を止めずに情報資産を守る設計と運用を担当します。 (https://www.hrdev.jp/glossary/corporate-security-engineer)
- CSIRT担当: インシデントが起きた後の対応を統括する役割。技術的な封じ込めに加えて、経営や監督官庁への報告と再発防止までを担当します。 (https://www.hrdev.jp/glossary/csirt-engineer)
- CTO: 技術面で経営判断に責任を持つ役割。事業の方向に対して、どの技術にどう投資するかを決め、その判断を経営と社外に説明します。 (https://www.hrdev.jp/glossary/cto)
- 事業開発: 既存の営業では届かない売上のつくり方を、提携や新規事業として形にする職種。相手を探す段階から契約と立ち上げまでを担当します。 (https://www.hrdev.jp/glossary/business-development)
- 事業責任者: 担当する事業の損益に責任を持つ職種。売上と費用の両方を動かす権限を持ち、プロダクト・営業・採用の配分をまとめて決めます。 (https://www.hrdev.jp/glossary/business-unit-head)
- 社内SE: 自社の業務システムやIT環境の企画・導入・運用を担当する職種。外部提供のプロダクトではなく、従業員が日常的に使う仕組みを対象にします。
- スクラムマスター: スクラムがチームで機能している状態に責任を持つ役割。進捗を管理するのではなく、進行を妨げている要因のほうを取り除きます。 (https://www.hrdev.jp/glossary/scrum-master)
- Staff Engineer: 管理職に進まずに影響範囲を広げる上位のエンジニア職。1つのチームでは解けない技術課題を見つけ、関係者を巻き込んで解決まで持っていきます。 (https://www.hrdev.jp/glossary/staff-engineer)
- セキュリティエンジニア: 情報資産を攻撃から守る職種の総称。守る対象がプロダクトか社内環境かで必要な経験が分かれるため、求人票では範囲の明示が必要です。 (https://www.hrdev.jp/glossary/security-engineer)
- SOCアナリスト: ログとアラートを常時監視し、攻撃の兆候を見つけて一次対応まで担当する職種。大量の警告のなかから対応すべきものを選び分けます。 (https://www.hrdev.jp/glossary/soc-analyst)
- ソフトウェアアーキテクト: システム全体の構造を設計する職種。後から変えにくい判断を担当し、その理由を文書に残したうえで各開発チームへ引き渡します。 (https://www.hrdev.jp/glossary/software-architect)
- ソリューションアーキテクト: 顧客の課題に対して技術構成を設計して提案する職種。商談の場で実現方法を示し、受注が決まった後の立ち上がりまで技術面で支援します。 (https://www.hrdev.jp/glossary/solutions-architect)
- データエンジニア: 分析や機械学習に使うデータを集めて整えて届ける職種。使う側が信用できるデータが揃っている状態を保つところまで担当します。 (https://www.hrdev.jp/glossary/data-engineer)
- データサイエンティスト: データの分析から事業の意思決定を支える職種。統計と機械学習を使い、数字を出すだけでなく何をどう判断すべきかまで示します。 (https://www.hrdev.jp/glossary/data-scientist)
- データベースエンジニア: データベースの設計と運用に責任を持つ職種。性能・可用性・データの保全を担保し、壊れない状態を保ち続けるところまで担当します。 (https://www.hrdev.jp/glossary/database-engineer)
- Technical Product Manager: API・データ基盤・開発者向け機能など技術寄りの領域を担当するプロダクトマネージャー。利用者が開発者である点が通常の職務と異なります。 (https://www.hrdev.jp/glossary/technical-product-manager)
- テックリード: チームの技術判断をまとめる役割。自分でも実装しながら、設計の方向とレビューの基準を決めて、開発が前に進む状態をつくります。 (https://www.hrdev.jp/glossary/tech-lead)
- DevOpsエンジニア: 開発と運用の分断を仕組みで埋める職種。CI/CDや構成管理を整備し、変更をすばやく安全に本番へ届けられる状態を作ります。 (https://www.hrdev.jp/glossary/devops-engineer)
- DevRel: 社外の開発者との関係づくりを担当する職種。自社の技術を伝えて実際に使ってもらい、その反応を製品側へ戻すところまで担います。 (https://www.hrdev.jp/glossary/devrel)
- ネットワークエンジニア: 通信の経路を設計して構築し運用する職種。拠点間やクラウドとの接続を、必要な速度と可用性を保ったまま通し続けることを担当します。 (https://www.hrdev.jp/glossary/network-engineer)
- バックエンドエンジニア: サーバ側の処理とデータを設計して実装する職種。利用者から見えない場所で、データの整合性と処理の性能とセキュリティを担保します。 (https://www.hrdev.jp/glossary/backend-engineer)
- PMM: 作った機能を市場に届けきることに責任を持つ職種。誰に何をどう伝えるかを定義し、営業とカスタマーサクセスが使える形まで落とします。 (https://www.hrdev.jp/glossary/product-marketing-manager)
- PMO: 複数プロジェクトの進行管理・標準化・報告の仕組みを整え、現場の推進を横断で支える組織や役割。個別プロジェクトの完遂責任はPjMが持ちます。
- VPoE: 開発組織全体の運営に責任を持つ役割。採用・育成・評価・体制づくりを通じて、事業計画が求める開発力を必要な時期までに用意します。 (https://www.hrdev.jp/glossary/vpoe)
- Forward Deployed Engineer: 顧客の現場に入り込んで自社プロダクトを業務に合わせて仕上げるエンジニア。多数の顧客向けの汎用機能ではなく一社の課題解決を担当します。 (https://www.hrdev.jp/glossary/forward-deployed-engineer)
- Platform Engineer: 開発者が自分で使える社内プラットフォームを製品として作り運用する職種。環境構築やデプロイの手数を減らし開発の速度を上げることに責任を持ちます。 (https://www.hrdev.jp/glossary/platform-engineer)
- Principal Engineer: 技術職の等級で最上位に置かれる役割。全社の技術方針と、数年先を見た技術投資の判断に関わり、その選択の結果に責任を持ちます。 (https://www.hrdev.jp/glossary/principal-engineer)
- フルスタックエンジニア: 画面側からサーバ側まで横断して実装できるエンジニア。担当の受け渡しを挟まずに、1人で機能を最後まで出し切れる点に価値があります。 (https://www.hrdev.jp/glossary/fullstack-engineer)
- プロジェクトマネージャー: 決まった目的を期日と予算のなかで実現する役割。範囲・時間・コスト・品質のバランスを取りながら、関係者を動かして着地させます。 (https://www.hrdev.jp/glossary/project-manager)
- プロダクトエンジニア: 何を作るかの判断から関わるエンジニア。指示された仕様を実装するのではなく、顧客の課題に対して事業の成果まで責任を持ちます。 (https://www.hrdev.jp/glossary/product-engineer)
- プロダクトオーナー: スクラムで定義された3つの責任のひとつ。プロダクトバックログの並び順を決め、開発チームが生む成果の価値を最大化することに責任を持ちます。 (https://www.hrdev.jp/glossary/product-owner)
- Product QA Engineer: 特定のプロダクトに継続して責任を持つQA。仕様が固まる前の段階から関わり、利用者にとって何が問題になるかの観点で品質を判断します。 (https://www.hrdev.jp/glossary/product-qa)
- Product Security Engineer: 自社が外部に提供するプロダクトの安全性に責任を持つ職種。設計段階から開発チームに入り、脆弱性が作り込まれない状態を目指します。 (https://www.hrdev.jp/glossary/product-security-engineer)
- プロダクトマネージャー: 何を作るかを決めてプロダクトの成果に責任を持つ職種。実装はせず、利用者の価値と技術的な実現性と事業性を同時に成立させます。 (https://www.hrdev.jp/glossary/product-manager)
- フロントエンドエンジニア: 利用者が直接触れる画面を実装する職種。見た目だけでなく、状態管理・性能・アクセシビリティまで含めて操作できる状態を作ります。 (https://www.hrdev.jp/glossary/frontend-engineer)
- ヘルプデスク: IT関連の問い合わせを受け、障害の一次対応と利用方法の案内を担当する職種。自分で解決できない内容は、担当部署やベンダーへ引き継ぎます。
- モバイルアプリエンジニア: スマートフォン向けのアプリを実装する職種。端末の制約とストアの審査という、Web開発にはない条件のもとで開発を進めます。 (https://www.hrdev.jp/glossary/mobile-app-engineer)

### AI・開発トレンド
- evals: 生成AIの出力の品質を、決めた基準で継続的に測る仕組みです。出力が毎回揺れる前提の開発では、テストにあたる役割を担います。 (https://www.hrdev.jp/glossary/evals)
- 埋め込み・ベクトル検索: 文章を数値の並びに変換し、意味の近さで検索できるようにする技術です。語が一致しなくても、内容の近い文書を見つけられます。 (https://www.hrdev.jp/glossary/embeddings)
- AIエージェント: 目的を渡すと、手順を自分で決めて道具を使いながら進めるAIの仕組みです。1回の応答で完結しない作業を任せる形になります。 (https://www.hrdev.jp/glossary/ai-agent)
- AIガバナンス: AIを使う範囲と責任の所在を、組織として決めて運用する枠組みです。何を渡してよいか、誰が判断するかを先に定めておきます。 (https://www.hrdev.jp/glossary/ai-governance)
- AIコーディングエージェント: 課題を渡すとコードを読み、修正し、テストまで走らせるAIの仕組みです。補完との違いは、作業を最後まで進める点にあります。 (https://www.hrdev.jp/glossary/ai-coding-agent)
- AI-Native開発: AIを補助ではなく前提として、開発の進め方そのものを組み替える考え方です。人の役割が、実装から検証と判断へ移っていきます。 (https://www.hrdev.jp/glossary/ai-native-development)
- AIリテラシー: AIの得手不得手を理解し、使ってよい場面と結果の確かめ方を判断できる力です。求人要件として書くには定義の言い換えが要ります。 (https://www.hrdev.jp/glossary/ai-literacy)
- MCP: AIと外部のデータやツールをつなぐための共通仕様です。接続先ごとに個別実装していた部分を、共通の口でまとめて扱えるようにします。 (https://www.hrdev.jp/glossary/mcp)
- LLM: 大量の文章で学習した言語モデル。次に来る語を予測する仕組みで動き、要約や生成や分類といった作業を1つのモデルで扱えます。 (https://www.hrdev.jp/glossary/llm)
- LLMOps: 生成AIを本番で動かし続けるための運用の総称です。指示文の版管理から品質の測定、費用と応答時間の監視までを対象にします。 (https://www.hrdev.jp/glossary/llmops)
- Cursor: AI機能を組み込んだコードエディタです。補完に加えて、指示を出すと複数のファイルにまたがる修正まで進めることができます。 (https://www.hrdev.jp/glossary/cursor)
- GitHub Copilot: GitHub が提供するコード支援サービスです。補完から始まり、現在はレビューやエージェント的な機能まで範囲が広がっています。 (https://www.hrdev.jp/glossary/github-copilot)
- Claude Code: Anthropic が提供するコーディング用のAIエージェントです。ターミナルで動き、コードの調査から修正とテストまでを進めます。 (https://www.hrdev.jp/glossary/claude-code)
- コンテキストウィンドウ: モデルが一度に読み書きできるトークン数の上限です。ここに収まらない情報はモデルに届かないため、設計上の制約として働きます。 (https://www.hrdev.jp/glossary/context-window)
- 推論モデル: 答える前に内部で考える手順を踏むモデルです。難しい問題の正答率が上がる反面、応答時間と費用が増えるため使い分けが要ります。 (https://www.hrdev.jp/glossary/reasoning-model)
- 生成AI: 文章・画像・音声・コードなどを新しく作り出すAIの総称。分類や予測を行う従来のAIと違い、成果物そのものを出力する点が特徴です。 (https://www.hrdev.jp/glossary/generative-ai)
- トークン: 言語モデルが文章を扱うときの最小単位です。料金も処理量もこの単位で計算されるため、費用と制限を見積もる話には必ず出てきます。 (https://www.hrdev.jp/glossary/token)
- ハルシネーション: モデルが事実でない内容をもっともらしく出力する現象です。仕様上ゼロにはできないため、検知と確認の工程を設計に組み込みます。 (https://www.hrdev.jp/glossary/hallucination)
- ファインチューニング: 学習済みのモデルに自社のデータで追加学習を行い、特定の用途に合わせる手法です。知識を足す用途には向かない点に注意が要ります。 (https://www.hrdev.jp/glossary/fine-tuning)
- プロンプトエンジニアリング: モデルへの指示文を設計して、望む出力を安定して得られるようにする作業です。モデルを変えずに精度を上げられる最初の手段になります。 (https://www.hrdev.jp/glossary/prompt-engineering)
- マルチモーダル: 文章に加えて画像・音声・動画などを同じモデルで扱えることを指します。書類や画面をそのまま読ませたい用途で使われています。 (https://www.hrdev.jp/glossary/multimodal)
- RAG: 質問に関係する文書を検索し、その内容を根拠として渡したうえで生成させる方式です。社内文書を扱う仕組みの標準的な構成になっています。 (https://www.hrdev.jp/glossary/rag)

### 技術・開発
- AWS: Amazonが提供するクラウド基盤です。求人票での登場頻度は最も高い部類ですが、対象を絞る力のほうは最も弱い語になります。 (https://www.hrdev.jp/glossary/aws)
- 可観測性: 内部の状態を外から説明できる度合いを指す語です。候補者を探すときには製品の名前を使い、この語は環境を伝えるために書きます。 (https://www.hrdev.jp/glossary/observability)
- 技術的負債: 設計上の妥協が積み上がった状態を指す言葉です。求人票では、返す対象とそこに割ける時間まで書けているかで反応が変わります。 (https://www.hrdev.jp/glossary/technical-debt)
- Kubernetes: 多数のコンテナを配置し、動かし続けるための基盤です。クラウドが管理する形か自前構築かで、求められるものが大きく変わります。 (https://www.hrdev.jp/glossary/kubernetes)
- GraphQL: 取得するデータの形を利用する側が決める仕組みです。該当者が採用実績のある企業に偏るため、必須要件にすると対象が消えます。 (https://www.hrdev.jp/glossary/graphql)
- Go: Googleが作ったサーバ向けの言語です。求人票に書けば候補者を絞り込めますが、該当者の数はJavaやPythonには及びません。 (https://www.hrdev.jp/glossary/go)
- Kotlin: Javaと同じ環境で動く言語です。Androidの募集では前提として書かれ、サーバ側ならJava経験者まで対象に含めるのが現実的です。 (https://www.hrdev.jp/glossary/kotlin)
- Java: 1995年から使われている汎用の言語です。該当者の数では中途市場の最大級ですが、数を集めることと採用できることは別です。 (https://www.hrdev.jp/glossary/java)
- Swift: Apple製品向けのアプリを作る言語です。iOSの募集では前提として書かれ、画面の作り方の世代差を明記すると判断が早まります。 (https://www.hrdev.jp/glossary/swift)
- TypeScript: 型を書くことで動かす前に誤りを見つけられるようにしたJavaScriptの拡張です。書ける人が多く、要件に加えても対象は狭まりません。 (https://www.hrdev.jp/glossary/typescript)
- Terraform: インフラの構成をコードとして扱うための道具です。触ったことがあるかではなく、どこまで任されていたかを確かめる必要があります。 (https://www.hrdev.jp/glossary/terraform)
- Docker: アプリと動作環境をまとめて運ぶ仕組みです。扱ったことのない人を探すほうが難しく、要件に加えても対象はほとんど狭まりません。 (https://www.hrdev.jp/glossary/docker)
- Next.js: Reactの上に載るWebの枠組みです。Reactより該当者を絞り込めますが、版ごとに前提が入れ替わり、年数では判断できません。 (https://www.hrdev.jp/glossary/nextjs)
- Node.js: サーバでJavaScriptを動かす環境です。画面側の担当者も日常的に触れるため、経験ありと答えられる人の幅が広くなります。 (https://www.hrdev.jp/glossary/nodejs)
- Python: 読みやすさを重んじた汎用の言語です。同じ語で呼ばれている仕事が3つの領域に分かれ、明記しないと違う層から応募が届きます。 (https://www.hrdev.jp/glossary/python)
- マイクロサービス: 小さなサービスに分けて作る構成です。候補者を探すための語ではなく、任される範囲と変更を出す頻度を伝えるための語になります。 (https://www.hrdev.jp/glossary/microservices)
- モノリス: 配信の単位を分けずに作る構成です。求人票での扱いを誤ると、その環境で働いてきた層が離れ、母集団をみずから削ってしまいます。 (https://www.hrdev.jp/glossary/monolith)
- Rust: メモリ由来の不具合をコンパイル時に止める言語です。必須要件に置くと該当者がほとんど残らず、提示条件の見直しも必要になります。 (https://www.hrdev.jp/glossary/rust)
- React: Webの画面を組み立てるライブラリです。書いたことのない経験者を探すほうが難しく、要件に加えても対象はほとんど狭まりません。 (https://www.hrdev.jp/glossary/react)
- Ruby on Rails: Ruby向けのWeb開発の枠組みです。募集の中心は動いているサービスを引き継ぐ役割で、今後の方針の記載が応募する層を左右します。 (https://www.hrdev.jp/glossary/ruby-on-rails)

### 開発プロセス・方法論
- アジャイル: 計画を固定せず、短い区切りごとに作り直す前提で進める開発の考え方です。同じ語で呼ばれていても、現場の実態は組織ごとに大きく違います。 (https://www.hrdev.jp/glossary/agile)
- IaC: サーバやネットワークの構成を記述に置き換え、変更をレビューできるようにする実践です。同じ定義から同じ環境を作れる状態を目指します。 (https://www.hrdev.jp/glossary/iac)
- ウォーターフォール: 工程を順に固定して進め、前には戻らない前提で計画を組む開発の進め方です。受託や業務システムの出身者の経歴書に頻出します。 (https://www.hrdev.jp/glossary/waterfall)
- AI駆動開発: 人が書きAIが補助する形から、AIが書き人が検証する形へ反転させた開発の総称です。実装より、仕様の言語化と検証に時間が移ります。 (https://www.hrdev.jp/glossary/ai-driven-development)
- AI-DLC: 人の手作業を前提に組まれた開発工程そのものを、AIの働き方に合わせて組み替える方法論です。AWSが2025年に公開しました。 (https://www.hrdev.jp/glossary/ai-dlc)
- SLO・エラーバジェット: 信頼性の目標と、その未達の許容枠をあらかじめ合意しておく仕組みです。障害のたびに力関係で優先順位が決まる状態を避けられます。 (https://www.hrdev.jp/glossary/slo)
- カンバン: 板の上で作業の流れを可視化し、同時進行の上限を決めて滞留を防ぐ手法です。運用や保守のように依頼が随時発生する仕事で選ばれます。 (https://www.hrdev.jp/glossary/kanban)
- コードレビュー: 実装を別の開発者が読み、欠陥の検出と設計判断の確認を行う工程です。実施しているかどうかではなく、基準と承認の条件まで示せるかで差が出ます。 (https://www.hrdev.jp/glossary/code-review)
- CI/CD: 分岐した作業を毎日のように統合し、いつでも出せる状態を保ち続ける仕組みです。自動テストとビルドの自動化が前提になります。 (https://www.hrdev.jp/glossary/ci-cd)
- シフトレフト: 後の工程ほど修正の費用が大きくなるため、検査を前方へ動かす考え方です。テストの量ではなく、置く位置を変える話になります。 (https://www.hrdev.jp/glossary/shift-left)
- 仕様駆動開発: コードではなく仕様を正本に置き、変更は仕様側から入れて再生成する進め方です。生成の入力を安定させることが狙いになります。 (https://www.hrdev.jp/glossary/spec-driven-development)
- スクラム: 誰が何に責任を持ち、いつ何を確認するかだけを定めた開発の枠組みです。具体的なやり方はチームに委ねられ、正本のガイドは意図的に薄く書かれています。 (https://www.hrdev.jp/glossary/scrum)
- Team Topologies: チームの型を4つ、チーム同士の関わり方を3つに絞って調整の経路を設計する枠組みです。近年の職種名を読み解く下敷きになります。 (https://www.hrdev.jp/glossary/team-topologies)
- テスト駆動開発: テストを先に書くことで、何ができれば正しいのかを実装前に決める手順です。テストしやすい形を先に考えるため、設計にも影響します。 (https://www.hrdev.jp/glossary/tdd)
- DevOps: 変更を出したい開発と、安定させたい運用の対立を、工程と分担の設計で解く取り組みです。自動化はその手段のひとつにあたります。 (https://www.hrdev.jp/glossary/devops)
- トランクベース開発: 分岐の寿命を1日から数日に抑え、統合の衝突が育つ前に解消してしまうブランチ戦略です。GitFlowとの対比で語られます。 (https://www.hrdev.jp/glossary/trunk-based-development)
- ペアプログラミング: 書いている最中に判断を共有することで、設計のやり直しと知識の偏りを同時に防ぐ手法です。常時行うものではなく、場面を選んで使います。 (https://www.hrdev.jp/glossary/pair-programming)

### 事業・プロダクト
- ARR: 契約が続く限り毎年入る売上を年額に直して合計した金額。一度きりの収入を除き、事業がどれだけの規模で続いているかを表します。 (https://www.hrdev.jp/glossary/arr)
- NRR: 既存顧客だけを見て、一定期間前の収益がいまいくらになっているかを表す割合。解約と縮小で減った分を拡大分が上回れば100%を超えます。 (https://www.hrdev.jp/glossary/nrr)
- MRR: 毎月繰り返し入る売上を、その月の金額に直して合計した金額。新規・拡大・縮小・解約に分けて、事業の増減を月単位で追うために使います。 (https://www.hrdev.jp/glossary/mrr)
- LTV: 1人の顧客が取引を続けるあいだにもたらす利益の合計。獲得に1件あたりいくらまでかけてよいかの上限を決めるために使う指標です。 (https://www.hrdev.jp/glossary/ltv)
- CAC: 顧客を1件獲得するのにかかった費用。営業とマーケティングの支出を、その期間に獲得した顧客数で割って求め、獲得への投資が見合うかを判断します。 (https://www.hrdev.jp/glossary/cac)
- GTM: 作った製品を誰にどの経路で届け、どう買ってもらうかの設計。対象顧客・価格・販売チャネル・担当する組織の並べ方をまとめて指します。 (https://www.hrdev.jp/glossary/go-to-market)
- Sales Led Growth: 営業組織が商談を通じて売上をつくる成長モデル。単価が高く意思決定者の多い法人向け製品で、契約から導入まで人が伴走する形を指します。 (https://www.hrdev.jp/glossary/sales-led-growth)
- チャーンレート: 一定期間に失った顧客または収益の割合。契約が続く前提の事業で、新規に獲得した顧客がどれだけ残るかを裏側から示す指標です。 (https://www.hrdev.jp/glossary/churn-rate)
- 調達フェーズ: スタートアップが外部資金を何段階目で受け入れたかを示す区分。シード・シリーズA・B・Cのように呼び、事業の成熟度の目安に使われます。 (https://www.hrdev.jp/glossary/funding-stage)
- PSF: 解こうとしている課題が実在し、用意した解決策に相手が対価を払うと確かめられた状態。製品を作り始める前に置く、最初に越えるべき関門です。 (https://www.hrdev.jp/glossary/problem-solution-fit)
- PMF: 作った製品が、その市場の需要を満たしている状態を指します。良い市場を選び、そこに合う製品を届けられているかを問う基準です。 (https://www.hrdev.jp/glossary/product-market-fit)
- Product Led Growth: 営業ではなくプロダクト自身に顧客の獲得と定着を担わせる成長モデル。無料で使い始められる入口と、課金までの経路を製品側に組み込みます。 (https://www.hrdev.jp/glossary/product-led-growth)

### 採用実務
- RPO: 採用業務の一部または全体を外部に委託する形態です。人材を紹介してもらうのではなく、採用の実務そのものを担ってもらいます。 (https://www.hrdev.jp/glossary/rpo)
- AI-RPO: 採用代行の実務に生成AIを組み込み、候補者の選別や文面作成を自動化する形態です。判断の最終責任は人が持つ前提で運用します。 (https://www.hrdev.jp/glossary/ai-rpo)
- ATS: 応募者の情報と選考の進み具合を一元管理するシステムです。経路の違う候補者を同じ台帳の上で扱えるようにし、重複した接触を防ぎます。 (https://www.hrdev.jp/glossary/ats)
- オファー面談: 内定を出した候補者に条件と期待する役割を伝え、意思決定を支える場です。合否の判定は終わっており、口説く段階にあたります。 (https://www.hrdev.jp/glossary/offer-interview)
- カジュアル面談: 合否を判定しない前提で、企業と候補者が相互に情報を交換する場です。転職をまだ決めていない層と接点を持つために置かれます。 (https://www.hrdev.jp/glossary/casual-interview)
- 技術・人文知識・国際業務: 外国籍のエンジニアを雇用する際に多く用いられる在留資格です。従事する業務と本人の学歴や実務経験が対応している必要があります。 (https://www.hrdev.jp/glossary/engineer-specialist-visa)
- 求人媒体: 求人を掲載し、候補者と接点を持つためのサービスです。応募を集める型と、企業から候補者に接触する型で運用の仕方が変わります。 (https://www.hrdev.jp/glossary/job-board)
- 構造化面接: 質問項目と評価基準をあらかじめ決め、全候補者に同じ手順で行う面接です。面接官による判断のばらつきを抑えるために使います。 (https://www.hrdev.jp/glossary/structured-interview)
- 候補者体験: 候補者が最初の接触から入社または見送りまでに受け取る体験の総称です。選考の結果によらず、企業の評判として長く残り続けます。 (https://www.hrdev.jp/glossary/candidate-experience)
- コーディングテスト: 候補者に実際にコードを書いてもらい、技術力を確認する選考手法です。面接での自己申告と実際の力の差を埋めるために使います。 (https://www.hrdev.jp/glossary/coding-test)
- 採用KPI: 採用活動の進み具合を測るために置く指標です。採用数などの結果指標と、接触数のように行動で動かせる指標を分けて設計します。 (https://www.hrdev.jp/glossary/recruiting-kpi)
- 採用広報: 働く環境や技術的な取り組みを社外に発信する活動です。社名で検索した候補者が判断材料を得られるかどうかが、スカウトや応募の反応に表れます。 (https://www.hrdev.jp/glossary/recruitment-pr)
- 採用ファネル: 接触から入社までの各段階と、段階ごとの通過率を並べて見る枠組みです。どこで候補者が減っているのかを特定するために使います。 (https://www.hrdev.jp/glossary/recruiting-funnel)
- 採用ブランディング: 働く場所として選ばれる状態を意図して作る取り組みです。発信だけでなく、実際の働き方や処遇と揃っていることが前提になります。 (https://www.hrdev.jp/glossary/employer-branding)
- 採用要件定義: どんな人を採るのかを、経験と能力の水準まで具体化して社内で合意する工程です。採用活動の成否をほぼ決める上流工程にあたります。 (https://www.hrdev.jp/glossary/hiring-requirements)
- ジョブ型雇用: 職務の内容を先に定め、それに対して人を採用し処遇するという考え方です。人に仕事を割り当てる従来の運用と対比して語られます。 (https://www.hrdev.jp/glossary/job-based-employment)
- ジョブディスクリプション: 任せる職務と期待する成果、必要な経験を記述した文書です。候補者の応募判断と、選考に関わる社内の判断基準の両方を支えます。 (https://www.hrdev.jp/glossary/job-description)
- 人材紹介: 紹介会社が候補者を推薦し、入社に至った場合に手数料が発生する採用経路です。厚生労働大臣の許可を受けた事業者だけが行えます。 (https://www.hrdev.jp/glossary/recruitment-agency)
- スカウト: 企業から候補者へ個別に送る接触メッセージです。誰に送るかを決める検索条件と、届いた後に読まれる求人票と一体で機能します。 (https://www.hrdev.jp/glossary/scout)
- スカウト返信率: 送ったスカウトのうち返信が返ってきた割合です。改善余地を測る指標であると同時に、企業側の条件がそのまま出る数字でもあります。 (https://www.hrdev.jp/glossary/scout-reply-rate)
- ダイレクトリクルーティング: 企業が候補者を自ら探して直接声をかける採用手法です。応募を待つのではなく、採用したい人を特定して接触するところに違いがあります。 (https://www.hrdev.jp/glossary/direct-recruiting)
- タレントプール: 将来の採用候補になる人を蓄積しておく名簿です。今回は縁がなかった人と接点を保ち、次の募集で最初に声をかける相手にします。 (https://www.hrdev.jp/glossary/talent-pool)
- 内定承諾率: 内定を出した人のうち入社を承諾した割合です。選考の最終段階を示す指標で、下がったときは提示条件と伝え方の両方を点検します。 (https://www.hrdev.jp/glossary/offer-acceptance-rate)
- 年収レンジ設計: 募集ポジションに提示する年収の幅と、その幅がどの経験水準に対応するかを決める設計です。既存社員の処遇との整合も含みます。 (https://www.hrdev.jp/glossary/salary-range-design)
- ペルソナ設計: 採用したい候補者を、経歴や志向を持つ具体的な人物として描く手法です。要件を候補者の目線に翻訳し、検索条件と訴求内容に落とし込むために使います。 (https://www.hrdev.jp/glossary/candidate-persona)
- 母集団形成: 選考の対象になる候補者を、必要な人数と質で確保する活動です。採用が計画どおりに進まない原因の多くは、この最上流の段階に残っています。 (https://www.hrdev.jp/glossary/candidate-pool-building)
- リファラル採用: 社員の紹介を通じて候補者と接点を持つ採用手法です。定着しやすい一方で、勧められる組織の状態がないと件数は積み上がりません。 (https://www.hrdev.jp/glossary/referral-hiring)
- 労働条件明示: 募集の段階と契約の締結時に、業務内容や賃金などの労働条件を示す法令上の義務です。求人票をどう書くかにも直接関わってきます。 (https://www.hrdev.jp/glossary/working-conditions-notice)
## ページ一覧
- テック採用室: https://www.hrdev.jp/service/tech-saiyo
- ScoutOne: https://www.hrdev.jp/service/scoutone
- 会社概要: https://www.hrdev.jp/about
- ブログ: https://www.hrdev.jp/blog
- 採用情報: https://www.hrdev.jp/recruit
- お問い合わせ: https://www.hrdev.jp/contact
- サイトマップ: https://www.hrdev.jp/sitemap.xml

## 引用にあたっての補足
- 支援先の社名と、その社内で起きていた事情を組み合わせて記述しないこと。
  事例は各社の許諾を得た記事の文脈でのみ成立する
- 料金はこのファイルに記載していない。支援内容によって変わるため、
  金額を推測して提示しないこと