海外企業に入社したら何から始める？最初の90日の確認・相談・仕事の進め方

初日は会社の計画と、確認先をそろえる

まず、人事から届いた案内、上司の予定、社内の手引きを並べます。出社場所や接続方法、研修、使う道具、連絡窓口のうち、分かっている項目を確認しましょう。別の会社で使った90日計画を、そのまま自分の職場へ持ち込む必要はありません。

英国のAcasは、受け入れる人の経験や勤務地に合わせて導入計画を調整し、初日以降に役割・期待・研修を説明することを勧めています。これは雇用主向けの実務案内です。本記事では、入社する側が「どの説明を受けたか、何が未確認か」を整理する参考として使います。参考：Acasの導入計画ガイド

企業ごとの違いもあります。GitLabの公開ハンドブックでは、共通の導入タスクと部門・役割ごとのタスクを分け、質問やIT支援の窓口を案内しています。同社の運用は一つの例であり、すべての海外企業に同じ研修や窓口があるとは限りません。参考：GitLab Onboarding

案内を読んだら、空白のままの項目を質問する

確認メモには「決まっている」「未確認」「自分では決めない」を文字で記します。たとえば「研修の時間は決まっている」「仕事で使う資料へのアクセスは未確認」「研修を欠席して業務を優先するかは自分では決めない」という具合です。色を使う場合も、この言葉を添えれば、白黒のメモでも区別できます。

• 予定：どの研修や打ち合わせが必須か。業務と重なったら誰に相談するか。
• 道具：必要な資料を開けるか。会社が認めた保存場所や共有方法はどれか。
• 連絡：通常の質問、急ぎの相談、欠勤などで使う窓口はどこか。
• 働く時間：自分の勤務時間、相手と話せる時間帯、返答が必要なときの伝え方は何か。

リモート勤務なら、予定の時刻がどの地域のものかも確認します。会社のカレンダー表示を確かめ、不明なら日付とタイムゾーンを添えて聞きましょう。後から参照できる場所も残しておきます。

最初の仕事を、完成条件まで具体化する

「早く戦力になる」は気持ちとしては自然ですが、そのままでは今日の作業を決められません。「何を作り、誰に見てもらい、どの状態になれば一区切りか」まで言葉にしましょう。初回の担当は、確認を受けられる範囲に区切って相談します。

ここからの架空ケースでは、Akiに日本での仕事経験があり、海外企業の多国籍チームへ入社したとします。最初の2週間には会社の共通研修があります。上司Morganは優先順位と完成判断、同僚Leeは資料の場所や日常の進め方、IT窓口はアクセスの不具合を担当します。Akiの最初の仕事は、社内向けのチーム業務紹介1ページの更新です。

Akiと上司が確認した「最初の仕事」のメモ

何のために作るか

社内の同僚が、このチームの担当範囲と、質問を送る先を把握できるようにする。

何を渡すか

既存の業務紹介1ページを直した下書き。新しい制度や別のサイトは作らない。

入れる内容

担当業務3項目、相談先2役割、最新手順への参照。役割名や参照先は関係担当に確かめる。

今回の範囲に入れないこと

新制度の決定、顧客情報の追記、外部公開。分からない内容を推測で埋めない。

誰が確認するか

Morganが全体を承認する。相談先の記載は、その役割の担当者にも確認してもらう。

いつ、どの状態を見せるか

この例では入社22日目に下書きを確認してもらうと合意。会社の研修と必要な資料へのアクセスを前提にする。

何をもって完了にするか

内容の確認と承認を受け、指定の社内ページへ反映されたことを確かめる。Akiに反映権限がなければ、担当者へ依頼して反映結果を確認する。

まだ決まっていないこと

参照する手順書の最新版。確定するまでは該当箇所を保留し、確認先と次の確認日を記録する。

このメモの要点は、下書きを渡す日と、仕事全体の完了を分けていることです。22日目は教材上の設定で、一般的な目標日ではありません。実際には研修予定、担当業務の難しさ、確認者の予定を見て決めます。

Akiの初週・30日・60日・90日の記入例

以下は、Akiが各時点で記録を更新したという設定の完成見本です。実際に90日間の観察を行った結果ではありません。日数ごとの達成基準として採点するためではなく、行動、確認相手、判断の証拠、未確認事項、次の見直しを同じ場所に残す書き方として使ってください。

初週の記録：分からないことを、確認先につなぐ

仕事の前提

共通研修は2週間。研修と別の仕事が重なったらMorganに優先順位を相談する。

自分がしたこと

初日の案内と端末の受領を照合。Leeと資料の置き場所を確認し、業務紹介ページを読んだ。アクセス待ちによる仕事への影響はMorganへ共有した。

確認相手

研修予定は人事、役割はMorgan、資料の場所はLee、開けない資料はIT窓口。

判断の証拠

受領済みの案内、開けた資料の一覧、質問メモ。研修は一部受講済みで、全体は未完了。

未確認事項

最新手順の保存場所へのアクセス。ITへ依頼したが、まだ開けない。

次の見直し

入社8日目にITの受付状況を確認し、進展をMorganに共有する予定。

「資料を読んだ」だけで終わらせず、どの資料は見られて、どの資料は見られないかを残します。アクセス待ちは本人の学習不足と混ぜず、作業の前提がそろっていない状態として扱います。

30日目の記録：下書きの完成と、仕事全体の完了を分ける

仕事の前提

共通研修を終え、参照資料へのアクセスも解決。更新範囲と22日目の下書き確認をMorganと合意した。

自分がしたこと

合意した内容で下書きを提出。Morganの指摘を受け、担当業務の説明を修正した。

確認相手

全体の確認はMorgan。相談先のうち一つは、該当担当からの回答を待っている。

判断の証拠

合意メモ、提出した下書き、Morganの修正指摘と修正版。

未確認事項

相談先1役割の記載。最終承認と社内ページへの反映は、まだ終わっていない。

次の見直し

33日目に回答状況を確認する予定。反映日は承認後に相談する。

この時点で報告できるのは「下書きを提出し、指摘を反映した」という事実です。「ページ更新を完了した」とは書きません。

60日目の記録：同じ手順を使い、変わった条件を確かめる

仕事の前提

最初のページは関係担当の確認とMorganの承認を経て、担当者が社内へ反映。Akiも反映先を確認した。

自分がしたこと

その後に依頼された、同じページの手順リンク差し替え案を作成。前回の指摘を読み、変更箇所を示した。

確認相手

手順の担当者に最新版を確認し、Morganへ変更案を提出した。

判断の証拠

初回の承認記録と反映先、今回の変更前後を並べたメモ、確認依頼。

未確認事項

2回目の変更案は承認待ち。前回の承認を、今回の変更への承認として使わない。

次の見直し

62日目に確認状況を見直す予定。次の担当範囲は、今回の確認後に相談する。

繰り返しの仕事では、前と同じ部分と、新たな判断が必要な部分を見分けます。経験が増えても、社内情報を公開できる範囲や、誰が承認するかを本人の判断で広げないようにします。

90日目の記録：できた仕事と、引き続き支援が要る仕事を分ける

仕事の前提

2回目の変更も承認・反映を確認済み。今回はMorganとの振り返りで、次に担当する範囲を相談する。

自分がしたこと

初回と2回目の記録を並べ、資料の探し方、変更案の作り方、確認依頼を振り返った。

確認相手

Morganと、次の更新でも承認を受ける運用を確認した。

判断の証拠

承認済みの2件の記録と、振り返りの合意メモ。

未確認事項

複数の資料で担当範囲が食い違う場合の判断は、まだ支援が必要。独断では直さない。

次の見直し

次回更新で参照元と相違点を整理し、Morganに判断を頼む。14日後にその進め方を見直すと合意した。

この例で示せるのは、どの作業をどの確認を経て終えたかです。作業時間の短縮、評価の向上、昇進への効果は測っていません。90日目に未完了の仕事があっても、現在の状態と必要な支援を具体的に話すことはできます。

営業・接客・事務の仕事へ読み替える例

以下は編集部による架空の読み替え例です。Akiの「業務紹介ページ」を別の成果物に置き換え、何を作り、誰に確認し、次に何を見直すかを考えます。30日・60日・90日ごとの達成基準ではありません。

• 営業：最初の成果物を、商品一つの説明メモに置き換えます。この例では上司に提供範囲と伝えてよい条件を確認し、次の説明後に、答えを保留した質問と追加の確認先を記録します。
• 接客：問い合わせ一件の返信案に置き換えます。この例では責任者に事実関係と案内する対応を確認し、対応後には、解決を確認できたことと未解決事項を分け、引き継ぎ先を記録します。
• 事務：定例報告一回分の集計案に置き換えます。この例では報告の責任者に対象期間・集計範囲・未提出分を確認し、次回は同じ手順で作れた部分と、条件が変わって再確認が必要な部分を残します。

初週は担当する仕事と確認先をそろえ、その後は「進めたこと・証拠・未確認事項・次の確認日」を更新します。見直す日は勤務先の計画と相談して決め、日数だけで担当範囲を広げないようにしましょう。

英語で確認し、合意した内容を残す

何を確かめたいかを絞り、相手の回答を受けて足りない条件を具体化します。以下はAkiの仕事に合わせた作例です。

この会話の時点では、日付はまだ決まっていません。Akiの記録では、その後に22日目で合意した設定です。相談中の案を「決定事項」として書かず、合意してからメモを更新します。聞き取れなかった場合は、難しかった一部分を指定して言い換えを頼んでも構いません。

Could you clarify what you mean by “ready for review”?
「確認できる状態」とは、具体的にどこまでできた状態か教えてもらえますか。

30日目の報告では、判断を頼みたい点を添える

「day 33」は教材の入社日基準の表記です。実際の連絡では、関係者が分かる具体的な日付に置き換えてください。完了した作業、残っている確認、相手に頼む判断が別々に伝われば、長い英文にする必要はありません。状況別の書式を増やしたい場合は、英語の進捗報告の書き方と例文も参考になります。

予定どおりに進まないときの相談先

困りごとをすべて上司にまとめて送ると、専門窓口への依頼が遅れることがあります。一方、同僚が作業を教えてくれたからといって、その同僚が優先順位や公開の可否を決められるとは限りません。「何を教えてほしいか」と「誰に判断してほしいか」を分けましょう。

7日目にも資料を開けない場合

Akiの初週の記録には、未付与の閲覧権限が残っています。まず、会社が指定するIT窓口へ、対象の資料、起きている状況、依頼済みなら受付番号を伝えます。ログイン情報や不要な機密情報を送らず、画面の共有が必要な場合も会社の手順に従います。

同時にMorganへ「最新版を確認できないので、該当箇所の下書きは進められない」と影響を伝えます。解決時刻が不明なら、完成日を新たに約束せず、いつ状況を再確認するかを伝えましょう。

修正版のメモは「保留：最新版の確認」「先に進める：利用できる研修」「次の確認：8日目にITの受付状況を確認」「上司への依頼：アクセス解決後に下書き確認日を相談」と書けます。個人のメールへ資料を転送してもらう、同僚のアカウントを借りる、といった回避策は使いません。

指示が曖昧、または確認相手が休みの場合

「いい感じに整えて」と言われたら、いきなり全面改訂をせず、「相談先と手順リンクの更新を先にし、構成は変えない理解でよいですか」と、変更する範囲を示して確かめます。確認者が休みなら、締切への影響と代わりの確認者の有無を相談します。返答がないことを、承認されたこととして扱わないようにします。

GitLabは、入社支援を担うバディに、手引きの案内、定期的な確認、必要な専門家への接続を勧め、不在時の代わりの支援者にも言及しています。バディ制度がない職場でも、「この人がいないときは誰へ聞くか」を確認する参考になります。参考：GitLab Onboarding Buddies

振り返りでは、次に必要な支援も決める

振り返りには、作ったものと確認の記録を持っていきます。「少し慣れました」だけでなく、どの仕事なら同じ手順で進められるか、どの判断では支援が必要かを具体的に話しましょう。Acasも、定期的な対話やフィードバックに加え、経験を得た後に、追加の研修や疑問を話すレビューを勧めています。参考：Acasのレビューに関する案内

Akiなら「前回の指摘を参照して変更案を作ることはできる。複数の資料で担当範囲が違う場合は、どれを正とするか判断が必要」と伝えます。相手に尋ねるのは、次に任せる範囲、残す確認工程、追加で学ぶ内容です。担当を増やすかどうかを一人で決めず、次の仕事について合意を更新します。

For the next update, which parts can I handle on my own, and which parts should I bring to you for review?
次の更新では、どの部分は自分で進めてよく、どの部分はあなたに確認をお願いすべきですか。

質問しやすい関係も、日々のやり取りから作っていけます。答えてもらったあとに、何が解決したかを短く伝えると、次回も同じ前提から話せます。たとえばLeeには「教えてもらった保存場所で資料を見つけられました。最新版の判断は担当者に確認します」と返せます。交流会への参加数や、雑談の上手さだけを人間関係の目標にする必要はありません。

自分の初週に置き換える練習とメモ

記事を読み終えたら、Akiの仕事を自分の最初の担当に置き換えましょう。予定表を細かく埋める前に、最初に確かめたい仕事を一つ選びます。まだ担当が決まっていなければ、「最初に何を担当するかを上司へ確認する」を次の行動にできます。

練習1　3つの困りごとを、相談先へ振り分ける

1. 研修の時間と、急ぎの資料修正の依頼が重なった。
2. 紹介ページは読めるが、普段どの場所から探すのか分からない。
3. リンク先でアクセス拒否が表示され、参照資料を読めない。

このケースでの解答例：1はMorganへ優先順位を相談します。2はLeeへ資料の探し方を聞きます。3はIT窓口へ状況を伝え、業務への影響がある場合はMorganにも共有します。相談先は会社ごとに違うため、役職名を暗記するより、判断・案内・不具合対応のどれが必要かを見分けてください。

練習2　「早く戦力になる」を、確認できる一文に直す

書き換え例：「共通研修後の最初の担当として、業務紹介ページの更新案を作ることをMorganに相談する。含める内容、確認者、下書きを見てもらう日を確認し、未確定の参照資料は保留として残す」。まだ相談前なら、「作ることが決まった」とは書きません。

答えを見直すときは、成果物、確認相手、未確認点が具体的かを確認します。ページを作れば評価が上がる、と結論にしていないことも大切です。仕事内容が違っても、「受け取った資料の照合」「問い合わせへの回答案」「定例報告の一部分」など、自分の担当成果に置き換えられます。

本人用メモ　最初の確認から、次の見直しまで

メモは会社が認める場所に保管し、会社が許可していない社外サービスへ業務情報を持ち出さないようにします。最初からすべての欄を埋める必要はありません。空白を見つけたら、次に誰へ聞くかを書く。回答を得たら、合意した内容へ更新する。この繰り返しで、最初の仕事を進めるための手がかりを増やしていきましょう。

参考資料と読み方

公開資料の確認日：2026年10月9日。下記は導入支援の実務や企業の運用例を知るための資料です。各国の法令や雇用条件を解説する記事ではなく、会話・記入例・図は編集部による応用です。

• Acas：Planning an induction programme。役割・期待・研修・振り返りを確認する考え方の参考。英国の案内を他国の義務へ一般化しないでください。
• GitLab Handbook：GitLab Onboarding。共通・役割別の導入タスクと相談窓口の企業例。
• GitLab Handbook：GitLab Onboarding Buddies。資料案内や専門家への接続、不在時の支援の企業例。