株式会社テイクアステップ 代表取締役社長 兼 一般社団法人BizOps協会 代表理事の祖川慎治です。
この記事の要点（3行サマリ）
- BizOpsの仕事は、会社の規模とフェーズで根本から変わります。少人数の会社では「1人で全体を見る」こと、1,000名を超える会社では「全社を横断して統合する」ことが仕事の中心になります。名前は同じでも中身は別物です。
- 変化の構造は、経営学者ラリー・グレイナーの「企業成長の5段階」で説明できます。成長の各段階の終わりに来る「危機」を乗り越える機能として、BizOpsの役割は段階ごとに入れ替わります。
- 前のフェーズで評価された仕事を抱え続けると、組織の成長に置いていかれます。BizOpsは、フェーズに合わせて自分の役割を手放し、組み替え続ける仕事です。
こんな悩みを抱えていませんか。
- 会社が大きくなるにつれて、以前は感謝されていた仕事が評価されなくなってきた
- 立ち上げ期に自分が作った仕組みが、今は現場の足かせになっている気がする
- 自社のBizOps（業務改善・システム導入・データ整備の担当）に、今何を任せるべきか判断できない
この記事は、社内で業務改善や部門横断の仕組みづくりを担っている方と、その役割をどう設計するかを考えている経営者・責任者の方に向けて書いています。
目次
- なぜ同じBizOpsでも、会社によって仕事がまったく違うのか？
- グレイナーの企業成長モデルとは何か？
- 各フェーズで、BizOpsには何が求められるのか？
- 実体験：同じ会社の中で、役割は何度入れ替わったか？
- 役割を変えられないと、何が起きるのか？
- 自社は今どこにいるのか？ 見極めるための5つの問い
- よくある質問
なぜ同じBizOpsでも、会社によって仕事がまったく違うのか？
会社の成長段階ごとに「組織が抱える危機」が違い、BizOpsはその危機を乗り越えるための機能だからです。
BizOpsの勉強会やコミュニティで話を聞くと、同じBizOpsという肩書きでも、話がかみ合わない場面によく出会います。
| 少人数の会社のBizOps | 大規模な会社のBizOps |
|---|---|
| SFAの初期設定も、数字の集計も1人でやる | 複数の事業部のデータ定義をそろえる |
| 「ついでに」全体を見ている | 専任のチームで全社を横断する |
| 仕組みがないところに最初の型を作る | 増えすぎた仕組みを統制し、つなぎ直す |
どちらが正しいという話ではありません。会社が直面している課題が違うので、必要とされる仕事が違うのです。
この違いを「会社ごとの事情」で片づけてしまうと、自社のBizOpsに何を任せるべきかが判断できなくなります。そこで、会社の成長段階を整理する補助線として、グレイナーの企業成長モデルを使います。
グレイナーの企業成長モデルとは何か？
企業は成長とともに5つの段階を経て、各段階の終わりには必ず「危機」が訪れる、というモデルです。
経営学者ラリー・グレイナーが1972年にハーバード・ビジネス・レビューで発表しました。成長の原動力になっていたものが、組織が大きくなるにつれて逆に足かせになり、それを乗り越えることで次の段階に進む、という考え方です。
| 段階 | 成長の原動力 | 終わりに来る危機 |
|---|---|---|
| 第1段階 | 創造性 | リーダーシップの危機 |
| 第2段階 | 指揮 | 自律性の危機 |
| 第3段階 | 権限移譲 | 統制の危機 |
| 第4段階 | 調整 | 形式主義の危機 |
| 第5段階 | 協働 | ― |
各段階をBizOpsの目線で読むと、次のようになります。
- 第1段階（創業期）: 全員が何でもやる。仕組みはない。創業者のリーダーシップだけでは回らなくなったところで危機が来る
- 第2段階: 指揮系統ができ、役割分担が明確になる。管理が増えると、現場が「自分たちで決めたい」と感じ始める
- 第3段階: 権限が各部門に移る。部門ごとにやり方・データ・システムがバラバラになり、全社の統制が効かなくなる
- 第4段階: 標準化・統一ルール・データ統合で全社を調整する。行きすぎると手続きが目的化する
- 第5段階: 部門同士の協働で、柔軟に課題を解く組織になる
BizOpsの出番が特に大きいのは、第3段階の「統制の危機」です。部門ごとに入ったツールやデータがバラバラになり、経営会議に出てくる数字の信頼性が揺らぐ。この状態を立て直すのが、BizOpsの中核の仕事になります。
各フェーズで、BizOpsには何が求められるのか？
「種を蒔く人」→「仕組みを作る人」→「統制し、つなぐ人」→「全社で統合する人」の順に、役割が入れ替わります。
以下の人数は、筆者の実務経験に基づく目安です。業種や事業モデルによって前後します。
| フェーズ（目安） | BizOpsの役割 | 主な仕事 |
|---|---|---|
| 創業期（〜50名前後） | 種を蒔く人 | ツール選定、初期設定、運用ルールづくり |
| 成長期（50〜300名） | 仕組みを作る人 | システム間の連携、データの流れの設計、KPIの定義 |
| 拡大期（300〜1,000名） | 統制し、つなぐ人 | データ統合、マスターデータ管理、業務の標準化 |
| 成熟期（1,000名以上） | 全社で統合する人 | 全社KPIの統一、組織統合、ガバナンス設計 |
創業期：種を蒔く人
この時期、組織図に「BizOps」という箱はありません。営業も管理も兼務している誰かが、「ついでに」スプレッドシートで数字を管理し、「ついでに」SFAの設定を触っている。この人がBizOpsの種です。
最大の武器は「全体が見える」ことです。人数が少ないうちは、1人で営業から請求までの流れを見渡せます。この時期に決めたデータの持ち方や命名ルールが、数年後の土台になります。
成長期：仕組みを作る人
部門が分かれ始め、営業がSFAを、マーケティングがMAを、カスタマーサクセスが別のツールを導入します。バラバラに入ったツールをつなぎ、データの流れを設計し、KPIの定義をそろえる。「作る」フェーズです。
拡大期：統制し、つなぐ人
事業部ごとの自律性が高まると、同じ「売上」という言葉でも事業部によって定義が違う、という状態が生まれます。BizOpsは、データの定義と業務の流れを全社でそろえ直す役割を担います。
成熟期：全社で統合する人
複数事業のオペレーション統一や全社データ基盤の整備が中心になります。1人のBizOpsが全部をやるのではなく、営業領域・管理領域・データ領域のように、機能を分けたチームとして動く段階です。
実体験：同じ会社の中で、役割は何度入れ替わったか？
私は前職の1社の中で、会社の成長に合わせて少なくとも3回、役割を組み替えました。
2014年、私はHR Techベンチャーに入社し、営業企画でSalesforceのシステム管理者を任されました。そこから全社の業務改善を担う部署の責任者になり、会社が大きくなる過程を業務基盤の面から支えました。振り返ると、グレイナーモデルの段階が進むたびに、私の仕事の中身は入れ替わっていました。
1回目：散らばった権限を集める（第2〜第3段階）
入社時点で、ユーザー数120名ほどの組織に対し、Salesforceの管理者権限を持つ人が10人いました。「設定を変えたいとき、いちいち依頼するのは面倒」という理由で、権限を持つ人が少しずつ増えた結果です。
たとえるなら、1台のテレビのリモコンを10人が持っている状態です。権限は分散しているのに、責任は誰にも帰属していない。まさに「統制の危機」の小さな縮図でした。
私は営業企画のメンバーに「管理者権限を引き取らせてください。設定変更の依頼はすべて私が受けます。対応スピードは落としません」と伝えて回り、数か月かけて権限を集約しました。この時期の私の仕事は、「1人で全部を引き受けて、型を作る」ことでした。
2回目：部門の壁を越えて、業務をそろえる（第3〜第4段階）
事業が増えると、同じお客様に別々の事業部から月2回、別々のフォーマットで請求書が届く、という事態が起きました。営業部門だけを見ていても解決できない問題です。
ここで私の仕事は「1人で設定する人」から「部門をまたいで業務の流れを設計し直す人」に変わりました。完全統一を目指すと例外対応でシステムが複雑になり、プロジェクトが止まります。そこで「8割を統一し、2割の例外は許容する」という落としどころで進めました。
3回目：経営の近くに、横断できる場所を作る（第4段階）
全社の業務改善を担う部署を、特定の事業部ではなく、経営直轄の事業戦略部門の中に置きました。事業部の下にいると、その事業部の利害に引っ張られるからです。営業プロセスの改善も、請求フローの統一も、経営数値の集計基盤づくりも、全社を横断できる位置にいたから実行できました。
3つの時期で、私が「得意なこと」は大きく変わっていません。変わったのは、会社が私に求めていたことの方でした。
役割を変えられないと、何が起きるのか？
前のフェーズで評価された仕事を抱え続けると、本人も組織も成長の足かせになります。
BizOpsが陥りやすいのは、「立ち上げ期に感謝された仕事」をいつまでも自分で持ち続けることです。
- 50名のときに自分でやっていたSFAの初期設定を、300名になっても自分でやり続ける
- 自分しか分からない設定や集計が増え、自分がボトルネックになる
- 目の前の依頼対応に追われ、次のフェーズで必要な「統制」や「統合」に手が回らない
- 結果として、組織は次の危機に備えられないまま大きくなる
私自身、1人で権限を抱えていた時期は、全体を把握できている安心感がありました。一方で、抱えている仕事の量がそのまま組織の限界になっていく感覚もありました。
役割を変えるとは、具体的には次の3つを繰り返すことです。
- 手放す: 前のフェーズで自分がやっていた仕事を、仕組みやチームに引き継ぐ
- 組み替える: 今のフェーズで一番必要な仕事は何かを問い直し、自分の時間の使い方を変える
- 先回りする: 今の仕組みが、次のフェーズ（人数や事業が倍になったとき）でも動くかを考えながら手を動かす
これは個人のキャリアの話であると同時に、組織設計の話でもあります。BizOpsの守備範囲は固定ではなく、会社の成長に合わせて定義し直し続ける必要があります。
自社は今どこにいるのか？ 見極めるための5つの問い
次の5つの問いに答えると、自社のフェーズと、BizOpsが今取り組むべき仕事が見えてきます。
問い1: BizOps（部門横断の業務改善・システム・データ担当）の専任者は何人いますか？
| 回答 | 目安のフェーズ |
|---|---|
| 0人（兼務のみ） | 第1段階の入り口 |
| 1人 | 第2段階 |
| 数名 | 第3段階 |
| それ以上のチーム | 第4段階以降 |
問い2: SFA/CRMのデータは正確ですか？
- そもそも入っていない → 導入と運用ルールづくりから
- 導入済みだが入力がバラバラ → データの正確さの確保が最優先
- 入力はそろっているが、システム同士がつながっていない → データ連携の設計へ
- データ基盤が整っている → ガバナンスの強化と分析の高度化へ
問い3: KPIの定義は全社でそろっていますか？
- KPI自体が定義されていない → 定義と計測の仕組みから
- 部門ごとにあるが定義が違う → 用語と定義の辞書づくり、定義ごとの責任者決め
- 全社でそろっている → 運用と定期的な見直しへ
問い4: 部門間の業務の受け渡しは、仕組みになっていますか？
- 口頭やチャットで都度依頼している → 受け渡しルールの設計へ
- ルールはあるが守られていない → システム上の自動化への落とし込みへ
- 仕組みになっている → 例外処理とエスカレーションの整備へ
問い5: BizOpsの成果は、どう評価されていますか？
- 評価基準がない → 経営陣とBizOpsの期待値のすり合わせから
- 定性的に評価されている → 定量の指標を追加する
- 定量・定性の両面で評価されている → 評価の仕組みを継続的に見直す
5つの回答がそろわないこともあります。たとえば「専任者は1人だが、データは複数の事業部でバラバラ」という状態は、人の体制が会社のフェーズに追いついていないサインです。回答のズレそのものが、次に手を打つべき場所を教えてくれます。
関連して、BizOpsを経営直轄に置くべき理由は「BizOpsの顧客は現場ではなく経営者 ── 経営直轄でなければ全体最適は動かない」で、改革の前に改善で信頼を積む順番は「BizOpsは改革者である。改善という実績を飛ばして改革はできない」で詳しく書いています。
よくある質問
Q. 少人数の会社にBizOpsは早すぎませんか？
専任者を置くには早いかもしれませんが、機能としてはすでに存在しています。兼務の誰かが「ついでに」数字やツールを見ているなら、その人がBizOpsの種です。この時期に決めたデータの持ち方が後々の土台になるため、担当者を明確にしておく価値はあります。
Q. フェーズが変わったかどうかは、何で判断すればよいですか？
人数よりも「以前は回っていたことが回らなくなった」というサインで判断するのが確実です。たとえば、同じ指標なのに部門ごとに数字が合わない、1人の担当者に依頼が集中して止まる、ツールが増えて誰も全体を把握していない、といった状態は、次の段階の危機が始まっている合図です。
Q. 役割を手放すと、自分の存在価値がなくなりませんか？
私の経験では逆でした。手放した分だけ、次のフェーズで必要な仕事に時間を使えるようになり、声がかかる範囲が広がりました。BizOpsの価値は、特定の作業を抱えていることではなく、その時点の会社に必要な仕事を見極めて動けることにあります。
Q. どのフェーズでも共通して変わらないことはありますか？
2つあります。1つは、特定の事業部ではなく全社の視点に立つこと。もう1つは、現場の実態を自分の目で見ることです。データだけを見て設計すると、現場の使われ方とかけ離れた仕組みができあがります。役割は変わっても、この2つは変わりません。
お知らせ
会社の成長に合わせて、業務改善やシステム・データの担当者にどこまで任せるか、どんな体制にするかを見直したい。そんな経営者・責任者の方は、お気軽にご相談ください。
現場に入って、今のフェーズと業務の実態を一緒に棚卸しするところから始めます。初回のご相談は無料です。
参考文献・出典
- Larry E. Greiner, “Evolution and Revolution as Organizations Grow”, Harvard Business Review, 1972
- 本記事は、筆者が執筆中の書籍『BizOps本(仮題)』第4章「事業フェーズで変わるBizOpsの役割」の議論を、筆者自身の実体験を中心に再構成したものです
- フェーズごとの人数の目安、体験談（管理者権限の集約、請求書の統一など）は、筆者（祖川慎治）の実務経験に基づくものです。特定の企業を指すものではありません
この記事を書いた人
祖川 慎治(そがわ・しんじ)
株式会社テイクアステップ 代表取締役／一般社団法人BizOps協会 代表理事。大手メーカー・大手SIerを経て、HR Techベンチャーで全社の業務改善を担うBPR部署の責任者として社内IT戦略の立案から実行・定着化までを担当。5年で300名から1,400名へ成長する組織とIPO実現を業務基盤の面から下支えした。2021年に株式会社テイクアステップを設立し、BizOps・業務プロセス設計の実行支援を行う。ポッドキャスト「どうする?BizOps」配信中。