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

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

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

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

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

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

このガイドは、1つ目の問いを扱います。2つ目の問いには、別の求人と自分の実績を比較するガイドを使ってください。自分の能力の評価は、業務範囲表に入れません。ある業務をこなせるとしても、それを主な責任として引き受けたくないと判断することはあります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ある業務から学びたいことが見つかった場合も、それは別の判断として扱います。学ぶ内容の選び方は、スキルの学習計画を作るガイドで扱っています。ここでは、何を学ぶかを決める前に、その職務が何を担当するのかを明らかにします。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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