BizOpsの顧客は現場ではなく経営者 ── 経営直轄でなければ全体最適は動かない
株式会社テイクアステップ 代表取締役社長 兼 一般社団法人BizOps協会 代表理事の祖川慎治です。
御社にこんな心当たりはありませんか？
- 業務改善の依頼は途切れないのに、事業の数字が動いた実感がない
- 全体を見渡せば課題がわかるのに、手を出せる範囲は自部門の中だけ
- 全社に関わる施策なのに、一つの部門の予算枠で通すしかない
- 「便利な部署」として頼られてはいるが、事業計画の議論には呼ばれない
一つでも当てはまるなら、原因は担当者の力量ではありません。BizOpsが組織のどこに置かれているか、という配置の問題です。
先に結論を書きます。
BizOpsの顧客は現場ではなく経営者です。そして経営直轄に置かれていないBizOpsは、全体最適を設計できても実行できません。
日々のカウンターパートが現場であることと、最終的な顧客が経営者であることは、両立します。この二つを混同したまま現場の要望だけを処理し続けると、誰も入力しない項目と誰も見ないレポートが積み上がっていきます。
この記事では、なぜBizOpsの顧客が経営者なのか、経営直轄でなければ何が詰まるのか、そして個人としてどう立ち位置を変えるのかを順に整理します。
目次
- BizOpsの顧客が経営者である理由
- 経営直轄でなければならない三つの根拠
- 事業部傘下に置かれたBizOpsに何が起きるか
- 「作る人」で終わるか、「相談される人」になるか
- 経営者側が明日できること
1. BizOpsの顧客が経営者である理由
BizOpsは誰のために存在するのか。「現場のために」と答える方は多いと思います。実際、日常の仕事は現場に密着しています。営業のプロセスを直し、マーケティングのデータ基盤を整え、カスタマーサクセスの運用を設計する。
それでも、最終的な顧客は経営者です。これは「経営に気に入られましょう」という処世術の話ではなく、機能の定義そのものです。
BizOpsは、経営の戦略を理解して、それを現場のオペレーションに翻訳する機能です。経営と現場の「間」に立つ。間に立つ以上、最終的な報告先は経営者になります。
理由をもう一段掘ります。
BizOpsが行う全体最適は、部門の利害と衝突します。営業にとって最適な入力フォームが、経理の請求処理を複雑にする。A事業に合うシステムが、B事業には合わない。部分最適同士がぶつかったとき、「全体としてこちらに進む」と決められるのは経営者だけです。
つまり、BizOpsは構造的に経営者の判断を代行する場面を持つ機能です。だから顧客は経営者になる。ここを取り違えると、BizOpsは「声の大きい人の要望を処理する部署」に変質します。
| 誰の要望を起点にするか | 判断の基準 | 積み上がるもの | |
|---|---|---|---|
| 顧客＝現場と考える | 依頼してきた部門 | その部門の使いやすさ | 部分最適の項目とレポート |
| 顧客＝経営者と考える | 事業の目標 | 全社の意思決定の質 | 経営が使えるデータ基盤 |
2. 経営直轄でなければならない三つの根拠
「顧客は経営者」を実務で成立させるには、組織上の配置が要ります。BizOpsは経営直轄であるべきです。これは組織論のきれいごとではなく、仕事をするための前提条件です。
根拠①：全社データへのアクセス権限
BizOpsの仕事は、事業全体のオペレーションを横断で見ることです。マーケティングのリード、営業の商談、カスタマーサクセスの解約、経理の売上、人事の採用。これらにアクセスできなければ、全体最適の設計は成り立ちません。
BizOpsが営業部門の下にあると、マーケティングのデータを見に行った時点で「なぜ営業の人間がうちのデータを見るのか」という壁が立ちます。経理のデータなら、壁はさらに高い。
経営直轄であれば、「経営の意思決定に必要なデータを集めている」という説明が成り立ちます。
根拠②：予算と人事権
BizOpsのプロジェクトは部門横断です。ツールを入れる、プロセスを変える、全社共通のデータ基盤を作る。いずれも予算が要ります。
特定の事業部の傘下にいると、その事業部の予算枠の中でしか動けません。全社に効く施策なのに、一つの事業部だけが費用を負担する形になる。この構造では、規模のある施策は通りません。
根拠③：部門間の利害調整権限
営業の下にいるBizOpsが、営業部門に対して「あなたたちのやり方を変えてください」と言えるか。言えません。自分の親組織に是正を求めるのは、構造的に無理があります。
経営直轄であれば、「全社最適の観点でこのプロセスを変更する」と、経営の権威をもって進められます。部門の上下関係に縛られず、フラットに各部門と向き合える立場が確保される。
権限と責任はセットにする
全社データに触れるということは、機密情報に触れる機会が増えるということでもあります。権限を渡す以上、情報管理のガバナンスも同時に設計してください。
- アクセスログの記録（誰が、いつ、どのデータを見たか）
- 最小権限の原則（施策に必要なデータだけに限定する）
- 定期的な棚卸し（不要になった権限は速やかに外す）
- 情報分類の明確化（社外秘・部門限定・一般公開を定義する）
「全社のデータを見られる＝何でも見放題」ではありません。見られるからこそ管理を厳格にする。この姿勢が、経営からの信頼と他部門からの協力を同時に支えます。
3. 事業部傘下に置かれたBizOpsに何が起きるか
配置を間違えると何が起きるか、順番に書きます。
BizOpsチームが営業本部の傘下に置かれたとします。最初は営業プロセスの改善に集中し、成果が出ます。ここまでは順調です。
やがて壁にぶつかります。営業の前工程であるリードの品質に課題があると気づいても、「それはマーケティングの問題」で手を出せない。後工程の請求フローに非効率があっても、「それは経理の管轄」で口を挟めない。
結果、見えている全体像と、手を出せる範囲にギャップが生まれます。 全体最適を設計する力があるのに、部分最適にしか手を出せない。これはチームのメンバーにとってもフラストレーションになります。「全体を変えたいのに、うちの部門のことしかやらせてもらえない」と。
私が前職でBPR部を経営直轄の事業戦略本部の中に置いたのは、この構造を先に理解していたからです。事業戦略本部は特定の事業部に属さず、全社を横断して動ける位置にありました。だからこそ、営業プロセスの改善も、請求フローの統一も、経営数値の集計基盤の構築も、部門の壁を越えて実行できました。
組織設計で避けるべきパターンを整理します。
| 避けるべき配置 | 何が起きるか | 対策 |
|---|---|---|
| 特定事業部の傘下に置く | その事業部の最適化に閉じる | 経営直轄に置く |
| 予算を他部門に依存させる | 全社横断の施策が通らない | 独自の予算枠を持たせる |
| 評価基準を他部門と同一にする | 横断的・長期的な仕事が評価されない | 専用の評価基準を設計する |
| 一時的なプロジェクト組織にする | 終了後に解散し知見が散る | 常設の組織として設計する |
4. 「作る人」で終わるか、「相談される人」になるか
ここからは、担当者個人の話です。
BizOpsのキャリアには分岐点があります。「作る人」で終わるか、「相談される人」になるか。
「作る人」 は、指示されたものを正確に速く作ります。設定変更、ダッシュボード構築、業務フローの文書化。手を動かすスキルは高く、依頼は確実にこなす。評価はタスクベースです。「期限どおりに構築した」「想定どおりに実装した」。
この評価構造には天井があります。どれだけ速く正確に作っても、「実行部隊の一員」という位置づけからは出られません。そして「手を動かして作る」領域は、ノーコード・ローコードやAIの進化で代替可能性が上がり続けています。作るスキルだけに依存したキャリアは、リスクを抱えます。
「相談される人」 には、構想段階から声がかかります。「来期の事業計画を考えているが、オペレーション面で何が必要か」「この事業を統合するとして、業務プロセスはどう変わるか」。評価の対象が「何を作ったか」から「どんな判断を可能にしたか」に移る。こちらには天井がありません。
私自身の転機も、ここでした。前職の事業統合の構想段階で、経営から「業務プロセスをどう組み替えればいいか」と声がかかった。その時点で仕事の中身が、依頼された業務の改善から、経営の意思決定を支える基盤の設計に変わりました。扱う情報の質も、関わる人の範囲も、まったく別のものになりました。
転換は、スキルの積み上げだけでは起きません。順番があります。
第一に、経営の言語を話すこと。 BizOpsは業務とシステムの言葉で考えることに慣れています。「このフローを変えればこの工程が省ける」。経営はこの言葉では動きません。経営が使うのは「その投資はいつ、どれだけ返ってくるのか」「事業のどの数字に効くのか」「リスクはどこか」です。業務改善の提案を、意思決定に必要な情報へ翻訳できるかどうか。ここが最初の壁です。
第二に、問われる前に提案すること。 「作る人」は依頼を受けてから動きます。「相談される人」は依頼が来る前に持っていきます。「来期の計画を拝見しました。オペレーション面で三つ課題が予見されます。先に打っておく対策を提案します」。この能動性が、「この人には早めに相談したほうがいい」という認識を作ります。
第三に、小さな成功体験を積むこと。 いきなり戦略の根幹に関わる提案をしても、実績がなければ通りません。今の施策の報告の場で「ついでにこちらも検討しました」と小さく添える。採用され、成果が出たら、次は少し大きく。この繰り返しでしか、構想段階に呼ばれる立場には移れません。
「報われない」を「選ばれる理由」に変える
BizOpsは横断組織なので、直接の売上を立てません。営業のように受注額で評価されることも、プロダクトのようにリリース機能で評価されることもない。この「報われない問題」には、二つの答えがあります。
一つは、評価の軸を自分で定義すること。既存の人事評価の枠にBizOpsの成果を無理やり当てはめると、必ず無理が出ます。そうではなく、自分の評価指標を自分で提案し、上司や経営と先に合意しておく。全社施策の完了件数と受益部門からのフィードバック、経営会議への提案採択率、部門間案件の調整リードタイム。この形なら、何を基準に評価されるかがわからないという不安は消えます。
もう一つは、目立たなさを立場の強さに変換すること。自分の手柄を主張しない人は、経営から見ると「組織全体のために動ける人」に映ります。各部門の機微な情報に触れ、経営の意思決定に関わり、全社のオペレーションを俯瞰する。この立場は、自分の成果を主張しすぎる人には任せられません。
5. 経営者側が明日できること
ここまでは担当者側の話が中心でしたが、配置を決められるのは経営です。明日から確認できることを挙げます。
- 組織図でBizOps（またはその役割を担う人）がどこにぶら下がっているかを見る。 特定の事業部の下にあるなら、その事業部の外には手が出せていないはずです
- 全社横断の施策に、独自の予算枠があるかを見る。 ないなら、施策の規模は事業部の裁量で頭打ちになっています
- 直近の事業計画の議論に、オペレーション側の人間が入っていたかを思い出す。 入っていないなら、実行可能性を織り込まないまま計画が立っている可能性があります
- その人に、依頼ではなく相談を一度投げてみる。 対案が返ってくるなら、構想段階から入ってもらう価値があります
BizOpsの本質は、業務効率化ではありません。経営が描く戦略と現場のオペレーションを一本のパイプラインでつなぎ、現場から出たデータを次の戦略に戻す。この循環を設計して回し続けることです。
単なる効率化ではなく、経営の意思決定の質そのものを上げる機能。だから顧客は経営者であり、だから経営直轄に置く必要があります。
よくある質問
Q1. 現場の要望に応えるのをやめろ、という話ですか？
A. 違います。日常のカウンターパートが現場であることは変わりません。変えるのは判断の基準です。「誰が言ったか」ではなく「事業の目標に効くか」で優先順位を決める。要望は受けつつ、順番は経営の目標から決める、という運用になります。
Q2. 経営直轄にすると、現場から遠くなって実態が見えなくなりませんか？
A. その懸念は正しく、全体最適に寄りすぎると現場の状況は見えにくくなります。逆に部分最適に寄りすぎると、システムが分散して連携が取れなくなる。どちらか一方に振り切るのではなく、行き来しながら調整し続ける前提で設計してください。
Q3. 専任のBizOps担当がいない会社は、どうすればいいですか？
A. 専任がいない会社にも、BizOpsの仕事だけは必ず存在しています。営業企画や情報システムの誰かが兼務で背負っているはずです。まずはその役割を組織図の上で明示し、全社データへのアクセスと横断施策の予算をひもづけるところから始めてください。
Q4. 経営直轄にしただけで機能しますか？
A. しません。組織設計は前提条件であって、十分条件ではありません。人材と組織設計は表裏一体です。配置が正しくてもカルチャーの合う人がいなければ動かず、人がいても配置が間違っていれば動けません。両方を同時に進める必要があります。
無料相談のご案内
BizOpsの置き場所をどう決めればいいかわからない、全社の施策が部門の壁で止まっている。そんな経営者・責任者の方は、お気軽にご相談ください。
現場に入って一緒に整理するところから始めます。初回のご相談は無料です。
参考文献・出典
- 本記事のBPR部を経営直轄の事業戦略本部に設置したエピソード、および事業統合の構想段階で相談を受けた転機は、いずれも筆者（祖川慎治）自身の前職での実体験に基づきます
- 組織設計の三つの根拠、避けるべき配置パターン、「作る人」と「相談される人」の分岐に関する考察は、筆者が執筆中の書籍『BizOps本（仮題）』第2章・第6章・第7章の議論を再構成したものです
この記事を書いた人
祖川 慎治（そがわ・しんじ）
株式会社テイクアステップ 代表取締役／一般社団法人BizOps協会 代表理事。大手メーカー・大手SIerを経て、HR Techベンチャーで全社の業務改善を担うBPR部署の責任者として社内IT戦略の立案から実行・定着化までを担当。5年で300名から1,400名へ成長する組織とIPO実現を業務基盤の面から下支えした。2021年に株式会社テイクアステップを設立し、BizOps・業務プロセス設計の実行支援を行う。ポッドキャスト「どうする？BizOps」配信中。