お疲れ様です!IT業界で働くアライグマです!
自社SaaSの開発チームにおいて、事業方針の転換により「1ヶ月後にベトナム子会社が解散する」という突然の通達を受けた経験があります。
これまでバックエンド開発の多くを担っていたオフショア(約6名規模)の拠点が閉鎖され、日本国内のエンジニア3名体制へ全業務を引き継がなければならないという、まさにスクランブル発進の体制移行でした。
しかも、引き継ぎ先となる国内メンバーは、自分よりも年齢が上で業界歴も長い猛者シニアエンジニアたちでした。開発速度を1ミリも落とさず、リリース遅延ゼロでKR(開発件数目標)を達成するまでに実践したマネジメントの工夫と泥臭い試行錯誤についてお話しします。
突然のオフショア解散宣告:1ヶ月で6名分の開発を引き取るプレッシャー
ある日突然、事業方針の変更によって「1ヶ月後にベトナム子会社を解散する」という決定が開発現場に降りてきました。
当時、ベトナム側のチームは約6名体制で、主にバックエンド側の機能開発を精力的に担ってくれていました。しかし、拠点の解散が決まった以上、残されたわずか30日足らずの期間で、彼らが持っているすべての業務と知識を日本国内チームへ移管しなければなりません。
受け皿となる国内チームは、プロパー社員2名と業務委託1名の計3名。自分(テックリード兼プレイングマネージャー)を含めてもわずか4名という小規模な体制でした。
約6名が回していた開発ボリュームを実質半分の人数で引き取るだけでも相当な負荷ですが、会社から求められたミッションは極めて明確でした。
- ベトナム側の開発業務・運用保守を国内チームへ完全に移管すること
- 体制移行中であっても開発速度を落とさず、機能追加と改善を継続すること
- 毎月のリリース件数目標(KR)を未達にせず達成し続けること
「人が減ったからリリースが遅れました」という言い訳は通用しない環境です。しかも、最大の問題は人数比だけではなく、ベトナム側に偏在していた仕様や手順のブラックボックス化でした。
IT女子 アラ美属人化のブラックボックスを壊す:Notionへの集約と引き継ぎ基盤の構築
体制移行で最初に直面した最大の障壁は、「仕様とデプロイ手順のブラックボックス化」でした。
それまでベトナム側が主導して改修を重ねてきたバックエンドのロジックや、CI/CDパイプラインを介したデプロイ手順、各環境固有のツール設定などが、彼らの頭の中やSlackの断片的なやり取りだけに留まっており、ドキュメントとしてまともに残っていなかったのです。
1ヶ月が経過すれば、彼らは退職・解散し、二度と質問できなくなります。Slackで都度質問している時間的猶予はありませんでした。
そこでまず着手したのが、「ベトナム側しか把握していない仕様知識と運用ツールの徹底的なNotion集約」です。
具体的には、以下のような観点で引き継ぎフォーマットを用意し、ベトナム側の各担当者に記述を依頼しました。
## 引き継ぎドキュメント構成テンプレート
1. 機能・ドメインの概要とビジネス要件(なぜこの仕様になっているか)
2. 関連するAPIエンドポイントとバッチ処理の一覧
3. 依存している外部連携サービス・認証トークン・環境変数
4. デプロイ手順と環境固有の反映手順(マイグレーション実行手順含む)
5. 過去に発生した障害パターンとトラブルシューティング手順
ただ「書いてください」と丸投げするのではなく、上がってきたドキュメントを国内チームで実際に読み合わせ、ローカル環境や検証環境で手順どおりにデプロイや動作確認ができるかを一つずつ検証しました。
不明点があれば即座にNotion上でコメントし、その日のうちに追記・修正してもらうという往復を繰り返しました。この土台があったからこそ、拠点が解散した翌日からも国内チームが迷子にならず、自走してシステムを触り続けられる環境を整えることができました。



年上・業界歴の長いシニアエンジニア3名とどう向き合ったか:指示ではなく適材適所と伴走
ドキュメント基盤の整備と並行して、マネジメント面で最も神経を使ったのが「国内メンバーとの向き合い方」でした。
新体制の国内メンバーは、正社員2名と業務委託1名の計3名。いずれも自分より年齢が上で、IT業界でのエンジニア経験もはるかに長い百戦錬磨のシニアエンジニアたちでした。
このような経験豊富なエンジニアに対して、年下のテックリードが上から目線で「あれをやれ、これをやれ」と指示命令を出しても、チームの一体感は生まれませんし、本来のパフォーマンスを発揮してもらうこともできません。
そこで私が意識したのは、「個々の得意領域と志向性を徹底的に尊重したタスク配分」と「自ら率先して手を動かすプレイングマネージャーとしての伴走」でした。
まず、1on1や日々の会話を通じてメンバーの志向性をヒアリングしました。たとえば「自分はインフラやバックエンドの設計に集中したい」「ロジックの最適化が得意だ」といった希望を丁寧に吸い上げ、無理に苦手な領域を押し付けるのではなく、強みが最大限に活きるように担当タスクを振り分けました。
以前に入社2週間で受託開発を引き継ぎ、ジュニア中心チームで納期と品質を死守した「タスク咀嚼」術でも触れましたが、チームの習熟度やメンバーの特性によって、マネージャーが果たすべき役割は大きく変わります。
ジュニア中心のチームでは「タスクを細かく分解して渡すこと」が主軸になりますが、シニアエンジニアに対しては、大きなゴールと技術的な要件を共有した上で裁量を渡し、マネージャー側は「他部署との仕様調整」「ブロッカーの排除」「進捗管理」に徹して彼らが開発に専念できる環境を守ることが最も効果的でした。
さらに、当時はまだCursorなどのAIコーディングツールが社内に導入されていなかったため、人手不足を補うべく、私自身もテックリードとしてフロントエンド・バックエンドを問わず自らコードを書いてPRを出し、リリース作業まで並行して進めました。「口先だけで管理するのではなく、一番面倒なタスクや隙間の実装も自ら拾って走る」というプレイングの姿勢を示したことで、年上の猛者エンジニアたちからも早い段階で深い信頼を寄せてもらえたと感じています。



週次KR管理と粘り強い伴走:開発速度を落とさずリリース遅延ゼロを達成
体制移行における最大の評価指標(KR)は、「月間の開発・リリース件数目標を落とさないこと」でした。
人数が約半減したからといって開発速度が落ちてしまえば、事業の成長スピードに急ブレーキがかかってしまいます。この目標を死守するため、私は「週単位でのKR進捗管理と早期アラート運用」を導入しました。
具体的には、月末に慌てて件数を数えるのではなく、月初の目標値を週ごとにブレイクダウンし、週次定例で実績と見通しをトラッキングしました。
【週次KR進捗管理サイクル】
・週初: 各メンバーの仕掛かりタスクとリリース予定件数の棚卸し
・週中: レビュー待ち・QA詰まり・他部署確認のブロッカーをPMが即座に解消
・週末: 目標件数に対する進捗率の記録(未達リスクがあれば即座に上長へリソース相談)
もし週半ばの時点で「あるタスクが外部仕様の確認待ちで止まっている」「レビューが滞って今週中のリリースが危うい」という兆候が見えれば、私が自ら他部署へ確認に走り、必要に応じて自分がレビューや修正を巻き取ってリリースまで押し込みました。
未達リスクがどうしても避けられない見通しになった場合は、月末になってから「間に合いませんでした」と報告するのではなく、2週間前の段階で上長へリソース調整や優先順位の変更を早めに相談する運用を徹底しました。
移行期の数ヶ月間は、正直なところ現職で最も負荷が高く、深夜や休日問わず開発件数の数字と向き合い続けるような怒涛の日々でした。しかし、この粘り強い伴走とメンバー全員の奮闘の結果、体制移行期を通じてもリリース遅延を一度も発生させることなく、毎月のKRを完全達成することができました。
さらに、体制が安定した後半からはAIコーディングツール(Cursor)の活用をチーム全体へ浸透させました。これにより、少人数体制であってもオフショア6名時代と同等以上のリリース頻度をチームとして自走・維持できる筋肉質な開発フローが完成したのです。



まとめ
オフショア子会社の突然の解散通達からわずか1ヶ月。約6名分の開発業務を国内3名体制へと引き継ぐ怒涛の移行期は、これまでのキャリアの中でも最もプレッシャーのかかる挑戦でした。
しかし、この危機を開発速度を落とさずに乗り越えた経験から、少数精鋭チームを率いるマネジメントにおいて大切な3つの教訓を得ることができました。
- ブラックボックスを放置しない: 退職や解散で人がいなくなる前に、仕様やデプロイ手順をNotion等のドキュメントへ強制集約し、実際に動かして検証する
- シニアへのリスペクトと環境づくり: 年上猛者エンジニアには指示命令ではなく、志向性を尊重したタスク設計と、開発に専念できる環境(ブロッカー排除・他部署調整)を提供すること
- プレイングマネージャーとしての泥臭い伴走: 自らもコードを書いて背中を見せつつ、週単位で進捗の歪みを早期検知してカバーすること
大変な局面ではありましたが、このスクランブル移行をやり切ったことで、プロダクト全体のアーキテクチャやドメインへの理解が誰よりも深まり、どんな体制変化にも揺らがないチームの土台を作ることができたと実感しています。
急なチーム縮小や体制変更、あるいは経験豊富なシニアメンバーのマネジメントに直面している方の参考になれば幸いです。










