外から公開データを取って数えると、何が起きるか

この章は、BizOpsの調査結果ではなく、調査そのものから出てきたものである。

本調査は、公開されている求人票という「外にあるデータ」を集めて数えた。その過程で、外からデータを取って数えるときに起こりうることが8つ見つかった。これは求人票に限らず、社内のデータを集計するときにも同じ形で現れる。

第1稿ではこれらを2章・3章・4章に分散して書いていたが、性質としては結果ではなく方法論上の発見なので、この章にまとめた。

5.1 偽陽性は、「該当なし」という、もっともらしい結果として現れる#

本調査では3回起きた。求人票でないもの68件の混入、給与の金額だけの欠落、1社の1文が生んだ要確認フラグ21件である。

本調査でいちばん重要な方法論上の発見である。そして、3回起きた。

① スクリーニングの側 ― 求人票でないものが68件混入した#

自社独自ページから求人を抽出できるようにしたところ、求人票ではないものが混入した。

目視で 68件を除外し、その結果 13社が「確認不能」に戻った（除外の根拠は1件ずつ記録してある）。

ここで重要なのは、除外の前も後も、結果が「もっともらしく見えた」ことである。偽陽性が混ざった状態では、その社は「求人はあるが該当なし」と表示される。これはまったく異常に見えない。

② 内容分析の側 ― 金額だけが消えていた#

集計の途中まで、給与の「但し書きのみ」は 18件あった。そこから「金額を書かず、但し書きだけで済ませる企業が27%もいる」という所見を書きかけた。

これは誤りだった。

ある採用管理サービスのページは、ページを開いたあとに画面側のプログラムが金額を書き込む仕組みになっている。取得ツールは、書き込まれる前の文字を読んでいた。その結果、「給与」「年収」という見出しと但し書きだけが残り、金額だけが消えていた。該当サービスの求人49件のうち48件が、同じ形だった。

実ページを39件開いて確認し、値を入れ直した結果、「但し書きのみ」は 13件（15%） になった。

「金額を書かない企業が27%」は、もっともらしく、かつ誤った結果だった。給与欄の見出しは存在し、但し書きも存在したので、データとしては完全に自然に見えた。

再発を防ぐためにしたこと

• 値をどこから取ったかを列として記録した（取得時の本文／実ページで確認／本文の値が実ページと一致することを確認）
• 86件の内訳は、本文55件／実ページで確認26件／本文の値が実ページと一致5件
• 実ページの値を使ってよい条件を決めた。本文が取得時と同じ求人に限る（表示の区切りと会社紹介の段落の削除だけの違いは「同じ」とみなす）。求人が書き換わっていた3件と、取得時に給与欄が無かった1件は使わなかった
• 実ページの確認は取得の約3週間後である。この時間差も記録した

③ 絞り込みの側 ― 1社の1文が、要確認フラグの2割を生んでいた#

T8要確認107件のうち、根拠語が定型句だけの偽陽性は22件あった。調べると、そのうち21件は、G社の求人に載っている社員プロフィールの一文が原因だった。

求人を掲載した社員の自己紹介文であり、求人本文ではない。同じ一文は、本文を取得した155件のうち23件に出現する（機械的に確認）。

原因は、その媒体の本文抽出が求人本体と社員プロフィール・関連記事を分離できていないことである。1社の1文が、要確認フラグの2割を生んでいた。

3回とも、誤りは「エラー」としてではなく「自然な結果」として現れた。取得が失敗すれば気づく。成功したように見えて中身が違うときに、気づかない。

5.2 取れなかった社と同じ熱心さで、取れた社の中身を疑う#

該当48件のうち自社独自ページ由来は2件だけ、該当あり22社のうち20社は既知ATS経由で、偽陽性は「該当なし」側にしか出ていなかった。

5.1①で述べたとおり、最初の分析では、自社独自ページで取得できた12社の中身を1件ずつ見ていなかった。

取れなかった社は目立つので調べる。取れた社は「取れている」ので疑わない。0件だった社ばかり調べて、取れた社は疑っていなかった。

主要な結論が影響を受けていないことは、後から確認した。

偽陽性は「該当なし」側にしか出ていなかった。以降の議論は、いずれも既知ATS由来のデータに乗っている。

機械だけで信頼できるのは、既知の採用管理サービス（HRMOS／HERP／Talentio／Wantedly／en-gage）経由のデータに限られる。自社独自ページからの抽出は、目視の仕分けを前提にした手法である。

5.3 媒体を経由した文面は、企業の言葉ではない#

同じ1件の求人が、企業自身の採用管理サービスと転職媒体とで別のタイトルになっていた。タイトル分類は文字列で判定するので、どちらを見たかで結果が変わりうる。

本調査は「企業がどの動詞を使ったか（『決定する』か『推進する』か）」そのものをデータにしている。そのため、転職エージェント媒体に転載された文面は使わないと決めた。媒体側がリライトしたものだからである。

この原則には、調査中に得た具体的な裏づけが1件ある。H社の同じ1件の求人が、掲載先によって別のタイトルになっていた。

タイトル分類はタイトルの文字列で判定するので、どちらを見たかで分類結果が変わりうる。媒体版には「立ち上げ」「社内SE」という別の語が入り、職の印象も変わる。

同じ理由で、求人ページ上部に媒体が付けるタグ（「マネージャー・管理職採用」「上場企業」等）も、企業の文面ではないので要求スキルの判定に使わない。

リライトされた文面で権限を判定すると、測定対象そのものが壊れる。

5.4 受け皿の列がないと、「存在しない」と「見えない」を分けられない#

新設した4列（自動化構築・データ基盤・AI活用・指標設計）は、いずれも当初からあるS1・S2と同程度かそれ以上に点灯した。

要求スキルの列は、調査の途中で S10（自動化構築）・S11（データ基盤・MDM）・S12（AI活用）・S13（指標設計・指標管理）の4つを新設した。

新設した理由は、受け皿がないと、その要求が「その他」の自由記述に落ちて集計できなくなるからである。たとえばS13を作る前は、要件欄のKPI要求がすべて枠外に散らばっていた。

新設した4列は、いずれも既存のS1・S2と同程度かそれ以上に点灯した。

文章にすると、歓迎以上／必須の件数は、データ抽出／分析10件／5件、BI・ダッシュボード構築11件／3件、自動化構築7件／2件、データ基盤・MDM 8件／6件、AI活用21件／5件、指標設計・指標管理10件／5件である。

「Tech Ops型の求人は存在しない」という結論と、「測る列がないから見えない」という状態は、別のことである。本調査は、列を足すことでこの2つを分けた。足した結果、Tech Ops的な要求は確かに存在するが、必須要件としては少ないことが分かった。

列を足したあとの作業にも、注意点が1つある。S13の割り当ては、過去の作業メモからではなく、155件の要件欄を機械的に走査してやり直した。メモから拾っていたら、1件を取りこぼしていた。

「受け皿が無かったせいで見えていなかったもの」を探す作業を、記憶に頼って行ってはいけない。

5.5 本調査で用いたLLMは、判定が不安定な項目を自己検知できなかった#

内部診断の一致率は全体75.5%、フラグありのセル41.7%、フラグなし84.9%だが、F3・P1では一致率が低いのにフラグが1件も立たなかった。

本調査は、10項目のうち 2項目（F3 指標の設計、P1 その決定権）だけを人が一次コーダーとし、残りをLLM（Claude）が担当した。この分け方には測定上の根拠がある。

調査の途中で、LLMに同じ11件を規則だけで再コードさせる内部診断を行った。

つまりフラグは有効に働いている。迷ったと言ったセルは、実際に一致率が低い。

ところがF3とP1では、一致率が低いのにフラグが1件も立たなかった。本調査で用いたLLMは、この2項目で自らの判定の不安定さを検知できなかった。

そこで、不安定だと分かった2項目だけを人が一次コーダーとして持ち、その2項目にはLLMがコードを付けない設計にした。LLMは、指標・数値に関する記述とその述語・射程を原文のまま抽出するところまでを担当する。

この設計の要点は、「どの項目を人が持つか」を、思い込みではなく測定結果で決めたことである。

全項目を人が読むのが理想だが、155件×30項目超の工数は現実的でない。どこに人手を置くかは、費用の問題ではなく測定の問題として決められる。

なお、これは「フラグが万能ではない」ことも意味している。最終的な一致率の測定（第4段階）でも、不一致だった14セルのうち13セルはフラグが立っていなかった（付録A）。

5.6 定性的な判断を量的な変数に変えると、別のものになる#

当初の設計にあった類型ラベルは、量的な変数に落とすと別のものになってしまうため採用しなかった。

当初の設計では、各求人に類型ラベル（Tech Ops型／Revenue Ops型／Corporate Ops型／複合／非BizOps／判別不能）を名義変数として付け、実務者の読みとの一致を見る予定だった。

この設計は採用しなかった。理由は、調査者本人の言葉で書ける。

【引用・調査者の決定・2026-09-12】

「この条件があるからこれ、という判定ではなく、文章を読んで判定しているため極めて定性的。よって定性的な記述にとどめたい。」

実務者が求人票を読んで「これはRevOps型だ」と判断するとき、その判断は条件の組み合わせではない。機械的なラベルに落とすと、落とした瞬間に「条件を満たしたからこの型」という別のものに変わってしまう。

そこで本調査は、

• 職務内容の合計だけを主データとして持ち、
• 類型は、成果物の中で定性的に記述する

という形にした。

内容分析では、「定性的な判断を量的な変数に変換すること」が方法の中心にある。しかし、変換すると別のものになってしまう判断がある。本調査は、その線を1か所で引いた。

類型を名義変数にしなかったこと自体が、方法論上の判断として記録に値する。

5.7 規則を細かく書いても、判定例を渡さなければ判定は再現しない#

判定例を渡さないと、コードブック自身が例示として確定させている値と食い違う値が出た。渡し方も効き、原文の断片を引いた側は判定例が当たる14件のうち13件が再現した。

調査の終盤で、最初にコードを付けた20件を最新の規則で付け直した。

このとき、1回目は規則の文章だけを渡し、コードブックに載せている判定例（アンカー）を渡さなかった。その結果、コードブック自身が例示として確定させている値と食い違う値が出た。アンカーを渡して付け直した2回目は、例示どおりに再現された。

規則を細かく書いても、判定例を渡さなければ判定は再現しない。判定例はコードブックの付録ではなく、コーディング手順に組み込むべき構成要素である。

同時にこれは限界でもある。アンカーを渡すと値が例示に寄るということは、アンカーの選び方が結果を左右するということでもある（7章 17）。

この観察には続きがある。公開前に F6・F7 を別のコーダーに盲検で付け直してもらったとき、今度は判定例を渡した。判定例が当たる14件のうち13件は例示どおりに再現した。再現しなかった1件は、前回アンカー無しで食い違ったのと同じ求人である。違いは渡し方にあった。再現した側は原文の断片をそのまま引いて渡しており、再現しなかった側は規則を言い換えて渡していた。

判定例は、規則の言い換えではなく原文の断片として渡さなければ効かない。

これは限界を弱める発見ではない。原文の断片を渡すほど、値はその断片に寄る。

5.8 落とさずに記録すると、点推定ではなく「幅」で書ける#

厳しい規則で主データを作りつつ漏れた記述を別の列に記録したことで、権限17%〜41%・規則の影響＋7件・訴求文だけを根拠にした2セル、という3つを幅で書けるようになった。

判定規則を厳しくすると、規則から漏れた記述は消える。消えた記述は後から戻せない。そこで本調査は、厳しい規則で主データを作りつつ、規則から漏れたものを別の列に記録する設計をとった。

この設計によって初めて書けるようになったことが、3つある。

1. 「権限の点灯は17%〜41%の幅で動く」（4.2.1）。単一の点推定より、この幅のほうが正確な記述である
2. 「訴求文まで読んでいるから権限が多く見えるのでは」という反論に、数字で答えられる（4.2.4）。権限が点灯したセルのうち、訴求文だけを根拠にしたものは2セルしかない
3. 「規則が落としているだけでは」という問いに、＋7件という幅で答えられる（4.1.3）

落とさずに記録するのは、後で規則を緩めるためではない。「規則をどう置いても動かない事実」がどれかを、示せるようにするためである。

5.9 「規則を外した値」を記入してもらうと、規則が混じる#

規則を外したはずの値が4行で主データを下回っており、補正しない生の記入値では4領域3以上が42件ではなく40件になる。

5.8 の「影の集計」は、規則を適用しなかったらどうなるかを、別の表で記入してもらうという形で作った。記入表には「この表では規則を当てないでください」と明記し、判定の目安にも書いた。

それでも、規則は混じった。

規則を外した値を主データと突き合わせたところ、4行で、規則を外した値のほうが主データより低くなっていた。規則を外して値が下がることは、定義上ありえない。記入した本人が、規則を当てないはずの表で「これはクライアントワークだから」と判断していたということである。

重要なのは、これが記入ミスではないことである。規則は、いったん身につけると読み方そのものに入り込む。「この表では当てないでください」という指示は、規則を知らない状態を復元してはくれない。

対処として本調査がしたこと

• 規則を外した値は、主データを下回らない（単調性）という機械的な検算を後から当てた
• 下回っていた4行は、主データの値に戻した
• 補正しない生の値だと、4領域の合計が3以上になるのは42件ではなく40件になる（4.1.3）

規則を外した値を人に聞くときは、「外してください」と書くだけでは足りない。外したはずの値が、外す前の値を下回っていないかを、後から機械的に検算する必要がある。

そして、この検算で見つかる誤りには向きがある。今回の4行は、すべて規則を外した値を低く見積もる方向だった。つまり、検算をしなければ「規則を外してもたいして増えない」という、本調査の主張に都合のよい方向に誤るところだった。

5.10 この章のまとめ#

本調査では3回起きた。求人票でないもの68件の混入、給与の金額だけの欠落、1社の1文が生んだ要確認フラグ21件である。