海外企業のオペレーション職は、営業や人事などの仕事が滞りなく進むよう、情報・手順・担当者のつながりを整える仕事です。日本の事務で行ってきた照合や進行管理と接点があります。ただし、Operationsという名前の中には、日々の処理を支える職も、部門をまたぐ改善を主導する職もあります。
この記事ではGitLabの公開職務説明を読み、Sales Operations、People Operations、Strategy and Operationsの違いを比べます。後半では、架空の処理依頼6件を使い、何を進め、どこで止め、次の人へ何を渡すかまで確認します。
公式資料の確認日:2026年10月9日。紹介するのは1社の職務定義で、現在募集中の求人一覧ではありません。日本からの応募・勤務、採用、就労資格を保証するものではありません。人物・依頼・数値・練習用ルールは、該当箇所に明記した編集部作成の架空例です。
表紙はオペレーション業務を表すAI生成イラストです。実在の職場・社員や業務実績を示すものではありません。
記事のもくじ
オペレーション職は何を整える仕事?
たとえば、営業担当から「顧客情報を直してほしい」と依頼が届いたとします。修正箇所を入力する前に、どの顧客の、どの情報を、何を根拠に変更するのかを確かめます。依頼と証拠が食い違えば確認を返し、承認が必要なら判断できる担当へつなぎます。更新後に履歴を残すところまで含めると、仕事の輪郭が見えてきます。
同じ考え方を、従業員の入社手続きに使う職もあれば、複数部署が使う業務フローの改善に使う職もあります。相手、扱う情報、判断の範囲が変わるため、「事務に似ているか」だけでは選べません。
営業が顧客への提案や契約を進める場面に対し、Sales Opsでは営業が使う記録や手順を支える仕事が見られます。顧客の利用・定着を支えるカスタマーサクセスとも連携しますが、本記事では社内の業務運用に注目します。実際の境界は会社ごとに違うので、肩書きより担当業務を確かめましょう。
比較のときは、次の三つを具体的に答えられるかが目安になります。
- 誰の仕事を支えるか:営業担当、従業員、人事担当、部門責任者など
- 何を受け取り、何を残すか:依頼、登録情報、確認結果、対応履歴、改善計画など
- どこまで自分で決めるか:決まった手順の実行、例外の判断、手順自体の設計など
GitLabの3職種を同じ項目で比べる
以下はGitLabの公式Job Description Libraryにある職務説明の要約です。比較する職位はAssociate、Specialist、Seniorでそろっていません。名前が似た仕事の範囲を見比べるための例で、難易度ランキングや共通の昇進コースではありません。
Sales Operations:営業が使う情報と手順を支える
参照職位:Associate Sales Operations Analyst
- 社内の相手
- 営業・営業支援と関連する運用チーム。
- 仕事内容
- Salesforce内の顧客記録の整備、社内質問への対応、データ品質の確認や標準手順に沿った運用の補助。上司の明確な指示・監督の下で進める職位です。
- 経験・能力の条件
- 営業運用の基礎知識と経験、Salesforce経験、企業向けSaaSツールの知識などが記載されています。期限管理、分析・優先順位付け、書面・口頭での伝達力も求められます。
- 働き方として読めること
- 上司や他部門との連携が前提。参照した職位欄だけでは、勤務国・勤務時間・個別の雇用条件は確定しません。
出典:GitLab「Sales Operations Roles」
仕事を想像するための成果物例:修正した項目、根拠、確認待ちを残す対応記録。これは編集部による学習用の例で、GitLabの指定書式ではありません。CRMは顧客情報や関係する履歴を管理する仕組みです。表計算で照合してきた経験との接点はありますが、CRMの操作や営業ルールを理解した経験とは分けます。
People Operations:従業員に関する手続きをつなぐ
参照職位:People Operations Specialist
- 社内の相手
- 新しく入る人、在籍する従業員、People Operationsの同僚。
- 仕事内容
- 入社時の手続きと連絡、従業員データの定期確認、Slackやメールでの問い合わせ受付、担当者不在時の引き継ぎなど。
- 経験・能力の条件
- 機密保持、細部への注意、複数業務の並行対応、伝達力を挙げています。Greenhouse・GitLab・Workdayの経験は加点要件です。この職位の要件欄に特定の経験年数はありません。
- 働き方として読めること
- 変化の速い環境で、分散したチームと働く力が明記されています。勤務可能な国や勤務時間は、この記載からは決まりません。
仕事を想像するための成果物例:入社準備の項目ごとに、完了・未完了・確認先を残したチェック記録。これも学習上の例です。総務や人事事務での確認・連絡と接点を探せます。給与や雇用に関する情報を扱う場合は、正確さだけでなく、誰が閲覧できるかも重要になります。
Strategy and Operations:部門をまたぐ課題を実行へ進める
参照職位:Senior Strategy and Operations
- 社内の相手
- CEOを支える組織や、課題に関係する複数部門。
- 仕事内容
- 継続するプロジェクトの支援、資料・プログラムの作成補助、実務上の要望を業務・技術の要件へ整理することなど。
- 経験・能力の条件
- 直接の指揮権がなくても部門を越えて協力を得る力、自律的に進めた実績、構想から実行まで進めた経験を挙げています。高成長スタートアップでの2年以上の経験は、望ましい条件です。
- 働き方として読めること
- 部門横断の協働と、自分で仕事を管理する力が必要です。参照したSenior欄だけで勤務地や時差条件は特定できません。
出典:GitLab「Strategy and Operations」
仕事を想像するための成果物例:課題、対応案、関係部署、決める人、実行の順序をまとめた計画。単に依頼を処理する場合よりも、問題の整理と実行責任の比重が大きいと読み取れます。事務経験から直ちに移れると判断せず、改善プロジェクトで何を担ったかを照合する候補です。
営業のデータを整えたいのか、従業員の手続きを支えたいのか、部署をまたぐ改善を進めたいのか。まず関心のある対象を決めると、Operationsという大きな言葉から、調べるべき業務へ絞り込めます。
公開職務説明と実際の求人を読み分ける
職務説明は、仕事の範囲を学ぶのに役立ちます。一方、応募するときは、現在の募集ページを開き、採用する職位・勤務地・雇用形態まで確かめます。公開ハンドブックに職名があることと、その職を今募集していることは別です。
読む順序は「職位→業務→要件→働ける条件」にすると整理しやすくなります。Responsibilitiesには担当する仕事、Requirementsには求める条件が書かれることが多く、is a plusやideallyなどの表現は、必須と同じ強さではありません。記載がない条件を、不要と補って読むことも避けてください。
- 職位:Associateだけで「未経験向け」と決めない。上のSales Opsには経験要件があります。
- 要件の強さ:望ましい条件と必須条件を分け、不明なものは「要確認」と残す。
- 勤務条件:居住・勤務できる国、出社の有無、時間帯の重なり、雇用形態、就労資格と支援の有無を個別に読む。
- 更新状態:確認日と募集URLを控え、応募直前に公式ページを読み直す。
GitLabの候補者向け案内も、自分がいる国でその職を採用しているかは、個別の募集を確認するよう案内しています。「リモート」と書かれていても、日本に住んだまま働けるとは限りません。出典:GitLab「Candidate Handbook Page」
海外へ移住して働く、日本法人で働く、日本から海外企業の仕事をする、という希望も分けておきましょう。本記事の3職種について、現在の募集有無、日本居住者の応募可否、ビザ支援は確認していません。
記録の数字を読む前に確認すること

Opsの練習では、合計を出す前に「1行は何を表すか」を説明してみてください。1行が顧客なのか、商談なのか、更新依頼なのかによって、数えた結果の意味が変わります。ここからは公式資料の要約を離れ、編集部作成の架空教材で考えます。
顧客名「教材A社」が2行。
顧客IDはB101とB207。
同じ企業の重複か、別の契約先かは未確認。
何を1件と数えるかを確認。
ID・契約先・登録根拠を照合する。
見た目の一致だけで削除・統合しない。
今言えるのは「記録が2行」。
顧客が2社とも1社とも確定しない。
未確認の扱いを、集計の担当者と決める。
次節の6件とは別の架空例。行数と顧客数の違いを確認する図です。実在企業のデータや処理手順ではありません。
実データを扱うときも、会社の手順と権限を確認したうえで、次の順番で読みます。
- 対象と時点:全件か一部か。いつまでの記録か。期間の途中を切り取っていないか。
- 単位と識別子:1行の意味、同じ対象を見分けるID、日付や金額の単位を確かめる。
- 欠けと重複:空欄は未入力、対象外、未確定のどれか。重複らしく見える行は、本当に同じ対象か。
- 確認先:元資料、入力担当、データの管理担当など、何を誰に聞くと決まるかを残す。
たとえば「依頼6件中2件を完了した」という記録から、担当者の生産性が低いとは言えません。受け付けてからの時間、依頼の難しさ、保留理由が不明だからです。数字を計算できることと、その意味を説明できることを分けると、報告が正確になります。
完成例:6件の依頼を分類し、引き継ぐ

ここでは、架空の会社で営業情報の更新を補助する場面を練習します。あなたは受付担当の佐藤さん、次の担当は森さんです。6件とも2026年10月15日9時台に受け付け、10時に引き継ぐ設定です。時刻はすべて日本時間です。GitLabの実務手順、採用試験、Kredoの授業課題ではありません。
この教材だけのルール
- 根拠資料と対象IDが一致した、表示名・業種ラベルの修正は受付担当が実行できる。
- 日付の食い違い、同一顧客か不明な記録は確認待ち。推測して書き換えない。
- 金額変更は営業責任者、担当者変更は該当チーム責任者の承認が必要。申請を出しただけでは承認済みにしない。
- 日付は確定資料との一致を確認後、金額・担当者は責任者の承認内容と根拠を照合後に、受付担当が更新できる。引き継ぎ後は森さんが同じ範囲を担う。
- 顧客記録の統合・削除は受付担当の権限外。管理担当へ判断を依頼する。
- 依頼者へ完了を約束するのは、必要な確認・承認と更新が終わってから。下の期限は「次に状況を確認する時刻」で、完了保証ではない。
必要な情報がそろい、食い違いはない?
依頼者や管理担当へ質問。
回答が来たら、根拠と対象を再確認。
承認が必要なら、承認待ちへ。
確認先と次の確認時刻を記録する。
決められた範囲で更新。
結果を確認し、履歴と完了連絡を残す。
保留中も引き継ぐ:理由/確認相手/次の担当/再確認時刻を残す
架空教材の判断順序です。回答や承認が来ても、内容の照合を飛ばして更新しません。
以下が、依頼内容と10時時点の処理を合わせた完成記録です。「対応中」だけで終わらせず、森さんが続きを進められるところまで書きます。
R01 表示名の誤字修正 通常処理・完了
依頼と根拠:A101の表示名を「教材エー」から「教材A」へ。対象IDが一致する申込資料で表記を確認済み。契約主体は変わりません。
記録:佐藤が9時35分に更新し、再表示で確認。変更前後と根拠の参照先を履歴に保存し、依頼者へ完了連絡済み。
次の担当・確認時刻:追加作業なし。森への確認依頼なし。
R02 業種ラベルの修正 通常処理・完了
依頼と根拠:A102の業種を「その他」から、承認済みの分類一覧にある「製造」へ修正。対象IDと顧客申告の資料が一致。
記録:佐藤が9時45分に更新し、選択値を確認。変更前後と根拠を記録し、依頼者へ連絡済み。
次の担当・確認時刻:追加作業なし。森への確認依頼なし。
R03 商談予定日の食い違い 情報待ち
依頼と未確認:商談D103を10月20日に変える依頼。添付の最新とされる日程表は10月22日。どちらが確定か不明。
記録:更新せず、営業担当の青木へ確定日と根拠を質問済み。
次の担当・確認時刻:森が15日11時に回答確認。返信がなければ影響を添えてチーム責任者へ相談。回答後に資料を照合して更新する。
R04 顧客の二重登録らしい記録 情報待ち
依頼と未確認:同名のA104・A204を一つにしてほしいとの依頼。契約先が同じか確認できていない。
記録:両方を維持し、データ管理担当の伊藤へ確認依頼。受付担当は統合・削除しない。
次の担当・確認時刻:森が15日13時に回答確認。同一対象と分かっても、実際の統合は管理担当の判断・手順へ引き継ぐ。
R05 商談金額の変更 承認待ち
依頼と未確認:D105を120万円から100万円へ。対象IDと金額が依頼に一致する改訂見積案は確認済み。営業責任者の承認は申請中。
記録:金額は未更新。営業責任者の田中へ、この見積案の内容の承認を申請中。
次の担当・確認時刻:森が15日14時に承認記録を確認。承認された対象・金額・資料の版を照合できた場合のみ、森が金額を更新し、結果と履歴を確認する。
R06 担当営業の変更 承認待ち
依頼と未確認:A106の社内担当を青木から蓮見へ。対象と変更先は特定済みだが、該当チーム責任者の承認がない。
記録:担当欄は未更新。責任者の加藤へ承認を依頼済み。
次の担当・確認時刻:森が15日15時に回答確認。承認後に対象と変更先を照合し、更新結果を両担当へ連絡する。
引き継ぎの冒頭は、このくらい短くまとめられる
森さんへの引き継ぎメモ・架空の完成例
10月15日10時時点、受付6件のうち完了2件、情報待ち2件、承認待ち2件です。R03〜R06は対象データを変更していません。
最初の再確認はR03の11時です。青木さんへ確定日を質問済みなので、回答と根拠を照合してください。R04の統合は管理担当の判断が必要です。R05・R06は承認申請中で、承認済みではありません。
各案件の確認相手と再確認時刻は、上の記録に残しました。時刻を過ぎても返答がない場合は、未回答の事実と業務への影響を責任者へ共有してください。
この例のポイントは、保留4件を「未処理」とまとめないことです。情報が足りない案件と、判断できる人の承認を待つ案件では、次に聞く相手が違います。引き継ぎ先が受け取れるかも確認し、不在なら責任者と代わりの担当を決めます。
自分で練習するなら、各依頼の内容だけを別紙へ写し、状態ラベルと対応記録を見ずに分類してから、完成例と比べてください。判断が違った場合は、速く処理できたかより「どの情報・権限が足りないと考えたか」を説明します。会社の実データは使わず、名前や金額も一から作った架空のものにします。
事務経験と不足を分ける準備シート
次は、営業事務経験のある架空の応募者・山田さんの記入例です。注文書と一覧の照合、確認依頼、引き継ぎを担当してきました。Salesforceは未使用、仕事上の英語連絡も未経験という設定です。GitLabのSales Opsの職務説明を参照しますが、採用可能性を判定するものではありません。
記入済みの準備シート
- ① データ整備に近い作業はあるか
- 経験あり:注文書と受注一覧の納品先を照合し、不一致を営業担当へ確認してから更新した。自分の担当は確認・更新まで。
次に確かめる:応募先で扱うデータ、変更権限、記録方法は違うため、近い経験として説明する。 - ② Salesforceと営業運用の知識はあるか
- 不足あり:表計算での照合経験はあるが、Salesforceの実務経験はない。応募先の営業ルールも知らない。
次の練習:公式の入門教材で顧客・商談・担当者の違いを学ぶ。学習と実務経験を区別し、要件の不足を隠さない。 - ③ 書面・口頭で状況を伝えられるか
- 一部経験あり・英語は未検証:日本語で確認待ちの一覧を共有していた。英語で質問を受け、返答する力は試していない。
次の練習:R03の保留理由を短い英語で伝え、確定日を聞く。これは英語を使う仕事を想定した自主練習で、参照職位に英語スコアの指定があるという意味ではない。 - ④ 働ける条件が合うか
- 未確認:この職務説明だけで日本勤務の可否は分からない。募集ページで勤務地・時間帯・雇用形態を確かめる。就労資格と支援の有無も別に確認する。
全部を「できる」に変えることが目的ではありません。たとえば山田さんは、情報照合の接点を説明できますが、Salesforce経験の要件はまだ満たしたと示せません。その差が分かれば、学習する、現職で許可された関連業務を担当する、別の条件の募集を探す、といった次の選択ができます。
自分で書くときの空欄版
参照する職位・公式URL・確認日:____
担当業務と要件を一つずつ:____
近い実務経験と、自分が判断できた範囲:____
不足している知識・ツール/まだ試していない能力:____
次に作る練習物と、できたか確かめる方法:____
勤務国・時間帯・雇用形態・就労条件の確認結果:____
採用担当などへ確認する質問:____
経験の材料を探すところから始めたい方は、日本での仕事経験を海外キャリアに向けて整理する方法も参考にしてください。本記事では、その材料を特定のOps業務へ照合します。
英語・ツール・業務知識を小さく試す
英語は、難しい表現を増やす前に、保留理由と確認したいことを短く伝えてみます。引き継ぎ後、森さんの立場でR03の状況を伝えるなら、次のように書けます。これは教材の英語例で、実際に送ったメッセージではありません。
R03 is on hold. The request says October 20, but the attached schedule says October 22. Could you confirm the correct date and share the source? I will check for your reply at 11:00 JST on October 15. I have not updated the record.
伝えているのは、状態、二つの日付の不一致、確認したい内容、こちらが返信を確認する時刻、まだ更新していない事実です。相手から「22日で確定」と返ってきたら、根拠もそろったかを確認し、更新後の結果まで伝える練習をします。実際の職場では、合意した連絡手段・期限・表記に合わせます。
ツール学習では、架空データに対象IDを付け、必須欄の不足や重複候補を見つけ、変更前後を残してみましょう。見栄えのよい一覧よりも、第三者が「なぜ保留にしたか」を追えるものを目指します。表計算で作ったサンプルは、Salesforceで実務を行った証拠にはなりません。
業務知識も別に必要です。Sales Opsなら顧客と商談、予定と確定、金額の変更とその承認を区別する。People Opsなら従業員情報の閲覧範囲や、入社手続きの担当を確かめる。Strategy Opsなら課題を決める人と実行する人、完了条件を整理する。自分が選んだ業務の言葉を、一つずつ説明できるようにします。
練習物を見せる場合は「自主学習・架空データ」と明記し、実務の成果や採用試験の合格実績にはしません。勤務先の情報は、会社名だけ伏せても内容から特定できる場合があります。個人情報や非公開資料を持ち出さず、共有が許される材料だけを使ってください。
オペレーション職でよくある誤解
- Operationsなら、入力作業が中心?
- 職務ごとに違います。記録の整備に加えて問い合わせ・改善提案を担う職や、部門横断のプロジェクトを進める職があります。扱う対象と、自分で判断する範囲を読みましょう。
- 事務経験が長ければ、Seniorにも応募条件が合う?
- 在籍年数だけでは判断できません。プロジェクトを構想から実行まで進めたかなど、募集が求める経験の中身を確かめます。肩書きの対応関係は会社によって異なります。
- 英語を学べば、業務やツールの不足も埋まる?
- 英語で伝える力、業務を判断する知識、ツールを操作する経験は分けて準備します。英語で状況を説明できても、その変更を承認する権限があるとは限りません。
- 保留を減らすため、分かる範囲で更新してよい?
- 推測で更新すると、誤った情報が別の担当や集計へ渡ることがあります。会社のルールに従い、不明点や権限外の処理は確認先と次の行動を残します。緊急時も、誰が判断するかを確かめます。
まずは気になる業務を一つ選ぶ
最初の一歩は、職種名を決め切ることよりも、気になる職務説明を一つ選び「誰の、どんな作業を支えるか」を書くことです。営業の記録、人事の手続き、部門横断の改善では、使う知識も確認相手も変わります。
選んだ業務と自分の経験を準備シートへ記入し、次に6件の練習で確認・保留・引き継ぎを試してください。うまく説明できなかった箇所が、英語なのか、ツールなのか、業務の判断なのか分かると、追加学習の目的が具体的になります。
英語やIT・AIの学習を相談するときも、気になる職務と作った練習物を持っていくと、何を学びたいか伝えやすくなります。Kredoの学習内容や相談窓口は公式サイトで確認できます。希望する職種の紹介、採用、就労資格の取得を約束するものではありません。
英語でIT・AIを学べるKredo
英語×IT・AIのスキルを身につけてグローバルに活躍しませんか?
当メディアを運営しているKredoは、英語×ITをオンラインで学ぶ「Kredoオンラインキャンプ」と、フィリピンのセブ島で英語とIT・AIを学ぶ「KredoIT留学」「KredoAI留学」を提供しています。これまでの卒業生は3,000名以上。卒業生の多くが、国内外のIT企業への転職、フリーランスなどへのキャリアチェンジを実現しています。これからの時代に必要な英語×IT・AIのスキルを身につけてグローバルに活躍しませんか?









