# 求人票からスキルの学習計画を作る方法

少数の求人票を全文で読み、繰り返し求められる業務を見つけます。次に、1つのプロジェクトでそれらの業務ができることを示します。

この計画は、何を学ぶか決める必要がある人に向けたものです。スキルマトリクスと、優先順位をつけた学習計画を作ります。スキルマトリクスとは、スキル、業務、要件区分、証拠をまとめた表です。

Actorは、ホスティング環境で動くデータ収集プログラムです。Taskは、保存済みの入力設定です。[LinkedIn Jobs Actor](https://apify.com/chronometrica/linkedin-jobs-scraper)は、求人レコードを収集します。そのレコードを読んで計画を作るのは、あなたです。Actorはスキルを分類しません。あなたの能力を測定することも、計画を書くこともしません。

フィールドとは、名前がついた入力項目または出力項目です。行とは、収集した1件の求人レコードです。ビルド0.2.19は、2026年10月13日に検証しました。入力として`searchTerm`、`location`、`maxItems`、`maxPagesPerSearch`、`postedWithin`、`saveOnlyUniqueItems`、`fetchJobDetails`を受け付けます。

公開されている[スキル需要Task](https://apify.com/chronometrica/linkedin-jobs-scraper/examples/linkedin-skills-demand)は、入力設定の出発点にすぎません。分析まで自動で行われるわけではありません。

[卒業したばかりの人が、どのスキルを学ぶべきか質問しています](https://www.reddit.com/r/FresherTechJobsIndia/comments/1ncge8k/recent_data_science_graduate_seeking_advice/)。この質問は、学ぶ内容を選ぶ必要があることを示しています。この計画で面接に進めると証明するものではありません。求人市場の規模を測定するものでもありません。

## 1. 学習対象を決める条件を明記する

求人広告を収集する前に、4つの条件を書きます。求人広告とは、1件の求人の募集広告です。

職種を1つ指定します。職種とは、データアナリストなどの仕事の種類です。経験レベルを1つ指定します。未経験者向けとは、その職種に初めて就く人を対象とするものです。求人市場を1つ指定します。ここでいう求人市場とは、働きたい国や都市のことです。求人広告を読んだ日付も書きます。

これは、その条件に向けた学習計画です。全国的なスキル不足を証明するものではありません。面接の機会を約束するものでもありません。

経験豊富な人向けの求人と、初めてアナリスト職に就く人向けの求人を混ぜないでください。両方が必要なら、別々に調べます。2つの求人市場を1つの表に混ぜないでください。

この記事の後半で使う学習例は、独自に作った架空のものです。未経験者向けのデータアナリスト業務を扱います。求人市場は、Market Oneという架空の市場1つです。求人広告を読んだ日は、2026年10月13日という設定です。Actorを検証した日も同じ日付です。日付が一致していても、この例の求人を実際に収集したという意味ではありません。

## 2. 求人票を全文で収集する

スキルを分類する前に、各行を確認します。どの求人かを特定できることを確認します。全文があることを確認します。行数の上限に達したために収集が止まったのか、実行の失敗で止まったのかも確認します。

行数の上限とは、収集を依頼する最大行数です。実行が失敗した場合、求人数は不明です。実行の失敗を求人0件として扱わないでください。

保存済みTaskの入力設定は、出発点としてのみ使います。

```json
{"searchTerm": "data engineer\nsoftware engineer\nproduct manager", "startUrls": [], "saveOnlyUniqueItems": true}
```

2. 求人票を全文で収集する

その入力設定には、データエンジニア、ソフトウェアエンジニア、プロダクトマネージャーが混在しています。職種1つと求人市場1つの設定に置き換えてください。空の`startUrls`リストも、保存済みの入力設定の一部です。この方法では、前述の7つのフィールドを使います。

最初の小規模な確認では、次の値を入力します。

| フィールド | 値 |
| --- | --- |
| searchTerm | data analyst |
| location | 選んだ1つの求人市場 |
| postedWithin | any |
| maxItems | 3 |
| maxPagesPerSearch | 1 |
| saveOnlyUniqueItems | true |
| fetchJobDetails | true |

この確認で得るのは、求人票の文章のサンプルです。募集中の求人すべてではありません。採用企業の全数調査でもありません。

確認するすべての行に、次の出力フィールドを残します。

| フィールド | 格納される内容 |
| --- | --- |
| jobId | 収集元の求人を識別する情報 |
| title | 求人の職名 |
| companyName | 採用企業名 |
| locationRaw | 求人に記載された勤務地のテキスト |
| descriptionText | 求人票の本文 |
| descriptionStatus | 全文を取得できているかどうか |
| jobUrl | 収集元の求人へのリンク |
| query | その行の収集に使った検索語 |
| searchLocation | 検索対象にした求人市場 |
| scrapedAt | その行を収集した時刻 |

`descriptionStatus`には、判断に役立つ2つの値があります。`full`は、分類に十分な本文がそろっていることを意味します。`missing`は、全文を取得できていないことを意味します。状態がmissingの場合は、スキルを分類しないでください。その行は情報の欠損として数えます。

職名だけでは、業務がわからないことがあります。短い抜粋では、必須業務が見えなくなることがあります。また、歓迎スキルが必須に見えることもあります。`descriptionText`を読んでください。

任意のフィールドには、値がない場合があります。値がないことと、値が0であることは別です。`companyName`がなければ、採用企業は不明です。名前を作らないでください。`jobUrl`がない場合は、`jobId`でその求人を識別できるときだけ行を残します。

`jobId`を使って、同じ求人広告の重複を除きます。1件だけ残してください。同じ採用企業が掲載したという理由だけで、別々の2件の求人広告を除かないでください。各求人広告に採用企業の情報を残します。1社が多くの求人広告を出していると、あるスキルが実際より広く求められているように見えることがあります。

`query`と`searchLocation`を確認します。対象の職種と求人市場に一致しなければ、その行をこのグループから外します。`locationRaw`に別の求人市場が記載されている場合も、その求人広告を外します。Market Oneにも、実際に調べている求人市場にも混ぜないでください。

ビルド0.2.19の動作確認では、収集元の求人IDを3件収集しました。収集元URL、収集時刻、全文の`descriptionText`も収集しました。この動作確認では、別の職種と別の求人市場を使いました。収集は上限の3行に達しました。この3行は、その求人市場の全求人ではありません。この確認は、全文を収集できることを示します。データアナリスト業務のスキルを選ぶものではありません。後述する架空の集計を裏づけるものでもありません。

## 3. スキルごとに根拠を1行保存する

求人票を1件ずつ全文で読みます。スキルまたは業務ごとに、根拠を1行保存します。

求人、採用企業、出典の文をそのまま保存します。実際の`jobUrl`がある場合は、出典リンクも保存します。短いスキル名、要件区分、業務、注記を保存します。

要件区分とは、文を読んだ後につける分類です。使う分類は、次の4つだけです。

- 「必須」は、そのスキルが必要であると本文に明記されている場合です。
- 「歓迎」は、そのスキルを求めているものの、必須とは書かれていない場合です。
- 「背景情報」は、ツール名が書かれていても、応募者の能力を判断する条件にはなっていない場合です。
- 「判別不能」は、文面から区分を判断できない場合です。

「当社ではPythonを使っています」という文だけでは不十分です。この文だけを根拠に、Pythonを必須と分類しないでください。背景情報または判別不能に分類します。

原文を残してください。要件区分をつける前に、読みやすい文に書き換えないでください。

[単純な単語の出現回数](/ja/articles/%E6%B1%82%E4%BA%BA%E7%A5%A8-%E3%82%B9%E3%82%AD%E3%83%AB%E7%94%A8%E8%AA%9E-%E9%9B%86%E8%A8%88%E6%96%B9%E6%B3%95/)では、すべての言及を同じように扱います。要件区分を使うと、この誤りを防げます。歓迎スキルは必須スキルではありません。背景情報としての言及は、最初に学ぶ必要があるスキルを示すものではありません。

## 4. スキル一覧を小さく保つ

各スキルに、短いスキル名を1つ決めます。その名前の横に、原文の表現を残します。

SQLは、テーブルに問い合わせるための言語です。SQLとStructured Query Languageが本文で同じ言語を指している場合に限り、1つのスキル名にまとめます。

JavaとJavaScriptはまとめないでください。別の言語です。グラフ作成業務を、特定の製品名と一緒にまとめないでください。すべてのクラウドサービスを1つのスキルにまとめないでください。クラウドサービスとは、インターネット経由で利用するソフトウェアです。サービスが違えば、必要なスキルも異なることがあります。

同義語とは、同じスキルを表す別の言葉です。同義語にあたるかどうかは、手作業で判断します。2つの分類が食い違ったら、両方の注記を残します。この作業を自動スキル分類ツールが行ったと主張しないでください。このActorは、スキルを分類しません。

## 5. 求人広告数と採用企業数を別々に数える

求人広告数とは、そのスキルを該当する要件区分で記載した、重複のない求人広告の件数です。採用企業数とは、それを記載した、重複のない採用企業の数です。1社の求人広告3件に記載があれば、求人広告での言及は3件です。それでも、採用企業は1社です。

両方の数に、要件区分を添えて報告します。求人広告の総数には、全文があるものだけを使います。結果を顧客需要と呼ばないでください。全国的な割合や、採用の増加と呼ぶこともできません。この方法での検索は、すべての求人から無作為に抽出したサンプルではありません。

### 架空のサンプル

以下の表は、独自に作った架空のものです。数え方を学ぶための例です。Actorの出力ではありません。動作確認で収集した3行でもありません。

この架空の例には、分類できる求人広告が6件あります。掲載した採用企業は5社です。採用企業AがJ1とJ2を掲載しました。採用企業BがJ3を掲載しました。採用企業CがJ4を掲載しました。採用企業DがJ5を掲載しました。採用企業EがJ6を掲載しました。J1からJ7は、この学習例で使う名前です。収集元のIDではありません。この架空の例に出典URLはありません。実際の表では、`jobId`と`jobUrl`を保存してください。

収集した7行目のJ7には、`descriptionText`がありません。架空の設定上、その状態はmissingです。スキルは不明です。不明は0ではありません。J7はスキルの集計から外します。情報の欠損を明記してください。収集した7行のうち1行は分類できません。スキル集計に使う求人広告の総数は、7件ではなく6件です。

| 求人 | 採用企業 | 全文の有無 | SQL | 表計算 | Python | ダッシュボード製品 |
| --- | --- | --- | --- | --- | --- | --- |
| J1 | A | あり | 必須 | 必須 | 記載なし | 記載なし |
| J2 | A | あり | 必須 | 記載なし | 歓迎 | 記載なし |
| J3 | B | あり | 必須 | 必須 | 記載なし | 記載なし |
| J4 | C | あり | 必須 | 記載なし | 歓迎 | 記載なし |
| J5 | D | あり | 記載なし | 必須 | 記載なし | 記載なし |
| J6 | E | あり | 記載なし | 記載なし | 歓迎 | 背景情報 |
| J7 | 不明 | なし | 不明 | 不明 | 不明 | 不明 |

「記載なし」は、この架空の本文に書かれていないという意味です。採用企業の実際の業務で、そのスキルを使わないという意味ではありません。

| 求人 | 採用企業 | 架空の求人票にある文そのまま | スキル名 | 要件区分 | 業務 | 注記 |
| --- | --- | --- | --- | --- | --- | --- |
| J1 | A | SQLを使って売上テーブルの行を絞り込み、テーブルを結合できることが必須です。 | SQL | 必須 | テーブルの行の絞り込みとテーブルの結合 | 「必須です」は、必要条件であることを示します。 |
| J1 | A | 表計算ソフトを使って月次実績をグラフ化できることが必須です。 | 表計算 | 必須 | 月次実績のグラフ化 | 同じ求人広告にある2つ目の業務です。 |
| J2 | A | レポート作成にはSQLが必須です。 | SQL | 必須 | レポート用クエリの作成 | 本文に必須と書かれています。 |
| J2 | A | 追加の確認にPythonを使える方を歓迎します。 | Python | 歓迎 | 追加の確認 | 歓迎は必須ではありません。 |
| J3 | B | SQLと表計算ソフトを使って注文合計を照合できることが必須です。 | SQL | 必須 | 合計の照合 | 1つの文に2つのスキルが含まれることがあります。 |
| J3 | B | SQLと表計算ソフトを使って注文合計を照合できることが必須です。 | 表計算 | 必須 | 合計の照合 | 2つ目のスキルを除かないでください。 |
| J4 | C | SQLが必須です。 | SQL | 必須 | データへのクエリ実行 | 必須であることが単独で明記されています。 |
| J4 | C | Pythonを使える方を歓迎しますが、必須ではありません。 | Python | 歓迎 | 必須業務としての記載なし | 本文が、必須にはあたらないと明示しています。 |
| J5 | D | 表計算ソフトで表のデータを整え、グラフ化できることが必須です。 | 表計算 | 必須 | データの整備とグラフ化 | 本文にSQLはありません。追加しないでください。 |
| J6 | E | Pythonを使える方を歓迎します。 | Python | 歓迎 | 必須業務としての記載なし | 歓迎のみです。 |
| J6 | E | チームでは、社内向けグラフにダッシュボード製品を使っています。 | ダッシュボード製品 | 背景情報 | 応募者の能力を判断する条件ではない | 必須スキルに分類しないでください。 |
| J7 | 不明 | 求人票の本文がありません。 | なし | 不明 | 不明 | 情報の欠損です。スキル0件と入力しないでください。 |

| スキル | 要件区分 | 求人広告 | 全6件中の求人広告数 | 採用企業 | 全5社中の採用企業数 |
| --- | --- | --- | --- | --- | --- |
| SQL | 必須 | J1, J2, J3, J4 | 4 | A, B, C | 3 |
| 表計算 | 必須 | J1, J3, J5 | 3 | A, B, D | 3 |
| Python | 歓迎 | J2, J4, J6 | 3 | A, C, E | 3 |
| ダッシュボード製品 | 背景情報 | J6 | 1 | E | 1 |

SQLを必須としている求人広告は、6件中4件です。その求人広告の採用企業は、5社中3社のA、B、Cです。J1とJ2は、どちらも採用企業Aのものです。SQLの求人広告が4件目になると求人広告数は増えますが、採用企業数は増えません。

表計算業務を必須としている求人広告は、6件中3件です。その求人広告の採用企業は、5社中3社のA、B、Dです。採用企業Dは表計算を必須としていますが、SQLには言及していません。

Pythonを歓迎としている求人広告は、6件中3件です。その求人広告の採用企業は、5社中3社のA、C、Eです。この表では、Pythonは必須ではありません。

ダッシュボード製品は、J6にだけ背景情報として登場します。6件のどの求人広告も、それを必須とはしていません。この「該当なし」は、この6件の本文につけた分類の集計です。全国的な結果ではありません。J7は不明のままなので、この「該当なし」には含めません。

キーワードの出現件数で順位をつけると、4は3より多いため、SQLが1位になります。その次に、表計算とPythonが同順位になります。ダッシュボード製品も残るかもしれません。この順位は、適切な学習順序ではありません。

採用企業数で見ると、SQL、表計算、Pythonはいずれも三社で並びます。次に要件区分を使うと、Pythonは二つの必須スキルより後になります。ダッシュボード製品も学習一覧から外れます。SQLの求人広告が一件多いのは、採用企業Aを二回数えているためです。それを理由に、SQLだけを表計算業務より優先すべきではありません。

6件中4件を、ある国の全求人における割合に置き換えないでください。6件中4件という数が表すのは、この架空の求人群だけです。

## 6. すでにある証拠を記録する

履歴書にスキル名を書くだけでは証拠になりません。証拠とは、他の人が確認できる完成した成果物です。クエリも証拠になります。データを整えたテーブルも証拠になります。判断を文章で添えたグラフも証拠になります。

繰り返し求められる各業務について、「あり」「一部あり」「なし」を記録します。「あり」は、確認済みの証拠がある状態です。「一部あり」は、業務の一部は示せているものの、残りを示す証拠がない状態です。「なし」は、証拠を示せていない状態です。採用可能性の点数を作らないでください。面接に進めるかどうかを予測しないでください。

この架空の例では、学習者はSQLで基本的な行の絞り込みを書けます。行の絞り込みとは、一部の行を残し、他の行を除くことです。その証拠はあります。学習者には、完成した結合処理がありません。結合とは、共通のキーで2つのテーブルをつなぐことです。その証拠はありません。合計を照合したレポートもありません。照合とは、出力の合計が入力の合計と一致することを確かめる作業です。その証拠はありません。表計算ソフトで作ったグラフもありません。Pythonは歓迎の区分なので、最初に補う対象ではありません。

| 業務 | サンプルに含めた根拠 | この架空の例にある証拠 | 記録 |
| --- | --- | --- | --- |
| SQLでの行の絞り込み | SQLに関する求人広告で必須 | 基本的な行の絞り込みを書ける | あり |
| SQLでの結合 | J1に行の絞り込みと結合の記載があります。採用企業はAです。 | 完成した結合処理なし | なし |
| 合計の照合 | J3で必須の業務です。採用企業はBです。 | 合計を照合したレポートなし | なし |
| 表計算ソフトでのグラフ作成 | J1とJ5にグラフ作成業務の記載があります。採用企業はAとDです。 | 完成したグラフなし | なし |
| Python | 歓迎のみ | 最初に補う対象には選ばない | 後で学ぶ |
| ダッシュボード製品 | 背景情報のみ | 必須業務ではない | 除外 |

あるスキルを求める企業の広がりと、特定の業務を求める企業の広がりは別です。SQLスキルを求める採用企業は3社です。表計算スキルを求める採用企業も3社です。結合業務は、採用企業AのJ1に記載されています。照合業務は、採用企業BのJ3に記載されています。グラフ作成業務は、採用企業AとDのJ1とJ5に記載されています。これらの業務に関する明示的な根拠は、合わせて採用企業A、B、Dに及びます。採用企業Cには及びません。各業務がそれぞれ3社で求められているわけではありません。

行の絞り込みをさらに練習しても、すでにある証拠を繰り返すことになります。必須業務のうち証拠がないのは、結合、合計の照合、グラフ作成です。最初のプロジェクトでは、それらを補う必要があります。J2だけを根拠に、Pythonだけの計画にしないでください。

## 7. プロジェクトを1つ選ぶ

この架空の例では、SQLでの結合、照合、表計算ソフトでのグラフ作成を使います。これは、意図して選んだ組み合わせです。3つの業務は、1つのまとまった作業として実施できます。3つとも、必須とする本文の記載に結びついています。結合業務は、採用企業AのJ1に記載されています。照合業務は、採用企業BのJ3に記載されています。グラフ作成業務は、採用企業AとDのJ1とJ5に記載されています。これらの業務に関する明示的な根拠は、合わせて採用企業A、B、Dに及びます。採用企業Cには及びません。SQLスキルを求める採用企業は3社です。表計算スキルを求める採用企業も3社です。あるスキルを求める企業の広がりと、特定の業務を求める企業の広がりは別です。各業務がそれぞれ3社で求められているわけではありません。

役立つプロジェクトは、それらの業務ができる証拠を示します。ツールを長く列挙しても、役立つプロジェクトにはなりません。先に練習すべきスキルを明記します。まず、基本的な結合と、表計算ソフトでの合計を練習します。SQLと表計算の結果を説明できるまでは、Pythonを追加しないでください。

受け入れ確認とは、プロジェクトが完了したかを判断するためのテストです。以下の確認項目は計画であり、学習者の実測結果ではありません。この記事では、クエリを実行していません。以下の合計は、テストデータを手作業で確認したものです。

テストデータとは、テスト用に作った少数の架空の行です。入力行は変更せずに使います。

顧客の行：顧客IDは4つです。

| customer_id | customer_name |
| --- | --- |
| C1 | North Shop |
| C2 | East Shop |
| C3 | West Shop |
| C4 | South Shop |

注文の行：注文は10件です。

| order_id | customer_id | order_month | amount |
| --- | --- | --- | --- |
| O1 | C1 | January | 10 |
| O2 | C1 | January | 20 |
| O3 | C2 | January | 15 |
| O4 | C2 | February | 25 |
| O5 | C3 | February | 30 |
| O6 | C3 | February | 5 |
| O7 | C1 | February | 40 |
| O8 | CX | January | 12 |
| O9 | C2 | January | 8 |
| O10 | CX | February | 18 |

ここでは、2種類の数を分けて読み取ります。顧客テーブルには、C1、C2、C3、C4の4つのIDがあります。注文で使われている顧客キーは、C1、C2、C3、CXの4種類です。注文にあるキーのうち3つは、顧客テーブルにあるIDです。1つは顧客テーブルと一致しません。一致しないキーはCXです。C4には注文がありません。CXが示す事実と、C4が示す事実は別です。

目で確認すると、各顧客IDは1回ずつ登場します。顧客IDの重複件数の期待値は0です。各注文IDも1回ずつ登場します。これはテストデータを手作業で読んだ結果であり、クエリの実行結果ではありません。

すべての注文を月次テーブルに残した場合の、手計算による合計は次のとおりです。

- 一月の金額は10、20、15、12、8です。合計は65です。
- 二月の金額は25、30、5、40、18です。合計は118です。
- 月別の合計は65と118です。両方を足すと183です。
- 10件の注文金額も、合計は183です。
- CXの金額は12と18です。合計は30です。
- 顧客テーブルと一致する注文の金額は、183から30を引いた153です。

すべての注文を含む正しい月次テーブルには、1月が65、2月が118、総合計が183と表示されるはずです。グラフには、この2か月の金額を示します。この記事には、完成したグラフはありません。表計算ソフトで自分で作成します。

顧客テーブルと一致しない注文は、O8とO10です。どちらもCXを使っています。一致しないキーを調べるテストが正しければ、この2行が見つかるはずです。

この架空の例におけるプロジェクトの概要は、次のとおりです。

- 入力：上記の注文10行と顧客4行。
- 出力：月次売上テーブル、表計算ソフトで作ったグラフ、文章でまとめた2つの発見。
- 方法：注文と顧客をつなぎ、CXを識別し、月ごとにamountを合計します。
- 品質確認：入力値を手計算で合計し、183が月次テーブルの合計と一致することを確認します。
- 提示するもの：クエリのテキスト、グラフ、一致しないキー、限界を1つ。

このテストデータからは、2つのことがわかるはずです。1つ目は、CXが顧客テーブルになく、その金額が30であることです。2つ目は、C4に注文がないことです。これらは、期待される説明です。実行して得た結果ではありません。

月次テーブル用に計画したクエリのテキストです。この記事では実行していません。

```sql
SELECT o.order_month, SUM(o.amount) AS month_amount
FROM orders AS o
GROUP BY o.order_month
```

7. プロジェクトを1つ選ぶ

顧客テーブルと一致しない注文のキーを調べるために計画したクエリのテキストです。この記事では実行していません。

```sql
SELECT o.order_id, o.customer_id, o.amount
FROM orders AS o
LEFT JOIN customers AS c
  ON c.customer_id = o.customer_id
WHERE c.customer_id IS NULL
```

7. プロジェクトを1つ選ぶ

次の項目で受け入れ確認を行います。

1. 元の注文10行と顧客4行を変更せずに使っている。
2. 成果物で、注文が10件と報告されている。
3. 成果物で、顧客IDが4つと報告されている。
4. 成果物で、注文に含まれる顧客キーが重複を除いて4種類と報告されている。
5. その4つのキーを、顧客テーブルにある3つのIDと、一致しないキーCXとして明記している。
6. 注記でCXを説明し、C4と混同していない。
7. 手作業での確認により注文金額の合計が183とわかり、月次テーブルの合計も183になっている。
8. クエリのテキストとグラフの両方を示している。
9. 学習者が限界を1つ説明している。

明確な限界を1つ示せば十分です。例えば、月次合計には顧客テーブルと一致しない注文の30が含まれ、一致する注文だけの合計は153であることです。また、このプロジェクトではPythonの能力を証明できないことも、実際の限界です。3つ目は、架空の求人広告6件が全国的な結果にはならないことです。このうちどれか1つを示せば、最後の確認項目を満たせます。

## 8. 計画に順序をつける

作業を4つの部分に分けます。歓迎スキルから始めないでください。

第1段階は、先に行う練習です。このテストデータを使って、結合を1つ練習します。表計算ソフトでの合計を1つ練習します。

第2段階は、複数の業務を組み合わせたプロジェクトです。月次テーブルを作ります。グラフを作ります。2つの発見を文章にします。

第3段階は、レビューです。別の人が受け入れ確認の項目を使います。その人は、点数を信用する必要がありません。注文を10件、顧客IDを4つと数え、CXを見つけ、金額を足すことで確認できます。

第4段階は、説明です。一致しないキーを説明します。限界を1つ説明します。

この架空の例の優先順位は、簡潔にまとめられます。まず、結合、照合、グラフ作成を行います。これらは必須業務で、証拠がまだないためです。このプロジェクトは、意図して複数の業務を組み合わせています。業務に関する明示的な根拠は、採用企業A、B、Dに及びます。採用企業Cには及びません。各業務がそれぞれ3社で求められているわけではありません。SQLスキルを求める採用企業は3社です。表計算スキルを求める採用企業も3社です。あるスキルを求める企業の広がりと、特定の業務を求める企業の広がりは別です。次に、確認項目を使ってプロジェクトをレビューします。その成果を説明できるようになってから、Pythonを練習します。ダッシュボード製品は、スキルの学習計画から外します。

各作業に使う時間枠は、自分で決めます。時間枠とは、その作業に使うと決めた時間です。その時間でスキルを習得できると約束するものではありません。この架空の計画では、練習に1回、プロジェクトに1回、レビューと説明に1回、それぞれまとまった作業時間を取ります。

職種、経験レベル、求人市場を変える場合は、新しいサンプルを収集します。同じルールを使ってください。この架空の優先順位を、別の職種に使い回さないでください。

## 次にすること

自分で集めた全文のサンプルから、異なる採用企業が繰り返し必須としている業務を1つ選びます。その業務ができることを示すプロジェクトについて、受け入れ確認の項目を1つ書きます。他の人が確認できる入力件数を含めてください。[LinkedIn Jobs Actor](https://apify.com/chronometrica/linkedin-jobs-scraper)で求人票の本文を収集します。保存済みの[スキル需要Task](https://apify.com/chronometrica/linkedin-jobs-scraper/examples/linkedin-skills-demand)を出発点にします。混在している3つの職種を、職種1つと勤務地1つに置き換え、収集行数の上限は小さく保ちます。

## 出典と参考資料

- [LinkedIn Jobs Actor](https://apify.com/chronometrica/linkedin-jobs-scraper)
- [LinkedIn Job Description Skills Demand Dataset](https://apify.com/chronometrica/linkedin-jobs-scraper/examples/linkedin-skills-demand)
- [データサイエンスを専攻して卒業したばかりの人による相談](https://www.reddit.com/r/FresherTechJobsIndia/comments/1ncge8k/recent_data_science_graduate_seeking_advice/)