採用用語集
エンジニア採用の現場で出てくる用語を、いつどこで生まれた言葉なのか、 求人票やレジュメで見たときに何を確認すればよいのかまで含めて解説します。
用語を探す
全276語
職種・体制
ITコンサルタント
（あいてぃーこんさるたんと／ITコンサル／IT Consultant）
顧客企業の経営や業務の課題を整理し、IT戦略やシステム導入、業務改革を支援する職種。担当の範囲は構想の策定から実行支援まで幅があります。
職種・体制
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）
サービスの信頼性をソフトウェアエンジニアリングで担保する職種。可用性の目標を数値で決め、運用作業をコードで自動化し、開発と運用の境界をなくしていきます。
職種・体制
SIerのSE
（えすあいやーのえすいー／SIerのシステムエンジニア）
受託開発を担う企業で、要件定義から設計、テストまでを担当する職種。自社プロダクトの開発とは、意思決定の範囲と関わる期間が異なります。
職種・体制
SET
（えすいーてぃー／Software Engineer in Test）
テストを速く確実に回すための基盤とツールを開発する職種。自分がテストを実行するのではなく、開発者がテストを書いて回すための仕組みを作ります。
職種・体制
MLOpsエンジニア
（えむえるおぷすえんじにあ／MLOps Engineer）
機械学習を継続して回すための基盤とパイプラインを整える職種。モデルを作る人が実験から本番投入までを繰り返せる状態を保ちます。
職種・体制
Engineering Manager
（えんじにありんぐまねーじゃー／エンジニアリングマネージャー）
開発チームの成果と、メンバーの成長・評価に責任を持つ職種。技術がわかる前提で、人と組織を動かして継続的に成果を出します。
職種・体制
Embedded QA
（えんべでっどきゅーえー／エンベデッドQA）
開発チームの一員として日々の開発に入るQA。独立したQA部門でリリース前を待つのではなく、同じチームで計画段階から品質を確認していきます。
職種・体制
Offensive Security Engineer
（おふぇんしぶせきゅりてぃえんじにあ／オフェンシブセキュリティエンジニア）
攻撃者の視点でシステムへの侵入を試み、実際に破れる経路とその影響を実証する職種。診断結果の一覧ではなく到達した事実を報告します。
職種・体制
カスタマーサクセスエンジニア
（かすたまーさくせすえんじにあ／Customer Success Engineer）
導入後の顧客に対し、技術面から製品の活用を支援する職種。設定の支援や連携の実装、技術的な課題の解決を担い、担当の範囲は企業で異なります。
職種・体制
機械学習エンジニア
（きかいがくしゅうえんじにあ／Machine Learning Engineer）
機械学習モデルを作り本番で動かし続ける職種。精度を上げるだけでなくデータの供給と再学習まで含めた仕組みに責任を持ちます。
職種・体制
QA Architect
（きゅーえーあーきてくと／QAアーキテクト）
組織全体の品質の担保の仕方を設計する上位職。個別のテストではなく、どこで何を担保するかという構造を決めて標準として各チームへ配ります。
職種・体制
QAエンジニア
（きゅーえーえんじにあ／QA Engineer）
プロダクトの品質を担保する職種。テスト設計と実施だけでなく、要件段階から品質のリスクを見つけて開発プロセスに手を入れます。
職種・体制
共通基盤エンジニア
（きょうつうきばんえんじにあ）
社内の複数サービスが共用する認証や決済などの基盤を開発し運用する職種。個別プロダクトではなく全社で重複する仕組みを担当します。
職種・体制
組み込みエンジニア
（くみこみえんじにあ／Embedded Engineer）
機器に内蔵されるソフトウェアを開発する職種。限られた資源と実時間の制約のもとで、ハードウェアを直接制御する設計を担当します。
職種・体制
Corporate Security Engineer
（こーぽれーとせきゅりてぃえんじにあ／コーポレートセキュリティエンジニア）
従業員が使う端末・ネットワーク・SaaSの安全性に責任を持つ職種。全社の業務を止めずに情報資産を守る設計と運用を担当します。
職種・体制
CRO
（しーあーるおー／最高収益責任者／Chief Revenue Officer）
収益に関わる複数部門を横断して統括する経営層の役職。営業・マーケティング・カスタマーサクセスなどを一人の責任者の下に置き、売上の計画と実績を担います。
職種・体制
CISO
（しーあいえすおー／最高情報セキュリティ責任者／Chief Information Security Officer）
情報セキュリティの戦略と管理体制を統括する責任者。リスク管理、規程の整備、監査、事故対応を担い、権限の範囲は組織によって異なります。
職種・体制
CIO
（しーあいおー／最高情報責任者／Chief Information Officer）
企業の情報戦略、社内IT、データ活用を統括する責任者。CTOとの担当範囲は企業によって異なり、明確に分かれない場合もあります。
職種・体制
CSO
（しーえすおー／Chief Sales Officer）
営業組織全体の戦略と実行を統括する経営層の役職。売上目標の設計、営業プロセスの標準化、営業組織の採用と育成を担当します。
職種・体制
CMO
（しーえむおー／Chief Marketing Officer）
全社のマーケティングに責任を持つ経営層の役職。ブランド、広告、市場調査、マーケティング技術と、それらに充てる予算の配分を担当します。
職種・体制
CSIRT担当
（しーさーとたんとう／CSIRT）
インシデントが起きた後の対応を統括する役割。技術的な封じ込めに加えて、経営や監督官庁への報告と再発防止までを担当します。
職種・体制
CTO
（しーてぃーおー／Chief Technology Officer）
技術面で経営判断に責任を持つ役割。事業の方向に対して、どの技術にどう投資するかを決め、その判断を経営と社外に説明します。
職種・体制
CPO
（しーぴーおー／最高プロダクト責任者／Chief Product Officer）
全社のプロダクト戦略に責任を持つ経営層の役職。何を作るかの方向を定め、経営会議の一員としてプロダクトへの投資配分に関わります。
職種・体制
事業開発
（じぎょうかいはつ／BizDev／Business Development）
既存の営業では届かない売上のつくり方を、提携や新規事業として形にする職種。相手を探す段階から契約と立ち上げまでを担当します。
職種・体制
事業責任者
（じぎょうせきにんしゃ／Business Unit Head）
担当する事業の損益に責任を持つ職種。売上と費用の両方を動かす権限を持ち、プロダクト・営業・採用の配分をまとめて決めます。
職種・体制
社内SE
（しゃないえすいー／社内システムエンジニア）
自社の業務システムやIT環境の企画・導入・運用を担当する職種。外部提供のプロダクトではなく、従業員が日常的に使う仕組みを対象にします。
職種・体制
情報システム部門
（じょうほうしすてむぶもん／情シス）
社内のIT環境と業務システムを統括する部門。端末や権限の管理から基幹システムの導入まで、従業員の業務基盤を対象にします。
職種・体制
スクラムマスター
（すくらむますたー／Scrum Master）
スクラムがチームで機能している状態に責任を持つ役割。進捗を管理するのではなく、進行を妨げている要因のほうを取り除きます。
職種・体制
Staff Engineer
（すたっふえんじにあ／スタッフエンジニア）
管理職に進まずに影響範囲を広げる上位のエンジニア職。1つのチームでは解けない技術課題を見つけ、関係者を巻き込んで解決まで持っていきます。
職種・体制
セキュリティエンジニア
（せきゅりてぃえんじにあ／Security Engineer）
情報資産を攻撃から守る職種の総称。守る対象がプロダクトか社内環境かで必要な経験が分かれるため、求人票では範囲の明示が必要です。
職種・体制
SOCアナリスト
（そっくあなりすと／SOC Analyst）
ログとアラートを常時監視し、攻撃の兆候を見つけて一次対応まで担当する職種。大量の警告のなかから対応すべきものを選び分けます。
職種・体制
ソフトウェアアーキテクト
（そふとうぇああーきてくと／Software Architect）
システム全体の構造を設計する職種。後から変えにくい判断を担当し、その理由を文書に残したうえで各開発チームへ引き渡します。
職種・体制
ソリューションアーキテクト
（そりゅーしょんあーきてくと／Solutions Architect）
顧客の課題に対して技術構成を設計して提案する職種。商談の場で実現方法を示し、受注が決まった後の立ち上がりまで技術面で支援します。
職種・体制
Chief Scientific Officer
（ちーふさいえんてぃふぃっくおふぃさー／最高科学責任者）
研究開発の方向と科学的な判断に責任を持つ経営層の役職。創薬や素材など研究が事業の中心にある企業で置かれ、研究テーマの選択と研究組織を統括します。CSOと略されます。
職種・体制
Chief Sustainability Officer
（ちーふさすてなびりてぃおふぃさー／最高サステナビリティ責任者／CSuO）
環境・社会に関する目標と取り組みを全社で統括する経営層の役職。脱炭素、人権、情報開示の方針を決め、事業部門の計画に組み込みます。CSOやCSuOと略されます。
職種・体制
Chief Strategy Officer
（ちーふすとらてじーおふぃさー／最高戦略責任者）
全社の戦略の策定と実行の推進に責任を持つ経営層の役職。中期経営計画、事業ポートフォリオ、M&Aや提携の判断を担当します。CSOと略されます。
職種・体制
Chief Security Officer
（ちーふせきゅりてぃおふぃさー／最高セキュリティ責任者）
情報セキュリティに加えて、物理的な安全や危機管理まで含めた会社全体の安全に責任を持つ経営層の役職。CSOと略され、CISOと役割が重なることがあります。
職種・体制
DoP
（でぃーおーぴー／Director of Product）
複数のプロダクトマネージャーを預かる管理職。担当領域のプロダクト戦略を定め、配下のプロダクトマネージャーを一人前に育てる責任を負います。
職種・体制
データエンジニア
（でーたえんじにあ／Data Engineer）
分析や機械学習に使うデータを集めて整えて届ける職種。使う側が信用できるデータが揃っている状態を保つところまで担当します。
職種・体制
データサイエンティスト
（でーたさいえんてぃすと／Data Scientist）
データの分析から事業の意思決定を支える職種。統計と機械学習を使い、数字を出すだけでなく何をどう判断すべきかまで示します。
職種・体制
データベースエンジニア
（でーたべーすえんじにあ／Database Engineer）
データベースの設計と運用に責任を持つ職種。性能・可用性・データの保全を担保し、壊れない状態を保ち続けるところまで担当します。
職種・体制
テクニカルサポート
（てくにかるさぽーと／テクニカルサポートエンジニア／Technical Support）
製品やサービスの利用者から技術的な問い合わせを受け、原因の調査と解決方法の案内を担う職種。専門部署へ引き継ぐ範囲は企業によって異なります。
職種・体制
Technical Product Manager
（てくにかるぷろだくとまねーじゃー／テクニカルプロダクトマネージャー）
API・データ基盤・開発者向け機能など技術寄りの領域を担当するプロダクトマネージャー。利用者が開発者である点が通常の職務と異なります。
職種・体制
テクニカルライター
（てくにかるらいたー／Technical Writer）
仕様書やAPIリファレンス、利用者向けマニュアルを作成する職種。製品の理解と、読み手に応じた構成の設計を両方求められます。
職種・体制
デザインエンジニア
（でざいんえんじにあ／Design Engineer）
デザインと実装の両方を担い、意図どおりの画面をコードで実現する職種。デザインシステムの構築と運用を任される例が多く見られます。
職種・体制
テックリード
（てっくりーど／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）
開発組織全体の運営に責任を持つ役割。採用・育成・評価・体制づくりを通じて、事業計画が求める開発力を必要な時期までに用意します。
職種・体制
VPoT
（ぶいぴーおーてぃー／VP of Technology）
技術の意思決定に責任を持つ役割。CTOが定めた方向を、技術選定・アーキテクチャ・品質基準という具体の判断へ落とし、実装の現場まで通します。
職種・体制
VPoP
（ぶいぴーおーぴー／VP of Product）
プロダクト組織全体の運営に責任を持つ役割。プロダクトマネージャーの体制を預かり、会社によってはデザイナーも含めて、事業計画に対する成果を揃えます。
職種・体制
VP of Customer Success
（ぶいぴーおぶかすたまーさくせす／Vice President of Customer Success）
導入後の顧客を支える組織を統括する役職。継続の利用や顧客の成果、組織の運営を担いますが、責任の範囲は企業の事業モデルによって異なります。
職種・体制
VP of Sales
（ぶいぴーおぶせーるす／Vice President of Sales）
営業組織の戦略と実行を統括する役職。売上目標、組織設計、営業プロセスを担い、CROとの上下関係や責任の分担は企業によって異なります。
職種・体制
VP of Marketing
（ぶいぴーおぶまーけてぃんぐ／Vice President of Marketing）
マーケティング組織の戦略と実行を統括する役職。市場の選定、需要の創出、ブランドを担い、CMOとの上下関係は企業によって異なります。
職種・体制
Forward Deployed Engineer
（ふぉわーどでぷろいどえんじにあ）
顧客の現場に入り込んで自社プロダクトを業務に合わせて仕上げるエンジニア。多数の顧客向けの汎用機能ではなく一社の課題解決を担当します。
職種・体制
Platform Engineer
（ぷらっとふぉーむえんじにあ）
開発者が自分で使える社内プラットフォームを製品として作り運用する職種。環境構築やデプロイの手数を減らし開発の速度を上げることに責任を持ちます。
職種・体制
ブリッジSE
（ぶりっじえすいー／ブリッジエンジニア／Bridge SE）
国内の発注側と海外の開発拠点をつなぎ、仕様の翻訳と品質の調整を担う職種。言語の違いに加えて、開発の進め方や品質の基準の違いを調整する役割を担います。
職種・体制
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開発にはない条件のもとで開発を進めます。
職種・体制
UIデザイナー
（ゆーあいでざいなー／UI Designer）
画面の視覚表現や操作要素を設計する職種。情報設計やデザインシステムの整備も担い、UXデザイナーとの分担は組織によって異なります。
職種・体制
UXデザイナー
（ゆーえっくすでざいなー／UX Designer）
利用者の行動や課題を調査し、製品を通じた体験を設計する職種。調査を専門とするUXリサーチャーとは役割が重なる場合がありますが、同義ではありません。
職種・体制
RevOps
（れぶおぷす／Revenue Operations）
営業・マーケティング・カスタマーサクセスの業務基盤を横断で整える職種。データ、業務プロセス、ツール、指標の定義を一本化して収益部門を支えます。
AI・開発トレンド
evals
（いーばる／イーバル／Evaluations）
生成AIの出力の品質を、決めた基準で継続的に測る仕組みです。出力が毎回揺れる前提の開発では、テストにあたる役割を担います。
AI・開発トレンド
埋め込み・ベクトル検索
（うめこみ、べくとるけんさく／Embeddings / Vector Search）
文章を数値の並びに変換し、意味の近さで検索できるようにする技術です。語が一致しなくても、内容の近い文書を見つけられます。
AI・開発トレンド
AIエージェント
（えーあいえーじぇんと／AI Agent）
目的を渡すと、手順を自分で決めて道具を使いながら進めるAIの仕組みです。1回の応答で完結しない作業を任せる形になります。
AI・開発トレンド
AIガバナンス
（えーあいがばなんす／AI Governance）
AIを使う範囲と責任の所在を、組織として決めて運用する枠組みです。何を渡してよいか、誰が判断するかを先に定めておきます。
AI・開発トレンド
AI関数
（えーあいかんすう／AI Function）
スプレッドシートのセルに数式として書き、指示文と参照するセルを渡して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・開発トレンド
OpenClaw
（おーぷんくろー）
自分のPCやサーバーで動かし、SlackやTelegramなどのチャットから仕事を頼めるオープンソースのAIエージェントです。メールや予定表と連携し、作業を自分で進めます。
AI・開発トレンド
Obsidian
（おぶしでぃあん）
メモを手元のフォルダにMarkdownのファイルとして保存するノートアプリです。フォルダへのアクセスを許可すればAIエージェントからも読み書きでき、知識の置き場として利用できます。
AI・開発トレンド
Cursor
（かーそる）
AI機能を組み込んだコードエディタです。補完に加えて、指示を出すと複数のファイルにまたがる修正まで進めることができます。
AI・開発トレンド
GitHub Copilot
（ぎっとはぶこぱいろっと）
GitHubが提供するコード支援サービスです。補完から始まり、現在はレビューやエージェント的な機能まで範囲が広がっています。
AI・開発トレンド
Claude Code
（くろーどこーど）
Anthropicが提供するAIエージェントです。コードの修正とテストに加え、アプリの画面操作や資料・動画の作成まで、PCで行う作業の多くを任せることができます。
AI・開発トレンド
Grok
（ぐろっく）
イーロン・マスク氏が設立したxAIが開発する対話型AIとAIモデルのシリーズです。SNSのXに組み込まれており、Xのアプリや専用アプリから使うことができます。
AI・開発トレンド
Codex
（こーでっくす／OpenAI Codex）
OpenAIが提供するAIエージェントです。コードの修正とテストに加え、アプリの画面操作や資料・動画の作成まで、PCで行う作業の多くを任せることができます。
AI・開発トレンド
コンテキスト
（こんてきすと／Context）
AIが答えを作るときに参照している情報の全体です。指示文、それまでの会話、添付した資料、ツールの実行結果までを含みます。
AI・開発トレンド
コンテキストウィンドウ
（こんてきすとうぃんどう／Context Window）
モデルが一度に読み書きできるトークン数の上限です。ここに収まらない情報はモデルに届かないため、設計上の制約として働きます。
AI・開発トレンド
Gems
（じぇむず／Gem）
Googleの生成AIであるGeminiで、指示文と参考資料を保存して繰り返し使えるようにする機能です。2027年に、後継となるGeminiのスキルへ置き換わる予定です。
AI・開発トレンド
実験管理
（じっけんかんり／Experiment Tracking）
モデルの学習や評価の条件と結果を記録し、後から比較できるようにする仕組み。データ、コード、パラメータ、評価指標を一組で残し、再現しやすくします。
AI・開発トレンド
推論コスト
（すいろんこすと／Inference Cost）
学習済みモデルに処理させるたびに発生する計算資源と費用。APIを使う場合は入力と出力のトークン量で料金が決まり、扱う文書の量と応答の長さが金額を左右します。
AI・開発トレンド
推論モデル
（すいろんもでる／Reasoning Model）
答える前に内部で考える手順を踏むモデルです。難しい問題の正答率が上がる反面、応答時間と費用が増えるため使い分けが要ります。
AI・開発トレンド
スキル
（すきる／エージェントスキル／Agent Skills）
作業の手順と資料をフォルダにまとめて保存し、AIが必要なときに読み込んで使う仕組みです。Claude Code、Codex、Geminiなどで同じ形式を使うことができます。
AI・開発トレンド
生成AI
（せいせいえーあい／Generative AI）
文章・画像・音声・コードなどを新しく作り出すAIの総称。分類や予測を行う従来のAIと違い、成果物そのものを出力する点が特徴です。
AI・開発トレンド
トークン
（とーくん／Token）
言語モデルが文章を扱うときの最小単位です。料金も処理量もこの単位で計算されるため、費用と制限を見積もる話には必ず出てきます。
AI・開発トレンド
トークンマネジメント
（とーくんまねじめんと／Token Management）
モデルに渡す情報量を設計し、費用と精度の釣り合いを取る取り組み。不要な文脈を落とし、必要な情報だけを残す判断が中心になります。
AI・開発トレンド
dots
（どっつ／OpenAI dots）
OpenAIが2026年に発表した、常に動き続けるAIエージェントです。ChatGPTやCodexから起動し、SlackやTeamsで頼んだ仕事を、人が席を外している間も進めます。
AI・開発トレンド
ハーネス
（はーねす／エージェントハーネス／Agent Harness）
AIのモデルに、ファイルの読み書きやツールの呼び出し、確認の手順を組み合わせて動かす仕組みです。同じモデルでも、作業を最後まで終えられるかはハーネスの作りに左右されます。
AI・開発トレンド
ハルシネーション
（はるしねーしょん／Hallucination）
モデルが事実でない内容をもっともらしく出力する現象です。仕様上ゼロにはできないため、検知と確認の工程を設計に組み込みます。
AI・開発トレンド
ファインチューニング
（ふぁいんちゅーにんぐ／Fine-tuning）
学習済みのモデルに自社のデータで追加学習を行い、特定の用途に合わせる手法です。知識を足す用途には向かない点に注意が要ります。
AI・開発トレンド
プロンプトエンジニアリング
（ぷろんぷとえんじにありんぐ／Prompt Engineering）
モデルへの指示文を設計して、望む出力を安定して得られるようにする作業です。モデルを変えずに精度を上げられる最初の手段になります。
AI・開発トレンド
Hermes Agent
（へるめすえーじぇんと）
Nous Researchが開発するオープンソースのAIエージェントです。会話の記憶と作業の手順（スキル）を蓄えて再利用し、SlackやTelegramなどのチャットから仕事を頼めます。
AI・開発トレンド
マルチモーダル
（まるちもーだる／Multimodal）
文章に加えて画像・音声・動画などを同じモデルで扱えることを指します。書類や画面をそのまま読ませたい用途で使われています。
AI・開発トレンド
RAG
（らぐ／Retrieval-Augmented Generation）
質問に関係する文書を検索し、その内容を根拠として渡したうえで生成させる方式です。社内文書を扱う仕組みの標準的な構成になっています。
技術・開発
AWS
（えーだぶりゅーえす／Amazon Web Services）
Amazonが提供するクラウド基盤です。求人票での登場頻度は最も高い部類ですが、対象を絞る力のほうは最も弱い語になります。
技術・開発
API設計
（えーぴーあいせっけい／API Design）
システム間で機能やデータをやり取りするための取り決めを設計する作業。操作の単位、入出力、エラーの返し方、互換性の保ち方を決めます。
技術・開発
可観測性
（かかんそくせい／Observability）
内部の状態を外から説明できる度合いを指す語です。候補者を探すときには製品の名前を使い、この語は環境を伝えるために書きます。
技術・開発
技術的負債
（ぎじゅつてきふさい／Technical Debt）
設計上の妥協が積み上がった状態を指す言葉です。求人票では、返す対象とそこに割ける時間まで書けているかで反応が変わります。
技術・開発
Kubernetes
（くーばねてぃす）
多数のコンテナを配置し、動かし続けるための基盤です。クラウドが管理する形か自前構築かで、求められるものが大きく変わります。
技術・開発
GraphQL
（ぐらふきゅーえる）
取得するデータの形を利用する側が決める仕組みです。該当者が採用実績のある企業に偏るため、必須要件にすると対象が消えます。
技術・開発
クレデンシャル
（くれでんしゃる／認証情報／Credential）
利用者やプログラムが正当な相手であることを確かめ、システムにアクセスするために使う情報の総称。パスワード、APIキー、アクセストークン、証明書などを含みます。
技術・開発
Go
（ごー）
Googleが作ったサーバ向けの言語です。求人票に書けば候補者を絞り込めますが、該当者の数はJavaやPythonには及びません。
技術・開発
Kotlin
（ことりん）
Javaと同じ環境で動く言語です。Androidの募集では前提として書かれ、サーバ側ならJava経験者まで対象に含めるのが現実的です。
技術・開発
Java
（じゃば）
1995年から使われている汎用の言語です。該当者の数では中途市場の最大級ですが、数を集めることと採用できることは別です。
技術・開発
Swift
（すうぃふと）
Apple製品向けのアプリを作る言語です。iOSの募集では前提として書かれ、画面の作り方の世代差を明記すると判断が早まります。
技術・開発
脆弱性診断
（ぜいじゃくせいしんだん／Vulnerability Assessment）
定めた範囲の脆弱性を体系的に検出して評価する作業。侵入できるかどうかを実証するペネトレーションテストとは、目的と進め方が異なります。
技術・開発
ゼロトラスト
（ぜろとらすと／Zero Trust）
ネットワーク上の位置だけを根拠に信頼せず、利用者・端末・対象資源の状況をアクセスのたびに検証する考え方。境界の内側も安全とみなしません。
技術・開発
ソフトウェアアーキテクチャ
（そふとうぇああーきてくちゃ／Software Architecture）
システムの主要な構成要素とその関係、設計上の原則や重要な判断のこと。性能・保守性・可用性などの要件と運用条件を踏まえて決めます。
技術・開発
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）
計画を固定せず、短い区切りごとに作り直す前提で進める開発の考え方です。同じ語で呼ばれていても、現場の実態は組織ごとに大きく違います。
開発プロセス・方法論
インシデント対応
（いんしでんとたいおう／Incident Response）
障害や攻撃が起きたときに、検知、影響の抑制、復旧、ふりかえりまでを決めた手順で進める活動。誰が何を判断するかを事前に決めておく点が要になります。
開発プロセス・方法論
IaC
（いんふらすとらくちゃあずこーど／Infrastructure as Code）
サーバやネットワークの構成を記述に置き換え、変更をレビューできるようにする実践です。同じ定義から同じ環境を作れる状態を目指します。
開発プロセス・方法論
ウォーターフォール
（うぉーたーふぉーる／Waterfall Model）
工程を順に固定して進め、前には戻らない前提で計画を組む開発の進め方です。受託や業務システムの出身者の経歴書に頻出します。
開発プロセス・方法論
受け入れテスト
（うけいれてすと／受入テスト／User Acceptance Test）
利用者や発注者が、合意した要件や業務上の受け入れ基準を満たすかを確認するテスト。検収との関係と合否の基準は、実施の前に定めておきます。
開発プロセス・方法論
運用・保守
（うんよう、ほしゅ）
稼働中のシステムを安定して使える状態に保ち、監視、問い合わせ対応、障害対応、改修を継続する業務。担当の範囲は組織によって異なります。
開発プロセス・方法論
AI駆動開発
（えーあいくどうかいはつ／AI-Driven Development）
人が書きAIが補助する形から、AIが書き人が検証する形へ反転させた開発の総称です。実装より、仕様の言語化と検証に時間が移ります。
開発プロセス・方法論
AI-DLC
（えーあいでぃーえるしー／AI-Driven Development Life Cycle）
人の手作業を前提に組まれた開発工程そのものを、AIの働き方に合わせて組み替える方法論です。AWSが2025年に公開しました。
開発プロセス・方法論
SLO・エラーバジェット
（えすえるおー・えらーばじぇっと／SLO / Error Budget）
信頼性の目標と、その未達の許容枠をあらかじめ合意しておく仕組みです。障害のたびに力関係で優先順位が決まる状態を避けられます。
開発プロセス・方法論
MLOps
（えむえるおぷす／Machine Learning Operations）
機械学習モデルの開発から配備、監視、更新までを継続して回すための実践。データの変化で精度が変わりうるため、作り直す前提で仕組みを整えます。
開発プロセス・方法論
MVP
（えむぶいぴー／Minimum Viable Product）
仮説を確かめるために必要な最小限の機能で作る製品。単に機能を削った試作ではなく、利用者から何を学ぶかを先に決めたうえで範囲を絞ります。
開発プロセス・方法論
開発生産性
（かいはつせいさんせい／Developer Productivity）
開発組織が価値を届け続ける力を、速さ・品質・安定性・開発者の働きやすさから捉える考え方。個人の作業量ではなく、組織としての流れを見ます。
開発プロセス・方法論
カンバン
（かんばん／Kanban）
板の上で作業の流れを可視化し、同時進行の上限を決めて滞留を防ぐ手法です。運用や保守のように依頼が随時発生する仕事で選ばれます。
開発プロセス・方法論
基本設計
（きほんせっけい）
要件定義を受けて、画面や帳票、外部との連携など利用者から見える仕様を決める工程。発注側と合意する対象になる範囲で、外部設計とも呼ばれます。
開発プロセス・方法論
結合テスト
（けつごうてすと／インテグレーションテスト／Integration Test）
複数のモジュールや外部サービスをつないだ状態での動作を確認するテスト。単体では表れない前提のずれや、データの受け渡しの不整合を見つける工程です。
開発プロセス・方法論
コードレビュー
（こーどれびゅー／Code Review）
実装を別の開発者が読み、欠陥の検出と設計判断の確認を行う工程です。実施しているかどうかではなく、基準と承認の条件まで示せるかで差が出ます。
開発プロセス・方法論
CI/CD
（しーあいしーでぃー）
分岐した作業を毎日のように統合し、いつでも出せる状態を保ち続ける仕組みです。自動テストとビルドの自動化が前提になります。
開発プロセス・方法論
シフトレフト
（しふとれふと／Shift-Left Testing）
後の工程ほど修正の費用が大きくなるため、検査を前方へ動かす考え方です。テストの量ではなく、置く位置を変える話になります。
開発プロセス・方法論
仕様駆動開発
（しようくどうかいはつ／Spec-Driven Development）
コードではなく仕様を正本に置き、変更は仕様側から入れて再生成する進め方です。生成の入力を安定させることが狙いになります。
開発プロセス・方法論
詳細設計
（しょうさいせっけい）
基本設計で定めた仕様を、処理手順やモジュール構成、データ構造など実装できる粒度まで具体化する工程。対象の範囲と呼称は開発体制によって異なります。
開発プロセス・方法論
スクラム
（すくらむ／Scrum）
誰が何に責任を持ち、いつ何を確認するかだけを定めた開発の枠組みです。具体的なやり方はチームに委ねられ、正本のガイドは意図的に薄く書かれています。
開発プロセス・方法論
スプリント
（すぷりんと／Sprint）
スクラムで、価値を生む作業を行う固定長の期間。1か月以内で長さを一定に保ち、計画、レビュー、レトロスペクティブなどのイベントを含みます。
開発プロセス・方法論
単体テスト
（たんたいてすと／ユニットテスト／Unit Test）
関数やクラスなど、ソフトウェアの小さな単位が期待どおり動くかを確認するテスト。自動化される例が多い一方、実施の方法は開発体制によって異なります。
開発プロセス・方法論
Team Topologies
（ちーむとぽろじーず）
チームの型を4つ、チーム同士の関わり方を3つに絞って調整の経路を設計する枠組みです。近年の職種名を読み解く下敷きになります。
開発プロセス・方法論
テスト駆動開発
（てすとくどうかいはつ／Test-Driven Development）
テストを先に書くことで、何ができれば正しいのかを実装前に決める手順です。テストしやすい形を先に考えるため、設計にも影響します。
開発プロセス・方法論
テスト自動化
（てすとじどうか／Test Automation）
人が繰り返し行う確認を、実行可能なコードとして残す取り組み。変更のたびに同じ検査を走らせ、壊れた箇所を早く見つける狙いがあります。
開発プロセス・方法論
DevOps
（でぶおぷす）
変更を出したい開発と、安定させたい運用の対立を、工程と分担の設計で解く取り組みです。自動化はその手段のひとつにあたります。
開発プロセス・方法論
トランクベース開発
（とらんくべーすかいはつ／Trunk-Based Development）
分岐の寿命を1日から数日に抑え、統合の衝突が育つ前に解消してしまうブランチ戦略です。GitFlowとの対比で語られます。
開発プロセス・方法論
PoC
（ぴーおーしー／概念実証／Proof of Concept）
考えた方法が実際に成り立つかを、小さく作って確かめる活動。本開発に入る前に、技術や前提の不確かさを減らすために置く工程を指します。
開発プロセス・方法論
BPR
（びーぴーあーる／業務プロセス改革／Business Process Re-engineering）
既存の業務手順を前提とせず、成果の向上を目的に業務プロセスを根本から見直して再設計する取り組み。組織や役割の変更を伴う場合があります。
開発プロセス・方法論
Fit&Gap分析
（ふぃっとあんどぎゃっぷぶんせき／フィットアンドギャップ分析／Fit and Gap Analysis）
既製のシステムの標準機能と自社の業務要件を突き合わせ、合う部分と合わない部分を洗い出す作業。差の埋め方を決めるための材料を作ります。
開発プロセス・方法論
ふりかえり
（ふりかえり／振り返り／レトロスペクティブ／Retrospective）
一定期間の進め方をチームで見直し、次に試す改善策を決める場。KPTなどの手法を使い、個人の責任追及ではなく進め方と仕組みの改善を対象にします。
開発プロセス・方法論
プロダクトディスカバリー
（ぷろだくとでぃすかばりー／Product Discovery）
作る価値があるかを、作り切る前に確かめる活動。開発と並行して進め、検証の結果を次に何を作るかの判断へ反映する進め方を指します。
開発プロセス・方法論
プロダクトバックログ
（ぷろだくとばっくろぐ／Product Backlog）
プロダクトに必要な作業を優先順に並べた一覧。プロダクトオーナーが並び順に責任を負い、内容は開発の進行にあわせて更新されます。
開発プロセス・方法論
ペアプログラミング
（ぺあぷろぐらみんぐ／Pair Programming）
書いている最中に判断を共有することで、設計のやり直しと知識の偏りを同時に防ぐ手法です。常時行うものではなく、場面を選んで使います。
開発プロセス・方法論
要件定義
（ようけんていぎ／Requirements Definition）
作るものが満たすべき条件を、関係者から引き出して文書にまとめる工程。何を作るかを決める工程であり、どう作るかを決める設計とは分かれます。
開発プロセス・方法論
リリース管理
（りりーすかんり／リリースマネジメント／Release Management）
変更を本番環境へ反映する手順と可否を統制する活動。切り戻しの手順と、誰が承認するかを事前に決めておくことが前提になります。
事業・プロダクト
ARPU
（あーぷ／Average Revenue Per User）
一定期間の売上を、その期間の利用者数や契約数で割った平均売上。分母を利用者、アカウント、契約のどれに置くかは事業によって異なるため定義を確認します。
事業・プロダクト
粗利率
（あらりりつ／売上総利益率／Gross Margin）
売上から原価を引いた利益の割合。SaaSでは基盤費用とサポート人件費の扱いで差が出るため、算入範囲を確認したうえで比較します。
事業・プロダクト
EBITDA
（いーびっとだー／Earnings Before Interest, Taxes, Depreciation and Amortization）
利息・税金・減価償却費・無形資産償却費を差し引く前の利益。資本構成や償却の影響を調整して収益性を比べる、会計基準の外にある指標です。
事業・プロダクト
ARR
（えーあーるあーる／年間経常収益／Annual Recurring Revenue）
契約が続く限り毎年入る売上を年額に直して合計した金額。一度きりの収入を除き、事業がどれだけの規模で続いているかを表します。
事業・プロダクト
SMB
（えすえむびー／Small and Medium Business）
中小規模の企業や事業者を指す顧客区分。売上高や従業員数など区分の基準は企業や市場によって異なるため、求人や事業資料では対象の範囲を確認します。
事業・プロダクト
NRR
（えぬあーるあーる／売上維持率／NDR／Net Revenue Retention）
既存顧客だけを見て、一定期間前の収益がいまいくらになっているかを表す割合。解約と縮小で減った分を拡大分が上回れば100%を超えます。
事業・プロダクト
MRR
（えむあーるあーる／月次経常収益／Monthly Recurring Revenue）
毎月繰り返し入る売上を、その月の金額に直して合計した金額。新規・拡大・縮小・解約に分けて、事業の増減を月単位で追うために使います。
事業・プロダクト
MAU・DAU
（えむえーゆー、でぃーえーゆー／Monthly / Daily Active Users）
一定期間内に、定義した利用行動を行ったユニークユーザー数。MAUは月間、DAUは日次を指し、対象の行動と重複の除き方をそろえて比較します。
事業・プロダクト
LTV
（えるてぃーぶい／顧客生涯価値／Customer Lifetime Value）
1人の顧客が取引を続けるあいだにもたらす利益の合計。獲得に1件あたりいくらまでかけてよいかの上限を決めるために使う指標です。
事業・プロダクト
仮説検証
（かせつけんしょう）
不確かな前提を仮説として言語化し、最小の手段で確かめる進め方。経歴では、検証の設計と結果にもとづく判断まで担ったかを確認します。
事業・プロダクト
技術戦略
（ぎじゅつせんりゃく／Technology Strategy）
事業の目標に対して、どの技術へ投資し、どこを内製し、どこを外部に任せるかを決める方針。採用計画や技術的負債への対応方針にも影響します。
事業・プロダクト
KPIツリー
（けーぴーあいつりー／KPI Tree）
最終的な目標を算式で分解し、枝分かれの形に並べた図。どの数字を動かせば目標に届くかを、担当者の行動まで降ろすために使います。
事業・プロダクト
顧客セグメント
（こきゃくせぐめんと／顧客区分／Customer Segment）
顧客を共通の性質でまとめた区分。法人向けの事業では企業規模で分ける方法が多く、区分ごとに、営業の進め方や求められる経験が異なります。
事業・プロダクト
CAC
（しーえーしー／顧客獲得単価／Customer Acquisition Cost）
顧客を1件獲得するのにかかった費用。営業とマーケティングの支出を、その期間に獲得した顧客数で割って求め、獲得への投資が見合うかを判断します。
事業・プロダクト
GTM
（じーてぃーえむ／GTM戦略／Go-to-Market）
作った製品を誰にどの経路で届け、どう買ってもらうかの設計。対象顧客・価格・販売チャネル・担当する組織の並べ方をまとめて指します。
事業・プロダクト
事業計画
（じぎょうけいかく／Business Plan）
売上と費用の見通しを、施策と人員の前提とあわせて置いた計画。採用の人数と時期は、この計画に置いた前提から逆算して決まるため、前提が変われば採用計画も見直します。
事業・プロダクト
失注分析
（しっちゅうぶんせき）
受注に至らなかった商談の理由を構造化して整理する取り組み。価格、機能、時期、競合のどこで外れたかを分けると打ち手が具体化します。
事業・プロダクト
Sales Led Growth
（せーるすれっどぐろーす／セールスレッドグロース）
営業組織が商談を通じて売上をつくる成長モデル。単価が高く意思決定者の多い法人向け製品で、契約から導入まで人が伴走する形を指します。
事業・プロダクト
0→1・1→10
（ぜろいち・いちじゅう／ゼロイチ／Zero to One / One to Ten）
事業の段階を表す言い方。0→1は事業を成り立たせる段階、1→10は成り立った事業を再現して広げる段階を指し、求められる経験が異なります。
事業・プロダクト
チャーンレート
（ちゃーんれーと／解約率／チャーン率／Churn Rate）
一定期間に失った顧客または収益の割合。契約が続く前提の事業で、新規に獲得した顧客がどれだけ残るかを裏側から示す指標です。
事業・プロダクト
チャネル販売
（ちゃねるはんばい／Channel Sales）
代理店や販売パートナーなど、第三者の販路を通じて販売する方式。直販と併用されることもあり、役割分担と提供条件の設計が必要になります。
事業・プロダクト
調達フェーズ
（ちょうたつふぇーず／資金調達フェーズ／調達ラウンド／Funding Stage）
スタートアップが外部資金を何段階目で受け入れたかを示す区分。シード・シリーズA・B・Cのように呼び、事業の成熟度の目安に使われます。
事業・プロダクト
toB・toC
（とぅーびー、とぅーしー／B2B / B2C）
法人を顧客とする事業と、一般消費者を顧客とする事業の区別。購買の意思決定者と導入までの期間に違いがあり、求められる経験も異なります。
事業・プロダクト
ドメイン知識
（どめいんちしき／Domain Knowledge）
対象業界の業務や商習慣についての理解。産業特化のプロダクトでは要件定義の精度を左右し、採用要件の加点条件に置かれることがあります。
事業・プロダクト
バーティカルSaaS
（ばーてぃかるさーす／Vertical SaaS）
特定の業界を対象に、その業界に固有の業務や商習慣へ対応するSaaS。業種を問わず共通の業務を扱うホリゾンタルSaaSと対になる分類です。
事業・プロダクト
バーンレート
（ばーんれーと／Burn Rate）
一定期間に消費する現金の額。総支出を示すグロスバーンと、収入を差し引いた減少額を示すネットバーンを区別して確認し、採用計画の前提に置きます。
事業・プロダクト
PSF
（ぴーえすえふ／プロブレムソリューションフィット／Problem Solution Fit）
解こうとしている課題が実在し、用意した解決策に相手が対価を払うと確かめられた状態。製品を作り始める前に置く、最初に越えるべき関門です。
事業・プロダクト
PMF
（ぴーえむえふ／プロダクトマーケットフィット／Product Market Fit）
作った製品が、その市場の需要を満たしている状態を指します。良い市場を選び、そこに合う製品を届けられているかを問う基準です。
事業・プロダクト
P/L
（ぴーえる／損益計算書／Profit and Loss Statement）
一定期間の収益と費用を並べ、利益がどう生まれたかを示す計算書。事業部の責任範囲を語るときは、その数字に責任を持つ立場を指します。
事業・プロダクト
B2B2C
（びーつーびーつーしー）
法人を通じて一般消費者へ価値を届ける事業構造。契約先と利用者が別であるため、導入先の業務と利用者の体験を同時に設計します。
事業・プロダクト
プロダクトマネジメント
（ぷろだくとまねじめんと／Product Management）
何を作り、何を作らないかを決めて成果に結びつける活動。顧客の課題、事業の目標、開発の制約を突き合わせて優先順位を決めます。
事業・プロダクト
Product Led Growth
（ぷろだくとれっどぐろーす／プロダクトレッドグロース）
営業ではなくプロダクト自身に顧客の獲得と定着を担わせる成長モデル。無料で使い始められる入口と、課金までの経路を製品側に組み込みます。
事業・プロダクト
ホリゾンタルSaaS
（ほりぞんたるさーす／Horizontal SaaS）
業種を問わず共通する業務を対象にするSaaS。会計や人事のように対象が広く、業界特化のバーティカルSaaSと対になる分類です。
事業・プロダクト
ユニットエコノミクス
（ゆにっとえこのみくす／Unit Economics）
顧客1件あたりの収益と費用を取り出し、事業が拡大するほど利益が出る構造かどうかを確かめる見方。SaaSではLTVとCACの関係で判断します。
事業・プロダクト
ランウェイ
（らんうぇい／Runway）
現在の手元資金で事業を継続できると見込む期間。手元資金をネットバーンで割って算出し、収入と支出の変動を織り込んで見直します。
採用実務
RPO
（あーるぴーおー／Recruitment Process Outsourcing）
採用業務の一部または全体を外部に委託する形態です。人材を紹介してもらうのではなく、採用の実務そのものを担ってもらいます。
採用実務
アルムナイ採用
（あるむないさいよう／Alumni Hiring）
自社を退職した人を、本人と企業の合意にもとづいて再び採用する手法。在籍していた実績だけで判断せず、退職後の経験と現在の要件を照らして評価します。
採用実務
一次面接
（いちじめんせつ）
選考の最初に置く面接。エンジニア採用では現場のエンジニアやエンジニアリングマネージャーが担当し、書類に書かれた経験の実体確認と、仕事内容の説明を兼ねます。
採用実務
AI-RPO
（えーあいあーるぴーおー／AI-driven RPO）
採用代行の実務に生成AIを組み込み、候補者の選別や文面作成を自動化する形態です。判断の最終責任は人が持つ前提で運用します。
採用実務
エージェントフィー
（えーじぇんとふぃー／紹介手数料）
人材紹介会社へ支払う手数料。届け出た手数料表の範囲内で個別の契約により額が決まるため、算定の基礎になる年収の範囲と、早期離職時の返金規定をあわせて確認します。
採用実務
ATS
（えーてぃーえす／Applicant Tracking System）
応募者の情報と選考の進み具合を一元管理するシステムです。経路の違う候補者を同じ台帳の上で扱えるようにし、重複した接触を防ぎます。
採用実務
オファー面談
（おふぁーめんだん／Offer Meeting）
内定を出した候補者に条件と期待する役割を伝え、意思決定を支える場です。合否の判定は終わっており、口説く段階にあたります。
採用実務
オンボーディング
（おんぼーでぃんぐ／Onboarding）
入社者が成果を出せる状態になるまでの受け入れ設計。環境準備、役割の明示、初期の担当業務の設定までを含み、定着率に直接影響します。
採用実務
カジュアル面談
（かじゅあるめんだん／Casual Interview）
合否を判定しない前提で、企業と候補者が相互に情報を交換する場です。転職をまだ決めていない層と接点を持つために置かれます。
採用実務
技術・人文知識・国際業務
（ぎじゅつ・じんぶんちしき・こくさいぎょうむ／Engineer / Specialist in Humanities / International Services）
外国籍のエンジニアを雇用する際に多く用いられる在留資格です。従事する業務と本人の学歴や実務経験が対応している必要があります。
採用実務
求人媒体
（きゅうじんばいたい／Job Board）
求人を掲載し、候補者と接点を持つためのサービスです。応募を集める型と、企業から候補者に接触する型で運用の仕方が変わります。
採用実務
業務委託
（ぎょうむいたく）
雇用ではなく契約にもとづいて業務を依頼する形態。成果物に責任を負う請負と、業務の遂行を約束する準委任で責任範囲が異なります。
採用実務
勤続年数
（きんぞくねんすう）
労働者が1つの企業に入社してから、現在または退職するまでの年数。職種単位で数える経験年数とは別の値で、採用では期間の長短より在籍中の役割の変化を確認します。
採用実務
構造化面接
（こうぞうかめんせつ／Structured Interview）
質問項目と評価基準をあらかじめ決め、全候補者に同じ手順で行う面接です。面接官による判断のばらつきを抑えるために使います。
採用実務
候補者体験
（こうほしゃたいけん／Candidate Experience）
候補者が最初の接触から入社または見送りまでに受け取る体験の総称です。選考の結果によらず、企業の評判として長く残り続けます。
採用実務
コーディングテスト
（こーでぃんぐてすと／Coding Test）
候補者に実際にコードを書いてもらい、技術力を確認する選考手法です。面接での自己申告と実際の力の差を埋めるために使います。
採用実務
最終面接
（さいしゅうめんせつ）
採用可否を決める最後の面接。経営層や事業責任者が担当することが多く、条件のすり合わせと相互の意思確認を行います。ここでの見送りが多い場合は前段の基準を疑います。
採用実務
採用計画
（さいようけいかく／Hiring Plan）
いつまでに何名を採用するかを、職種と時期で置いた計画。歩留まりの実績から必要な母集団数を逆算して立てると、稼働量の見積もりが合います。
採用実務
採用KPI
（さいようけーぴーあいー／Recruiting KPI）
採用活動の進み具合を測るために置く指標です。採用数などの結果指標と、接触数のように行動で動かせる指標を分けて設計します。
採用実務
採用広報
（さいようこうほう／Recruitment PR）
働く環境や技術的な取り組みを社外に発信する活動です。社名で検索した候補者が判断材料を得られるかどうかが、スカウトや応募の反応に表れます。
採用実務
採用単価
（さいようたんか／Cost Per Hire）
1名の採用にかかった費用。媒体費や紹介手数料に加え、社内工数を含めるかどうかで数値が変わるため、算入範囲を先に決めて比較します。
採用実務
採用パイプライン
（さいようぱいぷらいん／Hiring Pipeline）
いま選考中の候補者が、どの段階に何人滞留しているかという時点の見方。期間の通過率を扱う採用ファネルとは、測る対象が異なります。
採用実務
採用ファネル
（さいようふぁねる／Recruiting Funnel）
接触から入社までの各段階と、段階ごとの通過率を並べて見る枠組みです。どこで候補者が減っているのかを特定するために使います。
採用実務
採用ブランディング
（さいようぶらんでぃんぐ／Employer Branding）
働く場所として選ばれる状態を意図して作る取り組みです。発信だけでなく、実際の働き方や処遇と揃っていることが前提になります。
採用実務
採用要件定義
（さいようようけんていぎ／Hiring Requirements Definition）
どんな人を採るのかを、経験と能力の水準まで具体化して社内で合意する工程です。採用活動の成否をほぼ決める上流工程にあたります。
採用実務
試用期間
（しようきかん／Probation Period）
本採用の前に適性を確認する期間。労働契約は成立しているため、期間中であっても解約には客観的で合理的な理由が必要になります。
採用実務
職務経歴書
（しょくむけいれきしょ）
担当した業務と実績をまとめた書類。履歴書と違って様式が決まっておらず、何をどこまで書くかの選択そのものが判断の材料になります。
採用実務
ジョブ型雇用
（じょぶがたこよう／Job-based Employment）
職務の内容を先に定め、それに対して人を採用し処遇するという考え方です。人に仕事を割り当てる従来の運用と対比して語られます。
採用実務
ジョブディスクリプション
（じょぶでぃすくりぷしょん／Job Description）
任せる職務と期待する成果、必要な経験を記述した文書です。候補者の応募判断と、選考に関わる社内の判断基準の両方を支えます。
採用実務
書類選考
（しょるいせんこう／書類審査／Resume Screening）
履歴書や職務経歴書など、提出された書面をもとに次の選考へ進めるかを決める工程。判断できる範囲は書面に書かれた事実に限られます。
採用実務
書類選考通過率
（しょるいせんこうつうかりつ）
応募またはスカウト返信のうち、書類選考を通過した割合。低いときは要件の厳しさと母集団の質のどちらが原因かを分けて確認します。
採用実務
人員計画
（じんいんけいかく／Headcount Plan）
事業計画に対して必要な人員の数と配置を定める計画。採用計画の前提にあたり、既存メンバーの異動や退職の見込みも織り込みます。
採用実務
人材紹介
（じんざいしょうかい／Recruitment Agency）
紹介会社が候補者を推薦し、入社に至った場合に手数料が発生する採用経路です。厚生労働大臣の許可を受けた事業者だけが行えます。
採用実務
スカウト
（すかうと／Scout Message）
企業から候補者へ個別に送る接触メッセージです。誰に送るかを決める検索条件と、届いた後に読まれる求人票と一体で機能します。
採用実務
スカウト返信率
（すかうとへんしんりつ／Scout Reply Rate）
送ったスカウトのうち返信が返ってきた割合です。改善余地を測る指標であると同時に、企業側の条件がそのまま出る数字でもあります。
採用実務
スカウト要件
（すかうとようけん）
スカウトを送る相手を決める基準。採用要件の解像度を上げ、レジュメから読み取れる・判断できる要素へ蒸留したものを指します。
採用実務
スキルベース採用
（すきるべーすさいよう／Skills-based Hiring）
学歴や在籍企業ではなく、業務に必要なスキルの有無で評価する採用手法。評価対象のスキルを事前に定義し、確認方法まで決めておく必要があります。
採用実務
成功報酬
（せいこうほうしゅう）
採用が成立したときにだけ費用が発生する課金方式。初期費用を抑えられる一方、何をもって成立とするかは契約ごとに異なるため、請求の時点と返金の規定をあわせて確認します。
採用実務
選考ボトルネック
（せんこうぼとるねっく）
採用全体の人数や進み方を強く制約している選考の段や処理能力。通過率の低さだけでなく、母数と所要日数、改善したときの影響から見極めます。
採用実務
第二新卒
（だいにしんそつ）
学校卒業後に就職し、おおむね3年以内に転職する層。社会人経験は浅い一方で基礎的な就業経験を持つため、新卒とも中途とも異なる枠で募集されます。
採用実務
ダイレクトリクルーティング
（だいれくとりくるーてぃんぐ／Direct Recruiting）
企業が候補者を自ら探して直接声をかける採用手法です。応募を待つのではなく、採用したい人を特定して接触するところに違いがあります。
採用実務
タレントアクイジション
（たれんとあくいじしょん／Talent Acquisition）
欠員補充としての採用ではなく、中長期の事業計画から逆算して人材を獲得する考え方。母集団の形成やブランディングまでを含みます。
採用実務
タレントプール
（たれんとぷーる／Talent Pool）
将来の採用候補になる人を蓄積しておく名簿です。今回は縁がなかった人と接点を保ち、次の募集で最初に声をかける相手にします。
採用実務
短期離職
（たんきりしょく）
入社から短い期間で退職すること。職務経歴書では在籍年数・社数・直近数社の並びとして現れ、1年から3年を目安に見られます。
採用実務
定着率
（ていちゃくりつ／Retention Rate）
入社した人が一定期間後に在籍している割合。採用の成否を入社時点でなく定着まで含めて測る指標で、入社後1年時点を区切りに置く例が多く見られます。
採用実務
適性検査
（てきせいけんさ）
基礎的な能力や行動特性を測る検査。合否の単独基準ではなく、面接で確認する観点を絞るための補助情報として使うと運用が安定します。
採用実務
転職回数
（てんしょくかいすう）
職務経歴書に記載された勤務先の変更回数。年齢や業界慣行によって意味が変わるため、回数だけでなく在籍年数と役割の推移をあわせて読みます。
採用実務
転職潜在層・転職顕在層
（てんしょくせんざいそう、てんしょくけんざいそう）
いま転職活動をしている層と、活動はしていないが条件次第で検討する層の区分。採用側は層に応じて接触の方法と伝える内容を変えます。
採用実務
内定辞退
（ないていじたい）
内定を受けた候補者が入社を見送ること。条件面だけでなく、選考中の情報提供の不足や意思決定の遅さが原因になる場合があります。
採用実務
内定承諾率
（ないていしょうだくりつ／Offer Acceptance Rate）
内定を出した人のうち入社を承諾した割合です。選考の最終段階を示す指標で、下がったときは提示条件と伝え方の両方を点検します。
採用実務
年収レンジ設計
（ねんしゅうれんじせっけい／Salary Range Design）
募集ポジションに提示する年収の幅と、その幅がどの経験水準に対応するかを決める設計です。既存社員の処遇との整合も含みます。
採用実務
ノックアウト条件
（のっくあうとじょうけん／Knockout Criteria）
該当した時点で他を確認せず見送ると先に決めておく条件。判断を速くする一方、設定を誤ると要件に合う候補者まで機械的に除外します。
採用実務
副業・兼業
（ふくぎょう、けんぎょう）
本業を持つ人が別の仕事にも従事する働き方。複数の雇用契約がある場合は労働時間の通算が論点になり、勤務先の規程や秘密保持、競業の扱いも確認します。
採用実務
歩留まり
（ぶどまり）
選考の各段階で、次の段へ進んだ候補者の割合。どこで人数が減っているかを示しますが、低い段が必ず改善対象になるとは限りません。
採用実務
ペルソナ設計
（ぺるそなせっけい／Candidate Persona Design）
採用したい候補者を、経歴や志向を持つ具体的な人物として描く手法です。要件を候補者の目線に翻訳し、検索条件と訴求内容に落とし込むために使います。
採用実務
母集団形成
（ぼしゅうだんけいせい／Candidate Pool Building）
選考の対象になる候補者を、必要な人数と質で確保する活動です。採用が計画どおりに進まない原因の多くは、この最上流の段階に残っています。
採用実務
面談設定率
（めんだんせっていりつ）
スカウトに返信した候補者のうち、面談の日程まで確定した割合。分母の取り方を固定し、対応速度や候補者側の事情とあわせて読みます。
採用実務
離職期間
（りしょくきかん）
退職後、次の就業開始または現在までの、雇用先への在籍が確認できない期間。事情は書類に現れないため、書面の事実を起点に確認します。
採用実務
リファラル採用
（りふぁらるさいよう／Referral Hiring）
社員の紹介を通じて候補者と接点を持つ採用手法です。定着しやすい一方で、勧められる組織の状態がないと件数は積み上がりません。
採用実務
リファレンスチェック
（りふぁれんすちぇっく／Reference Check）
候補者の同意を得て、元上司や同僚に働きぶりを確認する手続き。同意なく実施すると法的な問題になるため、実施時期と範囲を事前に明示します。
採用実務
労働条件明示
（ろうどうじょうけんめいじ／Working Conditions Disclosure）
募集の段階と契約の締結時に、業務内容や賃金などの労働条件を示す法令上の義務です。求人票をどう書くかにも直接関わってきます。