稼働開始時期のミスマッチを防ぐには｜98.8%記載でも揃わない2,035通り

稼働開始時期は98.8%書かれている｜それでも揃わない理由

稼働開始時期のミスマッチは、メールに書かれていないから起きるのではなく、書き方が2,035通りに分かれていて比較できないから起きています。

案件側でも人材側でも、稼働開始時期はほぼ必ず書かれています。

にもかかわらず、提案や面談まで進んでから時期が合わないと判明する場面はなくなりません。

この記事では、Dot Linkが処理した50,419件のメール抽出データをもとに、稼働開始時期という項目で実際に何が起きているのかを整理します。

稼働開始時期のミスマッチが表面化するタイミング

稼働開始時期のミスマッチは、提案や面談まで進んだ後に判明することが多く、そこまでにかけた時間がそのまま失われます。

商流のように「合わなければ成立しない」とすぐ気づく項目と違い、稼働開始時期は先送りされやすい条件です。

メールに書かれてはいるため、確認したつもりで先へ進んでしまいます。

提案してから時期が合わないと判明する

もっとも痛いのは、スキルも単価も噛み合った候補で時期だけが合わないケースです。

面談の日程まで詰めた段階で「その方は来月末まで動けない」と分かると、案件側の期待も、人材側の稼働計画も同時に崩れます。

商流や単価は最初に確認する習慣が根づいている一方、稼働開始時期は最後に確認される項目になりがちです。

「4月～」がどの年かで話が食い違う

もうひとつよくあるのが、年の解釈が送り手と受け手でずれるケースです。

メールに「4月～」とだけ書かれていた場合、それが今年の4月なのか翌年の4月なのかは、本文だけでは決まりません。

受け取った側が直近の4月だと読み、送り手は翌年のつもりだった、という食い違いは、提案が進むまで表に出ません。

書かれているのに解釈が一致しないという状態が、稼働開始時期のミスマッチの正体です。

記載率98.8%｜稼働開始時期はほぼ必ず書かれている

集計対象50,419件のうち、稼働開始時期の記載があったのは49,836件、全体の98.8%でした。

つまり稼働開始時期は、商流や単価と並んで、SESメールにほぼ必ず含まれる条件です。

「書かれていないから確認できない」という前提は、この項目に関しては当てはまりません。

案件側98.7%と人材側99.0%でほぼ差がない

記載率は案件側と人材側でほとんど変わりませんでした。

案件側は25,363件中25,028件で98.7%です。

人材側は25,056件中24,808件で99.0%です。

どちらか一方だけが書き漏らしているという偏りはなく、両側とも時期を伝える意思を持ってメールを書いています。

記載漏れがミスマッチの原因ではない

この98.8%という数字は、課題の在りかを絞り込んでくれます。

稼働開始時期のミスマッチを減らすために「時期を必ず書いてもらう」よう取引先へ働きかけても、改善できる余地はほとんど残っていません。

対策すべきなのは、すでに書かれている49,836件を、どうすれば同じ基準で比べられるかという側です。

それでも揃わない｜稼働開始時期の表記は2,035通り

記載のあった49,836件を重複を除いて数えると、稼働開始時期の表記は2,035通りに分かれていました。

書かれているのに揃わない、というのがこの項目の本質的な難しさです。

以下の割合は、すべて記載のあった49,836件を母数にしています。

年が書かれていないのが85.3%

もっとも影響が大きいのは、年が書かれていない表記の多さです。

年が明記されていたのは7,346件、記載のあったレコードの14.7%にとどまりました。

裏を返すと85.3%は年の情報を持たず、「4月～」「7月～」といった月だけの表記になっています。

月だけの表記は、受け取った日付と突き合わせて初めて意味が定まるため、メール単体では確定しません。

「即日」と「即日～」が別の表記として分かれる

次に効いてくるのが、同じ意味なのに文字列が違うという分かれ方です。

出現頻度の上位8件を並べると、その様子がそのまま見えてきます。

最上位の「即日」と「即日～」は意味としてまったく同じですが、文字列としては別データとして積み上がります。

この2つを合わせると9,881件で、波ダッシュが1文字あるかどうかだけで集計が二分されている状態です。

なお「即日」を含む表記は全体で14,938件、記載のあったレコードの30.0%を占めます。

同じことは月の表記でも起きています。

同じ7月の開始を伝えるつもりで書かれた表記が、少なくとも6通りに分かれています。

年の有無、ゼロ埋めの有無、波ダッシュの有無、区切り文字の違いが、そのまま別の値になります。

1つの欄に複数の候補が同居する8.4%

さらに、1つの稼働開始時期に候補が複数入っているケースがあります。

「/」で複数の候補が並記されている表記は4,173件、8.4%ありました。

上位20位の中にも「即日～/5月～/6月～」が936件、「即日～/4月～/5月～」が385件と入っています。

これは複数人材をまとめて紹介するメールなどで起きる書き方で、1件の値として読むと意味が通りません。

幅のある表現と1回だけの表記が積み上がる

日付ではなく幅を持った言葉で書かれるケースもあります。

「随時」「応相談」「未定」「調整」といった表現を含む表記は1,015件、2.0%でした。

割合としては小さいものの、これらは日付に変換できないため、機械的な比較からこぼれ落ちやすい部類です。

そして2,035通りのうち881通り、異なり表記の43.3%は1回しか出現していません。

つまり新しいメールを受け取るたびに、社内の対応表に無い書き方に出会う可能性が常に残ります。

商流の表記ゆれとは問題の種類が違う

稼働開始時期の課題は、商流の表記ゆれとよく似て見えますが、性質は別物です。

商流は「そもそも書かれていないことがある」ため、条件を確定できないという課題を抱えています。

対して稼働開始時期は98.8%書かれているのに、揃っていないから比較できないという課題です。

前者は不足の問題で、後者は不統一の問題であり、打つ手も変わります。

書かれていない項目は確認して補うしかありませんが、書かれている項目は受け取る側で読み替えを揃えれば済みます。

商流の生テキストが何通りに分かれていたかは、別の記事で集計しています。

商流表記は本当は何通りある？メールの表記ゆれの実態

なぜ稼働開始時期の書き方が揃わないのか

書き方が揃わないのは、送り手ごとにメールのテンプレートも運用も違い、業界共通の形式が存在しないためです。

送り手には、自社のフォーマットを他社に合わせて変える理由がありません。

自社の中では「7月～」で十分通じますし、社内の他のメンバーも同じ読み方をします。

年を省くのも、送った時点では今年のことだと自明だからです。

つまり表記のばらつきは、書き手の不注意ではなく、それぞれの社内では正しく機能しているフォーマットが並んだ結果にすぎません。

送り手を揃えにいく発想では解けないという点が、この問題の出発点になります。

そして受け取る側から見ると、取引先の数だけフォーマットが増えていきます。

稼働開始時期のミスマッチを防ぐ実務の考え方

ミスマッチを防ぐ要点は、比較する前に表記を揃え、年の解釈を確定させ、幅のある表現は幅のまま扱うことです。

順番を守らずに「4月～」と「即日」を並べて眺めても、判断の材料にはなりません。

以下は、社内のオペレーションとして押さえておきたい4点です。

比較する前に表記を揃える

案件と人材を並べる前に、稼働開始時期を同じ形式へ変換する工程を挟みます。

「即日」「即日～」「随時～」がばらばらのまま並んだ一覧では、絞り込みも並べ替えも成立しません。

社内でどの形式を基準にするかを先に決め、そこへ寄せてから比較に入ります。

年の解釈を確定させてから提案する

年が書かれていない表記は、受信日を基準に「どの年として扱うか」を明示的に決めます。

重要なのは、決めた解釈を記録に残し、後から確認できる状態にしておくことです。

暗黙のうちに直近の月として読んでしまうと、認識の食い違いが提案の直前まで表面化しません。

年が書かれていない案件・人材については、提案前のひと言確認を習慣にするのが確実です。

幅のある表現は幅のまま扱う

「随時」「応相談」「調整」といった表記を、無理に特定の日付へ丸めないようにします。

幅のある条件を1点の日付に変換すると、本来なら成立したはずの組み合わせが、日付のずれだけで候補から消えます。

幅は幅として持たせたうえで、案件側の希望時期と重なるかどうかで判断します。

稼働開始時期がマッチングのどの段階で使われるかは、2段階フィルタの記事で扱っています。

AIマッチングはどう案件と人材を結びつけるのか｜2段階フィルタの仕組み

確認を提案の前に前倒しする

稼働開始時期の確認は、面談調整の直前ではなく、候補を絞る段階へ前倒しします。

特に「/」で複数候補が並記されているメールは、どの候補の話をしているのかを最初に確定させます。

複数候補が並記されたケースが8.4%あるという前提で運用を組むと、後戻りが減ります。

メール転送だけで稼働開始時期を正規化する

Dot Linkは、いつもの営業メールの配信リストにses@dot-link.jpを1つ足すだけで導入できます。

届いた案件・人材メールから、稼働開始時期を含む条件を自動で抽出し、比較可能な形へ正規化します。

営業担当の方が表記の読み替え表を作ったり、新しい書き方を見つけるたびにルールを追加したりする必要はありません。

正規化すると同じ基準で並べられる

「即日」も「即日～」も「2026年07月01日～」も、正規化を通せば同じ物差しの上に乗ります。

表記の違いではなく条件が合うかどうかだけで比較できる状態になるのが、正規化を挟む目的です。

Dot Linkのマッチングは自由文のメールから直接候補を出さず、この正規化済みデータを突き合わせます。

商流と単価をどう読み取っているかは、こちらで解説しています。

商流・単価をメールから自動判定する方法｜見落としを防ぐには

書かれていない年は推測で埋めない

正直に書いておくと、メールに書かれていない年を復元することはできません。

「4月～」とだけ書かれた記載を、勝手に「2026年4月」と決めつける処理はしていません。

根拠のない項目を推測で埋めると、もっともらしい値が入ったまま誤った比較が進んでしまうためです。

Dot Linkは根拠がない項目を「不明」として扱い、判断が必要な箇所を営業担当の方に残します。

自動化がどこまで届き、どこから人の確認が要るのかは、こちらで整理しています。

AI駆動SESとは｜メール処理・マッチングはどこまで自動化できるか

揃えてから比べるという順序

稼働開始時期のミスマッチは、確認の丁寧さではなく、比較の前に表記を揃えるという順序で防げます。

50,419件を集計して見えたのは、稼働開始時期が98.8%書かれているという事実と、その書き方が2,035通りに分かれているという事実でした。

書かれているものを揃えるのは仕組みの仕事で、書かれていないものを確認するのは人の仕事です。

この線引きをはっきりさせると、営業担当の方が時間を使うべき確認だけが手元に残ります。

実際の受信メールで稼働開始時期がどう揃うか確かめたい方は、まず1通転送して結果を見てみてください。

よくある質問

稼働開始時期が「即日」の人材はすぐ提案してよいのですか

「即日」と書かれていても、そのまま今日から稼働できるとは限りません。

集計上「即日」を含む表記は14,938件、記載のあったレコードの30.0%を占めますが、これは送信時点での状況を表した記述です。

メールの受信からしばらく経っている場合、すでに別の案件が決まっている可能性があります。

提案の前に現在の状況を確認する運用は、表記が「即日」であっても変わりません。

「即日～/5月～/6月～」のように複数の時期が書かれた場合はどう読めばよいですか

1件の条件ではなく、複数の候補が1つの欄に詰め込まれた記述として扱ってください。

このような並記は記載のあった49,836件のうち4,173件、8.4%ありました。

複数人材や複数ポジションをまとめて紹介するメールで起きやすく、どの候補についての時期なのかは本文全体を読まないと決まりません。

先頭の値だけを拾って登録すると誤った条件で比較されるため、どの対象の時期かを確定させてから扱うのが安全です。

年が書かれていない稼働開始時期はDot Linkでどう扱われますか

年を推測で補うことはせず、書かれていた内容と根拠を保持したまま扱います。

年が明記されていたのは記載のあったレコードのうち7,346件、14.7%にとどまり、残りの85.3%は年の情報を持ちません。

これを機械的に直近の年へ丸めてしまうと、翌年開始の案件が今年の候補として比較され、誤った組み合わせが生まれます。

根拠のない値を埋めないという方針のため、年の確定が必要なケースは営業担当の方の確認に委ねる設計です。

参照データ算出方法

本記事の数値は、Dot Linkが処理したメール本文抽出済みレコードの稼働開始時期フィールドを集計したものです。

1レコードが1通のメールから抽出した1件の案件または人材情報にあたります。

集計期間は2026年3月17日〜8月14日、母数は50,419件です。

以下のクエリの[メール本文抽出済みテーブル]・[稼働開始時期]・[抽出日時]・[レコード種別]は、実際のテーブル名・カラム名のプレースホルダです。

母数と記載率:

SELECT
  COUNT(*) AS total_records,                                         -- 母数（N）
  COUNTIF([稼働開始時期] IS NOT NULL AND TRIM([稼働開始時期]) != '') AS has_value
FROM `[メール本文抽出済みテーブル]`
WHERE [抽出日時] BETWEEN '2026-03-17' AND '2026-08-14';

案件側・人材側の内訳:

SELECT
  [レコード種別] AS record_type,                                      -- 案件 / 人材
  COUNT(*) AS total_records,
  COUNTIF([稼働開始時期] IS NOT NULL AND TRIM([稼働開始時期]) != '') AS has_value
FROM `[メール本文抽出済みテーブル]`
WHERE [抽出日時] BETWEEN '2026-03-17' AND '2026-08-14'
GROUP BY record_type;

表記の異なり数と1回のみ出現する表記:

WITH expressions AS (
  SELECT
    TRIM([稼働開始時期]) AS expression,
    COUNT(*)            AS occurrences
  FROM `[メール本文抽出済みテーブル]`
  WHERE [稼働開始時期] IS NOT NULL
    AND TRIM([稼働開始時期]) != ''
    AND [抽出日時] BETWEEN '2026-03-17' AND '2026-08-14'
  GROUP BY expression
)
SELECT
  COUNT(*)                  AS distinct_expressions,  -- 異なり表記数
  COUNTIF(occurrences = 1)  AS singletons             -- 1回しか出現しない表記
FROM expressions;

表記パターン別の割合（母数は記載のあったレコード）:

SELECT
  COUNT(*) AS records_with_value,
  COUNTIF(REGEXP_CONTAINS([稼働開始時期], r'[0-9]{4}\s*年|[0-9]{4}-')) AS has_year,           -- 年が明記
  COUNTIF(REGEXP_CONTAINS([稼働開始時期], r'即日'))                    AS immediate,          -- 「即日」を含む
  COUNTIF(REGEXP_CONTAINS([稼働開始時期], r'/'))                       AS multi_candidates,   -- 「/」で複数並記
  COUNTIF(REGEXP_CONTAINS([稼働開始時期], r'随時|応相談|未定|調整'))   AS flexible            -- 幅のある表現
FROM `[メール本文抽出済みテーブル]`
WHERE [稼働開始時期] IS NOT NULL
  AND TRIM([稼働開始時期]) != ''
  AND [抽出日時] BETWEEN '2026-03-17' AND '2026-08-14';

出現頻度の高い表記:

SELECT
  TRIM([稼働開始時期]) AS expression,
  COUNT(*)            AS occurrences
FROM `[メール本文抽出済みテーブル]`
WHERE [稼働開始時期] IS NOT NULL
  AND TRIM([稼働開始時期]) != ''
  AND [抽出日時] BETWEEN '2026-03-17' AND '2026-08-14'
GROUP BY expression
ORDER BY occurrences DESC
LIMIT 20;