新人が感じているギャップ

新人が戸惑っていることの多くは、こちらからは見えません。

理由は単純で、あなたにとっては当たり前すぎて、 説明が必要だと思っていないからです。

「30分詰まったら聞いていい」        → 言われないと、聞くのは迷惑だと思っている
「7割で見せていい」                → 完璧にしてから出すものだと思っている
「レビューの指摘は普通のこと」      → 減点されたと感じている
「分からないと言っていい」          → 分からないのは恥だと思っている

新人が黙って3日溶かしたとき、本人はサボっていたわけではありません。 学生時代のルールで、真面目に頑張っていただけです。

学生時代のルールは、実務とほぼ逆

新人が持ち込んでくる前提を、明示的に並べます。

左の列は、10年以上かけて身につけた習慣です。 1回言っただけでは切り替わりません。

見えている行動と、実際に起きていること

新人の行動を「やる気」や「能力」で解釈すると、たいてい誤ります。

どれも、本人の性格ではなく前提の問題です。

最初に言葉にして渡すこと

初日から数日のうちに、明示的に伝えてください。 「察してもらう」ことは期待できません。

□ 「30分詰まったら聞いてください。それが正しい行動です」
   → 数字を出す。「いつでも聞いて」では機能しない（質問しやすさを仕組みで作る）

□ 「完璧にしなくていいです。7割で見せてください」
   → 途中で見せる実例を、こちらから見せる

□ 「1日1回、進捗と詰まりを書いてください」
   → 形式（分報・チケットのコメントなど）を指定する

□ 「レビューの指摘はコードに対するものです。人への評価ではありません」
   → 最初のレビューの前に言う

□ 「見積もりは外れて構いません。外れたと分かった時点で言ってください」

□ 「コードを書いていない日があっても問題ありません」
   → 読む・調べる・聞くも仕事だと明言する

□ 「分からない言葉が出たら、その場で止めて聞いてください」

「困ったら聞いてね」        → 遠慮が残る
「30分で聞くのがルールです」 → 従うべき手順になる

質問できない理由を、仕組みで潰す

「なぜ聞かないのか」を本人に聞いても、あまり出てきません。 代わりに、聞かなくてよい状態を作ります。

□ こちらから定期的に聞く（1日1回、5分でよい）
   → 「困ってることある？」ではなく「今どこまで進んだ？」「どこで止まってる？」

□ 詰まりを検知する仕組みを持つ（質問しやすさを仕組みで作る）
   → チケットが動いていない、コミットが無い、分報が止まっている

□ ペアで作業する時間を作る
   → 質問という形をとらずに、疑問がその場で解消される

□ 「これは聞くべきか」の基準を先に渡す
   → 30分、という数字がそれ

悪い: 「何か分からないことある？」→「大丈夫です」
良い: 「この処理、なんで status を2回チェックしてるか分かる？」
     「さっきの用語、説明できる？」
     「今の作業、私が知らない人だと思って説明してみて」

期待値を、数字と例で渡す

新人が最も不安なのは、「このペースでいいのか」が分からないことです。

□ 「このタスクは3日を想定しています」と最初に言う
   → 遅れているのかどうかを、本人が判断できるようになる

□ 「最初の1ヶ月は、コードより理解に時間を使ってください」
   → 成果が見えないことへの不安が消える

□ 「3ヶ月後にこうなっていれば順調です」と伝える
   → 評価と目標設定の評価基準を先に渡す、と同じ

「大丈夫、最初はそんなもんだよ」
→ 本当に大丈夫なのか、気を遣われているのかが分からない

「今のペースは想定通りです。1ヶ月目はこれで問題ありません」
→ 事実として伝わる

こちらの当たり前を疑う

新人が詰まった時、説明していない前提が原因であることがよくあります。

□ 社内の略語・プロジェクト名・システム名（コードベースとドメイン知識を渡すの用語集）
□ 「いつもの手順」（誰にも書かれていない）
□ 承認が必要な作業と、必要でない作業の線引き
□ 誰に聞けばいいかの地図
□ Slack のどのチャンネルで何を話すか
□ 会議に出る目的（聞くだけでよいのか、発言すべきか）
□ 「これは触ってはいけない」の範囲

質問された → 答える → その場でドキュメントに書く（または本人に書いてもらう）

やってはいけない反応

□ 「そんなことも知らないの」（一度でも言えば、二度と聞かれなくなる）
□ 質問に対して、すぐ答えず「自分で調べて」だけ返す
□ 忙しそうな態度を見せる（聞くタイミングを永久に失わせる）
□ 他の人と比較する（複数人を同時に受け入れる）
□ 質問の内容ではなく、質問の仕方を先に指摘する

最後の項目は、良かれと思ってやりがちです。 まず答えてから、次回のための形式を伝えてください。 順序が逆だと、質問すること自体のハードルが上がります。

新人の側にしかない価値を、活かす

ギャップは埋めるだけのものではありません。 その時期にしか出せない価値があります。

□ 「なぜこうなっているんですか」と聞ける（慣れた人は疑問に思わない）
□ 環境構築手順を本当に検証できる唯一の人（受け入れ前にそろえるもの）
□ 用語の曖昧さに最初に気づく
□ 「これ、変じゃないですか」と言える

これらを歓迎していると明示してください。

「分からないことがあったら、それはドキュメントの不備です。教えてください」
「変だと思ったら言ってください。慣れてしまうと気づけなくなるので」

本人にとっては貢献の実感になり、チームにとっては実利があります。

この章のまとめ

• 新人が黙っているのは、サボりでも能力不足でもなく、 学生時代のルールで真面目に頑張っている結果
• 学生時代の常識は実務とほぼ逆。 聞くのは恥 / 完璧にして提出 / 自力で解く / 進捗は報告しない
• 「聞いていい」ではなく「30分で聞くのが仕事」 と、義務の形で渡す
• 質問を待たず、こちらから具体的に聞く。 「分からないことある？」では何も出てこない
• 期待値を数字と例で渡す。基準が無いと本人はペースを測れない
• 詰まりの原因は、たいていこちらが説明していない前提にある
• 新人の質問は暗黙知の棚卸し。答えたらその場でドキュメントにする
• 一度「そんなことも知らないの」と言えば、二度と質問は来ない
• 「なぜ？」と聞ける立場は一時的な資産。歓迎していると明示する

参考資料