ジョブ記述のデコード
すべての職務記述書は、希望リストを装った交渉文書です。企業は、理想的な候補者、つまりすべての項目にチェックを入れるユニコーンを説明しますが、それらのほとんどにチェックを入れ、面接もうまくいった人を採用します。要件を 100% 満たしていないために求人情報をスキップしたことがある場合は、JD の見方が間違っています。このレッスンでは、企業が実際に必要としているものと企業が夢見ているものを解読する方法を学びます。
60-70% ルール
ヒューレット・パッカードの社内調査(後に LinkedIn によって広められた)によると、男性は資格の約 60% を満たしたときに仕事に応募するのに対し、女性は 100% を満たすまで待つ傾向があることがわかりました。現実には、記載されている要件の 60 ~ 70% を満たしていれば、ほとんどの企業が面接に応じてくれます。
なぜ?なぜなら:
- 職務記述書は委員会によって作成されます - 採用マネージャー、採用担当者、人事部の全員が項目を追加します
- 多くの「要件」は願望的なものであり、ストレッチゴールとして追加されています
- 企業は、すべての項目にチェックを入れている弱い候補者を採用するよりも、不足しているスキルを備えた強力な候補者を訓練したいと考えています。
💡職務内容が自分に 70% 当てはまると感じたら、応募してください。 50% があなたに似ていると感じ、その役割に心から興奮している場合は、とにかく応募し、採用担当者の判断に任せてください。資格のある候補者が機会を逃す最も一般的な理由は、自己選択です。
職務記述書の構造
どの JD にも予測可能なセクションがあります。それぞれの実際の意味は次のとおりです。
「会社概要」セクション
これは、企業の 物語、つまり企業がどのように認識されることを望んでいるのかを示します。探す:
- 段階的なヒント — 「急成長」、「シリーズ B」、「確立されたリーダー」は企業の成熟度を示しています
- ミッション言語 — 理想主義的な言語は、目的を重視する文化を示唆しています
- 技術シグナル — 特定のツールまたはプラットフォームについての言及はスタックを示唆しています
「これから行うこと」セクション
これは JD の最も正直な部分です。 実際の日常業務について説明します。
- 最初の 2 ~ 3 つの箇条書きが中心的な責任です。これが仕事の 80% です。
- 後の箇条書きは二次的または願望的なものです
- 動詞は重要です。「ビルド」はグリーンフィールドを意味します。 「維持」とは遺産を意味します。 「リード」とは経営陣の期待を意味します
「必要なもの」(要件)
ほとんどの候補者がつまずくのはここです。次のようにデコードします。
| JD言語 |それが本当に意味すること |
|---------------|----------|
| 「X年以上の経験」 |厳しい解雇ではなく、大まかな年功序列のシグナル |
| 「React のエキスパート」 | React の快適な建築制作機能 |
| 「分散システムの経験」 |水平方向に拡張するシステムを設計または開発したことがある |
| 「コミュニケーション能力が高い」 |技術者以外の関係者にプレゼンテーションを行います |
| 「セルフスターター」 |最低限の人手保持 — チームのリソースが不足している可能性がある |
| 「ペースの速い環境」 |厳しい締め切り、場合によっては無秩序な優先順位付け |
「あると便利」セクション
これらは本物のボーナスであり、要件ではありません。これらが 1 つまたは 2 つあるとアプリケーションは強力になりますが、すべてが欠けていても失格になるわけではありません。
🤯Textio による調査では、5,000 万件以上の求人情報を分析し、要件セクションに箇条書き項目が 15 個以上ある JD は応募が 30% 少ないことがわかりました。これは、資格のある人が少ないからではなく、応募者がその長さによって応募をしないように脅迫されているためです。
期待されるレベルの特定
JD は、肩書きではなく言葉の中に年功序列のシグナルを埋め込むことがよくあります。レベルをデコードする方法は次のとおりです。
ジュニア/エントリーレベルの信号
- 「学ぶことに熱心」、「指導を受けられる」、「チームとともに成長する」
- 0~2年の経験を記載
- 実行に重点を置く: 「機能の実装」、「テストの作成」、「バグの修正」
- アーキテクチャやリーダーシップをあまり重視しない
中間レベルのシグナル
- 「機能を独立して所有」、「チーム間で共同作業」
- 3~5年の経験
- いくつかの技術的な決定を下すことが予想される
- 若手エンジニアの指導について言及する場合があります
シニア/スタッフの合図
- 「技術的な方向性を推進する」、「アーキテクチャに影響を与える」、「チームを指導する」
- 5~8年以上の経験
- システム設計とトレードオフの議論が予想される
- チーム間の影響、利害関係者の管理
職務経歴書には「5年以上の経験」が条件として記載されています。 3 年間の強力で関連性のある経験をお持ちです。どうすればいいでしょうか?
職務記述書の危険信号
すべての求人情報に時間を割く価値があるわけではありません。次の警告サインに注意してください。
- 「多くの帽子をかぶる」 — 刺激的な幅広さを意味する場合もあれば、1 つの給料で 3 つの役割を望んでいることを意味する場合もあります
- 「ロックスター / 忍者 / 達人」 — 未熟な雇用文化。不適切なエンジニアリング慣行を示している可能性があります
- 「よく働き、よく遊ぶ」 — 時折ピザ パーティーをしながら、長時間コーディングすることがよくあります
- 曖昧な責任 — 実際の仕事が何であるかを伝えられない場合、チームも分からない可能性があります。
- 非現実的な技術スタック — 「React、Angular、Vue、Svelte、Python、Go、Rust、Kubernetes の専門家」 — 彼らは自分たちに何が必要かを分かっていない
- チームやマネージャーについては言及されていません — 誰と仕事をしますか?彼らが言わなければ、尋ねてください。
- 頻繁に再投稿 — 同じロールが 6 か月以上募集されている場合、保持の問題が発生する可能性があります。
🤔Think about it:最近応募を検討した仕事の内容を見てください。どの要件が真に必須であり、どの要件が願望的なものであるかを特定できますか? 60-70% の法則を知った上で、今すぐ応募しますか?
JD からのインタビューをリバースエンジニアリングする
JD は面接準備のためのカンニングペーパーです。使用方法は次のとおりです。
ステップ 1: コアとなる技術スキルを抽出する
言及されたすべてのテクノロジー、フレームワーク、コンセプトを強調表示します。これらは技術的な準備リストを形成します。
JD の抜粋: 「Java と Spring Boot を使用してスケーラブルなマイクロサービスを構築します。RESTful API を設計します。PostgreSQL と Redis を使用します。Kubernetes を使用して AWS にデプロイします。」
準備リスト: Java、Spring Boot、REST API 設計、PostgreSQL クエリの最適化、Redis キャッシュ パターン、AWS サービス (ECS/EKS)、Kubernetes の基本。
ステップ 2: システム設計テーマを特定する
「何をするか」セクションでは、システム設計で直面する可能性のある次のような質問が示されています。
- 「スケーラブルなサービスを構築する」 → 期待: 「1 秒あたり 10,000 のリクエストを処理するサービスを設計する」
- 「リアルタイム データ処理」 → 期待: 「リアルタイム分析パイプラインの設計」
- 「決済システム」 → 期待: 「冪等性を備えた決済処理サービスを設計する」
ステップ 3: 行動に関する質問を責任にマッピングする
あらゆる責任には行動上の疑問が伴います。
- 「5 人のエンジニアからなるチームを率いています」 → 「チーム内の対立を解決したときのことを教えてください」
- 「製品とデザインのコラボレーション」→「技術以外の関係者との意見の相違にどのように対処しますか?」
- 「システムの信頼性の向上」→「解決した本番環境のインシデントについて説明してください」
ステップ 4: ギャップを調査する
JD で不足しているスキルがある場合は、次のことを行うかどうかを決定します。
- 賢く議論できるよう十分に学習します (1 ~ 2 日間の学習)
- どのように立ち上げていくかについて、正直な答えを用意してください
- 明らかに「あると便利」な場合はスキップしてください
通常、職務記述書のどのセクションが、実際に日々行うことについて最も正直に記述されていますか?
実際のデコード例
以下は、「シニア バックエンド エンジニア」の役割の簡略化された JD です。
要件: 5 年以上のバックエンド経験、強力な Java または Kotlin、マイクロサービス アーキテクチャの経験、クラウド プラットフォームへの精通 (AWS が望ましい)、CI/CD パイプラインの理解、優れたコミュニケーション スキル。
あれば嬉しい: イベント駆動型アーキテクチャ (Kafka)、コンテナ オーケストレーション (Kubernetes)、可観測性ツール (Datadog/Grafana) の経験。
デコード済み:
- 主な仕事: AWS 上で Java/Kotlin マイクロサービスを構築および維持します。頻繁に出荷し (CI/CD について言及)、チーム間でコミュニケーションをとるチームで働くことになります。
- チームはおそらくすでに使用している: 非同期メッセージングには Kafka、デプロイメントには Kubernetes、モニタリングには Datadog または Grafana を使用しています。彼らは、代替手段を使用している候補者を怖がらせたくないだけです。
- 面接準備の焦点: Java コーディング、マイクロサービス設計パターン、AWS サービス、イベント駆動型アーキテクチャを含むシステム設計の質問、およびチーム間のコラボレーションに関する 3 ~ 4 つの行動のストーリー。
💡応募する仕事ごとに簡単なスプレッドシートを作成します。JD に必要なスキルを 1 列に、証拠/経験を次の列に、準備計画を 3 列にリストします。これは、アプリケーションごとにカスタマイズされた学習ガイドになります。
重要なポイント
- 60 ~ 70% の適合性で応募 — JD は、最低要件ではなく、理想的な候補者について説明します。
- 言語を解読する — 「自発的」とは自主性を意味し、「ペースが速い」とは締め切りが厳しいことを意味し、長年の経験は門ではなくガイドです。
- 「何をするか」セクションはあなたの親友です - 実際の仕事を明らかにし、面接の質問のヒントを提供します。
- 危険信号に注意 — 曖昧な責任、非現実的な技術スタック、および「ロックスター」のような言葉遣いは危険信号です。
- 準備をリバースエンジニアリング — スキルを抽出し、システム設計の質問を予測し、行動ストーリーを各 JD にマッピングします。
📚 続きを読む
- Textio Blog - 職務記述文が応募者にどのような影響を与えるかに関する研究
- 主要な値 - エンジニアリング文化の価値観で企業をフィルタリングします
- levels.fyi - 企業全体のレベルの期待と報酬を理解する