こんにちは、インフラエンジニアのryuです。
先日、従業員100人ほどの会社の方から、こんな話をうかがいました。
「インフラを見ているのが、自分ともう1人だけなんです。今度そこに新卒が1人入ることになったんですが、正直、どう育てればいいのか分かりません」
似たような状況の方は、たぶん少なくないのではないでしょうか。
育成の記事を読むと、研修カリキュラムを組み、トレーナーを任命し、進捗を可視化して……と書いてあります。どれも正しいのですが、そもそも教える側が1人しかいない現場では、その1人が日々の運用で手いっぱいです。
今日は、インフラエンジニアが2〜3人しかいないチームで新人を育てるにはどうするか、という話をします。人を増やさずに済ませる魔法の話ではありません。教える人の時間が有限であることを前提に、育成の設計そのものを変えるという話です。
少人数チームの育成は、まず「引き算」から始まる¶
大きな会社の育成と、少人数チームの育成は、何が違うのでしょうか。
いちばん大きな違いは、教える側の時間が固定されていることです。人数の多い部署なら、育成に週5時間かかるなら5人で1時間ずつ分けられます。2人のチームでは、その5時間がまるごと1人にのしかかります。
ですから、少人数チームで最初にやるべきことは、カリキュラムを足すことではありません。今年は何を教えないかを決めることです。
もうひとつ、見落とされがちな違いがあります。少人数チームでは、育成の遅れがそのまま事業のリスクになるということです。
インフラを2人で見ている会社で、そのうち1人が転職したらどうなるでしょうか。残った1人に全部がのしかかり、その人も限界を迎える。よくある展開ですよね。
つまり少人数チームにとって、新人を育てることは「余裕があればやる活動」ではなく、業務継続の一部です。優先度をそこまで上げないと、日々の運用に押し流されて必ず後回しになります。
「一通り全部」は、少人数チームでは絶対に終わらない¶
新人の育成計画を立てるとき、つい網羅的にしたくなります。Linux、ネットワーク、クラウド、監視、セキュリティ、社内システム。どれも必要に見えますよね。
けれど、教える側が1人で、その人が運用も兼任しているなら、1年で丁寧に教えられるのはせいぜい2領域です。5領域を薄く広げると、どれも「聞いたことはある」で止まります。
判断の基準はシンプルで、その会社で今いちばん人手が足りていない作業は何か、です。そこに直結する領域から埋めます。
サーバーの構築と障害対応が回っていないなら、Linuxを厚く。拠点の増設やVPNの調整が滞っているなら、ネットワークを厚く。「将来必要かもしれないから」という理由の領域は、来年に送ります。
厚生労働省の能力開発基本調査でも、人材育成の課題として「指導する人材が不足している」「人材育成を行う時間がない」が毎年のように上位に並びます。つまりこれは、あなたの会社だけが特別に苦しいわけではありません。多くの現場が同じ制約の中で、なんとか順番をつけてやりくりしているということです。
優先順位は、業務の棚卸しから逆算する¶
何を教えるかで迷ったら、先輩の1週間を書き出してみるのがおすすめです。
やり方は難しくありません。1週間、自分が手を動かした作業をメモに残すだけです。そのうえで、各作業に「新人に渡せそうか」の印をつけます。
| 印 | 作業の性質 | 育成での扱い |
|---|---|---|
| ◎ | 手順が決まっていて、失敗しても戻せる | 最初の3か月で渡す候補 |
| ○ | 手順はあるが、判断がいくつか混ざる | 半年後に、横で見せながら渡す |
| △ | 前提知識がないと危ない（本番の変更など） | 1年後。それまでは見学のみ |
| × | 経営判断や契約が絡む | 渡さない。教える対象からも外す |
この表を1枚作るだけで、「何から教えるか」の議論がかなり具体的になります。抽象的な研修計画より、こちらのほうが早く効きます。
教える時間を増やさずに、学ぶ時間を増やす¶
さて、教える範囲を絞ったとして、それでも先輩の時間は足りません。ここからは、投入する時間あたりの効果を上げる話です。
考え方は3つあります。基礎を外に出すこと、既存環境を教材にすること、そして質問の受け方を変えることです。
基礎は、外の教材に任せてしまってよい¶
ls や grep の使い方、サブネットマスクの計算、DNSの仕組み。この手の基礎は、どの会社で学んでも中身が同じです。
同じ内容を、貴重な先輩の時間を使って対面で教える理由は、実はあまりありません。ここは書籍やオンライン教材に任せて、先輩は「うちの環境ではこうなっている」という部分に集中したほうが、全体としてうまく回ります。
InfraAcademy でも、こうした基礎の部分はLinuxの学習ロードマップやネットワークの学習ロードマップとして順番どおりに並べてあります。何をどの順で触ればいいかが決まっていれば、新人は先輩の手が空くのを待たずに進められます。
外部の教材を選ぶときの観点は、インフラの外部研修、どれを選べばいい？失敗しない研修サービスの選定基準とチェックリストにまとめてあります。少人数チームの場合は「質問対応まで含まれているか」を特に見ておくとよいです。
少人数チームにとっての外部教材の価値は、知識そのものより「先輩に聞かなくても進める時間」を作れることにあります。
自社の環境そのものが、いちばんいい教材になる¶
一方で、外に出せないものもあります。それが、自社の構成です。
なぜこのネットワーク構成なのか。なぜこのサーバーだけOSのバージョンが古いのか。この辺りは、どの教科書にも書いてありません。そして、少人数チームではこの知識が完全に属人化しています。
ここでおすすめしたいのが、新人に構成図と手順書を書かせることです。
教わった内容を新人がドキュメントにまとめ、先輩がそれをレビューする。この形なら、先輩が使う時間は「説明する時間」から「読んで直す時間」に変わります。所要時間は、だいたい半分以下になります。
しかも副産物として、いままで誰も書いていなかったドキュメントが増えていきます。属人化の解消についてはインフラが「あの人しかわからない」問題。属人化を解消する育成とナレッジ継承の設計でも触れましたが、少人数チームではこれが育成とほぼ同じ作業になります。
質問は、溜めてもらったほうがお互い楽になる¶
もうひとつ、地味ですが効くのが質問のルールです。
新人がその都度話しかけてくる状態は、一見すると面倒見がよさそうに見えます。ただ、割り込みを受けた側は、そのたびに作業の文脈を失います。1回5分の質問でも、復帰まで含めれば15分が飛びます。
ですから、緊急でないものは溜めてもらいます。たとえば「1日2回、11時と16時にまとめて聞く」と決めるだけでも、先輩の集中時間は目に見えて増えます。
同時に、新人の側にも効果があります。次の質問時間まで自分で調べる時間ができるので、聞く前に答えにたどり着くことが増えるからです。
質問を書き出す過程そのものにも意味があります。「エラーが出ました」ではなく「この操作をしたら、このメッセージが出た。ここまでは確認済み」と整理する練習になるからです。この書き方が身につくと、そのまま障害報告が書けるようになります。
ただし、この運用には条件があります。手が止まって困っているときは、時間を待たずに聞いてよいと、明確に伝えておくことです。これを言わないと、真面目な新人ほど3時間黙って悩みます。
「壊せる環境」が無い会社ほど、育成が止まる¶
少人数チームでよく聞く悩みが、練習させる場所がないというものです。
本番環境しかないので触らせられない。だから見学だけ。結果として、半年経っても新人が何もできない。この流れは本当に多いです。
ただ、ここは工夫の余地があります。クラウドの小さなインスタンスを1台、あるいは社内の余ったPCにLinuxを入れるだけでも、練習環境としては十分に成立します。月に数千円で、新人が失敗できる場所が手に入ると考えれば、安い投資ではないでしょうか。
料理に少し似ています。レシピを100回読んでも、包丁を握らなければ料理はできるようになりません。かといって、いきなりお客様に出す一皿を任せる人もいないはずです。練習用のまな板がいる、というだけの話です。
そして、練習環境の効果は新人だけに及ぶものではありません。先輩の側も、本番で試せなかった設定変更をそこで検証できるようになります。育成のために用意したものが、結果的にチーム全体の道具になります。
環境の作り方とコストの抑え方は、新人インフラエンジニアには「壊していい環境」がいる。研修用サンドボックスの設計とコストの抑え方に詳しくまとめてあります。
本番に触らせる順番を、先に決めておく¶
練習環境で慣れたら、次は本番です。ここでも段階を決めておくと、判断に迷いません。
最初は参照だけ。ログを見る、設定を確認する、監視画面を読む。次に、戻せる変更。アカウントの追加や、決まった手順のある作業です。最後に、影響範囲の大きい変更を、先輩が横で見ている状態で。
この順番は、さきほどの棚卸し表の◎○△とそのまま対応します。表を作ってあれば、改めて考え直す必要はありません。
ひとつ補足すると、段階を上げる判断は「本人ができそうか」ではなく「戻せるか」で決めるのがコツです。できそうかどうかは主観が入りますが、戻せるかどうかは作業の性質で決まります。判断に迷う回数が、ぐっと減ります。
進み具合の確認は、月1回15分でも十分¶
育成を始めると、今度は「ちゃんと進んでいるのか分からない」という悩みが出てきます。
とはいえ、少人数チームで立派な評価シートを運用するのは現実的ではありません。月に1回15分、棚卸し表を一緒に眺めて、渡せた作業に印をつけていくだけで足ります。
大事なのは、進捗を先輩の印象ではなく、渡した作業の数で見ることです。印象で判断すると、忙しい月ほど「あまり成長していない気がする」という感想になりがちですが、実際には作業が2つ増えていたりします。
もう少し体系立てて見たい場合は、新人インフラエンジニアのスキルの見える化と進捗管理のすすめで紹介している考え方を、規模に合わせて簡略化して使うとよいでしょう。
少人数チームで、やりがちな失敗¶
最後に、うまくいかない例も挙げておきます。心当たりがあれば、修正は早いほうがよいです。
| よくある状態 | 何が起きるか | 代わりにどうするか |
|---|---|---|
| 「暇なときに教える」と決めている | 暇なときが永遠に来ない | 週1回30分でいいので枠を固定する |
| 教える内容を先輩の記憶だけで決める | 抜けが出て、新人が同じ壁で何度も止まる | 棚卸し表と学習ロードマップを基準にする |
| 質問にその都度すべて答える | 先輩の作業が進まず、育成が嫌になる | 時間を決めてまとめて受ける |
| 本番作業を「まだ早い」と渡さない | 1年経っても戦力にならない | 参照→戻せる変更→大きい変更、と段階で渡す |
| ドキュメントを先輩が書く | 先輩の負担が減らず、新人も理解が浅い | 新人が書き、先輩がレビューする |
どれも「忙しいから」という同じ理由から生まれます。ただ、忙しさは放っておいても減りません。減らすには、育成を先に進めるしかない、というのが正直なところです。
なかでも最初の1つ、枠を固定する話はぜひ試してみてください。週1回30分でも、カレンダーに入れて動かさないと決めるだけで、半年後には13回分の差がつきます。「暇なときに」と言い続けた場合の回数は、経験上ゼロです。
チーム全体の受け入れ設計を見直したいときは、インフラ未経験の新人研修、どう設計する？現場で戦力になるまでの育て方や、教える側の役割を整理した“背中を見て覚えろ”では、もう育たない。インフラ新人のOJTを仕組みに変えるトレーナー制度のつくり方もあわせてご覧ください。
なお、社内で基礎から教える余力がどうしても作れない場合は、その部分だけを外に出す選択肢もあります。InfraAcademy では法人向けに、Linuxやネットワークの基礎を体系立てて学べる仕組みをご用意しています。詳しくは法人プランのご案内をご覧ください。
まとめ¶
少人数のインフラチームで新人を育てるときの要点を、もう一度整理します。
まず、教える範囲を絞ること。1年で丁寧に教えられるのは2領域までで、優先順位は業務の棚卸しから逆算します。
次に、時間あたりの効果を上げること。基礎は外部の教材に任せ、先輩は自社固有の部分に集中します。ドキュメントは新人が書き、先輩はレビューに回ります。
そして、失敗できる場所を用意すること。月数千円の練習環境があるかないかで、1年後の姿はまったく変わります。
人数が少ないことは、確かに不利です。ただ、少人数チームには「意思決定が早い」という強みもあります。今日この記事を読んで、来週から週30分の枠を作ることだって決められるはずです。
その30分の積み重ねが、1年後に「もう1人分」の戦力になります。焦らず、けれど先送りせずに始めてみてください。
