エンジニアのオンボーディングチェックリスト｜30・60・90日プラン

エンジニアのオンボーディングとは、新しく加わったメンバーが「自分で課題を取り、コードを出し、チームの一員として動ける」状態になるまでを、受け入れ側が計画して支えることです。準備の大半は、本人が来る前に終えられます。

この記事は、受け入れる側（メンター・チームリーダー・管理者）が使う資料に絞っています。前任者から業務を渡すための引き継ぎ資料とは別のもので、ここで扱うのは「誰が・いつまでに・何を用意するか」です。入社前・初日・1週目・1か月のチェックリストを担当者と優先度つきで載せ、30・60・90日プランは役割別の記入例まで用意しました。例はすべて、架空の「備品予約システム」を開発するチームを題材にしています。

確認環境：チェックリストの表とタブ区切りテキストは同じデータから Python 3.11 で生成し、件数を数えています。確認日の計算も Python 3.11 で実行しました。Mermaid のフロー図は @mermaid-js/mermaid-cli 11.14.0 と Chromium で描画できることを確かめています。

オンボーディングの早見表

担当者と優先度の決め方

チェックリストは項目を並べるだけだと、「誰かがやるだろう」で残りがちです。この記事では、すべての項目に担当と優先度を付けています。

時間が限られるときは、必須の27項目だけを先に終える使い方ができます。担当別では、受け入れ側16項目、本人13項目、管理者11項目です。

時期別チェックリスト

入社前（12項目）

入社前の必須項目は、すべて受け入れ側と管理者の担当です。なかでも A-05（手順書を自分で1回通す） は効果が大きく、初日の環境構築で止まる時間をまとめて減らせます。

初日（10項目）

初日は詰め込みすぎないのがコツです。「全体像」「質問先」「明日やること」の3つが伝われば十分で、細かい仕様は1週目以降に回します。

1週目（10項目）

1か月（8項目）

表計算ソフトに貼れるタブ区切り版

次のブロックをコピーして、Excel や Google スプレッドシートのセル A1 に貼り付けると、6列の表になります（「完了」列は空欄です）。

時期  No  やること    担当  優先度 完了
入社前 A-01    受け入れ担当（メンター）を決め、本人とチームに伝える  管理者 必須  
入社前 A-02    PC・周辺機器を手配し、初期設定を済ませる   受け入れ側   必須  
入社前 A-03    アカウントを発行する（メール・チャット・予定表・ID管理）   管理者 必須  
入社前 A-04    権限申請一覧に沿って、リポジトリ・課題管理・ドキュメントの権限を申請する    受け入れ側   必須  
入社前 A-05    環境構築手順書を受け入れ側が自分で1回通し、動かない箇所を直す 受け入れ側   必須  
入社前 A-06    最初のプルリクエストに向く課題を2〜3件選んでおく   受け入れ側   必須  
入社前 A-07    1週目の日別スケジュールを作り、予定表に入れる 受け入れ側   必須  
入社前 A-08    初日の集合時刻・場所・持ち物を本人に連絡する  管理者 必須  
入社前 A-09    30・60・90日プランの下書きを作る 管理者 推奨  
入社前 A-10    チームに着任日・役割・担当予定の範囲を共有する 管理者 推奨  
入社前 A-11    最初に読む資料の一覧を1ページにまとめる    受け入れ側   推奨  
入社前 A-12    入社前に読める公開資料を案内する（読むかどうかは自由と明記）  管理者 任意  
初日  B-01    出迎えて、チームのメンバーを紹介する  受け入れ側   必須  
初日  B-02    PCを受け取り、ログインと多要素認証の設定を済ませる  本人  必須  
初日  B-03    チャット・メール・予定表にログインし、自己紹介を投稿する    本人  必須  
初日  B-04    システムの全体像を構成図1枚で30分説明する  受け入れ側   必須  
初日  B-05    情報の扱いとセキュリティのルールを説明する   管理者 必須  
初日  B-06    質問先と質問のしかたを伝える（15分考えて進まなければ聞く、など）   受け入れ側   必須  
初日  B-07    リポジトリをクローンし、環境構築を始める    本人  必須  
初日  B-08    1週目のスケジュールと30・60・90日プランの下書きを一緒に確認する 管理者 必須  
初日  B-09    終業前に15分のふりかえりをする（困ったこと・明日やること）  受け入れ側   推奨  
初日  B-10    昼食やオンラインの雑談の時間を取る   受け入れ側   任意  
1週目 C-01    ローカルでアプリケーションを起動し、テストを通す    本人  必須  
1週目 C-02    環境構築でつまずいた箇所を手順書に反映する   本人  必須  
1週目 C-03    ブランチ運用・コミットの書き方・レビューの進め方を説明する   受け入れ側   必須  
1週目 C-04    最初のプルリクエストを出し、レビューを受けてマージする 本人  必須  
1週目 C-05    朝会と定例の会議に参加する   本人  必須  
1週目 C-06    足りない権限を洗い出し、追加で申請する 本人  必須  
1週目 C-07    週の終わりに30分ふりかえり、30・60・90日プランを確定する    管理者 必須  
1週目 C-08    デプロイの流れを1回、横で見る 受け入れ側   推奨  
1週目 C-09    関わりの多い人3〜5人と15分ずつ顔合わせをする    本人  推奨  
1週目 C-10    知らなかった言葉を用語集に追記する   本人  任意  
1か月 D-01    小さな機能追加か修正を1件、着手からリリースまで担当する    本人  必須  
1か月 D-02    週1回の1on1を続ける    管理者 必須  
1か月 D-03    30日の確認をする（プランの「確認方法」の列で確かめる）    管理者 必須  
1か月 D-04    オンボーディング資料の改善点を本人から集め、反映する  受け入れ側   必須  
1か月 D-05    ほかの人のプルリクエストを1件以上レビューする 本人  推奨  
1か月 D-06    問い合わせ・障害対応の流れを説明し、当番の様子を横で見てもらう 受け入れ側   推奨  
1か月 D-07    60日の目標を、30日の結果をもとに見直す   本人  推奨  
1か月 D-08    メンターとの毎日の確認を、週2〜3回に減らす  受け入れ側   任意  

権限申請一覧表

権限は、申請から付与まで日数がかかることがあります。入社日の1週間前までに申請を出し、初日の朝に使える状態にしておくのが目安です。最初に付ける範囲は必要最小限にして、役割が広がる時点で足していきます。

No  対象  最初に付ける権限    付ける時期   申請する人   申請日 付与日 確認（本人がログインできた日）
1   ID管理（シングルサインオン） アカウント発行、多要素認証の登録    入社前 管理者         
2   メール・予定表 利用者 入社前 管理者         
3   チャット    チームのチャンネルへの参加   入社前 受け入れ側           
4   ソースコード管理    担当リポジトリへの書き込み   入社前 受け入れ側           
5   課題管理    課題の作成・編集    入社前 受け入れ側           
6   ドキュメント（Wiki）    閲覧と編集   入社前 受け入れ側           
7   CI/CD   実行結果の閲覧、ジョブの再実行 入社前 受け入れ側           
8   パッケージの配布元   読み取り    入社前 受け入れ側           
9   VPN・社内ネットワーク    接続  入社前 管理者         
10  開発環境（クラウド）  開発用の環境での作成・変更   入社前 受け入れ側           
11  検証環境のデータベース 読み取り    1週目 受け入れ側           
12  ログ・監視   閲覧  1週目 受け入れ側           
13  シークレット管理    開発用の値の読み取り  1週目 受け入れ側           
14  デザインツール 閲覧とコメント 1週目 受け入れ側           
15  本番環境    付けない    60日以降   管理者         
16  有償ツールのライセンス 1席  入社前 管理者         

「付与日」だけでなく「本人がログインできた日」の列を持つのがポイントです。付与されたはずの権限が、グループの設定もれなどで使えないことは珍しくありません。初日に本人と一緒に1行ずつ確かめます。

1週目の日別スケジュール例

1週目の予定は、入社前に予定表へ入れておきます。空き時間に何をすればよいかが決まっていると、本人が迷わずに済みます。

メンターの時間も先に確保します。目安は、1日目と2日目は半日、3日目以降は1日あたり1時間です。メンターが不在の日は、代わりに質問を受ける人を決めておきます。

最初のプルリクエストに向く課題の条件

最初のプルリクエストの目的は、機能を作ることではなく、「課題を取る → ブランチを切る → 変更する → テストする → レビューを受ける → マージされる」という一連の流れを1周することです。その目的に合う課題を、入社前に2〜3件選んでおきます。

課題管理のツールで「最初の課題向け」のラベルを用意し、普段から条件に合う課題に付けておくと、次の受け入れのときに探す手間がなくなります。

30・60・90日プランのテンプレート

30・60・90日プランは、入社から約1・2・3か月の時点で「どうなっていたいか」を、本人と管理者が合意して書き残すものです。目標・行動・確認方法の3列で書くと、後から「届いたかどうか」を事実で確かめられます。

空のテンプレート

# 30・60・90日プラン

- 氏名：
- 役割：
- 入社日：
- メンター：
- 管理者：
- 確認日：30日（　/　）　60日（　/　）　90日（　/　）

| 時期 | 目標 | 行動 | 確認方法 |
|---|---|---|---|
| 30日 |  |  |  |
| 60日 |  |  |  |
| 90日 |  |  |  |

## 確認の記録

| 時期 | 確認日 | 届いたこと | 次の期間に持ち越すこと | 受け入れ側が変えること |
|---|---|---|---|---|
| 30日 |  |  |  |  |
| 60日 |  |  |  |  |
| 90日 |  |  |  |  |

タブ区切り版：

時期  目標  行動  確認方法    確認日 結果
30日                 
60日                 
90日                 

確認日を先に決める

確認日は、プランを作るときに予定表へ入れておきます。入社日から30・60・90日後を求め、土日に当たったら次の月曜にずらす計算は次のとおりです（祝日は考慮していないので、当たった場合は手で調整します）。

# 入社日から 30・60・90日後の確認日を求める（土日に当たったら次の月曜にずらす）
from datetime import date, timedelta

def review_day(start: date, days: int) -> date:
    d = start + timedelta(days=days)
    while d.weekday() >= 5:      # 5=土曜, 6=日曜
        d += timedelta(days=1)
    return d

start = date(2026, 10, 5)
youbi = "月火水木金土日"
print(f"入社日    {start}（{youbi[start.weekday()]}）")
for n in (30, 60, 90):
    d = review_day(start, n)
    print(f"{n}日の確認 {d}（{youbi[d.weekday()]}）")

実行結果：

入社日    2026-10-05（月）
30日の確認 2026-11-04（水）
60日の確認 2026-12-04（金）
90日の確認 2027-01-04（月）

記入例1：バックエンドエンジニア

記入例2：フロントエンドエンジニア

記入例3：インフラエンジニア

3つの例に共通しているのは、30日は「小さく1周する」、60日は「範囲を持つ」、90日は「自分から提案する」という段階です。目標の大きさは、経験年数や担当するシステムの複雑さに合わせて、1週目のふりかえりで調整します。

オンボーディング進行のフロー図（Mermaid）

入社前から90日までの流れと、途中で止まったときの戻り先を図にしたものです。Mermaid に対応したエディタやWikiに貼ると、そのまま描画されます。

flowchart TD
    A[入社前: 機器・アカウント・権限・最初の課題を準備] --> B[初日: 出迎え・全体像の説明・環境構築を開始]
    B --> C{2日目までに<br/>ローカルで起動できたか}
    C -- いいえ --> C1[メンターと一緒に構築し<br/>手順書を直す]
    C1 --> C
    C -- はい --> D[最初のプルリクエストを出す]
    D --> E{1週目のうちに<br/>マージできたか}
    E -- いいえ --> E1[課題を小さく分け直す]
    E1 --> D
    E -- はい --> F[1週目のふりかえり<br/>30・60・90日プランを確定]
    F --> G[30日の確認]
    G --> H{目標に届いたか}
    H -- いいえ --> H1[妨げを取り除き<br/>60日の目標を調整]
    H -- はい --> I[60日の確認]
    H1 --> I
    I --> J[90日の確認]
    J --> K[オンボーディング完了<br/>資料の改善点を反映]

図の分岐は3か所です。

30・60・90日の確認で聞くこと

確認の場は、評価を伝える場ではなく、プランと受け入れ方を調整する場として使います。次の質問を上から順に使えます。

最後の質問の答えは、チェックリスト D-04 の入力になります。入ったばかりの人は、資料のわかりにくい所にいちばん気づける人です。直してもらった箇所は、次の受け入れでそのまま役に立ちます。

つまずきやすい点と整え方

よくある質問

Q. オンボーディングの期間は、どのくらいを見ておけばよいですか？ A. この記事では、区切りを付けやすい90日を1つの単位にしています。経験者で似た技術に慣れている人は短く、担当するシステムが大きい場合は長くなります。期間よりも、30・60・90日のそれぞれで「何ができていれば届いたと言えるか」を先に決めることが大切です。

Q. メンターと管理者は、同じ人でもよいですか？ A. 小さなチームでは同じ人が兼ねることもあります。その場合でも、日々の技術的な質問を受ける役と、プランを合意して確認する役は別の仕事として時間を分けておくと、どちらかが後回しになるのを防げます。

Q. リモート勤務の場合、何を変えればよいですか？ A. チェックリストの項目は同じで、やり方を変えます。機器は入社日より前に届くように送り、初日はビデオ通話をつないだまま環境構築を進めます。1週目は、毎日決まった時刻に15分の通話を入れておくと、質問のきっかけが作れます。

Q. チェックリストは誰が管理しますか？ A. 管理者が全体を持ち、各項目は担当列の人が完了を付けます。表計算ソフトや課題管理のツールに貼り、本人にも見える場所に置くと、次に何が起きるかを本人が自分で確かめられます。

まとめ

• 準備の大半は入社前に終えられる。入社前の必須8項目は、すべて受け入れ側と管理者の担当
• チェックリストは担当（受け入れ側・本人・管理者）と優先度（必須・推奨・任意）を付け、必須27項目から終える
• 権限は1週間前に申請し、「本人がログインできた日」まで確かめる
• 最初のプルリクエストは流れを1周するためのもの。小さく、急ぎでなく、完了の条件がはっきりした課題を選ぶ
• 30・60・90日プランは目標・行動・確認方法の3列。確認方法は、プルリクエストや文書など残るもので書く
• 段階は30日「小さく1周する」、60日「範囲を持つ」、90日「自分から提案する」
• 確認の場で集めた改善点を資料に反映すると、次の受け入れが楽になる

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。