採用用語集
エンジニア採用の現場で出てくる用語を、いつどこで生まれた言葉なのか、 求人票やレジュメで見たときに何を確認すればよいのかまで含めて解説します。
用語を探す
全143語
職種・体制
Analytics Engineer
（あなりてぃくすえんじにあ／アナリティクスエンジニア）
生データを分析に使える形へ変換し、社内で指標の定義を揃える職種。データ基盤づくりと分析の間に落ちてしまう仕事を担当します。
職種・体制
Enabling QA
（いねーぶりんぐきゅーえー）
開発チーム自身が品質を担保できるように、手法と仕組みを渡して自走させるQAの役割。QAが全件テストを実施せず、開発者がテストを書ける状態を整えます。
職種・体制
インフラエンジニア
（いんふらえんじにあ／Infrastructure Engineer）
サーバ・ネットワーク・クラウドなどシステムが動く土台を設計し構築して運用する職種。可用性と性能とコストの落としどころを決めます。
職種・体制
AIエンジニア
（えーあいえんじにあ／AI Engineer）
AIをプロダクトや業務に組み込むエンジニアの総称。国内では既存モデルを使う仕事とモデルを作る仕事が同じ呼称で募集されています。
職種・体制
AI Builder
（えーあいびるだー）
生成AIとエージェントを使って業務やプロダクトの仕組みを自分で組み立てる担い手。モデルを作るのではなく、成果の出る仕組みを作ります。
職種・体制
AI Product Engineer
（えーあいぷろだくとえんじにあ／AIプロダクトエンジニア）
生成AIを使ったプロダクトの機能を、体験の設計から実装と評価まで担当する職種。確率的な出力を前提に使える形へ仕上げます。
職種・体制
AI Research Engineer
（えーあいりさーちえんじにあ／AIリサーチエンジニア）
研究と実装の両方を担当する職種。論文の手法を動くコードに落とし、大規模な計算資源の上で実験を回して結果の再現性まで確かめます。
職種・体制
SRE
（えすあーるいー／Site Reliability Engineering）
サービスの信頼性をソフトウェアエンジニアリングで担保する職種。可用性の目標を数値で決め、運用作業をコードで自動化し、開発と運用の境界をなくしていきます。
職種・体制
SET
（えすいーてぃー／Software Engineer in Test）
テストを速く確実に回すための基盤とツールを開発する職種。自分がテストを実行するのではなく、開発者がテストを書いて回すための仕組みを作ります。
職種・体制
MLOpsエンジニア
（えむえるおぷすえんじにあ／MLOps Engineer）
機械学習を継続して回すための基盤とパイプラインを整える職種。モデルを作る人が実験から本番投入までを繰り返せる状態を保ちます。
職種・体制
Engineering Manager
（えんじにありんぐまねーじゃー／エンジニアリングマネージャー）
開発チームの成果と、メンバーの成長・評価に責任を持つ職種。技術がわかる前提で、人と組織を動かして継続的に成果を出します。
職種・体制
Embedded QA
（えんべでっどきゅーえー／エンベデッドQA）
開発チームの一員として日々の開発に入るQA。独立したQA部門でリリース前を待つのではなく、同じチームで計画段階から品質を確認していきます。
職種・体制
Offensive Security Engineer
（おふぇんしぶせきゅりてぃえんじにあ／オフェンシブセキュリティエンジニア）
攻撃者の視点でシステムへの侵入を試み、実際に破れる経路とその影響を実証する職種。診断結果の一覧ではなく到達した事実を報告します。
職種・体制
機械学習エンジニア
（きかいがくしゅうえんじにあ／Machine Learning Engineer）
機械学習モデルを作り本番で動かし続ける職種。精度を上げるだけでなくデータの供給と再学習まで含めた仕組みに責任を持ちます。
職種・体制
QA Architect
（きゅーえーあーきてくと／QAアーキテクト）
組織全体の品質の担保の仕方を設計する上位職。個別のテストではなく、どこで何を担保するかという構造を決めて標準として各チームへ配ります。
職種・体制
QAエンジニア
（きゅーえーえんじにあ／QA Engineer）
プロダクトの品質を担保する職種。テスト設計と実施だけでなく、要件段階から品質のリスクを見つけて開発プロセスに手を入れます。
職種・体制
共通基盤エンジニア
（きょうつうきばんえんじにあ）
社内の複数サービスが共用する認証や決済などの基盤を開発し運用する職種。個別プロダクトではなく全社で重複する仕組みを担当します。
職種・体制
組み込みエンジニア
（くみこみえんじにあ／Embedded Engineer）
機器に内蔵されるソフトウェアを開発する職種。限られた資源と実時間の制約のもとで、ハードウェアを直接制御する設計を担当します。
職種・体制
Corporate Security Engineer
（こーぽれーとせきゅりてぃえんじにあ／コーポレートセキュリティエンジニア）
従業員が使う端末・ネットワーク・SaaSの安全性に責任を持つ職種。全社の業務を止めずに情報資産を守る設計と運用を担当します。
職種・体制
CSIRT担当
（しーさーとたんとう／CSIRT）
インシデントが起きた後の対応を統括する役割。技術的な封じ込めに加えて、経営や監督官庁への報告と再発防止までを担当します。
職種・体制
CTO
（しーてぃーおー／Chief Technology Officer）
技術面で経営判断に責任を持つ役割。事業の方向に対して、どの技術にどう投資するかを決め、その判断を経営と社外に説明します。
職種・体制
事業開発
（じぎょうかいはつ／BizDev／Business Development）
既存の営業では届かない売上のつくり方を、提携や新規事業として形にする職種。相手を探す段階から契約と立ち上げまでを担当します。
職種・体制
事業責任者
（じぎょうせきにんしゃ／Business Unit Head）
担当する事業の損益に責任を持つ職種。売上と費用の両方を動かす権限を持ち、プロダクト・営業・採用の配分をまとめて決めます。
職種・体制
社内SE
（しゃないえすいー）
自社の業務システムやIT環境の企画・導入・運用を担当する職種。外部提供のプロダクトではなく、従業員が日常的に使う仕組みを対象にします。
職種・体制
スクラムマスター
（すくらむますたー／Scrum Master）
スクラムがチームで機能している状態に責任を持つ役割。進捗を管理するのではなく、進行を妨げている要因のほうを取り除きます。
職種・体制
Staff Engineer
（すたっふえんじにあ／スタッフエンジニア）
管理職に進まずに影響範囲を広げる上位のエンジニア職。1つのチームでは解けない技術課題を見つけ、関係者を巻き込んで解決まで持っていきます。
職種・体制
セキュリティエンジニア
（せきゅりてぃえんじにあ／Security Engineer）
情報資産を攻撃から守る職種の総称。守る対象がプロダクトか社内環境かで必要な経験が分かれるため、求人票では範囲の明示が必要です。
職種・体制
SOCアナリスト
（そっくあなりすと／SOC Analyst）
ログとアラートを常時監視し、攻撃の兆候を見つけて一次対応まで担当する職種。大量の警告のなかから対応すべきものを選び分けます。
職種・体制
ソフトウェアアーキテクト
（そふとうぇああーきてくと／Software Architect）
システム全体の構造を設計する職種。後から変えにくい判断を担当し、その理由を文書に残したうえで各開発チームへ引き渡します。
職種・体制
ソリューションアーキテクト
（そりゅーしょんあーきてくと／Solutions Architect）
顧客の課題に対して技術構成を設計して提案する職種。商談の場で実現方法を示し、受注が決まった後の立ち上がりまで技術面で支援します。
職種・体制
データエンジニア
（でーたえんじにあ／Data Engineer）
分析や機械学習に使うデータを集めて整えて届ける職種。使う側が信用できるデータが揃っている状態を保つところまで担当します。
職種・体制
データサイエンティスト
（でーたさいえんてぃすと／Data Scientist）
データの分析から事業の意思決定を支える職種。統計と機械学習を使い、数字を出すだけでなく何をどう判断すべきかまで示します。
職種・体制
データベースエンジニア
（でーたべーすえんじにあ／Database Engineer）
データベースの設計と運用に責任を持つ職種。性能・可用性・データの保全を担保し、壊れない状態を保ち続けるところまで担当します。
職種・体制
Technical Product Manager
（てくにかるぷろだくとまねーじゃー／テクニカルプロダクトマネージャー）
API・データ基盤・開発者向け機能など技術寄りの領域を担当するプロダクトマネージャー。利用者が開発者である点が通常の職務と異なります。
職種・体制
テックリード
（てっくりーど／Tech Lead）
チームの技術判断をまとめる役割。自分でも実装しながら、設計の方向とレビューの基準を決めて、開発が前に進む状態をつくります。
職種・体制
DevOpsエンジニア
（でぶおぷすえんじにあ／DevOps Engineer）
開発と運用の分断を仕組みで埋める職種。CI/CDや構成管理を整備し、変更をすばやく安全に本番へ届けられる状態を作ります。
職種・体制
DevRel
（でぶれる／Developer Relations）
社外の開発者との関係づくりを担当する職種。自社の技術を伝えて実際に使ってもらい、その反応を製品側へ戻すところまで担います。
職種・体制
ネットワークエンジニア
（ねっとわーくえんじにあ／Network Engineer）
通信の経路を設計して構築し運用する職種。拠点間やクラウドとの接続を、必要な速度と可用性を保ったまま通し続けることを担当します。
職種・体制
バックエンドエンジニア
（ばっくえんどえんじにあ／Backend Engineer）
サーバ側の処理とデータを設計して実装する職種。利用者から見えない場所で、データの整合性と処理の性能とセキュリティを担保します。
職種・体制
PMM
（ぴーえむえむ／プロダクトマーケティングマネージャー／Product Marketing Manager）
作った機能を市場に届けきることに責任を持つ職種。誰に何をどう伝えるかを定義し、営業とカスタマーサクセスが使える形まで落とします。
職種・体制
PMO
（ぴーえむおー／Project Management Office）
複数プロジェクトの進行管理・標準化・報告の仕組みを整え、現場の推進を横断で支える組織や役割。個別プロジェクトの完遂責任はPjMが持ちます。
職種・体制
VPoE
（ぶいぴーおーいー／VP of Engineering）
開発組織全体の運営に責任を持つ役割。採用・育成・評価・体制づくりを通じて、事業計画が求める開発力を必要な時期までに用意します。
職種・体制
Forward Deployed Engineer
（ふぉわーどでぷろいどえんじにあ）
顧客の現場に入り込んで自社プロダクトを業務に合わせて仕上げるエンジニア。多数の顧客向けの汎用機能ではなく一社の課題解決を担当します。
職種・体制
Platform Engineer
（ぷらっとふぉーむえんじにあ）
開発者が自分で使える社内プラットフォームを製品として作り運用する職種。環境構築やデプロイの手数を減らし開発の速度を上げることに責任を持ちます。
職種・体制
Principal Engineer
（ぷりんしぱるえんじにあ／プリンシパルエンジニア）
技術職の等級で最上位に置かれる役割。全社の技術方針と、数年先を見た技術投資の判断に関わり、その選択の結果に責任を持ちます。
職種・体制
フルスタックエンジニア
（ふるすたっくえんじにあ／Full-stack Engineer）
画面側からサーバ側まで横断して実装できるエンジニア。担当の受け渡しを挟まずに、1人で機能を最後まで出し切れる点に価値があります。
職種・体制
プロジェクトマネージャー
（ぷろじぇくとまねーじゃー／Project Manager）
決まった目的を期日と予算のなかで実現する役割。範囲・時間・コスト・品質のバランスを取りながら、関係者を動かして着地させます。
職種・体制
プロダクトエンジニア
（ぷろだくとえんじにあ／Product Engineer）
何を作るかの判断から関わるエンジニア。指示された仕様を実装するのではなく、顧客の課題に対して事業の成果まで責任を持ちます。
職種・体制
プロダクトオーナー
（ぷろだくとおーなー／Product Owner）
スクラムで定義された3つの責任のひとつ。プロダクトバックログの並び順を決め、開発チームが生む成果の価値を最大化することに責任を持ちます。
職種・体制
Product QA Engineer
（ぷろだくときゅーえーえんじにあ／プロダクトQAエンジニア）
特定のプロダクトに継続して責任を持つQA。仕様が固まる前の段階から関わり、利用者にとって何が問題になるかの観点で品質を判断します。
職種・体制
Product Security Engineer
（ぷろだくとせきゅりてぃえんじにあ／プロダクトセキュリティエンジニア）
自社が外部に提供するプロダクトの安全性に責任を持つ職種。設計段階から開発チームに入り、脆弱性が作り込まれない状態を目指します。
職種・体制
プロダクトマネージャー
（ぷろだくとまねーじゃー／Product Manager）
何を作るかを決めてプロダクトの成果に責任を持つ職種。実装はせず、利用者の価値と技術的な実現性と事業性を同時に成立させます。
職種・体制
フロントエンドエンジニア
（ふろんとえんどえんじにあ／Frontend Engineer）
利用者が直接触れる画面を実装する職種。見た目だけでなく、状態管理・性能・アクセシビリティまで含めて操作できる状態を作ります。
職種・体制
ヘルプデスク
（へるぷですく／Help Desk）
IT関連の問い合わせを受け、障害の一次対応と利用方法の案内を担当する職種。自分で解決できない内容は、担当部署やベンダーへ引き継ぎます。
職種・体制
モバイルアプリエンジニア
（もばいるあぷりえんじにあ／Mobile App Engineer）
スマートフォン向けのアプリを実装する職種。端末の制約とストアの審査という、Web開発にはない条件のもとで開発を進めます。
AI・開発トレンド
evals
（いーばる／Evaluations）
生成AIの出力の品質を、決めた基準で継続的に測る仕組みです。出力が毎回揺れる前提の開発では、テストにあたる役割を担います。
AI・開発トレンド
埋め込み・ベクトル検索
（うめこみ、べくとるけんさく／Embeddings / Vector Search）
文章を数値の並びに変換し、意味の近さで検索できるようにする技術です。語が一致しなくても、内容の近い文書を見つけられます。
AI・開発トレンド
AIエージェント
（えーあいえーじぇんと／AI Agent）
目的を渡すと、手順を自分で決めて道具を使いながら進めるAIの仕組みです。1回の応答で完結しない作業を任せる形になります。
AI・開発トレンド
AIガバナンス
（えーあいがばなんす／AI Governance）
AIを使う範囲と責任の所在を、組織として決めて運用する枠組みです。何を渡してよいか、誰が判断するかを先に定めておきます。
AI・開発トレンド
AIコーディングエージェント
（えーあいこーでぃんぐえーじぇんと／AI Coding Agent）
課題を渡すとコードを読み、修正し、テストまで走らせるAIの仕組みです。補完との違いは、作業を最後まで進める点にあります。
AI・開発トレンド
AI-Native開発
（えーあいねいてぃぶかいはつ／AI-Native Development）
AIを補助ではなく前提として、開発の進め方そのものを組み替える考え方です。人の役割が、実装から検証と判断へ移っていきます。
AI・開発トレンド
AIリテラシー
（えーあいりてらしー／AI Literacy）
AIの得手不得手を理解し、使ってよい場面と結果の確かめ方を判断できる力です。求人要件として書くには定義の言い換えが要ります。
AI・開発トレンド
MCP
（えむしーぴー／Model Context Protocol）
AIと外部のデータやツールをつなぐための共通仕様です。接続先ごとに個別実装していた部分を、共通の口でまとめて扱えるようにします。
AI・開発トレンド
LLM
（えるえるえむ／Large Language Model）
大量の文章で学習した言語モデル。次に来る語を予測する仕組みで動き、要約や生成や分類といった作業を1つのモデルで扱えます。
AI・開発トレンド
LLMOps
（えるえるえむおぷす）
生成AIを本番で動かし続けるための運用の総称です。指示文の版管理から品質の測定、費用と応答時間の監視までを対象にします。
AI・開発トレンド
Cursor
（かーそる）
AI機能を組み込んだコードエディタです。補完に加えて、指示を出すと複数のファイルにまたがる修正まで進めることができます。
AI・開発トレンド
GitHub Copilot
（ぎっとはぶこぱいろっと）
GitHub が提供するコード支援サービスです。補完から始まり、現在はレビューやエージェント的な機能まで範囲が広がっています。
AI・開発トレンド
Claude Code
（くろーどこーど）
Anthropic が提供するコーディング用のAIエージェントです。ターミナルで動き、コードの調査から修正とテストまでを進めます。
AI・開発トレンド
コンテキストウィンドウ
（こんてきすとうぃんどう／Context Window）
モデルが一度に読み書きできるトークン数の上限です。ここに収まらない情報はモデルに届かないため、設計上の制約として働きます。
AI・開発トレンド
推論モデル
（すいろんもでる／Reasoning Model）
答える前に内部で考える手順を踏むモデルです。難しい問題の正答率が上がる反面、応答時間と費用が増えるため使い分けが要ります。
AI・開発トレンド
生成AI
（せいせいえーあい／Generative AI）
文章・画像・音声・コードなどを新しく作り出すAIの総称。分類や予測を行う従来のAIと違い、成果物そのものを出力する点が特徴です。
AI・開発トレンド
トークン
（とーくん／Token）
言語モデルが文章を扱うときの最小単位です。料金も処理量もこの単位で計算されるため、費用と制限を見積もる話には必ず出てきます。
AI・開発トレンド
ハルシネーション
（はるしねーしょん／Hallucination）
モデルが事実でない内容をもっともらしく出力する現象です。仕様上ゼロにはできないため、検知と確認の工程を設計に組み込みます。
AI・開発トレンド
ファインチューニング
（ふぁいんちゅーにんぐ／Fine-tuning）
学習済みのモデルに自社のデータで追加学習を行い、特定の用途に合わせる手法です。知識を足す用途には向かない点に注意が要ります。
AI・開発トレンド
プロンプトエンジニアリング
（ぷろんぷとえんじにありんぐ／Prompt Engineering）
モデルへの指示文を設計して、望む出力を安定して得られるようにする作業です。モデルを変えずに精度を上げられる最初の手段になります。
AI・開発トレンド
マルチモーダル
（まるちもーだる／Multimodal）
文章に加えて画像・音声・動画などを同じモデルで扱えることを指します。書類や画面をそのまま読ませたい用途で使われています。
AI・開発トレンド
RAG
（らぐ／Retrieval-Augmented Generation）
質問に関係する文書を検索し、その内容を根拠として渡したうえで生成させる方式です。社内文書を扱う仕組みの標準的な構成になっています。
技術・開発
AWS
（えーだぶりゅーえす／Amazon Web Services）
Amazonが提供するクラウド基盤です。求人票での登場頻度は最も高い部類ですが、対象を絞る力のほうは最も弱い語になります。
技術・開発
可観測性
（かかんそくせい／Observability）
内部の状態を外から説明できる度合いを指す語です。候補者を探すときには製品の名前を使い、この語は環境を伝えるために書きます。
技術・開発
技術的負債
（ぎじゅつてきふさい／Technical Debt）
設計上の妥協が積み上がった状態を指す言葉です。求人票では、返す対象とそこに割ける時間まで書けているかで反応が変わります。
技術・開発
Kubernetes
（くーばねてぃす）
多数のコンテナを配置し、動かし続けるための基盤です。クラウドが管理する形か自前構築かで、求められるものが大きく変わります。
技術・開発
GraphQL
（ぐらふきゅーえる）
取得するデータの形を利用する側が決める仕組みです。該当者が採用実績のある企業に偏るため、必須要件にすると対象が消えます。
技術・開発
Go
（ごー）
Googleが作ったサーバ向けの言語です。求人票に書けば候補者を絞り込めますが、該当者の数はJavaやPythonには及びません。
技術・開発
Kotlin
（ことりん）
Javaと同じ環境で動く言語です。Androidの募集では前提として書かれ、サーバ側ならJava経験者まで対象に含めるのが現実的です。
技術・開発
Java
（じゃば）
1995年から使われている汎用の言語です。該当者の数では中途市場の最大級ですが、数を集めることと採用できることは別です。
技術・開発
Swift
（すうぃふと）
Apple製品向けのアプリを作る言語です。iOSの募集では前提として書かれ、画面の作り方の世代差を明記すると判断が早まります。
技術・開発
TypeScript
（たいぷすくりぷと）
型を書くことで動かす前に誤りを見つけられるようにしたJavaScriptの拡張です。書ける人が多く、要件に加えても対象は狭まりません。
技術・開発
Terraform
（てらふぉーむ）
インフラの構成をコードとして扱うための道具です。触ったことがあるかではなく、どこまで任されていたかを確かめる必要があります。
技術・開発
Docker
（どっかー）
アプリと動作環境をまとめて運ぶ仕組みです。扱ったことのない人を探すほうが難しく、要件に加えても対象はほとんど狭まりません。
技術・開発
Next.js
（ねくすとじぇーえす）
Reactの上に載るWebの枠組みです。Reactより該当者を絞り込めますが、版ごとに前提が入れ替わり、年数では判断できません。
技術・開発
Node.js
（のーどじぇーえす）
サーバでJavaScriptを動かす環境です。画面側の担当者も日常的に触れるため、経験ありと答えられる人の幅が広くなります。
技術・開発
Python
（ぱいそん）
読みやすさを重んじた汎用の言語です。同じ語で呼ばれている仕事が3つの領域に分かれ、明記しないと違う層から応募が届きます。
技術・開発
マイクロサービス
（まいくろさーびす／Microservices）
小さなサービスに分けて作る構成です。候補者を探すための語ではなく、任される範囲と変更を出す頻度を伝えるための語になります。
技術・開発
モノリス
（ものりす／Monolith）
配信の単位を分けずに作る構成です。求人票での扱いを誤ると、その環境で働いてきた層が離れ、母集団をみずから削ってしまいます。
技術・開発
Rust
（らすと）
メモリ由来の不具合をコンパイル時に止める言語です。必須要件に置くと該当者がほとんど残らず、提示条件の見直しも必要になります。
技術・開発
React
（りあくと）
Webの画面を組み立てるライブラリです。書いたことのない経験者を探すほうが難しく、要件に加えても対象はほとんど狭まりません。
技術・開発
Ruby on Rails
（るびーおんれいるず）
Ruby向けのWeb開発の枠組みです。募集の中心は動いているサービスを引き継ぐ役割で、今後の方針の記載が応募する層を左右します。
開発プロセス・方法論
アジャイル
（あじゃいる／Agile）
計画を固定せず、短い区切りごとに作り直す前提で進める開発の考え方です。同じ語で呼ばれていても、現場の実態は組織ごとに大きく違います。
開発プロセス・方法論
IaC
（いんふらすとらくちゃあずこーど／Infrastructure as Code）
サーバやネットワークの構成を記述に置き換え、変更をレビューできるようにする実践です。同じ定義から同じ環境を作れる状態を目指します。
開発プロセス・方法論
ウォーターフォール
（うぉーたーふぉーる／Waterfall Model）
工程を順に固定して進め、前には戻らない前提で計画を組む開発の進め方です。受託や業務システムの出身者の経歴書に頻出します。
開発プロセス・方法論
AI駆動開発
（えーあいくどうかいはつ／AI-Driven Development）
人が書きAIが補助する形から、AIが書き人が検証する形へ反転させた開発の総称です。実装より、仕様の言語化と検証に時間が移ります。
開発プロセス・方法論
AI-DLC
（えーあいでぃーえるしー／AI-Driven Development Life Cycle）
人の手作業を前提に組まれた開発工程そのものを、AIの働き方に合わせて組み替える方法論です。AWSが2025年に公開しました。
開発プロセス・方法論
SLO・エラーバジェット
（えすえるおー・えらーばじぇっと／SLO / Error Budget）
信頼性の目標と、その未達の許容枠をあらかじめ合意しておく仕組みです。障害のたびに力関係で優先順位が決まる状態を避けられます。
開発プロセス・方法論
カンバン
（かんばん／Kanban）
板の上で作業の流れを可視化し、同時進行の上限を決めて滞留を防ぐ手法です。運用や保守のように依頼が随時発生する仕事で選ばれます。
開発プロセス・方法論
コードレビュー
（こーどれびゅー／Code Review）
実装を別の開発者が読み、欠陥の検出と設計判断の確認を行う工程です。実施しているかどうかではなく、基準と承認の条件まで示せるかで差が出ます。
開発プロセス・方法論
CI/CD
（しーあいしーでぃー）
分岐した作業を毎日のように統合し、いつでも出せる状態を保ち続ける仕組みです。自動テストとビルドの自動化が前提になります。
開発プロセス・方法論
シフトレフト
（しふとれふと／Shift-Left Testing）
後の工程ほど修正の費用が大きくなるため、検査を前方へ動かす考え方です。テストの量ではなく、置く位置を変える話になります。
開発プロセス・方法論
仕様駆動開発
（しようくどうかいはつ／Spec-Driven Development）
コードではなく仕様を正本に置き、変更は仕様側から入れて再生成する進め方です。生成の入力を安定させることが狙いになります。
開発プロセス・方法論
スクラム
（すくらむ／Scrum）
誰が何に責任を持ち、いつ何を確認するかだけを定めた開発の枠組みです。具体的なやり方はチームに委ねられ、正本のガイドは意図的に薄く書かれています。
開発プロセス・方法論
Team Topologies
（ちーむとぽろじーず）
チームの型を4つ、チーム同士の関わり方を3つに絞って調整の経路を設計する枠組みです。近年の職種名を読み解く下敷きになります。
開発プロセス・方法論
テスト駆動開発
（てすとくどうかいはつ／Test-Driven Development）
テストを先に書くことで、何ができれば正しいのかを実装前に決める手順です。テストしやすい形を先に考えるため、設計にも影響します。
開発プロセス・方法論
DevOps
（でぶおぷす）
変更を出したい開発と、安定させたい運用の対立を、工程と分担の設計で解く取り組みです。自動化はその手段のひとつにあたります。
開発プロセス・方法論
トランクベース開発
（とらんくべーすかいはつ／Trunk-Based Development）
分岐の寿命を1日から数日に抑え、統合の衝突が育つ前に解消してしまうブランチ戦略です。GitFlowとの対比で語られます。
開発プロセス・方法論
Product Led Growth
（ぷろだくとれっどぐろーす／プロダクトレッドグロース）
営業ではなくプロダクト自身に顧客の獲得と定着を担わせる成長モデル。無料で使い始められる入口と、課金までの経路を製品側に組み込みます。
開発プロセス・方法論
ペアプログラミング
（ぺあぷろぐらみんぐ／Pair Programming）
書いている最中に判断を共有することで、設計のやり直しと知識の偏りを同時に防ぐ手法です。常時行うものではなく、場面を選んで使います。
採用実務
RPO
（あーるぴーおー／Recruitment Process Outsourcing）
採用業務の一部または全体を外部に委託する形態です。人材を紹介してもらうのではなく、採用の実務そのものを担ってもらいます。
採用実務
AI-RPO
（えーあいあーるぴーおー／AI-driven RPO）
採用代行の実務に生成AIを組み込み、候補者の選別や文面作成を自動化する形態です。判断の最終責任は人が持つ前提で運用します。
採用実務
ATS
（えーてぃーえす／Applicant Tracking System）
応募者の情報と選考の進み具合を一元管理するシステムです。経路の違う候補者を同じ台帳の上で扱えるようにし、重複した接触を防ぎます。
採用実務
オファー面談
（おふぁーめんだん／Offer Meeting）
内定を出した候補者に条件と期待する役割を伝え、意思決定を支える場です。合否の判定は終わっており、口説く段階にあたります。
採用実務
カジュアル面談
（かじゅあるめんだん／Casual Interview）
合否を判定しない前提で、企業と候補者が相互に情報を交換する場です。転職をまだ決めていない層と接点を持つために置かれます。
採用実務
技術・人文知識・国際業務
（ぎじゅつ・じんぶんちしき・こくさいぎょうむ／Engineer / Specialist in Humanities / International Services）
外国籍のエンジニアを雇用する際に多く用いられる在留資格です。従事する業務と本人の学歴や実務経験が対応している必要があります。
採用実務
求人媒体
（きゅうじんばいたい／Job Board）
求人を掲載し、候補者と接点を持つためのサービスです。応募を集める型と、企業から候補者に接触する型で運用の仕方が変わります。
採用実務
構造化面接
（こうぞうかめんせつ／Structured Interview）
質問項目と評価基準をあらかじめ決め、全候補者に同じ手順で行う面接です。面接官による判断のばらつきを抑えるために使います。
採用実務
候補者体験
（こうほしゃたいけん／Candidate Experience）
候補者が最初の接触から入社または見送りまでに受け取る体験の総称です。選考の結果によらず、企業の評判として長く残り続けます。
採用実務
コーディングテスト
（こーでぃんぐてすと／Coding Test）
候補者に実際にコードを書いてもらい、技術力を確認する選考手法です。面接での自己申告と実際の力の差を埋めるために使います。
採用実務
採用KPI
（さいようけーぴーあいー／Recruiting KPI）
採用活動の進み具合を測るために置く指標です。採用数などの結果指標と、接触数のように行動で動かせる指標を分けて設計します。
採用実務
採用広報
（さいようこうほう／Recruitment PR）
働く環境や技術的な取り組みを社外に発信する活動です。社名で検索した候補者が判断材料を得られるかどうかが、スカウトや応募の反応に表れます。
採用実務
採用ファネル
（さいようふぁねる／Recruiting Funnel）
接触から入社までの各段階と、段階ごとの通過率を並べて見る枠組みです。どこで候補者が減っているのかを特定するために使います。
採用実務
採用ブランディング
（さいようぶらんでぃんぐ／Employer Branding）
働く場所として選ばれる状態を意図して作る取り組みです。発信だけでなく、実際の働き方や処遇と揃っていることが前提になります。
採用実務
採用要件定義
（さいようようけんていぎ／Hiring Requirements Definition）
どんな人を採るのかを、経験と能力の水準まで具体化して社内で合意する工程です。採用活動の成否をほぼ決める上流工程にあたります。
採用実務
ジョブ型雇用
（じょぶがたこよう／Job-based Employment）
職務の内容を先に定め、それに対して人を採用し処遇するという考え方です。人に仕事を割り当てる従来の運用と対比して語られます。
採用実務
ジョブディスクリプション
（じょぶでぃすくりぷしょん／Job Description）
任せる職務と期待する成果、必要な経験を記述した文書です。候補者の応募判断と、選考に関わる社内の判断基準の両方を支えます。
採用実務
人材紹介
（じんざいしょうかい／Recruitment Agency）
紹介会社が候補者を推薦し、入社に至った場合に手数料が発生する採用経路です。厚生労働大臣の許可を受けた事業者だけが行えます。
採用実務
スカウト
（すかうと／Scout Message）
企業から候補者へ個別に送る接触メッセージです。誰に送るかを決める検索条件と、届いた後に読まれる求人票と一体で機能します。
採用実務
スカウト返信率
（すかうとへんしんりつ／Scout Reply Rate）
送ったスカウトのうち返信が返ってきた割合です。改善余地を測る指標であると同時に、企業側の条件がそのまま出る数字でもあります。
採用実務
ダイレクトリクルーティング
（だいれくとりくるーてぃんぐ／Direct Recruiting）
企業が候補者を自ら探して直接声をかける採用手法です。応募を待つのではなく、採用したい人を特定して接触するところに違いがあります。
採用実務
タレントプール
（たれんとぷーる／Talent Pool）
将来の採用候補になる人を蓄積しておく名簿です。今回は縁がなかった人と接点を保ち、次の募集で最初に声をかける相手にします。
採用実務
内定承諾率
（ないていしょうだくりつ／Offer Acceptance Rate）
内定を出した人のうち入社を承諾した割合です。選考の最終段階を示す指標で、下がったときは提示条件と伝え方の両方を点検します。
採用実務
年収レンジ設計
（ねんしゅうれんじせっけい／Salary Range Design）
募集ポジションに提示する年収の幅と、その幅がどの経験水準に対応するかを決める設計です。既存社員の処遇との整合も含みます。
採用実務
ペルソナ設計
（ぺるそなせっけい／Candidate Persona Design）
採用したい候補者を、経歴や志向を持つ具体的な人物として描く手法です。要件を候補者の目線に翻訳し、検索条件と訴求内容に落とし込むために使います。
採用実務
母集団形成
（ぼしゅうだんけいせい／Candidate Pool Building）
選考の対象になる候補者を、必要な人数と質で確保する活動です。採用が計画どおりに進まない原因の多くは、この最上流の段階に残っています。
採用実務
リファラル採用
（りふぁらるさいよう／Referral Hiring）
社員の紹介を通じて候補者と接点を持つ採用手法です。定着しやすい一方で、勧められる組織の状態がないと件数は積み上がりません。
採用実務
労働条件明示
（ろうどうじょうけんめいじ／Working Conditions Disclosure）
募集の段階と契約の締結時に、業務内容や賃金などの労働条件を示す法令上の義務です。求人票をどう書くかにも直接関わってきます。