今日の文書 — 職務記述書（ジョブディスクリプション）
採用したいポジションの業務内容・必須スキル・歓迎スキルを定義し、社内の関係者（人事・面接官）と、最終的には候補者との間で「何を求めているか」の認識を揃えるための文書。求人票（人事#2、外部の転職媒体に掲載する広告としての文書）とは別物で、職務記述書は先に定義される「役割の設計図」であり、求人票はそれを候補者向けにマーケティング的に書き直したものという関係にある。
この文書の勝負どころ：必須と歓迎が区別され、実態と乖離していないか。
「なんでもできる人がほしい」という採用側の願望をそのまま要件に並べると、必須要件が肥大化し、本来なら応募してくれたはずの候補者が「自分は要件を満たしていない」と判断して離脱する。特にITエンジニア職は人材の需給が逼迫しており、要件の厳格さと応募数はトレードオフの関係にある。
「なんでもできる人がほしい」という採用側の願望をそのまま要件に並べると、必須要件が肥大化し、本来なら応募してくれたはずの候補者が「自分は要件を満たしていない」と判断して離脱する。特にITエンジニア職は人材の需給が逼迫しており、要件の厳格さと応募数はトレードオフの関係にある。
シナリオ
あなたは当社EC事業本部・販促システム部の MOpsチームマネージャー・宮田（Day004〜Day005の続き）。
2026年12月1日（火）、西村本部長（Day005の予算査定会議・11/27の経営企画会議を通過）から正式に、配信基盤刷新プロジェクト（Day004のRFI・Day005の予算計画書で扱った案件、2027年1月RFP発注予定）の実装・運用体制を強化するため、MOpsチームに新規ポジション「配信基盤エンジニア」を1名増員することが承認された。
宮田さんは12月2日（水）に職務記述書のドラフトを作成。12月3日（木）17時までに人事部の採用担当・中村さんへレビュー依頼し、12月4日（金）中にフィードバックをもらった上で、12月8日（月）に社内公募制度と提携転職エージェント2社経由での募集を開始したい。目標入社日は2027年2月1日（RFP発注と同時期に体制を立ち上げたい）。
- 提出先（直接の読み手）： 人事部 採用担当・中村さん。過去に技術職の求人票を10件ほど扱った経験があるが、うちクラウド・インフラ系は2件のみで、技術要件そのものの妥当性は判断できない
- 中村さんの役割： 差別的表現・法令面（労働施策総合推進法9条＝旧雇用対策法10条により、募集・採用における年齢制限は原則禁止）・給与レンジの社内整合性を確認し、掲載可否を判断する
- その先の読み手： レビューを通過すれば、そのまま社内公募の掲示、または中村さんがこれを基に外部向けの求人票（人事#2、別文書）を作成する際の元原稿になる
- 面倒な事情①： 配信基盤エンジニアという職種はIT人材の需給が逼迫しており、現場でも「要件を厳しくしすぎると応募が集まらない」という懸念が既にある
- 面倒な事情②： 宮田さんは技術要件をどこまで削ってよいか自信がなく、「念のため全部必須にしておく」という書き方に流れやすい状態にある
- 面倒な事情③： レビューから掲載希望日まで実質中1日しかなく、中村さんが差し戻しを出すと12/8掲載に間に合わない
つまり中村さんは、この職務記述書のまま社内公募・外部募集に出してよいかを、法令面・応募のしやすさ・給与の社内整合性の3点から判断する、掲載前の最後のチェックポイントである。
読み手プロファイル
| 項目 | 内容 |
|---|---|
| 誰が読むか | 人事部 採用担当・中村さん（1名、直接の読み手）。レビュー通過後は社内公募の閲覧者、および外部求人票を読む候補者（間接的な最終読み手） |
| 何を判断するために読むか | ①このまま12/8に社内公募・外部募集へ出してよいか ②修正が必要な場合、どこをどう直せば良いか |
| 何を知っているか | 西村本部長経由で、配信基盤刷新プロジェクトに予算がつき体制強化が必要になったという概要レベルの経緯 |
| 何を知らないか | 技術要件の意味・難易度差（AWS経験とTerraform経験のどちらがより重要か等）、配属後の実際の業務比率、必須要件をどこまで厳格にすべきかの技術的な妥当性 |
| 何を気にしているか | ① 差別的・排他的な表現が残っていないか（年齢・性別を示唆する表現を含む） ② 必須要件が厳しすぎて応募母集団が狭まらないか（人材が逼迫している職種であることを認識） ③ 給与レンジが既存メンバー・他部署の同職級とバランスが取れているか ④ 12/8掲載までの残り日数で確認しきれるボリュームか |
| 読む時間と場面 | 12/3(木)の夕方以降、他の求人票のレビューと合わせて15分程度。差し戻す場合は12/4(金)午前中には宮田さんに連絡する必要がある |
この読み手が変わると何が変わるか：
同じ職務記述書でも、読み手が候補者本人（他社オファーと比較検討中）であれば、要件の羅列より先に「このポジションで何が面白いか・裁量の大きさ」という動機づけが冒頭に来る。読み手が技術面接官（現場エンジニア）であれば、「クラウド運用経験」のような抽象的な括りではなく、実際に使う技術スタック（具体的なAWSサービス名・監視ツール名等）が先に来る。今回は掲載可否を法令・応募ハードル・給与整合性の観点から判断する中村さんが読み手なので、技術的な深さより「候補者に不利益・排他性がないか」「社内の他ポジションとの整合が取れているか」に紙面を使うのが正解。
4段階で見る — 「2. 必須要件・歓迎要件」
この文書の勝負どころそのものがこのセクションに集約されているため、他のセクション（業務内容・給与・選考プロセス等）よりも段階間の差が大きく出る。
Bad
必須6項目に「あれば尚可」
が混在し境界崩壊。「スピー
ド感についてこられる方」等
排他的表現、業務内容不明。Good
必須/歓迎を分離し主観表現
を削除。だが要件の理由なし、
年数が断定的、選考フロー
なし。Better
業務内容と要件の対応を明示。
年数は目安と明記。だが候補
者向け/中村さん向けが混在
し最長化。Best
候補者向け本文と人事レビュー
用メモを分離。分量はBetter
の約半分に減少。3点の確認
事項を独立提示。Bad
6 required items, "a plus"
mixed in. Exclusionary phrase
"keep up with our pace",
no context on the work.Good
Required/Preferred split,
subjective phrases removed.
No rationale, years stated
as hard cutoff, no process.Better
Maps work to requirements.
Years reframed as guideline.
But candidate/HR content
mixed - becomes longest.Best
Splits candidate text from
HR review note. Length cut
roughly in half vs Better.
3 review points made explicit.Bad — 妥協して雑に作った状態 ／ 約13行
2. 募集要件
【必須】
・IT関連の実務経験3年以上
・クラウド、インフラ、SQLの知識
・メール配信システムの経験があれば尚可
・コミュニケーション能力が高く、当社のスピード感についてこられる方
・チームプレーヤーであること
・何にでも前向きに取り組める方
【歓迎】
・AWS経験者
・大規模システム運用経験者Bad
2. Requirements
Required:
- 3+ years of IT experience
- Knowledge of cloud, infrastructure, and SQL
- Email delivery system experience a plus
- Strong communicator who can keep up with our fast pace
- Team player
- Willing to take on anything
Nice to have:
- AWS experience
- Large-scale systems experience英語だと法的リスクとしてより強く警戒される表現
日本語版と同じ問題（境界の崩壊・排他的表現）に加えて、"keep up with our fast pace" は米国の採用実務では年齢差別（ADEA: Age Discrimination in Employment Act, 1967年制定、40歳以上の労働者を保護）に抵触しうる典型的な言い回しとして、採用担当者向け研修で明示的に避けるよう教えられる表現の一つ。
Good — 型は満たしている ／ 約19行
2. 必須要件・歓迎要件
【必須要件】
・Webサービスのバックエンド開発、またはインフラ運用の実務経験3年以上
・AWS等パブリッククラウドでの運用経験
・SQLを用いたデータ抽出・分析の実務経験
・Linux環境でのサーバー運用経験
【歓迎要件】
・メール配信システム(ESP)の選定・移行プロジェクトの経験
・月間数百万通規模のメール配信基盤の運用経験
・Terraform等IaCツールの実務経験
想定年収: 600万〜850万円(経験・スキルに応じて決定)
面接では、上記の各経験について具体的な業務内容を伺います。Badから何が変わったか 動いた軸：③事実と解釈の分離
- ③ 必須要件と歓迎要件が明確に2つのリストに分離され、「〜あれば尚可」のような境界の崩れがなくなった
- ③ 主観的・排他的な表現（「スピード感についてこられる方」等）が削除され、行動・経験として検証可能な項目に置き換わった
- 想定年収がレンジで明記された
まだ足りないもの
- なぜこの4つの要件が必要なのかが、業務内容と結びついていない。中村さんはこの文書だけでは「本当に4つとも必須なのか」を判断できない
- 経験年数が「3年以上」と断定的に書かれており、目安なのか厳格な基準なのかが不明
- 選考プロセスの記載がない
- 給与レンジの根拠がない。中村さんが最も気にする「既存メンバーとのバランス」に答えていない
Goodの限界は「読めば分かる」が「読まないと分からない」こと。 中村さんはこの文書を読んでも、要件が本当に妥当か・応募のハードルが高すぎないかを、自分で他の求人票と比較して判断する作業が残っている。
Good
2. Requirements
Required:
- 3+ years of experience in backend development or infrastructure
operations
- Hands-on experience operating public cloud environments (e.g.,
AWS)
- Practical experience writing SQL for data extraction and
analysis
- Experience operating servers in a Linux environment
Nice to have:
- Experience selecting or migrating an email service provider
(ESP)
- Experience operating an email platform at a scale of several
million sends/month
- Hands-on experience with IaC tools such as Terraform
Target compensation: JPY 6.0M-8.5M, commensurate with experience"Nice to have" はフォーマル文書では弱い
"Nice to have" は口語的な響きが強く、社外向けの正式なJDでは "Preferred Qualifications" の方がフォーマルな型として好まれる。日本語版の「歓迎要件」は口語・正式のどちらにも使える中立語だが、英語はフォーマル度で語を使い分ける必要がある。
Better — 読み手に最適化されている ／ 約29行 ← 最長
2. 必須要件・歓迎要件
■ このポジションで実際に取り組んでいただくこと
既存メール配信基盤(1時間あたり処理上限80万通)のクラウド移行
プロジェクト(2027年1月RFP発注予定)を、外部ベンダーと共同で
進めます。以下の要件は、この業務を推進するために必要な範囲で
設定しています。
【必須要件】(年数は目安です。同等の経験があれば年数に満たなく
ても対象とします)
・バックエンド開発またはインフラ運用の実務経験 目安3年以上
→ベンダーとの技術要件のすり合わせ、既存システムとの接続部分
の実装で必要
・AWS、GCP等いずれかのパブリッククラウドでの運用経験
→移行先候補が現時点でAWSを軸に検討中のため。他クラウドの
経験でも応相談
・SQLを用いたデータ抽出・分析の実務経験
→配信実績データの分析、移行前後の処理能力比較で必要
【歓迎要件】(必須要件を満たしていれば、下記が未経験でも応募を
歓迎します)
・メール配信システム(ESP)の選定・移行プロジェクトの経験
・月間数百万通規模のメール配信基盤の運用経験
・Terraform等IaCツールの実務経験
想定年収: 600万〜850万円
※既存MOpsチームメンバー(平均680万円)との整合を確認済みです★ Goodから何が変わったか — ここが今日の学習の中心
読み手プロファイルの各項目に、変更を1対1で対応させている。
| 読み手プロファイルの項目 | Betterで行った変更 |
|---|---|
| 何を知らないか 「配属後の実際の業務比率」 | 「■このポジションで実際に取り組んでいただくこと」を新設し、具体的なプロジェクト内容と要件の対応関係を示した。中村さんが「なぜこの要件が必要か」を自分で推測しなくてよくなった |
| 何を気にしているか② 「必須要件が厳しすぎて応募母集団が狭まらないか」 | 「年数は目安です。同等の経験があれば年数に満たなくても対象とします」を明記。さらに必須要件を4→3項目に絞り込んだ |
| 何を気にしているか① 「排他的な表現が残っていないか」 | クラウドの種類を「AWS等」から「AWS、GCP等いずれか」に広げ、「他クラウドの経験でも応相談」を追記 |
| 何を気にしているか③ 「給与レンジの根拠」 | 「既存MOpsチームメンバー(平均680万円)との整合を確認済み」を追加し、中村さんが給与テーブルと突き合わせる作業を省いた |
特に重要な1つの動き
各必須要件に「→なぜ必要か」を1行添えたことで、要件の妥当性そのものを中村さんが検証できる状態になった。 Goodまでは要件が並んでいるだけだったが、Betterでは業務内容との因果関係が文書自体に書き込まれている。
ただし副作用がある：候補者向けの文言（要件そのもの）と、中村さん向けの説明（なぜ必要か・応相談等）が同じ文章の中に混在しており、候補者がこの職務記述書をそのまま読んだ場合、必須要件を読むのに余分な情報を読まされることになる。読み手ごとに知りたい粒度が違うのに1つの文章で両方に応えようとした結果、分量が最も長くなった。
Better
2. Requirements
WHAT YOU WILL ACTUALLY DO: You'll help migrate our current email
delivery platform (current peak: 800K emails/hour) to the cloud,
working jointly with an external vendor, with RFP issuance targeted
for January 2027. The requirements below reflect what's needed to
drive that work, not to do it alone.
REQUIRED (years are a guideline; equivalent experience counts even
short of the stated years)
- Backend development or infrastructure operations experience,
roughly 3+ years
-> Needed to align technical requirements with the vendor and
implement integration points with existing systems
- Hands-on experience with AWS, GCP, or another public cloud
-> We're currently leaning toward AWS as the migration target;
experience with other clouds is welcome, let's discuss
- Practical SQL experience for data extraction and analysis
-> Needed to analyze delivery performance data and compare
throughput before/after migration
PREFERRED QUALIFICATIONS (you're welcome to apply without these if
you meet the required items above)
- Experience selecting or migrating an ESP
- Experience operating an email platform at several million
sends/month
- Hands-on experience with IaC tools such as Terraform
Target compensation: JPY 6.0M-8.5M
(Benchmarked against the current MOps team average of JPY 6.8M)"WHAT YOU WILL ACTUALLY DO" の機能と副作用
英文JDの定型見出しの一つで、日本語版の「■このポジションで実際に取り組んでいただくこと」と同機能。ただし英語版でも日本語版と同じ副作用（候補者向け情報と社内レビュー向け情報が同じ文章に混在し冗長化）が起きている。
Best — 読み手が意思決定できる ／ 約15行 ← Betterの約半分
──候補者向け・職務記述書本文──
【必須要件】(年数は目安。同等スキルなら年数不問)
・バックエンド開発またはインフラ運用の実務経験 3年程度
・AWS/GCP等パブリッククラウドでの運用経験
・SQLでのデータ抽出・分析経験
【歓迎要件】(未経験でも必須要件を満たせば応募歓迎)
・ESP(メール配信システム)の選定・移行経験
・月間数百万通規模の配信基盤運用経験
想定年収: 600万〜850万円 選考: 書類選考→技術面接→最終面接→内定
[人事レビュー用メモ・候補者には非公開]
①主観表現(「スピード感についてこられる方」等)は削除済み
②必須要件を4→3項目に整理し、年数は目安・同等スキル歓迎と明記
③年収は既存メンバー平均680万円、他部署同職級との整合を確認済みBetterから何が変わったか 動いた軸：①結論の位置 → ②読み手適合
- ② Betterでは候補者向けの要件と中村さん向けの説明が1つの文章に混在していたが、Bestでは「候補者向け本文」と「人事レビュー用メモ」を明確に分離した。候補者は要件だけを簡潔に読め、中村さんはレビューに必要な3点だけを独立して確認できる
- ① 中村さんにとっての結論（「掲載してよいか」を判断するための3点）が、要件の後ろに埋もれず独立した見出し付きのメモとして先頭級の扱いになった
- ② 各要件の「→なぜ必要か」という業務説明は、候補者にとっては必須ではない（面接で聞けばよい）と判断し、候補者向け本文からは削除。要点だけを人事レビュー用メモの③に凝縮した
- 選考フロー（書類選考→技術面接→最終面接→内定）を追加し、候補者が応募後の見通しを持てるようにした
分量について（今日特に見てほしい点）：Better（約29行）→Best（約15行）で分量が減っている。これは情報を削ったからではなく、「候補者向けに必要な情報」と「中村さんのレビューに必要な情報」を分離し、それぞれに不要な情報を削ぎ落とした結果。Betterは両方の読み手に配慮しようとして1つの文章に詰め込みすぎ、結果的にどちらの読み手にも最適化されていなかった。
今回はBestまで作るべきか：Best必要。
理由は2つ。① 採用のミスマッチや法令違反（年齢差別的表現の見落とし等）は後戻りコストが高く、掲載後に修正しても既に見た候補者への悪印象は消えない ② 中村さんのレビュー時間は中1日しかなく、確認すべき3点が独立して示されていないと、Betterの文章全体を読み込んで自分で3点を抽出する作業が発生し、12/8掲載に間に合わないリスクがある。
── 逆に、選考フローの詳細（各面接の所要時間・面接官の氏名等）まで職務記述書に書き込む必要はない。 それは採用計画書や候補者への個別案内メールの役割。
理由は2つ。① 採用のミスマッチや法令違反（年齢差別的表現の見落とし等）は後戻りコストが高く、掲載後に修正しても既に見た候補者への悪印象は消えない ② 中村さんのレビュー時間は中1日しかなく、確認すべき3点が独立して示されていないと、Betterの文章全体を読み込んで自分で3点を抽出する作業が発生し、12/8掲載に間に合わないリスクがある。
── 逆に、選考フローの詳細（各面接の所要時間・面接官の氏名等）まで職務記述書に書き込む必要はない。 それは採用計画書や候補者への個別案内メールの役割。
Best
REQUIRED (years are a guideline; equivalent experience is welcome
even short of the stated years)
- Backend development or infrastructure operations experience,
roughly 3 years
- Hands-on experience with AWS, GCP, or another public cloud
- Practical SQL experience for data extraction and analysis
PREFERRED (you're welcome to apply without these)
- Experience selecting or migrating an ESP
- Experience operating an email platform at scale (millions of
sends/month)
Target compensation: JPY 6.0M-8.5M Process: Application review ->
technical interview -> final interview -> offer
[HR REVIEW NOTE - not shown to candidates]
1. Coded language ("keep up with our fast pace," etc.) removed
2. Required items trimmed from 4 to 3; years reframed as a
guideline, with an explicit welcome for equivalent experience
3. Compensation benchmarked against current team average (JPY
6.8M) and comparable bands in other departments角括弧ラベルで「別チャンネル」と一目で分かるようにする
"[HR REVIEW NOTE - not shown to candidates]" は、英文実務でも候補者向け文書と内部レビュー資料を同一ファイル内で明確に区切る際によく使われる型。日本語版の「人事レビュー用メモ・候補者には非公開」と同機能。
日英差分ノート
1. 「差別的表現」の法的な地雷の位置が日英で異なる
日本語版では労働施策総合推進法9条（旧雇用対策法10条、2007年制定・2018年に条文移設）により、募集・採用における年齢を理由にした差別が原則禁止されている（一定の例外事由あり）。英語版（米国）ではADEA（1967年制定、40歳以上の労働者を保護）が対応する規制だが、日本語の「スピード感についてこられる方」のような遠回しな表現より、英語圏の採用実務は"digital native"や"recent graduate"のような一見ポジティブな表現の方を、年齢差別の指標として明示的に警戒する文化がある。 同じ「排除の含意」でも、日本語は婉曲表現、英語は一見前向きな形容詞が地雷になりやすいという違いがある。
2. 給与レンジの開示が「配慮」から「法的義務」に変わりつつある地域がある
日本語版では想定年収の記載は任意（ただし実務上は記載する流れが強まっている）。一方、米国ではカリフォルニア州SB 1162（2023年1月施行）やニューヨーク州の給与透明化法（2023年9月施行）により、従業員数の要件を満たす企業には求人票への給与レンジ記載が法的に義務化されている州が増えている。英語版のJDを書く際は「書いた方が親切」ではなく「書かないと違法になりうる地域がある」という前提で臨む必要がある。
3. 「必須/歓迎」の呼称のフォーマル度の使い分け
日本語の「歓迎要件」は口語・正式文書のどちらでも自然に使えるが、英語は "Nice to have"（口語的）と "Preferred Qualifications"（正式）でフォーマル度が明確に分かれる。社内ドラフトの段階では "Nice to have" でよいが、外部公開する求人票に転記する際は "Preferred" に置き換えるのが実務上の型。
頻出表現
| 日本語 | English | トーンの強さ・使う場面 |
|---|---|---|
| 必須要件 | Required Qualifications | 中立・フォーマル |
| 歓迎要件 | Preferred Qualifications（社内ドラフトでは Nice to have も可） | 中立〜口語。外部公開時はPreferredに統一 |
| 〜経験があれば尚可（避けるべき） | （Requiredに混在させず、Preferredに明確に分離する） | 弱い。境界を壊すため避ける |
| 同等の経験があれば年数不問 | Equivalent experience is welcome regardless of years | 中立。応募ハードルを下げる定型 |
| 応相談 | Open to discussion / Let's discuss | 中立 |
| 想定年収 | Target compensation / Salary range | 中立。開示義務化が進む地域があることに留意 |
差分5軸まとめ
| 軸 | 🔴 Bad | 🟡 Good | 🟢 Better | 🔵 Best |
|---|---|---|---|---|
| ① 結論の位置 | 要件が羅列されるだけで、必須/歓迎の境界すら崩れている | 必須/歓迎は分離されるが、中村さんが確認すべき論点は埋もれたまま | 業務内容の説明が冒頭に来るが、中村さん向けの論点は要件の中に散らばったまま | 中村さんが確認すべき3点を独立した「人事レビュー用メモ」として先頭級に配置 |
| ② 読み手適合 | 候補者にも中村さんにも機能しない汎用文言 | 一般的な技術要件の羅列で、誰向けでもない | 候補者・中村さんの両方に配慮しようとして1つの文章に混在（冗長化） | 候補者向け本文と人事レビュー用メモを分離し、双方に最適化 |
| ③ 事実と解釈の分離 | 「知識」「〜あれば尚可」等で必須/歓迎の境界が崩壊 | 必須/歓迎は分離されるが、なぜ必要かの根拠がない | 各要件に業務上の根拠（→の行）を明記 | 根拠の説明は候補者向けから削り、要点のみ人事レビュー用メモに凝縮 |
| ④ 次の行動 | 給与・選考プロセスの記載がなく、応募すべきか判断不能 | 想定年収のみ提示、選考フローなし | 年収と根拠は示されるが選考フローがまだない | 給与・選考フロー・レビュー確認事項まで明記し、即座に掲載可否を判断できる |
| ⑤ 想定反論 | 無視（応募ハードル・差別表現のいずれも検討された形跡がない） | 一部レベル感（経験年数）が示されるのみ | 「年数に満たなくても対象」「他クラウドでも応相談」等、一部先回り | 差別的表現・応募ハードル・給与根拠という3つの懸念すべてに個別に先回り |
| 分量（参考） | 約13行 | 約19行 | 約29行 ← 最長 | 約15行 ← Betterより大幅に短い |
分量の行に注目。 Day004・Day005は2回連続でBad→Bestにかけて分量が単調増加した回だったが、今回はBetter（約29行）→Best（約15行）で分量が減少している。理由は情報を削ったからではなく、候補者向けとレビュー向けで読み手を分離し、それぞれに不要な情報を削ぎ落としたため。Bestの分量（約15行）はGood（約19行）よりも短く、直近2回とは逆のパターンを示す回として記録する。
Best版・全文
ここまでは「2. 必須要件・歓迎要件」の抜粋だけを比べてきた。以下は Best 水準の職務記述書としての全文。そのまま社内公募・レビュー依頼に出せる完成形。
日本語版 全文を見る
職務記述書：配信基盤エンジニア（MOpsチーム）
作成: EC事業本部 販促システム部 MOpsチーム マネージャー 宮田
日付: 2026年12月2日
レビュー依頼先: 人事部 採用担当 中村さん（12/3(木)17時までに確認依頼、
12/4(金)中にフィードバック希望）
公開予定: 2026年12月8日（社内公募＋提携転職エージェント2社経由）
■ 1. ポジション概要
ポジション名: 配信基盤エンジニア
配属先: EC事業本部 販促システム部 MOpsチーム
雇用形態: 正社員
採用人数: 1名
目標入社日: 2027年2月1日
■ 2. 業務内容
既存メール配信基盤（2018年構築、処理上限1時間あたり80万通）の
クラウド移行プロジェクト（2027年1月RFP発注予定）を、外部ベンダー
と共同で推進していただきます。具体的には：
・ベンダーとの技術要件のすり合わせ、既存システムとの接続部分の
設計・実装
・移行前後の処理能力の測定・比較、配信実績データの分析
・移行後の運用体制の設計（監視・アラート設計を含む）
配属後は、既存の配信基盤の日次運用（他メンバーと分担）も一部
担当していただきます。
■ 3. 必須要件・歓迎要件
【必須要件】(年数は目安。同等スキルなら年数不問)
・バックエンド開発またはインフラ運用の実務経験 3年程度
・AWS/GCP等パブリッククラウドでの運用経験
・SQLでのデータ抽出・分析経験
【歓迎要件】(未経験でも必須要件を満たせば応募歓迎)
・ESP(メール配信システム)の選定・移行経験
・月間数百万通規模の配信基盤運用経験
・Terraform等IaCツールの実務経験
■ 4. 想定年収・勤務条件
想定年収: 600万円〜850万円（経験・スキルに応じて決定）
勤務地: 本社（週2日リモート可）
勤務時間: フレックスタイム制（コアタイム11:00-15:00）
■ 5. 選考プロセス
書類選考（約1週間）→ 技術面接（宮田・配信基盤担当エンジニア、
60分）→ 最終面接（西村本部長、45分）→ 内定
内定から入社までの目安: 1.5ヶ月
■ 6. 人事レビュー用メモ（候補者には非公開・中村さんへの確認事項）
①差別的表現: 「スピード感についてこられる方」等の年齢差別を
示唆しうる主観的表現は全て削除済みです（労働施策総合推進法
9条を踏まえて確認しました）
②応募ハードル: 必須要件を当初案の4項目から3項目に整理し、
経験年数は「目安」であることを明記。同等スキルであれば年数
不問で応募を歓迎する一文を追加しました
③給与根拠: 想定年収600〜850万円は、既存MOpsチームメンバーの
平均年収（680万円）、および他部署の同職級レンジ（700万円台
中心）との整合を確認済みです
④掲載スケジュール: 本レビューを12/4(金)中にいただければ、
12/8(月)の社内公募・エージェント掲載に間に合いますEnglish 全文を見る
Job Description: Delivery Platform Engineer (MOps Team)
Prepared by: Miyata, MOps Team Manager, Promotion Systems Dept.,
EC Business Unit
Date: 2 December 2026
Review requested from: Nakamura, HR Recruiting (please review by
17:00 on 3 Dec; feedback requested by end of day 4 Dec)
Target posting date: 8 December 2026 (internal job posting + two
partner recruiting agencies)
1. POSITION OVERVIEW
Title: Delivery Platform Engineer
Team: MOps Team, Promotion Systems Dept., EC Business Unit
Employment type: Full-time
Headcount: 1
Target start date: 1 February 2027
2. WHAT YOU WILL DO
You will help drive the cloud migration of our current email
delivery platform (built 2018, current peak: 800K emails/hour),
working jointly with an external vendor, with RFP issuance targeted
for January 2027. Specifically:
- Align technical requirements with the vendor; design and
implement integration points with existing systems
- Measure and compare delivery throughput before and after
migration; analyze delivery performance data
- Design the post-migration operations setup, including monitoring
and alerting
You will also share day-to-day operation of the existing platform
with the rest of the team.
3. REQUIRED / PREFERRED QUALIFICATIONS
REQUIRED (years are a guideline; equivalent experience is welcome
even short of the stated years)
- Backend development or infrastructure operations experience,
roughly 3 years
- Hands-on experience with AWS, GCP, or another public cloud
- Practical SQL experience for data extraction and analysis
PREFERRED (you're welcome to apply without these)
- Experience selecting or migrating an ESP
- Experience operating an email platform at scale (millions of
sends/month)
- Hands-on experience with IaC tools such as Terraform
4. COMPENSATION AND WORKING CONDITIONS
Target compensation: JPY 6.0M-8.5M, commensurate with experience
Location: Head office (up to 2 remote days/week)
Hours: Flextime (core hours 11:00-15:00)
5. HIRING PROCESS
Application review (~1 week) -> Technical interview (Miyata + a
delivery platform engineer, 60 min) -> Final interview (Director
Nishimura, 45 min) -> Offer
Typical time from offer to start: ~1.5 months
6. HR REVIEW NOTE (not shown to candidates - for Nakamura)
1. Age-coded language (e.g., "keep up with our fast pace") has
been removed, reviewed against Japan's Labor Measures
Comprehensive Promotion Act, Art. 9 (age discrimination in
hiring is prohibited with limited exceptions)
2. Required items trimmed from an initial 4 to 3; years reframed
as a guideline, with equivalent experience explicitly welcomed
regardless of years
3. Compensation (JPY 6.0M-8.5M) benchmarked against the current
MOps team average (JPY 6.8M) and comparable bands in other
departments
4. Schedule: if this review is completed by end of day 4 Dec, we
remain on track for the 8 Dec posting date完成の定義チェックリスト
職務記述書を提出・掲載する前に必ず確認する。「雑・妥協」を防ぐための外部基準。1つでも未チェックがあれば、まだ出さない。
進捗 0 / 8
今日の演習
15分版 — まずこれだけでもやる
Bad例の「コミュニケーション能力が高く、当社のスピード感についてこられる方」という1文を、書き直す。
条件はこれだけ：
- 主観的な形容詞（「高い」「ついてこられる」等）を使わない
- 具体的な業務内容と結びつけるか、そもそも必須要件から削除するかのどちらかを選ぶ
- 1〜2文で完結させる
書き終えたら、本文中のBetterの該当箇所と見比べる前に、なぜその判断（残す/削る）をしたかを自分の言葉で1文書いておく。
60分版
同じ職務記述書の「必須要件・歓迎要件」を、読み手を「中村さんではなく、候補者本人（他社からもオファーを検討中）」に変えて書き直す。
守る条件：
- 必須/歓迎の区別、経験年数が目安であること、給与レンジは維持する
- 「なぜこの要件が必要か」という説明よりも、「このポジションで働く面白さ・裁量の大きさ」という動機づけの要素を冒頭に追加する
- 人事レビュー用メモの内容（差別表現チェック・給与根拠の社内比較等）は候補者向け本文に含めない
- 分量はBestの候補者向け本文の1.5倍程度まで（動機づけの追加分のみ増える想定）
取り組む前のヒント
考える順序
- 中村さんが知りたいこと（掲載してよいか＝リスクの有無）と、候補者本人が知りたいこと（応募する価値があるか＝魅力の有無）が全く別の判断であることを、まず自分の言葉で書き出す
- 候補者にとって「年収600〜850万円が他部署とバランスが取れている」という情報は判断材料にならない。むしろ「このポジションで何が身につくか」「裁量がどれくらいあるか」の方が意思決定を左右する
- 動機づけの要素を書く際、誇張にならないよう、Best版の「業務内容」セクションにある具体的な業務を根拠に、何が面白いのかを書く
陥りやすい罠
- 中村さん向けの文面をそのまま流用してしまう。中村さんが気にする「差別表現チェック済み」「給与の社内整合性」は、候補者にとっては読む必要のない情報
- 動機づけを書こうとして、根拠のない誇大な表現（「裁量が大きい」「成長できる」等の中身のない言葉）で埋めてしまう
チェックすべき観点
書き上げたら、「候補者がこれを読んで、他社のオファーと比較した上で応募したいと思えるか」を判定する。「なぜ必要か」を説明する行が多すぎる場合、まだ中村さん向けの粒度から抜け切れていない。
実務での使いどころ
職務記述書は、採用プロセスの起点となる文書。前後の文書との関係を押さえると、どこまで書くべきかの判断がつく。
| 関係 | 文書 | この職務記述書との関係 |
|---|---|---|
| 前 | 予算計画書（財務・会計#1、Day005） | 配信基盤刷新プロジェクトの体制強化という増員理由そのものが、Day005で計上した予算項目2の実行体制に紐づいている |
| 前 | プロジェクト憲章（PMO#1、Day003） | Day003で定義した実行体制・権限範囲が、増員の必要性を裏付ける根拠になっている |
| 後 | 採用計画書 / 求人票（人事#2） | 本職務記述書は「役割の設計図」であり、中村さんはこれを基に外部の転職媒体向けに、よりマーケティング的な求人票を作成する |
| 後 | オンボーディング資料（人事#5） | 入社後、本職務記述書の「業務内容」が、オンボーディング資料で具体的なタスクレベルまで分解される |
| 後 | 人事評価資料（人事#3） | 本職務記述書の必須要件・業務内容が、配属後の評価基準の土台になる |
現場での実感として一番大きいのは、必須要件を絞り込む作業そのものが、実は「この人に何を任せるか」を採用側が言語化する作業になっている。 要件を厳しくしすぎる背景には、多くの場合「配属後に何を任せるか」がまだ曖昧なまま採用活動だけが先行しているという事情がある。業務内容を先に具体化してから要件を絞ると、必須要件は自然と絞り込まれる。
何が起きているか