株式会社テイクアステップ 代表取締役社長 兼 一般社団法人BizOps協会 代表理事の祖川慎治です。
この記事の要点（3行サマリ）
- MOpsやSalesOpsなど各部門の「Ops」は自部門を最適化する改善者です。BizOpsは部門の壁を越えて事業全体を作り変える改革者です。
- 改革の号令を先に上げても現場は動きません。改善で実績を出し、信頼を得て、改革の権限を得る。この順番は飛ばせません。
- 改革の起点は「全社統一」という号令ではなく「お客様に迷惑をかけない」という一点です。撤退ラインのない企画書は、埋没コストの罠に落ちます。
御社にこんな心当たりはありませんか。
- 各部門の業務改善は進んでいるのに、部門をまたぐ問題だけがいつまでも放置されている
- 「全社で統一しましょう」と号令をかけたのに、各部門から反論が出て前に進まない
- 改革プロジェクトが始まったものの、途中でやめる基準がなく、ずるずる続いている
いずれも、改善と改革を混同しているところに原因があります。この記事では、両者がどう違うのか、なぜ改善を飛ばして改革はできないのか、そして改革をどう始めればいいのかを、私自身の実務経験に基づいて整理します。
目次
- 各Opsは「改善者」、BizOpsは「改革者」
- 成長企業ほどOS層はサイロ化する
- 改善と改革は「レベル」ではなく「見ている景色」が違う
- 「自席を捨てろ」── 動かない人には物理的に張り付く
- 企画書に「撤退ライン」を入れないと埋没コストの罠に陥る
- 改革の起点は号令ではなく「お客様に迷惑をかけない」
1. 各Opsは「改善者」、BizOpsは「改革者」
企業の中には、MOps（マーケティングオペレーション）、SalesOps（セールスオペレーション）、CSOps（カスタマーサクセスオペレーション）など、「Ops」と名のつく機能が増えています。これらに共通するのは、特定部門のKGI（重要目標達成指標）を伸ばすことを目的としている点です。MOpsはマーケティング部門の数字を、SalesOpsは営業部門の数字を、それぞれ改善する。守備範囲が明確で、部門の中で成果を出すことに集中する専門家です。
私はこれらを「改善者」と呼んでいます。動き方は現場寄りで、担当部門のメンバーと同じ目線、同じ数字を追いかけます。
一方、BizOpsは「改革者」です。マーケティングから営業、カスタマーサクセス、経理の請求フローまで、部門の壁を越えて事業全体を一本の線として見渡します。
具体例で考えてみます。マーケティング部門がリード獲得数を倍にしたとします。しかし、そのリードを引き受けるインサイドセールスの人員が足りなければ、リードは滞留するだけです。受注後の契約手続きや請求フローがボトルネックになっていれば、売上の計上も遅れます。MOps単体で見れば成果は出ている。しかし事業全体で見ると、リードの増加が売上に結びついていません。
BizOpsが見ているのは、この全体像です。どこかの部門を改善する仕事ではなく、部門と部門の接合部を設計する仕事です。
| 項目 | 各Ops（MOps・SalesOpsなど） | BizOps |
|---|---|---|
| 呼び名 | 改善者 | 改革者 |
| スコープ | 特定部門の業務 | 部門横断の事業プロセス全体 |
| 最適化の対象 | 部分最適 | 全体最適 |
各Opsが不要という話ではありません。マーケティング部門にはMOpsが、営業部門にはSalesOpsが要ります。ただ、部門の中だけを見ていては解決できない問題が必ず出てきます。それを引き受けるのがBizOpsです。
御社では、部門ごとの改善は進んでいるのに、部門と部門の間の問題を引き受ける人がいない、ということはありませんか。
2. 成長企業ほどOS層はサイロ化する
会社の構造は、iPhoneの3層構造に似ています。CPUやメモリといったハードは経営リソース（ヒト・モノ・カネ・情報）、iOSにあたるOSは法務・経理・人事などのバックオフィス、LINEやカメラのようなアプリは各事業部です。各事業部（アプリ）は、バックオフィス（OS）が提供する共通基盤の上で動いています。
この構造は、企業が小さいうちは問題になりません。社員数十人規模であれば、バックオフィスの担当者が全事業部の状況を把握できています。経理担当は全事業の請求フローを理解しているし、人事担当は全事業の採用計画を一元管理しています。
問題が起きるのは、企業が成長したときです。事業が増え、組織が大きくなると、バックオフィスの担当者ですら自分が担当する事業しか見なくなります。A事業の経理担当はA事業の請求フローだけを、B事業の経理担当はB事業の請求フローだけを管理する。共通基盤であるはずのOS層が、事業部ごとに分断されていくのです。
以前いた急成長企業で、まさにこれが起きていました。複数の事業がそれぞれ独自に請求書を発行していたのです。テンプレートはバラバラ。発行タイミングもバラバラ。最も困ったのは、二つの事業の両方を利用している顧客に、月に2回、別々のフォーマットで請求書が届いていたことでした。
顧客の立場で考えてください。同じ会社と取引しているのに、請求書が2通届く。フォーマットも支払いタイミングも違う。「この会社は社内で連携が取れていないのでは」という印象を与えてしまいます。
請求書だけではありません。契約書のテンプレート、経費精算のルール、社内申請の承認経路。企業が成長するほど、事業部ごとのローカルルールが増殖し、「同じ会社なのにやり方が違う」という状態が常態化します。
これは、どこか一つの部門を改善しても解決しない問題です。A事業の請求フローだけを直しても、B事業は別のフローで動いたままだからです。部門の外に踏み出さなければ、この種の問題には手が届きません。
御社の請求フローや契約管理は、事業部の数だけバラバラになっていませんか。
3. 改善と改革は「レベル」ではなく「見ている景色」が違う
改善は「今あるものをよくする」ことです。改革は「構造そのものを作り変える」ことです。この二つは、片方が高度でもう片方が初歩的だという関係ではありません。見ている景色が違うのです。
改善は現場の視点で、特定の部門や業務の課題を解決する行為です。たとえば、営業チームが毎月のレポート作成に3時間かけている。原因はSalesforceのレポート機能を使いこなせていないことだった。ダッシュボードを整備し、作業時間を15分に短縮する。これが改善です。スコープは部門の中に閉じていて、ボトムアップで動き、効果も局所的に現れます。
改革は経営の視点から事業全体を俯瞰し、構造を作り変える行為です。先に挙げた、事業部をまたいで請求の仕組みそのものを設計し直す取り組みがこれにあたります。トップダウンの意思決定とボトムアップの実行力、その両方が必要で、影響範囲は広く、期間も長くなります。
| 項目 | 改善 | 改革 |
|---|---|---|
| 視点 | 現場思考 | 経営思考 |
| スコープ | 特定部門・特定業務 | 事業全体・部門横断 |
| 期間の目安 | 数日〜数週間 | 数か月〜1年以上 |
ここで大切なのは、改革が改善より偉いわけではない、ということです。改善なくして改革はありません。BizOps担当者は例外なく「改善者」としてキャリアを始めます。現場に入り、小さな課題を解決し、実績を積む。その過程で「この人に任せれば大丈夫だ」という信頼が生まれる。信頼が蓄積されて初めて、改革の権限が手に入るのです。
改善で実績を出す。信頼を得る。改革の権限を得る。改革を実行する。この順番は飛ばせません。実績も信頼もないまま「全社を改革します」と宣言しても、現場は誰もついてきません。
経営者の方へ： 改革を担ってほしい人材に、いきなり全社プロジェクトの旗を持たせていませんか。実績も現場の信頼もないまま改革の号令だけを預けても、その人は孤立するだけです。まずは現場で改善の実績を積める時間と裁量を与えてください。改革の権限は、その先にしか生まれません。
御社では、いま改善と改革のどちらの景色を見ていますか。
4. 「自席を捨てろ」── 動かない人には物理的に張り付く
改善者としての最初のルールは、「自席を捨てる」ことです。比喩ではありません。物理的に、自分のデスクに座っている時間を最小化するという意味です。
デスクに座っていると、見えるのはシステムの画面とチャットのメッセージだけです。数字や文面からは、現場で起きていることの一部しかわかりません。本当の課題は、現場の人の表情や会話のトーン、ちょっとした愚痴の中に隠れています。各部門のフロアを歩き、「最近どうですか」「何か困っていることはありますか」と声をかける。それだけで、デスクにいては絶対に聞こえない声が拾えます。
現場に溶け込んだら、次にやるのは「小さな武器を渡す」ことです。大きな改革を提案してはいけません。最初にやるべきは、目の前の人が「便利だ」と感じる小さな改善です。レポート機能の使い方を1対1で教える、日々の報告作業を自動化する、関数を一つ教えて毎月の手作業をなくす。どれも30分から1時間で終わることです。しかし「あなたの毎月の作業が2時間なくなりますよ」という入口には、確実に相手が反応します。人は自分ごとでしか動きません。
改善を進めると、自分一人では動かせない範囲にぶつかります。組織的な意思決定が必要な場面や、複数チームにまたがる調整です。この壁を越えるために必要なのが、現場で影響力を持つマネージャーやリーダー、いわゆるChampionです。日頃からチームの非効率さに課題意識を持っている人を探し、小さな成果を積み重ねて信頼を得る。Championが「この改善は効果があった」と周囲に伝えてくれれば、改善の波は一人の力をはるかに超えて広がります。
もう一つ、必ず出会うのが「いいですね、ぜひやりましょう」と言った後、何も動かない人です。悪意はありません。日々の業務に追われて優先順位が下がり、忘れてしまうだけです。この問題への対処はシンプルです。物理的に、相手の席の隣に座る。「30分だけお時間もらえますか、一緒にやりましょう」と言って、横に座り、一緒に手を動かす。
これには三つの効果があります。物理的に後回しにしにくくなること。隣で作業を見ることで相手の業務を深く理解できること。そして「口だけじゃない、一緒に汗をかいてくれる」という信頼が生まれることです。
経営者の方へ： 改革を任せている人が、日中ずっと会議とレポート作成に追われていませんか。現場に張り付く時間そのものを業務として認めなければ、その人は現場の本当の課題に触れられません。改善の芽は、デスクの外にしか落ちていません。
御社の改革担当者は、現場に張り付く時間をどれだけ確保できていますか。
5. 企画書に「撤退ライン」を入れないと埋没コストの罠に陥る
改善は「やってみましょう」の一言で始められます。しかし改革はそうはいきません。複数部門をまたぎ、予算とリソースを使い、数か月以上の期間を要します。経営層の意思決定が要るため、「なぜやるのか」「何が変わるのか」を企画書に落とし込む必要があります。
企画書に書くべき要素は、背景、課題、目的、体制、スケジュール、予算、リスクなど七つを超えます。中でも最も見落とされがちで、最も大切なのが「撤退ライン」です。
撤退ラインとは、そのプロジェクトを中止する条件をあらかじめ定めておくことです。「第1フェーズ完了時点で主要要件の8割以上が実現不可能と判明した場合は中止する」「予算超過が一定割合を超えた時点で経営会議に再度諮る」。こうした条件を、プロジェクトが始まる前に決めておきます。
撤退ラインを引かないまま走り出すと、途中で「これはまずい」と気づいても止められなくなります。「ここまでやったのだから」という心理が働くからです。投じた時間と費用は戻ってこないのに、それを惜しんで前に進み続けてしまう。埋没コストの罠です。
撤退ラインは、プロジェクトの失敗を前提とした後ろ向きな仕組みではありません。むしろ逆です。あらかじめ「止める条件」を決めておくからこそ、途中で立ち止まる判断がしやすくなります。想定外の事態が起きたときに立ち止まるのは、逃げではなく、判断力の証です。
御社の改革プロジェクトには、始める前に決めた「やめる条件」がありますか。
6. 改革の起点は号令ではなく「お客様に迷惑をかけない」
ここからは、私自身が手掛けた改革プロジェクトの話です。
以前いた急成長企業では、複数の事業部がそれぞれ独自のやり方で請求書を発行していました。ある事業部は月初に、別の事業部は月末締めの翌月10日に送る。テンプレートのデザインも問い合わせ先の電話番号も違う。同じ会社なのに、顧客には別々のフォーマットで複数の請求書が届いていました。
この改革を始めるとき、私が意識したのは「号令で動かさない」ことでした。「全社統一の請求フローを作ります」とトップダウンで宣言しても、各事業部にはそれぞれの事情があります。「うちはこのやり方で長くやってきた」「今のフローで問題ない」。号令だけでは抵抗が生まれます。
そこで起点にしたのは、「お客様に迷惑をかけない」というシンプルな一点でした。各事業部のマネージャーを集めて、こう伝えました。「同じお客様に、月2回、別々のフォーマットで請求書が届いています。お客様から『どちらが正しいのか』という問い合わせが来ています。この状況を解消しませんか」。誰も反論できません。「お客様に迷惑をかけていい」とは誰も言えないからです。
社内効率の話から入ると「うちの部門は効率的にやっている」と反論される余地が生まれます。しかし顧客視点から入ると、全員が同じ方向を向かざるを得ません。
プロジェクトは、現状把握、統合設計、システム構築とテスト、移行と定着という順にフェーズを分けて進めました。最も難航したのは、統合設計の段階で浮上した「各事業部の例外」の扱いです。「うちの事業は月末締めでないと困る」「この顧客だけは特殊な請求条件がある」。全体最適を進めると、必ず部分の例外が出てきます。
ここで取った方針は「8割を統一し、2割の例外は許容する」でした。完全統一を目指すと、例外対応でシステムが複雑化し、結果的にプロジェクトが破綻します。8割統一できれば、顧客への混乱は大幅に減る。この現実的な落としどころを設定したのです。
移行も一度に全事業部を切り替えるのではなく、まず1事業部で先行稼働し、問題がないことを確認してから順次展開しました。プロジェクト完了後、同一顧客への重複請求はゼロになり、請求書に関する顧客からの問い合わせも月5件からゼロに減少しました。請求業務の工数も、全社合計で月40時間削減されました。
この改革は、改善者として積み重ねた信頼がなければ実現できませんでした。各事業部のマネージャーが「あの人が言うなら協力しよう」と動いてくれたのは、それ以前に現場で一緒に手を動かしてきた実績があったからです。改善が改革の土台を作り、改革が改善では届かなかった価値を生む。この循環こそが、BizOpsという仕事の本質です。
御社の改革プロジェクトは、号令から始まっていますか。それとも、お客様の視点から始まっていますか。
よくある質問
Q1. 改善と改革、どちらを先にやるべきですか。
A. 例外なく改善が先です。改善で実績を出し、信頼を得てからでなければ、改革の権限は手に入りません。改革を急いで号令から始めると、現場の抵抗にあって前に進みません。
Q2. 経営の後ろ盾がないまま改革を進めることはできますか。
A. 難しいと考えてください。改革は複数部門をまたぎ、予算とリソースを使う取り組みです。経営層の意思決定を伴わない改革は、途中で部門間の調整に行き詰まります。まずは改善で実績を積み、経営が構想段階から相談してくれる関係を作るところから始めてください。
Q3. 撤退ラインは誰が決めるべきですか。
A. プロジェクトを起案する側と、意思決定する経営層が、企画書の段階で一緒に決めておくべきものです。プロジェクトが動き出してから決めようとしても、埋没コストの心理が働いて冷静な線引きができなくなります。
Q4. 現場に張り付く時間がなかなか確保できません。どうすればいいですか。
A. まずは1日のうち1時間、あるいは週に1回でも、デスクを離れて現場を回る時間を固定してください。改善のタネは、現場の何気ない会話の中にしかありません。この時間を確保できるかどうかを、業務として経営に認めてもらうことも同時に必要です。
お知らせ
改善と改革の順番を間違えないまま、事業全体のオペレーションを見直したい。そんな経営者・責任者の方は、お気軽にご相談ください。
現場に入って一緒に整理するところから始めます。初回のご相談は無料です。
参考文献・出典
- 本記事の請求書統合プロジェクトの実録、および「自席を捨てろ」「張り付き戦法」に関する記述は、いずれも筆者（祖川慎治）自身の前職での実務経験に基づきます
- 改善と改革の定義、各Opsとの比較、撤退ラインの考え方に関する考察は、筆者が執筆中の書籍『BizOps本（仮題）』第2章・第5章の議論を再構成したものです
- 本記事内に出典のない数値・記述は、すべて筆者の実務経験に基づく記述です
- 関連記事：BizOpsがあなたの会社で必要な理由
この記事を書いた人
祖川 慎治（そがわ・しんじ）
株式会社テイクアステップ 代表取締役／一般社団法人BizOps協会 代表理事。大手メーカー・大手SIerを経て、HR Techベンチャーで全社の業務改善を担うBPR部署の責任者として社内IT戦略の立案から実行・定着化までを担当。5年で300名から1,400名へ成長する組織とIPO実現を業務基盤の面から下支えした。2021年に株式会社テイクアステップを設立し、BizOps・業務プロセス設計の実行支援を行う。ポッドキャスト「どうする？BizOps」配信中。