BizOps（ビズオプス）に求められる力を、2つの層に分けて整理しました。土台にするのは、厚生労働省が紹介しているポータブルスキルの9要素で、版を上げても変えません。その上に、BizOpsでの行動例と専門性を載せ、こちらは仕事の変化に合わせて書き直します。企業がBizOpsの役割を定義するときも、個人が自分の経験を棚卸しするときも、同じ要素名と番号で話せるようにするのが目的です。
今の人事制度はそのまま残し、採用、役割定義、1on1などの場面で、必要な部分だけを使う前提で作っています。
この版は、意見を募るために出す公開草案です。水準ごとの記述はまだ検証していないため、寄せられた意見と支援先での実例をもとに改訂していきます。
全体図
図の下から順に、起点となる問い、変えない「固定層」、版を上げて更新する「可変層」を重ねています。固定層には、厚生労働省が紹介しているポータブルスキルの9要素を使っています。
軸足の型：Tech Ops ／ Revenue Ops ／ Corporate Ops
「これは自分の仕事か」ではなく、
「これは誰かがやるべき仕事か」と問う。
要素名の出典：厚生労働省「ポータブルスキル見える化ツール（職業能力診断ツール）」。ポータブルスキルは一般社団法人人材サービス産業協議会が開発したものです。各要素の定義は同ページをご覧ください。番号（P・H・E）と、要素名以外の記述は株式会社カクシアジによるものです。
起点の問いを置く理由：データ分析、プロジェクト管理、部門をまたぐやりとりは、BizOpsの仕事を始めてからでも身につきます。向き不向きを分けるのは、担当の決まっていない仕事を見つけたときの考え方です。多くの人は「自分の担当か」を考え、担当でなければ手を出しません。BizOpsに向く人は「誰かがやるべき仕事か」を考え、担当者がいなくても手をつけます。この問いは、L1〜L3の水準では測りません。
AIとの分担を書く理由：AIが普及しても9要素そのものは残りますが、要素の中で人が受け持つ部分は変わります。たとえば「現状の把握」では、データを集める作業はAIに任せられるようになり、人は「AIに何を調べさせるか」「出てきた結果のどこを疑うか」を受け持つようになります。要素ごとに分担を書いておけば、改訂のたびに何が変わったかを示せます。
使い方：必要な部分だけを使う
人事制度は会社ごとに違うため、このマップは、今の制度に足して使える「部品」の集まりとして作っています。
基本の考え方
- 一部だけ使ってよい。採用の場面だけ、P2の要素だけ、といった使い方を想定しています。
- 等級とは連動させない。L1〜L3は仕事の影響が及ぶ範囲を表すもので、役職や等級とは別に付けます。そのため、どの等級制度とも併用できます。
- 評価と報酬の判断には、当面使わない。水準ごとの記述を検証し終えるまでは、採用、役割定義、育成の場面で使ってください。
- 起点の問いは、採用の合否に使わない。候補者の人柄を判定しているように受け取られやすいためです。本人の振り返りや、上司との対話に使ってください。
場面ごとの部品
| 場面 | 部品 | 使い方 | 既存の制度との関係 |
|---|---|---|---|
| 採用 | 求人票の文例、要素ごとの面接の問い | 求人票の「求める経験」を、つくった成果物で書く。面接では要素ごとに「何をつくったか」を聞く | 求人票と面接の質問に足すだけで、制度は変えない |
| 役割定義・配置 | 役割定義シート（1枚） | 欠けている機能、要素×水準の印、権限3項目、この役割に任せない仕事を書く | 職務記述書の下書きになる |
| 育成・1on1 | 要素ごとの対話の問い | 「この半年で一番伸びた要素は何か、それが分かる成果物は何か」を本人と上司で話す | 評価と切り離して使える |
| 評価 | 既存の評価項目との対応表 | 自社の評価項目が9要素のどれに当たるかを対応づける | 今の評価項目はそのまま使い、対応を示すだけ |
| 個人の棚卸し | 棚卸しシート | 経験を9要素に分け、成果物で書き出す | 会社の制度と関係なく使える |
最初に試すなら、制度を変えずに使える「採用」と「育成・1on1」をおすすめします。v0.1で配布しているのは次の最小セットのシートだけで、ほかの部品は順に公開します。
最小セットのシート（記入の目安は15分）
自社のBizOpsに必要な要素と水準に印をつけ、権限3項目（指標設計の決定、ツール選定・予算執行、他部門の業務プロセス変更）について、決めてよいのか、提案までなのかを書くシートです。個人の棚卸しにも使えます。登録は不要です。
番号で部分的に参照する
要素と領域に番号を振っています。「P2-L2（課題の設定・部門横断）」のように水準と組み合わせて書けば、「採用要件にはP2-L2とH1-L3だけを使う」といった使い方がしやすくなります。
| 区分 | 番号と名称 |
|---|---|
| 仕事のし方 | P1 現状の把握、P2 課題の設定、P3 計画の立案、P4 課題の遂行、P5 状況への対応 |
| 人との関わり方 | H1 社内対応、H2 社外対応、H3 上司対応、H4 部下マネジメント |
| 専門性 | E1 KPI・予実の設計、E2 業務プロセスの設計と標準化、E3 データの定義と流れの設計、E4 業務システムの選定と連携、E5 意思決定と権限の設計、E6 人・AI・外注の分担の設計 |
P・H・Eは、仕事のし方・人との関わり方・専門性（Expertise）の頭文字です。求人票調査のスキル分類（S1〜S13）とは別の番号です。
番号は版を上げても付け替えません。要素や領域を足すときは新しい番号を振り、やむを得ず変えるときは変更履歴に新旧の対応を載せます。
変えてよいところ、変えずに使ってほしいところ
- 変えてよい：行動例や成果物の言い換え、自社に合わない要素・領域の省略、自社の用語への置き換え、記入例の追加
- 変えずに使ってほしい：要素名、番号、水準L1〜L3の定義。ここを変えると、他社の使い方や公開版と比べられなくなります（利用条件には含めていない、当社からのお願いです）
- 改変して使う場合は、出典と「改変あり」を明記してください
このマップが前提にするBizOpsの定義
BizOpsとは、宙に浮いた変化を見つけ、誰の仕事でもないその変化を引き受け、着地させるまで設計し続ける仕事です。ここでいう「宙に浮いた変化」とは、戦略として正しく、必要性も社内で理解されているのに、「誰がやるか」「どうやるか」が決まらないまま止まっている変更のことです。BizOpsは、こうした変更の担当と手順を決め、現場で定着するまで設計を続けます。
変化が宙に浮く原因は、経営と現場のあいだにある二つの断絶です。
- 経営から現場への断絶：戦略が言葉になっていない。または、言葉になっていても、現場で何をするかに置き換えられていない
- 現場から経営への断絶：現場で起きていることが、経営の判断の場に届かない
断絶が起きる理由の一つは、見ている期間の違いです。経営は3〜5年先、仕組みづくりは数か月単位、現場は今日から3か月ほど先までを見ています。BizOpsはこの間に立ち、二つの方向で言い換えをします。経営が数年先の方針として話していることは、今月やる作業に分けて現場に渡します。現場で毎日起きている手間や食い違いは、数か月かけて直す仕組みの課題として経営に上げます。
RevOpsは収益を、Chief of Staffは経営者を支えることで、仕事の範囲が決まります。BizOpsには、こうした決まった範囲がありません。会社ごとに担う仕事が違っても共通しているのは、起点の問いです。このマップの要素と水準は、その問いに答えて実際に動くために要る力を書いたものです。
→ 当社の見解：BizOpsとは ― 職種名ではなく、権限とセットで働く機能
水準：仕事の影響が及ぶ範囲で3段階
水準は役職で分けず、仕事の影響が及ぶ範囲で3段階に分けます。スタートアップは階層が浅く、10名規模の会社では1人がL1からL3までの仕事を兼ねることがよくあるためです。
経営者がまだ言葉にしていない意図をくみ取って全社の仕組みに反映し、経営者と一緒に優先順位を決める
部門をまたぐ課題を解決する仕組みをつくり、担当者が替わっても続くようにする
決められた課題に答えを出し、その業務を安定して続けられる
- 1人の中で要素ごとに水準が違うのは普通です。全要素をL3にそろえる必要はありません。
- 会社の規模ごとの目安（10名規模でL2、100名規模でL3が必要になる等）は、今後の検証で加えます。
L1からL2へ上がるときに越える壁
L1からL2へ上がると、扱う範囲が自分の担当業務から、部門をまたぐ課題に広がります。次の3つの壁は、どれも自分の担当の外に手を広げるときに越えるものです。
| 壁 | 手前で止まる動き | 越えた動き | 主に関わる要素 |
|---|---|---|---|
| 持ち場の壁 | 問題を自分の担当の範囲だけで解決しようとする | 原因を部門の外にも探し、部門をまたぐ課題として定義する | P1・P2 |
| 属人の壁 | 自分が作業を続けることで業務を安定させる | 手順を書き残し、担当者が替わっても同じように続く運用にする | P4・H4 |
| 依頼の壁 | 依頼して協力してもらう | 利害の違う部門の合意をつくり、決まったことを守ってもらう | H1 |
L2からL3へ上がるときに越える壁
L2までは、頼まれたことを確実にこなす「頼りになる便利屋」でも到達できます。L3に上がるには、新しく何かを足す判断よりも、どの依頼を断り、どの業務をやめ、何を作らないかを決める判断が求められます。
| 壁 | 手前で止まる動き | 越えた動き | 主に関わる要素 |
|---|---|---|---|
| 御用聞きの壁 | 現場の要望を反射的に受け入れる | 会社全体にとって損になる要望は、反発があっても断り、代わりの進め方を示す | H1・P2 |
| ツール思考の壁 | ツールを入れれば解決すると考える | ツールを選ぶ前に現場で業務を見て、業務フローそのものを見直す。ツールの導入は、それでも足りないときに検討する | P1・P3 |
| 足し算の壁 | 新しいフローやルールを足し続ける | 会議、レポート、慣習のうち不要なものを見つけ、やめることを提案して決める | P4・P2 |
| 作る壁 | 作れるものを作り続ける | 作らない選択肢も含めて検討する。作るなら、誰が保守し、いつ使うのをやめるかも決める | P3・P5 |
4つ目の「作る壁」は、AIで誰でも道具を作れるようになってから現れた壁です。作る手間が小さくなった分、作ったものが増えて管理しきれなくなる問題が起きやすくなりました。そのため、作るかどうかを決める判断が以前より重要になっています。
仕事のし方（対課題）5要素
5要素は「つかむ → 決める → 計画する → やり切る → 想定外に備える」の流れで並びます。要素を開くと、水準ごとの行動、成果物、AIとの分担、現場での具体的な行動が読めます。
P1現状の把握数字と現場の両方から事業の実態をつかむ（診断）
- 成果物の例
- KPIの現状値、業務フローの現状図、ヒアリング記録
- AIに任せる部分
- データの集計・整形、資料の要約
- 人に残る部分
- 何を調べるかを決め、数字と現場の話が食い違っている点に気づき、集計結果をそのまま信じずに確かめる
現場での具体的な行動
- 業務システムの管理画面を自分で開き、現場と同じ入力画面を操作してみる。「1件の商談を入力するのに3つの画面を行き来している」といった、報告や数字には出てこない手間を見つける。部門ごとに違う業務フローを集めて、一枚の図にまとめる
- 遅れの原因を「担当部門の中の論点」と「部門の外から情報が届かない論点」に分けて見る（例：月次の締めの遅れは、経理の体制だけでなく各部門からデータが届く日でも決まる）
P2課題の設定経営者がまだ言葉にしていない意図を、取り組む課題として書き出す
- 成果物の例
- 課題の一覧と優先順位、「何を決めるための課題か」の整理
- AIに任せる部分
- 課題候補の列挙、他社事例の整理
- 人に残る部分
- どの課題に取り組み、どれをやらないかを、経営の意図に照らして決める
現場での具体的な行動
- 同じ言葉で語られる別々の問題を分ける（例：「予実が合わない」を、実績が出るのが遅い問題と、予算差異と見込差異が分かれていない問題に分ける）
- 課題は「いま組織に何が欠けているか」から立てる。「BizOps担当を置く」「ツールを入れる」といった手段は、その後で選ぶ
P3計画の立案課題を「誰が・いつ・何を・どの指標で測るか」まで決めた計画にする
- 成果物の例
- 実行計画、KPI定義、あるべき業務フロー、予算
- AIに任せる部分
- 計画の下書き、日程案、抜け漏れの確認
- 人に残る部分
- 計画が現場で実行できる細かさになっているかを判断し、人と予算をどこに配るか、何をあきらめるかを決める
現場での具体的な行動
- 先に経営が判断に使う日を決め、そこから逆算して、実績の確定、差異の分類、会議の準備にそれぞれ何日使えるかを割り振る
- 「完了の定義を一つの文で言えるか」を確かめる。言えないなら、進捗管理の前に「誰がどこまで引き受けるか」「完了の定義」「現場の状況を誰がどう経営に伝えるか」を決める
P4課題の遂行計画を実行し、担当者が替わっても続く仕組みにする
- 成果物の例
- 運用ルール・手順書、定例の会議体、改善の記録
- AIに任せる部分
- 進捗の集計、定例資料の作成、催促
- 人に残る部分
- 進行を妨げている問題を関係者と調整して取り除き、反発や時間の制約があっても最後まで進め、新しいやり方が定着したかを見極める
現場での具体的な行動
- 進捗を追う前に、進捗を記録する表や確認する定例など、追うための形をつくる。形ができてから進行管理に移る
- すべての情報がそろうのを待たない。どこまでを後回しにするか（翌月に調整する、概算の数字を使う、など）を決め、現場に伝えてから進める
P5状況への対応想定外のことが起きたときに、事業を止めずに判断し、その結果に責任を持つ
- 成果物の例
- 判断の記録（根拠と決定）、事後の振り返りと再発防止策
- AIに任せる部分
- 影響範囲の洗い出し、選択肢の整理
- 人に残る部分
- 情報がそろわない中で判断し、その責任を取り、動揺している関係者に状況と次の対応を説明する
現場での具体的な行動
- 方針は変わるものとして動く。変わりにくいもの（データの定義、権限の設計など）には時間をかけ、変わりやすいもの（帳票、運用の細かい決まりなど）は小さく早く作り、作り直しやすい形にしておく
- 大きな決定をしたときは、選んだ案、見送った案、その理由を短く記録する。後で状況が変わったときに、どこから判断し直せばよいかが分かる
人との関わり方（対人）4要素
4要素のうち、BizOpsの仕事で最も比重が大きいのは「社内対応」です。「上司対応」と「部下マネジメント」は階層型の組織を前提にした要素なので、要素名はそのままにして、BizOpsでの意味を読み替えます。
H1社内対応部門間の利害を調整し、仕組みへの支持を得る
- 成果物の例
- 合意した役割分担表、説明資料、会議の決定記録
- AIに任せる部分
- 相手別の論点整理、説明資料の下書き
- 人に残る部分
- 日ごろから信頼関係をつくり、反対する人の本当の理由を聞き出したうえで、納得してもらう
BizOpsの働きは、組織論でいう「バウンダリースパナー」（部門や専門領域の境目に立ち、そのあいだで情報をやりとりさせる役割）に近いものです。この役割では、部門ごとに違う言葉を相手に通じる言葉に言い換えること、立場の違う人と信頼関係を築くこと、どの人とどの人をつなげば話が進むかを見極めることが求められます。特定の部門に肩入れしない立場でいることも、各部門に話を聞いてもらうための条件になります。
現場での具体的な行動
- 経営の言葉を具体的にする：たとえば「標準化」と言われたら、変える項目、やめる作業、判断する人、切り替える日付まで決める
- 現場の声を経営が判断できる形にする：「入力が増えて手が回らない」という声を、どの入力項目が誰の時間を何分使っているか、それでどの数字が不正確になっているかまで調べてから経営に伝える
- 話が噛み合わないときは、言葉の選び方を変える前に、相手が今月の話をしているのか、数か月先か、数年先の話をしているのかを確かめる
H2社外対応業務委託先、SaaSベンダー、士業、投資家・金融機関との調整と合意形成
- 成果物の例
- 委託範囲の定義、ベンダーの比較・選定記録、契約条件の整理
- AIに任せる部分
- 比較表の作成、契約書の論点の洗い出し
- 人に残る部分
- 条件を交渉し、双方の利害を調整しながら、長く続く取引関係をつくる
現場での具体的な行動
- 外部に委託する業務は、費用だけでなく、仕事のノウハウが社内と委託先のどちらに残るかも考えて選ぶ。件数が多く、大半をルールどおりに処理できる業務（例：経費精算や請求書支払の申請処理）は委託し、規程の解釈が必要な1〜2割の例外は社内で処理する
- 委託先が判断してよい範囲を決めて伝え、その範囲を超えるものは定例の場でまとめて報告してもらう。その都度の連絡だけで済ませると、誰がどう判断したかの記録が残らない
- 報告された例外を定期的に見返し、規程、申請の書式、社内への説明のどれを直すかを決める。判断の基準と例外の記録を社内に残しておけば、委託先を変えるときにも引き継げる
H3上司対応読み替え：経営者への報告・提言
BizOpsは経営者の直下に置かれることが多いため、この要素は、経営者に事実を伝え、経営者にとって都合の悪いことも提言する力として読み替えます。
- 成果物の例
- 定例の報告、選択肢と推奨を添えた提言メモ
- AIに任せる部分
- 報告の整形、数字の更新
- 人に残る部分
- 何をどのタイミングで伝えるかを判断し、経営者と異なる意見でも伝える
現場での具体的な行動
- 経営者の話を「意図（何を実現したいか）」と「進め方（どう実現するか）」に分けて聞く。意図はそのまま記録し、進め方は自分が考えて提案する部分として扱う
- 1回の面談ですべてを聞こうとせず、間隔を空けて何度か話す。毎回繰り返し出てくる話が、経営者の意図だと考えてよい。聞き取った意図を文章にして見せ、2〜3回やりとりして確かめる
- 経営者の以前の発言を持ち出して、判断の変更を責めない。状況に応じて判断を変えるのは経営者の仕事の一部なので、方針が変わることを前提に記録や進め方を組み立てる
H4部下マネジメント読み替え：権限なしで人を動かす
BizOpsには部下がいないことが多いため、この要素は、兼務メンバー、現場リーダー、業務委託先に協力してもらい、仕事を進める力として読み替えます。部下がいる場合は、その育成も含みます。
- 成果物の例
- 役割の割り当て、引き継ぎ資料、育成計画
- AIに任せる部分
- 手順書・引き継ぎ資料の下書き
- 人に残る部分
- 相手が何に意欲を持ち、何が得意かを見極め、どこまで任せるかを決める
現場での具体的な行動
- 現場が自分で決めてよいことと、経営に確認することを分けて決めておく。分けておけば、細かい判断のたびに経営の確認を待たずに済み、現場の仕事が止まらない
- 業務フローを一枚の図にして見せる。「ここでデータが止まっている」「この二重入力で処理が遅れている」と図で分かると、現場のリーダーが自分から協力してくれるようになる
BizOps固有の専門性（6領域）
BizOpsの仕事に必要な知識と技術を、6つの領域に分けました。どの領域が重要かは会社の成長段階や事業モデルで変わり、使う道具も入れ替わるため、この層は版を上げて更新します。
専門性は、BizOpsが設計するものの種類で分けています。9要素では説明できない仕組みづくりの知識・技術であること、BizOps相当の求人票に担当業務・権限・要件として現れること、L1〜L3の行動を影響範囲で書き分けられること、の3つを満たすものを選びました。
| 領域 | L1 | L2 | L3 |
|---|---|---|---|
| E1 KPI・予実の設計 KPIツリー、ユニットエコノミクス、予算・実績・見込、差異の分け方、締めの日程、指標をやめる条件 | 決められた指標と予実を正しく集計し、毎月同じ形で出せる | 部門のKPIを全社の指標とつなげ、予算差異と見込差異を分けて見られる集計の形と締めの日程をつくる | 事業計画、予算、KPIをつながった形で設計し、指標ごとに見る人、使う判断、やめる条件まで決める |
| E2 業務プロセスの設計と標準化 現状の可視化、部門間の受け渡し、標準と例外、手順書 | 担当業務の流れを図にし、標準の手順と例外を書き分けられる | 部門をまたぐ受け渡しを設計し直し、例外が戻ってきて手順が更新される運用にする | 事業の成長に合わせて、内部統制の要件も含めて全社の業務の流れと標準を組み直す |
| E3 データの定義と流れの設計 どのデータを正とするか、更新の責任、定義の統一、集計・可視化（BI、簡単なSQL） | 必要なデータを取り出し、定義を確かめてから集計・可視化できる | 部門ごとに違うデータの定義をそろえ、どのデータを正とし、誰が更新するかを決める | 経営が見る数字を決め、そのデータがどこで生まれ、どこに保存され、誰が責任を持つかまで設計する |
| E4 業務システムの選定と連携 SaaSの選定、ツール間の受け渡し、入力の設計、権限・マスタの管理 | 決まったツールを設定・運用し、入力の手間と、入力した人に返るものを点検できる | 要件を整理してツールを比較・選定し、ツール間の受け渡しを設計して導入する | 数年先の規模を見越して、ツール同士のつなぎ目を誰が持つかまで含めて全社のシステム構成を設計する |
| E5 意思決定と権限の設計 会議体の目的（共有・議論・決定）、誰が何を決めるか、権限委譲、判断の記録 | 自分で決めてよいことと確認が要ることを分け、決めた理由を記録する | 部門をまたぐ会議体の目的と、誰が何を決めるかを設計する | 全社の決裁と権限委譲の範囲を設計し、判断の記録を残して、あとから安全に見直せるようにする |
| E6 人・AI・外注の分担の設計 生成AI・自動化の組み込み、外注と内製の切り分け、例外が戻る経路、作った道具の保守とやめどき | 自分の業務にAIを使い、結果を確かめられる | 部門の業務で、AI・自動化に任せる範囲、外注する範囲、人が確認・判断する点を設計する | 全社で人・AI・外注の分担を決め、ノウハウが社内に残る形にする。AIで道具を作るかどうか、誰が保守し、いつやめるかまで決める |
E5は、最小セットの「権限3項目」（指標設計の決定、ツール選定・予算執行、他部門の業務プロセス変更）を設計する力にあたります。E6は6領域の中で最も早く中身が変わるため、改訂のたびに見直します。
専門性の軸足：3つの型
6領域のどれが重くなるかは、BizOpsがどの仕事を中心に担うかで変わります。求人では、次の3つの型に分かれる傾向があります。
| 型 | 中心になる仕事 | 重みが大きい領域 | 求められやすい場面 |
|---|---|---|---|
| Tech Ops型 | 人手の作業をSQL・スクリプト・iPaaSなどで自動化する | E3・E4・E6 | テック企業、手作業の集計が多い組織 |
| Revenue Ops型 | SFA/CRMを軸に売上プロセスを設計・運用する | E1・E4 | SaaS企業の営業組織 |
| Corporate Ops型 | 社内ルールを守りながら業務を速く進められる仕組みを、全社でつくる | E5・E2・E1 | 事業部が増える上場前後の企業 |
型によって変わるのは専門性6領域の重みだけで、9要素と起点の問いはどの型でも同じです。
企業が役割を定義するときの注意
- 欠けている機能から書く。「BizOpsが欲しい」と考える前に、「いま組織に何が欠けているか」を書き出してください。役割を決めずに「社長の右腕」として採用すると、入社してから役割を決めることになります。その結果、何でも引き受ける担当になり、目の前のトラブル対応に追われて、仕組みを設計する時間が取れなくなります。
- 水準と一緒に権限を書く。L3の行動は、他部門の業務を変える権限がないと成り立ちません。少なくとも「指標設計の決定」「ツール選定・予算執行」「他部門の業務プロセス変更」の3つについて、決めてよいのか、提案までなのかを書いてください。
- 仕事を分けてから担当を決める。経営企画に近い仕事は、次の4つに分けると、誰に何を任せるかを決めやすくなります。
| 仕事 | 周期 | 必要な力 | 主に関わる要素 |
|---|---|---|---|
| 意思決定に使う数字を集める | 毎月 | 事業の仕組みの理解、各部門から情報をもらえる関係 | P1・H1 |
| 来期を描く | 期に1〜2回 | 数年先の事業の形を考える力 | P2・P3 |
| 部門をまたいで動かす | 常時 | 社内の信頼 | P4・H1 |
| 役員の特命を引き取る | 予告なし | 不確実な状況での判断 | P5 |
4つを一人に任せると、期日の近い仕事から順に処理されます。毎月の数字の集計が先になり、部門をまたいで動かす仕事は後回しになります。役員の特命が入るとさらに後ろにずれ、期日の遠い「来期を描く」には最後まで手がつきません。担当者を替えても、4つを一人が持つかぎり同じことが起きます。
- 成果物で評価する。仕組みがうまく動き始めると問題が起きなくなるため、BizOpsが何をしたかは外から見えにくくなります。評価するときは、「欠けていた機能が補われたか」を、つくった成果物で確かめてください。
個人が棚卸しするときの注意
- 部門をつなぐ力も専門性として書く。部門ごとの事情を理解する力、立場の違う人の言葉を言い換えて伝える力、戦略を現場の作業に置き換える力は、経験を重ねて身につく専門性です。ただ、職種名のような呼び名がないため、本人も自分の強みとして書けていないことがよくあります。9要素の名前と番号を使えば、こうした経験を具体的に書き出せます。
- 起点の問いで経験を振り返る。誰にも頼まれていないのに整理しようとした仕事を思い出し、そのときに何をつくったかを書き出してください。
このマップは、誰でも同じ内容を読める公開資料です。当社が、マップへの記入結果をもとに特定の求人を個人に勧めることはありません。
なぜこのスキルマップが要るのか：求人票調査から
当社の『BizOps求人票調査 2026』では、東証グロース上場143社の求人票のうち、BizOps関連と判定した86件を読みました。多くの求人票は、担当する仕事は書いていても、その仕事に必要な経験と、与える権限を書いていませんでした。このマップは、経験と権限を書くときの項目として使えるように作っています。
| 見えたこと | 数字 | マップとの関係 |
|---|---|---|
| 必須要件は、技術より調整・管理 | 調整・管理系のどれかを必須にした求人 45件（52%）、技術系 13件（15%）。分母：86件 | 人との関わり方4要素の比重が大きいことを裏づける |
| 最も多い職務なのに、経験を必須にしていない | 部門横断のプロセス設計を職務に書いた51件のうち、業務フロー設計の経験を必須にしたのは8件（16%） | E2を、成果物の形で要件に書けるようにする |
| AI活用は歓迎どまり | 必須5件（6%）、歓迎以上21件（24%）。分母：86件 | 「AIとの分担」を版ごとに見直す理由になる |
| 他部門を変える権限は書かれない | 他部門の業務プロセス変更の権限を明記した求人は66件中0件 | 役割定義で、水準と一緒に権限を書く理由になる |
| 何を求めるかが書かれていない | 必須要件が0〜1領域の求人が43件（半数） | 要素と水準に印をつければ、それをそのまま求人票の要件として書ける |
数字は求人票の要件欄の記載を数えたもので、実際の選考基準ではありません。母集団は上場企業で、非上場スタートアップとは異なります。
質問と回答
BizOpsスキルマップは公的な基準ですか？
いいえ。ポータブルスキルの考え方をもとに、株式会社カクシアジが独自に作成したものです。厚生労働省や一般社団法人人材サービス産業協議会の認定・監修を受けたものではありません。
なぜプロジェクトマネジメントや営業企画、戦略立案は専門性に入っていないのですか？
プロジェクトマネジメントは、計画の立案（P3）と課題の遂行（P4）で扱っています。BizOpsが受け持つのは、決まったプロジェクトを進めることより、誰がどこまで引き受け、何をもって完了とするかを決めて、進められる状態をつくるところで、これはE2とE5に含めています。営業企画は職種の名前なので、仕組みづくりにあたる部分をE1・E4とRevenue Ops型で扱っています。事業戦略の立案は、このマップの前提に置いています。ここでいうBizOpsは、戦略を描く仕事ではなく、決まった戦略を現場で動く仕組みにする仕事だからです。
人事評価や等級制度に使えますか？
等級とは連動させず、評価と報酬の判断には当面使わないことをおすすめします。水準ごとの記述を、まだ検証している途中だからです。採用、役割定義、育成・1on1、個人の棚卸しで使ってください。今の評価項目と9要素の対応を示すことはできます。
一部だけ使ってもよいですか？
はい。一部だけ使うことを前提に作っています。採用の場面だけ、1つの要素だけ、という使い方もできます。「P2-L2（課題の設定・部門横断）」のように番号で書くと、どの部分を使ったかが相手に伝わります。
社内資料に転載したり、書き換えたりしてもよいですか？
株式会社カクシアジが書いた部分は CC BY 4.0 で公開しています。出典を示し、改変した場合はその旨を示せば、商用を含めて使えます。ポータブルスキルの要素名と定義は対象外です。要素名・番号・水準の定義は、他社や公開版と比べられるよう、変えずに使っていただくようお願いしています。
版と変更履歴、ご意見の送り先
| 版 | 日付 | 内容 |
|---|---|---|
| v0.1（公開草案） | 2026-10-06 | 初版。水準の記述は検証中です |
このURLの内容を上書きで更新します。小さな表現の修正は v0.2 のように、要素の読み替えや水準の定義を変えるときは v1.0 → v2.0 のように版を上げ、何をどう変えたかをこの表に残します。
ご意見を募集しています
「この水準の書き方は実態と違う」「自社ではこの要素をこう使った」など、要素の番号（例：P2-L2）を添えてお送りください。お問い合わせと共通のフォームで、本文の冒頭に「BizOpsスキルマップへのご意見」と入った状態で開きます。いただいた意見は次の版の改訂に使い、個人や会社が特定できる形で公開することはありません。
出典と利用条件
出典
- 固定層の9要素の名称：厚生労働省「ポータブルスキル見える化ツール（職業能力診断ツール）」。ポータブルスキルは一般社団法人人材サービス産業協議会が開発したものです。各要素の定義は同ページをご覧ください。
- 求人票の数字：株式会社カクシアジ『BizOps求人票調査 2026』
- BizOpsでの意味、水準ごとの行動、現場での具体的な行動の多くは、代表の御園がnoteのマガジン「BizOpsの輪郭」などに書いてきた内容をもとにしています。
利用条件
このマップは、ポータブルスキルの考え方をもとに、株式会社カクシアジが独自に作成したものです。公的な機関の認定や監修を受けたものではありません。
株式会社カクシアジが書いた部分（起点の問い、BizOpsでの意味、水準ごとの行動、成果物、AIとの分担、現場での具体的な行動、専門性6領域、使い方、番号、配布しているシート）は、クリエイティブ・コモンズ 表示 4.0 国際（CC BY 4.0）で公開しています。出典を示し、改変した場合はその旨を示せば、商用を含めて自由に使えます。ポータブルスキルの要素名とその定義は、この条件の対象外です。
出典の書き方の例：
株式会社カクシアジ「BizOpsスキルマップ」v0.1（公開草案）、https://kakushiaji.co.jp/bizops-skill-map（CC BY 4.0、改変あり）
自社の役割定義にこのスキルマップを使ってみたい方は、こちらからご相談ください。