# 求人の職種名と記載された仕事内容が合うかを確認する

職種名と実際の担当業務が異なる可能性を見つけるには、求人情報に記載された業務を表に整理します。成果物、繰り返す作業、判断事項、業務を確認する人を一覧にします。その表を、自分が希望する仕事と比べます。情報が足りない点は、判断する前に採用企業へ確認しましょう。不一致は質問する理由になります。ただし、採用企業がうそをついた証拠にはなりません。

まず、公開されている求人情報の全文を用意します。1件の求人なら、手作業で確認できます。データ収集ツールを使うと複数の求人情報を保存しやすくなりますが、担当業務を読み、不明な責任事項を質問する作業は必要です。

この方法で作るのは、業務範囲表と質問票です。業務範囲表とは、その職務が担当する業務と、責任がまだ明確でない点を示す表です。

## 1. 希望する業務を明確にする

職種名を詳しく見る前に、自分が希望する仕事を短く書き出します。やりたい業務、自分で判断したい事項、入社を承諾する前に理解しておきたい責任を挙げましょう。

たとえば、分析の仕事を希望する人は、データを調べ、調査結果を説明し、報告書を作りたいと考えているかもしれません。その場合、会計処理の準備や最終承認も担当業務に含まれるか、確認が必要になることがあります。これは本人の希望を明らかにするための記述です。すべてのアナリスト職がどうあるべきかを定めるルールではありません。

次の2つの問いを分けて考えます。

1. 記載された業務は、自分が希望する仕事と合っているか。
2. その業務ができることを、根拠を示して説明できるか。

このガイドは、1つ目の問いを扱います。2つ目の問いには、別の[求人と自分の実績を比較するガイド](/ja/articles/%E6%B1%82%E4%BA%BA-%E3%82%B9%E3%82%AD%E3%83%AB%E7%85%A7%E5%90%88-%E5%80%99%E8%A3%9C%E3%81%AE%E7%B5%9E%E3%82%8A%E8%BE%BC%E3%81%BF/)を使ってください。自分の能力の評価は、業務範囲表に入れません。ある業務をこなせるとしても、それを主な責任として引き受けたくないと判断することはあります。

この懸念を述べた[公開の体験談があります。2026年10月25日閲覧。本人の経験の報告であり、採用企業について確認された事実ではありません](https://www.reddit.com/r/antiwork/comments/1tnzk1t/new_data_analyst_job_is_turning_into_replacing_a/)。投稿者によると、データアナリストの仕事は、ダッシュボード、レポート作成、データ基盤、業務プロセスの改善を扱うものとして説明されていました。その後、投稿者は実際の仕事が説明と異なるのではないかと疑問を持ちました。この体験談は、何を確認すべきかを考える手がかりになります。ただし、採用企業が何を要求したかや、この問題がどの程度起きるかを示すものではありません。

## 2. 職種名と担当業務の全文を保存する

職務を分類する前に、求人情報の全文を読みます。検索結果や短い抜粋では、担当業務、報告先、責任に付く条件が省かれていることがあります。

原文は書き換えずに保存します。自分の解釈は別の列に記入します。こうすると、懸念が採用企業の記述に基づくものか、自分の読み取り方から生じたものかを確認できます。

求人が1件なら、本文を手作業でコピーし、公開URLと閲覧日を添えることで、この方法を実施できます。収集したレコードを使う場合は、出力仕様に定義された次のフィールドを残します。

| フィールド | 保存して確認する内容 |
| --- | --- |
| `jobId` | 収集元で使われている求人の識別子。文字列のまま保存します。 |
| `jobUrl` | 公開求人ページのURL。提供されている場合に保存します。 |
| `title` | 記載された職種名。変更せずに保存します。 |
| `companyName` | 記載された採用企業名。提供されている場合に保存します。 |
| `locationRaw` | 収集元に記載された勤務地の表記。 |
| `descriptionText` | 業務範囲表の根拠となる、保存済みの求人本文。 |
| `descriptionStatus` | 求人本文を取得できたかどうかについて、提供された情報。本文と併せて確認します。 |
| `scrapedAt` | レコードを収集した時刻。採用企業による確認を示すものではありません。 |

フィールドとは、レコード内の名前付きの項目です。レコードとは、保存された1件の求人情報です。仕様に定義されたフィールドでも、値が欠けていることがあります。企業名が欠けている場合、そのレコードでは企業名が不明という意味です。求人本文が欠けていても、その仕事に担当業務がないという意味ではありません。

保存した本文が、対象の求人のものか確認します。職種名、採用企業、識別子、収集元のリンクを併せて読みます。本文がない場合や不完全な場合は、業務範囲表に「未完成」と記入します。記載されていない業務を、その仕事には存在しないと推測してはいけません。

## 3. 役立つ場合に限り、小規模に収集する

公開求人のレコードを集める選択肢が、[LinkedIn Jobs Scraper Actor](https://apify.com/chronometrica/linkedin-jobs-scraper)です。Actorとは、データを収集するためにサーバー上で動くプログラムです。文書に記載されたフィールドを使って、職種名と求人本文を保存し、手作業で確認できます。

Taskとは、Actorの入力設定を保存したものです。公開されている[LinkedIn Job Description Skills Demand Dataset Task（2026年10月25日確認。ページの存在のみ確認）](https://apify.com/chronometrica/linkedin-jobs-scraper/examples/linkedin-skills-demand)を出発点にできます。現在保存されている設定や、実行時の動作は確認していません。以下は、小規模な収集のための入力案です。確認済みのTaskの保存設定をコピーしたものではなく、このガイドのために実行したものでもありません。

```json
{
  "fetchJobDetails": true,
  "location": "United States",
  "maxItems": 3,
  "maxPagesPerSearch": 1,
  "saveOnlyUniqueItems": true,
  "searchTerm": "data analyst"
}
```

3. 役立つ場合に限り、小規模に収集する

`searchTerm`の値を、希望する職種に置き換えます。`location`の値を、希望する国や地域に置き換えます。最初の確認では、小さい上限値を維持してください。

`fetchJobDetails`は求人の詳細情報を要求します。`maxItems`は収集件数の上限を3件に設定します。`maxPagesPerSearch`はページ数の上限を1ページに設定します。`saveOnlyUniqueItems`は重複のない項目を要求します。これらは、提案した収集の範囲を制限する設定です。利用できる求人本文が3件得られることや、すべての求人を網羅できることを保証するものではありません。

[2026年10月25日に確認した公開デフォルトビルド（フィールド定義と静的検証のみ確認）](https://api.apify.com/v2/acts/kkH2KvT3IfbFf6A6P/builds/default)は、ビルド0.2.26でした。ビルドとは、プログラムの特定の版です。このビルドには、上記の入力フィールドと、保存対象の出力フィールドが定義されていました。入力案は、スキーマの静的チェックに合格しました。スキーマとは、データのフィールドに関する規則です。静的チェックでは、求人を収集せずに、入力をその規則と照合します。

この記事の作成では、実際のデータ収集を行っていません。このチェックは、データが取得可能であること、収集が成功すること、本文が完全であることを証明しません。収集に失敗した場合、結果は不明です。失敗した収集を「求人0件」と報告してはいけません。件数の上限に達した場合も、保存された求人が取得可能な求人のすべてだと扱ってはいけません。

この方法では、公開されている求人情報を使います。非公開の応募記録、受信メッセージ、社内の作業指示は、別の証拠です。自分の応募や面接の過程で得た回答は、公開求人の本文と分けて保存します。

## 4. 成果物、作業、判断事項を表にする

成果物とは、担当者が作成または完了しなければならない結果です。たとえば、ダッシュボード、月次報告書、完了した点検などがあります。定期作業とは、決まった予定に沿って繰り返す業務です。権限とは、判断や業務の承認を行うことが認められている範囲です。

各業務を読み、次の点を確認します。

1. 担当者は何を作成または完了する必要があるか。
2. どの業務を繰り返す必要があるか。
3. どのような判断をする必要があるか。
4. 誰が業務の結果を確認するか。
5. 誰が最終承認を行うか。

確認と承認は、異なる責任です。確認担当者は、業務の結果を点検します。最終承認者は、その結果を受け入れるか、公開・提供してよいかを決めます。サインオフとは、この最終承認を指します。報告書を作成する担当者に、その承認権限もあるとは限りません。

業務範囲の項目ごとに、表の1行を使います。業務範囲の項目とは、個別に説明が必要な1つの責任です。密接に関連した記述は、分けると意味が変わる場合、そのまままとめて扱います。

収集元のレコードに対応させて、次の項目を手作業で記入し、保存します。

| 業務範囲表の項目 | 記入する内容 |
| --- | --- |
| 根拠となる原文 | その行の根拠となる記述を、そのまま記入します。 |
| 成果物 | 成果物を記入します。記載がなければ「記載なし」とします。 |
| 定期作業 | 繰り返す業務と、記載されている実施時期や頻度。 |
| 業務の分類 | レポート作成、会計処理の準備など、業務を平易な言葉で記入します。 |
| 担当責任 | 誰が業務を完了する責任を持つか。記載がある場合に記入します。 |
| 権限 | その職務でどの判断を行えるか。記載がある場合に記入します。 |
| 確認担当者と最終承認者 | 誰が確認し、誰が承認するかを分けて記入します。 |
| 時間配分 | 記載された時間数や時間の割合。記載がなければ「不明」とします。 |
| 希望する仕事との比較 | その責任が、自分の希望する業務とどう関係するか。 |
| 未解決の質問 | 判断を変える可能性がある、まだ分かっていない事実。 |
| 根拠の区分 | 公開情報の記述、自分の解釈、採用企業からの回答のいずれか。 |

業務は、その内容に基づいて分類します。ソフトウェア名だけで分類してはいけません。同じツールを使う2つの業務でも、求められる責任は大きく異なることがあります。

ある業務から学びたいことが見つかった場合も、それは別の判断として扱います。学ぶ内容の選び方は、[スキルの学習計画を作るガイド](/ja/articles/%E6%B1%82%E4%BA%BA%E7%A5%A8%E3%81%8B%E3%82%89%E4%BD%9C%E3%82%8B%E3%82%B9%E3%82%AD%E3%83%AB%E5%AD%A6%E7%BF%92%E8%A8%88%E7%94%BB/)で扱っています。ここでは、何を学ぶかを決める前に、その職務が何を担当するのかを明らかにします。

## 5. 責任の範囲が不明な点を見つける

誰が責任を持つのかが曖昧な表現を探します。「支援する」「管理する」「対応する」などの言葉は、前後の説明が必要です。これらの表現だけでは、誰が準備し、誰が判断し、誰が結果を承認するのかが分からない場合があります。

回答を得ていない点は、それぞれ明記します。記述がない場合は「この求人情報には記載なし」とします。記述はあっても責任が定まらない場合は「不明確」とします。どちらも、採用企業に手順がないという意味ではありません。

次の責任の範囲を確認します。

1. この職務は成果物を作成するのか、それとも別の担当者による作成を支援するのか。
2. この職務は情報を準備するのか、それとも最終判断を行うのか。
3. 公開・提供の前に、別の担当者が内容を確認するのか。
4. 複数の業務が競合したとき、誰が優先順位を決めるのか。
5. 業務がその職務の権限を超えたとき、誰が支援するのか。
6. 報告先について何が記載され、何がまだ不明なのか。

職種名も見えるように残します。ただし、各懸念は担当業務や未回答の質問に基づいて記入します。「職種名はアナリストとなっている」よりも、「求人情報では報告書の最終承認を担当するが、承認権限の範囲が不明確だ」のほうが、確認に役立ちます。

担当業務の一覧が長くても、時間配分は分かりません。短い1文が、週の大半を使う業務を表していることもあります。長い文がいくつかあっても、たまに行う作業の説明かもしれません。業務範囲の項目数は、あくまで項目数として数えます。

## 6. 架空の例で手順を確認する

独自に作成した架空の例です。Actorの実行結果、顧客の成果、実際の企業についての調査結果ではありません。以下の職務、記述、読者の希望は、説明のために作ったものです。

架空の職種名は「データアナリスト」です。架空の求人情報には、次のように書かれています。

### 6. 架空の例で手順を確認する

ダッシュボードを作成し、月次の会計照合を完了し、報告書の最終承認に対応する。

ダッシュボードとは、選んだ情報をまとめて表示するものです。会計照合とは、関連する会計記録や合計額を比較し、一致しているかを確認する作業です。「報告書の最終承認に対応する」という表現では、本人が報告書を承認するのか、別の担当者の承認に向けて準備するのかが明確ではありません。

この架空の読者は、分析の仕事を希望しています。採用企業からの説明は、まだ受けていません。

| 業務範囲の項目 | 記載された業務 | 記載から分かること | 未解決の点 |
| --- | --- | --- | --- |
| ダッシュボード | ダッシュボードを作成する | この職務が成果物を作成する。 | 実施時期や頻度、利用者、確認担当者、優先順位。 |
| 月次の会計照合 | 会計記録を照合する | この作業を毎月繰り返す。 | 誰が会計上の判断を行い、誰が差異を確認するか。 |
| 報告書の最終承認 | 承認手続きに関わる | 求人情報は、承認に関係する責任を割り当てている。 | 本人が承認するのか、承認に向けて準備するのか。また、その権限の範囲。 |

業務範囲表には、3つの項目があります。

ダッシュボード1項目 + 会計処理の準備1項目 + 承認1項目 = 業務範囲の3項目。

ここで数えている単位は、業務範囲の項目です。週当たりの時間数、人数、週の勤務時間に占める割合ではありません。3項目あるからといって、仕事が均等に分かれるわけではありません。求人情報には時間数がないため、時間配分は不明のままです。

「月次」という言葉から、会計作業を毎月繰り返すことは分かります。ただし、毎月その作業に何時間かかるかは分かりません。時間数が不明であることは、0時間という意味ではありません。

これで、読者は懸念を具体的に書けます。ダッシュボードの業務は希望する分析業務に関係しています。一方、会計処理の準備と承認の責任については説明が必要です。ソフトウェア名が一致していても、これらの責任は明確になりません。

この例からは、職務の組み立て方について質問する根拠が得られます。ただし、採用企業が偽りの職種名を使った、または応募者を誤解させようとしたと判断する根拠にはなりません。

## 7. 各不明点を質問に変える

業務範囲表の不明点を解消できる質問をします。職種名が「正確か」と聞くのではなく、各質問を記載された業務に結び付けます。

架空の例には、次の質問票を使えます。

| 不明点 | 確認する質問 | 判断に必要な回答 |
| --- | --- | --- |
| 時間配分 | 通常の月では、ダッシュボード業務、会計処理の準備、承認業務に、それぞれどの程度の時間を使いますか。 | 具体的な配分、または配分が変動することについての明確な説明。 |
| 会計上の判断 | 会計上の差異をどう解消するかは、誰が決めますか。 | 責任を持つ職務と、この仕事が担当する範囲。 |
| 確認 | 月次の照合結果を使う前に、誰が確認しますか。 | 確認の責任を持つ担当者。 |
| 最終承認 | この職務は最終承認を行いますか。それとも、別の担当者が承認するための報告書を準備しますか。 | 準備と承認の明確な分担。 |
| 優先順位 | ダッシュボード業務と月次の会計業務の締め切りが重なった場合、誰が優先順位を決めますか。 | 判断する責任者と、想定される優先順。 |
| 成果の評価 | どのような成果物があれば、この担当者は仕事を適切に行っていると評価されますか。 | 実際の担当業務に結び付いた評価基準。 |

採用企業が所要時間の見積もりを示した場合は、単位も保存します。週当たりの時間数と、月当たりの時間数は異なります。通常の月の時間配分と、報告業務が忙しい時期の配分も異なる可能性があります。「通常」「最大」「月末の期間中」などの条件を残してください。見積もりを、確定した約束に変えてはいけません。

自分の応募や面接の過程で、詳しい説明を求めてください。この記事が質問を送ることはありません。また、採用企業がどのように答えるかを示すものでもありません。回答が届くまでは、その項目を未解決のままにします。

## 8. 業務範囲表を確認し、次の判断をする

業務範囲表を使う前に、全体を確認します。各解釈には、原文の記述か、回答であることを明記した情報が必要です。

1. 求人本文が対象の求人のものか確認します。
2. 表に整理した各業務に、根拠となる記述があるか確認します。
3. 作成、確認、最終承認を分けます。
4. 記載のない詳細と、明記された責任の範囲を区別します。
5. すべての時間数に、単位と元の条件が付いているか確認します。
6. 業務の数から推測した時間配分を取り除きます。
7. 採用企業からの回答と、自分の解釈を分けます。

採用企業からの回答で確認できるのは、その担当者が何を述べたかです。実際の毎週の働き方を証明するものではありません。誰が回答したか、いつ受け取ったか、どの質問への回答かを保存します。

根拠に基づいて、次の行動を決めます。記載された責任が希望する業務と合う場合は、その理由を記録します。判断に影響する重要な責任がまだ不明なら、引き続き説明を求めます。確認できた責任が希望する業務と合わない場合は、その不一致を、応募や入社を再検討する理由として記録します。

判断に必要な情報が足りない状態を、明記したままにします。本文が欠けていれば、完全な求人情報が必要です。承認に関する表現が不明確なら、権限について質問する必要があります。時間配分が不明なら、業務量について質問する必要があります。未回答の質問は、未回答のままです。だます意図があった証拠には変わりません。

## 1件の求人でこの方法を試す

検討中の求人を1件選びましょう。公開されている求人情報の全文を保存し、業務範囲表を作ります。判断に最も影響する、まだ説明を得ていない責任事項を特定します。職種名から結論を出す前に、その点を採用企業に確認しましょう。

公開求人情報の収集が役立つ場合は、上記の小規模な入力案を使って、[LinkedIn Jobs Scraper Actor](https://apify.com/chronometrica/linkedin-jobs-scraper)で収集できます。業務範囲表を作る前に、返された本文を確認してください。次の判断は、記載された業務、得られた回答、そして残っている不明点に基づいて行いましょう。

## 出典と参考資料

- [元の公開体験談。2026年10月25日閲覧。職務についての懸念を述べたものであり、採用企業について確認された事実や、発生頻度の証拠ではありません。](https://www.reddit.com/r/antiwork/comments/1tnzk1t/new_data_analyst_job_is_turning_into_replacing_a/)
- [LinkedIn Jobs Scraperの公開デフォルトビルド0.2.26。2026年10月25日確認。フィールド定義と入力の静的チェックのみ確認。実際のデータ収集は行っていません。](https://api.apify.com/v2/acts/kkH2KvT3IfbFf6A6P/builds/default)
- [LinkedIn Job Description Skills Demand Dataset Task。2026年10月25日確認。ページと正確なTask IDの存在を確認。保存設定と実行時の動作は未確認です。](https://apify.com/chronometrica/linkedin-jobs-scraper/examples/linkedin-skills-demand)