マネージャの継承をするときに考えること
これはEngineering Manager Advent Calendar 2023 13日目の記事です。
エンジニアリングを軸としながら、現職で所謂マネージャという役割を正式に担い始めてから約2年、自分が持っていた職責を他のメンバーに渡して次のステップに挑戦したり、他のマネージャが職責を継承していくサポートをしてきました。
その中で心がけたこと、今振り返ってこうすればよかったなと思うことがいくつかあるので、この期に棚卸ししようと思いました。
マネージャの継承についての文章って意外と少ないと思うので、誰かの役に少しでも立てば嬉しいです。
"成果"に対する向き合い方が変わることを伝える。客観的に見た成果をより細かくフィードバックし続ける
個人的にマネージャという職責を担って大きく変わる(変えざるを得ない)のは成果に対する向き合い方だと考えています。
これまでマネージャを経験したことのある方であれば、これまで以上にアピールできる成果が減ったなあ・・・とか、成果が出るまでかなり時間がかかるのでしんどいなあ・・・という気持ちの壁に何度もぶつかったことでしょう。
脅すわけではないのですが、事前にこの事実を知っておいてもらうことでマネージャという仕事と向き合う覚悟を持ってもらい、いざその事実に直面したときに周りを頼り、長期的な時間軸の視座を持ってチームで成果を挙げられるよう準備を一緒に整えます。
とはいえ、「成果がでるまで時間がかかるから頑張れ!」だけだと誰でもしんどいので、北極星に向かって着実に歩みを進められている実感を持てるようにする必要があります。
職責を新たに継承したマネージャが主導する様々な取り組みが、目指す北極星に対してどの程度妥当であるか、課題がある場合どのように軌道修正すべきかを、役割を継承した初期は特に気を配ってコミュニケーションを取ります。
マネージャとしてやってきたこと、その背景、見えていた課題を伝える。
継承をする上では未来の話だけでなく足元の"今"の話もとても重要です。
ジョインして日の浅いメンバーだったり、それなりに歴があるメンバーだったとしても昔のことは意外と覚えてなかったりするでしょう。 (自分もよく忘れる)
任せるチームがそのタイミングでどういった状況か(プロジェクト、メンバーの状況、チーム外との関係値 etc...)や、それまでの取り組み(メンバーとのコミュニケーション、スクラムイベント、職能やチーム間の関係値づくり etc...)がどのようなきっかけで何を考えてやり始めたのかという経緯、各取り組みなどが抱える課題を伝えて、新任のマネージャが現状と理想をつなぐための目標や取り組みを考えられるようにサポートをします。
組織として何を目指し、何をマネジメントしてほしいか伝える
新たな役割にチャレンジし、さらに大きな事業成果を挙げ続けてもらうためには、いかに全社の目標やスタンスと地続きに本人が目標を立て実現していってもらうかがとても重要です。
新任のマネージャが自ら自チームの北極星を打ち立てメンバーと一緒に推進できるようにするために、継承元のマネージャはより視座を上げて北極星を打ち立てる必要があります。
ただ目標を立てそれに従ってもらうのではなく、目標を自分で立てメンバーを巻き込みながら推進できるようになってもらうことで、組織をよりスケールしやすくすることが出来ます。
また、EMといってもその範囲は非常に広く、マネジメントの領域によってはコンテキストスイッチが発生したり、得意不得意によるパフォーマンスのばらつきがうまれ、かなり苦戦することでしょう。
課題解決のスコープをうまく絞り、切り替えながらマネージャとして仕事をしていくには、それなりの経験とスキルが必要です。
組織状況によって特に注力すべきマネジメント領域も異なるため、最初から全領域を任せるのではなく、最初は2人3脚でマネジメントのカバー範囲を調整し、着実に成果を挙げてもらいながら見る領域も増やしてもらうことで、継承する/される側のリスクを減らしながらパニックゾーンに入ってしまうことなく新たなチャレンジを後押しすることが出来ます。
マネージャはうまく行ったときも行かないときも、チームや組織などに与える影響が大きいため、任せる側としてもどうしても慎重になってしまうと思います。
組織のスケールのためにメンバーにチャレンジのきっかけをたくさん作っていくためには、当たり前ですがこういった丁寧なサポートが必要だなあとこれまでの経験を踏まえて痛感しています。
同じことはしなくてよい、ということを伝える
役割を継承するということは、なんらかの形でチームや組織の状況が変わったということだと思います。
状況が変わったということはこれまでやっていたことや職能の定義、メンバーの期待値なども改めて見直す必要があるかもしれません。
しかし、新たな役割を担うということはとても大きなプレッシャーとなるため、コンフォートゾーンを抜け出せず表面的にこれまで通りの取り組みを行ってしまい、役割を継承したにも関わらず改善が促進されない、組織がスケールしない、といった状況に陥る可能性があります。
役割の継承は、それまでの様々な取り組み、定義を棚卸しして仕切り直すよい機会なので、上で書いたような現状の共有を通じて課題の共通認識を育み、場合によっては今ある仕組みや定義、期待を"一緒に"ドラスティックに変えてしまうのも手です。
いまでこそ色々な事例が世に出るようになってきましたが、自分が所属する組織においてマネージャという職責をどう定義するかは最後は自分たちで考え定義し、状況に応じてアップデートしていかなくてはなりません。
ここで書いたようなサポートを通じて、自らを取り巻く仕組みや期待だけでなく、自らの職責自体も一緒に定義し直していこう!というメッセージングをしていきたいという想いもあります。
同じチャレンジをする仲間を作る
少し自分の話をすると、2年ほど前にEngineering Program Managerという役割を任され、そのタイミングで本格的にマネージャの門をたたきました。 EPM(Technical Program Managerと呼ぶ会社もある)という職責はそもそも世の中にケースが少なく自ら役割を定義していく必要があり、更には同タイミングで採用も担いはじめました。
新たなチャレンジをするのはとても勇気がいることです。マネージャともなるとメンバーのパフォーマンスに影響を与えたり、採用においてはお給料などにも影響を与えうる役割となります。
しかし、自分の場合はありがたいことに同タイミングで他に2人がEPMの役割を担い、計3人で日々の開発をリードしつつ自身の役割の定義や採用の試行錯誤をするようになりました。
正直同じタイミングでチャレンジする仲間がいなかったら、ここまで色々な言語化やそももそもマネージャとしてのチャレンジは心が折れていたと思います。一緒にEPMをやってくれた仲間には本当に感謝しています。
そういった経験も踏まえ、大きなチャレンジをしてもらうときに同じレイヤーで一緒に試行錯誤できる仲間もできるだけ作れるようにし、コンフォートゾーンから抜け出しやすくすることを心がけています。
最後に
EMは定義が広いです。広いということはそれだけ課題解決の選択肢が与えられているとも言えると思います。
役割を任せる際には自ら羅針盤を作り、オーナーシップを持ち自らの役割を自分で定義し続け、自分が率いるチームがどの島に向かうべきかを選べるようになって行ってもらいたいと思っています。
そのために、役割を任せる側の人間としてはこれまで自分自身がどういう海路や島々を辿ってきたか伝えて歴史から学んでもらい、はじめは一緒に舵を取っていく必要があると思います。
自分がそうしてもらったように、他のメンバーに対しても同じように、それ以上にサポートをしていろんなチャレンジをしてもらえるようになり、それがもっと広がってより多くのメンバーが自分で自分の仕事を作っていろんなチャレンジができるようになっていってもらいたいなと思っています。
全ては問いの質で決まる 〜"みんなでアジャイル"書評〜
とあるきっかけがあって、"みんなでアジャイル"をお盆休み中に読んだ。
存在は知っていたものの、またアジャイルとかスクラムのテクニック本でしょとかひねくれた偏見を持っていたが、日々改善を繰り返しながらチームとして共通のゴールへ向かうための価値観や考え方を丁寧に言語化してくれているとても良い本だった。
感想
全体を通して、エンジニアの文脈で語られがちだったり、具体的なプラクティスについて背景や解決したい課題について深ぼられることなく議論されがちなアジャイルというものについて、なぜアジャイルな文化をつくりたいのか、どういった価値観であればよいのか、どういった組織課題を解決したいのか、など目的についてしつこいほど何度も繰り返し言及している。
巷で見かける、"いわゆる"スクラムやアジャイルについての議論に対して漠然と抱えていた的外れ感の答えや、自分たちがチームで作り出そうとしてるムーブメントについての強力な武器を得られた気がした。
1章のまとめにある"アジャイルはシンプルにできている(だが簡単ではない)"というタイトルがアジャイルを浸透させる難しさを端的に表しているなと感じた。
シンプルだからこそさまざまな手法が存在する余地があり、様々な課題や方向性を持つ組織に持ち込む器の広さがアジャイルにはあるからこそ、自分たちの組織の課題を解消するためにどのようにアジャイルの原則を適用すべきか自分たちの頭で徹底的に考え、行動しなければならない。
幼い頃から今に至るまで目的を考え行動する訓練をあまりしてこなかった人には確かにとてもむずかしいだろうし、個人ではなくチームや組織として実現するために能動的な進行役として推進していかなければならないということを改めて突きつけられ、身の引き締まる思いをした。
この本をおすすめする人
- どういったかたちであれ、チームでものづくりをしている人
- チームや組織での仕事のしざまに停滞感を感じている人
- スクラムやアジャイルの文脈でよく紹介される手法に違和感を感じている、または導入してもあまりうまくいっていないと感じている人
ムーブメントとしてのアジャイル
様々な失敗を繰り返しながら自分たちなりにアジャイルの本質の一部だけでも理解できたチームが、改めてアジャイルソフトウェア開発宣言の全文を見ると17人の賢人が言いたかったことがより深く理解できると思う。
続きを読む"チームが機能するとはどういうことか" 書評
所属する組織で期待される役割が変わり、これまで以上にチームの動き方に意識を向ける機会が増えた。
どういう事を考え、働きかけるべきか学ぶために、Amy C. Edmondson著の "チームが機能するとはどういうことか"を読んだ。
本の刊行自体は2014年だが、今読んでも内容の古い点などは感じられず、リーダーがどういうスタンスであるべきか、チームメンバーにどうあってもらうべきかなど、チーミングについてよくまとまっていた。
今後大いに参考としていきたいと思ったので整理がてら書評を書く。
この本をおすすめする人
- チームを率いる役割を担う人
- チームのリーダーとしてどう考え、振る舞うべきか悩んでいる人
- チームメンバーにどういったスタンスでいてもらえばよいかわからない人
- 仕事の特性を踏まえ、チームがどう学習していけばいいか知りたい人
世の中には様々な仕事の特性があり、組織規模に合わせた様々なサイズのチームが存在すると思う。
そういった様々な背景や状況のチームを率いる人に対して、リーダーとしてのあり方やチームメンバーの行動変容の方法など様々なアイデア、フレームワークを提供してくれる本である。
当然それらのツールをそのまま適用してもうまくいくわけではないが、自分たちを一度客観視するためにはとても有用な本だと思った。
全体の構成
この本は全部で3部、8章構成になっている。
第1部では、チーミングとはなにかやそのプロセス、メリットなどの説明を行っている。
続く第2部では、チーミングの人間的な側面について主に述べ、フレーミングを使った行動変容や心理的安全、失敗の重要性について述べている。
最後の第3部では、どのように旧来の組織から自律的にチーミングを行える組織へ変容させたかを実例を交えながら説明している。
参考になったところをピックアップ
続きを読むISUCON11予選に参加した(47995点で予選落ち)
要約
2021/8/21 に開催されたISUCON11オンライン予選に参加した。
結果は47995点で598チーム中79位くらい。
初参加かつほぼノー練習の状態にもかかわらず、一応目標にしていた100位以内に入れたのでOK?と思いつつ、他の参加者の参加エントリを見ているとだんだん悔しくなってきた！
ISUCON11の概要はこちら。
初参加のISUCON
随分前から存在は知っており興味はあったが、休みの日に8時間も拘束されるのか~疲れそうだな~と思い敬遠していたISUCON。(同じ理由で競プロにも興味はあるがコンテスト出場はしたことがない)
社のslackで#club-isucon というチャンネルがあり、わいわいして楽しそうだったのと、かつ会社で同じチームの @budougumi0617 さんも初参加されるとのことだったので、申込み人数の上限に達する直前にすべりこみ申し込みをした。
Speed of Sound というチームを組んだ。当日知ったがPerfumeの曲名らしい。⊿は昔よく聴いてたはずなのに気づきもしなかった・・・
予選までの練習
予選1ヶ月くらい前に過去問の中でも特に良問といわれているISUCON9予選問題を解こうと matsuuさんが公開してくださっていたAMIを使ってインスタンスの立ち上げ、ベンチマークの実行まではやった。
しかし公私(特に公)が忙しすぎて平日夜や休日に練習をする体力が0になり、結局きちんとチューニングをする練習をすることなく予選を迎えることになってしまった。なので実質無練習。
github.com
@budougumi0617 さんは事前に競技序盤の初速を上げるためのさまざまなチートシートを作成してくださっており、もう当日序盤の諸々はおまかせすることにしつつ、ボトルネック解消してスコアに直接コミットできるようにするぞ~~~~~と祈りながら前日は寝た。
今考えると完全に他人任せ・・・すいませんでした・・・。
github.com
