エンジニアのジョブディスクリプションを読むときは、技術名に加えて、何を担当し、どこまで判断し、何ができたら期待に応えたことになるのかを確認しましょう。書かれている内容と、自分の推測を分けることが出発点です。
この記事では、応募先の職務記述を読み解くための判断表と、記述が曖昧なときの確認方法を紹介します。表や記載例は応募検討のための整理案であり、特定企業の採用基準ではありません。
ジョブディスクリプションとは
ジョブディスクリプション（JD・職務記述書）は、役割の目的や主要な職責を示す文書です。英国の専門職団体CIIは、職務の目的・責任を記すjob descriptionと、その遂行に必要な知識・スキル・経験などを記すperson specificationを区別しています。CII「Designing a role」
この区別を使い、まず「入社後にする仕事」と「応募者に求める経験」を別々に拾ってください。「データベースの利用経験」は要件の情報ですが、それだけで入社後にデータベース設計を任されるとは判断しないようにします。
エンジニアの実例として、GitLabのBackend Engineeringの公開資料には、要件と責任が別の項目で示されています。責任には機能開発だけでなく、他職種との協働、コードレビュー、技術的負債への対応も含まれています。これは同社の職務の例であり、すべてのバックエンド職に当てはめるものではありません。GitLab「Backend Engineering」
職務記述を六つの観点に分ける
読む際は、該当する原文を残したうえで、次の表に沿って整理する方法を勧めます。項目が見当たらなければ「記載なし」とし、都合のよい解釈で埋めないでください。
| 観点 | 拾う記述 | 判断すること・不足時の確認 |
|---|---|---|
| 役割の目的 | どの製品・業務の何を改善するか | 自分が取り組みたい課題と接点があるか |
| 担当範囲 | 設計、実装、テスト、運用などの行動 | 主担当の工程と、支援だけの工程はどこか |
| 判断と責任 | 提案する、決定する、承認する、支援する | 自分で決める範囲と承認を受ける範囲はどこか |
| 期待成果 | 成果物、達成したい状態、確認基準 | 何をもって完了・達成とするか |
| 連携相手 | 他のエンジニア、企画、利用部門など | 誰から依頼を受け、誰へ引き渡すか |
| 必要な経験 | 必須・歓迎、実務経験、学習経験 | どの仕事を行うための要件か |
特に「担当する」と「判断する」は分けて確認します。たとえば「設計に参加する」という文から、設計方針の最終決定権まで持つとは読み取らず、レビューへの参加なのか、設計案の作成なのかを確かめましょう。
期待成果については、作業・成果物・達成状態を分けると確認点が見つかります。「監視設定を見直す」は作業、「更新した監視設定と手順書」は成果物、「必要な異常を検知し、対応担当へ通知できる」は達成状態の例です。これらは説明用の整理であり、求人に書かれていない成果を応募者側で確定するものではありません。
曖昧な一文から、分かることと分からないことを分ける
次の文は、読み方を説明するために作成した架空の職務記述です。
業務システムのAPI開発・運用を担当し、関係部門と連携して性能改善を進める。
ここから拾えるのは、対象が業務システムであること、APIの開発と運用が含まれること、性能改善と部門間の連携が求められることです。設計の決定権、夜間対応、改善目標の数値までは書かれていません。
| 原文 | 読み取れる範囲 | 追加で確認すること |
|---|---|---|
| API開発・運用 | 開発と運用の双方に関わる | 設計、実装、リリース、障害対応のうち主担当はどこか |
| 関係部門と連携 | 他部門とのやり取りがある | 相手の部門と、要求・優先度を決める人は誰か |
| 性能改善を進める | 改善が職務に含まれる | 対象指標、現状、目標、達成を確認する人は誰か |
この場合は「性能改善の経験が積めそう」という仮説と、「性能改善が職務に含まれる」という記載事実を分けて持ちます。計測や原因調査を担当したいなら、それを自分で行うのか、別チームの分析結果を受けて実装するのかが確認点です。
「運用」という単語だけで夜間当番の有無を決めず、対応時間帯と担当分担も確認してください。自分にとって応募判断を左右する項目ほど、未確認のまま残さないようにします。
必須・歓迎要件を、自分の経験と照合する
必要な経験を読むときは、使える技術の数を数えるより、職務との対応を整理しましょう。次の三つに分けてメモする方法が使えます。
- 実務で担当した：対象、担当工程、自分の判断、説明できる成果を書く。
- 一部だけ経験した：チームの担当範囲と自分の担当を分け、不足部分を書く。
- 未経験・学習中：実務経験と区別し、取り組んだ範囲を書く。
たとえば「性能改善の実務経験」に対して、監視ツールを使った経験だけを同じものとして扱わず、計測・分析・修正・検証のどこを担当したかを書き出します。必須と明記された経験が足りない場合は、応募要項を確認し、代替経験を相談できるかを問い合わせる方法があります。歓迎要件も含め、自己判断で条件を読み替えないようにしましょう。
経験の棚卸しを応募書類へ移す段階では、エンジニアの職務経歴書の書き方を参照してください。本記事の表には、まず応募先の記述と自分の経験の対応だけを残せば十分です。
応募判断に使うメモを作る
最後に、応募先ごとに「希望と合う仕事」「説明できる経験」「判断に必要な未確認点」をまとめます。未確認点は数を増やすより、自分の選択が変わるものを優先しましょう。
たとえば設計を主担当にしたい人なら、「設計に関与」とあるだけでは判断を保留し、設計案の作成や方針決定の分担を確認します。運用改善を続けたい人なら、初期構築後も改善を担当するのかが確認点になります。
質問は原文を添えて、「『API開発・運用』について、最初に任される工程と、完了を確認する方を教えてください」のように具体化できます。聞き方を整理したい場合は、エンジニア面接の逆質問も参考にしてください。
テクノヴァースへの応募を検討する方は、採用情報を起点に募集内容をご確認ください。職務記述の一文を、担当範囲・期待成果・未確認点に分け、自分が次に担いたい仕事と照合してみましょう。