Chaosに立ち向かい、運用額2倍になっても大丈夫なチームを立ち上げた話
どうも、RettyのよしDです。
実は2020年の3月くらいに異動がありまして、広告コンテンツ部門というRettyの中でも割と新しい部門におります。(部門としては昨年末あたりに成立)
広告コンテンツ部門が何をやっている部門かを少し説明しますね。
Rettyでは大きく2つの事業があります。
一つは、飲食店さんに対して予約機能等を提供しているSaaSモデルの事業。
もう一つは、Rettyのメディアパワーを活かした広告掲載や、Food Data Platformと呼ばれるDBからクライアントにデータを提供することでソリューションを共に作り上げるなどの手段で売上を上げている事業です。
広告コンテンツ部門は後者を取り扱う部門です。
今回は、
・ようやく運用チームのベースができてきたこと
・実績として運用額が約2倍になっても問題なく回るチームになったこと
・チーム立ち上げはケースが多岐に渡るゆえ、意外とチームの立ち上げに関する事例、資料が転がってないこと
もあり、n=1のケースではありますがnote執筆に至りました。
似たような環境に立ち向かっている方々に少しでも参考になれば、また、少しでも再現性が高められればと思いますので、どうぞ気軽に読んでみてください。
広告を運用するための新チームを立ち上げ
さて、僕が広告コンテンツ部門にJoinして課されたミッションは「新たに運用チームを立ち上げること」でした。
実はRettyでは、広告事業自体の歴史は割と長いのですが、開発/運用/営業が一つの部門という形で売上を立てていくことは、昨年から始まりました。
当初は運用チームはなく、営業メンバーと開発メンバーが直接やり取りしながら運用をする形をとっていました。
しかし徐々に案件が増えたり、商品ラインナップが変わるに連れて、密なコミュニケーションや安定的な運用が難しくなってきたこともありました。
その結果、営業と開発を繋ぎながら案件を成功に導くために「運用チーム」の発足が決まったのです。
Chaosを知った → まずは交通整理だ
僕が入った時点で運用チームを含めた部門のリソースはざっくりこんな感じでした。
[広告コンテンツ部門]
└ 営業チーム × 7名
└ 運用チーム × 7名
└ 開発チーム × 6名
実態として、弊社の広告案件は大枠の商品はあるものの、クライアント毎にカスタマイズして提供するケースが多いです。
詳細までは言えませんが、そのような案件が最低でも5~6件、多いときはその2倍くらいは同時並行で運用されている状態でした。
これがどれくらいの規模感かをお伝えするのは難しいですが、個人的には当時のリソースと照らし合わせると、まあ回せない数では無いかなというのが当初の印象でした。
しかし、いざやってみるとなかなか効率的に回らないのです。
(運用)「この案件てどうなればクライアントは満足するっけ？」
(営業)「これの進捗どうなっている？」→ (運用)「やべ！」
(運用)「この商品のナレッジってどっかにまとまってる？」→ (運用)「〇〇さんの頭の中！」
(よしD)「ヤバい、これは巷で言われている"Chaos"というやつでは？www」
もともと僕はフローや仕組み、ドキュメントの整備が割と行き届いていた別部門に所属していました。
しかし今度は自らがそれを作っていく立場になることを改めて認識しましたw
そこで最初に立ち向かったのが「交通整理」だったのです。(ここから具体的な話に入っていきます。)
どの道を誰が通るか宣言し、"理想"について共通認識を持つ
ⅰ ) 運用チームの役割を可視化し、何をやるチームかを宣言する
僕がJoinした当初、様々なナレッジや情報が暗黙知の状態で回っていました。Chaosにはよくある現象だと思います。
いろんな情報があったなかで、どの情報から可視化していくか試行錯誤した末に、まずは「運用業務フロー」を可視化することから始めました。
ドキュメントの整備やタスクの可視化、コミュニケーションの可視化も検討されたのですが、これらが可視化されたとて、運用業務フローに共有認識が無い以上は、結局情報が氾濫してしまうので意味が無いと考えました。
例えるならば、車線が整備されていない広場に大量の車が放たれている状況で、地図を作れど、どんな車があるかを調査すれど渋滞/交通事故は解決されないと考え、まずは車線を引いて交通整備することから始めたイメージです。(最悪、渋滞は解決されなくても事故は減りそうですよね。)
ここで実際に可視化したフローの一例をご紹介します。
これを商品毎に作成しました。
また、整理したフローはもちろん、チームがどんな役割を担っているチームなのかを営業メンバー、開発メンバーらの部門の他のメンバーに対して宣言しました。
特に既存の体制の中で新しいチームを作るとなると、他のチームメンバーの理解があるとないとでは、その後チームがワークするかしないかのスピード感が大きく異なってくると感じています。
このように決して難しいことをやった訳ではありません。しかし、これによって商品ごとに「誰が何をいつまでにどうすれば良いか」について営業/運用/開発で共通認識を持つことができました。
その結果コミュニケーションコストが下がるとともに情報伝達の精度も上がりました。
戦略的属人化でスピード感を保ち現状を把握する
ⅱ) あえての属人化戦略
ⅰをやりつつ、次は複数ある商品やクライアントに関してどうコミュニケーションを取っていくか考えました。
当時の僕のチームの状況は、「商品は複数展開していて、案件は入ってくるけど運用する人が足りない…(というか一人に知識が属人化/暗黙知化している…)」というものでした。
さて"属人化"という言葉を耳にすると反射的に
(´；ω；｀)ｳｯ…
となる気持ち、すごいわかりますｗ
嫌ですよね…僕もですw
ただ、チームのフェーズや取り巻く環境によって"属人化"は良くも悪くもなります。
現状、弊部門では商品が大きく3つに分類され、それぞれに対して1人ずつ責任を持つことができるリソースが確保されていたこと、売上/案件数的に各メンバーで(ギリギリw)回せること、新たにjoinしたメンバーが複数人いたことを鑑みて、あえて商品毎の運用を属人化させることを意思決定しました。
これによって体制の切り替えコストは最小限にしながら、スピードを落とすことなく各案件の運用を進めることができました。
上記のような体制構築によって、営業メンバーが誰にどの商品について聞けば良いのかが明確になり、情報が錯綜することは目に見えて減少しました。
ⅲ) コミュニケーションのシステム化
ⅰとⅱが進むことで、どこにどんな情報が集まるかは共通認識を持つことができました。
次に出てくるのが各メンバーへの情報が氾濫するという課題です。
これに対しては、コミュニケーションルールを決めてやり取りの行き来を解消しました。
具体的には、「分析依頼はslackのワークフローで行う」「キックオフシートのテンプレ運用」等です。
どのコミュニケーションをシステム化していくかですが、重要な情報こそ取り組むべきだと感じています。
運用チーム・営業チームがそれぞれ必要な情報をすり合わせて漏れないようにシステム化していくことが必要です。
予想できる副作用に対しては対策を！
ⅳ) タスク量を定量的に可視化することでアラート体制の整備
一方で、運用する案件の売上額が2倍近くになるにつれて、属人化戦略を選んだ当初の予想通り、特定のメンバーのリソースが逼迫してしまう等の課題が発生してきました。
現場としてはすぐにでも「やばい！人を増やしてくれ！」と言いたいものですが、よほど資金が潤沢な(ヴィッセ◯神◯のような)組織でないと、そうもいかないものですw
なのでまずはこの状況に対して、チームのタスクの可視化を進めました。
そして、ただ可視化するだけでなく、定量的にアラートを上げられるようにスクラムを参考にタスク規模をpointで定義して運用をし始めました。
その結果、相対的ではあれど、チームリソースの状況をしっかり吸い上げてアラートを上げられる環境を整えることに注力しました。
このように、各週でどの商品に関してどれくらいチームのリソースを割いているかを可視化しました。(ちなみにクライアント軸でも同様のものを準備しました。)
この時期はチームとしても本当に辛く、特定のメンバーにはかなり負荷がかかってしまったのですが、なんとかチームメンバーでサポートしながら乗り越えました。しかし、それが美談で終わることの無いように、各メンバーで属人化を解消するタイミング/方針のすり合わせや、各週の消化point変動による部門へのアラート上げを実施しました。
それによって現在では、属人化解消に向けた部門全体の体制変更やそもそもの営業戦略の議論につなげることができました。
様々な課題が顕在化しつつも、半年間、地道にチーム作りをしていった結果、運用額が2倍近くになってもしっかりと運用が回るチームにすることができました。
再現性を高めるために
ここまでかなりシンプルにお話してきましたが、実は色々な改善施策が同時に走りながらも、なかなか上手くいかない時期もありました。
その中で、基本が如何に大事なのかを再確認させてもらいました。
issueの見極め、チームとしての振り返りの室の向上と習慣化、メンバーの声の吸い上げ(ファシリテーション能力)などなど…
今後同じような課題にぶち当たったときのためにも、ここからは、再現性を高められるように簡単ではありますが僕なりに抽象度を上げて考えていきたいと思います。
新チームの立ち上げなどに関わらず、様々な"Chaos"な現場があるとは思います。
そんな環境にぶち当たったときは、まず理想の状態から逆算して"何がどのように動くべきか"をステークホルダーの皆が共通認識を持てる形でアウトプットする必要があります。
ここで、表層の問題からアプローチしてしまうと結局チームの生産性が何も変わらないまま、チームの体力だけがすり減ってしまうと思います。
"Chaos"な状況で理想に目を向けるのは難しいかもしれませんが、まずはあるべき姿をみんなですり合わせて行きたいですね。そうすることで、個人だけでなく、チームとしてどこに本質的な課題があるか、声が上がってくるはずです。
そして次に必要なのが、チームに求められている役割と適切な体制を考え、変化することを前提に、柔軟な頭を持って実際に動かしてみる。
自分の中の通説と真逆のことすら、"Chaos"の中では最適な解決策かもしれません。
また予め副作用が考えられるときは、しっかり周囲を巻き込んだ意思決定ができるよう、判断材料を示せるような準備をしておく重要性を今回感じました。
さらに、チームにとって重要な情報の見極めとそこでの事故を防ぐ仕組み作りが重要だと考えます。何がどのように動くべきかが共通認識でき、物事が前に進み始めると、進み方自体は健全になるはずです。
一方で、やり取りが煩雑だったり抜け漏れが発生することは(人間なので)往々にしてあると思います。しかし防げるコミュニケーションミスほどもったいないことは無いです。
まずはチームにとって重要な情報が何かを判断し、運用できる範囲で仕組み化を進めていくことが有効だと考えます。
Chaosは楽しもう！いや、楽しむしかないんだ！w
日常的にChaosの中にいると、正直滅入ってしまうときもありますよねw
「本当にチーム、部門に貢献できているのだろうか？正しい方向に進んでいるのだろうか？」と。
しかし、真っ暗闇の中で少しでも確かな手応えを感じたときに得る幸福感はたまらないものがあります。(個人的にはw)
Chaosは楽しみましょう！いや、楽しむしかないのです！w
全てのChaosに立ち向かっている人たちに最大級のリスペクトを！
最後まで読んで頂いてありがとうございました！
この記事が気に入ったらサポートをしてみませんか？