ICからエンジニアリングマネージャーへのキャリア転換ガイド

• はじめに: 最も難しい役割転換
• 第1章: ICとEM - 根本的に異なる二つの役割
  • 直接的な貢献と間接的な貢献
  • 成果物の変化: コードから人とシステムへ
  • フィードバックループの違い: 即座と長期
• 第2章: 役割転換を決める前に - 自己診断
  • なぜマネージャーになりたいのか
  • ICトラックとEMトラックの比較
  • Staff+ EngineerとEngineering Managerの選択基準
• 第3章: 最初の100日ロードマップ
  • 1〜30日: 傾聴と関係構築
  • 31〜60日: 小さな改善と信頼の獲得
  • 61〜100日: ビジョンと方向性の設定
  • 100日ロードマップのまとめ
• 第4章: 最も難しい転換 - コーディングを手放す
  • メイカーのスケジュールとマネージャーのスケジュール
  • 技術的貢献とマネジメントのバランス
  • コーディングを手放すのが難しい理由
• 第5章: よくある失敗とアンチパターン
  • アンチパターン1: 「自分ならもっとうまくやれる」の罠（マイクロマネジメント）
  • アンチパターン2: すべての技術的決定に介入する
  • アンチパターン3: メンバーの成長機会を奪う
  • アンチパターン4: 対立を避ける
  • アンチパターン5: 全員を幸せにしようとする
  • アンチパターン総合セルフチェック表
• 第6章: 中核スキルの開発
  • スキル1: 1対1ミーティングの運営
  • スキル2: 評価とフィードバック
  • スキル3: 採用と面接
  • スキル4: ステークホルダー管理
  • スキル5: プロジェクト管理
• 第7章: バーンアウトの予防とセルフケア
  • EMのバーンアウトが特別な理由
  • セルフケアのチェックリスト
• 第8章: ICに戻ってもかまわない - 役割転換の可逆性
  • エンジニア・マネージャーの振り子
  • EMからICに戻ることに価値がある理由
  • 戻るときの注意点
  • 役割選択の意思決定フレームワーク
• 第9章: チェックリスト - EM転換後100日のセルフチェック
  • 最初の30日の点検
  • 31〜60日の点検
  • 61〜100日の点検
  • 100日以降の長期点検
• 第10章: 実践的なフレームワークとテンプレート
  • 1対1ミーティングのメモテンプレート
  • 週次チーム状況報告テンプレート
  • 新任マネージャーの90日学習計画
• 結論: 転換は旅である
• 参考資料

はじめに: 最も難しい役割転換

ソフトウェアエンジニアのキャリアで最も劇的な転換点の一つが、Individual Contributor（IC）からEngineering Manager（EM）への役割転換です。これは単なる昇進ではありません。まったく別の職業への転換です。

Camille Fournierは著書『The Manager's Path』（2017）でこう述べています。

「マネジメントは技術的リーダーシップの自然な次の段階ではない。それはまったく異なるスキルセットを要求する、別個のキャリアトラックである」

昨日までプルリクエストを出しコードレビューをしていた人が、今日から1対1のミーティングを行い、評価を書き、採用面接を担当することになります。成果の基準が「自分が何を作ったか」から「チームが何を達成したか」へと完全に変わります。フィードバックループも即座のもの（コンパイル、テスト）から長期的なもの（四半期、半期）へと変わります。

この記事は、ICからEMへの転換を検討している、あるいは転換して間もないエンジニアのための100日サバイバルガイドです。さまざまな経験と参考文献をもとに、役割転換の全過程を実践的に案内します。

第1章: ICとEM - 根本的に異なる二つの役割

直接的な貢献と間接的な貢献

ICとEMの最も本質的な違いは、価値を生み出す方法にあります。

Julie Zhuoは『The Making of a Manager』（2019）でマネージャーの役割をこう定義しました。

「マネージャーの仕事は、チームがより良い結果を出せるように助けることだ。それがすべてである」

単純に見えますが、この定義は深い含意を持ちます。「助けること」が核心です。マネージャーは結果を直接つくる人ではなく、結果をつくる人たちを助ける人です。

成果物の変化: コードから人とシステムへ

ICの成果物は目に見えます。コード、プルリクエスト、システム設計書、技術ブログ。一日が終われば「今日は何をしたか」への答えが明確です。

EMの成果物は目に見えません。メンバーとの対話、対立の解消、方向性の設定、障害物の除去。一日が終わっても「今日は何をしたか」への答えがはっきりしない日が少なくありません。

Will Larsonは『An Elegant Puzzle』（2019）でこの違いをこう表現しました。

「マネージャーとして最も生産的だった日は、外から見れば何もしていないように見える日だった」

この変化に適応できないと、新任のマネージャーは「今日、自分は何をしたのだろうか」という不安に絶えず苛まれます。コードを書かなかった一日は非生産的な一日のように感じられます。しかし、メンバーのブロッカーを解消し、ステークホルダーとコミュニケーションを取り、チームの次の四半期の方向を設計した一日は、実際には非常に生産的な一日です。

フィードバックループの違い: 即座と長期

ICにとってフィードバックは速いものです。コードを書けばコンパイラが即座にエラーを教えてくれ、テストが通ったかどうかを示し、CI/CDパイプラインがデプロイの成功を確認してくれます。この即座のフィードバックはドーパミンをもたらし、学習を加速させます。

EMにとってフィードバックは遅いものです。今日行ったコーチングがメンバーの成長に表れるまで数週間から数か月かかります。今日設定したプロセスが効果を発揮するまで一四半期かかります。この遅れて届くフィードバックは不安と自己不信を招きます。

Michael Loppは『Managing Humans』（2016）で、このフィードバックの遅れこそ新任マネージャーが直面する最大の心理的課題だと指摘しています。

第2章: 役割転換を決める前に - 自己診断

なぜマネージャーになりたいのか

役割転換を決める前に、動機を正直に点検する必要があります。誤った動機でマネージャーになると、本人もチームも不幸になります。

健全な動機:

• 人の成長を助けることからエネルギーを得られる
• チーム全体の成果を引き上げることに関心がある
• 技術的な問題よりも組織的な問題に強く惹かれる
• コミュニケーションと調整の仕事を楽しめる
• より広い範囲の影響力を持ちたい

危険な動機:

• 「マネージャーにならないと昇進できないから」（組織構造の問題）
• 「より高い年収を得たいから」（ICトラックでも可能な場合が多い）
• 「コーディングに飽きたから」（マネジメントは代替にならない）
• 「権限を持ちたいから」（サーバントリーダーシップと相反する動機）
• 「次の等級がマネージャーだから」（キャリアパスの再設計が必要かもしれない）

ICトラックとEMトラックの比較

Staff+ EngineerとEngineering Managerの選択基準

この選択は「より高い等級」と「より低い等級」の問題ではありません。根本的に異なる二つの専門性のあいだの選択です。

Staff+ Engineerが向いている人:

• 技術的な問題解決から最も大きなエネルギーを得る人
• 深い集中時間がないと不幸になる人
• 技術的な影響力で組織を変えたい人
• コードとシステムが自分の「作品」だと感じる人
• 対人的な対立の解消よりも技術的な挑戦を好む人

Engineering Managerが向いている人:

• 人が成長するのを見てエネルギーを得る人
• ミーティングと対話がエネルギーを消耗させない人
• 組織のシステムとプロセスを設計することに関心がある人
• チームの成果を自分の成果だと感じる人
• 曖昧な人間関係の問題に忍耐強く向き合える人

第3章: 最初の100日ロードマップ

1〜30日: 傾聴と関係構築

最初の一か月の目標は観察し、聞き、理解することです。変化を起こしたい誘惑をこらえる必要があります。

すべてのメンバーと1対1を行う

最初の2週間のうちに、すべての直属メンバーと最低30分以上の1対1を実施します。次のような質問を活用してください。

• 「このチームで一番良いところは何ですか」
• 「一番不満なところ、改善したいところはありますか」
• 「前のマネージャーからもっと受け取りたかったものはありますか」
• 「いま取り組んでいる仕事で一番楽しみなことは何ですか」
• 「私はあなたをどう助けられますか」
• 「半年後、一年後の目標は何ですか」

既存のプロセスと文化を観察する

ステークホルダーマップを作る

チームが関わるすべてのステークホルダーを把握します。

• 上位: 自分のマネージャー、ディレクター、VP
• 同僚: 他チームのEM、PM、デザイナー
• 下位: 直属のメンバー
• 外部: 顧客、パートナー、ベンダー

それぞれとの関係の状態、期待されていること、主要なコミュニケーションチャネルを記録します。

31〜60日: 小さな改善と信頼の獲得

二か月目の目標はクイックウィンを通じて信頼を築くことです。

クイックウィンの特定と実行

最初の一か月の観察で見つけた小さな問題のうち、素早く解決でき、チームにすぐ良い影響を与えるものを選びます。

クイックウィンの候補例:

• 不要なミーティングの削除または最適化
• 開発環境の改善（ビルド時間の短縮、ツールのアップグレード）
• オンコールプロセスの小さな改善
• 技術的負債を返すための時間の確保
• ドキュメント習慣の改善

チームの最大の不満を解消する

1対1で繰り返し挙がった不満を整理し、最も多く言及されたものから解消します。「あなたの声を聞いている」というメッセージを行動で示すことが、信頼構築の核心です。

フィードバックループを作る

• 定期的な1対1のスケジュールを確立する（週1回、30分）
• チームのふりかえりを導入または改善する
• 匿名のフィードバックチャネルを運用する（アンケート、提案箱）

61〜100日: ビジョンと方向性の設定

三か月目から最後までの目標はチームの方向を定め、長期戦略を立てることです。

チーム目標を立てる

• 会社の戦略目標とチームの技術目標をつなぐ
• 測定可能な四半期目標（OKRまたは類似のフレームワーク）を設定する
• メンバーと一緒に目標を立て、当事者意識を高める

成長計画を立てる

• 各メンバーの強み、改善領域、キャリア目標を把握する
• 個人ごとの成長計画を一緒に作成する
• 成長の機会（挑戦的なプロジェクト、メンタリング、研修）を配分する

プロセスを改善する

最初の100日の観察をもとに、根本的なプロセス改善を始めます。

• コードレビュープロセスの最適化
• デプロイパイプラインの改善
• インシデント対応プロセスの整備
• 技術的負債の管理戦略の策定

100日ロードマップのまとめ

第4章: 最も難しい転換 - コーディングを手放す

メイカーのスケジュールとマネージャーのスケジュール

Paul Grahamは2009年のエッセイ「Maker's Schedule, Manager's Schedule」で、根本的に異なる二つの時間の使い方を区別しました。

メイカーのスケジュール:

• 最低4時間以上の連続した集中時間が必要
• 途中にミーティングが挟まると時間ブロック全体が壊れる
• 一度集中が切れると回復に30分以上かかる
• コーディング、執筆、デザインなどの創作活動に適している

マネージャーのスケジュール:

• 1時間単位のミーティングで一日が構成される
• ミーティングの合間に短い切り替え時間があれば足りる
• 多様な文脈を素早く切り替える能力が求められる
• 意思決定、コミュニケーション、調整に適している

ICからEMへ移ると、メイカーのスケジュールからマネージャーのスケジュールへの強制的な移行が起こります。これは単なる時間管理の問題ではなく、働き方そのものの根本的な変化です。

技術的貢献とマネジメントのバランス

多くの新任マネージャーが直面するジレンマが「どれだけコーディングを続けるべきか」です。

Charity Majorsはブログ記事「The Engineer/Manager Pendulum」（2017）でこう助言しています。

「マネージャーになったらコーディングをしてはいけない、という意味ではない。ただしクリティカルパス上のコーディングをしてはいけない。あなたがコードを手放してもチームが回らなければならない」

コーディングを続けてよい場合:

• 技術的な文脈を保つための小さな作業（バグ修正、ツールの改善）
• チームにブロッカーがなく、自分のマネジメント業務が終わっている状態
• クリティカルパス上にない、優先度の低い作業

コーディングをやめるべき場合:

• 自分がコーディングをするために1対1を延期または中止しているとき
• メンバーがやるべき仕事を自分が代わりにやっているとき
• 自分のコードレビューがボトルネックになりチームの速度を落としているとき
• コーディングがマネジメント業務からの逃避手段になっているとき

コーディングを手放すのが難しい理由

コーディングを手放すのが難しい理由は心理的なものです。

1. アイデンティティの危機: 「自分は開発者だ」というアイデンティティが揺らぎます。コーディングをしない自分はもうエンジニアではないような感覚になります
2. 統制感の喪失: コードは予測でき統制できますが、人はそうではありません
3. 即座の報酬の不在: コードを書けばすぐ結果が見えますが、マネジメントの結果はゆっくり現れます
4. 能力への不安: 新しい領域での不足と、コーディングでの自信との落差
5. 技術的貢献への未練: 「自分が直接やればもっと速く上手くできるのに」

これらの感情はすべて自然なもので、時間が経つにつれて新しい形の満足感に置き換わっていきます。メンバーの成長、チームの達成、組織の変化から来る満足感は、コード1行の満足感とは質的に異なりますが、十分に深く意味のあるものです。

第5章: よくある失敗とアンチパターン

アンチパターン1: 「自分ならもっとうまくやれる」の罠（マイクロマネジメント）

症状: メンバーのコードを見て「自分ならこうしなかった」と考えてしまいます。プルリクエストに細かなスタイルの指摘を20件も残します。メンバーが書いた設計書を自分で書き直します。

原因: ICとしての技術的な誇りと、マネージャーとしての統制欲求が結びついた状態。コーディングから得ていた満足感を別の形に置き換えられていません。

解決: 「自分の期待の80%を満たせば十分だ」という原則を立てます。メンバーのやり方が自分と違うからといって間違っているわけではありません。結果ではなく方向だけを設定し、実行はメンバーに任せます。

アンチパターン2: すべての技術的決定に介入する

症状: すべての技術議論に参加します。アーキテクチャの決定、ライブラリの選定、変数名まで自分が最終承認します。メンバーがマネージャーの承認なしには何も決めなくなります。

原因: 技術的な統制力を保ちたいという欲求。「自分が抜けたら誤った決定が下される」という恐れ。

解決: Camille Fournierは『The Manager's Path』で「決定の委譲マトリクス」を提案しています。

アンチパターン3: メンバーの成長機会を奪う

症状: 技術的に挑戦的なプロジェクトが来ると自分でやってしまいます。重要な発表やステークホルダーとの会議にはいつも自分が出ます。メンバーに「これは自分がやる」とよく言ってしまいます。

原因: 技術的貢献への郷愁。メンバーの力量への不信。自分の価値を技術的貢献で証明したいという欲求。

解決: 「この機会をメンバーに渡したら、誰が一番成長するだろうか」をまず考えます。自分がやりたい仕事をメンバーに任せ、代わりにコーチングと支援に集中します。Zhuoはこれを「自分の代わりを育てること」と表現しました。

アンチパターン4: 対立を避ける

症状: メンバー同士の対立を目にしても気づかないふりをします。成果の低いメンバーにフィードバックを渡しません。難しい会話を延ばし続け、「時間が経てば解決するだろう」と考えます。

原因: 対人的な対立への居心地の悪さ。「良い人」でいたいという欲求。対立を解消した経験の不足。

解決: 対立は無視すれば悪化します。Michael Loppは『Managing Humans』で、難しい会話を先延ばしにするほど、その会話はさらに難しくなると警告しています。問題が小さいうちに素早く話すことが核心です。

アンチパターン5: 全員を幸せにしようとする

症状: あらゆる依頼に「はい」と答えます。相反する要求のあいだで優先順位を決められません。全員の期待に応えようとして、誰の期待にも応えられなくなります。

原因: 断ることの難しさ。対立回避のもう一つの形。「良いマネージャーとはすべての依頼を受け入れるマネージャーだ」という誤解。

解決: 「全員を満足させることは不可能だ」と受け入れます。代わりに意思決定の過程を透明に共有します。「この決定に同意できないかもしれませんが、なぜこう決めたのかを理解していただけると嬉しいです」という姿勢が、長期的にはより大きな信頼を築きます。

アンチパターン総合セルフチェック表

第6章: 中核スキルの開発

スキル1: 1対1ミーティングの運営

1対1はマネージャーの最も重要な道具です。うまく運営された1対1は、メンバーの成長、動機づけ、問題解決の中心的なチャネルになります。

1対1の構成:

1対1で尋ねるべき問い:

• 「今週いちばん大変だったことは何ですか」
• 「私が助けられるブロッカーはありますか」
• 「いまの仕事から学んでいることはありますか」
• 「チームで改善したいことはありますか」
• 「この数か月で試してみたいことはありますか」

1対1でしてはいけないこと:

• ステータス報告だけに時間を使うこと（それはスタンドアップや非同期の更新で行う）
• マネージャーだけが話すこと（聞く時間と話す時間の比率は最低でも60対40）
• 頻繁に中止したり延期したりすること（メンバーに「あなたは優先度が低い」と伝えてしまう）

スキル2: 評価とフィードバック

効果的なフィードバックのSBIフレームワーク:

評価を書くときのコツ:

1. 評価期間の全体をカバーする（直近の一か月ではなく期間全体）
2. 具体的な事例とデータに基づく
3. 強みと改善領域の両方を含める
4. 次の期間の期待値を明確にする
5. メンバーのキャリア目標と結びつける

スキル3: 採用と面接

良い採用は、マネージャーができる最も影響力のある決定の一つです。

面接評価マトリクス:

スキル4: ステークホルダー管理

EMはチームの内側だけでなく、外部のステークホルダーとのコミュニケーションも管理する必要があります。

ステークホルダー別のコミュニケーション戦略:

スキル5: プロジェクト管理

技術プロジェクトの成否は、リスクをどれだけ早く見つけて対応できるかにかかっています。

プロジェクト健全性チェックのフレームワーク:

第7章: バーンアウトの予防とセルフケア

EMのバーンアウトが特別な理由

ICのバーンアウトが主に技術的挑戦の過負荷から来るのに対し、EMのバーンアウトは感情労働の過負荷から来ます。

マネージャーは毎日ほかの人の問題を聞き、対立を解消し、悪い知らせを伝え、場合によっては解雇を決めなければなりません。そのすべてが感情的なエネルギーを消耗させます。

EMのバーンアウトの前兆:

セルフケアのチェックリスト

毎日:

• 一日のうち最低1時間、邪魔されない時間を確保する
• 昼食の時間にミーティングを入れない
• 一日の終わりに「今日うまくできたこと」を一つ書き留める

毎週:

• 同僚のマネージャーとの非公式な対話（互いの悩みを共有する）
• 自分のマネージャーとの1対1で状態を正直に共有する
• 運動や趣味の時間をカレンダーにブロックする

毎月:

• 自分のエネルギー水準を1から10で評価する
• 「今月いちばん自分を消耗させたもの」を特定して対応を計画する
• マネージャーという役割への満足度を正直に点検する

四半期ごと:

• キャリアの方向性を見直す
• マネジメントに関する学習（本、講演、ワークショップ）
• 仕事の外の人間関係に投資する

第8章: ICに戻ってもかまわない - 役割転換の可逆性

エンジニア・マネージャーの振り子

Charity Majorsは有名なブログ記事「The Engineer/Manager Pendulum」（2017）で、革命的な視点を示しました。

「最も効果的なリーダーは、ICとマネージャーのあいだを行き来した経験を持つ人だ。片側にとどまり続けるより、両側を経験するほうが価値がある」

この振り子という考え方は、ICからEMへの転換が一方向のドアではないことを強調しています。

EMからICに戻ることに価値がある理由

戻るときの注意点

1. プライドを手放す必要があります: 「マネージャーからICに戻ることは降格だ」という受け止めがあるかもしれません。しかしこれは別の専門性への転換です
2. 技術的なギャップを認める必要があります: EMの期間に技術的な深さが減っている可能性があります。謙虚に学習モードに戻りましょう
3. マネージャーの習慣を手放す必要があります: 「チームを率いようとする」習慣は、ICの役割では抑える必要があります
4. 組織の支援が必要です: ICへの移行をやりやすくする組織文化が重要です

役割選択の意思決定フレームワーク

定期的に（年1回程度）、自分に次の問いを投げかけてみてください。

第9章: チェックリスト - EM転換後100日のセルフチェック

最初の30日の点検

• すべての直属メンバーと最初の1対1を終えたか
• チームの現在のプロセスと文化を文書化したか
• ステークホルダーマップを作成したか
• 自分のマネージャーと期待値をすり合わせたか
• メンバーの名前、役割、強み、関心を把握したか
• 大きな変化を試みたい誘惑をこらえたか

31〜60日の点検

• 定期的な1対1のスケジュールが確立されたか
• 最低一つのクイックウィンを達成したか
• メンバーから初期のフィードバックを集めたか
• チームの主要なブロッカーを把握し解消を始めたか
• ステークホルダーとのコミュニケーションチャネルができたか
• コーディングの比重を適切に調整できているか

61〜100日の点検

• チームの四半期目標が立てられたか
• 各メンバーの個人の成長計画があるか
• プロセス改善が一つ以上実行されたか
• メンバーが自律的に意思決定をしているか
• 自分のエネルギー水準とバーンアウトのリスクを点検したか
• マネージャーという役割への満足度を正直に評価したか

100日以降の長期点検

• チームの生産性と品質が維持または向上したか
• メンバーの成長速度が加速したか
• チーム内に心理的安全性が確保されたか
• 自分がいなくてもチームがうまく回るか
• この役割で継続的な学習と成長ができているか
• いまもこの役割が自分に合っていると感じるか

第10章: 実践的なフレームワークとテンプレート

1対1ミーティングのメモテンプレート

週次チーム状況報告テンプレート

新任マネージャーの90日学習計画

結論: 転換は旅である

ICからEMへの転換は100日で「完了」するものではありません。それは継続的な学習と適応の旅です。

この旅で覚えておきたい中核的な原則を整理します。

1. 謙虚に始めましょう: 最初の一か月は聞き、観察し、理解する時間です。変化は理解が十分になってから試みます
2. コードを手放す練習をしましょう: コーディングへの未練は自然ですが、マネジメントに集中しなければ両方で失敗します
3. 人に投資しましょう: メンバーの成長こそマネージャーの最も重要な成果物です
4. 自分自身をいたわりましょう: 感情労働の重さを過小評価してはいけません。バーンアウトはチーム全体に影響します
5. 戻れることを覚えておきましょう: EMが合わないならICに戻ることは失敗ではなく賢明な選択です

Charity Majorsが言うように、最も効果的な技術リーダーはICとEMの両方を経験した人です。どちらを選んでも、その経験が無駄になることはありません。

「マネジメントはそれ自体に報いのある仕事だ。ただしそれはコーディングとはまったく異なる種類の報いである。二つの報いはどちらも価値がある」 - Camille Fournier, The Manager's Path

役割転換を目前にしたすべてのエンジニアへ、そしてすでに転換のただなかにいるすべての新任マネージャーへ。不安は自然なものです。完璧でなくてもかまいません。大切なのは、毎日少しずつより良いマネージャーになろうと努めることです。

参考資料

1. Camille Fournier, The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change (2017) - ICからCTOまでのキャリアパスに関する総合的なガイド
2. Will Larson, An Elegant Puzzle: Systems of Engineering Management (2019) - エンジニアリングマネジメントにシステム的に取り組む方法論
3. Julie Zhuo, The Making of a Manager: What to Do When Everyone Looks to You (2019) - 新任マネージャーのための実践的なガイド
4. Paul Graham, "Maker's Schedule, Manager's Schedule" (2009) - メイカーとマネージャーの時間の使い方の根本的な違い
5. Michael Lopp, Managing Humans: Biting and Humorous Tales of a Software Engineering Manager (2016) - ソフトウェアエンジニアリングマネジメントの人間的な側面
6. Charity Majors, "The Engineer/Manager Pendulum" (2017) - ICとEMのあいだの役割転換についての新しい視点
7. Kim Scott, Radical Candor (2017) - 率直でありながら思いやりのあるフィードバックの方法論
8. Lara Hogan, Resilient Management (2019) - マネージャーとしての回復力とチームの運営