BizOpsがあなたの会社で必要な理由 ―"名前のない仕事"が組織の競争力を左右する―

名前のない仕事、いなくなると困る人

あなたの会社に、こんな組織や人はいませんか？

• 誰の担当でもない課題が出てきたとき、気づいたら動いている人
• 事業を成長させるために、部門も職種も関係なく、必要なことをやりきる人
• 「何でも屋」と呼ばれているが、いなくなったらプロジェクトや事業が停滞してしまう人
• オペレーションや社内のシステムを知っており、課題を伝えると解決してくれる人
• 正確な経営数字を把握するために、頼みにしている人

その人がやっていること、それが BizOps（ビズオプス） です。

名前がないだけでいないと困る。これがBizOpsの現在地であり、この記事の出発点です。ではなぜBizOpsには名前がなかったのか。なぜ今、それを可視化すべきなのか。そしてBizOpsが組織の競争力になるために何が必要なのか。私自身の実体験も交えて、お話しします。

先日、あるインタビューでこんな問いを投げかけられたんです。

「BizOpsやってますって言われても、で、結局何やってるんですか？」

正直、私自身もこれまで一言でスパッと説明できたことがありません。そして、この「説明できない問題」こそが、「BizOps」という仕事に携わる人が抱えがちな悩みの根幹なんじゃないかと思っています。

今回は、なぜBizOpsが名無しの透明人間になってしまっていたのか、なぜ今それを可視化すべきなのか、そしてBizOpsが透明人間を脱するために何が必要なのかを、私自身の実体験も交えてお話しします。

1. そもそもBizOpsって何？ ―概念と職種のズレ問題―

まず大前提として正直に言います。

BizOpsの定義は、まだ確立されていません。

私自身が話していても、ちょっとブレることがあるくらいです（笑）。ただ、大まかに言うとこうです。

BizOps＝ビジネスオペレーション。つまり、顧客や事業に価値を届けるためのオペレーションを、どう構築し、実行し、改善していくか。その営みの総称。

対象範囲でいえば、RevOps（レベニューオペレーション）、CorpOps（コーポレートオペレーション）、HROps（人事オペレーション）、MOps（マーケティングオペレーション）…いろいろ言われますが、それらを包含する上位概念としてBizOpsがあると私は捉えています。

「で、何やってるんですか？」に答えられない問題

ここで厄介なのが、「概念としてのBizOps」と「職種としてのBizOps」は意味合いが違うということなんです。

「BizOpsやってます」と言ったとき、それは職種としてのBizOpsの話ですよね。

まず職種として何をしているかというと…

• リードを獲得するための施策を企画・実行したり
• SalesforceなどのSaaS基盤を導入・運用したり
• 売上や契約の管理オペレーションを回したり
• データを整備して経営判断に資する情報を届けたり

…と、その一部を具体的に話すことで、相手にようやく「ああ、そういうことね」と理解してもらう感じなんですよ。

じゃあ概念としてはどうなのか。「経営の構想を現場に落とし、現場のデータを経営に返す好循環を作る」というような整理ができます。

「マーケター」に学ぶ、ふんわり括る力

ここで一つ、マーケターの例を出させてください。

「マーケティングやってます、マーケターです」って名乗っている人、たくさんいますよね？ でも、広義のマーケティングは事業戦略そのもの。ピーター・ドラッカーが定義したような、顧客創造としてのマーケティング。それをやっている人が、マーケターと名乗っている人の何割いるかっていうと…ほぼいないと思います。

一番人数が多いのは、リード獲得のところを運用している人たち。それはマーケティング運用であって、広義のマーケティングとは違う。でもみんな「マーケティングやってます」って言うんですよね。 そして、それで十分伝わる。

「あの人マーケターだよ」って言われたら、なんとなく「売れるようにする人なんだな」ってふんわり理解できますよね。

BizOpsにもこの”ふんわり括れる力”を持たせたい。 それが今、私がBizOps協会を通じてやろうとしていることの一つです。

転職サイトを見ても、BizOpsに当てはまる職種カテゴリってないんですよ。Salesforceを扱えるから「Salesforceエンジニア」を選ぶとSalesforceのコーディング中心の開発案件がメインとなる。とはいえ「経営企画」「事業企画」「情シス」…どれもちょっと違う。こっちもちょっと違う、あっちもちょっと違う。差し引いた残りがBizOpsである。

今まで「何でも屋」って呼ばれてきた人たちは世の中にいっぱいいます。表出できてないだけだと考えています。

2. なぜBizOpsには”名前”がなかったのか？

「名前がないってことは、重要じゃないから名前がないんでしょ？」

…そう思いますよね。世の中一般論で言えば、わざわざ名前がついていない仕事や概念は重要性が低いから名前がない、というのは一理あります。

でも、BizOpsは違う。名前がないのに、いないと困る。

じゃあなぜ名前がなかったのか。これには二つの側面があると思っています。

側面① SaaS企業の急増で、現場主導のIT化が進んだ

この10年でBtoBのSaaS企業が急激に増えました。インターネット企業の特色って、モノを売っていないことなんですよね。在庫を抱えない。リコールもない。バグがあってもすぐ直せる。つまり、自分たちのやり方自体を素早く変更できるという特性がある。

そうなると、スピード感が求められる。現場に近くないと速く回せるわけがない。でも、現場から遠いところにいる「〇〇企画」部門や情報システム部門は、見る範囲が広すぎて細かく速く回すところに力を割けなかった。

より現場に近いところで、現場主導のIT化が進んでいった。そしてそれをやるひとは重宝もされている。でも名前がなかった。

側面② 情報システム部門の構造的限界

もう少し歴史を遡ると、1990年代にERPという概念が日本にやってきました。企業のリソースをどうプランニングするかのための基幹システムですね。分散化されていた情報を集約させましょうという動き。これ、誰のためかっていうと、現場のためじゃなくて経営のためなんです。

その流れで情報システム部門が業務に食い込んでいったわけですが、モノがある会社はどうしても受注後の製造ライン・流通・会計処理の効率化に目が行く。「じゃあ営業側も見ましょう」となっても、営業はスピードが速いから全部は追いつけない。しかも情シスはコストセンターとして見られがちで、予算もそんなに割り振られない。

結果、売上を伸ばす側のオペレーション改善は、どうしても後回しになっていた。

「じゃあ手伝ってくれないんだ」と思った現場の人たちが、自分たちでやろうとした。そこにSaaSが登場しました。手軽な予算で自分たちで様々な改善をできるようになった。シャドーIT問題なんかも起きましたが、とにかく現場が自走し始めた。

その中で「システムに詳しい人がほしい」「横串で見てくれる人がほしい」というニーズが生まれ、BizOps的な役割を担う人が自然発生的に現れた。でも、その役割にはまだ名前がない。 これが今の状況です。

3. BizOpsの価値をiPhoneで説明してみる ―ハード・OS・アプリの3層構造―

以前、私がBPR部を立ち上げた会社で、もう一人のマネージャーが面白いたとえを使ったんです。

「会社の構造って、iPhoneと同じ3層構造なんですよ」 と。

これが非常にわかりやすかったので、紹介させてください。

3層構造の内訳

アプリ（＝各事業部） は、顧客に直接価値を提供する機能です。LINEを使っていたら、LINEのサービス内容が表示されて、そのサービスを享受する。各事業もそれぞれ独自のマーケティング・営業・プロダクトという要素を持って、顧客に価値を届けている。

OS（＝バックオフィス） は、各事業の共通基盤です。法務、経理、人事…各事業でやってきた内容をバックアップする存在。経営層と話をして、ヒト・モノ・カネのリソースを各事業に最適配置する役割を担っている。

ハード（＝経営リソース） は、ヒト・モノ・カネ・情報。会社の根幹ですね。

じゃあBizOpsはどこにいるの？

ここからがポイントです。

OSは「各事業における共通項」のはず。でも実態はどうか。バックオフィスの人でさえ全体を見ている人はごく一部で、自分が担当している事業しか見ていない。隣の事業が何をやっているか知りません、という状況が全然起きる。

そうなると、もう共通項ではない。形がどうあれ、組織図がどうあれ、実質的には各事業が個別に持っているのとニアリーイコール。

BizOpsはアプリ間の横串を通しながら、OSのアップデートを担う存在であり、「車輪の再発明」をさせず、共通オペレーションを効率的に行うために改革・改善をし続ける存在です。

各事業を横断的に見て、情報基盤をベースに、どう接続すれば事業が成長するかを企画し、運用・定着させる。「ムリ・ムダ・ムラをなくし、事業成長に寄与する」をミッションに、全体最適を設計して実行する機能。 それがBizOpsです。

4. 【実録】契約・請求統合プロジェクト ―部分最適から全体最適へ―

理屈だけだと「ふーん、全体最適ね」で終わっちゃうと思うので、具体的な実話をお話しします。

各事業部がバラバラに請求書を出していた時代

以前私がいた会社では、複数の事業がそれぞれ独自に契約・請求の機能を持っていました。プロダクトの中に組み込んで、独自にお客様に請求書を出していたんです。

何が起きていたかというと…

• 請求書のテンプレートが事業ごとにバラバラ
• 同じ意味なのに言葉が違う（「システム利用料」と「利用料」など）
• 請求書の発行タイミングもバラバラ（片方は1営業日、もう片方は3営業日）
• 両方の事業を利用しているお客様に、月に2回請求書が届く

お客様からしたら「月初で請求書きたばかり。今度も請求書？なんでタイミングもフォーマットも別々なの？ まとめてよ」。とおっしゃっていました。お客様もまとめて処理したい。つまりお客様のためになっていない。

なぜバラバラだったのか？ ―部分最適には理由がある―

けれど、各事業がそれぞれ独自に持っていたことには理由があるんです。事業としては生きるか死ぬかでやっている。そこそこ大きくなるまでは、自分たちで改善するために自分たちの独自機能を持った方がスピードが出る。これは一理あります。

ただ、ずっとそれでいいのかというと、そうじゃない。ある程度の規模になったときに「じゃあ統合しましょうね」というタイミングがやってきました。そうしてはじまったのが契約・請求の統合プロジェクトでした。

統合後に起きたこと

このプロジェクトでは、各プロダクトが持っていた契約・請求のシステム的な機能とオペレーション的な機能を剥がして、共通基盤に集約しました。

すると何が起きたか。

プロダクトチームの貴重なリソースをお客様に近い機能やコアとなる機能に集中することができた。また、お客様への価値提供から遠い契約や請求の処理は、正直やりたくないと思っているので後手後手に回る。何も好き好んで「金額間違えました」「期間違いますけど」って怒られるリスクを抱えたい人はいないですから。

その「やりたくないけど必要な仕事」を引き取ったら、大変喜ばれた。 そして契約や請求は統一され、お客様からの「また来たの？」というクレームもなくなった。

ちなみに、このプロジェクトの起点は「全体最適しよう！」という号令ではなかったんです。「お客様に迷惑をかけない」「価値を早く届ける」が先にあって、全体最適の形になった。そしてこの仕組みは使われ続け請求額が2倍になっても枚数が2倍になっても同じ人数で処理し続けることができた。自社も楽になった。

ここの順番は大事だと思っています。

5. BizOpsの評価問題 ―数値化より”口コミ”が効く理由―

ここからが多くのBizOps実務者が頭を抱えている話です。

「やった成果を、どう評価してもらえばいいんだ？」

請求書が統一されました、クレームが減りました。やった側は実感値として持っています。でも正直、それを”評価させる”のはめちゃくちゃ厳しい。 これがBizOpsが世の中にもっと出てきてない大きな理由の一つだと思っています。

マス向け社内広報は、実はさほど効かない

みんな試行錯誤するのが「自分たちの成果をどう数値化するか」ですよね。もちろん、主張するためには数値は必要です。

ですが、ここで重要なことを一つお伝えします。

自分たちで出している数値って、あまり信用されません。

なぜなら、「自画自賛」と受け取られてしまうからです。

最強の武器は「第三者のリファレンス」

じゃあ何が効くのか。

口コミです。 つまり、第三者からの「良かったよ」という声。

モノを買うときも同じですよね。企業のCMをバーンとやっても、鵜呑みにはしない。YouTube のレビューを見たり、@cosme を見たり、食べログを見たり…検証したくなる。そして、何が一番最後のひと押しになるかっていうと、友人からのおすすめなんですよ。

BizOpsの評価も同じ原理だと私は思っています。

さっきの契約・請求統合プロジェクトの例でいえば、プロダクトチームの人たちが「いやー、あの統合のおかげで本当に楽になったよ」って社内のあちこちで言ってくれること。これが、自分たちで数値を並べるよりもはるかに効果が高い。

利害関係がない第三者から「あのチームのおかげで助かった」と差し込まれたら、「お？」と思いますよね。

泥臭い”寝技”で口コミを引き出す

「でも、言ってくれって頼んでも言ってくれないでしょ？」

その通りです。「評価会議で言ってね」なんて頼んだら重たすぎる（笑）。

だからもっと泥臭くやるんです。

• こっちが出した施策報告に対して 「感想を一言だけ追記してね」 とお願いする
• Slackで相手が成果を発信したときに、こっちから先に「ありがとう」のリアクションを入れる
• お互いに感謝し合う文化を小さく作っていく

言ってねって直接頼むんじゃなくて、言いたくなる状況を泥臭く作る。 これは戦略的にやっていたわけではなく、結果的にそうなったんですが…今思えば最初から設計できていたら、もっとうまくいっていたと思います（笑）。

6. BizOpsが”透明人間”を脱するための2つの視点 ―会社と個人―

最後に、BizOpsが組織の中で”透明人間”にならないために必要なことを、会社の視点と個人の視点に分けてお話しします。

【会社の視点】複数の施策に「協力者」として名前が出続けること

会社の中で何かしら施策が行われたとき、誰がやったのかはみんな見ています。

そこに度々BizOpsの人の名前が出てくる。別に表立って発表するわけじゃない。でも横で見たら、複数の施策にずーっと協力者として名前が出ている。

「なんだかんだ、裏で支えているのはあの人たちだな」

こういう認識が取れるかどうか。空気にならないためには、この地道な存在感の積み重ねが大事だと思っています。

【個人の視点】「作る人」で終わるか、「相談される人」になるか

個人の視点では、もっとシビアな話をします。

こんな場面を想像してください。

【パターンA：作る人】

営業担当：「これSalesforceで作ってほしいんだけど」 BizOps：「わかりました、作りました」

【パターンB：相談される人】

営業担当：「こういうキャンペーンを打とうと思ってるんだけど、そもそもこの方向性で合ってるかな？ ちょっと一緒に確認してほしい」 BizOps：「なるほど、データを見ると〇〇の方が効果が出そうですね。過去のこの事例も踏まえると…」

全然違いますよね。

パターンAは、はっきり言って代替可能です。 外注しても品質は大体同じ。AIが進化したら、もっと代替されやすくなる。実行に近ければ近いほど、具体的な作業になればなるほど、空気と一緒です。

パターンBは、その会社の中のコンテキスト ―空気感、文化、前例、データ― が合わさって初めて成り立つ。 だから社内の人間でなければできないし、信頼関係がないとそもそも相談されない。

最初の第一歩は、確かに「作る人」からかもしれません。でもそこからちゃんとステップアップして、相談の粒度が徐々に抽象的になっていくかどうか。 「ここを改修して」から「そもそもこの方向性で合ってる？」に変わったら、もうあなたは”透明人間”ではありません。

構想段階から相談されるBizOpsは、会社にとっても個人にとっても、間違いなく価値がある存在です。

そしてこれは、もっと大きなキャリアの話にもつながります。

私が大切にしたいのは、「〇〇株式会社の誰々さん」ではなく、「誰々さんが携わった会社はすごい」と言われる人になろうということ。会社の看板に依存するのではなく、個人の名前で信頼される。BizOpsという横断的な仕事をしているからこそ、プロのジェネラリストとして自分のキャリアを切り拓ける。

「作る人」止まりでは、会社が変わったら価値がリセットされてしまいます。でも「相談される人」としてのスキルは、どの会社に行っても、独立しても、一生モノの武器になる。 そういうキャリアを、私はBizOpsに携わるすべての人を応援したいと思っています。

まとめ

• BizOpsは自然発生的に存在する役割。 でも、名前がなかったせいで”透明人間”になりがちだった。
• BizOpsを”見える化”する意義は、全体最適を実現するため。 そして何より、顧客に迷惑をかけず、価値を早く届けるため。
• 評価は自分たちの数値化だけでは不十分。 第三者の口コミ＝リファレンスを泥臭く引き出すことが、実は最も効果が高い。
• 「作る人」で終わらず、「相談される人」になること。 それがBizOpsが”透明人間”を脱する最大のカギ。

いきなり「BizOps部を作りましょう！」なんて改革を掲げても、現場は動きません。まずは目の前の人が困っていることを泥臭く改善する。「ありがとう」って言ってもらえる小さな実績を積む。その信頼の先に、初めて組織としての認知と評価がついてきます。

事件は会議室で起きてるんじゃない。現場で起きてるんです！一歩一歩確実に進んでいきましょう。