海外転職で専門職とマネージャーのどちらを目指す？得意な仕事から考える方法

こんにちは、Kredo Blog編集部です。

専門職とマネージャーを、仕事と責任で比べる

この記事では、専門職を「主に専門性を通じて成果を出す役割」として整理します。ここでいうマネージャーは、人の育成・配置・評価などの責任を担う役割です。海外企業の求人には、前者をIndividual Contributor（IC）、後者をPeople Managerと表す例があります。ただし、専門職とICは完全な同義語ではなく、ICが必ず高度専門職や特定の役職を指すわけでもありません。

また、Managerという肩書きでも直属の部下がいない職種があります。プロジェクトの納期や関係者調整を担う仕事と、技術的な判断をリードする仕事は異なります。人の評価や育成に責任を負う仕事も、分けて確認しましょう。同じ人が兼ねる場合もありますが、名称だけでは判断できません。

ICにも戦略づくり、指導、部門間の調整が求められることがあります。マネージャーにも、専門分野を理解して判断する力が必要な役割があります。「人と話すのが得意だから管理職」と性格だけで分けると、実際の仕事を見落としかねません。「一人で集中したいから専門職」とも限らないのです。

管理職に求められる責任が広くても、採用や評価の最終決定を一人で行うとは限りません。誰が提案し、誰が決め、誰が本人に説明するのかまで確認すると、引き受ける範囲が具体的になります。

専門知識を深めたい気持ちと、人の成長を支えたい気持ちが両方あっても構いません。この段階で一生の進路を決める必要はありません。ただし、入社後に自由に経路を変更できるとも限らないため、会社の制度や空いている役割を確認します。

公開されている役割定義から、何を読み取るか

会社が公開するキャリアフレームワークは、仕事の違いを調べる入口になります。以下はソフトウェア開発領域の企業例です。営業、研究、デザインなど、別職種や別企業の標準として当てはめることはできません。応募先の最新の職務記述書と照らし合わせてください。

GitLabの例では、ICにもリーダーシップがある

GitLabのEngineering IC Leadershipの説明には、技術的な問題の解決や、再利用できる仕組みづくりが挙げられています。知識共有や、周囲の仕事を進めやすくする貢献もその一つです。一方、同社のEngineering Managerの役割定義では、人の成長、チームの運営や採用などに関わる責任を確認できます。マネージャーにも技術的な信用や理解が求められるため、「専門性を使うか、人と関わるか」の二択にはなりません。

同社のEngineering Career Developmentでは、SeniorからStaffやEngineering Managerへ進む条件を説明しています。役割の必要性に加え、その仕事を担えることを示す経験が求められます。経験を積めば希望する役割が自動的に用意される、と読まないことが重要です。

Dropboxの例では、影響の範囲と仕事の進め方を読む

Dropboxの公開Engineering Career Frameworkは、レベルごとの期待と、役割ごとの行動を分けて整理しています。同資料は、昇進のチェックリストではありません。資料の冒頭にも、この位置づけが明記されています。

たとえば、同社のIC5 Staff Software Engineerには、複数チームにまたがる技術方針や、他のエンジニアの育成が含まれます。M3 Engineering Managerの仕事の例は、上司の支援を受けたチーム運営や、上司と相談したうえでの担当配置です。これは仕事の種類を知るための例で、IC5とM3が同じ等級・待遇だという比較ではありません。

肩書きだけを他社と対応させず、担当する課題と協働する相手の範囲を読みましょう。そのうえで、何を変えることが期待されているかを確かめます。資料に列挙された行動をこなすだけで昇進できる、という使い方は避けます。

上記は2026年10月30日に確認した公開資料の例です。公開版と実際の募集・社内運用が一致するとは限りません。すべての海外企業に、専門職と管理職の二つの経路があるわけではありません。役職名、等級、評価、報酬や異動の条件も異なります。

最近の仕事から、増やしたい業務を見つける

「どちらが向いているか」を今すぐ決める代わりに、最近担当した仕事をいくつか書き出してみてください。うまくいった仕事だけでなく、負担が大きかった仕事も材料になります。忙しさや人手不足が原因なのか、その業務自体への関心が薄いのかは分けて振り返りましょう。

成果、やりたい気持ち、未経験を分けて書く

例えば「後輩に教えるのが好き」なら、何を教え、相手がその後どう仕事を進められるようになったかを思い出します。その経験でわかるのは、説明や支援の一場面です。評価へのフィードバック、業務配分、不調時の対応まで担いたいかは、別に確かめる必要があります。

専門職側も「分析が得意」だけで止めず、力を発揮した場面を分けます。課題の定義、分析方法の選択、結果の説明、他部署との調整などを振り返りましょう。自分で作業を完結させる楽しさと、専門判断を周囲に採用してもらう仕事への関心は、重なることも異なることもあります。

• 実際にできたこと：状況、自分の担当、判断、相手や業務に起きた変化。
• 今後増やしたいこと：もう一度引き受けたい具体的な業務と、その理由。
• 負担だった条件：割り込み、曖昧な権限、準備不足、言語など、業務以外の要因も含む。
• まだわからないこと：担当したことがない仕事、結果を追えていない支援、応募先の運用。

「得意」「やりたい」「経験がある」は別々に書くと、練習すれば広げられそうなことも見つけやすくなります。今の苦手さを固定的な適性と決めつけたり、項目数に点数をつけて結論を出したりする必要はありません。

現在の管理職の負担を先に整理したい場合は、管理職を辞めたいと感じたときの考え方も参考になります。そのうえで、転職先ではどの仕事を続け、何を変えたいかを具体化しましょう。

権限を確認して、小さく試す

試行は、今の上司や関係者と目的・担当範囲・終える時点・振り返り方を合意してから行います。現職の仕事に一方的に新しい責任を加えたり、同僚を進路選びの実験台にしたりしないことが前提です。余力がなければ、実務を増やさず架空のケースを使った練習から始められます。

• 専門性を広げる試行：許可された小さな課題について、複数の案と判断理由を整理し、関係者のレビューを受ける。専門的な正しさに加え、説明や合意形成も振り返る。
• 人を支える仕事を知る試行：了承を得た範囲で、オンボーディング資料の改善や業務計画の整理を担当する。相手の理解や負荷を確認し、上司と支援の仕方を振り返る。
• 経験できない責任を調べる：管理職への一般的な仕事内容の質問や、架空のフィードバック面談の練習を行う。実在の部下の評価、給与、健康などの情報を持ち込まない。

メンタリングや一時的なプロジェクトの取りまとめは、人を支える経験になります。ただし、それだけで採用・人事評価・処遇の権限が与えられるわけではありません。試行で経験したことは、その範囲で記録します。「育成資料の改善を担当した」を「部下の育成・評価を管理した」に広げないようにしましょう。

終わったら、成果物だけでなく、自分が判断した点と相手から受けた具体的な指摘を残します。時間の使い方や、もう少し経験したい業務も振り返りましょう。記録先は会社が認める場所にし、転職用に持ち出す資料や実績の説明には、機密・個人情報・開示権限の確認が必要です。名前を消すだけで外部共有できるとは限りません。

仕事の結果を記録する方法は、海外企業の人事評価は何を見られる？目標設定と成果の残し方でも整理しています。応募先への説明では、担当範囲と確認できた成果を区別しましょう。

海外の応募先に確認したいこと

求人票を読んだら、希望する働き方と近いかを、採用担当者や将来の上司への質問に変えます。制度の有無に加え、そのチームで実際にどう使われているかも聞きましょう。肩書きからの推測を減らす手がかりになります。

1. 仕事の配分：最近の代表的な一週間は、専門作業、会議、調整、育成にどう分かれているか。繁忙期には何が変わるか。
2. 成果と経験：この職位で期待される成果は何か。応募時に必要な経験と、入社後に学べることはどこか。
3. 人への責任：直属の部下はいるか。目標設定、採用、評価、配置、処遇にどこまで関わり、誰が最終決定するか。
4. 支援と働く条件：相談相手、管理職研修、専門家のレビューはあるか。使用言語、時差、勤務場所が日常業務にどう影響するか。
5. 経路を変える条件：専門職と管理職の間で変更する制度や実例はあるか。応募・選考、必要な実績、空きポジション、等級の扱いはどう決まるか。

英語では、担当する仕事を先に確認する質問が役立ちます。次の文は編集部が作成した例です。

「入社して合わなければ戻ればよい」と考える前に、変更時の手続きと条件を確かめてください。制度があっても希望時点でポジションがあるとは限らず、元の職位・待遇に戻れるとも限りません。役職名の高さだけで報酬や将来の昇進を推測せず、具体的なオファーの条件は別途確認します。ここでの進路整理は、採用や就労・在留資格の取得を保証するものではありません。

架空のケースで考える次の一歩

以下は編集部が作成した架空例です。実在する人物の体験談や、適性診断の結果ではありません。

どちらの例も、結論は「今後確かめる仕事」を絞ったところまでです。一つの成功や苦手な場面だけで進路を固定せず、役割の情報と自分の経験を増やして判断します。

進路を決める前の記入メモ

次のメモを使って、仕事の具体例から一つずつ埋めてみてください。空欄は適性がない証拠ではなく、追加で調べたい点です。

最近の仕事と自分の担当

どんな課題で、何を自分が判断・実行したか。関わっただけのことと、責任を持ったことを分ける。

もう少し増やしたい仕事

専門的な判断、説明、合意形成、育成、業務配分など、実際の場面と言葉で書く。

負担だった仕事と条件

業務自体への関心、準備や支援の不足、権限の曖昧さなどを分ける。

候補の役割でまだわからないこと

日常の配分、成果への責任、必要経験、権限、支援、経路変更の条件。

次に確かめること

誰に何を聞くか、または合意を得て何を試すか。終えたときに何を振り返るか。

よくある質問

情報の確認日・出典

以下の公開資料は、2026年10月30日（日本時間）に確認しました。掲載された役割定義は企業ごとの例です。実際の募集状況や社内運用は、応募先へ確認してください。

• GitLab：Engineering IC Leadership — ICの専門性や周囲への貢献。
• GitLab：Engineering Manager — 人の成長やチーム運営への責任。
• GitLab：Engineering Career Development — 次の役割に進む条件。
• Dropbox：Engineering Career Framework — 公開資料の位置づけと使い方。
• Dropbox：IC5 Staff Software Engineer — 専門職の仕事の例。
• Dropbox：M3 Engineering Manager — 管理職の仕事の例。