オンボーディングは新人を会社に慣らす期間ではない。採用判断が正しかったかを低リスクで確かめられる、最後の1週間だ。

採用したAIエンジニアの最初の1週間：オンボーディングの設計

思考版1 AI執筆

優秀なAIエンジニアが3ヶ月で静かに去るとき、引き金はたいてい本人のスキルでも報酬でもない。最初の5日間で「何を任され、何を任されなかったか」が、すでに答えを出していた。

顧問として入社直後のすれ違いを何度も見てきたが、原因はほぼ初週にある。オンボーディングを「新人を会社に慣らす期間」だと思っているうちは、ここは設計できない。最初の1週間は、採用前の評価では見えなかったものが表に出てきて、採用判断が正しかったかを低リスクで確かめられる、最後のチャンスだ。

最初の1週間でやること・やらないこと

やること

開発環境のセットアップを自力でやってもらう：環境構築手順書があれば渡す。なければ「READMEだけを頼りに環境を構築してください」という課題にする。

分かったこと：

  • どこで詰まったか（ドキュメントの品質の問題か、理解の問題か）
  • 詰まった時にどうしたか（自分で調べるか、すぐ聞くか）
  • ドキュメントの改善提案を自発的にするか

既存コードを読んで説明してもらう：「このコードを読んで、次のミーティングで自分の言葉で説明してください」という課題を出す。

コードの量は「1〜2時間で読める範囲」で十分。AIを相棒として使ってほしい（むしろ、使わない方が不自然だ）。見たいのは「コードを正しく理解したか」ではなく、「相棒とどう組んで、未知のコードに分け入っていくか」だ。AIに丸投げした答えを読み上げるのか、AIの出力を疑って自分で裏を取るのか——その差に、その人の仕事のしかたが出る。

やらないこと

1週間でプロダクションに機能を出すことを求めない：コンテキストがない状態でプロダクションに出すことを求めると、リスクを理解せずに動くか、動きが止まるかのどちらかになる。

手取り足取りのウォークスルーをしない：セコンドは選手の代わりに殴らない。1日目からメンターが全部説明してしまうと、その人がひとりで立てるかが1週間では見えなくなる。渡すのは答えではなく、READMEと現物のコードだ。横にはいる。代わりに進めはしない。

初期の期待値を話す

採用後のミスマッチで多いのは「期待していたこととやっていることが違う」という状態だ。これは能力の問題ではなく、ほぼ言語化の不足から起きる。

月曜から動ける具体として、初日までに次の3つを1枚にまとめ、本人に渡す：

  • 最初の3ヶ月でやってほしいことを3つ書く：採用の時点で言語化したもの（言語化できていなければ、本人を迎える前に言語化する。書けないなら、何を採ったのかが自分でも曖昧だということだ）
  • どの程度の独立度で動いてほしいかを書く：毎日確認してほしいのか、週1確認でいいのか。本人に「自分で進めていい」と思わせる線を、こちらから引く
  • 間違いや詰まりをどう報告してほしいかを書く：黙って抱えるのか、すぐ相談するのか。これは性格ではなく、組織として先に決めて渡すルールだ

1週間後に確認すること

1週間後に「入社前に期待していたことと、入ってみて感じるギャップはあるか」を聞く。

ギャップは、初週なら一言で直せる。放置すれば、3ヶ月後に「思っていた仕事と違う」という退職に化ける。AIエンジニアは引く手が多く、辞められたときの穴も埋め直しのコストも大きい。だからこそ、安いうちに直す。

このチェックインは「新入社員の満足度確認」ではない。「採用プロセスで伝えたことが、本当に伝わっていたか」を確かめる、採用側の答え合わせだ。初週は、相手を試す週ではなく、自分たちの設計を試す週でもある。

関連記事