強いオペレーション部門(CS Ops.)を作るために意識したいこと

Leanerにて、カスタマーサクセス(CS)、オペレーション(Ops.)部門を担当している小野といいます。

Leanerという会社では、現在社内の見積業務をDXするプロダクトを開発・提供する、いわゆるSaaS事業を展開しております。

s

この記事をなぜ書いたか？

会社は創業してから2年半と若く、メンバーも拡大中の組織ではありますが、Ops.部門はその中でも在籍人数の大きい部門となっています。

現フェーズにおいて、顧客へ価値提供をする点でも、プロダクト開発を進めていく上でも重要な位置付けを担っている部門になってきているかと思っています。

しかし部門を立ち上げ当初は、都度問題ごとに必要な役割をなんとか推進したり、必要な人員を集めたりと、かなり場当たり的に邁進しておりました。

その当時を振り返ると、SaaS全体のプロセスを描いたTHE MODELや、CS・インサイドセールスなど新たな職種についての書籍や情報は出始めているものの、(CS)Ops.・テクニカルサポートなど、裏方的な運用面を担う部門の情報がものすごく少ない、、、と感じておりました。

そこで、Ops.部門を作る際や、現状運用代行のみを担うような部門がより価値を発揮するために、当時の自分が参考になるような

・現部門はどんな経緯で生まれ、何をやっているのか？
・部門を作るにあたり何を意識したか？
・現在、今後組織においてどのような役割を担っていくのか？

あたりを書いていこうと思っています。

(CS)Ops.とはどのような部門か？

SaaS事業をやっている会社だと、最近ではよくある部門ではあるのですが、その内実は、何をやる部門なのか一言でいうには難しく、会社によってどの業務を担当しているか異なっているように感じています。

一般的には、Ops.部門はCS配下として置かれ、顧客へ継続的な価値を提供するためのサポート業務や、CS企画推進、それに伴うデータ収集・分析などを行っていることが多そうです。

その辺りは、具体としてはSaaSの先輩として各所参考にさせてもらっているSmart HRにてCS Ops.を担当されてる@hasedaさんの記事がわかりやすかったです。

Ops.部門を立ち上げた経緯

Leanerは、当初顧客から展開いただいた膨大な経理データを元に、解析・分析をした結果から価値を生み出していました。

創業間もない時期から、ありがたいことに一部上場企業のような大手のお客様にご支援する機会をいただいておりましたので、当然いただくデータの量も比例して膨大な数が存在しており、その処理を行うだけで、かなりの時間を要していました。

(代表やCOOがエクセルマクロを組んで、10数時間処理をかける専用のPCが存在していたり、テックリードの安齋が夜な夜なプログラムを実行してデータ統合をしたりという暗黒の時代がありました)

当然このままでは、顧客開拓やプロダクト開発など本来集中しなければいけない領域に割く時間を圧迫する事になる

という想いから、段階的に切り出せる運用業務の部分から、まずは派遣社員の方を雇ってご依頼するという形から始めたのがオペレーション部門立ち上げのきっかけになります

現在の体制・実行している業務

そんな闇の状態を救うために、立ち上がった部門も、現在では以下のような体制で業務を行なっています。

・意思決定者：方針やトレードオフの判断などを行う
・管理者：方針や判断を受け、実行者が迷わず運用ができるためのドキュメント作成や、タスク管理の仕組みを作る
・実行者：様々な業務分岐を理解し、方針の則って実行する。

その中で推進している業務は、現在ではかなり多岐にわたっていて、

・データ集計処理
・BI用ファイル、ダッシュボード作成
・企業データベース用リサーチ
・顧客問い合わせへのテクニカルサポート
・プロダクトデータ分析、レポート作成

など、広義のプロダクトとして汎用的に提供していくべきものの中で、自動化が難しい領域についてを型化して実行しております。

強いOps.組織を作るにあたって意識していたこと

どれも初めから意識をしていたというわけではなく、業務を推進し、メンバーとコミュニケーションを取っていく中で生まれてきたルールや、指針が多いです。
いくつかありますが、その中の4つを紹介します。

1. 誰でもできる管理体制を整える

これはある程度どの会社でも意識していることかもしれません。

ただこれは、実行している運用手順のドキュメントを残すということや、管理シートをスプレッドシートで作ろうということだけを指しているわけではありません。

Leanerでは定期的に別行程を推進しているメンバーの業務をインプット・実際の運用作業を交代で行うことを定期的に実行しています。

業務が属人化されていないことによって、急遽の依頼にて特定業務に集中して対応しないといけないシーンや、メンバーの病欠やシフト変更による業務の滞りが発生しない体制を作ることができます。

<手順ドキュメントや管理シートを軽視しているわけではなく、実際Leanerでもめちゃくちゃ作り込んで推進しています>

2. シンプルなルールを設ける

行う運用の全てが手順通りに推進できるに越したことはないですが、イレギュラーというものは起こります。

その際に、誤った対応をしてしまうのを避けるために多くの会社では、対応の時間がかかってもエスカレーション(上司に相談)をせよ、というルールが一般的に思います。

一方、イレギュラーケースは往々にして顧客が緊急で対応を求めていることなど、一定のスピードを持って対応する必要もあります。そこでLeanerでは、通常オペレーション外のことが起きた時の指針としていくつかのシンプルルールを定めています。

・問われていることは、リソース(時間・お金・工数)が必要なものか？(noであれば、顧客のプラスになる行動をしてOK)

は、個人的に気に入っていて、これのおかげで細かな相談なしに顧客のためにプラスの行動をメンバーが行なってくれているように感じます。

3. なぜその業務が必要かの背景を伝える

Ops.部門は、業務の特性上クリエイティブよりも運用的な業務が多く、また顧客と直接対峙せず、過程を担う傾向があると思います。

すると、先の見えない業務からモチベーションを保ちにくかったり、黙々と任されたことを実行するに止まりプラスアルファが産まれにくかったりするように思います。

そこで、
・なぜ、その業務が必要なのか、そのような意思決定がなされたのか
・実行いただいている業務の結果、誰がどう嬉しいのか
・今後どういう戦略の元、現在の運用はどう変わっていくのか

ということを、現場のメンバーにしっかりと背景に渡って伝えることが重要だと考えています。
特に、非正規雇用が多く構成される部門だからこそ、ここまで徹底することで、雇用形態という本来気にする意味のない垣根を壊し、自走的に推進するメンバー組織を作り上げられると思っています。

Leaner Ops.の今後

強いOps.組織、と言って始めたもののまだまだ組織もプロダクトも成長過程にあります。

その中で、現状はまだまだ守り(やらなければいけない、運用業務)をいかに効率よく、スケールさせていくかということに注力している状況だと思っています。

そこからさらに攻め(新たな機能やプロダクト開発のためのサポート)に価値を発揮するような、攻めたOps.組織にも進化できるように邁進したいと思っています。

終わりに

最後に、何も情報がない、、！と思っていた当時の自分のためにと思い書き始めていましたので、
他の会社のOps.をもっと知りたい、情報交換したい！と思っています。

気軽にお話しさせてくれたら嬉しいです！

Twitter: https://twitter.com/kouya_relas22