4.6.1 何をしたか#
3値の簡易判定と一行の理由は全件に付け、詳しい読みは「機能しうる」と判定した求人にだけ書くと、先に決めてある。
本調査には、コードとは独立した基準変数を1つ置いた。
BizOpsの実務経験を持つ調査者が、求人本文だけを読んで、「BizOpsとして機能しうるか／機能しないか／判別不能か」の3値と、一行の理由を付ける。
重要なのは、これをLLMのコードを見る前に付けたことである。コードを見てから付けると、コードとの一致は当然のものになり、独立した基準として使えなくなる。
記入の範囲も先に決めた。
- 3値の簡易判定と一行の理由は全件に付ける
- 詳しい読み（この求人が実際に解こうとしている問題は何か／このまま採用したら入社後に何がズレるか）は、「機能しうる」と判定した求人にだけ書く
- 「機能しうる」でも書くことがなければ空欄のまま確定する（空欄と「対象外」を区別して集計する）
4.6.2 結果 ― 1名の実務者判定では、4分の3が「機能しない」#
66件の判定は、機能しうる16件（24%）・機能しない49件（74%）・判別不能1件（2%）である。
個別にコードを付けた66件についての判定である。
| 簡易判定 | 件数 | 割合 |
|---|---|---|
| BizOpsとして機能しうる | 16 | 24% |
| 機能しない | 49 | 74% |
| 判別不能 | 1 | 2% |
1名の実務者による判定では、4分の3が「BizOpsとして機能しない」と評価された。
この66件は、タイトルで該当したか、本文にBizOps的な語が現れて該当と判定された求人である。つまり機械的な絞り込みを通過した求人であって、無作為の求人ではない。にもかかわらず、実務者の読みでは4分の1しか残らない。
調査の初期段階で、同じことが起きていた#
調査の最初に8件を精読した段階でも、8件中7件が「BizOpsではない」と読まれていた。理由として書かれていたのは、たとえば次のような言葉である。
「所謂THE経営企画」／「BizOpsではなくRevOps」／「FP&Aという印象」
これらは求人票の文言ではなく、調査者が理由欄に書いた言葉である。本レポートでは、どの求人についての言葉かは示さない（2026-09-12 決定）。
3つの理由に共通しているのは、「BizOpsではない別の職種名」で言い換えられていることである。「何が足りないか」ではなく「これは別の職だ」と読まれている。
BizOps明示・経営企画・事業企画といった判定語で拾った求人でも、実務者の目にはBizOpsに見えないものが多かった。「BizOps相当の求人」を名前だけで探す方法の限界が、この段階でも示されている。
4.6.3 なぜこの列を置いたか#
コードは規則に従って付けるため、規則が捉えていないものは必ず落ちる。この列は、その取りこぼしを検出するために置いた。
この調査は、求人票に書かれた語をコードに変換する作業である。コードは規則に従って付けるので、規則が捉えていないものは必ず落ちる。
たとえば、機能が3領域そろい、権限も点灯し、レポートラインも明記されている求人があったとする。コード上は「BizOpsとして成立している」ように見える。だが実務者が読めば、「これは経営企画の予実管理で、BizOpsではない」と一行で判断できる場合がある。その判断は、どの規則にも書かれていない。
この列は、コードが取りこぼしたものを検出するために置いた。実務者の読みを「正解」として使うのではなく、コードと食い違う場所を見つけるための独立した観測として使う。
4.6.4 この節で出さないこと、出せないこと#
1件ごとの判定値を成果物に持ち込まないと決めたため、実務者判定とコードのクロス集計を含む3つの分析を行っていない。
本レポートでは、実務者の読みを集計としてのみ示し、個別の求人についての読みは引用しない。
- 1件ごとの読みは、企業の個別評価として読まれうる。匿名化していても、「この求人はBizOpsとして機能しない」という判断を個別に公開することは、本調査の目的ではない
- 調査の目的は、個々の企業の求人の良し悪しではなく、日本の上場グロース企業全体で何が起きているかを示すことにある
そのため、次の分析は本レポートでは行っていない。
| できなかったこと | 理由 |
|---|---|
| 実務者の判定と、機能・権限のコードとのクロス集計 | 1件ごとの判定値を成果物側に持ち込まない方針としたため |
| 「機能しうる」16件に共通する特徴の抽出 | 同上 |
| 最初にコードを付けた20件との比較 | この20件には3値の簡易判定が付いていない（付けた時点でコードを見ているため、独立性の条件を満たさない） |
これは意図的な制約である。実務者の読みとコードの一致／不一致を分析すれば、本調査でいちばん面白い結果が出る可能性が高い。しかし、それを出すには1件ごとの評価を成果物に載せることになる。今回はそれをしないと決めた。
なお、当初の設計にあった「類型ラベル」（Tech Ops型／Revenue Ops型／Corporate Ops型…）は採用しなかった。理由は方法論上の判断なので、5.6 に書いた。
4.6.5 この節の限界#
判定したのは1名で、二者間の一致率は測っておらず、最初にコードを付けた20件には簡易判定が付いていない。
- 簡易判定は個別コード66件にのみ付けた。最初にコードを付けた20件にはない
- 判定したのは1名である。二者間の一致率は測っていない（独立した基準変数として置いたもので、信頼性を測る対象にしていない）
- 判定は求人本文のみから付けた。企業の事業内容・規模・組織に関する外部知識は、自由記述欄にのみ書き、判定には使っていない
- 「機能しない」49件の理由欄には、職種名（セールス、マーケティング等）が書かれているものが多い。これは本文を読んだうえでの要約であって、タイトルだけで判断したものではない