新人SE育成シート(Excel・無料)
新人システムエンジニアを3か月で開発に入れる状態にするための育成計画例です。開発環境の構築、既存コードの読み方、仕様の理解、変更の実装とレビュー、テストの作り方、リリースの手順までを記入した完成例と、編集用テンプレートを収録しています。
Excel(エクセル)形式 / PDF対応 / 更新日 2026-09-03
上のボタンから、メールアドレスと6つの質問にご回答ください。ダウンロードリンクをすぐにお送りします。
ご回答は、次に作るテンプレートを決める材料にしています。
この育成シートは誰向けですか
- 新人エンジニアを初めて受け入れる開発責任者
- メンター役を任されたエンジニア
- 教え方が人によって違う状態を直したい開発リーダー
- 未経験採用を始めた受託開発会社の管理者
どのような場面で使いますか
受託開発や業務システムの開発を行う会社で、新人エンジニアを受け入れるときに使います。完成例では、環境を自分で作れるようにする段階から、小さな変更を一人で設計してリリースする段階までを週ごとに設定しています。手を動かす前に読む時間が必要な職種なので、第2週と第3週をコードと仕様を読む週にしています。
含まれる項目
このExcelには、次の内容が記入済みで入っています。自社に不要な項目は削除して構いません。
- 育成方針・到達目標(6テーマ:環境/コードを読む/仕様の理解/実装/テスト/リリース)
- 3か月のフェーズ構成(読む期/直す期/出す期)
- 週次育成計画 全12週(第1週 環境を作る 〜 第12週 設計の入口と振り返り)
- 各週のOJT内容 合計60項目(実際にやることを動詞まで記入済み)
- 各週の成果物 12種類(環境構築手順メモ(追記版)/構成の説明図/データの流れ図/仕様の要点メモ ほか)
- 各週の評価・フィードバック担当
- スキルチェック 7項目(到達基準とチェック時期つき)
- 評価項目 6観点(何をもってできていると判断するかを記入済み)
- 完成版(記入済み)と編集用テンプレートの2ファイル
Excel画面のプレビュー
完成版のExcelを、シートごとにそのまま表示しています。5枚すべて見られます。伏せている箇所はありません。
| A | B | C | D | |
|---|---|---|---|---|
| 1 | 新人SE育成シート 育成方針・到達目標 | |||
| 2 | 育成板|3か月で最終的にどの状態まで育てるかを整理するシートです。 | |||
| 3 | ||||
| 4 | No | 育成テーマ | 目的 | 育成の方向性 |
| 5 | ① | 環境 | 自分の手元で動かせる | 開発環境の構築/依存の入れ方/設定ファイル/動作の確認 |
| 6 | ② | コードを読む | 既存の作りを説明できる | ディレクトリの構成/データの流れ/命名の決まり/過去の変更履歴 |
| 7 | ③ | 仕様の理解 | 何を作るかを言葉で言える | 要件と仕様の違い/画面と項目/異常系/確認する相手 |
| 8 | ④ | 実装 | 小さな変更を自分で入れられる | ブランチ/変更の粒度/コミットの書き方/レビューの受け方 |
| 9 | ⑤ | テスト | 壊れたことに気づける | 確認の観点/自動テスト/再現手順/回帰の確認 |
| 10 | ⑥ | リリース | 本番へ出して確かめられる | 手順/確認の項目/戻し方/出したあとの確認 |
| A | B | C | D | E | |
|---|---|---|---|---|---|
| 1 | 新人SE育成シート 3か月計画 | ||||
| 2 | 育成板|育成期間を月ごとのフェーズに分け、その月に出す成果物まで決めるシートです。 | ||||
| 3 | |||||
| 4 | 月 | フェーズ | メインテーマ | サブテーマ | 成果物 |
| 5 | 1か月目 | 読む期 | 環境の構築とコード・仕様の読解 | 環境構築/構成の把握/データの流れ/仕様書 | 環境構築手順メモ/構成の説明図/仕様の要点メモ |
| 6 | 2か月目 | 直す期 | 小さな変更の実装とレビュー | ブランチ/実装/レビュー/不具合の調査 | 変更の記録/レビュー指摘の一覧/調査記録 |
| 7 | 3か月目 | 出す期 | テストとリリース、設計の入口 | テスト/リリース/設計の相談/振り返り | テストの記録/リリース手順メモ/設計メモ |
| A | B | C | D | E | F | G | |
|---|---|---|---|---|---|---|---|
| 1 | 新人SE育成シート 週次育成計画 | ||||||
| 2 | 育成板|その週に何を経験させ、何を提出させるかを1週ずつ決めるシートです。実施日と確認欄は運用中に記入します。 | ||||||
| 3 | |||||||
| 4 | 週 | テーマ | OJT内容 | 成果物 | 評価・FB担当 | 実施日 | 確認 |
| 5 | 第1週 | 環境を作る | 手順書に沿って開発環境を構築する | 環境構築手順メモ(追記版) | メンター | ||
| 6 | 止まった箇所と対処を記録する | ||||||
| 7 | 依存関係の入れ方を確認する | ||||||
| 8 | 設定ファイルの中身と置き場所を確認する | ||||||
| 9 | 手順書に足りなかった箇所を追記する | ||||||
| 10 | 第2週 | 構成を読む | ディレクトリの構成を書き出す | 構成の説明図 | メンター | ||
| 11 | 各ディレクトリの役割を1行で書く | ||||||
| 12 | 起動から画面が出るまでの流れを追う | ||||||
| 13 | 設定と定数の置き場所を確認する | ||||||
| 14 | 構成の説明図を書いてメンターに説明する | ||||||
| 15 | 第3週 | データの流れを追う | 画面の1つの操作を選ぶ | データの流れ図 | メンター | ||
| 16 | 入力から保存までを順に追う | ||||||
| 17 | 通っている関数の名前を書き出す | ||||||
| 18 | データが入るテーブルと列を確認する | ||||||
| 19 | 流れを図にして説明する | ||||||
| 20 | 第4週 | 仕様を読む | 担当する機能の仕様書を読む | 仕様の要点メモ | メンター/設計担当 | ||
| 21 | 分からない用語を10件書き出して聞く | ||||||
| 22 | 画面の項目と保存先の対応を確認する | ||||||
| 23 | 異常系(入力誤り・重複・権限なし)の扱いを確認する | ||||||
| 24 | 仕様の要点を1枚にまとめる | ||||||
| 25 | 第5週 | 変更を入れる(表示) | ブランチを切る決まりを確認する | 変更の記録 | メンター | ||
| 26 | 表示の文言や並びを直す変更を1件入れる | ||||||
| 27 | 手元で動かして確認する | ||||||
| 28 | コミットのメッセージの書き方を確認する | ||||||
| 29 | レビューを依頼する | ||||||
| 30 | 第6週 | レビューを受ける | 指摘を1件ずつ読んで意図を確認する | レビュー指摘の一覧 | メンター | ||
| 31 | 直す前に、なぜそう書くかを聞く | ||||||
| 32 | 指摘を反映する | ||||||
| 33 | 同じ指摘が出た箇所を自分で探す | ||||||
| 34 | 指摘の一覧を作って型を3つ挙げる | ||||||
| 35 | 第7週 | 変更を入れる(処理) | 条件の追加や計算の変更を1件入れる | 変更の記録 | メンター | ||
| 36 | 影響する箇所を先に探す | ||||||
| 37 | 手元で正常系と異常系を確認する | ||||||
| 38 | 変更の理由をコミットに書く | ||||||
| 39 | レビューを受けて反映する | ||||||
| 40 | 第8週 | 不具合を調べる | 報告された不具合を1件受け取る | 調査記録 | メンター | ||
| 41 | 再現の手順を書く | ||||||
| 42 | ログの見方を確認する | ||||||
| 43 | 原因の箇所を特定する | ||||||
| 44 | 直し方を2案考えてメンターに相談する | ||||||
| 45 | 第9週 | テストを書く | 既存のテストを10件読む | テストの記録 | メンター | ||
| 46 | テストの実行方法を確認する | ||||||
| 47 | 自分が入れた変更にテストを足す | ||||||
| 48 | 正常系と異常系の両方を書く | ||||||
| 49 | 全部のテストを通してから依頼する | ||||||
| 50 | 第10週 | 確認の観点を作る | 担当した機能の確認項目を書き出す | 確認項目一覧 | メンター/試験担当 | ||
| 51 | 画面の幅を変えて確認する | ||||||
| 52 | 権限の違いで確認する | ||||||
| 53 | 前の状態に戻る操作を確認する | ||||||
| 54 | 確認項目の一覧をレビューしてもらう | ||||||
| 55 | 第11週 | リリースを見る | リリースの手順書を読む | リリース手順メモ | メンター/開発リーダー | ||
| 56 | リリースに同席して手順を書き取る | ||||||
| 57 | 出したあとに確認する項目を確認する | ||||||
| 58 | 問題が出たときの戻し方を確認する | ||||||
| 59 | 自分の変更を含むリリースを1件担当する | ||||||
| 60 | 第12週 | 設計の入口と振り返り | 小さな機能追加の設計を1件書く | 設計メモ/振り返りシート | 設計担当 | ||
| 61 | テーブルと画面の変更を書く | ||||||
| 62 | 影響する既存の機能を書き出す | ||||||
| 63 | 設計をレビューしてもらう | ||||||
| 64 | 3か月で受けた指摘の型を整理する | ||||||
| A | B | C | D | E | F | |
|---|---|---|---|---|---|---|
| 1 | 新人SE育成シート スキルチェック | |||||
| 2 | 育成板|到達できたかを確認するシートです。判定・判定日・判定者は確認したときに記入します。 | |||||
| 3 | ||||||
| 4 | 項目 | 目標スキルレベル | チェック時期 | 判定 | 判定日 | 判定者 |
| 5 | 環境 | 手順書から環境を構築し、詰まった箇所を記録して手順書を直せる | 1か月目 | |||
| 6 | コードを読む | ディレクトリの構成とデータの流れを、図で説明できる | 1か月目 | |||
| 7 | 仕様の理解 | 画面の項目と保存先の対応、異常系の扱いを説明できる | 2か月目 | |||
| 8 | 実装 | 表示と処理の小さな変更を、影響範囲を確認したうえで入れられる | 2か月目 | |||
| 9 | レビュー | 指摘の意図を確認し、同じ指摘が出る箇所を自分で直せる | 2か月目 | |||
| 10 | テスト | 正常系と異常系のテストを足し、全部通してから依頼できる | 3か月目 | |||
| 11 | リリース | 手順に沿って出し、出したあとの確認と戻し方を説明できる | 3か月目 | |||
| A | B | C | D | |
|---|---|---|---|---|
| 1 | 新人SE育成シート 評価項目 | |||
| 2 | 育成板|育成の途中のフィードバックと、期間終了時の評価の両方に使うシートです。 | |||
| 3 | ||||
| 4 | 観点 | 内容 | 評価 | コメント |
| 5 | 読む力 | 手を動かす前に、既存のコードと仕様を読めているか | ||
| 6 | 影響範囲の確認 | 変更する前に、どこに影響するかを探せているか | ||
| 7 | 確かめる姿勢 | 手元で動かして、正常系と異常系の両方を確認しているか | ||
| 8 | 指摘の吸収 | 同じ指摘を繰り返さず、他の箇所にも自分で当てられるか | ||
| 9 | 報告 | 詰まったときに、何をどこまで試したかを添えて相談できるか | ||
| 10 | 記録 | 調査した経緯と直した理由を、後から読める形で残せているか | ||
| 11 | ||||
| 12 | 利用上の注意 | |||
| 13 | この様式に記入されている内容は、一般的な新人SEの育成をもとに作成した例です。法令で定められた様式ではありません。 実際の業務内容・商品・体制によって、教える順番と期間は変わります。到達の速さには個人差があります。 自社の評価制度・就業規則・教育に関する社内規程がある場合は、そちらを優先してください。 作成・更新:育成板(SYOJIN / 商陣 https://syojin.com info@syojin.com) | |||
ファイル形式
| 形式 | Excel(.xlsx) 2ファイル(完成版・編集用) / PDF(印刷用) |
|---|---|
| 対応 | Microsoft Excel 2016以降 / Googleスプレッドシート / LibreOffice Calc |
| 用紙 | A4縦。シートごとに印刷でき、全部で6枚になります |
| シート | 育成方針 / 3か月計画 / 週次育成 / スキルチェック / 評価項目 |
| マクロ | 使用していません |
| ファイルサイズ | 完成版 約 18KB / 編集用 約 16KB / PDF 約 303KB |
| 更新日 | 2026-09-03 |
入力方法
- まず完成版の3か月育成例を確認します。第1週から第4週で読み、第5週から直し、第9週から出す組み方です。
- 第1週の前に、必要な権限(リポジトリ・課題管理・開発環境)を渡しておきます。権限が無いと第1週が進みません。
- 第2週と第3週は削らないでください。既存の作りを読まないまま変更を入れると、動くけれど筋の悪いコードになります。
- 第5週と第7週の変更は、メンターが先に題材を1件ずつ選んでおきます。題材選びを本人に任せると、難しすぎるものを選んで止まります。
- スキルチェックの確認時期は、実際にレビューを通した後に置きます。書けたことと通せたことは違います。
- 毎週30分、レビューの指摘を本人と一緒に読み返します。指摘の数ではなく、同じ指摘が減っているかを見ます。
カスタマイズ方法
- 受託で顧客と直接話す会社は、第4週の後に「顧客との確認の場に同席する」を1週足します。
- 自社サービスを持つ会社は、第11週のリリースを2週に広げ、出したあとの監視の見方を足します。
- 扱う言語や枠組みが複数ある会社は、第2週と第3週を主力の1つに絞ります。2つ同時に読ませると、どちらも身につきません。
- テストの仕組みが無い会社は、第9週を「確認の手順を書き残す」に差し替え、第10週の確認項目一覧を2週に広げます。
- 未経験採用の場合は、第1週の前に言語の基礎の学習期間を2〜4週足します。完成例は基礎の学習が済んでいることを前提にしています。
利用上の注意
- 完成例は、既存のシステムに変更を入れる仕事を前提にしています。新規の開発が中心の会社では、第2週と第3週の「既存を読む」が当てはまりません。
- 3か月目の到達点は「小さな機能追加の設計を書いてレビューを受けられる」です。設計を一人で決められる状態ではありません。設計の判断はレビューを前提にしてください。
- 掲載している内容は、一般的なOJT・研修・スキル管理・評価の業務をもとに作成した参考例です。法令で定められた様式ではありません。
- 実際の業務内容に応じて調整してください。自社の評価制度・就業規則・社内規程がある場合は、そちらを優先してください。
- 内容は更新することがあります。このページの更新日(2026-09-03)をご確認ください。
- 本様式の利用によって生じたいかなる損害についても、当サイトは責任を負いません。
よくある質問
未経験の新卒でも3か月で開発に入れますか?
完成例は、言語の基礎(文法・関数・データ構造)の学習が済んでいることを前提にしています。基礎から始める場合は、第1週の前に2〜4週の学習期間を足してください。基礎が無いまま第2週のコード読解に入っても、読めずに止まります。
メンターの負担が大きくなりませんか?
完成例では、第5週と第7週の題材選び、週30分の指摘の読み返し、レビューの3つがメンターの主な作業です。題材を先に選んでおくことで、その場で考える時間を減らしています。メンター1人が同時に見る新人は1人までを目安にしてください。
テストの仕組みがありません。使えますか?
使えます。第9週を「確認の手順を書き残す」に差し替え、第10週の確認項目一覧を2週に広げてください。自動化されていなくても、確認の観点を書き出して残す作業には意味があります。
3か月で設計まで任せられますか?
任せる前提では組んでいません。第12週の到達点は「小さな機能追加の設計を書いてレビューを受けられる」です。設計の判断を一人でできる状態ではないため、レビューを必ず通す運用にしてください。