そのまま使えるテンプレート集

# 受け入れ前チェックリスト（受け入れ日: YYYY-MM-DD / 対象: ○○さん）
 
## 2週間前
- [ ] 貸与 PC を申請した（受け取り予定日: ____）
- [ ] 入館証・座席を申請した
- [ ] メインメンターを決めた（担当: ____）
- [ ] バックアップメンターを決めた（担当: ____）
- [ ] 1on1 担当を決めた（担当: ____）
- [ ] メンターの稼働を 2〜3 割空けることをチームに合意した
 
## 1週間前
- [ ] メール／チャット／カレンダーのアカウントを申請した
- [ ] ソースコード管理・チケット管理の招待を出した（承認者: ____ / 代理: ____）
- [ ] クラウド・ステージング環境の権限を申請した
- [ ] パスワード管理ツールに招待した
- [ ] 参加してもらう定例（朝会・スプリント関連）にカレンダー招待を出した
- [ ] 最初のタスクを起票し、受け入れ条件を書いた（チケット: ____）
- [ ] 予備のタスクを1つ用意した（チケット: ____）
- [ ] 初日〜1週目の到達目標を書いた
 
## 3日前
- [ ] まっさらな環境で環境構築手順を最後まで通した（所要時間: ___ 分）
- [ ] 詰まった箇所を手順書に反映した
- [ ] 初日のタイムテーブルを組み、関係者の予定を押さえた
- [ ] 昼食・歓迎の時間を誰かの予定に入れた
 
## 2日前
- [ ] 発行済みの権限を「実際に操作して」確認した
      - [ ] リポジトリを clone できる
      - [ ] ブランチを push できる
      - [ ] CI の実行結果が見える
      - [ ] 開発チャンネルに参加できている
      - [ ] ステージング環境にログインできる
- [ ] 初回ログイン案内が本人に届いているか確認した
 
## 前日
- [ ] 担当の地図（誰に何を聞くか）を1ページにまとめた
- [ ] 質問先のチャンネルを作った／既存チャンネルに招待した
- [ ] 初日の集合時間・場所（または会議 URL）を本人に連絡した
- [ ] 席／リモート環境を確認した
      - [ ] 席・モニタ・電源（出社の場合）
      - [ ] 会議ツールの権限、常時つなぐ用の部屋（リモートの場合）
- [ ] チームに「明日から来ます」を共有した

初日タイムテーブル（YYYY-MM-DD / ○○さん）
 
10:00-10:20  挨拶と今日の流れの共有          メンター
             → 今日のゴール「コードを1行変えて動かす」を先に伝える
10:20-11:00  チーム紹介 / 担当の地図を渡す    メンター
11:00-12:00  アカウント・権限の疎通確認       本人
             → 使えないものが出たらこの時間に申請し直す
12:00-13:00  昼食（誰かと一緒に）             チーム
13:00-15:00  環境構築                         本人（30分詰まったら声かけ）
15:00-15:30  コードを1行変えて動かす          本人  ★今日のゴール
15:30-16:30  明日以降のタスクの説明           メンター
16:30-17:00  1日の振り返り（15分でよい）      2人
17:00        終了。残業させない
 
事前に押さえておく人の予定:
- 10:20 チーム紹介に出る人: ____
- 12:00 昼食に行く人: ____
- 16:30 振り返り: ____

## 背景
 
（なぜこれをやるのか。2〜3行。ドメインの前提知識が要る場合はここで説明を完結させる）
 
## やること
 
- [ ] （具体的な変更内容を、判定できる粒度で書く）
- [ ] （テストが必要ならここに書く）
 
## 関連ファイル
 
- `path/to/file.ts` — （このファイルの何を変えるか）
- `path/to/another.ts` — （読むだけでよいなら「参考」と書く）
 
## 参考になる既存実装
 
- `path/to/similar.ts` — 同じことを別の場所でやっている例。まずこれを読むとよい
- PR #___ — 似た変更の過去 PR
 
## 完了条件
 
- [ ] ローカルで ○○ が ○○ になることを目視で確認できる
- [ ] 既存のテストが通る
- [ ] PR がマージされている
 
## 詰まったら
 
- まず聞く人: ____（不在時: ____）
- 30分やって進まなかったら、整理できていなくても声をかけてください
- 想定時間: ___ 時間（これを大きく超えたら、タスクの設計ミスなのでこちらに教えてください）

# オンボーディング計画（○○さん / 開始: YYYY-MM-DD）
 
| 時期 | 到達目標 | 確認方法 | 現在地 |
|---|---|---|---|
| 1週目 | 環境を自分の手で起動できる / 小さい PR が1本マージされている | その場で起動してもらう / マージ履歴 | |
| 2週目 | 小さい修正を、指示なしで PR まで進められる | レビューでの手戻り回数 | |
| 1ヶ月 | 仕様が曖昧なタスクを、質問で詰めながら進められる | 質問の内容が「どうすれば」から「A と B で迷っている」に変わっているか | |
| 3ヶ月 | 見積もりが出せる / 他人の PR にコメントできる | 見積もりと実績の差 / レビューコメントの有無 | |
 
## 各時期に渡すタスク
 
| 時期 | タスクの性質 | 具体例 | 担当レビュアー |
|---|---|---|---|
| 1週目 | 答えがこちらにある1行変更 | | |
| 2週目 | 手順が決まっている小さい修正 | | |
| 1ヶ月 | 仕様の確認が必要なもの | | |
| 3ヶ月 | 設計の選択肢があるもの | | |
 
## 受け入れ側の宿題
 
| いつまでに | 誰が | 何を |
|---|---|---|
| | | |

# 1on1（初回）— ○○さん / YYYY-MM-DD / 30分
 
## 0-5分 この時間の説明
- 進捗確認ではないこと
- 評価の場ではないこと（評価の話をする回は事前に予告すること）
- 記録は2人が見られる場所に残すこと
- 言いにくいことを言ってよい場であること
 
## 5-15分 相手のこと
- ここまでで、いちばん戸惑ったことは何ですか
- 事前に聞いていた話と、実際で違ったところはありますか
- この期間で「これができるようになりたい」と思っているものはありますか
 
## 15-25分 こちらから伝えること
- 何ができていれば順調か（1週目 / 1ヶ月 / 3ヶ月）
- 30分ルール（30分手が止まったら、整理できていなくても声をかける）
- 質問先（メイン / バックアップ / 領域ごと）
- レビューの返し方と、ラベルの意味
 
## 25-30分 決めごと
- 1on1 の曜日・時間・頻度
- 記録をどこに置くか
- 次回までのアクション（双方）

# 1on1（定例）— ○○さん / YYYY-MM-DD / 30分
 
## 0-5分 コンディション
- 体調・睡眠・負荷
- 今週の忙しさは 10段階でいくつでしたか
 
## 5-15分 相手が話したいこと（相手7・自分3）
選んで聞く:
- 今週いちばん時間を使ったのはどこですか
- そのうち、想定より時間がかかったのはどれですか
- 今、聞きたいけど聞けていないことはありますか
- 誰かの手を止めるのを我慢した場面はありましたか
- 私のやり方で分かりにくいところはありますか
- 読んだ資料で「これ書いてないな」と思った箇所はありますか
 
## 15-25分 こちらから
- 良かったこと（事実 + 影響で。事前にメモしたもの）
- 気になったこと（1回に1つだけ）
- 期待値の確認: 前回話した「____」、今週は使えましたか
 
## 25-30分 次回まで
- 本人のアクション:
- こちらのアクション:
- 前回のアクションはどうなったか:

## YYYY-MM-DD（第 ___ 回 / 30分）
 
### 話したこと
-
 
### 決めたこと
-
 
### 次回までの宿題
- 本人:（誰が・何を・いつまでに）
- こちら:（誰が・何を・いつまでに）
 
### 前回の宿題の結果
- 本人:
- こちら:
 
### 気になったこと
-（事実だけ。「いつ・何があったか」で書く。人物評は書かない）

◆ 悪い例
  「あの PR よかったよ、ありがとう」
 
◆ 良い例
  「昨日の検索まわりの PR（S）、変更を3つのコミットに分けてくれていたので（B）、
   レビューが15分で終わりました。まとめて来ると1時間はかかるところでした（I）。
   あの粒度で続けてほしいです」
 
 
◆ 悪い例
  「調査ありがとう、助かった」
 
◆ 良い例
  「今週の障害調査の報告（S）、試したけど違った仮説まで書いてくれていたので（B）、
   私が同じ調査をやり直さずに済みました（I）。あれは書くのが面倒なところなので助かります」
 
 
◆ 悪い例
  「最近いい感じだね」
 
◆ 良い例
  「先週のタスク（S）、着手前に仕様の確認を済ませていましたよね（B）。
   おかげで手戻りがゼロでした（I）。私はそれを後回しにして直したことが何度もあります」

◆ 悪い例
  「もっと主体的に動いてほしい」
 
◆ 良い例
  「先週の計画会で、担当の決まっていないチケットが3件残りました（S）。
   その時に手が挙がらなかったので（B）、私が3件とも持つことになって
   レビューが半日遅れました（I）。
   次の計画会では、内容が分からないものでも『これ調べてみます』と
   声を上げてもらえると助かります」
 
 
◆ 悪い例
  「報告が遅い」
 
◆ 良い例
  「水曜に聞いた API の仕様変更、気づいたのは月曜だったと言っていましたよね（S・B）。
   その2日、フロント側が古い仕様のまま実装を進めていました（I）。
   仕様が変わったと気づいた時点で、まだ確定していなくてもチャンネルに投げてください」
 
 
◆ 悪い例
  「コードの品質が低い」
 
◆ 良い例
  「昨日の PR で、エラーをそのまま握りつぶしている箇所が2つありました（S・B）。
   本番で起きた時にログに何も残らないので、原因を追えなくなります（I）。
   握りつぶす判断をした時は、理由をコメントに1行残してもらえますか」

◆ 悪い例
  「言いにくいんだけど……いや、大したことじゃないんだけどね、
   もし気にしてたらごめんなんだけど、その、なんというか……」
  → 前置きが長いほど「重い話だ」と伝わります。本題より前置きが怖い
 
◆ 良い例（入り方）
  「1つだけ気になったことがあるので、小さいうちに言っておきますね」
 
 
◆ 悪い例
  「いつも遅刻するよね」
  → 「いつも」は回数を盛った表現で、話が事実から感情に移ります
 
◆ 良い例
  「先週の火曜と今週の木曜、朝会に5分ほど遅れて入ってきましたよね（S・B）。
   朝会は10分しかないので、共有事項を2回言い直すことになりました（I）。
   間に合わない日は、事前にチャンネルに一言だけ入れてもらえますか」
 
 
◆ 悪い例
  「態度が受け身に見える。どう思う？」
  → 観測できない人格評価で、質問で終わっているので依頼も伝わりません
 
◆ 良い例
  「この2週間の 1on1 で、私からの質問には答えてもらえていますが（S）、
   そちらから話題が出たことがまだ無いんです（B）。
   そうすると、私が気づいていない詰まりを拾えないままになります（I）。
   次回は1つでいいので、聞きたいことを持ってきてもらえますか。
   内容は何でも構いません」
 
 
◆ 悪い例（3つ並べる）
  「PR の説明が空なのと、テストが無いのと、あと朝会の遅刻も気になってて」
  → 内容にかかわらず人格否定として受け取られます。1回に1つだけにします

must: 直さないとマージできない
------------------------------------------------------------
must: この関数は await が抜けているので、DB 書き込みの完了を待たずに
      レスポンスを返しています。負荷が上がった時に書き込み前に
      次の処理が走ります。await を付けてください。
 
must: 例外が発生した経路でコネクションが閉じられません。
      try/finally で閉じるか、withConnection のような
      既存のヘルパー（path/to/helper.ts）を使ってください。
 
must: ここでユーザー入力を文字列結合で SQL に入れています。
      パラメータ化クエリに変えてください。同じ形の実装が
      path/to/query.ts の 40 行目付近にあります。
 
 
nit: 直さなくてよい
------------------------------------------------------------
nit: 変数名が data だと、何のデータか読み取れないので
     userProfiles だと分かりやすいかもしれません。直さなくて大丈夫です。
 
nit: 空行が2つ続いています。formatter を通せば消えるはずです。
     気が向いたらで構いません。
 
 
imo: 自分の意見。異論歓迎
------------------------------------------------------------
imo: ここは早期 return にすると、ネストが1段減って読みやすくなると思います。
     ただ今の書き方でも読めるので、好みの範囲です。
 
imo: この定数はこのファイルの中でしか使わないので、
     共通定数ファイルに置かなくてもいい気がします。
     他で使う予定があるなら今のままで大丈夫です。
 
 
q: 質問。指摘ではない
------------------------------------------------------------
q: 再帰にしたのは、カテゴリの階層が不定の深さになる想定でしょうか。
   固定の深さなら別の書き方もあるので、意図を教えてください。
 
q: 手元でどこまで確認しましたか。異常系も試していれば、
   このあとの確認を省けるので教えてください。
 
q: この条件が false になるのはどういう時ですか。
   自分がケースを思いつけていないだけかもしれません。
 
 
praise: 良かった点
------------------------------------------------------------
praise: エラーログに request_id を入れてくれたの助かります。
        調査でログを追う時に、これがあるかどうかで時間が変わります。
 
praise: このテスト、境界値（0件・1件・上限）が揃っていて良いです。
 
praise: 既存のヘルパーを見つけて使ってくれたのが良いです。
        あれ見つけにくい場所にあるので。

◆ 承認するとき
  LGTM です。nit を2つ付けましたが、直さなくてもマージして構いません。
  ○○の書き方が良かったので、次も同じ形でお願いします。
 
◆ 直してほしいことがあるとき
  全体の方向は問題ないです。must が2件あるので、そこだけ直したら承認します。
  他は好みの範囲なので無視して大丈夫です。
 
◆ 設計から見直したいとき（コメントで書かず、その場で話す）
  実装は正しく動いていますが、置き場所を相談したいので
  15分だけ話しませんか。文字だと長くなりそうなので。

# 受け入れ振り返り（○○さん / 期間: YYYY-MM-DD 〜 YYYY-MM-DD）
 
## A. 本人が書く
 
1. この期間でできるようになったことを3つ挙げてください
   -
2. いちばん時間を溶かしたのは何でしたか（技術・環境・人間関係・その他）
   -
3. 「もっと早く教えてほしかった」ものはありましたか
   -
4. 聞きたかったけれど聞けなかったことはありましたか。聞けなかった理由も書いてください
   -
5. 用意されていた資料・手順で、間違っていた／足りなかった箇所はどこですか
   -
6. もう一度最初からやるとしたら、自分は何を変えますか
   -
7. 次に来る人に、受け入れ側がやるべきことを1つ挙げるとしたら
   -
 
## B. 受け入れ側が書く
 
1. 事前に立てた到達目標のうち、達成できたもの／できなかったもの
   -
2. 達成できなかったものについて、原因は「本人・タスク設計・環境・時間」のどれでしたか
   -
3. 準備が足りなかった項目はどれですか（チェックリストの行で答える）
   -
4. メンターの工数は実際どれくらい使いましたか。見積もりとの差は
   -
5. 手順書・ドキュメントで、今回直した箇所と、直しそびれた箇所
   -
6. 次回の受け入れで、チェックリストに足す行／削る行
   -
 
## C. 読み合わせで決めること
 
- 次回までに直すもの（担当と期限を入れる）
  | 何を | 誰が | いつまでに |
  |---|---|---|
  | | | |
- 本人に伝える最終フィードバック（SBI で、良かった点を先に）
  -

# 最終日チェックリスト（○○さん / 最終出社: YYYY-MM-DD）
 
## 本人が持って帰るもの（アカウント停止より前にやる）
- [ ] 書いたコード・PR の一覧（URL のリスト。社外秘の中身は含めない）
- [ ] 成果のサマリ1枚（何を作り、何が変わったか。本人が職務経歴に書ける粒度で）
- [ ] 最終フィードバック（口頭 + 書面。良かった点と、次の場で伸ばすとよい点）
- [ ] 推薦・照会に応じられるかどうかと、その連絡先
- [ ] 公開してよい範囲の明示（技術ブログ・ポートフォリオに何をどこまで書いてよいか）
- [ ] 個人の学習用リポジトリ・メモの退避（会社アカウント配下にあるもの）
 
## 引き継ぎ
- [ ] 未完了タスクの状況を書き出し、引き取り手を決めた
- [ ] 作業中ブランチの扱いを決めた（マージ / Draft PR で残す / 破棄）
- [ ] 本人しか知らない手順・設定を手順書に反映した
- [ ] 本人が作ったドキュメントのオーナーを付け替えた
 
## 受け入れ側がやること
- [ ] 受け入れ振り返りシートを書いてもらい、読み合わせた
- [ ] チェックリストの更新差分を反映した
- [ ] チームの場で、何をやってくれたかを事実で共有した
- [ ] 連絡手段を伝えた（今後質問してよい窓口があるなら明示する）
 
## 返却・停止（上が全部終わってから）
- [ ] 貸与 PC・周辺機器・入館証を返却した
- [ ] 各種アカウントの停止を申請した（停止日: ____）
- [ ] 権限の棚卸しをした（外部サービス・クラウド・リポジトリ）
- [ ] 個人情報を含む共有ドキュメントの権限を見直した