人材派遣会社が新しく就業を始めたスタッフの就業データから、90日以内に本人都合で契約が終わる見込みを Python で出し、初期のフォローの順番を決める

処理の起点を決める

毎週月曜の早朝に、定時実行で動かします。 コーディネーターは月曜の朝にその週の連絡の予定を立てるので、それまでに一覧が置かれている必要があります。毎日動かすことも考えましたが、連絡の予定は週単位で立てるため、毎日一覧が変わると予定が立ちません。

対象は、その時点で就業7日目・21日目・45日目のいずれかを過ぎ、まだ次の時点の見込みが出ていない人です。週1回の実行なので、7日目を過ぎた直後の人もいれば、12日目の人もいます。時点は「その日数を過ぎた最初の月曜」に出すと決め、各人が各時点で1回ずつ一覧に載るようにします。

月に1回、学習し直すのではなく、当たり方を確かめるだけにします。 学習のし直しは四半期に1回とし、そのたびに一致度が前のモデルより下がっていないかを見てから入れ替えます。

入力データを集める

入れないものを先に決めます。 年齢、性別、国籍、家族の状況、健康の状態、住所そのものは入れません。早期の終了と統計的な関係があったとしても、それで連絡の順番を変えれば、属性で人を扱い分けることになります。 住所は通勤の所要時間に置き換えてから使い、住所そのものはモデルに渡しません。

フォローの記録の自由記述も、モデルには入れません。 書く量が担当者ごとに違い、「よく書く担当者のスタッフほど見込みが高く出る」という、担当者の癖を学んでしまうからです。 記述は一覧を見た担当者が自分で読みます。

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

派遣管理システムから、毎週同じ形のCSVを4つ書き出します。就業、勤怠、スタッフの経歴、交通費の届出です。スタッフ番号と就業番号で結び付けます。

書き出したら、毎週同じ3つを機械で確かめます。 行数が前の週から大きく変わっていないか、就業の開始日が終了日より後になっている行が無いか、勤怠の最終日が実行日の前日まで届いているか、です。どれかが外れたら一覧を作らずに止め、担当者に知らせます。 書き出しの設定が変わっただけで、全員の見込みが静かにずれることを防ぎます。

学習用のデータは、過去2年分の就業から作ります。 90日の観察が終わっている就業はもちろん、終わっていない直近の就業も、その時点までの記録として入れます。 打ち切りを扱えるモデルなので、直近の就業を捨てる必要がありません。

AIへ渡す前に整形する

1. 終了の理由をそろえる … 自由記述を「本人都合」「派遣先都合」「契約満了・その他」の3つに、担当者が決めた対応表で置き換えます。対応表に無い記述は人に回します
2. 出来事と打ち切りを決める … 90日以内の本人都合の終了だけを出来事（1）とし、派遣先都合・満了での終了と、90日を超えて続いた人は、その日で打ち切り（0）とします
3. 時点ごとの表を作る … 7日目の表は、7日目までに分かる項目だけで作ります。21日目・45日目の表は、その時点まで続いた人だけを入れ、そこまでの勤怠を加えます
4. 項目を数値にする … 職種・勤務時間帯は区分ごとの0／1の列にし、時給の差は前の就業との差額にします
5. 欠けている値を扱う … 初めて派遣で働く人は「前の就業の時給」がありません。0で埋めず、「初めての派遣」の列を立てて、差額は職種の平均との差で置き換えます
6. 派遣先の過去の傾向の扱い … 派遣先ごとの過去の早期終了の割合は、学習の対象期間より前のデータだけで計算します
7. 人数の少ない区分をまとめる … 年に数件しかない職種は「その他」にまとめます

2番目がいちばん大事な処理です。 派遣先の事業の都合で終わった就業を出来事に入れると、モデルはスタッフの様子ではなく、派遣先の業績を学んでしまいます。 本人都合と派遣先都合を分けられない記録は、学習から外します。

勤怠の数え方も、時点ごとに割合にそろえます。 週3日勤務の人と週5日勤務の人では、同じ7日間でも出勤の予定日数が違います。欠勤や遅刻は回数ではなく、予定日数に対する割合として列にします。 派遣先の休業日や、本人が事前に届けた休みは欠勤に数えません。

6番目も気を付けます。 同じ期間のデータで派遣先の傾向を計算すると、答えを先に見たのと同じことになり、学習のときだけ当たりが良く見えます。

AIに処理させる

させるのは、各時点で「90日目まで続く見込み」を出し、それに効いている項目を並べることだけです。

21日目以降は「そこまで続いた人の」見込みです。 lifelines の predict_survival_function には conditional_after を渡せるので、既に21日続いた人について、その先の見込みを出す形で計算できます。就業を始めた時点からの見込みを毎回出すと、続いている人ほど見込みが下がらず、2か月目の変化が見えません。

比例ハザードの仮定を確かめます。 Cox のモデルは、項目の効き方が時間を通じて一定であることを前提にしています。lifelines の check_assumptions は、項目ごとにこの仮定を検定し、満たさない項目と直し方の助言を出すとされています。勤務時間帯のように区分の少ない項目が仮定を満たさないときは、strata に入れて層ごとに基準を分けます。

3行目が、運用でいちばん起きやすい誤りです。 「通勤時間が効いている」は、通勤がつらいという意味ではありません。一覧に出た項目は、連絡のときに確かめる話題の候補にとどめます。

指示内容を固定する

生成AIは使わないので、プロンプトではなくPython の処理の要点を示します。

import pandas as pd
from lifelines import CoxPHFitter

H = 90
df = pd.read_csv("train_day7.csv")
df["duration"] = df["days_worked"].clip(upper=H)
df["event"] = ((df["end_reason"] == "self") & (df["days_worked"] <= H)).astype(int)

features = ["commute_min", "wage_diff", "first_dispatch",
            "same_job_exp", "days_to_start", "match_count",
            "shift_night", "absent_w1", "late_w1"]
cph = CoxPHFitter(penalizer=0.1)
cph.fit(df[features + ["duration", "event"]],
        duration_col="duration", event_col="event")
print(cph.concordance_index_)
cph.check_assumptions(df[features + ["duration", "event"]])

now = pd.read_csv("score_day21.csv")
sf = cph.predict_survival_function(now[features], times=[H],
                                   conditional_after=now["days_worked"])
now["stay_90"] = sf.loc[H].values
now["band"] = pd.cut(now["stay_90"], [0, 0.7, 0.85, 1.0],
                     labels=["高", "中", "低"])

決まりは3つです。 1つ目は、event を本人都合の終了だけで作ること。派遣先都合と満了は event=0（打ち切り）です。2つ目は、features に属性の列を入れないこと。列の一覧はコードの外の設定ファイルに置き、追加には営業部長と個人情報の担当の承認を要るようにします。3つ目は、21日目以降は conditional_after に、その時点までの就業日数を渡すことです。

区分の境目（0.7・0.85）は、最初は仮の値です。 過去のデータで「高」に入る人数がコーディネーター1人あたり毎週何人になるかを見て、連絡できる人数に合わせて決めます。 当たり方より、連絡しきれる人数に収まることを優先します。

出力形式を固定する

コーディネーターごとに、次の形の表をCSVで置きます。

効いている項目は、係数と、その人の値と平均との差の積の大きい順に3つ選びます。 項目名は担当者が読める言葉に置き換えます。「commute_min」ではなく「通勤75分」と書きます。

一覧の行は、たとえば次のようになります。

1行目のように初日以降の連絡が無い「高」の人が、その週の最初の連絡先になります。 3行目のような「低」の人は、決まりどおりの1か月目の連絡を入れるだけで足ります。

表にする理由は、並べ替えと絞り込みをコーディネーターに任せるためです。 band で絞ってから last_follow_date の古い順に並べる、という使い方を想定しています。見込みの数字そのものより、前回いつ話したかと合わせて見ることのほうが、順番を決めるのに役に立ちます。

model_version を必ず付けます。 モデルを入れ替えた週に見込みの並びが大きく変わったとき、スタッフの様子が変わったのか、モデルが変わったのかを分けるためです。

システムへ連携する

見込みは派遣管理システムに書き込みません。 スタッフの画面に見込みが表示されると、紹介や更新の場面で目に入り、使い道を守れなくなります。 一覧は担当のコーディネーターと、その上長だけが開ける共有フォルダに置きます。

人が確認する

1. 一覧を見て順番を決める … コーディネーターが「高」の人から見て、自分が知っている事情を加えて順番を決めます
2. 連絡する … 効いている項目を話題の候補にしつつ、本人の話を聞くことを優先します
3. 結果を記録する … 話した内容と、職場の困りごとの有無をフォローの記録に書きます
4. 派遣先に関わることを営業に渡す … 職場の環境や指示のしかたに理由があるものは、派遣先担当の営業と相談します
5. 月1回、上長が見る … 「高」と出て連絡しなかった人が終了していないか、「低」なのに終了した人がいないかを確かめます

連絡の話し方は、一覧の項目から入らないようにします。 「通勤が大変ではないですか」と最初に聞くと、本人は見張られているように感じます。「最初の1週間はどうでしたか」と広く聞き、話の中で通勤や仕事の内容に触れたら、そこを詳しく聞くという順にします。効いている項目は、聞き漏らしを防ぐための控えです。

5番目を省かないでください。 「低」なのに終わった人の記録は、モデルが見ていない理由が何かを教えてくれます。 そこから入力の項目を足すかどうかを決めます。

例外に対処する

下から2行目は、四半期の学習し直しのたびに起こりえます。 新しいデータで学習したモデルが必ず良いとは限りません。下がったときに前のモデルへ戻せるよう、モデルは版ごとに保存します。

記録を残す

• 毎週の書き出しのCSVと、時点ごとに作った表
• 出した見込み（stay_90・band・top_factors）と model_version
• モデルの版ごとの係数、一致度、check_assumptions の結果
• 終了の理由の対応表と、その更新の履歴
• 連絡の結果（フォローの記録）と、その後の実際の終了
• 特徴量の列の一覧と、追加・削除を承認した記録

最後の行は、使い道を守るための記録です。 誰かが便利だと思って年齢の列を足すことを防ぐには、列の追加に承認が要り、その記録が残る仕組みにしておくのが確実です。

見込みの保存期間も決めておきます。 90日の観察が終わり、当たり方の確認に使い終えた見込みは、一定期間の後に消すと決めます。