こんにちは、インフラエンジニアのryuです。
新人の育成を任されている方に、ひとつ質問です。あなたの現場のOJTは、「誰が担当につくか」で新人の育ち方が大きく変わっていないでしょうか。
面倒見のいい先輩についた新人は半年で独り立ちしたのに、隣の新人は同じ期間たっても任せられる仕事が増えない。よく聞く話です。
これは、新人の資質の差というより、OJTそのものが「先輩まかせ」になっているサインかもしれません。
今日は、この属人的になりがちなOJTを、担当者の当たり外れに左右されない「仕組み」へ変えていくための、トレーナー制度の組み立て方をお話しします。新人インフラの育成を預かる、企業のご担当者に向けた内容です。
OJTが「先輩まかせ」になっていないか？¶
まず、日本の会社が新人育成をどうやっているのか、全体像を確認しておきましょう。
厚生労働省の「令和6年度 能力開発基本調査」によると、日常業務のなかで計画的にOJTを実施した事業所は、正社員に対して6割ほどにのぼります。多くの会社が、集合研修だけでなく現場での指導も育成の柱にしている、ということです。
つまりOJTは、育成の主役です。ところが、この主役が現場では「なんとなく」で回っていることが少なくありません。
新人が配属される。「じゃあ、この子よろしく」と手近な先輩に預けられる。あとはその先輩の裁量とセンス次第——。こういう状態を、ここでは属人的なOJTと呼ぶことにします。
たとえるなら、地図もマニュアルもないまま「先輩の背中を見て道を覚えろ」と言っているようなものです。道をよく知る先輩についた新人は迷わず進めますが、そうでない先輩についた新人は、同じ会社にいながら遠回りを強いられます。
同じお金と時間をかけて採った新人が、配属先の運しだいで育ち方が変わってしまう。これは、育成としてかなりもったいない状態です。
もちろん、優秀な先輩の背中から学べることは本当に多い。腕のいい人の仕事を間近で見るのは、何よりの教材です。問題は、それが「たまたま良い先輩に当たれば」という偶然に委ねられていることのほうにあります。
偶然に頼った育成は、うまくいっているうちは問題が見えません。だからこそ厄介で、優秀な先輩が異動したり辞めたりした瞬間に、現場は急に新人を育てられなくなります。
そして、この「先輩まかせ」の構造には、放っておくと必ず表面化する弱点があります。
なぜ「背中を見て覚えろ」だと育たないのか？¶
属人的なOJTがうまくいかない理由は、大きく2つに分けられます。教わる側から見た問題と、教える側から見た問題です。
教える人によって、育ち方がバラバラになる¶
ひとつめは、指導する人のスキルや経験によって、教える内容も質もばらついてしまうことです。
同じ「Linuxの基礎を教える」でも、ある先輩はユーザー権限とログの見方を丁寧に扱い、別の先輩はとりあえず動かし方だけを教える。何を、どこまで、どんな順で教えるかが、担当者の頭のなかにしかない。だから新人の到達点も、担当者ごとにばらけます。
これは、教える先輩が悪いわけではありません。教える中身が個人の経験に依存する構造そのものが問題なのです。育成の世界では、こうした「あの人にしか分からない」状態を属人化と呼びます。
属人化したOJTは、担当者が異動したり退職したりすると、育て方のノウハウごと消えてしまいます。この、担当者に知識が集中してしまう問題は、インフラの属人化を解消する記事でも詳しく扱っているので、あわせて読んでみてください。
教える側の「本業の片手間」問題¶
ふたつめは、教える側の負担です。ここが、じつは根の深い問題です。
先ほどの能力開発基本調査では、能力開発や人材育成に何らかの問題があるとした事業所が約8割にのぼります。そして、その問題点として多く挙がったのが、次のようなものでした。
指導する人材が不足している（約6割）、人材を育成しても辞めてしまう（約5割）、人材育成を行う時間がない（約5割）。
注目したいのは、上位に「指導する人材が足りない」「教える時間がない」が並んでいることです。多くの現場で、教える側そのものが足りていない。
考えてみれば当然で、OJT担当の先輩には、自分の運用や障害対応という本業があります。そこへ「新人も見てね」が上乗せされる。教えるための時間は、本業の合間から捻出するしかありません。
すると何が起きるか。先輩は自分の仕事で手一杯になり、新人への指導は後回しになります。新人は質問しづらくなり、放置されたと感じる。これが積み重なると、せっかく採った新人の早期離職にもつながります。離職を防ぐ視点は、オンボーディング設計の記事にまとめました。
しかも、育てた新人が辞めてしまえば、また一から採用して育て直しです。先ほどの調査で「育成しても辞めてしまう」が上位に挙がっていたのは、この悪循環に多くの会社がはまっている証拠だと言えます。教える側の余裕のなさと、新人の離職は、じつは地続きの問題なのです。
属人的なOJTの本当の問題は、教える中身のばらつきと、教える側の負担が、どちらも個人まかせのまま放置されることにあります。 この2つを個人の頑張りではなく仕組みで支える、というのが今日の主題です。
OJTを「仕組み」に変える3つの部品¶
では、どうすればOJTを属人技から仕組みへ変えられるのか。ここが本題です。
大がかりな制度を新しく作る必要はありません。次の3つの部品を用意するだけで、OJTはぐっと安定します。誰が教えるか・何を教えるか・教える人をどう支えるか、この3点をあらかじめ決めておくのです。
①誰が教えるかを決める——OJTトレーナーの指名¶
まず、「なんとなく手近な先輩」をやめて、新人ごとにOJTを担当するトレーナーを正式に指名します。ここで大事なのは、指名を口約束で終わらせないことです。
トレーナーの役割を、簡単でいいので文書にして本人に渡す。「この新人を、いつまでに、どの状態まで育てるのが役割です」と明文化するだけで、責任の所在がはっきりします。
このとき、トレーナーの負担を上司が把握しておくことも忘れないでください。「新人育成も仕事のうち」と評価に組み込み、そのぶん本業の量を調整する。教えることを片手間扱いにしない、という会社側の姿勢が、制度を機能させる土台になります。
指名する相手も、必ずしも一番のベテランである必要はありません。むしろ、少し年次の近い先輩のほうが、新人のつまずくポイントを覚えていて教えやすいこともあります。教えることは、その先輩自身の理解を深める良い機会にもなります。
②何を教えるかを決める——育成計画とチェックリスト¶
次に、教える中身を担当者の頭のなかから外に出します。具体的には、育成のゴールと、そこへ至るチェックリストを用意します。
たとえばインフラ新人の3ヶ月なら、こんな粒度で項目を並べておきます。
# 新人OJTチェックリスト（配属〜3ヶ月・例）
[ ] Linux: ユーザー・権限の基本操作ができる
[ ] Linux: ログの場所を理解し、障害時に確認できる
[ ] Network: 疎通確認（ping / traceroute）で切り分けができる
[ ] 運用: 手順書に沿ってサーバの定期作業を1人で完了できる
[ ] 運用: 分からないことを、調べてから質問する習慣がついた
こうしたチェックリストがあると、誰がトレーナーでも「教えるべきことの地図」が共有されます。新人自身も、今どこまで来ていて次に何を身につければいいかが見えるので、迷いが減ります。
ポイントは、項目を「できる」という行動の形で書くことです。「Linuxを理解する」だと、できたかどうかの判断が人によってぶれます。「ログの場所を理解し、障害時に確認できる」なら、実際にやってもらえば達成が一目で分かります。曖昧なゴールは、結局また属人的な判断に逆戻りしてしまうからです。
最初から完璧なリストを目指す必要はありません。一度作ってみて、新人がつまずいた項目を足し、不要な項目を削る。数人の新人を通すうちに、自分の現場に合った育成の地図が育っていきます。
到達度を可視化する具体的なやり方は、新人研修の進捗を見える化する記事にまとめてあります。
③教える人を支える——トレーナー自身の学びと振り返り¶
3つめが、意外と見落とされがちな部品です。教えるのがうまい人と、技術が高い人は、必ずしも同じではありません。
技術力の高いベテランでも、教え方は自己流ということがよくあります。だから、トレーナーになる人には「教え方」を軽くでいいので学んでもらう。目標の伝え方、質問の受け方、フィードバックのやり方を、短い研修や社内の勉強会で共有するだけでも、指導の質は揃っていきます。
あわせて、トレーナー同士が「最近どう教えているか」を持ち寄る場を月に一度でも設けると、良いやり方が横に広がります。教える人を孤立させないことが、制度を長続きさせるコツです。
もうひとつ意識したいのは、うまく育てたトレーナーをきちんと認めることです。新人育成は成果が見えにくく、放っておくと「やって当たり前」で終わってしまいます。誰かの育成がうまくいったら、その工夫をチームで共有し、評価の場でも触れる。教えることが報われる空気があってはじめて、次に教える人が出てきます。育てる人を育てる、という視点を忘れないでください。
ここまでの、属人的なOJTと仕組み化したOJTの違いを、表にまとめておきましょう。
| 観点 | 属人的なOJT | 仕組み化したOJT |
|---|---|---|
| 担当 | 手近な先輩に丸投げ | 役割を明文化して指名 |
| 教える中身 | 担当者の頭のなか | 育成計画とチェックリスト |
| 教える人の支援 | 本業の片手間 | 教え方の共有と評価への反映 |
| 結果 | 担当の当たり外れが出る | 誰が担当でも一定の水準に届く |
大切なのは、右の列を完璧に一度で作ろうとしないことです。まずはチェックリスト一枚からでも、十分に効果があります。
インフラのOJTならではの落とし穴¶
ここまでの話はどんな職種にも当てはまりますが、インフラの現場には固有の難しさもあります。
ひとつは、失敗させにくいこと。設定を一つ間違えるとサービスが止まりかねない領域なので、「まず本番でやってごらん」がやりにくい。だからこそ、検証環境や自宅で作れる練習環境を用意して、安全に手を動かせる場を先に確保しておくことが効きます。
もうひとつは、範囲の広さです。Linux、ネットワーク、クラウド、監視と守備範囲が広く、一人のトレーナーが全部を高いレベルで教えるのは現実的ではありません。分野ごとに詳しい人が少しずつ関わる、という発想に切り替えると、教える側の負担も分散します。
たとえば、Linuxはこの先輩、ネットワークの切り分けはあの先輩、というように担当を薄く分ける。メインのトレーナーが全体の進み具合を見ながら、要所で専門の人に短く登場してもらう形です。こうすれば、一人に負担が集中せず、新人はそれぞれの分野で一番詳しい人から学べます。
見えにくいものを扱うのもインフラの特徴です。パケットの流れもサーバ内部の状態も目には映りません。だからOJTでは、コマンドの結果を一緒に画面で見ながら「今、何が起きているか」を言葉にして共有する時間が、とりわけ効いてきます。
このあたりは、インフラ新人が独り立ちするまでを縮める設計や、研修と現場をつなぐ研修転移の記事とも通じる話です。あわせて読むと、育成の全体像が見えてきます。
InfraAcademy を「共通の土台」に使う¶
最後に、私たちのサービスの話を少しだけ。
ここまで見てきたとおり、OJTを仕組みにする第一歩は、「何を、どの順で教えるか」を担当者の頭の外に出すことでした。とはいえ、その土台をゼロから自作するのは、忙しい現場にはなかなか荷が重い。
私たち InfraAcademy は、Linuxやネットワークの基礎を体系立てて学べる教材を提供しています。これをOJTの「共通の土台」として使うと、新人はまず教材で基礎を固め、トレーナーは現場ならではの応用に集中できます。教える中身の下地が揃うので、担当者ごとのばらつきも小さくなります。
まずはLinuxの学習ロードマップやインフラ全体の学習ロードマップを新人に渡し、そのうえで現場のチェックリストとひもづける。この一手間が、OJTを安定させます。
チーム全体の育成の仕組みづくりまで相談したい、という企業のご担当者は、InfraAcademyの法人プランからお気軽にお問い合わせください。教材の提供だけでなく、OJTの土台づくりまで一緒に考えます。
まとめ¶
最後に、今日の話を振り返っておきましょう。
現場のOJTは、多くの会社で育成の主役です。ところが、それが「先輩まかせ」のままだと、新人の育ち方は担当者の当たり外れに左右されてしまいます。
その背景には、教える中身が個人の経験に依存してばらつくことと、教える側が本業の片手間で疲弊していること——この2つの問題がありました。
だからこそ、OJTを個人の頑張りに任せず、仕組みで支える。誰が教えるかを指名し、何を教えるかをチェックリストにし、教える人自身を支える。この3つの部品を用意するだけで、OJTは驚くほど安定します。
大きな制度を一度に作る必要はありません。次に新人を迎えるとき、まずはチェックリスト一枚から始めてみてください。育成は、仕組みにした分だけ、あなたの現場の財産になります。
