【開発チーム・ハンドブック】（3）開発メンバーが異動で別のマネージャーの元で働くとき

2020-12-18
Coral Capital

本連載はオープンソースライセンスの1つであるGPLの元に公開されている「The Eng Team Handbook」（エンジニアチーム・ハンドブック）を翻訳したものです。開発チームが効率的に仕事するために必要な「効果的な1on1の実施方法」「開発メンバーから開発マネージャーに役割が変わるときの注意点」「パフォーマンス評価のテンプレート集」「360度評価のテンプレート」などが含まれます。

著者はStripeのエンジニアであるrayleneさん。これがStripeのやり方と明示されているわけではありませんが、急成長するシリコンバレーのスタートアップにおけるエンジニアチームの取りまとめ方という意味で、日本のスタートアップでも参考にしていただけるのではないかと思います。全体を5回の連載に分けてお届けします。本記事は第3回です。

【開発チーム・ハンドブック】連載目次

エンジニアの異動に伴うマネージャー変更

本ガイドはマネージャーとして、別のチームに異動するエンジニアの移行を円滑に行うための方法を説明しています。

用語

異動元／現在のマネージャー：異動するエンジニアのマネージャー
チームメンバー：異動するエンジニア
異動先／新しいマネージャー：エンジニアが異動した先の新しいマネージャー

以下に、チームメンバーの異動をすでに経験していて、簡単な概要だけを知りたい方向けのステップを記します。

直接話をする：マネージャーは異動するチームメンバーと1対1で、異動について直接話し合ってください。マネジャーとチームメンバーが同じ認識を持っていることを確認してから、異動を他の社員に伝えます。
異動計画を立てる：いつ、どのように異動するか計画を立て、他のメンバーに引き継ぐ仕事を洗い出し、一覧を作成します。
異動を周知する：チーム内や社内に異動を通達し、質問やフィードバックを受け付けます。
異動中：異動をスムーズに行うため、移行期間中は異動元のマネージャーと異動先のマネージャーがどちらも異動するチームメンバーのマネージャーとして関わります。
最終確認：事務手続きが済んでいるか確認しましょう。

直接話をする

可能な限り、現在のマネージャーは異動するメンバーと直接話し合い、異動について合意を得ましょう。

チームメンバーはすでに友人、さらには異動先のマネージャーと異動について話し合っていることがよくあります。それで異動をなし崩し的に進めるではなく、当事者である現在のマネージャーとチームメンバーが異動について直接話し合い、合意した上で異動を進めることが重要です。チームの状況を最も理解しているのは、現在のマネージャーと異動するチームメンバーであるので、2人で異動の計画を立てるのが望ましいでしょう。

話し合うこと：

チームメンバーが別のチームに異動したいと考える理由は何ですか。
チームメンバーはどのように異動先を決めましたか。
チームメンバーが異動を決断するにあたり、マネージャーにできたことやこれからできることはありますか。

あなたが異動先の新しいマネージャーである場合、逆方向から上記の点について考えましょう。現在のマネージャーがチームメンバーと異動について直接話し合うまで、メンバーの異動を承認しない方がいいでしょう。また、なぜそのメンバーがあなたのチームに異動することに興味を持ったのか理由を聞いてください。

どちら側のマネージャーでも、異動を承認する前に、マネージャー同士で話し合う機会を設けましょう。

異動計画を立てる

現在のチームから離れ、スムーズな異動のためにすべきことを洗い出します。これは現在のマネージャーとマネージャーが率いるチームのメンバー、それから現在のマネージャーと新しいマネージャーとで詳細を決める必要があります。

現在のマネージャー <=> チームメンバー

異動は単にマネージャーや組織変更以上の作業が発生します。異動するメンバーが担当している仕事を洗い出し、いつまでに、どうやって担当を引き継ぐかを決めましょう。異動計画はメールなど、文書にして共有します。異動計画に載せる内容は以下の項目を参考にしてください。

異動時期。これは進行中のプロジェクトに加え、現在のチームおよび異動先のチームのニーズを考慮する必要があります。「この仕事が終わる6週間後に異動する」といったように、実際に異動するしばらく前から計画を立てることができます。
異動するチームメンバーが担当している仕事やプロジェクトを洗い出し、それぞれの仕事を引き継ぐ。異動計画には、後任の担当者に仕事を引き継ぐのに必要な時間を含める必要があります。
異動先チームにとって異動のタイミングと異動計画は理に適うか。異動のタイミング（例：6週間後）が両チームにとって理に適うか確認しましょう。場合によっては、仕事を調整する必要があるかもしれません。例えば、「異動は2週間後で、そこから異動先の仕事を始めるけれど、現在のチームでの仕事を終え、完全に引き継ぐまではそちらの仕事も続ける」など。

以下にエンジニアの仕事をいくつか記しています。

プログラムの運用と修正対応
コードレビュー
採用面接（専門的な分野では特に重要。機械学習/フロントエンド/モバイルなど）
進行中の重要なプロジェクト

現在のマネージャー <=>異動先のマネージャー

チームメンバーのためにプロジェクトや業務ベースの異動計画を立てるだけでなく、メンタリングやキャリア開発の面でもスムーズな異動ができるように気を配りましょう。なるべくチームメンバーに関する情報を共有するようにします。異動から数か月経って気になることが出てきた場合も遠慮せずに聞くようにしましょう。

マネージャー同士で共有すべき内容：

異動元のチームに在籍していた期間、可能なら会社に在籍してきた期間におけるチームメンバーの情報：参加したプロジェクト、チームでの立ち位置、興味のある分野など
長期的、短期的なキャリア目標
強みと今後伸ばせる部分：過去のパフォーマンス評価やフィードバックを共有する
チームメンバーのマネージャーとしてその人について学んだこと：その人に合ったマネジメントスタイルや1on1の頻度など。

パフォーマンス評価とフィードバック

過去のパフォーマンス評価やフィードバックをどのように共有すべきか悩んでいるマネージャーもいるかもしれません。パフォーマンス評価やフィードバックは積極的かつオープンに共有しましょう。メンバーのキャリアの発展に役立つよう、各関係者がメンバーのパフォーマンスについての情報を共有しているのが望ましいです。具体的な方法としては、過去のフィードバックを要約した内容をメールで共有したり、「1:1:1」のミーティングで（前のマネージャー、チームメンバー、新しいマネージャー）フィードバックを共有したりすることができます。

異動を周知する

異動の影響をより強く受ける人から順にメンバーの異動を伝えます。

現在のマネージャー、チームメンバー、新しいマネージャーで情報を共有し、異動計画ができたら、異動を他の社員に伝えます。どのチームも同じではないので、あなた自身の判断で最も理に適う伝え方をしましょう。

異動を周知する方法の一例：

最初に直接関係するチームに異動を伝えます。次回の1on1で1人ずつ伝えるか、チームミーティングの際に周知します。もちろん、チームを異動するメンバー自身が伝える形でも構いません。また、「異動について質問があるなら遠慮なく聞いてください」と呼びかけるなどして、他のチームメンバーからの質問を受け付けます。
次に自分たちのチームと関わりの深いチームに伝えるか、メーリングリストなどで社内に広く周知します。

一般的には現在のマネージャーが異動を伝えるのが最適ですが、必要に応じて変えても構いません（例：マネージャーがすでに離職している、あるいは育児休暇でいない場合など）。

異動開始！

どちらのマネージャーも異動計画に積極的に関わり、スムーズな異動を行います。

異動を周知したら、異動の最初から最後までチームメンバーをサポートします。新しいチームで人間関係を築くのには時間がかかります。なので、メンバーが異動元のマネージャーと異動先のマネージャーのどちらからもサポートが受けられ、どちらにもフィードバックができる環境を整えることが重要です。両方のマネージャーが関わる期間は状況にもよりますが、最大1か月間が目安です。

マネジメント移行の一例（異動と並行して行う）：

異動するメンバーは、両方のマネージャーと1on1を行います。その後、異動元のマネージャーとの1on1は正式に終了しますが、いつでも連絡が取れるようにしておくと良いでしょう。
たとえ組織上では関連がなくなったとしても、個人的な関係を断つ必要はありません。
フィードバックが互いに行える環境にするのが望ましいでしょう。異動元/異動先のマネージャーはマネージャー同士、あるいは異動元/異動先のチームのメンバーと1on1が順調か話をするようにします。
これは正式な形で行う必要はありません。たまに顔を出し「最近どう？」と聞くのでも構いません。