BizOps（ビズオプス／Business Operations）は、部門をまたぐ業務の流れを設計し直し、現場で回る状態にする機能です。
株式会社カクシアジは、BizOpsをこう捉えています。職種名として置くだけでは働かない。設計したものを現場に通す権限とセットになって、はじめて働く。
このページは、2026年9月15日を基準日とする当社の見解です。根拠の一部に、当社が行った『BizOps求人票調査 2026』を使っています。ただし、調査そのものはこのページの定義を使っていません（→「このページと調査の関係」）。
職種名ではなく、機能として捉える
BizOpsという職種名で探しても、この仕事の需要はほとんど見えません。
当社の調査では、東証グロース市場の143社が出していた求人938件のうち、「BizOps」を名乗る求人は2件、RevOps・SalesOps系も2件でした。合わせて0.4%です。
一方で、求人の本文を読むと、この仕事は書かれています。名前のない求人を読むと43件がBizOps相当で、その43件のタイトルには、BizOps・RevOps・SalesOpsの語が1件もありませんでした。個別に判定した86件で最も多かった担当業務は、部門横断のプロセス設計（51件）です。
名前はなくても、仕事はあります。だから当社は、「BizOpsという職種を置くかどうか」ではなく、「自社にどの機能が欠けているか」から考えます。
当社がBizOpsとして扱うのは、たとえば次のような仕事です。
- 部門をまたぐ業務フローの設計
- KPIの設計と、その数字が自然に集まる仕組みづくり
- SaaS・CRMの選定と、現場への定着
- 全社の予算・計画と、それが部門間で回る仕組みづくり
権限とセットでなければ働かない
部門をまたいで業務を設計し直すことは、他部門のやり方を変えることを含みます。その変更を通す権限がどこにあるのかが決まっていないと、設計は提案のまま止まります。担い手は、調整役になります。
当社の調査では、他部門の業務プロセスを変更する権限を、「決定する」「責任を持つ」「最終判断」といった決定の言葉で明記した求人は、1件もありませんでした。書かれていたのは「主導する」「リードする」「牽引する」「統括する」までです。
同じ66件で、指標設計の決定権は7件、ツール選定・予算執行は4件が明記されていました。書かれないのは、他部門を変える権限だけです。
分母は、求人票を1件ずつ読んで個別にコードを付けた66件。出典：株式会社カクシアジ『BizOps求人票調査 2026』4.2.1節
「社長直下」と書かれた求人も同じです。6件のうち、権限が読み取れたのは1件だけでした。上長が近いことと、権限が書かれていることは、求人票の上では結びついていません。
調査が示しているのは、権限が「求人票に書かれていない」ところまでです。 権限がなければBizOpsは働かない、というのは、当社代表の実務経験にもとづく見解です。
権限の置き場所は、2つある
BizOpsの担い手が働くための権限は、次のどちらかにあります。
- 担い手自身が持つ
- 上長が持ち、担い手がその上長と一体で動く
2つ目の形は見落とされがちです。当社代表は、事業会社で部門をまたぐ仕組みづくりを担っていたとき、この形で仕事をしてきました。役員クラスの上長と、指示を受ける側としてではなく、ビジネスパートナーとして動けたことで、その上長の権限のもとで他部門の仕事を変えていくことができました。振り返ると、恵まれた条件でした。
この形が成り立つには、2つの条件があります。
- 上長の権限が、変えたい部門まで届いていること（役員、または役員に相当する立場）
- 上長と担い手が、報告する・されるの関係ではなく、判断を分かち合う関係になっていること
求人票に「社長直下」と書いてあっても、この関係があるかどうかまでは分かりません。
→ 調査：BizOps相当の求人に、他部門を変える権限は与えられているか（4.2章）／求人票から、誰の下につくのかは読み取れるか（4.5章）
BizOpsと混同されやすいもの
- BizDevOps
- 名前は似ていますが、別の概念です。BizDevOpsはソフトウェア開発の進め方に関する言葉、BizOpsは事業運営に関する言葉です。検索結果では、両者が混ざって出てくることがあります。
- RevOps
- 当社は、RevOpsをBizOpsと並ぶ別の仕事というより、BizOpsが扱う領域のひとつ（売上プロセス）と捉えています。
- 名前だけのBizOps
- 職種名を置いても、機能の範囲と権限の置き場所が決まっていなければ、BizOpsは働きません。
採用する前に、決めておくこと
BizOpsを採用するにせよ、外部に頼むにせよ、先に決めておくことは同じです。
- 自社に欠けている機能の範囲
- 権限の置き場所 — 担い手自身に持たせるのか、どの役員のもとで動くのか
棒の長さは、職務に書いた件数を100%としたときの、必須にしている件数の割合。出典：株式会社カクシアジ『BizOps求人票調査 2026』4.3.2節
当社の調査では、部門横断のプロセス設計を担当業務に書いた51件のうち、その経験を必須要件にしていたのは8件（16%）でした。事業戦略の立案では、27件中13件（48%）です。仕事としては期待しているのに、採用の条件にはなっていません。
→ 調査：BizOps相当の求人は、どんな経験を必須にしているか（4.3章）
→ 役割と権限の書き方：BizOpsスキルマップ（公開草案）。要素と水準に印をつけ、権限3項目を書く1枚のシートがあります
採用か、外部委託か
採用できるなら、採用が第一の選択肢です。 知見も権限も社内に残ります。
ただ、採用には2つの壁があります。
ひとつは、採用そのものです。名前のない職種なので、機能の範囲と権限の置き場所が言葉になっていないと、求人票が書けません。当社は、現実にはこの採用はなかなか進まないと見ています。
もうひとつは、採用できた後の育成です。BizOpsとして部門をまたいで立ち回れるようになるまでには、時間がかかります。そして、この役割を初めて置く会社では、社内にその仕事を経験した育て手がいないことが少なくありません。先に見たとおり、部門横断のプロセス設計の経験を必須にしている求人は多くありません。経験を問わずに迎えるなら、入社後に誰が育てるのかまで決めておく必要があります。
選択肢は3つです。
| 向いているケース | 弱み・前提 | |
|---|---|---|
| 採用 | 欠けている機能と権限の置き場所を、すでに言葉にできている／専任1人分の仕事が続く／社内に育て手がいる | 定義がないと求人票が書けない。採用できても、立ち回れるようになるまで時間がかかる |
| 外部委託 | 機能の定義から始める必要がある／立ち上げの時期に負荷が集中する | 任せきりにすると、社内に知見が残りにくい。続けるほど費用がかかる。外部は社内の権限を持たないため、役員と一体で動けることが前提になる |
| 組み合わせ | 外部と一緒に機能と権限の置き場所を定義し、その言葉で採用する／採用した人と外部が一緒に動き、育成を兼ねて知見を社内に移していく | 外部から社内へ、何をどう引き継ぐかを最初に決めておく必要がある |
→ note：「BizOpsが欲しい」の前に問うべきこと
カクシアジの関わり方 — 言葉になっていない意図を、回る仕組みに翻訳する
株式会社カクシアジは、経営者の頭の中にある「こうしたい」を、現場で回る仕組みに翻訳します。
その意図の多くは、まだ言葉になっていません。当社はそれを、機能の範囲、権限の置き場所、業務フロー、KPIに落とし込みます。
外部の支援者は、社内の権限を持ちません。だから当社は、経営者と一体で動きます。先に書いた「上長と一体で動く」形を、社外から担う関わり方です。
そのため、経営者や役員が直接の相手にならないご依頼では、当社の支援はうまく働きにくいと考えています。
進め方は3つのステップです。
- 現状診断 — どこで仕事が詰まり、何が落ちているかを可視化する
- 設計・実装 — 業務フロー・KPI・ツールを、現場が使える状態まで実装する
- 改善・定着 — 組織が自走できる状態になるまで、改善のサイクルを回す
扱う領域は、売上プロセス（Revenue Ops）、全社の仕組み（Corporate Ops）、業務の自動化とデータ（Tech Ops）です。
社内の担い手と一緒に動き、知見を残す
社内にBizOpsの担い手を採用した場合や、社員の誰かを担い手に選んだ場合は、当社がその人と一緒に入ります。
実務を一緒に進めながら、育成も兼ねます。設計した仕組みだけでなく、なぜその形にしたのかという考え方も、少しずつ社内に移していきます。当社の支援が終わったあとも、仕組みと知見が社内の資産として残る状態をめざします。
→ 支援内容の詳細
設計で終わらせない
設計図を渡して終わる支援では、仕組みは現場に届きません。当社は、設計・実装から現場への定着までを引き受けます。
方向を示すところまでが役割の支援と、決まった要件を実装する支援。そのあいだに落ちる実務の設計と実装が、当社の考えるBizOpsの守備範囲です。
このページと調査の関係
当社の『BizOps求人票調査 2026』は、このページの定義を使っていません。調査は、求人票に書かれた職務と権限を、あらかじめ決めた判定規則で分類したものです。判定規則は付録Bにあります。
調査が測ったのは、「企業が募集の時点で何を約束しているか」です。このページは、その結果を踏まえた当社の見解です。
このページの見解の基準日は、調査の公開日と同じ2026年9月15日です。
このページの見解は、支援や調査を通じて見直すことがあります。改訂したときは、下の履歴に版と日付を残します。
版と改訂履歴
| 版 | 見解の基準日 | 内容 |
|---|---|---|
| 2026年9月版 v1.0 | 2026-09-15 | 初版 |
よくある質問
BizOpsの読み方は？
「ビズオプス」と読みます。Business Operationsの略です。
BizOpsとは何ですか？
部門をまたぐ業務の流れを設計し直し、現場で回る状態にする機能です。株式会社カクシアジは、職種名として置くだけでは働かず、設計を現場に通す権限とセットになって、はじめて働く機能だと捉えています。
BizOpsとBizDevOpsは同じものですか？
別のものです。BizDevOpsはソフトウェア開発の進め方に関する言葉、BizOpsは事業運営に関する言葉です。
BizOpsとRevOpsはどういう関係ですか？
当社は、RevOpsをBizOpsが扱う領域のひとつ（売上プロセス）と捉えています。
BizOpsは、採用と外部委託のどちらがよいですか？
採用できるなら、採用が第一の選択肢です。ただし、欠けている機能の範囲と権限の置き場所を先に言葉にしないと、求人票が書けません。また、採用できても、BizOpsとして立ち回れるようになるまでには時間がかかり、誰が育てるのかという課題が残ります。定義から始める必要がある場合や、社内に育て手がいない場合は、外部委託や、採用した人と外部が一緒に動く組み合わせも選択肢になります。
社内に経営企画の機能がありません。事業の仕組みづくりを外部に頼めますか？
頼めます。株式会社カクシアジは、この相談もBizOps構築支援としてお受けしています。経営企画の機能がないという会社でも、計画や構想そのものは経営者の頭の中にあることが多くあります。足りていないのは、その構想を業務の流れやKPIに落とし込み、現場で回り続ける状態にする機能です。当社はこの機能をBizOpsと呼んでいます。計画を作って渡すのではなく、社内の担い手と一緒に設計から定着まで進め、知見を社内に残します。
このページの定義は、求人票調査で使われていますか？
使われていません。調査は、あらかじめ決めた判定規則で求人票を分類したものです。このページは、その結果を踏まえた当社の見解です。