BizOpsは「何でも屋」なのか。何でもやってきた私が思う、その境界線

BizOpsについて調べていると、たびたび出てくる言葉があります。

「何でも屋」

これは、正直かなり分かります。

私自身、これまでの仕事を振り返ると、本当にいろいろなことをやってきました。

SFAやCRMを触る。

業務フローを整理する。

データを見る。

現場にヒアリングする。

ベンダーと話す。

部門間を調整する。

ルールを変える。

新しい仕組みをつくり、それを現場に定着させる。

最近も、SFAの刷新や請求領域の再構築など、一つの職種名だけでは説明しにくい仕事に関わっています。

だから、

「BizOpsって、結局いろいろやる人ですよね」

と言われたら、たぶん否定はしません。

実際、いろいろやります。

ただ、最近はこう思っています。

「何でもやる人」と「何でも屋」は、同じではない。

違いは、扱う仕事の幅ではありません。

仕事の受け方にあります。

組織の問題は、きれいに部署ごとに分かれてくれない

会社には担当が明確な仕事があります。

営業は営業。

経理は経理。

人事は人事。

システムは情報システム。

でも、本当に厄介な問題ほど、一つの部署だけでは解けません。

たとえば、営業データを使って管理側が数字を見たいとします。

必要な情報が足りない。

では、営業側の入力項目を増やすのか。

そうすると現場の負担が増える。

システムを変える必要があるかもしれない。

でもシステムだけ変えても、入力ルールが変わらなければ意味がない。

さらに掘ると、

「そもそも、その数字を見て何を判断したいのか」

という話になる。

こうなると、もう営業だけの話でも、ITだけの話でもありません。

こういう問題に、私は昔からよく入り込んできました。

今になって振り返ると、これがかなりBizOps的な仕事だったのだと思います。

「あの人に言えば何とかしてくれる」は、少し危ない

部門をまたいで動いていると、だんだん仕事が集まってきます。

「この数字を出してほしい」

「この項目を追加してほしい」

「この作業、自動化できませんか」

「この部署と調整してもらえませんか」

頼まれたものを返せば、周囲からは喜ばれます。

そのうち、

「あの人に言えば何とかしてくれる」

と言われるようになる。

これは、悪い評価ではありません。

むしろ私自身、困っている人がいて、自分に解決できるなら何とかしたいと思う方です。

でも、この状態が続くと少し危ない。

仕事を片づけているのに、仕事が減らないのです。

それどころか、どんどん増えていく。

理由は簡単で、

目の前の依頼は解決していても、その依頼が発生する構造は何も変わっていないからです。

ここが、私は一つの境界線だと思っています。

「レポートを作ってほしい」と言われたら

たとえば、

「毎週、このレポートを作ってほしい」

と言われたとします。

もちろん、作ることはできます。

Excelを組む。

データを自動取得する。

集計作業を短くする。

それも立派な改善です。

ただ、私はその前に少し気になります。

そのレポートは、誰が見るのか。

何を見るのか。

見たあとに、何を判断するのか。

その判断によって、何が変わるのか。

毎週である必要はあるのか。

聞いていくと、

「実は最近、誰もほとんど見ていない」

ということもあります。

そうであれば、一番良い改善は自動化ではありません。

やめることです。

SFAでも同じです。

「この項目を追加してください」

と言われたとき、そのまま追加することはできます。

でも、

「なぜ必要なんですか」

と聞いてみる。

すると、本当に知りたかったのはその情報ではなく、

「案件が止まっている理由を知りたい」

だったりする。

だったら、設計すべきものは変わります。

依頼された仕事を上手に処理する。

それ自体は悪くありません。

でもBizOpsとして見るなら、その一歩奥まで行きたい。

なぜ、この仕事が必要になっているのか。

私はそこを見ることの方が大事だと思っています。

「やる」より「やらない」の方が難しい

業務改善の仕事は、どうしても「何をつくったか」で評価されやすいです。

新しいシステムを導入した。

ダッシュボードを作った。

業務を自動化した。

新しいフローをつくった。

成果として分かりやすい。

一方で、実際に仕事をしていると、

やめる。

減らす。

まとめる。

作らない。

要望を断る。

こちらもかなり重要です。

むしろ、こっちの方が難しいことがあります。

何かを作れば、「やった感」は出ます。

でも、

「それ、本当に必要ですか」

と問い直す仕事は、成果が見えにくい。

場合によっては、要望を出してきた人に、

「今回はやらない方がいいと思います」

と言わなければならない。

それでも会社全体として見れば、その方が良いことがあります。

だから私は、

何でもできるから、何でも引き受ける

という状態にはしたくありません。

いろいろな領域を見るからこそ、

何をやるか。

何をやらないか。

その判断まで持つ。

そこまで含めて、この仕事だと思っています。

BizOpsは「横断する人」なのか

BizOpsの話では「部門横断」という言葉もよく出てきます。

確かに、私の仕事も部門をまたぐことが多いです。

ただ、横断すること自体が目的ではありません。

営業だけでは解けなかった。

だからITを見る。

ITだけでも解けなかった。

だから業務ルールを見る。

業務を見ていたら、評価指標までつながった。

評価指標を見たら、データの持ち方に問題があった。

そんなふうに、一つの問題を追いかけているうちに、結果として境界を越えていく。

なので私は、BizOpsを

「いろいろな仕事をする人」ではなく、問題が解けるところまで境界を越えていく人

と考える方がしっくりきます。

地方企業に来たら、同じ仕事をもっと直接やっていた

今、私は大企業で仕事をしながら、地方企業の経営にも携わっています。

こちらには、BizOpsという部署はありません。

DX推進部もありません。

業務企画の専任もいません。

でも、問題は普通にあります。

ある人にしか分からない仕事。

昔から続いている作業。

紙と口頭で何となく回っている運用。

誰が決めるのか曖昧な仕事。

新しい仕組みを入れたのに残っている昔のやり方。

こういう問題が出てくると、経営者自身が動きます。

現場を見る。

数字を見る。

ルールを変える。

ツールを選ぶ。

人と話す。

必要ならマニュアルまで作る。

外から見れば、こちらの方がさらに「何でも屋」に見えるかもしれません。

でも、やはり目的は何でもやることではありません。

人の頑張りや記憶だけに頼らなくても、会社が回る状態をつくること。

そのために必要なので、いろいろやる。

大企業と地方企業では、規模も予算も人数も違います。

それでも、ここは驚くほど同じでした。

何をする人かではなく、何のためにやる人か

BizOpsを仕事内容だけで定義しようとすると、かなり難しくなります。

SFA。

CRM。

データ。

BPR。

業務改善。

事業企画。

システム導入。

プロジェクトマネジメント。

どれも関係する。

でも、どれか一つだけでもない。

だから最近は、

「BizOpsは何をする職種なのか」

より、

「何のために存在するのか」

で考えた方が分かりやすいのではないかと思っています。

私なりの答えは、

事業が前に進むために、必要なところまで境界を越えて仕組みを整える。

です。

必要なら、何でもやる。

でも、頼まれたものを何でも作るわけではない。

作るより、やめる方が良いこともある。

引き受けるより、問題の構造そのものを変えた方が良いこともある。

だから、

「BizOpsって何でも屋ですか？」

と聞かれたら、今ならこう答えます。

何でもやります。
でも、何でも屋ではありません。

その境界線は、

「何を頼まれたか」ではなく、

「事業を前に進めるために、今何が必要か」から仕事を選んでいるかどうか。

私は、そこにあるのだと思っています。