この調査は、どんな手続きで行われたか

本文を読むのに必要なことは2章にまとめてある。この付録は、再現と検証のために手続きを記録したものである。

A.1 対象の選び方#

母集団598社→標本200社→対象層143社→求人938件。求人本文まで到達できなかった68社（対象層の48%）を分母から外していない。

母集団と標本#

標本200社の業種の内訳（調査用業種は7区分。主業で判定している）

企業単位の割合（到達率・該当率など）は、対象層143社を分母とする。標本200社を分母にした値は出さない。

なぜ東証グロース市場を母集団にしたか#

いちばんの理由は、名簿が確定していることである。

本調査が測りたいのは、成長段階の企業における職務設計である。それなら未上場スタートアップを対象にするのが自然に見えるが、未上場企業には確定した名簿が存在しない。「シリーズB以降の企業」を母集団にしようとすると、その一覧をどこから取るかで恣意性が入り、分母が説明できなくなる。分母が説明できない調査は、率を報告できない。

東証グロース市場を選ぶと、この問題が消える。

トレードオフは、上場済みであるため「シリーズB期の立ち上げ需要」が測れないことである。

これは受け入れた。本調査が測りたいのはタイトルと中身の乖離であり、乖離が大きいのはBizOpsという言葉を使っていない層のほうだからである。「経営企画」「業務改革」という名義が濃いグロース企業は、避けるべき対象ではなく本命の観察対象である。

（実際、3.6で見るとおり、BizOpsと名乗る求人は938件中2件しかなく、機能はT8＝「その他」に分類された求人の中に分散していた。）

なぜ2業種に絞ったか#

事前に基準を決めて絞った層化抽出である。

標本200社を全社当たるのではなく、T1〜T7（BizOps隣接職）が出る見込みの高い層に絞った。製造・医療・ヘルスケア・EC系は、それまでの手作業スクリーニングの傾向からBizOps隣接職の掲載可能性が低く、ここに工数を使う費用対効果が低いと判断した。

分母は「グロース200社」ではなく「グロース200社のうち、事前基準で絞った143社」になる。絞り込みの基準を明示してあるので、これは正当な層化抽出である。

★ 設計時の基準と、実際に絞られた層は一致していない（限界 25・26）#

設計時の絞り込み基準は「従業員数が一定以上、かつ 調査用業種が SaaS・IT／人材・サービス」の2条件だった。しかし実際に絞られた対象層143社は、業種の1条件だけで選ばれている。

標本200社のうち SaaS・IT は89社、人材・サービスは54社で、合計143社。つまりこの2業種に属する社は、規模を問わず全社が対象層に入っている。従業員数のしきい値は適用されていない。

さらに、従業員数そのものを変数として保持していない。企業マスタにも取得結果にも従業員数・上場年の列がなく、上の「利点」で挙げた「成長段階を示す変数を推測なしで持てる」という利点を、本調査は使っていない。

この結果、次のことができていない。

• 規模（従業員数）と該当率の関係を測れない。本調査が示せたのは掲載求人数との関係だけである（3.5）
• 「規模が一定以上の企業」という当初の想定より、対象層が広い。小規模な社が含まれており、それが「求人が1〜4件の20社は該当率0%」の一部を作っている可能性がある

従業員数は有価証券報告書から後から取得できる。次に手を入れるならここである（6.6）。

分母から外していないもの#

求人本文まで到達できなかった68社（対象層の48%）を、分母から外していない。

到達できた75社だけを分母にすると、「求人を出していることが確認できた企業のうち◯%」という別の指標になり、数字は必ず良く見える。本調査の問いのひとつは「そもそも観測できるのか」なので、観測できなかった社を分母に残すことが測定の一部である。

求人の母数#

文章にすると、検出した求人タイトル1,213件から、重複掲載120件・新卒／インターン99件・パート30件・アルバイト26件の計275件を除いて、母数938件になる。

本稿では、スクリーニング母数を「求人938件」と明記する。86件・66件など別の分母を用いる集計では、その都度、分母を示す。

A.2 スクリーニングの設計#

求人タイトルは文字列だけで分類し、既知の採用管理サービス経由で0件だったとき以外は「掲載なし」ではなく「確認不能」に落とした。

処理の流れ#

コーポレートURL
  ↓ ① 採用ページを見つける
採用ページ（多くはLP＝入口にすぎない）
  ↓ ② 実際の求人掲載先を特定する ★ここが最大の難所
求人一覧ページ（HRMOS / HERP / Talentio / Wantedly / en-gage / jobcan / 自社独自ページ）
  ↓ ③ 求人タイトルを全件取得する
求人タイトル一覧
  ↓ ④ タイトルの文字列でスクリーニングする
該当求人
  ↓ ⑤ 本文を取得する

タイトル分類（T分類）#

求人タイトルの文字列のみで判定する。本文は見ない。

本文を読んで分類を決めると、本調査の関心のひとつである「タイトルと中身の乖離」が測れなくなる。タイトルは企業がその職をどう名付けたかであり、本文は何をやらせるかである。この2つは別のデータとして扱う。

複数の判定語に当たった場合はコード番号の小さい方を採る（例：「事業企画（BizOps）」→ T1）。併記があった事実は備考に残す。

T6の判定語は、調査の途中で5語から12語に増やした。

増やした理由は、当初の5語で20社を処理して T6 が1件も出なかったためである。判定語を足すときは、増える件数だけでなく、増える求人の中身を並べて確認してから決めた（本調査の運用原則）。件数だけで足すと、判定語の設計で結論を作ってしまう。

「掲載なし」と断定してよい条件#

「求人掲載なし」と断定してよいのは、既知ATS経由で取得できて0件だったときだけ。次はすべて「確認不能・要目視確認」に落とす。

• 自社独自ページで0件
• 求人一覧は取れたが、求人へのリンクが1本もない
• HTTPエラー（403・404・SSLエラー）
• JavaScript描画で本文が取れない
• robots.txt が読めず、取得を見送った

ファネルの分母を汚さないことを、取得件数を増やすことより優先した。その結果、確認不能が68社（48%）と大きくなっているが、「求人掲載なし」と断定した社は143社中1社もない。

企業自身の言葉だけを使う#

転職エージェント媒体（doda、リクルートエージェント等）に転載された文面は使わない。媒体側がリライトしたものであり、企業自身の言葉ではないためである。求人ページ上部に媒体が付けるタグ（「マネージャー・管理職採用」「上場企業」等）も使わない。

この原則の裏づけ（H社の実例）は 5.3 にある。

歩留まりは2段階で報告する#

この2つを混ぜてはいけない。混ぜると「求人情報が機械的に読める状態にあるか」という指標の意味が消える。

A.3 内容分析の設計#

該当48件とT8ゲート該当43件を合わせた91行にコードを付け、本文が同一の5行を束ねて個別コード86件とした。

読んだ対象#

T8要確認107件は、本文に「KPI設計」「業務プロセス」「部門横断」「BI」等が出現するものを機械が拾ったものである。この要確認フラグはT分類を変えない。人が全項目を読む候補を絞り込むためだけに使う。

107件（本文がほぼ同一の求人を束ねると103クラスタ）を1件ずつ読み、自社の事業運営に対して、F1〜F4領域のいずれかが担当業務として本文に書かれているものを該当とした。結果は 該当43／非該当60。

何を記録したか#

値は 2＝明記／1＝示唆／0＝記載なしの3値で、迷ったら低い方に倒す。

F7は必ず「手続き・処理・事務の反復」と定義を添えて書く。当初は「定型業務の遂行」と書いていたが、この表記だと営業やマーケティングの実務まで含むと読まれる。実際、一致率の測定で、不一致の原因のひとつがこの読み違いだった。

誰が何を判定したか#

この分け方の根拠（内部診断の結果）は 5.5 にある。

汚染を避けるための手順#

1. LLMが全件に F1・F2・F4〜F7、P2・P3、S、W、R を付ける
2. あわせて F3根拠文言とP1根拠文言を原文のまま抽出する。コードは付けない
3. P1〜P3を1以上としたセルには、根拠文言と根拠層を記録する
4. S1〜S13を1以上としたセルには、対象（自社／顧客・プロダクト／判別不能）を記録する
5. コードは本文クラスタの代表行に1回付け、同一クラスタ内に複写する
6. 人が、抽出された文言から F3 と P1 を付ける
7. 人がLLMの迷いフラグを判定する
8. 事前登録したseedで無作為8件を抽出し、人が盲検で8項目を付ける（一致率の測定）

M（実務者の読み）は、LLMのコードを見る前に付ける。これが「LLMが先に出すとアンカーになる」問題への歯止めである。人に記入を依頼する表には、本文・根拠文言・対象までしか載せない（LLMのコード・見立て・区分は載せない）。この条件は、渡す前に機械的に照合して確認している。

落とさずに記録する#

この設計が何を可能にしたかは 5.8 にある。

規則の版管理#

コードブックは v1.0 から v1.5 まで改訂した。v1.2（調査の中盤）で定義を凍結し、以降は定義を変えていない。凍結後に行ったのは、列の追加と、すでに運用していた判断の文書化、規則の線引きの明確化だけである。

値を動かした訂正はすべて訂正台帳に1件ずつ記録した（2026-09-14時点で 287件）。各行に、対象・列・旧値・新値・適用した規則・理由・決定者・日付が入っている。

規則の追加・訂正は、すべて実務者（調査の責任者）が決めた。LLMが提案して採用された場合も、承認を取ってから「決定」として記録している。

公開前の F6・F7 再点検（2026-09-14）#

一致率の測定で F6・F7 の項目別一致が基準（8割）を下回っていた（A.4）ため、公開前にこの2項目を個別コード86件の全件で付け直した。

• 作業条件：コードブック本体・コード表・過去の集計を見ていない別セッションのコーダーに、規則と判定例だけを渡して行った
• 結果：172セル中 146セルが一致。割れた26セルを実務者が1セルずつ判定し、18セルを訂正・8セルを現状維持とした。訂正はすべて台帳に記録している
• この数字を一致率としては報告しない。LLM同士の再コードであり、二者間の信頼性の測定ではない（第3段階と同じ性格の内部診断）。報告値は第4段階の 50／64＝78.1%・κ0.34 のままで、再計算していない
• 86件のうち14件は、その行の記述が判定例そのものに使われている。この14件について再点検は独立ではない（独立なのは72件）
• コーダーが迷いのフラグを立てたのは16行で、割れた26セルのうち11セルにはフラグが立っていなかった（5.5 と同じ方向の観察）
• 判定例の渡し方について得られた知見は 5.7 にある

A.4 一致率と、その読み方#

報告値は第4段階の50／64＝78.1%・κ0.34（重み付きκ0.45）で、基準の8割を下回ったのはF1・F6・F7・P3の4項目である。

この節は、本調査でいちばん正直に書く必要がある節である。

信頼性の測定は4回行ったが、報告値として使えるのは最後の1回だけである。

第4段階の設計#

• 母集団：32行。個別にコードを付けた66行から、コードブックや作業記録に値が出ている29行と、慎重を期して除いた5行（権限の一覧表に載せた3行／職務の性格を要約して記録した2行）を除いた
• 抽出：母集団を行番号順に並べ、事前登録したseed（20260825）で8件を無作為抽出
• 抽出のタイミング：LLMのコードがすべて確定し、将来形の記述に関する再点検も終えた後
• 項目：F1・F2・F4〜F7・P2・P3 の8項目。分母は8項目×8件＝64セル

- F3・P1 は人が一次コーダーなので、二者の一致率は定義できない。10項目中8項目の一致率である

• 作業条件：人は、本文と入力欄と判定の目安だけが載った表で作業した。コードブックもコード表も見ていない

- ただし F3・P1 は人がすでに全件付け終えているので、この8件も既読である（8項目に限るので盲検は成立する）

結果#

文章にすると、第4段階の項目別の一致は、F1 が8件中4件（50%）、F2 が8件（100%）、F4 が7件（88%）、F5 が8件（100%）、F6 が5件（63%）、F7 が4件（50%）、P2 が8件（100%）、P3 が6件（75%）である。

基準（8割）を下回ったのは F1・F6・F7・P3 の4項目。

この数字をどう読むか（3つの但し書き）#

① 母集団から難しい行を除いている。値が作業記録に出ている行を除いた結果、規則を議論した難しい求人が母集団から抜けている。一致率は、全体を対象にした場合より高めに出ているおそれがある。

② 抽出後に、除くべきだった行が1件あると気づいた。抽出された8件のうち1件は、記録の中で職務の性格を要約されており、除外した他の行と同じ理由で母集団から除くべきだった。事前登録を守り、入れ替えていない。その行を除いた値（44／56＝78.6%）を感度分析として併記する。この併記を決めたのは抽出の後であることを明記する。

③ 事後の確認は、一致率とは別に書く。一致率を計算し記録したうえで、不一致14セルの中身を確認した。一致率は再計算していない。

• F7 の4セルは、人側が定義を読み違えたものだった（「手続き・処理・事務の反復」を、営業実務まで含むと読んだ）。規則は変えず、項目名に定義を併記することにした
• 残り10セルは、LLMの値が妥当7／人の値が妥当3。コードの訂正は2セルにとどまった
• LLMが迷いフラグを立てていたのは1セルだけで、不一致14セルのうち13セルはフラグが立っていなかった

凍結の規則：不一致の中身を見たあとにコードを訂正した場合、その訂正後の値で一致率を再計算してはならない。実測値は訂正前の値で据え置き、訂正は台帳に別に記録する。本調査はこの規則を守っている。

逐次フィードバックの開示#

第1〜3段階は逐次フィードバックあり。完全に独立なのは第4段階の無作為8件だけ。また、最初にコードを付けた20件は、類型に関する仮説を宣言するより前にコードされている。

A.5 匿名化と引用の方針#

逐語引用は主張が引用に依存している3か所だけを残し、8か所は記述に置き換えた。

本調査は当初から、公開する成果物では企業名を出さず、業種と規模レンジまで丸める方針で設計している（2022年改正職業安定法への配慮。求人票の原文をデータベース化して公開しない／個別求人の転載は行わない）。

表記のしかた

• 原則として「あるSaaS・IT企業」「ある人材・サービス企業」と書く
• 同じ企業を複数の章で参照する必要がある場合にかぎり、A社・B社…の記号を割り当てる
• 必要なときは掲載求人数のレンジ（1〜4件／5〜9件／10〜19件／20件以上）を添える
• 業種は「SaaS・IT」「人材・サービス」の2区分だけで、これは本調査が標本を絞るために使った区分であり、一般的な業種分類ではない

逐語引用の方針（2026-09-12 決定）

主張が引用に依存している3か所だけを残し、ほかの8か所は記述に置き換えた。（2026-09-12 の判断では4か所を残していたが、4.5.3 の求人タイトル5件は 2026-09-14 に必要語のみの引用へ変更した。）

置き換えた8か所（3.6 の本文1文／4.2.5 のレポートラインの明記／4.4 の勤務体系欄の1句／3.5 の求人タイトル1件／4.3.4 の要件欄の1句／要旨と考察での再掲2か所／4.5.3 の求人タイトル5件）は、いずれも記述で代替でき、主張は弱くなっていない。唯一 3.6（タイトルにRevOpsの語がないRevOps求人）だけは、引用があるほうが読者に伝わりやすいが、主張そのものは立つ。

4.5.3 の変更（2026-09-14 決定）：求人タイトル5件の全文を削除し、論証に必要な語だけを残した。残したのは、①5件の本文が実質的に同一であること、②12文字以上の行の集合で比較したJaccard係数が 0.984 であること、③2件のタイトルに「社長室」または「社長直下」が含まれること、④残る3件には当該語が含まれないこと、⑤前者2件が R1・後者3件が R6 と判定されたこと、⑥判定根拠がタイトルの違いだけであること、の6点である。3件は「事業開発系のタイトル」と要約し、論証に不要な特徴的表現は引用しない。

方針：主張を支えるのに必要な箇所にかぎり、1〜2文の短い引用を、社名・サービス名・部署の固有名詞を伏せて用いる。求人票そのものの掲載・転載は行わない。

あわせて明記する：逐語引用は検索によって元の求人に辿り着ける場合があるため、「匿名化は編集上の方針であって、特定不可能性を保証するものではない」（7章 22）。

法務の判断が要る論点である。当方は弁護士ではない。必要であれば専門家に確認いただきたい。