OJT計画書テンプレート｜エンジニア新人3ヶ月の育成計画例

OJT計画書とは、仕事を通じて新人を育てるために「いつまでに・何ができるようになるか・どう確かめるか」を書いた表です。 項目を増やすより、週ごとの課題と到達基準が埋まっていることが役に立ちます。

この記事では、架空の開発チームに配属された新人エンジニアの12週間（3ヶ月）の計画を、すべての週を埋めた形で載せます。表はコピーしてそのまま使えるよう、Markdownとタブ区切りの両方を置きました。受け入れ初日から1週間の準備（アカウントや権限、初日の予定）には触れず、3ヶ月の育成計画と到達の確認に絞っています。なお、ここで扱う「確認」は育成のためのもので、人事評価の決め方は扱いません。

確認環境：Mermaidのガント図は @mermaid-js/mermaid-cli 11.14.0 とChromiumで描画できることを確かめています（Linux、確認日 2026-10-06）。計画の内容・人名はすべて架空の例です。

この記事の結論

• 計画書は「到達目標・週ごとの課題・確認方法・担当」の4列があれば回る
• 目標は「理解する」ではなく「〜できる」という行動で書く（見て確かめられる形にする）
• 12週間を4週×3期に分け、30日・60日・90日に到達基準を置く
• 毎週1回、成果物を見ながら15〜30分のふり返りを行い、翌週の課題の量を調整する
• 教え方は「やって見せる→説明する→やらせる→確認する」の4段階を、課題ごとに繰り返す

OJT計画書の早見表

最小の形は、到達目標・週ごとの課題・確認方法・担当の4列です。この記事の12週間の表は、確認方法を「成果物」と「到達基準」の2列に分けて、より確かめやすくしています。

OJT・Off-JT・メンター制度の違いと組み合わせ方

3つは置き換えではなく組み合わせて使います。基礎はOff-JT、仕事の進め方はOJT、相談はメンターと役割を分けると、トレーナー1人に負担が集まりません。

目標は「できる行動」で書く

「理解する」「慣れる」は、できたかどうかを人によって違う基準で判断してしまいます。動詞を「説明できる」「1人で進められる」「示せる」に変え、回数・時間・手助けの有無を足すと、新人もトレーナーも同じものを見て確かめられます。

12週間のOJT計画（記入例）

想定は次のとおりです。

• チーム：社内向け図書貸出システムの開発チーム（5人）
• 新人：田中さん（入社後の基礎研修を終えて配属。Webアプリを作る研修は経験済み）
• トレーナー：山本さん（入社4年目）、チームリーダー：中村さん
• 期間：2026-04-06〜2026-06-26（12週間）
• 90日後の到達目標：
  1. 小さな機能を、設計メモから実装・テストまで進められる
  2. 再現手順のある不具合を1人で調べて直せる
  3. 作業を半日単位に分け、見通しを自分から報告できる
  4. ほかの人の変更に、根拠つきのレビューコメントを書ける

表計算ソフトに貼れるタブ区切りです。

週   課題  成果物 到達基準（できる行動） 確認者
1   開発環境を整え、チームの用語と決まりを知る   手元で動くアプリ、環境構築メモへの追記 手順書を見ながら、1人でアプリを起動しテストを実行できる    トレーナー
2   既存コードを読み、貸出登録の処理の流れを追う  処理の流れをまとめた図（1枚） 貸出登録で呼ばれるクラスとテーブルを、図を見せながら5分で説明できる  トレーナー
3   文言の修正など小さな変更を出す プルリクエスト2件   ブランチ作成からレビュー依頼までを、手順書どおりに1人で進められる   トレーナー
4   画面の入力チェックを1つ追加する    プルリクエスト1件、テストコード    指摘を受けた点を直し、同じ種類の指摘を次の変更で繰り返さない  トレーナー
5   再現手順のある不具合を調べる  調査メモ（原因と直し方の案）  ログとデバッガを使い、原因の箇所を示せる    トレーナー
6   調べた不具合を直す   プルリクエスト1件、再発を防ぐテスト  直す前は通らず、直した後に通るテストを書いて示せる   トレーナー
7   既存機能にテストを足す テストコード（正常・境界・エラーの3種）    テストの観点を自分で挙げ、抜けを指摘されたら追加できる 先輩メンバー
8   ほかの人の小さな変更をレビューする   レビューコメント3件以上    根拠を添えて質問や提案を書ける トレーナー
9   小さな機能（返却期限の通知一覧）の設計メモを書く    設計メモ（画面・データ・処理） 分からない点を質問にまとめ、30分の相談で方針を決められる   チームリーダー
10  設計メモに沿って実装する    プルリクエスト（2〜3件に分ける）   作業を半日単位に分け、毎日の進み具合を自分から報告できる    トレーナー
11  テストとレビュー対応を終える  取り込まれたプルリクエスト、動作確認の記録   レビュー指摘への対応を2営業日以内に返せる   トレーナー
12  3ヶ月をふり返り、次の3ヶ月の目標を決める   ふり返りシート、次の目標（3つ）    できるようになったことと次の課題を、事実を挙げて説明できる   チームリーダー

組み立ての考え方は3つです。

• 第1期（1〜4週）は「読む・小さく直す」。 最初の変更は文言の修正など、作りを壊しにくいものにします。
• 第2期（5〜8週）は「1人で調べて直す」。 調査と修正を別の週に分け、調査メモを成果物にすると、考え方を確かめられます。
• 第3期（9〜12週）は「小さな機能を通しで作る」。 設計メモ→実装→テストを1つの機能で経験します。

30日・60日・90日の到達基準表

節目では、週ごとの課題とは別に、観点ごとにどこまでできるようになったかを確かめます。

観点  30日（4週の終わり） 60日（8週の終わり） 90日（12週の終わり）    確認方法
技術  手順書を見て環境を作り、小さな変更をレビューに出せる  再現手順のある不具合を1人で調べて直し、テストを添えられる   小さな機能を設計メモから実装・テストまで進められる   プルリクエストと成果物を見る
コードを読む力 1つの処理の流れを図にして説明できる  変更の影響が及ぶ箇所を自分で挙げられる 既存の作りに合わせた実装の方針を提案できる   図や設計メモを見ながら説明してもらう
仕事の進め方  その日の作業と困りごとを毎日報告できる 作業を1日単位に分け、遅れそうなときに前日までに伝えられる   作業を半日単位に分け、見通しを自分から報告できる    日々の報告と週次ふり返りシート
質問と相談   30分調べて分からなければ質問できる  調べたこと・試したこと・聞きたいことをそろえて質問できる    選択肢と自分の案を添えて相談できる   質問の記録を見る
レビュー    指摘の意図を確かめてから直せる 同じ種類の指摘を繰り返さない  ほかの人の変更に根拠つきのコメントを書ける   レビューのやり取りを見る

節目の確認は、「できた」「もう少し」の2段階で記録すれば十分です。「もう少し」が付いた観点は、次の期の課題に1つだけ織り込みます。 一度に直す点を絞るほうが、本人も動きやすくなります。

4段階の進め方（やって見せる・説明する・やらせる・確認する）

新しい種類の課題に入るたびに、次の4段階を回します。例は7週目の「既存機能にテストを足す」です。

• 1と2を省くと、3で止まる時間が長くなります。 忙しいときほど、最初の30分を確保します。
• 3では答えを言わず、「どこまで分かった？」「次に何を試す？」と問いかけます。
• 4は成果物を画面に出して行います。 記憶ではなく、見えるものを材料にします。

週次ふり返りシート

毎週同じ曜日・同じ時間に15〜30分で行います。新人が先に記入し、トレーナーが書き足します。

# 週次ふり返りシート（第　週　／　月　日）

記入者：　　　　　トレーナー：

## 1. 今週の課題と到達基準
- 課題：
- 到達基準：
- 結果：できた ／ もう少し

## 2. できたこと（事実で3つ）
-
-
-

## 3. つまずいたことと、どう進めたか
-

## 4. 来週の課題と、最初にやること
- 課題：
- 最初の一歩：

## 5. トレーナーへのお願い・質問
-

## 6. トレーナーから（できた点 → 次に伸ばす点を1つ）
-

記入例（6週目）です。

# 週次ふり返りシート（第6週／5月15日）

記入者：田中　　トレーナー：山本

## 1. 今週の課題と到達基準
- 課題：先週調べた不具合（返却日が月末をまたぐと期限が1日ずれる）を直す
- 到達基準：直す前は通らず、直した後に通るテストを書いて示せる
- 結果：できた

## 2. できたこと（事実で3つ）
- 月末をまたぐ日付のテストを3本書き、直す前に2本が通らないことを確かめた
- 修正のプルリクエストを出し、指摘2件に翌日までに対応した
- 調査メモを更新し、原因の箇所と直し方を残した

## 3. つまずいたことと、どう進めたか
- 日付の計算をどこで行っているか見つけるのに半日かかった。検索の語を変えても見つからず、山本さんに質問して共通部品の場所を教わった

## 4. 来週の課題と、最初にやること
- 課題：貸出登録の機能にテストを足す
- 最初の一歩：今あるテストを読み、足りない観点を書き出す

## 5. トレーナーへのお願い・質問
- 共通部品の一覧があれば教えてほしい

## 6. トレーナーから（できた点 → 次に伸ばす点を1つ）
- 直す前に通らないテストを先に書けたのがよかった。原因を説明する材料にもなっていた
- 次は、30分探して見つからない時点で質問してみよう

指導する側の準備チェックリスト

計画書がうまく回るかどうかは、配属前の準備で決まります。16項目を時期ごとに並べました。

時期  確認すること  済
配属前 到達目標（90日後にできる行動）を3〜5個に絞って書いた    □
配属前 12週間の課題と成果物を表に埋め、チームリーダーと合意した   □
配属前 最初の4週間の課題を、実際のリポジトリから選んで確保した    □
配属前 アカウント、権限、端末、手順書の場所を確かめた □
配属前 自分が不在の日の代わりの確認者を決めた □
配属前 週次ふり返りの日時を12回分、予定表に入れた  □
1週目 計画書を本人と一緒に読み、到達基準の意味をすり合わせた □
1週目 質問のしかた（どこに、いつ、何をそろえて）を伝えた   □
1週目 1日の終わりの報告の形を決めた □
毎週  成果物を見て、到達基準に対して できた・もう少し を記録した  □
毎週  できた点を先に、具体的な事実で伝えた  □
毎週  来週の課題の量を、今週の進み具合に合わせて調整した   □
毎週  本人の困りごとを聞き、自分が動くことを1つ決めた    □
節目（30・60・90日）   到達基準表を本人と一緒に見て、観点ごとに確認した    □
節目（30・60・90日）   計画の残りを見直し、変更点をチームリーダーに伝えた   □
節目（30・60・90日）   次の節目までに伸ばす点を1〜2個に絞った    □

Mermaidのガント図で計画を見せる

12週間の全体像を1枚で見せたいときは、Mermaidのganttが手軽です。次のコードは、Mermaidに対応したエディタやドキュメントにそのまま貼れます。

gantt
    title 新人エンジニアOJT計画（12週間）
    dateFormat YYYY-MM-DD
    axisFormat %m/%d
    excludes weekends
    section 第1期 環境と読む力
    開発環境と用語（1週）           :a1, 2026-04-06, 5d
    既存コードを読む（2週）         :a2, after a1, 5d
    小さな修正を出す（3〜4週）      :a3, after a2, 10d
    30日の確認                      :milestone, m1, after a3, 0d
    section 第2期 一人で直す
    不具合の調査と修正（5〜6週）    :b1, after a3, 10d
    テストを書く（7週）             :b2, after b1, 5d
    レビューを受けて直す（8週）     :b3, after b2, 5d
    60日の確認                      :milestone, m2, after b3, 0d
    section 第3期 小さな機能を作る
    機能の設計メモ（9週）           :c1, after b3, 5d
    実装とテスト（10〜11週）        :c2, after c1, 10d
    ふり返りと次の目標（12週）      :c3, after c2, 5d
    90日の確認                      :milestone, m3, after c3, 0d

• excludes weekends を入れると土日が作業日から外れ、5d が月曜から金曜の1週間になります。描画した図では、各週の棒が月曜日に始まり、最後の棒が2026-06-26（金）で終わりました。
• 祝日も外したいときは excludes weekends, 2026-04-29, 2026-05-04, 2026-05-05, 2026-05-06 のように日付を並べます。この形で描画すると、5週目の棒の開始が2026-05-04から2026-05-08へ移り、それ以降もずれました。
• after a1 のように前の棒のIDを指定すると、開始日を1つ変えるだけで全体が動きます。
• 節目は milestone と 0d で置けます。

計画を見直すタイミングと直し方

計画は、進み具合に合わせて直すものです。直してよい列と、動かさない列を分けておくと迷いません。

確かめて分かったこと

• Mermaidのganttは、excludes weekends だけでは祝日を外しません。 祝日の日付を並べて描画し直すと、棒がその日数分だけ後ろへずれました。12週間で終える計画なら、祝日のある週の課題を軽くしておくと収まります。
• after でつないだ棒は、祝日を足したときも自動で後ろへ送られました。 日付を1本ずつ書くより、直す箇所が少なくて済みます。
• 節目（milestone）は、前の棒の終わりの位置に置かれました。 30日・60日・90日の確認を期の最後の棒に after でつなぐと、計画がずれても節目が一緒に動きます。
• 12週間の表をタブ区切りにすると、1つのセルが長くなるのは「到達基準」の列でした。 表計算ソフトではこの列の幅を広げ、折り返して表示する設定にすると読みやすくなります。

よくある質問

Q. OJT計画書とは何ですか？ A. 仕事を通じて新人を育てるための、期間・課題・到達基準・確認者をまとめた表です。新人、トレーナー、上長の3者が同じ見通しを持つために使います。

Q. OJTとOff-JTの違いは何ですか？ A. OJTは配属先の仕事の中で学び、Off-JTは仕事を離れた研修や講座で学びます。基礎知識はOff-JT、チームの作り方や進め方はOJTと分けると組み合わせやすくなります。

Q. OJTの期間は3ヶ月でよいですか？ A. 小さな機能を1つ通しで作るところまでを目標にするなら、3ヶ月（12週間）が区切りやすい長さです。扱う仕組みが大きい場合は、同じ表を次の3ヶ月分も作って続けます。

Q. 計画どおりに進まないときはどうすればよいですか？ A. 到達基準は変えず、課題の量と順番を直します。週次のふり返りで翌週の課題を調整し、節目で残りの計画を見直します。

Q. トレーナーが1人で見きれないときは？ A. 確認者を週ごとに分けます。記入例でも、7週目は先輩メンバー、9週目と12週目はチームリーダーが確かめる形にしています。

まとめ

• OJT計画書は、到達目標・週ごとの課題・確認方法・担当の4列があれば回る
• 目標は「〜できる」という行動で書き、回数・時間・手助けの有無を足す
• 12週間を3期に分け、読む→1人で直す→小さな機能を作る、と進める
• 30日・60日・90日の到達基準表で、観点ごとの伸びを確かめる
• 新しい課題のたびに4段階（やって見せる・説明する・やらせる・確認する）を回す
• 週次ふり返りは枠を固定し、成果物を見ながら翌週の課題の量を調整する
• 計画を直すときは課題を動かし、到達基準は動かさない

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