【チーム組成編】なぜBizOpsチーム立ち上げたのか
今回から、数回に分けて、BizOpsチームの組成について書いていこうと思います。
私の周りを見ていると、たった一人でBizOpsという強大な 敵 大仕事に立ち向かっている方もたくさんいらっしゃるように思います。
ありがたいことに、私はBizOpsのチームを立ち上げるという機会に恵まれ、大規模なオペレーション/システム改善プロジェクトに取り組み、優秀チーム賞を受賞しチームとしての一定の評価も手にすることができました。
なかなか組織の中でその重要性が理解されづらいBizOpsという仕事で、どのようにしてチーム立ち上げにこぎつけたのか。
チーム組成に至った背景や、チーム組成に向けてのファーストステップを紹介していこうと思います。
チーム組成を決意するまでーカオスの中の1人SalesforceADMINー
自己紹介の記事で簡単に触れましたが、2社での社歴を経て、2014年にHR Tech企業の営業企画として入社しました。
主たる業務はSalesforceのシステム管理。いわゆる「1人ADMIN」というやつです。
入社したてかつビジネスの解像度もない中で、できることを探した結果、
権限が乱立していることが判明…
Salesforceの権限、整理しよう。
権限がありすぎると何でも各個人が出来てしまうため、同じようなデータが複数できたり、消してはいけないデータを削除してしまったりして、使っている側に混乱が生じます。
それは無駄な時間を生み出すことに。
さらに調査を進めていくと、恐ろしい実態が発覚…
Salesforceのシステム管理者、10人いる…
※当時Salesforceを利用していたユーザーは120名程度。
Salesforceに不慣れな人も設定変更・カスタマイズし放題。
例えるなら、1台のテレビに対して10人がリモコン持ってて、好きにチャンネル変え放題みたいなもんです。
権限を絞るための説明をするべく、
「営業企画の皆様には企画業務に集中してほしい。
企画の内容からSalesforceの変更が必要であれば、実装は私がやります。
協力していきましょう。そのために権限を整理します。」
と宣言。
権限を絞った反応は・・・?
営業企画チームが大喜び。Salesforceに詳しいわけでもないのに、権限があるからという理由であちらこちらからカスタマイズを頼まれ、その度に手を焼いていた営業企画チーム。
これで企画に集中できると、歓迎してくれました。
また、権限を集中したこともあり、「Salesforceならソガワさん」というラベリングに成功し、意図せずして現場の営業メンバーから相談がたくさん来るようになりました。
これにより、入社してすぐの段階にもかかわらず、戦術1つ1つの解像度が非常に高まり、事業課題を鮮明に把握することができるようになりました。
当時実際にもらった相談としては、
リードが増えてきたので、BtoBマーケ組織を作ることになった。獲得したリードをスムーズに営業プロセスに載せたいんだけどどうしたらいい?
戦術を実行に移るにあたり測定可能な状態にしたい。
顧客先のデータが重複しているので、どっちに電話したらいい?
見積もりや申込書をPDFで出力したい。
見たい指標が変わった。一覧化できる?
お客様がプロダクトを利用したタイミングでサポートをしたい。タイミングをつかむためにはどうしたらいい?
などなど…
加えて、テレアポの録音を聞いてトークスクリプトに対するお客様の反応を学習したり、営業同行をして実際に商談に参加し、受注/失注のプロセスを理解するなど、営業現場の実業務を理解するための取り組みを実施。
もっと泥臭い部分では営業部門の飲み会に積極的に参加したり(笑)
更に解像度を高めていきました。
見えてきた課題、このままでいいのか?
事業の全体像や、課題がよりはっきりと見えてくるにつれ、
「このままでいいのか?」
という疑問を抱くようになっていき、一度立ち止まって整理することにしました。
大前提として、事業が伸び続けている。これは何よりも素晴らしい。
法人のリード認知から、受注→契約→成果報酬を含む、請求に至るプロセスも理解した。
中の人たちは?
組織や人々の熱量が、士気が高い。
そして、無茶苦茶なほどに働いている。
なぜか?
各業務の量を追いかけている、質は見ているんだろうか?
予算、戦略立案や組織構成を考える際の、元データが合っているかどうか疑わしい…
組織や各人の落とし込むデータは合っているのだろうか?
転記をはじめ、無駄な作業もたくさんある。
組織の体制は?
ベンチャーということもあり、組織変更や人の異動や退職も激しい…施策がやり切れず放置されがち。
作った仕組みの利用率を見ていると、その時必要でも戦術が変わればシステムは使われなくなることが判明。
ということは、一見温度感が高く聞こえる内容や課題が、必ずしも本質的なものではない。
現在の自分の状況は?
打ち合わせの連続で、一面壁のように埋まったスケジュール。
正直パンクしている。
夕方までミーティングとその準備をして、夜一人作業。
そして翌朝からミーティング。
ミーティングの内容は悪くなく、自社で計画している戦略や戦術の経済合理性の実現は支援できている。
ように思える。
しかし実は、本質的に解決すべきではない課題の解決や、施策の実現に取り組んで疲弊しているんじゃないか?
PDCAは必要だが、必要性度外視でなんでも実現しようとし続けているような…意味あるのか?と思える内容もあった。
こんな一連の思考をぐるぐると巡らせた結果、まずはコミュニケーションを変えてみることにしました。
相談を受けたら、まずは情報を収集して自分なりの仮説を立て、
仮説を元に相談してくれた人に対して当ててみて、提案する
という流れです。
【BEFORE】
相談者:「見積もりや申込書をPDFで出力したいです。」
私:「今までどのような見積や申込書があったか教えてください。」
→システム化へ
【AFTER】
相談者:「見積もりや申込書をPDFで出力したいです。」
私:「どうしてですか?」
相談者:「スプレッドシートでひな型をコピーして見積書や申込書を作っているんですが、お客様の要望に合わせてカスタマイズされすぎてしまい、許容できない内容も含まれてたことがわかりました。
システムで統一化して出力できるようにしとけば安心だと思うんです。」
私:「なるほど。他にはありますか?」
相談者:「そうですね。あまり思い当たらないですね。」
私:「了解です。
現段階で備考欄などにお客様の要望が書けるようになっていると思います。
ざっと私が見た限りでもXX件はお客様の要望が書かれたものがありそうです。まずは、
・お客様要望を削っても、お客様は契約してくれるのか?(売上棄損にならないか?)
・許容しないって基準をちゃんと作り、営業部全体展開して、運用可能か?
を期限を区切って、一緒に考えて検証してみませんか?
なので、基準を作って、まずスプレッドシートをベースに運用。
その後大丈夫であれば、システム化しましょうか。」
上記はわかりやすい一例ですが、検証を挟むことで、
本当に必要な内容なのか?
相談者は本当に事業成長につながる仕組みを作りたいのか?
を確認できるコミュニケーションに変更しました。
ポイントとして心がけたのは、
無下に否定すると今後に影響もあるため、一旦は受け止める。
しかし、事業/営業戦略上の内容と合致しているかどうかも確認をする。
試行してみてもし違った場合は、再度話し合って自分の案を提示して議論する。
残念ながら、単なる思い付きで丸投げして、結果のみ自分の成果にしたいといった人も残念ながら一定数います。
自分のリソースを無駄にすることなく、事業/営業戦略にとっての最良を一緒に探すコミュニケーションに切り替えました。
その上で、
現場とBizOpsが協働して初めて動く施策も多い。
自分たちの意見だけでなく、現場の内容を理解しながら進める必要がある。しかしながら無駄も多い。どうすべきか?
という問答を繰り返した結果、たどり着いた結論は、
事業成長を支えるため、
顧客を中心に据えて業務プロセスを再定義し、
実行できるチームが必要だ
チーム組成は組織にとって妥当だろうか?
ー組成に動くための判断材料ー
これまで1人体制で行っていたことをチームにするとなれば、当然ヒトもカネも動くということであり、事業にとって、現場にとってのメリットを以て組織変更を申し出る必要があります。
チーム組成に動くにあたり、
チーム組成は組織にとって妥当、いや有意義な効果をもたらすものとなるだろうか?
という点を改めて整理しました。
事業戦略の視点から
YoYで30%以上の伸びを示し、トップラインが伸び続けている
毎月10名以上の入社があり、組織拡大及び細分化が進行
人数が増えれば増えるほど組織が増える=戦術数が増える
一方でスピードを落とすと競合との競り合いで勝てなくなる
会社全体でみるとビジネス側、コーポレート側のシステムを横断的に見る組織は存在しない(都度対応できる人がやっている)
顧客へのバリューチェーンは入金まである
分断すると顧客提供価値を棄損する
現場の視点から
複数の部署(エンタープライズチーム、SMBチーム・・)が様々な施策を同時並行で実行しており、熱気はある
一方で、コミュニケーションコスト度外視で同時多発的に発生する施策、増え続ける業務量により疲弊している
戦略は理解できるが、要素分解した戦術に疑問が残る
「 自分がリーダーとなった施策の成果を測定したい」など顧客のためになっていないものも多数
個人の視点から
就業時間がMTGで埋まり、就業時間後に作業が山積みの状態
意思決定プロセスに入り込めず、合理性のない戦略が決定事項として下りてくることに歯がゆさを感じている
「実装できる」ことに価値はなく、「事業成長に寄与する」ことに価値がある。今のままだと価値が発揮しきれてない
事業全体を俯瞰しても、現場視点で見ても、私個人で考えたとしても、事業戦略を考えつつ、社内システムを利用し現場のオペレーションの実行までできるチームの組成は、有意義な結果をもたらすと確信し、チーム組成に動き始めることにしました。
チーム組成の第一歩ー社内編ー
ベンチャーで働いていらっしゃる方々なら想像がつくかもしれませんが、レポートラインに相談せず、勝手に動いても文句は言われなかった当時。
「チームを作るなんて簡単だろう」
と余裕綽々に構えていましたが、
甘かった…
あれ?一緒にチームやってくれる人がいない
ビジネス部門のトップとエンジニアチームのトップに1on1をの時間をもらい、BizOpsチーム組成の重要性を説明。
快くOKをもらい、ビジネス部門、エンジニア部門それぞれの全体のMTGで、チームへの参画希望者を募りました。
どんなメンバーとチームを作り上げていくことになるのだろう・・・!
ワクワクしながら待つこと数日。
エンジニア部門・・・
応募ゼロ。
ビジネス部門・・・
応募2名、適正NG2名→対象者は0名・・・
前を向いて、原因探し。
応募者、対象者0名、まさかの結果は痛手ではありましたが、組織にとっても絶対に有意義なチーム組成。
ここで立ち止まるわけにはいきません。
まずは、応募がなかった/少なかった理由、適正候補者が現れなかった理由を探ることから始めました。
エンジニア部門の場合・・・応募がゼロだったのは?
興味はすごくあるし、ダイナミックで面白そう。
だけど特定のプラットフォーム(=Salesforce)に依存した施策の実行だとキャリア的に不安。
ビジネス部門の場合・・・適正なしの理由は?
「現場の数値プレッシャーから逃れたい」という後ろ向きな理由での応募
「未経験だけど自己成長につながる」「将来起業したいがITを理解しないといけない」「営業企画をやってみたい」という理由で応募をしておきながら、自社で使っているツールについて学んだり、聞いたりという成長のための行動をこれまで行っていない、行動が矛盾している。
人員募集に向けて、解決策を携え再始動。
明らかになった原因から、それぞれの部署に向けに解決策を用意し、地道なチームメンバー募集活動を再スタートしました。
エンジニア部門に向けて
自ら手を挙げてもらうために、BizOpsの仕事、キャリアの可能性について啓発活動を行う
ビジネス部門に向けて
社内での啓発活動は行わない。
基本的には社外からのダイレクトリクルーティングでの採用を狙う。
ただし社内からのキャリア相談に対しては真摯に対応し、行動を見極める。
→後にこの社内相談のルートからチームに加わったのが、マガジン執筆のメンバーでもあるマリモン。
マーケ、企画部門の方々にも募集はかけていましたが、そもそも自社内に少なすぎたため、社外からの採用にターゲットを絞ることにしました。
まだまだ続くよBizOpsチーム組成編・・・!
ここからいよいよ本格的にチーム組成に向けての動きが進みますが、今回はひとまずここまで。
エンジニアに向けての啓発活動や、ビジネス部門への真摯な対応などの具体的な内容は次回採用編で紹介します。
またチーム組成後、どのような軌跡をたどってチームが出来あがり、社内外から一定の評価を得られるようにまで成長していったのか。
チーム目標の立て方、浸透のさせ方からメンバー育成まで、少しずつ紹介していきます。
皆さんからの反響を励みに、次のステップ「採用実行編」を準備していきます!
是非とも記事やマガジンに「スキ!」「コメント」そしてTwitterの「いいね!」、「フォロー」をお願いします!
(10年の歴史が長くて濃くて・・・モチベーション維持して書き続けるの、けっこう大変です笑)
BizOpsチーム組成編記事
この記事が気に入ったらサポートをしてみませんか?