こんにちは、インフラエンジニアのryuです。
経験者として中途採用したインフラエンジニア。書類も面接も申し分なく、前職ではチームを支えていた人。なのに入社してみると、思ったように動き出さない。そんな経験はないでしょうか。
「即戦力のはずなのに」と、採用した側は少し焦ります。本人はもっと焦っています。
これは能力の問題ではないことがほとんどです。受け入れる側の「設計」が足りていないだけ、というケースを私は何度も見てきました。
今日は、中途で採ったインフラエンジニアが本来の力を出せるようになるまでを、どう短くするか。育成・採用を担う方に向けて、受け入れ（オンボーディング）の考え方と具体的な手順をお話しします。
「即戦力なのに動けない」のはなぜ起きるのか？¶
まず、なぜスキルのある人が現場で足踏みするのか。ここを取り違えると、受け入れの打ち手を全部間違えます。
新しい職場に移るというのは、引っ越しに似ています。家具（スキル）は持って行けても、最寄り駅の場所やゴミ出しのルール、ご近所付き合いは全部ゼロから覚え直しです。仕事も同じで、技術は持ち込めても「文脈」は持ち込めません。
技術は移せても、現場の文脈は移せない¶
インフラの仕事は、純粋な技術力だけで回っているわけではありません。
「本番の変更はいつ、誰の承認で流すのか」「このアラートは無視していいのか」「あのシステムは誰が詳しいのか」。こうした暗黙のルールや人間関係が、日々の判断の大半を支えています。
前職で10年やってきた人でも、ここは新人と同じスタートラインです。むしろ「分かっているはず」という周囲の期待があるぶん、質問しにくくて詰まりやすい。技術は持ち込めても、現場の文脈は持ち込めない。 これが中途採用ならではの落とし穴です。
組織にどう馴染むかを研究している立教大学の中原淳教授も、中途入社者には職務そのものへの適応だけでなく、職場や組織文化への適応という別の課題があると指摘しています。技術の話ではないのです。
具体的に想像してみましょう。前職では監視ツールがDatadogだった人が、新しい職場ではZabbixを使っている。ツールが違うだけなら数日で慣れます。ですが本当に難しいのは、その先です。どのアラートが緊急で、どれは様子見でいいのか。夜中に鳴ったとき、誰にエスカレーションするのか。この線引きは、その現場で痛い目を見た人たちが積み上げてきた暗黙のルールで、マニュアルには書かれていません。経験者ほど「聞かなくても分かるはず」と思われるせいで、この線引きを教わる機会を逃しがちなのです。
最初の90日は「価値を生む前」の助走期間¶
経営学の世界には『最初の90日で成果を出す技術』（マイケル・ワトキンス著）という有名な考え方があります。
新しい環境に入った人は、最初のうちは組織から与えてもらう側、いわば価値を消費する期間にいる。自分のやり方と現場のやり方がかみ合い、正味の価値を生み始めるのは、その助走を終えてから、という見立てです。
つまり、入社直後に成果が出ないのは自然なこと。問題は、その助走期間を放置して長引かせてしまう受け入れ体制のほうにあります。
逆に言えば、この90日をどう設計するかで立ち上がりの速さは大きく変わります。実際、大手の人材会社でも中途採用者について「入社後およそ半年での早期立ち上がり」を一つの目安に置き、受け入れを仕組み化しています。
そして、この投資は数字にも表れます。米国のBrandon Hall Groupの調査では、体系立ったオンボーディングを持つ組織は、新入社員の定着率を82%、生産性を70%以上高めたと報告されています。受け入れは「気配り」ではなく「投資」だ、ということです。
中途採用の受け入れを支える三つの柱¶
では、具体的にどう設計するのか。私は受け入れを三つの柱で組み立てることをおすすめしています。
一つずつ見ていきましょう。
柱その1：入社前〜初日の「つまずき」を消しておく¶
意外に軽視されがちなのが、入社初日の環境です。
アカウントが作られていない。VPNがつながらない。権限が足りず検証環境にすら入れない。初日にこれをやられると、経験者ほど「歓迎されていないのかな」と感じ、出足のモチベーションを削がれます。
初日までに、次のようなものを用意しておきたいところです。
| 準備するもの | 具体例 |
|---|---|
| アクセス環境 | 各種アカウント、VPN、検証環境への権限 |
| 全体像の地図 | システム構成図、ネットワーク図、主要な連携先 |
| はじめの一歩 | 最初の1〜2週間で触ってよいタスクのリスト |
| 人の地図 | 「何は誰に聞くか」の担当者一覧 |
とくに構成図や「誰に聞くか」の一覧は、あるだけで立ち上がりがまるで違います。属人化した知識をどう渡すかは、インフラの属人化を解消する育成とナレッジ継承の設計でも触れていますが、中途受け入れはその知識を棚卸しする良い機会でもあります。
ここで一つ、現実的な話をしておきます。「そんな図やドキュメント、うちには揃っていない」という現場のほうがむしろ多数派です。それで構いません。完璧な資料を用意してから迎えようとすると、いつまでも受け入れは始まりません。大事なのは、手書きの雑なネットワーク図一枚でも、口頭で30分説明した内容のメモでもいいので、何か「取っかかり」を渡すことです。むしろ入ってきた本人に、分かりにくかった点をその都度ドキュメントに書き足してもらう。新しい目で見た人ほど、どこがブラックボックスかに気づけます。受け入れそのものを、資料を育てる作業にしてしまうわけです。
柱その2：30・60・90日のロードマップを引く¶
「困ったら聞いてね」で放り出すのが、いちばん立ち上がりを遅らせます。経験者は自走できると思われがちですが、そもそも走る道が見えていないのです。
そこで、最初の90日を三つに区切って期待値を言語化します。何を「できていればいい」とするかを、受け入れる側と本人ですり合わせるわけです。
| 期間 | この時期のゴール |
|---|---|
| 〜30日 | 環境・構成・チームのルールを把握し、小さな変更を一人で回せる |
| 〜60日 | 定常運用や小規模な構築を任せられる。オンコールに部分参加 |
| 〜90日 | 一つの領域を主担当として持ち、改善提案を出せる |
ここで大事なのは、ゴールを高くしすぎないことです。焦って60日で主戦力を求めると、本人は分からないことを隠すようになり、かえって遠回りになります。新人研修全体の組み立て方はインフラ未経験の新人研修をどう設計するかに譲りますが、中途でも「段階を踏ませる」という原則は変わりません。
柱その3：気軽に聞ける「バディ」をつける¶
三つ目は、人です。
入社直後の人がいちばん欲しいのは、マニュアルよりも「こんな初歩的なこと聞いていいのかな」を受け止めてくれる相手です。
そこで、斜め上の先輩を一人、オンボーディング・バディとしてつけます。評価者である直属の上司には聞きにくいことも、バディにはこぼせる。この心理的な安全地帯があるだけで、詰まる時間が驚くほど減ります。
バディを置くときのコツは、最初のうちは相手から声をかける約束にしておくことです。「困ったらいつでも聞いて」は、忙しそうな相手を前にすると案外使えません。だから、たとえば毎日15分だけ雑談も兼ねた時間を取り、「今どこで詰まっていますか」とこちらから尋ねる。この小さな習慣が、抱え込みを未然に防ぎます。最初の2週間さえ乗り切れば、あとは本人が自然と質問できるようになっていきます。
先輩が新人を計画的に育てる仕組みづくりは、OJTをトレーナー制度に変えるつくり方で詳しく書いています。中途受け入れのバディも、考え方は地続きです。
「あの人しか分からない」を、渡せる形にする¶
受け入れの設計は、実は既存チームの体質改善にもつながります。
新しく入る人に説明できないルールは、たいてい既存メンバーの頭の中にしかない暗黙知です。それを言葉にする過程で、チームの属人化そのものが薄まっていきます。
たとえば、口伝で回っている作業手順を、簡単なランブックにしておく。中途の人はこれを読んで自走でき、既存メンバーも「いつもの作業」を見直せます。
# ランブック: 本番Webサーバの再起動手順
## 前提
- 対象: web-prod-01 / 02（LB配下）
- 影響: 1台ずつなら無停止。必ず1台ずつ実施する
## 手順
1. Slackの #ops に作業開始を宣言する
2. 対象1台をLBから切り離す（`lbctl drain web-prod-01`）
3. 接続が0になったのを監視画面で確認してから再起動
4. ヘルスチェックが緑になったらLBへ戻す
5. もう1台も同様に。最後に #ops へ完了報告
## 困ったら
- LBの操作は @ネットワーク担当
- 監視の見方が不安なら #ops で質問する
こうした手順書やチェックリストが積み上がると、次に人が入るときの受け入れコストは下がり続けます。受け入れ設計は、一度作れば資産として残るのです。
なお、ここで求められるスキルを整理したいときは、インフラエンジニアに必要なスキルマップが棚卸しの下敷きになります。もし特定領域の知識に穴が見つかったら、Linuxの学習ロードマップのような教材で本人に補ってもらうのも一手です。
受け入れがうまくいっているか、どう測るのか？¶
最後に、設計しっぱなしにしないための「ものさし」の話です。
受け入れの良し悪しは、感覚では分かりません。次のような指標を、90日の節目で軽く振り返るだけで十分です。
| 見る指標 | チェックの観点 |
|---|---|
| 初期タスクの進み | 30日ゴールを予定どおり通過できたか |
| 質問の量と質 | 質問が出ているか（無いのは詰まっている兆候） |
| 定着 | 入社後3か月・半年で辞意が出ていないか |
| 本人の手応え | 「馴染めている」感覚があるか（本人に直接聞く） |
とくに「質問が出ていない」は要注意です。順調なのではなく、聞けずに固まっているサインであることが多い。
数字が思わしくなければ、期待値が高すぎたか、バディが機能していないか、そもそも情報が渡っていないか。三つの柱のどこが弱いかを見直せば、打ち手は絞れます。早期離職を防ぐという観点はオンボーディングで離職を防ぐ設計にもまとめています。
こうした受け入れ設計をゼロから組むのは、正直たいへんです。InfraAcademyでは、中途・未経験を問わずインフラ人材を戦力化するための研修プログラムを提供しています。自社の受け入れに悩んでいる方は、InfraAcademyの法人プランから一度ご相談ください。
受け入れで、つい陥りがちな三つの失敗¶
ここまでは「こうするとよい」という話でした。最後に、良かれと思ってやってしまいがちな失敗を三つ挙げておきます。どれも私自身が現場で見てきた、あるあるです。
一つ目は、期待を口にしすぎることです。「経験者だからすぐ回せるよね」「前職でやってたでしょう」。励ましのつもりの一言が、本人には無言のプレッシャーになります。分からないと言い出せなくなり、独りで抱え込んで、気づけば一週間止まっていた。こうなると立ち上がりはむしろ遅くなります。前職の経験は財産ですが、それは「この現場で通用するか本人が確かめてから」の話です。最初はむしろ「分からなくて当たり前」と繰り返し伝えるくらいでちょうどいいのです。
二つ目は、いきなり難所を任せることです。即戦力への期待が高いほど、初日から込み入った障害対応や、誰も触りたがらない古いシステムを渡してしまいがちです。気持ちは分かります。でも、地図もないまま真っ暗な森に放り込まれた人が実力を出せるでしょうか。まずは全体像の見える、失敗しても致命傷にならない小さな仕事から始める。そこで一度きちんと成功体験を積んでもらうことが、その後の自走につながります。急がば回れ、です。
三つ目は、受け入れを現場任せにして、担当を決めないことです。「みんなで面倒を見よう」は、裏を返せば「誰も責任を持たない」になりがちです。全員が善意で見ているつもりでも、結局その人の進捗を誰も把握していない。そんな状態がいちばん危うい。だからこそ、前に述べたバディのように、受け入れの主担当を一人はっきり決めておくことが効きます。一人が見ていれば、詰まりの兆候にも早く気づけます。
この三つは、いずれも「相手を経験者として信頼している」ことの裏返しでもあります。信頼と放置は違う。 この一点さえ押さえておけば、受け入れは大きく外しません。任せることと、任せきりで見ないことは、まったくの別物です。経験者を迎えるときほど、口出しは減らしても、目は離さない。そのさじ加減が、受け入れる側に求められる腕の見せどころだと私は思います。
まとめ¶
中途で採ったインフラエンジニアが動けないのは、能力ではなく受け入れの設計不足であることがほとんどです。
技術は持ち込めても、現場の文脈は持ち込めない。だから最初の90日は助走期間だと割り切り、そのあいだに「初日のつまずきを消す」「30・60・90日の期待値を引く」「気軽に聞けるバディをつける」の三つを用意しておく。
受け入れの設計は、その人のためだけでなく、チームの属人化を薄め、次に入る人のコストまで下げてくれる投資です。
せっかく縁あって来てくれた経験者に、気持ちよく力を発揮してもらう。その一手間が、半年後のチームの厚みを変えていきます。今日から、初日の準備リストを一枚作ることから始めてみてください。
