- 支払に関わる仕事は、一次査定、専門査定（医務・法務）、支払管理（漏れの抽出・再鑑・事後検証）、システム企画、エンジニアの5つに分けて考えると伝わります。
- 募集要項には「何を決める仕事か」と「何を決めない仕事か」を書きます。特に支払可否を決めるのは査定の職務で、エンジニアは決めないことを明記します。
- 選考課題は合成の書類・データで行い、精度の高さより、責任の線の引き方と、正当な支払を削らない評価の設計を見ます。
1. 仕事が生まれる場所：支払の規模と当局の要求
生命保険会社の保険金・年金・給付金の支払は2024年度に約18.9兆円（生命保険協会の公表値から編集部が合計）、損害保険会社の正味支払保険金は約5.6兆円でした（日本損害保険協会）。
現在の監督指針には、支払管理態勢の着眼点が具体的に書かれています。高度な法的・医学的判断での法務部門や医師の意見の聴取、支払漏れを防止するシステム対応、支払管理部門とシステム部門の連携、不払い事例の事後検証などです。2025年・2026年の改正では、保険金不正請求の事案を踏まえた支払管理部門の独立性や不正請求の疑い情報の管理も加わりました。これらがそのまま、支払部門とシステム部門の仕事になっています。全体像は支払管理態勢の解説にまとめています。
2. 5つの職務と責任範囲
| 職務 | 決めること | 決めないこと | 確認したい経験 |
|---|---|---|---|
| 査定担当（一次査定） | 個別請求の支払可否と金額、不備の照会、契約者への説明 | システムの仕様、専門的な医学的判断 | 約款・契約内容にもとづく判断、書類確認、判断理由の記録 |
| 専門査定（医務・法務） | 医学的・法的な判断を要する案件への意見、査定基準の見直しの提案 | 一次査定の定型処理 | 医療職・法務としての経験、意見の文書化（資格要件は職務による） |
| 支払管理（再鑑・事後検証） | 漏れ候補の再鑑、不払い・請求放棄のサンプル検証、抽出ルールの見直しの提案 | 一次査定の代わりの判断 | 検証の設計、原因分析、苦情との照合 |
| システム企画（業務とシステムの橋渡し） | 自動化の範囲の案、人に渡す条件の案、評価の計画、商品改定時のテスト計画 | 支払可否、自動化範囲の最終承認 | 業務要件の定義、並行稼働の運営、支払部門との合意形成 |
| エンジニア（査定支援システム） | 抽出・突合・検索の実装、根拠の提示、記録と変更管理、評価の仕組み | 支払可否、業務ルールの採否 | 書類のデータ化、ルールの実装とテスト、評価の設計、個人情報を扱うシステムの運用 |
表は監督指針の着眼点と業務の流れから編集部が整理したもので、すべての会社がこの分け方をしているわけではありません。損害保険の物損では、保険会社から委託を受けて損害額を調べる損害保険登録鑑定人や、日本損害保険協会に登録されたアジャスター（自動車の物損事故の損害調査）も関わります。小さな組織で1人が複数を兼ねる場合は、どれを兼ねるかを書くと伝わります。
3. 募集要項に書くこと・書かないこと
書くこと
- 担当する範囲：生命保険か損害保険か、扱う請求の種類（給付金・保険金・付随的な保険金など）、書類の種類
- 決める権限：支払可否の判断者はだれか、システム側は提案・実装までか
- 関わる相手：査定担当、医務・法務、支払管理、商品開発、コンプライアンス、内部監査
- 評価のされ方：処理日数だけでなく、支払漏れの発見経路や過少支払の件数も見るのか
- 扱う情報：病歴などの要配慮個人情報を扱うこと、その取扱いの規程と研修
- 使う仕組み：自社開発か外部サービスか（社名を出せない場合は種類で）
書かないこと・避けること
- 「AIで査定を自動化」「支払コストを削減」など、支払を削ることを成果とする表現。支払管理の目的は約束どおりに払うことです
- 前職の実データ・査定基準を持ち込めることを期待させる表現（守秘義務・個人情報の扱いに反する）
- 「査定DX全般」だけの、職務の境界があいまいな記述
- 求人の需要や年収の水準を根拠なく断定する表現
「給付金請求の書類確認を支援するシステムの開発を担当します。書類からの項目抽出、契約内容との突合、根拠の表示、判断と修正の記録を設計・実装します。支払可否の判断は査定担当が行い、本職務は判断の材料の正確さと、判断の過程を後から確かめられる仕組みに責任を持ちます。病歴等の要配慮個人情報を扱うため、社内規程に沿った開発・評価環境で作業します。」
4. 選考課題の作り方：合成データで「責任の線」と「評価の設計」を見る
応募者に実在の診断書や請求データを扱わせることはできません。合成の請求書類（架空の記号で作った入院・手術の証明書類）を用意すれば、全員に同じ条件で課題を出せます。作り方は抽出評価の演習を参考にしてください。
「合成の請求書類200枚と、架空の商品の支払条件を渡します。書類確認を支援する仕組みを提案してください。A4で2枚。自動化する範囲と人に渡す条件、評価の方法（過少支払の方向の誤りをどう数えるか）、根拠の示し方、記録の残し方、限界を書くこと。」
| 見る観点 | 高く評価する答え | 注意が必要な答え |
|---|---|---|
| 責任の線 | 支払可否は査定担当が決め、システムは材料と記録を担うと書き分ける | 「システムが査定する」「不払いを自動判定」 |
| 評価の設計 | 項目別・方向別の誤り、見逃しと誤検知、人への引継ぎ率を測る | 全体の正解率だけ |
| 正当な支払 | 過少支払を増やさないことを採用の条件に置く | 処理時間・支払額の削減だけを効果とする |
| 根拠と記録 | 値ごとの根拠の位置、版と修正履歴を残す | 結果だけを保存 |
| データの扱い | 合成データの範囲で完結し、実データの扱いの規程に触れる | 実データで試したいと述べる |
査定担当・支払管理の候補者には、課題の代わりに「架空の不払い事例を3件読み、判断の根拠が後から検証できる記録になっているかを指摘する」といった検証の課題が向きます。事例はすべて架空で作り、実在の案件を使いません。
5. 入社後の評価観点を職務ごとに書いておく
募集要項と選考で伝えた役割は、入社後の評価の観点と一致させます。支払に関わる職務では、処理件数や削減額だけで評価すると、確認の形式化や正当な支払の削減を招くおそれがあります。以下は編集部の整理による例です。
| 職務 | 評価の観点（例） | 評価に使わないほうがよいもの |
|---|---|---|
| 査定担当 | 判断理由の記録の完全さ、事後検証での指摘の少なさ、処理日数、契約者への説明の質 | 不払い・減額の件数や金額 |
| 専門査定 | 意見の根拠の明確さ、回付から回答までの日数、査定基準の改善提案 | 回付件数の多寡だけ |
| 支払管理 | 支払漏れの発見経路のうち会社が先に見つけた割合、抽出ルールの改善、検証の実施率 | 再鑑件数の多さだけ |
| システム企画 | 並行稼働の結果にもとづく判断材料の質、商品改定時のテストの漏れのなさ | 導入した機能の数 |
| エンジニア | 見逃し・誤検知・根拠の正確性・引継ぎ・監査可能性の改善、変更時の影響試算と記録 | 削減した作業時間だけ |
兼務させるときの組み合わせ
- 避けたい組み合わせ：同じ人が一次査定と、その案件の事後検証を兼ねる。監督指針も、不払いへの苦情を支払部門だけで処理せず別部門で検証する態勢を求めています。
- 組みやすい組み合わせ：システム企画とエンジニア、支払管理とシステム企画（業務ルールの持ち主として要件を出す）。この場合も、支払可否の判断を担わないことを明記します。
6. 面接で確認すること（例）
- 支払の誤りが見つかったとき、どこで見つかり、仕組みのどこを直したか（個人名・顧客情報を出さずに説明できるか）
- 処理の速さと正確さがぶつかったとき、だれに何の数字で判断を求めたか
- 商品の改定や様式の変更に、システムやルールをどう追随させたか
- 自分が決めなかったこと（決める権限がなかったこと）を、どう線引きしていたか
- 要配慮個人情報を扱う環境で、開発・テストのデータをどう扱ったか
エージェントが候補者に求人を紹介するときも、職務の表（2節）のどの行の仕事かを先に確認すると、候補者の経験との照合がしやすくなります。たとえば「OCRの経験がある」候補者でも、確認画面や根拠の表示、記録の設計まで経験しているかで、査定支援のエンジニアとしての適合は変わります。逆に、査定や支払管理の実務経験がある候補者は、システム企画の職務で業務ルールの持ち主として力を発揮できる場合があります。いずれも、前職の具体的な査定基準や案件の内容を聞き出すのではなく、仕組みと判断の線引きをどう考えたかを聞きます。
7. 失敗・注意点
- 査定とエンジニアの職務を1つの募集にまとめる：判断の責任とシステムの責任が混ざり、入社後に「だれが決めるのか」が曖昧になります。兼ねる場合も範囲を書き分けます。
- 資格や経験年数だけで選ぶ：支払管理の仕組みで問われるのは、根拠を残し、漏れを拾い、後から検証できるようにする姿勢です。課題と面接で見ます。
- 需要や年収を断定する：求人の条件は企業ごとに異なります。この記事でも断定しません。
- 採用を延期する判断：職務の範囲や判断の権限が社内で決まっていない段階では、募集を出す前に支払部門とシステム部門で線引きを決めるほうが、ミスマッチを減らせます。