BizOpsの組織が生まれる日――担当者の意思ではなく、会社の力学が決める

株式会社テイクアステップ 代表取締役社長 兼 一般社団法人BizOps協会 代表理事の祖川慎治です。

御社に、こんな状況はありませんか？

• 業務改善やシステムを見ている人が、実質的に社内で一人しかいない
• 事業は伸びているのに、業務のほうが追いつかず、毎月どこかで破綻している
• 「そろそろ組織にしたほうがいいのでは」という話は出るが、判断の基準がない
• 誰の担当にもなっていない業務が、社内のあちこちに点在している
• 企画や管理の部門が「コストセンターではないか」と見られている

一つでも心当たりがあるなら、今日の話はきっと刺さります。

そして最初にお伝えしたいのは、これは担当者の能力や人望の問題ではないということです。

BizOpsの組織は、担当者が望んだから生まれるのではなく、会社の力学が動いた瞬間に生まれます。その力学を知らないまま「うちにもそういう部署が必要だ」と旗を立てても、まず通りません。

なお、前回の記事の最後で、「担当者が孤独にならないための組織設計」について書くとお伝えしていました。今回はその一歩目として、私が実際に一つの組織が生まれる場に立ち会った話を、前後編でお話しします。

この記事の要点（3行サマリ）

• BizOps組織は、担当者の意思ではなく会社の力学で生まれます。いつ組織にするかを、担当者が決めることはできません
• できたばかりの組織に回ってくるのは、構造的に誰もやりたがらない仕事です。ただし、それを持てること自体が存在理由になります
• 担当者に今日から用意できるのは一つだけ。誰の担当にもなっていない業務を、数字つきで一つ名指しできる状態にしておくことです

目次

1. 組織は、あなたの意思では生まれません
2. 集まった直後に来たのは、誰もやりたがらない仕事でした
3. 「スポッと空いている」ものを、誰が拾うのか
4. おわりに――まず、隣の空白を一つ名指しする

1. 組織は、あなたの意思では生まれません

私は以前いた組織で、BPR（Business Process Re-engineering／業務プロセスの抜本的な見直し）という名前の部署を立ち上げました。

……と書くと、私が構想して、企画書を書いて、経営に通した話に聞こえますよね。

違います。

きっかけは、私とはまったく関係のないところにありました。

「一回ゼロリセットする」と言われた

当時の会社は、いわゆる拡大路線のまっただ中でした。

売上の伸び率は年40〜50%。採用は毎月10人から20人が入ってくる。組織は、細かいものなら毎月、大きな改編でも3ヶ月から半年に一度は変わっていました。

そうすると、組織の歪みが出ます。

そのとき経営の側から出てきたのが、ビジネス・プロダクト・コーポレートの各部門にある企画部門は「コストセンターではないか」という見方でした。

売上や利益を明確に背負っている部門と並べられると、企画部門は数字を持っていません。しかも人が増えている。

だから、一回ゼロリセットしよう、と。

なくすと決めた瞬間に、「でも機能は要る」となる

ただ、ゼロリセットは組織の話であって、業務の話ではありません。

請求は毎月発生します。管理画面のメンテナンスは止められません。事業ごとの数字の集計も、誰かがやらないと経営会議が開けません。

そこで、各事業に散らばっていた企画や業務改善の担当者を、一箇所に集めることになりました。

主力事業の売上・請求まわりを見ていた人。後発の別事業で同じ機能を見ていた人。社内の管理画面を担当していた人。

三つのチームだったので、三人のマネージャーと、合計で10人ほどの部隊になりました。

これがBPR部の発足の経緯です。

つまり、私たちの部署は、機能を強くするために作られたのではなく、組織をいったん壊した結果、行き場のなくなった機能の受け皿として作られました。

組織は「たまたま出来上がった」

三人のマネージャーに、この組織を作りたいという意思はありませんでした。私にもありません。決めたのは、当時の経営です。

外的要因のほうが、はるかに大きかった。会社の事情と、人事の都合です。

組織は、振り子が振れた瞬間に生まれます

部分最適と全体最適が振り子のように行き来するという話は、以前の記事で詳しく書きました。事業を伸ばす局面では部分最適が正解で、コストやガバナンスが問われる局面で全体最適に振れる、という話です。

今回の件は、その振り子が全体最適側に振れた瞬間そのものでした。

そして今になって思うのは、これは私の会社だけの話ではないということです。

BizOpsの組織は、振り子が全体最適に振れた瞬間にしか生まれません。振れた瞬間に「じゃあ、誰がまとめるのか」という問いが必ず立つからです。

逆に言えば、振り子が部分最適側にある時期に「横断組織を作りましょう」と提案しても、まず通りません。事業を伸ばす邪魔にしか見えないからです。

だから私は、組織にするタイミングを担当者が選ぶことはできない、と考えています。担当者に選べるのは、振れた日までに何を用意しておくかだけです。

御社の振り子は今、どちら側にありますか？

ここで一つ、名称の話をさせてください

私たちの部署名はBPRでしたが、やっていたことは、今の言葉で言えばBizOps（ビズオプス／事業運営を仕組みで支える機能）です。

概念としてのBPRは、業務プロセスを根本から設計し直すことを指します。既存のやり方を前提にしない、というのが本来の定義です。

ただ、職種としての実態は、もう少し泥臭いものでした。

実際に手を動かしていたのは、請求書のフォーマットを揃えることであり、承認経路を直すことであり、Salesforceの項目を整理することです。抜本的な再設計というより、目の前で壊れているものを直し続ける仕事でした。

「BPR」「BizOps」「業務推進」「経営企画」――名前が変わっても、中身は会社ごとに違います。逆に、名前が違っても同じ仕事をしていることも多い。

だから求人を見るときも、社内で異動先を探すときも、名称ではなく「その部署が何をどこまで持っているか」で見たほうが早いです。

経営者の方へ： 御社の組織が今、部分最適と全体最適のどちらに振れているかを、一度言葉にしてみてください。全体最適に振れているのに横断機能を置いていないなら、その分の非効率は今この瞬間も積み上がっています。逆に部分最適のフェーズなら、横断組織はまだ早い可能性があります。

2. 集まった直後に来たのは、誰もやりたがらない仕事でした

こうして、チームは一箇所に集まりました。ただ、集まっただけです。

三つのチームは、三つのラインのまま並んでいました。そして最初に来た大玉が、契約と請求の統合プロジェクトでした。

※このプロジェクトで何が起きていたかは、BizOpsがあなたの会社で必要な理由の第4章で書いています。三つの事業がそれぞれ独自の契約・請求機能をプロダクトの中に持っていて、複数事業をご利用のお客様のもとには、フォーマットも到着日も違う請求書が別々に届いていました。今回は、その中身ではなく、できたばかりの組織がなぜその仕事を持つことになったのかという側面から書きます。

誰もやりたがらない仕事だったから、回ってきました

正直に言うと、この仕事が私たちに来たのは、私たちが適任だったからではありません。

誰もやりたがらなかったからです。

契約情報は、プロダクト（サービスそのもののシステム）の中に組み込まれています。成果報酬型のビジネスなので、「この期間に何人決まったか」がわからないと請求金額が出せない。つまり、請求の仕組みとプロダクトが、構造的に分かちがたく繋がっていました。

4ヶ月、遅れました

結果から書きます。

このプロジェクトは大きな遅延を2回起こして、計画から4ヶ月遅れました。

1回目は、要件定義のフェーズです。

各事業が長年かけて育ててきたローカルルールと、独自の請求管理の方法。この洗い出しを、私は甘く見積もっていました。

ヒアリングを重ねるたびに、想定していなかった例外処理が次々に出てきます。議論は堂々巡りになり、ここで2ヶ月をロスしました。

2回目は、データ移行と検証のフェーズです。

いざ既存データを統合しようとしたら、プロダクト間で顧客データの名寄せがまったくできていませんでした。

「システム利用料」と「利用料」のような表記の揺れ。過去の二重登録。このクレンジングに、想定の3倍以上の時間がかかりました。ここでさらに2ヶ月です。

どちらも、技術が難しかったという話ではありません。私が、現状の汚さを見積もれていなかったという話です。

「ロードマップに載せられるわけがありません」

遅れた背景には、もう一つあります。

計画の当初は協力を得られていたのですが、事業の変化に伴ってプロダクト部門とエンジニア部門の優先順位が変わり、そこで止まりました。

プロジェクトの初期、ある主力事業のプロダクトマネージャーに、Salesforceとプロダクトのデータ連携機能の開発を打診したときは、こう言われています。

「僕らのミッションは、エンドユーザー向けの価値を1日でも早くリリースして売上を作ることなんですよ。請求書を綺麗に発行するためのデータ連携なんて、社内都合の裏方作業じゃないですか。そこに工数を割く時間があるなら、新機能の開発にリソースを全振りさせてもらいます。プロダクトのロードマップに載せられるわけがありません」

このセリフは、今でも覚えています。

ただ、これを「非協力的な部署だった」と書くのは、まったく的外れです。

彼らはPL（損益計算書／その部門が背負う売上と利益の責任）を明確に背負っています。今期の数字を作る責任がある。

その状況で、顧客に近い機能のリリースと、社内の請求業務の統合、どちらにエンジニアを割くか。前者を選ぶのは、経営判断として合理的です。

デザインを変えたい。新しい機能を出したい。当然そう思います。私が逆の立場でも、同じ順番をつけたはずです。

「確かにその通りですね」と、まず受け止めました

どう進めたか。

私がやったのは、反論しないことでした。

「確かにその通りですね」と一度受け止めたうえで、こう提案しています。

「だったら、その社内都合の裏方作業は、全部こちらでSalesforce側に引き受けます。プロダクトチームには、面倒な管理画面を一切作らせません。だから、最低限のデータを取り出すAPIの口だけ、1工数で開けてもらえませんか」

相手の「売上を作る」という大義名分は、そのまま尊重する。そのうえで、面倒な部分をこちらが引き取る。

この形にして、ようやく首を縦に振ってもらえました。

つまり、契約と請求は、誰が悪いわけでもなく、構造的に誰もやりたがらない仕事でした。

民主的な合意形成を、捨てました

遅延が重なって、プロジェクトの雰囲気は最悪でした。

そこで、進め方を二つ変えています。

一つは、全員が納得する着地点を探すのをやめたことです。

それまでは各事業の要望を全部聞いて、どこかに落とし所を作ろうとしていました。これでは埒が明きません。

そこで「全社共通のOSとして、目指す業務プロセスはこれだ」という形を先に決め、この共通ルールに乗らない例外的な要望は、原則として却下するというスタンスに切り替えました。

もう一つは、事業ごとにブリッジ担当者を一人ずつ立てたことです。

各事業から、システムとオペレーションに最も詳しい実務のキーマンを引っ張り上げて、専任にする。そのうえで週次の定例で、遅れているタスクとその原因を全員の前に出し、その場で解決策を決めていく。

意思決定は、速くなりました。

1割は、手作業のまま残しました

もう一つ、諦めたことがあります。

100点でリリースしようとしていたら、このプロジェクトは崩壊していたと思います。

だから、9割を仕組みに乗せて、残る1割は手動運用にすると決めました。

残した1割の正体は、特定の超大口のお客様だけに適用されていた個別対応です。

• 子会社3社分の利用料を親会社に一括請求する。ただし請求書の明細は、子会社の事業部ごとに内訳を分けて記載する――という合算請求
• 「この顧客だけは、2つのプランの合算から毎月決まった額を手動で引く」といった、特別稟議による個別値引き

どちらも自動化しようとすると、その1社のためにSalesforceのオブジェクト設計が一気に複雑になります。

だから、Salesforceからは標準の請求書を出力して、経理の担当者が最後の10分でスプレッドシートを使い、手で合算と値引きの調整をしてPDFにする。この運用を残しました。

きれいではありません。ただ、この1割を諦めたから、リリースまで辿り着けました。

「コストセンター」に見える部署が、本当は何をしているのか

ここで、第1章の話に戻ります。

私たちの前身は、「コストセンターだろう」と言われてゼロリセットされた部署でした。

そして、その言われ方は半分わかります。売上も利益も持っていない。数字で説明できるものが少ない。

でも、実際にやっていたのは何かというと、放っておけば事業運営が非効率になっていく、その進行を止める仕事です。

請求書が三つに分かれたままなら、お客様の負担は増え続けます。事業が四つ、五つと増えれば、同じ機能が四つ、五つと重複して作られます。誰かが止めなければ、非効率は自動的に積み上がっていく。

止めた分は、数字に出ません。起きなかったコストは、誰にも見えないからです。この「成果が数字では伝わらない」という話は、以前BizOpsの成果は数字では伝わらない ── 評価を動かす「証言」の設計でも詳しく書きました。あわせてご覧ください。

だから一見コストセンターに見える。ただ実態としては、そこがないと組織が立ち行かなくなる機能です。

御社で、いま「構造的に誰もやりたがらない仕事」は何でしょうか。

3. 「スポッと空いている」ものを、誰が拾うのか

※部門や会社の枠を越えて情報を持ち寄る話については、以前の記事その提案、本当に御社のため？ ― ベンダーに振り回されない3つの武器の「武器②横連帯」でも触れています。あわせてご覧ください。

ここまでは、会社の力学の話でした。

ここからは、私個人の視点で見えていたものを書きます。

BizOpsは、フロントラインに寄りがちです

BizOpsという言葉で語られる仕事は、どうしてもフロントライン中心になります。

マーケティングがあって、インサイドセールスがあって、商談があって、受注があって、請求まで。この一本のラインが、話題の中心になりやすい。

それ以外の業務はどうだったのか。

私が見ていた範囲では、点在していました。

各部門が、それぞれ必要なSaaS（クラウド型のソフトウェア）を個別に導入している。それ自体は悪いことではありません。自分たちで運用できるなら、そのほうが速いですから。

問題は、誰も全体を見ていないことでした。

事業は年40〜50%で伸びています。その速度に業務が追いつくには、バックオフィスも同じ速度で効率化していかないと、どこかで詰まります。

それをやっている人は、いたのか。

いなかったんです。

コーポレートIT部門はありました。ただ、そちらはPCの調達、ネットワーク、オフィス移転、セキュリティで手一杯です。急成長する会社では、この四つだけで一つの部署が埋まります。

つまり、業務プロセスそのものを見る役割が、組織図の上でスポッと空いていました。

空いていたところで、何が起きていたか

具体的に何が起きていたか、ここでは代表的な内容を一つだけ書きます。

当時のワークフロー（申請と承認の仕組み）では、マネージャー以上が、自分で申請して自分で承認できてしまう状態がありました。

自己承認です。

上場準備の内部統制で、一発でアウトになるやつですね。

ここで、私の判断ミスを書いておきます。

私は当時、「やめてください」と言いました。言っただけです。

そして、当時のワークフロー製品の仕様では、自己申請した内容を自己承認しないようにすることはできたものの、複雑な自己承認要件をかなえることができず、これ以上の制御はできないと判断していました。運用でカバーするしかない、と。

今から振り返ると、この判断の根拠が弱すぎます。私は製品の設定画面を一通り見て、標準機能にないことを確認しただけでした。ベンダーに問い合わせてもいませんし、他社がどう回避しているかも調べていません。

「探したけれど無かった」ではなく、「探し方を知らなかった」というのが正確なところです。

結局、直せたのは外圧が来てからでした

この自己承認が是正されたのは、ずっとあとです。

上場準備が本格化して、内部統制対応の監査が入ったときでした。

監査法人と主幹事証券会社から、「自己承認が通る承認プロセスは、職務分掌の観点で完全にアウトです」と指摘を受けました。

そこからは、早かったです。

普段なら「承認を待っていたらスピードが落ちる」「面倒くさい」と反対するマネージャー陣に対して、「上場に向けた必須要件です」と言えば通る。一括で自己承認を不可にする制御を、一気に実装しました。

……つまり私は、外から指摘が来るまで直せなかったわけです。

社内の論理では通せなかったものが、外圧では一発で通る。

そして、その外圧が来るまでの数年間、ザルな承認経路は動き続けていました。あのとき「できない」で止めたのは、私です。

だから、線を引きました

とはいえ、点在しているものを全部拾うのは無理です。人がいませんから。

そこで、線を引きました。

各部門が自分たちで入れて、自分たちで運用できているものは、いったん置いておく。手を付けるのは、全社共通で使っているものから。

理由は単純で、全社共通のものは、壊れたときの影響範囲が最も広いからです。そして、部門をまたぐので、どの部門も自分では直せません。

実際に着手したのは、この三つでした。

① 全社のSalesforce

営業活動のデータ一元化はもちろんですが、当時はなんと、人事の採用管理までSalesforce上に構築されていました。

応募者データの表記揺れ、面接官による二重登録。個人情報保護の観点でも、かなり危うい状態です。ここの再設計とガバナンス強化から入りました。

② 見積書・申込書の発行

営業担当が個人のスプレッドシートやExcelのひな形を使って、備考欄を勝手にカスタマイズして出力し、そのまま契約を締結してくる。法務とガバナンスのリスクです。

Salesforceから標準化された書式をワンクリックで出せる形に移しました。

ただし、新規事業は対象から外しています。ビジネスモデルもキャッシュポイントもころころ変わるので、ある程度落ち着いてから実装する、と決めました。

③ 販売管理と請求の基盤

第2章に書いた統合プロジェクトが、これにあたります。

逆に、置いておいたものも書いておきます。

一つは、財務会計システムです。決算と仕訳は経理財務部門がすでに回していました。そこにこちらが踏み込むと、上場準備のスケジュールを圧迫します。データの受け渡し口だけ合わせて、あとはノータッチにしました。

もう一つは、現場が自作していた小さな連携ツールです。「Slackとスプレッドシートを勝手に繋いで、アポの通知を飛ばす」という類のもの。

セキュリティのポリシーを大きく外れない限りは、見逃しました。現場の自走スピードを落とすほうが、損だからです。

何に手を付け、何を見送ったかを整理すると、次のようになります。

同時に、コーポレートIT部門とは役割を分けました。

向こうはライセンスの管理、契約まわり、コストの把握を持っています。こちらはプロセスを持つ。そのうえで、情報を渡し合いながら進めていました。

この分担は、いま一人で全社を見ている方にも使えると思います。「全部見る」と言った瞬間に、何も見られなくなります。

御社の組織図で、いちばん大きく空いているマスはどこでしょうか。

経営者の方へ： 「誰がやっているのか」を担当者に聞くのではなく、組織図を広げて「どこにも書かれていない業務」を数えてみてください。承認経路、社内申請、部門間のデータの受け渡し。ここが空白のまま人数だけ増えると、内部統制の指摘は必ず後から来ます。

4. おわりに――まず、隣の空白を一つ名指しする

ここまで、一つの部署がどう生まれたかを書いてきました。

改めて振り返ると、私が意思決定したことは、ほとんどありません。

組織を作ると決めたのは経営です。集まるメンバーを決めたのも、当時の人事と組織改編です。私がやったのは、空いていた場所に線を引いたことくらいです。

だから、お伝えしたいのはこれです。

組織になるタイミングを、私たちは選べません。でも、その日までに何を用意しておくかは、私たちが決められます。

そして、今日から用意できるものが一つあります。

社内で、誰の担当にもなっていない業務を、一つ名指しできる状態にしておくことです。

「バックオフィス全般が非効率です」ではなく、「◯◯の申請だけが紙で回っていて、月にXX件、承認に平均YY日かかっています」まで言えるようにしておく。

振り子が全体最適に振れた日に、その一行を出せる人のところに、話は来ます。

その一行を、あなたは今すぐ書けますか？

一つ、いまも自信がないことがあります

最後に、この記事で書ききれていないことを一つ。

第2章で、「共通ルールに乗らない例外的な要望は原則として却下する」「遅れているタスクと原因を週次で全員の前に出す」という進め方に切り替えた、と書きました。

意思決定は速くなりました。ただ、あれは気持ちのいいやり方ではありません。

却下される側は面白くないですし、進捗を全員の前に出されるのは、担当者にとってはきついはずです。

当時、私はそれをどこまで引き受けさせてしまったのか。振り返っても、正直よくわかりません。

「トップダウンに切り替えたら進むようになりました」と一行で書けば、成功事例のように読めます。でも実際には、誰かに負担を寄せた上で成立していたはずで、そこを私は把握しきれていません。

ここは、答えが出ないまま置いておきます。

よくある質問（FAQ）

Q1. BizOpsや業務改善の部署は、どのタイミングで作るべきですか？

A. 作るタイミングは、担当者の側からはほとんど選べません。組織は、部分最適と全体最適のあいだを振り子のように動いており、横断組織はコストや統制が問題になって全体最適側に振れたときに生まれやすいためです。部分最適に振れている時期に横断組織を提案しても、まず通りません。準備としてできるのは、振れた瞬間に「誰の担当にもなっていない業務」を具体的な数字つきで一つ提示できる状態にしておくことです。

Q2. 一人で全社の業務を見ています。どこから手を付ければいいですか？

A. 全社共通で使っているものから手を付け、各部門が自前で入れて自前で運用できているものは、いったん置いてください。全社共通のものは壊れたときの影響範囲が最も広く、かつ部門をまたぐためどの部門も自力では直せないからです。また、コーポレートIT部門がある場合は、ライセンス・契約・コストは向こう、プロセスはこちら、と役割を分けたうえで情報を渡し合うと、一人でも回せる範囲が広がります。

Q3. 部門横断のプロジェクトが、要望の調整で止まってしまいます。

A. 全員が納得する着地点を探すのをやめる、という判断が必要になる局面があります。目指す業務プロセスの形を先に決め、そこに乗らない例外的な要望は原則として却下する。あわせて、各部門から実務のキーマンを一人ずつ専任のブリッジ担当として立て、週次で遅れとその原因を全員の前に出して、その場で決めていく。あわせて、すべてをシステムに乗せようとしないことも重要です。私は9割を仕組みに乗せ、残る1割は手作業として残しました。

Q4. 業務改善の部署は、経営から見るとコストセンターではないのですか？

A. 売上も利益も持たないため、一見そう見えます。ただし実際にやっているのは、放っておけば積み上がっていく非効率の進行を止める仕事です。止めた分は数字に出ません。起きなかったコストは誰にも見えないからです。判断の材料としては、「この機能がなかった場合、同じ仕組みが事業の数だけ重複して作られるか」を見ると実態に近づきます。

……人がいない、という次の問題

ここまでで、組織はできました。仕事もあります。

ただ、ここから先に、もっと厄介な問題が待っていました。

人が、圧倒的に足りなかったんです。

外部採用を打っても来ない。それならばと社内公募をかけたら、手を挙げた人はゼロでした。

後編では、そこから何をしたのかを書きます。応募がゼロだった本当の理由と、非公式の勉強会から人を集めた話です。

無料相談のご案内

「誰の担当にもなっていない業務が社内に点在しているが、それを整理して上に出す材料がない」「そろそろ組織にすべきか、判断の軸がほしい」。

そんな経営者・責任者の方、そしてご担当者の方は、お気軽にご相談ください。

社外の知見と御社の情報を掛け合わせて、まず現場が喜ぶ改善から、その先の改革へ。順番も含めてご一緒します。

実際、最初のご相談は現場のご担当者お一人から、というケースがほとんどです。上申の材料づくりからご一緒します。初回のご相談は無料です。

お問い合わせはこちら

これまでの支援実績はこちら

参考文献・出典

• 本記事に登場する数値（売上の伸び率年40〜50%、採用が毎月10〜20人、三つのチームで合計10人ほどの部隊、統合プロジェクトの4ヶ月の遅延、仕組み化9割・手動運用1割の切り分けなど）は、いずれも筆者（祖川慎治）自身の実務経験に基づく記述です。第三者調査による統計値ではありません
• 「組織は部分最適と全体最適の振り子で生まれる」という整理、および自己承認の是正・全社共通システムの優先順位づけに関する考察も、筆者の実務経験に基づく整理です
• 前回の記事：その見積もり、本当に発注側のためですか？-ベンダーの行動原理を読み解く3つの視点-
• 関連記事：その提案、本当に御社のため？ ― ベンダーに振り回されない3つの武器
• 関連記事：BizOpsがあなたの会社で必要な理由
• 関連記事：「全社最適プロジェクト」が支援ファーム丸投げになる、本当の理由
• 関連記事：BizOpsの成果は数字では伝わらない ── 評価を動かす「証言」の設計

この記事を書いた人

祖川 慎治（そがわ・しんじ）

株式会社テイクアステップ 代表取締役／一般社団法人BizOps協会 代表理事。大手メーカー・大手SIerを経て、HR Techベンチャーで全社の業務改善を担うBPR部署の責任者として社内IT戦略の立案から実行・定着化までを担当。5年で300名から1,400名へ成長する組織とIPO実現を業務基盤の面から下支えした。2021年に株式会社テイクアステップを設立し、BizOps・業務プロセス設計の実行支援を行う。ポッドキャスト「どうする？BizOps」配信中。