PdMからCS Opsに異動してわかった、共通する「3つの逃げない」教訓と、それに向き合った実体験 #日めくりLayerX
こんにちは、LayerXの本間(@kazushiro_tcmc)です。
去年まではバクラクのプロダクトマネジメントをやっていたんですが、今年からCS Opsのマネージャーをしています。
最近、2歳の息子がGMOのテレビCMにハマっており、電車でGMOのつり革を見るたびに「じー！えむ！おーっ！」と大声で叫びます。CMのナレーションオファーお待ちしています。
さて、バクラク事業部のCS Opsマネジメントを任せていただいて3ヶ月経ちました。
CS Opsの活動を通じて、
「あぁ、以前プロダクトマネジメントで経験したことが今の組織でもめちゃくちゃ活きるじゃない」
と思うことが多く、この思いを皆さんに知ってもらいたいと思って記事にしました。
ちなみに、プロダクトマネジメント時代はこんな記事を書いたりしてました。
本noteの前提
こんな前提条件の元、このnoteを書いてます。
CS Opsに限らず、RevOps全般や一部BizOpsの領域にも学びがありそうなテーマだと思います
私の所属する「CS Opsグループ」は複数のRoleとミッションで構成されるチームですが、今回は「一般的なOps」の領域での話です
記載している中には、自信を持って「できてる」と言い切れるものも、「まだまだできていない」道半ばのものもあります
私たちについて
BSM領域を中心としたBtoB SaaSを提供する「バクラク」のカスタマーサクセス部内にある"CS Opsグループ"という組織です。
「CS部のポテンシャルを最大限発揮する」をチームミッションに掲げ、生産性・精度・意思決定の質の向上に努めてます。
具体的には以下3つをしています。一般的なRevOps ( Revenue Operations、レベニュー組織の持続的な収益成長を目指す役割 ) とかなり近しいです。
オペレーションマネジメント
「どれだけCS業務をバクラクにし、お客様に向き合う時間を増やすか」を実現するための業務設計と実現
RevTechマネジメント
CS活動で必要なCRM,コミュニケーションツールのAdminや施策管理、施策の効果最大化に向けた支援
データマネジメント
データを下に努力する方向性やフォーカスポイントを決めるためのBIツール ( ビジネス・インテリジェンス、KPIをモニタリングするダッシュボード的もの ) 構築やデータ分析
CS Opsとして活動をする中で「無意識のうちに〇〇から逃げちゃいがちだが、そこをグっと我慢することでCS Opsチームはより良くなるなー」って思ったことが3つありました。
そしてその3つはどれも、プロダクトマネジメントで学んだことでした。
プロダクト組織からOpsの組織に異動する人はそこまで多くない気がしてて、そんな経験をした私だからこそ伝えられるものがあるかなぁと思ってます。
その3つとは
「アウトカムから逃げない」
「あるべき未来から逃げない」
「"オペレーションもプロダクトである"事実から逃げない」です。
ひとつずつ見ていきます。
逃げないその1. アウトカムから逃げない
至極当たり前な話ですが、成果・効果から逃げちゃいかんって話です。
Ops組織はセールスやCSのようにフロントに立つ職種と比べると、どうしても成果が数値化しにくい。
「どれだけ業務時間を削減できたか」「自分たちが関わることで売上がどれくらい伸びたか」「お客様への提供価値をどう高める仕組みを作れたか」——
どれも大事だけど、測るのがなかなか難しいものです。
だからこそ、「特定の目的を達成するための改善やプロジェクトを完了させること」がGOALになりやすい。
本当は「成果が出たらDone」が理想なのに、計測の難しさから「作業が終わったらDone」となってしまうことが多い。
気づけば、タスクを片付けること自体が目的化してしまうんですよね。
実際その「作業をやりきった」はスタートであり、そこからの定着とアウトカムの発揮を目指さねばいけないのです。
業務改善であれば、変更周知し、運用サポートに入り、マニュアル整備しつつ関係者のヒアリングを繰り返して、より良い業務フローを再構築し、当初決めた目的達成にそっているか知恵を絞って計測しうんぬん…
その結果、当初の目的を達成できなければ、その施策/プロジェクトをやめるとか元の運用に戻す という意思決定も選択肢に持つ。
・・・
「あっこれプロダクトマネージャーで経験したやつだ！」進研ゼミの冊子よろしく、過去のプロダクトマネジメントでの経験とリンクするものがありました。
プロダクト開発も何かを作っただけじゃダメで、お客様に届け、利用いただき、効果を感じていただき、よりバクラクになってもらうまでがお仕事です。
で、僕らはどうやっているかというと、「なんのためにそれやるんだっけ？」というアウトカム種別をもとに施策やプロジェクトを管理し、完了の定義をあらかじめ決めた上で進捗管理してます。
つまり、「作業が終わったらDone」ではなく、「定義する状態になったらDone」。
そしてQの終わりには、"どれだけの数値効果をうめたのか"をある程度の根拠を元にまとめてます。
誰がどの課題に対して何した結果、どんな効果が得られたかをまとめている。
データマネジメントやダッシュボード構築も同じです。
「こういうデータが見えたら便利そうだな」と思うことは無限にあります。データを整備・可視化する立場としては、「切り口はいくらあってもいい」「BIのグラフも全条件を網羅したい」と考えがちです。
そして、貧乏性な私はその気がより強い。
でも、それではフォーカスが定まらず、結局誰の行動も変わらない。
大事なのは、「誰のどんな行動を変えたいのか」「その行動からどんなアウトカムを生み出したいのか」に合った、"今必要なデータ" に絞り、それを広く伝搬すること。最近、改めてそう感じます。
逃げないその2. あるべき未来から逃げない
Cs Opsチームには日々様々な依頼が来ます。CSに限らず"Ops"とつく組織は基本どこも同じだと思います。
不明点の確認・対応のヘルプ・業務改善の依頼などなど…幅広く、たくさん。
その依頼をマッハで対応することで、依頼者は喜んでくれるし、何かは必ず改善される。だって困っているから依頼がくるんだもの。
目の前に顕在化している課題解決も構造上同じで、短期的な小さい積上アウトカムはうまれます。
でも、今見えているものの積上による改善は長い目で見ると改善幅が少ないことがけっこうあったりします。
プロダクトマネージャー時代にこんなブログを書きました。
抽象度あげると結構近いことをいってました。
PdMというロールでプロダクトの機能優先度を決めたり、ロードマップを検討したりする中で、どうしても「プロダクトありき」で考えがちになります。定期的に立ち止まり「業務の本来あるべき姿」から考えて、それに近づくためのアプローチをしていく必要があります。それが経費精算システムの場合は、" 経費精算がなくなる世界 " だったりします。
よく「backcasting」と「forecasting」の違いが語られますが、大事なのはforecasting的な視点を持つことだなと感じます。
たとえば、「業務生産性を10%改善する」という依頼を受けて、寿命2年の業務改善に取り組むとします。でも、それをやるなら、倍の時間をかけてでも、その業務自体をなくすための改善をすべきです。
ひとつ実際の例え話をすると…
・・・
「商談で得たお客様の情報をSFAやCRMに記録する」——
営業ならよくある業務です。そこで、「入力しづらいから動線を改善したい」「誰かに代行してほしい」といった要望が出るのも、自然な流れ。
その要望をそのまま受け取って対応すれば、確かに問題は解決します。でも、本当に目指したいのはそこじゃなくて、「入力しなくても、必要な情報が勝手に記録される未来」なんですよね。
バクラク事業部では、商談動画の書き起こし→要約→重要項目の抽出→お礼メールの作成までを自動化する社内プロダクトを実装しています。
こういうことって、目の前の要望を一つずつ解決してるだけじゃ実現できない。「あるべき未来って何だっけ？」を考えてこそ、100倍のスピードで生産性を上げられるはず。
だからこそ、forecasting的な視点で未来を描いていきたいですね。
逃げないその3. 「オペレーションもプロダクトである」事実から逃げない
ひとつ、実際に社内であった小話です。
・・・
最近、とあるミーティングでこんな話題が挙がりました。
「バクラクの年次契約更新を行う際にお客様にアンケートを取れないか？」というアイデア提案です。
類似の取り組みをしている企業もあるし、「その声をうまく反映できれば、私たちもお客様もWin-Winになるかも！」という期待もあって"いいかもー"となりました。
ところが、話し合いが進むにつれて「アンケート項目はどう設定する？」「回答率を上げる手段は？」などのHowばかりに目が向いてしまい、「本当にお客様のためになっているだろうか？」という視点をつい見落としそうになってました。
アンケートは、ほんの少しの時間であろうと、お客様の貴重な時間をいただく行為。
お客様の大切な時間を奪っている以上、きちんとした意図やお客様にとって価値をお返しするロジックが必要です。
オペレーションのことばかり考えると、つい「データを貯めておけば、いつか役に立つかもしれない」みたいなログ設計みたいな考え方になりがち。
「将来に活きるデータかもしれない」というぼくら都合だけでなく、「今このアンケートに答えてもらうことで、お客様自身にどんな価値が提供できるのか？」を設計段階でしっかり考える――
それが「オペレーションもプロダクトの一部であり、お客様の体験を作るものである」の逃げない、につながっていきます。
では最終的に僕らはどうしたか。
「アンケートを基に、お客様がより便利に、より満足度高くサービスを使えるための提案に繋げる」仕組みを組み込みました。
アンケートを回答いただく前後の体験設計を中心に、「これならお客様の体験を損ねず、回答内容をもとにお客様へ価値を返せそうだ」と思えるような施策に仕上がりました。
ウォークスルー ( 特定のお客様になりきり、アンケート回答画面に遷移する所から本当っぽい回答をするまでのロールプレイ ) を何度もやりました。
回答項目に違和感がないか？忙しい時でも回答しやすいか？スマホでも回答しやすいか？表現による認識ずれないか？
細かな単語の選択や説明文の表現などもこだわって何度も修正しました。
いざ運用を始めてみると、「実は○○で困っていて…」「こんな機能があれば助かるのですが」というお声を、打ち合わせ前に把握することができるようになりました。
その結果、お打ち合わせに向けた準備を精度高く「お客様が本当に話したかった」ことにフォーカスして契約更新に関するお打ち合わせができるようになりました。
「プロダクト外で持つ全てのお客様との接点も含めてプロダクト」という前提を持ったうえで、その接点の構築がお客様のためになるのかを考える必要があるなと再考しました。
・・・
「オペレーションもプロダクトである」という抽象的な話ですが、意識しないままだと、私たちの都合ばかりを優先してしまう“内向きなOps組織”になっちゃいがちです。
お客様と直接やり取りしない部署であっても、そこが構築したダッシュボードや運用フロー、テンプレート構築などは、回り回って最終的にお客様へのサービス品質に影響を与えます。
ほんの些細な設定の不備や情報の遅れが、結果的にはお客様の負担になってしまうことも。
だからこそ、どんな業務であっても「これは本当にお客様の方向を向いているのか？」「この取り組みは、お客様の大切な時間や手間を奪うに値するだけの価値を生み出しているのか？」と問い続ける必要があります。
意識を変えるだけで、資料の作り方やメール文面の書き方が見直され、お客様にとってわかりやすい情報提供が可能になるかもしれません。オペレーションを“自分たちのため”から“お客様のため”へとシフトすることで、プロダクト全体の体験価値を高めるきっかけになると感じています。
最後に、とおまけ
このnoteはLayerX全社の「春の日めくりX（日めくりLayerX）」と言う企画の一環です。
共通テーマのひとつに「私のAI活用」というものがあり、最後のおまけ程度に触れると…
このブログはCursorというAIネイティブなエディタで書いてます。
右サイドバーに常にLLMとのチャットが立ち上がっており、テキストを書きつつChatでLLMに相談したりしてます。
Contextを渡すこともでき、今書いている文章をContextとして渡すことでその文章をもとに会話ができたりします。めっちゃ便利です。有償版であるPro版は会社経費で出してもらっています。ありがたやー。
さて、私のAI活用について触れたところで。私も所属するバクラク事業部カスタマーサクセス部は絶賛一緒に働くメンバーを募集中です。
youtrustでカジュアル面談も募集中です。
【Rev Ops】事業全体のデータ利活用や生産性向上について情報交換したい
！ | YOUTRUST 募集
youtrustのアカウントがない方は、こちらから登録不要で応募もできます。
【Rev Ops】事業全体のデータ利活用や生産性向上について情報交換したい！| LayerX Open Door
転職の意向がなかったとしても、生産性向上とかデータの利活用とか、そういうお話一緒にしましょう。LayerXのこと、バクラクのこと、キャリアのこと、色々お話できると思います！
「カジュアル面談しゃらくせい、応募するぜ！」というかた、是非一緒に働きましょう！求人一覧はこちらです！