マネージャーを民主化する！ビジネススクラム編
企業が断続的な成長するのに必要なことがあります。マーケットの不確実性と向きあうことです。仮説検証を通じて学習した内容をもとに、顧客にサービス提供するプロセスが必要不可欠になります。今回はサービスのグロースの専門とするUbie Customer Science(スケールチーム)の責任者としてどのようにチームを構築したのか、何が課題になったのかについてまとめました。
☑︎事業がひたすら右肩上がりを続けている
☑︎権限委譲ができておりマネージャーが自走している
☑︎仮説検証がまわってしかいない
☑︎組織拡大の必要がないので優秀なマネージャーが不要
上記で全てを満たした方は読む必要がないのでここで Command + W を推奨します。
##読んだら得られること
- 120%成長を継続させるセールスマネージャーを誕生させる方法!?
- 120%成長を継続させるサクセスマネージャーを誕生させる方法!?
- 120%成長を継続させるマーケティングマネージャーを誕生させる方法!?
- 120%成長を継続させる事業責任者を誕生させる方法!?
- 権限委譲が100%進んで暇な経営者を生む方法
前提
（※1-5フェーズが開発組織、5-10フェーズあたりからスケール組織が対応）
前提1
Ubieには、不確実な事象に取り組む開発チームUbie Discoveryと、開発された機能/事業を統合しスケールする組織のUbie Customer Scienceが存在します。
前提2
スケールチームでは、ビジネスプロセスを統合し、安定改善することが求められます。さらには1Quaterに複数の新しい機能が追加されます。
前提3
同時多発的に多くの機能を移管してスケールできる状態に、磨き込む必要があります。
前提4
私1人では統合/改善活動を同時に対応できません。中間層（マネージャーと言われる人々）の存在が必要不可欠でした。
前提5：今回はUbie Customer Scienceの代表として、どう組織を構築してきたのかについてお伝えします。
1.SaaSを安定的にグロースする上で遭遇した３つの課題
人に頼った改善、ノリと勢いで進める改善に限界を迎えました。しかし限界がきても開発は止まりません。ベンチャーにとってスピードが命だからです。プロダクト開発は破竹の勢いで進みます。組織拡大が進むなかで、徐々にひずみが生まれ始めていました。その中でも特に苦労したのが下記３点です。
課題1.管理職がバラバラに改善が進め、開発改善にグロースが間に合わない
改善/統合を同時多発的にすすめる中で優先度の高いものから着手できませんでした。複数のマネージャーが「改善する！改善する！改善する！」という気持ちから、それぞれが独自にくことで全体として空回りしていました。
メンバーが、同じような課題に着手していたことも起因しています。例えば 、「セールス部門でセグメントごとに動きを変えたらいいのではないか？」と検証をはじめていました。マーケでも同様にセグメントへの攻略アプローチを、クライアントの課題のフェーズによって変更する検証を行なっており、同じ課題を解決しにいくために同じような検証をスタート、組織として非効率な業務が発生していました。
同様のことがサクセスとセールスでも発生していました。サクセスに新規オペレーションが実装されると、連動してセールスのオペレーションも変わることになります。それによって同じ課題に２つの組織が改善策を別々にまわす状況が発生し、「意思の疎通ガッデム！」と心の中で思いました。
しかしながら上記は、構造上起きるべくしておきていたのです。解くべき課題を全員がシンクロしながら、リターンの大きいものから順番に全社員でとりくめたら最高ですよね。理想は理想に終わり、現実は厳しいものでした。
1人で全部を解決できるなら問題ありませんが、そうもいきません。私とシンクロしながら、統合と改善をすすめる必要があります。すなわちグロースができる人材を育成するマネージャーの重要性が大きくなってきたのです。型化せど、型化せど、次の開発がおちてくる。「またメトリクスが増えた。あとぼくがせめてもう1人いたらいいのに」何度思ったことでしょう。自信過剰すぎかもしれません笑
（※課題が発生した時の、実際の1週間の予定です。同時間帯に予定の被りがないだけましですねw 権限委譲が進まないと発生する悪い事例）
課題2.仮説検証を終えたはずなのに、なぜか解決していない
部下に、改善すべきポイントを絞って作業をまかせました。しかし検証がうまく回らずグロースのスピードが鈍化してしまいました。「適切な改善場所を渡すのに、なぜか成果がでない」、「与えられた場所で、MECEに課題は整理できているのに適切な課題からとりくむことができていない」
例えばサクセスの立ち上げ時には、ヘルススコアの設計をしていました。さまざまな指標を数値化するけれど、サクセス活動のオンボーディング成功と相関する指標が特定されない、おぼろげに指標化してもダッシュボードが適正なリードタイムと、メトリクスで管理できる状態にならない。
次から次へと課題が落ちてくる中で、メンバーが課題の整理ができなくなっていき、2人目の仕事をする自分、3人目の仕事をする自分、4人目の仕事をする自分がうまれ、課題整理から、さらにオペレーションやって、24時間稼働、精神と時の部屋にやってきましたよ、という状況に陥ります。何度か沖縄で1週間ぼけっとしたいと思ったことがありました。
課題3：特権階級による権利の支配：現場での気づきを拾えなくなり、改善のスピードがおちる
ビジネスプロセスを改善するために、必要な指標をデータ化。全体を可視化しながら、ボトルネックを特定し改善活動をしていました。自身で2事業部のサクセス、セールス、マーケティングとそれぞれのオペレーション改善責任を持つようになっていました。自ら現場にいける機会が減り、現場での気づきを施策に反映できず、あたまでっかちな改善になってしまっていたのです。改善の幅が減り、現場から上がってくる課題と私が認識する課題にずれが出始めました。
取り組む課題は、当初私が全部決めていました。その後改善のメトリクスが見える化され、意思決定のミスによる想定リスクが許容範囲を超えてから、VP of Sales, etc ....をおいてVPに権限を委譲しました。しかしながら1番顧客現場にいっているのはセールスです。
セールスが現場で実際にひろってきた課題こそが課題を解決するに1番近づける価値ある情報になります。しかし組織の拡大とともに、私がしていたのはダッシュボードと睨めっこ。ダッシュボードから見えていた課題と、現場から「~~が課題だと思います」という課題がずれはじめていたのです。結果、改善の幅も小さくなります。
どうやって現場から正しい課題を拾ってくることがうまくできるのかという壁にもぶち当たったのです。
上記で３つの課題をあげましたが、特に影響していたのは課題２でとりあげた完了の定義の甘さだと思っています。課題を適切なサイズにきることができれば、誰でも優先順位をつけることができるようになります。小さく課題を切る。そして検証して、リターンの大きいものから取り掛かる。これこそがエッセンスだと思います。
2.SaaSを安定growthさせる仕組み
Ubie Customer Scienceでは、プロセスを改善を圧倒的にできる人材の採用してきました。だが現実は甘くなかった。それだけでは、サービスを安定成長させることが難しかったのです。
上記３つの課題に対して下記の方法で乗り越える仕組みを設計しました。
仕組み１：課題を１つの看板で整理し取り組む優先順位を明確化
決められたプロセスをオペレーションエクセレンスの実現により改善するだけでも素晴らしい。「それだけじゃ、事業の右肩上がり成長は続かないんや！」そしてバラバラに課題にとりかかっていても適切な課題に取りかかれない。
したことはシンプルで下記の4ステップです
(※上記のようにカンバンに課題をリスト化して、優先度の高い順番に並び替えます)
1.適切な課題をみつける
2.優先順位正しく検証する
3.検証が適切にまわっているかチェックできる
4. 1に戻る
やっていたことを簡単にまとめると上記です。全てのメンバーがとりくむ課題を全て１つのカンバンで管理、優先順位の高い順番に並べ、1週間ごとにとりくむ課題をきめレビューを行う。上記4つのステップをくりかえす方式にしました。
ただ優先順位の齟齬もおきていたので、明確にするために下記を意識しました。
##優先順位を決めるポイント
1.課題を解決した時のリターン
2.課題を解決に必要な投資時間
3.課題の背景
を明確にしないとそれが課題なのか、どれを解決したら事業にとってインパクトがあるのかがわかりません。
仕組み２：課題の完了の定義を明確化させた
上記の仕組みを実現したものの、また課題にぶつかります。それぞれが効率よく課題にとりかかっているのに、課題が解決されません。それは課題の完了定義の認識が人によってずれていたことだと特定しました。課題への解像度が薄く、課題を大きくきってしまうことが多かったのです。そこで課題の完了条件まで定義するプロセスを入れました。さきほどの４ステップの2と3の間に下記の要件追加したプロセスに変更しました。
1.適切な課題を見つける
2.優先順位正しく検証する
3.課題の完了定義を入れる
4.検証が適切にまわっているかチェックできる
5.1に戻る
（※課題をクリックすると、上記のようにAC=Accepted Criteria＝完了条件をが記載されています）
完了を定義をすることで見えたことがあります。人によって課題の切り方にばらつきがあるということです。課題を解決できるサイズにブレイクダウンしないと課題を解決するアクションまでたどり着きません。課題を小さく切って、解決できるサイズに落としていくことで、毎週毎週課題が解決され、事業がスケールしていきました。
実際に起きた事例を１つとりあげます。サクセスにおけるオンボーディングの型化を依頼した時のおとです。発生しました。
##精査前
- ヘルススコアを設定して、サクセスがオンボを正常にできる状態を作る
##精査後：
- NPSを可視化して、オンボ成功率との相関関係を明確にする。
- 機能Xの活用率を可視化して、オンボ成功率との相関関係を明確にする
- etc...
ヘルススコアとオンボの相関関係がない中で、何の指標とオンボを相関させていくのか順番に検証しなければ見えてきません。課題を小さく切り、一つづつ検証していくしかありません。
仕組み３：誰もが現場の気づきから、とりくむ課題を見える化する仕組みを作った
適切なサイズの課題を作り、適切な順番で課題を解決していくことで、どんどん改善がまわりました。目に見えるように数値は改善されていきましたが、ある時改善のスピードがまた停滞しました。（※一生課題はでてきますね。いいことです）
私が医療機関との直接的な接点が少なく、インサイトが減っている自分自身が課題を拾っていたため、現地現物ではなく数値偏重の改善になってしまっていたのです
そこで顧客と出会う全てのメンバーが課題をあげれるような仕組みにしました。これまでは課題はマネージャー以上が選定した課題のみをを解決する流れでした。しかし、全てのメンバークラスが気づいた課題を、カンバンに追加できる権限を付与しました。課題定期を民主化したのです。メンバークラスもマネージャーと一緒に課題をカンバンに積むことを許容することで組織の雰囲気は変化します。
この仕組みは、効用が得に大きかったです。自ら課題を発見する力を鍛えることができる上記により当事者意識が上がる。自分が見えてない現場での具体的な歪みから課題を発見できる。
という習慣がメンバーに身につきました。決められたビジネスプロセスを解決するだけでも尊いですが、自ら課題を見つけてきて、ビジネスプロセスを更にUPDATEできるメンバーも尊いです。
適切な課題を発見することで当事者意識を養成するだけでなく、実際におきている課題を拾い続けることができるようになりました。
結果
下記が結果の振り返りとなりますが、最終的にはOKR（目標管理の手法）のすり合わせだけを行い、あとはマネージャーロールに任せれる状態になりました。改善までを回すことできるまで、マネージャーに任命せず、改善できるようになってからマネージャーにすることで強い組織にすることができました。
##課題と仕組みの振り返り
課題1：管理職がバラバラ改善、開発改善にグロースが間に合わない
仕組み1：課題を１つのカンバンで整理し取り組む優先順位を明確化
課題2：課題をとけども事業が進捗しない。完了の条件定義が甘い
仕組み2：課題の完了の定義を明確化させた（課題を小さくきってアクションできるサイズにする）
課題3：一部の特権階級が取り組むべき課題を支配していた
仕組み3：誰もが現場で気づいた課題をあげれるようにした
結果１：チームとしてのアウトプットが最大化された
チームで取り組むべき課題と優先順位がきまったため、同じようなタスクにとりかかる、リターンの低い課題にとりかかるといったことが減少し、チームとしてのアウトカムが最大化されました。自分がコミュニケーションとって確認しなくてもカンバンを見れば課題の妥当性を確認しコミュニケーションできるのです。
どれが優先順位高いとか議論が空中戦になりがちです。何を優先するのか、リターンのない課題がないからこそ、価値ある課題が何か共通認識をもって前にするめるようになったことは大きな果実でした。
結果２：検証可能な課題に落とし込むことができるようになった
解決できる課題の数が増えた。適切なサイズで検証できるようになったので、改善のスピードが加速的にあがりました。組織にとってわからなかったことが、ドンドンわかるようになりました。
課題を解決すれば、必ずリターンがうまれるようになりました。当たり前ですが、アクションに繋がらない行動を一生議論していても前に進みません。「〜〜が課題ですよね」一生議論している組織もありますが、どうすれば解決できるのか、アクションにつながる課題なのか？全メンバーの前提になることで、課題解決型の組織に変貌をとげることができました。意味のない議論が0になりました。
結果３：自走できるメンバーが増えた
どのメンバーも自ら現場から課題を発見しとりかかることができるような自走するメンバーが増えました。
与えられた課題にとりかかることは容易です、しかしながら課題をみつけて解決するプロセスを経験しているメンバーは世の中にいっぱいいるわけでありません。課題を自らあげるっていうのもなかなか大変なことなんですけど。このTIPSはまた別の記事でお伝えしましょう。
効果番外編1：マネジメントの難易度削減
メンバー全員の感じている課題が可視化されるので、マネジメントをしやすくなります。どこにメンバーが課題を感じているかもわかるようになり目線を合わせやすくなりました。
効果番外編2：7人のマネージャーが爆誕
全員が顧客から課題を拾い、課題のリターンとインベストを理解し、優先度順位高く、チームとしてのアウトプットを最大化できるようになりつつあります。
## Mgrのレベルアップ
Lv1. 優先順位を全体で並び替えることができる
Lv2. 課題を小さく区切ることができ、優先順位の妥当性の改善を可能にする
Lv3. 現場から課題をあげさせることができるようになる。
Lv4. メンバーが自発的に優先度について発言させるところまでできる
Lv5. 優先度を並び変えなくても勝手に課題解決が回っていてMgr不必要
このような流れでこれまでMgrがやってきたことをメンバーにもうまく浸透させていくことが可能になりました。セールスで3名、サクセスで2名。マーケティングで2名マネージャーの役割を果たすことができるメンバーが生まれました。マネージャーってなんでも自分でやりがちだけど、チームとしての生産性が最大化されればいいので、マネージャーの「俺がやったど、どや！」っていらないんですよね。
最終的に私が各チームと行うのは、課題解決のたまを決めるミーティングで、一部のメンバーだけで運営がされていないかチェックするだけです。課題は解決されるので、メンバー全員への実装をサポートするだけになってきました。
最後に
組織を拡大していく上で必要なのは、数値と向き合い改善することではありません。まだ開拓されていない不確実なマーケットと向き合い、真の課題を拾って改善し続けることが必要です。1人じゃできない。初めから誰もが解決が適切にできたわけでもない。だからこそマネージャー、メンバーと一緒に失敗をしながら学習するマインドが必要でした。
この仕組みを通じて組織で学習をしながら、改善をするメンバーを増やすことができました。これっていわゆるスクラムやん。ビジネススクラムで運用しているって状態になっていました。「スクラムしか勝たん！」
課題解決を通じて、世の中に新しい価値を生み出したいと思えたら、ぜひ気軽に連絡ください。
少しでも役にたったと思えたらシェアしていただけると嬉しいです。シェア100超えたら「ビジネススクラム実践編」も書いてみたいと思います。
P.S
業務委託でサポートも実施しております。無料の相談は上記からください！
この記事が気に入ったらサポートをしてみませんか？