職務等級の定義と現場へのヒアリングメモから職種ごとの職務記述書を下書きし、等級の定義との食い違いと書いてはいけない条件を人事へ返す

処理の起点を決める

ヒアリングメモが SharePoint の決まったフォルダに保存されたことを起点にします。 メモと一緒に、職種と等級を選ぶ欄を持たせます。職種と等級はメモの文章から推測させません。 どの等級の定義と照らすかが変わってしまうからです。

改訂のときは、既存の職務記述書を選んでから動かします。 新規と改訂で入力が違います。改訂では既存の職務記述書とメモの両方を渡し、どこを変えたかの差分も返させます。

等級の定義書が改定されたときは、その等級の職務記述書を一覧にして担当へ知らせます。 改定のたびに全部を書き直す必要はありませんが、食い違いの照合をやり直す対象にはなります。

入力データを集める

質を決めるのは、3行目の「上下1等級」です。 その等級の定義だけを渡すと、食い違いの指摘は「この等級らしくない」というぼんやりしたものになります。上下の等級の定義を並べると、「この記述はG5の定義の言葉に近い」と、どちらにずれているかを示せます。

4行目の同じ職種の職務記述書は、書き方をそろえるためです。 同じ職種のG3とG5の職務記述書があれば、G4はその間に収まる書き方になります。第3章（b）の粒度のばらつきを、ここで抑えます。

データの取得方法を決める

等級の定義書は、等級ごとに分けた写しを用意しておきます。 定義書1冊を毎回渡すと、照らす相手が多すぎて、どの等級の定義を根拠にした指摘かが曖昧になります。 改定のたびに写しも作り直します。

AIへ渡す前に整形する

1. メモの整形 … 箇条書きと話し言葉が混ざったメモを、段落ごとに番号を振ってそのまま渡します。言い換えや要約はしません
2. 人の名前の置き換え … メモに出てくる社員の名前を「担当者A」のように置き換えます。職務記述書に人の名前は要りません
3. 等級の定義の切り出し … 選んだ等級と上下1等級の定義を、等級の見出し付きで並べます
4. 辞書の照合（1回目） … 書いてはいけない言葉の辞書でメモを照らし、当たった段落番号を控えます
5. 長さの確認 … メモが極端に短いもの（数行）は、下書きを作らず担当へ戻します
6. 改訂の準備 … 改訂のときは、既存の職務記述書にも項目ごとの番号を振って渡し、差分を項目の番号で返せるようにします

2番目の置き換えは、人に紐づいた記述を見分けるためにも効きます。 「担当者Aは英語の契約書も読める」と書かれていれば、それがいまの担当者の話だと読み取れます。名前が残っていると、AIは要件と事実の区別をつけにくくなります。

5番目は、下書きの質を守るためです。 材料が足りないメモから作った下書きは、等級の定義をなぞっただけの文書になり、一見それらしいので、足りないことに気づかれません。

AIに処理させる

させるのは、決まった型の下書きと、3種類の指摘です。

3行目の食い違いは、両方の引用をそろえさせます。 メモの「部下5名の評価を行う」と、G4の定義の「個人として成果を出す」を並べて返せば、担当は等級の定義書を開かずに判断できます。

2行目の「人に紐づいた記述」は、次のように見分けさせます。

違いは、主語が人か職務かです。 同じ「英語」「休日」の話でも、人の能力や善意として語られたものは要件にせず、職務として繰り返し発生することとして語られたものだけを下書きに入れます。

4行目の区分は、厚生労働省の公開資料に沿って一覧に持たせます。

2行目は、拾いすぎを恐れないためでもあります。 「夜間の障害対応がある」はインフラの職務では業務上の必要がある記述かもしれません。AIには該当しうるものを広く拾わせ、要るかどうかは人事が決めます。

指示内容を固定する

あなたは人事部で職務記述書を下書きする係です。
渡すヒアリングメモ・等級の定義・同じ職種の職務記述書だけを根拠にしてください。

【下書きの型】
- 職務の目的（2文以内）
- 主な責任（5〜8項目。各項目は「〜する」で終える）
- 成果の指標（3〜5項目）
- 必要な知識とスキル（職務に求めるものだけ）
- 経験（年数ではなく、経験の中身で書く）

【指摘の出し方】
1. person_specific：いまの担当者の能力や働き方を述べた記述。
   職務に求めることとは分けて、メモの段落番号と原文を引用してください。
   下書きには入れないでください。
2. grade_mismatch：選んだ等級の定義と合わない記述。
   メモの原文と、近い等級の定義の原文を両方引用してください。
3. restricted：年齢・性別・身長体重体力・転勤・本人に責任のない事項・
   思想信条に関わる記述。メモか下書きの原文と、一覧の区分を書いてください。
   業務上の必要があるかもしれないものも、拾って理由を書いてください。

【厳守事項】
- メモに無い責任や要件を、等級の定義から補って書かないでください。
  足りない項目は空にし、missing_info に何が足りないかを書いてください。
- 引用は原文を一字一句そのまま写してください。要約しないでください。
- 等級を上げるべき、下げるべきと書かないでください。
- 書いてはいけない条件に当たる記述は、下書きに入れないでください。
  指摘の一覧にだけ残してください。
- 「担当者A」などの置き換えられた名前を下書きに書かないでください。

【職種と等級】{job_family} / {grade}
【等級の定義（選んだ等級と上下1等級）】{grade_definitions}
【同じ職種の職務記述書】{related_jds}
【書いてはいけない条件の一覧】{restricted_list}
【ヒアリングメモ（段落番号付き）】{memo}

「等級の定義から補って書かない」がいちばん大事な制約です。 メモが薄いと、AIは等級の定義の言葉で主な責任を埋めます。埋まった下書きはそれらしく見えますが、どの職種でも同じ文書になります。 足りない項目は空にし、ヒアリングで聞き足すべきことを missing_info に返させます。

「下書きに入れず、指摘の一覧にだけ残す」は、書いてはいけない条件が外へ出る経路を断つためです。 下書きに残したまま印だけ付けると、印を見落とした人が求人票へ写します。

出力形式を固定する

次の形のJSONで受け取ります。 構造化出力のスキーマとして渡し、strict: true にします。

{
  "job_family": "",
  "grade": "",
  "draft": {
    "purpose": "",
    "responsibilities": [""],
    "kpis": [""],
    "skills": [""],
    "experience": [""]
  },
  "findings": [
    {
      "type": "person_specific | grade_mismatch | restricted",
      "memo_paragraph": 0,
      "quote": "",
      "grade_quote": "",
      "restricted_category": "age | sex | physical | relocation | personal | none",
      "note": ""
    }
  ],
  "missing_info": [""]
}

1つ目の理由は、findings を下書きと別に持てることです。 担当は指摘の一覧を先に読み、判断を決めてから下書きを直します。指摘が下書きの文の中に埋もれていると、読み飛ばされます。

2つ目は、引用を機械的に確かめられることです。 Azure Functions が quote をメモと下書きの中から、grade_quote を等級の定義の写しの中から探します。見つからない指摘は「引用不一致」として一覧の先頭に出します。 AIが言い換えた文や作った文を、判断の材料にしないためです。

3つ目は、restricted_category で辞書の照合と突き合わせられることです。 辞書が拾ってAIが拾わなかったもの、AIが拾って辞書が拾わなかったものを、両方とも一覧に出します。

4行目は、指示の守られ方を見張るためです。 本来は起きないはずの状態なので、起きたら下書きを確定させません。

担当に届く指摘の一覧の例です。

【職種・等級】インフラエンジニア／G4
【警告】なし
【等級の定義との食い違い】1件
 メモ¶7「チームの3名の目標設定と評価を担う」
 G5の定義「メンバーの目標設定と評価を行い、チームの成果に責任を持つ」に近い
【書いてはいけない条件】2件
 メモ¶4「体力のある若手が望ましい」（区分：年齢／身長・体重・体力）［辞書・AI］
 メモ¶9「障害時は休日も当番で対応する」（区分：なし。業務上の必要の確認）［AIのみ］
【人に紐づいた記述】1件
 メモ¶5「担当者Aはネットワークの資格を3つ持っている」
【聞き足すこと】成果の指標が1項目しか無い

一覧の並びは、判断の重い順にしています。 食い違いは等級の論点になりうるので最初に、書いてはいけない条件は外へ出る前に止めるので次に置きます。人に紐づいた記述と聞き足すことは、管理職との確認の場で片づくものです。

システムへ連携する

人事システムへは書き込みません。 職務記述書と職種・等級の紐づけは、管理職の確認を経て人事が確定した後に、人が行います。この構成が出すのは、下書きと指摘までです。

人が確認する

下書きは、すべて人事の担当が読んで直します。 読む順は次のとおりです。

1. 最上段の警告を見る … 下書きに辞書の言葉が残っているもの、引用不一致のもの
2. 食い違いの指摘を読む … 職務を直すか、等級を見直す論点として上長に上げるかを決める
3. 書いてはいけない条件を確かめる … 業務上の必要があると判断したものは、その理由を記録する
4. 人に紐づいた記述を確かめる … 職務に求めることとして残すべきものがあれば、言葉を職務の言葉に直して入れる
5. 下書きを直す … missing_info に挙がったものは、管理職に聞き足す

3番目で理由を記録するのは、後から問われたときのためです。 「夜間の障害対応がある」を残すなら、それが職務に必要な理由を書いておきます。理由の無いまま残った条件は、求人票に写された時点で説明できなくなります。

例外に対処する

いちばん多いのは2行目です。 ヒアリングが短く終わった職種や、管理職が書面で答えた職種のメモは薄くなりがちです。下書きを作らずに戻すと手間が増えたように見えますが、薄いメモから作った下書きを直すほうが、聞き足すより時間がかかります。 戻すときは、missing_info の形で聞き足す項目の例を添えます。

記録を残す

• ヒアリングメモ（名前の置き換え前と後）、選んだ職種と等級
• 渡した等級の定義の写しの版、同じ職種の職務記述書
• AIが返したJSONの全文と、辞書の照合の結果
• 担当が指摘をどう扱ったか（職務を直した／等級の論点として上げた／業務上の必要があるとして残した、とその理由）
• 確定した職務記述書と、管理職の確認の日付

4つ目の記録が、等級制度の見直しの材料になります。 同じ等級で食い違いの指摘が続くなら、職務の側ではなく等級の定義の書き方に問題があるかもしれません。

名前を置き換える前のメモは、見られる人を人事の担当に限ります。 管理職が部下について話した内容が含まれるため、職務記述書と同じ場所に置きません。生成AIに渡すのは置き換えた後のメモだけです。