インターンならではの受け入れ

ここまでの章は、期限のない新人——つまり正社員の受け入れを前提に書いてきました。 インターンはそこに1つだけ条件が加わります。終わりの日が最初から決まっていることです。

この条件は、タスクの選び方から終わり方まで、設計のほぼ全部を変えます。 この章では、期間という制約の下で何が成立し、何が成立しないかを扱います。

期間が決まっていることが最大の制約

3ヶ月のインターンを受け入れたとします。稼働は週5日、営業日でおよそ60日です。 ここから引き算をしてみてください。

つまり 3ヶ月のうち、まとまった仕事ができるのは45日ほどです。 そして稼働が週3日なら、この45日は27日に縮みます。

さらに悪いことに、立ち上げの遅れは後ろにしか吸収されません。 環境構築に2週間かかったインターンは、成果を出す期間が2週間短くなるだけです。 正社員なら「最初の1ヶ月はゆっくりでいい」が成立しますが、インターンでは成立しません。

初日から逆算して設計する

やるべきことは単純です。終了日を先に置き、そこから逆に予定を引くことです。

• 最終週は成果のまとめと引き継ぎに使う。ここは開発に数えない
• 最後にマージされるべき PR の期限を、終了日の1週間前に置く
• レビューと修正の往復に数日かかる前提で、実装完了はさらにその数日前
• 上記から逆算した日付を、初日に本人と共有する

最後の1つが効きます。 終わりの日付だけを知らされている状態と、「この日までに最後の PR を出す」と分かっている状態では、 本人の時間の使い方が変わります。

期間別の到達目標

期間が違えば、置くべき目標も違います。同じ「戦力になってもらう」を全期間に適用すると、 1週間のインターンは何も達成できないまま終わります。

1週間の欄をよく見てください。目標は1周することです。 これで十分だと割り切れるかどうかが、1週間のインターンが成功するかどうかを決めます。

1週間で「機能を1つ作ってもらおう」とすると、たいてい最終日にレビュー途中の PR が残り、 本人には未完のまま終わった記憶だけが残ります。 一方で文言修正1本でも、マージまで通れば「自分の変更が動いているものに入った」という体験になります。

期間が延びた時に増やすもの

期間が長くなった時に増やすべきなのは、タスクの本数だけではありません。

• 1ヶ月: 完了条件をこちらが書く。触るファイルまで指定する
• 3ヶ月: 完了条件は書くが、影響範囲の調査は本人に任せる。設計の相談を挟む
• 半年以上: 課題だけ渡す。他の人のコードをレビューしてもらう。仕様の相談相手になってもらう

支援を減らす順序は第4部と同じ 手順 → 調査 → 設計です。 期間が長いということは、この階段を上る段数が増えるということです。

完結するタスクを渡す

インターンのタスク設計で、正社員と最も大きく違うのがここです。

期間内に完結しないタスクを渡すと、本人にも会社にも何も残りません。

途中で終わったタスクがどうなるかを考えてみてください。

• 引き継いだ側は、他人の未完成のコードを読むところから始める
• たいてい「自分で書き直した方が早い」となり、実際そうする
• 本人の成果はマージされないまま消えます
• 最終日の振り返りで、話せることが「途中まで作りました」しかない

引き継ぎ前提のタスクは、渡す側にとっては合理的に見えます。 「大きい仕事の一部を任せた」と言えるからです。 しかし完了しなかった部分は、渡した側の工数も食い、本人の実績にもなりません。

完結させるための分け方

大きい仕事を任せたい場合は、タスクを切る位置を変えることで解決できます。

判断基準は1つです。 その単位だけでマージでき、単体で価値があるかを見てください。 満たしていれば、途中で期間が終わっても、そこまでは成果として残ります。

学業との両立を前提に置く

学生の稼働は不定です。これは例外ではなく標準の状態として設計してください。

• 週2〜3日、しかも曜日が学期ごとに変わる
• 試験期間は2週間ほど丸ごと来られない
• 研究の締め切り前は連絡も返ってこない
• 就活の時期は面接で日中が飛ぶ
• 授業が長引いて開始が遅れる

これらを「事前に相談してくれれば対応する」で運用すると、本人は相談しにくくなります。 学生側は、休むことを「迷惑をかけている」と受け取りがちだからです。

やるべきなのは、先にこちらから前提を言うことです。

「試験期間は来なくて大丈夫です。日程が分かったら教えてください。 その週にタスクの期限が来ないように、こちらで調整します」

初日にこれを言っておくと、後から相談が来るようになります。

稼働が飛ぶ日のコストを見積もる

週2日勤務で最も大きいのは、実は稼働時間の少なさではありません。 前回の続きを思い出すコストです。

5日空くと、次のような状態から再開することになります。

• 何を調べていたか忘れている
• 途中まで書いたコードの意図が読めない
• 次に何をするつもりだったか思い出せない
• ブランチが古くなっていて、まず追従作業が要る

体感として、5日空いた後の再開には30分〜1時間が消えます。 週2日なら、これが毎週1回発生します。1ヶ月で4回、半日分です。

作業メモを残す運用が効く

対策は単純で、効果が大きいものが1つあります。

その日の終わりに、5分で作業メモを書いて帰る

書く内容は3行で十分です。

今日やったこと: ユーザー登録のバリデーションを追加。空文字は弾けた
次にやること: 33文字以上のケースのテストを書く
詰まっていること: テストの実行方法が分からない。実行コマンドを聞く

3行目が特に重要です。 詰まりを書き残しておくと、次の出勤日の最初にそれを質問できます。 書いていないと、思い出すところから始まり、質問はさらに後ろにずれます。

置き場所は、チケットのコメントでもチャンネルへの投稿でも構いません。 ただし本人だけが見る場所には置かないでください。 メンター側がそれを読むことで、稼働日の間に起きていることが見えるようになります。

学生であることの前提差

インターン生に対して最も起きやすい誤解は、 知らないことを能力の問題として受け取ってしまうことです。

学生と社会人の間にあるのは、多くの場合、能力差ではなく経験の差です。

右の列を見ると分かるとおり、これらはすべて環境の違いから来る未経験です。 同じ人が半年後には普通にやっています。

git rebase を知らないこと、チャットのスレッドの使い方を知らないこと、 勤怠の打刻を忘れることを、意欲や地頭の話にしないでください。 学生が触れてきた環境に、それらは存在しません。 知らないのは当然で、説明していないこちらの抜けとして扱う方が、結果として速く立ち上がります。

就業体験としての価値を設計する

インターンの価値は、成果物だけではありません。 給料をもらって働く経験そのものが、学生にとっては初めての学習対象です。

その中身は、たとえば次のようなものです。

• 決められた時間に稼働し、進捗を他人に説明する
• 自分の書いたコードが、知らない誰かに使われる
• 一人で完結せず、レビューと合意を経て物事が進む
• 締め切りが自分の都合と関係なく存在する
• 分からないことを、恥ずかしがらずに人に聞く

これらは授業では手に入りません。だから地味な仕事にも価値があります。 実務の大半が華やかでないことを知るのは、学生にとって重要な情報です。

問題はバランスです。次の2つは、どちらも失敗です。

現実的な配分は、主軸に本物の開発タスクを置き、その中に地味な工程が自然に含まれる形です。

• テストを書く、既存テストを直す
• ログを仕込んで挙動を確認する
• ドキュメントを最新に直す
• 動作確認の手順を1つずつ潰す

これらは開発の一部なので、切り出して押し付ける必要がありません。 「地味だが必要な工程」として、本物のタスクの中で経験してもらえます。

終わり方を設計する

インターンは終わります。にもかかわらず、終わり方が設計されていないことがほとんどです。 最終日が「お疲れさまでした」で終わると、本人が何を得たのか本人にも分かりません。

最終日までに渡すもの

成果のまとめは本人に書いてもらう

こちらがまとめて渡すのではなく、本人に書いてもらうことが重要です。 書く過程が、そのまま整理になります。

書式は指定してください。自由記述だと、たいてい作業の羅列になります。

• 何をやったか: 実装した機能、直した不具合を PR のリンク付きで
• なぜそれが必要だったか: 背景。ここが書けると、業務を理解していた証拠になります
• どう解いたか: 選んだ方法と、選ばなかった方法
• 詰まったことと、どう抜けたか: ここが一番、後で本人の役に立ちます
• 次にやるならどうするか: 心残りと改善案

成果発表の場を作る

30分でも構いません。チームの数人が聞く場を作ってください。効果は3つあります。

1. 本人が整理できる。人に説明するために、やったことを構造化する必要が出ます
2. チームに認知される。誰が何をやったかが、本人不在の後にも残ります
3. 説明の練習になる。学生が最も経験していないスキルの1つです

質疑では、詰めるのではなく、掘り下げる質問をしてください。

「その方法を選んだ時、他にどんな案がありましたか？」

この形なら、答えられなくても本人の学びになります。

フィードバックは具体的な出来事に紐づける

最終日のフィードバックで「よく頑張りましたね」だけを言うのは、何も言っていないのと同じです。 第5部の 1on1 と同じ原則で、事実 → 評価の順に話してください。

悪い例:

「積極的でよかったです。これからも頑張ってください」

良い例:

「認証まわりで詰まった時、2日目の朝に自分から相談に来ましたよね。 あれが良かったです。あのタイミングで来なかったら、1週間溶けていました。 詰まった時に早く言えるのは、チームで働くうえで一番役に立つ性質です。

逆に、次にやるなら設計の相談を先にしてほしいです。 3本目の PR で、書いてから方針を変えることになりましたよね。 あれは着手前の5分の相談で防げます」

今後の学習指針も同じで、「テストと CI と設計と DB を勉強するといいです」は、 渡された側には何も残りません。 本人が今回詰まったところを1つ選び、次に読むべきものを具体的に1つだけ渡してください。 本を1冊、あるいは書けるようになるべきコードを1種類。それで十分です。

終わった後の関係を設計する

インターンは、終了時点で関係が切れる仕事ではありません。 学生には横のつながりが強いという特徴があり、体験は必ず共有されます。

• 研究室やサークルの後輩に、そのまま伝わる
• 就活の口コミサイトやSNSに書かれる
• 翌年の応募数に効く
• 本人が別の会社に入った後、取引先や協業先になることもある

つまり、インターンの終わり方は採用活動の一部です。

社員登用を考えるなら、期間中にやること

登用の可能性がある場合、判断材料は期間中にしか集まりません。

• 本人に可能性を早めに伝える。最終日に初めて言われても、本人はすでに他社を決めています
• 評価の観点を先に共有する。第8部の評価の原則と同じで、後出しにしない
• 判断に必要な経験を意図的に渡す。設計判断や他人との合意形成は、渡さなければ観測できません
• 断る場合も、理由を具体的に伝える。「今回はご縁が」で終わらせると、学びが残りません

終わり方が悪いと何が起きるか

次の終わり方は、確実に悪い評判になります。

これらはすべて、忙しさによる不作為で起きます。悪意は必要ありません。 最終週の予定を先に押さえておくことだけが対策になります。

やってはいけないこと

インターン受け入れで繰り返し起きる失敗は、次の4つです。

1. 期間が短いからと放置する

「どうせすぐ終わるから」と、タスクだけ渡して見ない状態です。 短期であればあるほど、放置1日の割合は大きくなります。 3ヶ月のうちの1週間の放置は、正社員の1ヶ月分の放置に相当します。

2. 短いからと詰め込みすぎる

逆のパターンです。「限られた期間で成長してほしい」という善意から、 毎日新しい技術と新しいタスクを渡してしまいます。

結果として、どれも中途半端に終わり、本人に残るのは疲労だけになります。 期間が短いなら、やることも絞ってください。1つを最後まで通す方が残ります。

3. 学生だからと雑務専任にする

データ入力、動作確認の単純作業、資料の清書だけで期間が終わるパターンです。 本人は「開発の仕事はさせてもらえなかった」と受け取ります。

そしてこれは、ほぼ確実に外に伝わります。

4. 成果を本人の実績として語らせない

意外に多いのがこれです。

• 名前が PR に残らない形で取り込む
• 社外に話してはいけない範囲を伝えないまま「守秘だから話すな」で済ませる
• 成果のまとめを作らせない

学生にとって、インターンの成果は就活で語る材料です。 語れる形で渡さないと、本人の側から見れば、期間まるごとが空白になります。

守秘義務がある場合は、禁止するのではなく、 どこまでなら話していいかを具体的に伝えてください。 「使った技術と、自分が担当した処理の一般的な説明までは可。サービス名と数値は不可」のように線を引けば、 本人は安心して語れます。

受け入れ前に決めておくこと

最後に、インターン特有の項目だけをチェックリストにします。 第2部の準備チェックリストに、これを足して使ってください。

「中間地点で範囲を削る」は、忘れられやすいわりに効きます。 期間の半分を過ぎた時点で終わりが見えていないなら、その時点で範囲を減らしてください。 最終週に気づいても、もう間に合いません。

この章のまとめ

• インターンの最大の制約は終わりの日が決まっていること。立ち上げの遅れは後ろにしか吸収されない
• 3ヶ月・週5日でも、まとまった仕事ができるのは45日ほど。終了日から逆算して初日に予定を共有する
• 期間別に目標を変える。1週間なら「開発の流れを1周する」で十分。量ではなく完了で設計する
• 完結するタスクを渡す。単体でマージでき、単体で価値がある単位に切る。引き継ぎ前提のタスクは避ける
• 学生の稼働は不定なのが標準。試験・研究・就活の扱いをこちらから先に伝えると相談が来るようになる
• 稼働日が飛ぶと再開に30分〜1時間かかる。その日の終わりに3行の作業メモを書く運用が効く
• Git・チーム開発・レビュー・業務時間は、能力ではなく経験の差。説明していない側の抜けとして扱う
• 給料をもらって働く経験自体が学び。地味な工程は、本物のタスクの中に自然に含める
• 終わり方を設計する。成果のまとめを本人に書いてもらい、発表の場を作り、具体的な事実に紐づけたフィードバックを渡す
• 学生は横のつながりが強い。終わり方は採用活動の一部であり、放置・雑務専任・成果を語らせないことは外に伝わる

参考資料