屍を越えて、チームビルディングに向き合う
全部で4回。組織をテーマに連載3本目。
エンプロイーオンボーディングについて2回に渡り、連載してきたCS*組織シリーズ。今回はチームビルディングについて、渾身のnoteをお送りします。
チームは2回死んでいる
2016年秋冬、Reproはカスタマーサクセスチームを立ち上げ、2017年から一気に顧客数を伸ばしてきました。その時のCSチームはグロースに耐えられるリソースが一切なく、目の前の課題を必死に解決していくことで精一杯でした。朝から深夜まで土日もなく全力で働きました。歩きながら寝たときにようやく「限界だ」と気づくくらいの視野の狭さで目の前のことだけに全力で向き合っていました。
それでも限界突破をし続けて働きました。ほぼサイヤ人感覚です。
1回目の死 - ボトルネックはCS -
定例のセールスミーティングで言われました。
CSO越後「このままだとCS、ボトルネックになるよ」
セールス伊藤「受注数コントロールしようか？質の担保ができないなら」
ズキズキ、、、、胃が、ギュン!ってなるような感覚。
気づいたらカスタマーサクセスチームは事業のボトルネックになりかけていた。いや、なっていました。質が下がっていました。
カスタマーサクセスチームが事業のボトルネックになることは是が非でも避けたかったことを覚えております。事業の成長にとって、一つのチームがボトルネックになることはよくあることですが、これはマネージャーの自分にとって職務放棄しているのと同じ状態と言えます。給料なんて、絶対もらえない。作り笑顔さえできない、そんな状況でした。
2回目の死 - 全員やめるよ？こんなチーム -
ついに、チーム内部からの崩壊が始まります。
2017年秋冬、継続的に事業がグロースしている状態。そんな時にReproのCSに入ったのが黒川と孫の2名。もちろん汎用的なドキュメントなんて何もない、業務過多と期待値過多、それをサイヤ人方針で乗り越える全力スタートアップ状態。
その日も、日付をまたぎ帰宅中。黒川からの電話。
黒川 「もう無理です」
佐々木「ん？何が？」
黒川 「もう持ちません」
佐々木「なるほど」
黒川 「こんなチームだと全員辞めますよ」
まぁ、わかる。全員が限界だった。
Aさん「クライアントファーストって言葉に逃げてませんか？」
佐々木「逃げてねぇよ。」
Bさん「成長ってなんですか？ただ働くだけで成長するワケではないですよ」
佐々木「わかってるけど、今はそんな余裕ない。」
この時、チームは死んでいました。
反省
当時、全てのタスクが後追いでした。課題の把握能力がチームになく、先回りしたタスクが何か定義することすらままならない状態でした。結果として、タスクの横槍、意味のない数字に惑わされた仕事、的を得ない指示が横行しておりました。
これは、全て短期的な視点、積み上げ思考（as-is）、メンバー同士の無関心がイシューとなっておきた問題だったと言えます。
また、チームマネジメントに経営陣が関与することが多かった当時。会社の成長スピードを考えるとよくないことなので、これもチームビルディングができてないが故の問題であると反省しました。
そして、4つのことを改善しようと決めました。
１、どんなに目の前に課題があろうと中長期の視点を維持すること
２、全てのモノゴトをtobeで捉えること
３、チームメンバー同士、全てを理解しようとするチャレンジをすること
４、ボードメンバーの関与を減らし、チームを自走させること
チームビルディングに本気で向き合う
まず、崩壊したチームを立て直すにはメンバー同士の相互理解しかないと考えました。
そこで半ば無理矢理、手段としてオフサイトを決行することに決めました。オフサイトのポイントは5点。
１、日常業務に意識が向かないよう休日を使うこと
２、思考を閉ざさないため非日常の空間で行うこと
３、立場や入社年数は無視すること
４、否定は絶対にせず、なんでも言える空気つくること
５、確実に次のアクションに繋げること
アジェンダは以下
AM 10:00 桜木町近くのコワーキング集合
AM 10:10 自己紹介 1人30分以上
PM13:00 ランチ
PM 14:00 課題の洗い出し
PM 15:00 課題の理解
PM 16:00 課題のカテゴライズとtodo化
この時に一番、大切にしたのは相互理解。
相互理解は思考のプロセスを合わせるための前提となります。
思考のプロセスを合わせることでチームのタスク処理速度あげる
なぜ、このチームのタスクは全然進まないのだろうか？
なぜ、このチームは仕事の質が低いのか？
そう思ったことがある人は多いと思います。
CSチームでは、チームのタスクが全然進まない原因の一つに思考のプロセスがブレていることがあると考えております。
数年前にIVSに参加した際、（おそらく）セプテーニ佐藤さんが「チームが同じ方向に進むには、思考のプロセスを合わせることが大事」的なことを言っていおりました。この言葉は自分にとって印象的で、思い返すと上手くチームが回っているときは、思考のプロセスがあっていたので感覚的にも納得感がありました。
例えば、以下のような会話があったとします
岩田「ここはAとBならAだよね！」
黒川「そうだね！」
この場合、お互いの頭の中には、判断に至るまでのロジックが存在しており大枠近く思考のプロセスを辿っているから結論はブレない。そんな感じです。
思考のプロセスが全く違うからこそ、結論や方向性がブレブレになる。
なら、まずは、思考のプロセスの整理。そのためにはお互い何を考えて生きているのか、どのような価値観を持っているのかを理解するのが早い。そう思って自己紹介（相互理解）に時間を割きました。
結果として、意見が異なる時になぜ他の人はこの意見なのかの推測が立てられるようになり、対立から会話にコミュニケーション質が変わりました。
補足：思考のプロセスがあってない状態での最悪のケースは、マネージャーが自分の価値観で否定することです。そうなると、建設的な議論がチームで出ることはなく、プロアクティブなチームにはなりづらいのです。マネージャーは全てYesって言っておけばいいとすら思ってます。一番現場を理解してないのはマネージメントより上のレイヤーの人たちなんですから。自戒の念を込めて。
チームパフォーマンスをあげる環境をつくる
新たなメンバーを迎え入れ相互に理解する文化を築かなければならない。それを怠ると、メンバーの心理的安全性が担保できず、最適なパフォーマンスを発揮できなくなります。 人間は心理的安全性が得られないとバリューは出せなのです。
そのため、エンプロイーオンボーディングはもちろん、3ヶ月に一度はオフサイトを継続的に続けております。
googleはチームのパフォーマンスに影響する心理的安全性を整理しております。
---
心理的安全性とは、対人関係においてリスクある行動を取ったときの結果に対する個人の認知の仕方、つまり、「無知、無能、ネガティブ、邪魔だと思われる可能性のある行動をしても、このチームなら大丈夫だ」と信じられるかどうかを意味します。心理的安全性の高いチームのメンバーは、他のメンバーに対してリスクを取ることに不安を感じていません。自分の過ちを認めたり、質問をしたり、新しいアイデアを披露したりしても、誰も自分を馬鹿にしたり罰したりしないと信じられる余地があります。
CSチームの場合、オフサイトでは何を言ってもOKなので、心理的安全性の確保をはじめ、マネージャーに対してやメンバー間のフィードバックも行われます。
また、チームの成長には、情報の透明性を高め、情報の流動性を高め、メンバーの流動性を高めることが最大化させると考えております。オフサイトはその手段としての位置付けもあります。
チームのパフォーマンスの高さと課題のレベルには相関がある
オフサイトで洗い出した課題をみてみると開催回数と共に課題が徐々に高度になっているのがわかります。
課題の変遷
▶︎１回目:横浜（メンバー4人）
- 課題のレベルが個人の域を出ない
- ミッションの不明確さ、KPIなど組織運営の課題は的を得ない
▶︎2回目:鎌倉（メンバー9人）
- 課題のレベルがチームの域に昇華
- 問題が顕在化されている状態
- 前向きな課題の増加
▶︎3回目:日吉（メンバー11人）
- 課題がチーム間連携にまで昇華
- 半年先を意識した課題が出るようになる
- 理想の状態を議論できるようになる
- CREチームの課題が顕在化しだす
▶︎4回目:箱根（メンバー15人）
- 課題は引き続きチーム間連携のレベル
- 業務範囲がプロダクトのPMFや業務フロー改善にまで広がった結果、課題がカオス
- チームが大きくなってくることによるマネジメントの課題が顕在化する
- PDCAのCの部分からくる課題が大半をしめる
- チーム内で解決できない課題が大半となる。課題の高度化。
第1回横浜：このときは課題のレベルがまだ低い
第2回鎌倉：新しいメンバーと相互理解を積極的に
第３回日吉：課題が多様化（付箋は課題の量）
第4回箱根：スケールと共に課題が増加。タスクフォースだけでこの量
3ヵ月毎のタスクフォースでチームの質とスピードをあげる
オフサイトの目的は課題を整理することだけでなく、そこからタスクフォース化するところをゴールとしてます。タスクフォースはKPTのTRY（トライ）をより具体化させるような手順で作成してます。トライから抽出されるタスクフォースは、先に洗い出した課題にも紐づいております。よって、課題の中身やそこからトライを作成したプロセスは全て会話することによって擦りあわされている状態となってます。
こういう状態が、一番タスクフォースが自分ごと化されやすいといえます。自分ごと化されたタスクフォースは、質が高くスピードが早い状態で解決に向けて推進されます。
この状態になっていないチームが前述した“なぜ、このチームのタスクは全然進まないのだろうか？”という疑問にぶつかります。
制約の中でチームを最大化させる
時間、リソース、お金、たくさんの制約があるが‘時間’が一番厄介な制約です。時間を制約の一つと考えるとやることは自ずと見えてきます。限られた時間で生み出せる付加価値を最大限高めるようにチームを運営して行かなければなりません。時間あたりの成果物をどこまで最大化できるかが重要です。
その成果物をどこまで最大化までのアプローチを、CSチームではタスクフォースの質とスピードの最大化と捉えてます。
事業のボトルネックになるチームはダサい
ザ・ゴールで有名なConstraints（制約条件）があります。制約条件とは「あるシステムが、ゴール達成のためより高い機能へレベルアップするのを妨げる因子」と定義されてます。
スタートアップはレベルアップするのを妨げるチームが生まれやすい環境といえます。チームビルディングに失敗し、生産性の低いチームとなることが往々にしてあります。
スタートアップの成長速度を担保するには、足の遅いボトルネックなチームをなくすことです。各チームが部分最適をし、生産性を上げていくことがとても重要と言えます。CSは特に経験者が少ない職種であるが故にチームビルディングしづらいと思います。それでもチームビルディングと本気で向き合わないと、いづれ事業の足を引っ張ることになるのです。
ReproのCSチームは順風満帆ではないですが、本気で向き合っている自信はあります。少しでもCSに携わっている方の参考になれば幸いです。
もっと死ぬ気で頑張ろう
もっとCSを楽しもう
次回は、採用について
by Head of CS / tsubasa sasaki