
私をマネージャーとして育ててくれた失敗達
はじめに。このnoteについて
個人的な話なのですが、この度、14年務めたサイバーエージェントを退職する事になりました。在職中、いろんな部署を経験したのですが、リーダー/マネージャーとして約10年を費やしたことになります。
いずれもサイバーエージェントグループ内ですが、SEO会社、オペレーション会社、メディア部門でエンジニア、プロダクト、スタッフ、セールスといった範囲をマネジメントしてきました。
2-3年のMGR経験でホップ、ステップ、ジャンプ!で出世していってしまうスターとは違い、私はどちらかというとたくさんの失敗をするタイプのマネージャーでした。
ピープルで、組織で、採用で、プロダクトで、業績で、踏んでない罠は無いのではないかと思うほど数多くの失敗をし、そういう出来の悪いマネージャーを辛抱強く見守り、育ててくれたサイバーエージェントには本当に感謝しています。
そして、失敗の度に内省し、次の糧にし、実際に同じ失敗をしないというスタイルで私は成長してきました(ついでに言うとキャリアの後半では先行している部署や人に失敗談を聞き、その失敗を「先に内省する」事で同じ失敗をしないという技も身につけました)。
このnoteでは、私のマネジメント観に大きな影響を与えた出来事とそこから得た学びをまとめています。
このnoteでは、以下の学びが書いてあります。
1.なんでなんで攻撃を越えて学んだ事
2.部署がなくなった事から学んだ事
3.CTOの退職から学んだ事
4.サプライズ退職から学んだ事
5.星取り表を元にした戦略の失敗から学んだ事
なんでなんで攻撃を越えて学んだ事
・どういう失敗をしたか
これは、私が初めてリーダーとして人を預かった時の話です。私が4年目でメンバーが2年目という、そういうくらいの時代です。
目標達成はおろか、決めた行動すらちゃんと遂行しないメンバーを私は毎朝毎朝怒りました。
「なんでやんないの?」「昨日はこれやるって言ってたじゃん!」「今日までにできるって言ってたじゃん!」「なんで?なんで?」
決めた行動の可否や目標進捗を怒られてるはずが、言い方や一挙手一投足まで怒られるようになって結局そのメンバーは萎縮してしまい「一体何をやれば良いんですか」という状態になってしまいました。
億劫になって私に適当な報告を上げるようになり、適当さを知った私は更に彼を追いかけ、という悲惨なループです。
担当するようになって3ヶ月くらいで、結局当時の上長に「なんでなんで攻撃やめて。お前が朝からキレまくってると雰囲気最悪になるんだけど」という苦言を呈されるまでになってしまいました。
・どうやって失敗を克服したか
私が自分の行動を鑑みるきっかけになったのは「雰囲気が最悪になる」という当時の上長の言葉でした。正しい事を言ってるのは僕の方だしおかしくなくない?!
そこで周りに「俺悪くないよね」と尋ねてみて、自分が犯している間違いに気が付きました。僕の近くに座っていた女性社員に聞いた時の感想です。
「まぁ、あんなにガンガン怒られてる人がいて雰囲気が良いわけがないですよねー。でも、小越さん、一体何にあんなに怒ってるんですか?」
・・・当時は正直な同僚に恵まれました。
・何を学んだか
私はハッとしました。そして気づいたのですが実のところ「なんでなんで」と私が怒っていたのは、俺の言うことを聞け!という感情からだったのです。
本来、マネジメントは組織成果を達成するのが最大の目的なので、リーダーが指示してメンバーが実行する、という形式に拘らなくたって良いのです。
メンバーが走れさえするならば、議論をして決めるスタイルでも良いし、この範囲で自由にやっていいけど報告だけして、まずいやつは止めるから。というスタイルでも良いわけです。
その時、特に引き出しが無い私はとりあえず言われたとおりに「なんでなんで」と怒るのをやめてみたんですが、結局、物事はそれでうまく進むようになりました。
この経験から私は以下の事を学びました
1)目的を達成できるならばひとつの形に拘らない。
今回のケースでいえば、他の人を通じてヒアリングしても良かったし、
そもそも意味ない朝会(お互い思ったように仕事が進んでないんだから)
なんてなくして良かった。
今の私が当時の私にアドバイスするならば「そもそも怒りまくっても成果出てないんだから、有効じゃないからやめなよ。別の方法試すか、やってみせてみれば?」などと言うと思います。
2)そもそも、判断基準を作る
後々「Value」などに消化されていくこの考え方も、重要だと気づくようになりました。「自分はこういう判断軸で考えているよ」というものを公開し、実際そのとおり判断することでメンバーとのコミュニケーションはよりスムーズになりました(例え怒っていたとしても、意味が通じる)。
部署がなくなった事から学んだ事
・どういう失敗をしたか
これも私が4-5年目の時の部署なのですが、当時の私はスタッフ部門で、役割が多様な部署を任されていました。言い換えると、これは「何をしているか分からない」部署とも言えます。
「やること」はあるわけなので、人は増えるわけですが・・・そもそもなんとなく多様な役割が集まった部署なので、成果らしい成果が出るわけがありません。
それでも当時の僕は「自分の島が大きくなる」ような感覚がうれしくて、メンバーを増やしていました。
そうしてある時に私が所属していた子会社全体の業績が悪化した時があり、当然ながら一度引き締めるために人を減らす話になりました。その時に候補に上がるのは・・・もちろん、成果が出ていない部署、役割が曖昧な部署です。
一旦、私が分掌していた部署を解散し、人の再配置と有期契約の終了する事が決まりました。私が分掌していた部署はほとんどが有期メンバーという状態なので、契約を終了することになります。メンバーには告知しないものの、日々減りゆく業務で気づいたメンバーが私のところに来て言った事が、私は今でも忘れる事ができません。
小越さん、私はこの会社で働く事を気に入っているので、なんでも良いから貢献したいと思っています。なにか私に出来ることはありませんか?
無い、と当時の私は言えませんでした。本当は「すいません、私のせいで一度部署は解散になり、伴って皆さんとの契約は終了なんです」と言わないといけないのに。
・何を学んだか
非常にシンプルです。マネジメントとは組織成果が全てである、
という事です。
そして、「成果」はしっかり定義するべきでした。自分や部署に期待されている役割、自分が経営計画に貢献できると思っていること。これは実際に発言し、すり合わせればよかったと思います。
組織成果が出てない組織がどうなるか。無くなる。
そんなシンプルな事を私は学びました。
CTOの退職から学んだ事
・どういう失敗をしたか
時代はちょっと下ります。私が違う部署で20名程度のエンジニアが所属してる部署をマネジメントしていたときの話です。
私はその時に初めて「CTO」と呼ばれる人と仕事をしました。高いコミュニケーション能力をもちプランナーサイドともエンジニアとも何不自由なくコミュニケーションをとりプロジェクトをまとめていました。また、自身も高いコミット力で設計からコードをバリバリ書くところから、運用までレベル高くこなす彼は非常に尊敬されていましたし、頼りにされていました。
ただ、ある時から彼に私は相談をされるようになっていました。
曰く、「今使っている技術、ドメイン、デバイスに向けた開発にちょっと限界を感じている。伸びているところで勝負したいという気持ちがある」
それはもちろん、そうでした。私は彼が言っている事が理解できました。ただ、1on1の時に頷いていながら同時にこうも思っていたのです。「そうはいっても、さすがに抜けないんじゃないかな・・・代わりが全然いないよ。」
同じ悩みを何回か相談された後、ある日彼から静かにこう告げられます。
「退職しようと思います。」
それなりの立場にある人の決意ですから翻意は叶いませんでした。
・何を学んだか
この失敗からはいろいろな学びがありました。
ひとつは、本当にキャリアチェンジを望んでいる人を長期に渡って留め続ける事は難しい。それならば、グループ内も含めてこちらから期間を決めて提案すれば良いという事。
当時、彼の希望に合致する子会社はサイバーエージェントグループ内に既に存在していたので、そこに異動してもらい、もしかしたら再度一緒に仕事をすることもあったかもしれません。
それ以来、私はキャリアチェンジについてある程度寛容になりました。一定期間貢献してくれて、希望が強いならば、話し合いの上期間を決めて送り出す、という事をやっていました。
ふたつめは抜けないと思っていた彼が抜けたあと、組織は彼無しでなんとかする体制に変わった事です。もちろん、代替になる人はいませんでした。
でも、いないなりに違う方法が編み出されて違う組織なりの運用が可能になりました。
後任が絶対必要だ、という自分が思考停止していた事を理解しました。
みっつめは「出戻り組」は、有力な採用ソースという事です。
後々、私が別の新規事業を立ち上げる事になった際、真っ先に声をかけたのは円満に異動、退社していったメンバー達でした。
そう、長い時間軸で見るともう一度働くこともあるんだ、という事を理解している現在、もう少し長い時間軸で考えられるようになりました。
サプライズ退職から学んだ事
・どういう失敗をしたか
更に時代は下ります。30名程度の部署をマネジメントしていた時の話で、
その時もエンジニアをマネジメントしていました。
2-3名程度から30名まで拡大しつつあったその部署はいろんなきしみが出ていました。わかりやすいところでは、意思疎通の不備やキャッチアップするコストが高すぎて、hotfixが連発されている、などです。
更にマネージャーである私自身にも限界が来ていました。1on1を通常月に1回行うのですがそれだけではメンバーのことやメンバーのパフォーマンスが十分に把握できず、アサイメントや評価などに、すこしずつ、すこしずつズレが出てくるようになりました。
ズレは当然、メンバーがそのつけを払うことになります。
なにかを変えなければいけない、そう思いながらほとんど何も変えられないでいたとき、期待の新メンバーから突然の退職をつげられました。タイミングの問題、と彼は言っていましたがその時に私ははっきりと自分のマネジメントを変えなければこのまま続けられないと悟ったのです。
・何を学んだか
簡単に言えば、この問題は1:1で対話しながらマネジメントすることがもう限界であることを示していました。
そこで私は1:Nでコミュニケーションを取る必要を悟り、そういうマネジメントに変えることにしました。具体的には、「以心伝心からシステムへ」「1on1からプレゼンテーションとSurveyへ」「一回一回の特別な対応から、仕組みを作り再現性があるように」。
すべて細かくは書かないですが、例えば目標設定や査定の仕組みを整えたりもこれにあたります。
Surveyというのは、メンバーを対象に行うアンケート調査のことです。典型的には「CoreValueがどれくらい体現されているか?」といったことを4段階評価してもらい、フリーアンサーを受け取ります。
そして、チーム会やAllhandsで意見を紹介しながら対処するものには具体的な対処方法、対処しないものもあえてとりあげ、対処しない理由を発表しました。
今まで1on1でしていた対話のプロセスを1:Nで行うような感覚です。
このときの私の学びは、今でも組織が「ちょっとした規模」になるときに何回も使えるフレームワークとなっています。
星取り表を元にした戦略の失敗から学んだ事
・どういう失敗をしたか
これは比較的新しい失敗で、去年の話です。
とある市場の可能性を感じていた私は密かに調査を進め、現状の事業が破壊される可能性があるとともに、チャンスでもあることを確信しました。
そうして、その市場に参入しようと思ったときに、差別化要素を分かりやすくするために星取り表を作ることにしたのです。その時把握していた顧客が感じる利益を横軸にとって、将来の参入の可能性まで見据えて戦えるかを検証しました。
念の為補足すると、星取表とは、想定競合を横、必要バリューを縦にとり、競合に対してどの要素で勝てるかを可視化する表です。
そして、出た結論は、おそらく1位を取るであろうプレイヤーには勝てない。軸をずらして参入しようという決断でした。
・何を学んだか
結論として、私のよみは外していました。1位が全部を独占すると思っていたその市場は、実は2-3位くらいのプレイヤーまでは十分に収益を上げる可能性がある事業でした。
そして、2-3位のポジションを持っていれば、蓋を開けてみれば首位にもつけ入るすきがあることが分かる市場だったのです。一去年の決断で一番悔しかった失敗です。
私はこの失敗から、星取表の危険性を学びました。
1)そもそも星取り表で比較している項目が正確に市場ニーズを表しているとは限らない(というか、ほとんどの場合多様なニーズをひとつに錯覚させてしまう)。
2)同居可能な事業者数がわからない
これはつまり、ニーズが異なる層を分け合う、という戦略が見えない
他にもありますが、要するに一昨年あの時点で星取表を出し、全てに○がついても我々は勝てなかったと思います。苦い思い出です。。。
以上が私を育ててくれた失敗です。最後までお読みいただき、ありがとうございました。