こんにちは。株式会社LayerXの鈴木（@suuu）と申します。

圧倒的に使いやすいプロダクトでわくわくする働き方を届けるバクラク事業部にて、「BizOps」という組織が2022年10月に立ち上がり7ヶ月ほどが経過しました。

当記事ではBizOpsという組織を運営する中で感じた変化や課題、そして未来に向けて実現していきたいことについて書いていこうと思います。

LayerXでのBizOps立ち上げの背景については以下記事やスライドをご覧いただけますと幸いです。

LayerXのBizOpsについて

ミッション

バクラクはおかげさまで多くのお客様からのご支持のもと、事業に関わるプロダクト、プロセス、組織すべてが日々"バクソク"で成長しており、この成長速度はLayerXにおいての大きな事業優位性であると感じます。この事業成長速度は落としたくないですし、むしろ加速させていきたい。
しかし、我々が本当に届けたいのはプロダクトをご利用いただいているお客様の業務が"バクラク"になるという体験であり、この体験を毀損してまで事業成長を追い求めることだけは絶対にしたくありません。

この「事業成長」と「顧客体験」とをどちらも高い水準で保ち続けるのは非常に困難が伴いますし、この両者は意思決定の際のトレードオフになりやすいものだと思います。

BizOpsとしてはこの「事業成長」と「顧客体験」を両立できるインフラを作り上げ、事業部メンバー全員がお客様に向き合い続けることだけに集中できる環境を提供し続けたいという願いのもと、その実現において必要なことは役割や手段に囚われず何でもやっていく気概で活動しています。

業務範囲

BizOpsの業務範囲を抽象化すると、「業務プロセス」「システム」「データ」「情報セキュリティガバナンス」の４つのカテゴリに分解できます。

各カテゴリにおけるBizOpsとしての業務内容や関与度合いの変化はあれど、概念としてのBizOpsの業務範囲は組織立ち上げ当初から変わっていません。
（このカテゴリ毎の詳細については冒頭で紹介したnoteをご覧ください。）

事業全体を俯瞰した視点で捉え、各種プロセスのボトルネックを見つけ、自らがオーナーシップを持って改善に取り組むことができることがBizOpsの醍醐味だと思います。

立ち上げ時から”変化したこと”

プロセスオーナーの巻取りと改善

事業には大小様々な業務プロセスが存在しておりますが、スタートアップあるあるとして以下のような問題が発生します。

• 少人数であるがゆえに特定の人に業務が依存してしまい、業務量がスパイクした際の負荷集中による長時間労働と生産性低下が起きる

• プロセスオーナーが曖昧でそもそもプロセス改善に着手されない

こうした状況を打破するため、「特定の人に依存」していたり、「オーナーが曖昧」であったり、「本来そのチームでやらなくてもいい」ような業務プロセスに対し、BizOpsがプロセスオーナーとなる形で業務自体を巻取り、改善し、さらに複数名体制で遂行できる状態へと作り上げてきました。

以下はBizOpsがプロセスオーナーとして巻き取った業務の一例です。

• バクラクのお客様環境作成およびマスタセットアップ対応

• バクラクの契約更新（リニューアル）にまつわる定型連絡や事務手続き

• IT導入補助金にまつわるお客様および事務局対応

• お客様いただく個別セキュリティチェックシート対応

• スキャン代行事業の実務オペレーション

BizOpsがプロセスオーナーとして巻き取ることにより、多少業務量がスパイクしても安定したアウトプットが出せるようになっただけでなく、業務の型化とシステム化も同時に進めることで業務ミス発生件数が低下するといった品質向上にもつながっています。

さらにプロセスオーナーが明確になることで「この業務はなぜやってるんだっけ？」と立ち返ることが可能となり、不要な業務はそもそも辞める意思決定も可能となります。
単に業務を巻き取って改善するだけであればBPOを得意とする企業様におまかせするのと大きく代わりはありませんが、「業務自体を無くす」「根本的にプロセスを変える」といった意思決定は事業内部に存在する組織であるからこそ実現できることであり、今後よりBizOpsとして価値を発揮していきたい領域でもあります。

現場組織の生産性に直結するオペレーションとシステムの改善

「プロセスオーナーシップ巻取り」だけでなく、お客様と日々接点を持つ現場部門の生産性改善に向けたオペレーション・システムの改善にも取り組みました。

以下はBizOpsメンバーが取り組んだ現場組織の改善内容の一例です。

• Saleforceによるプロセス改善

  • バクラクカードの商談・ご利用状況管理

  • パートナーチームの代理店商談・ご利用状況・支払管理

• SalesチームにコミットしたPipeline Management、Deal Managementの実践と展開

• プロダクト上でのお客様接点となるKARTEのシナリオやターゲティングデータ連携の設計・実装

• Data Enablingチームと連携したデータ分析環境のアップデート

現場のプロセス変革は関わる人数や関連するシステムが非常に多く、着手してから成果が出始めるまでに一定の労力と時間を要しますし、改善による成果の振れ幅はプロジェクトを率いる人の経験値によって左右される部分も大きいです。

BizOpsにはセールス、カスタマーサクセス、Salesforce Admin、データアナリストなど、様々なバックグラウンドを持ったメンバーが集結しており、それぞれが得意とする領域をベースに現場に入り込んで改善を推進しています。

また今後はBizOpsという横断組織からの現場改善だけでなく、現場組織にOps改善を推進するロールを根付かせ、より深いドメイン知識とスピード感を持って改善推進できる体制を構築していきたいと考えています。

BizOpsのチーム細分化

BizOps立ち上げ当初は4名でスタートしましたが、7ヶ月経過した現在では正社員/インターン/パートナーの方々含め総勢10名の組織になりました。

4名であればフラットな組織であっても特段問題はありませんが、10名規模になってフラット組織のままだと、意思決定ラインが不明瞭になる、採用要件が曖昧になるなどの不都合が発生します。

より専門性を高め、よりスケーラブルな組織とするため、2023年4月からBizOpsをチーム制にし、各チームの期待役割およびリーダーを明確化しました。
チーム制にして1ヶ月ほど経過しましたが、やるべきことがフォーカスされたことにより、業務改善の質・量・速度が体感的に向上していると感じます。

チーム制にしたことで組織が縦割りになってしまい、チーム間での情報共有や支援関係が薄くなることだけは防ぎたい。
そのため各チームが遂行しているイシューを週次定例で共有したり、各メンバー毎の相互理解促進のため「一緒に仕事をする上で知っておいてほしいこと」を共有する等の取り組みを行っています。

立ち上げ時から”変わらないこと”

イシュー収集・優先度決定・調整のプロセス

BizOpsとして取り組むべきイシューを集め、対応優先度を決め、優先度自体を適宜修正する。このプロセスは細かいアップデートはあれど、進め方や管理方法は立ち上げ当初から大きく変えておりません。

特に重要なのが「イシュー収集」で、このフェーズが不十分だと本来もっと成果が出せるはずの改善ポイントを見逃すこととなってしまいます。（事業部長のmakiさんが以前ツイートされてたものを拝借）

ゆえにイシューを見逃さないためにBizOpsメンバー自身が現場組織の状況変化を感度高く把握することに加え、現場組織から自組織が抱えている問題について気軽に相談してもらえる関係性を日頃から作り上げておくことも重要です。

イシュー管理の仕組みも当時作成したNotion DBによる管理手法をそのまま利用し続けています。
現在対応中のイシューはロードマップ化してオーナー/納期/状況が一覧でパッとわかる状態にしておき、滞留要因特定とネクストアクション設定を定期的に確認しています。

また差し込みで重要な案件が発生した場合もロードマップ上の案件優先度を落としてリソース配分を調整するなど、比較的柔軟な運用をしています。

BizOpsのこれから

直近1年で解決すべき課題

BizOps立ち上げから7ヶ月間で様々な改善に着手し、一定の成果を出せてきた実感はありますが、バクラク事業が目指す未来像に対してBizOpsが実現しなければならないことは本当に山積みの状況です。

直近1年間で解決したいと考えている課題に一例を記載します。

• （特に事業優先度の高い領域での）プロセスオーナーシップ巻取りと改善

• CPQ（Configure Price Quote）、契約管理のシステム刷新

• 組織横断プロジェクトを推進できるプロジェクトマネージャーの採用・育成

CPQシステムは料金プラン設計/支払手段/請求オペレーションに影響を及ぼす重要なコンポーネントです。バクラクは半年に一つのペースで新しいプロダクトが生まれている状況で、プライシング検討機会が高頻度で発生しますが、システムがボトルネックであるべきプライシングが設計できないという状況が発生することもありえます。そうした状況を引き起こさないためにもCPQおよび契約管理におけるシステム刷新を早急に遂行していく必要があります。

またBizOpsは複数部門にまたがったプロセスやシステムの改善に取り組むため、プロジェクトの推進にあたってはQCD設定・リソース調整・スケジュール管理・ステークホルダーコミュニケーションといったプロジェクトマネジメントスキルを保有し、さらに関連業務に対する一定以上の理解のあるメンバーをアサインしなければなりません。こうしたメンバーは社内でも貴重な人材であり、特定メンバーにプロジェクトオーナーが集中してしまいがちです。
今後も組織横断プロジェクトが複数立ち上がっていくことが確実な中、プロジェクト推進にオーナーシップを発揮できる人物を採用および育成できる環境を生み出すことは急務です。

個人的にやってきたいこと

BizOpsのような「xOps」と名の付く組織は、米国では一定の認知や役割定義の整備が進んでいるようですが、日本国内ではまだまだ未成熟な領域です。
社外のOps組織に所属する方々とお話させてもらっていても、各社手探りな状態で運営されているのが実態のようです。

事業拡大フェーズにおいて、もはやOps組織は必須のロールであり、特にLayerXは新規事業・新プロダクトが数ヶ月単位で生み出される事業体でもあることからOps組織のニーズは衰えることはしばらく無いでしょう。

こうした背景もあり、私個人として以下のような取り組みをやっていきたい野望があります。

1. Ops組織を再現性を持って立ち上げ・運営可能な"型"の発明

2. Ops組織をリードする人材の採用・育成・抜擢

1は、BizOpsだけでなく現場組織のOpsも含めた"型"を発明し、Ops文化をより定着させていきたいと考えています。各組織の期待役割や状況によってOpsに求められることは異なるはずですが、ある程度の型は作れるのでは？という感覚もあります。これを感覚で留めず言語化して実践し、確信を持てる形へと昇華させたいと思っています。

2は、特に「育成・抜擢」にフォーカスしたいと考えています。国内にOps組織が存在する企業が多くない中、さらにOps組織を率いたことのある経験者を「採用」することは中々に困難であると言えるでしょう。
よってOps組織自体を率いる人材を組織内部から育成、抜擢する環境を生み出すことにチャレンジしたい。これは1の「組織の再現性のある型」とセットで取り組むことで、人材育成自体も再現性のある型に落とし込みたいと考えています。

さいごに

BizOpsチームでは一緒にお客様提供価値向上に取り組んでくださる方を募集しております。
少しでも興味が湧いてくれた方は以下どちらからでも構いませんのでカジュアル面談のお申し込みください！

LayerXでは各種Ops系のポジションを積極的に採用しております！
ご経験やキャリア志向性に合ったポジションを受けられる「Opsオープンポジション」もありますのでぜひこちらもご覧ください。

• Salesforce Administrator

• CS Ops

• HR Ops

• x-Opsオープンポジション