新人インフラエンジニアには「壊していい環境」がいる。研修用サンドボックスの設計とコストの抑え方

こんにちは、インフラエンジニアのryuです。

新人インフラエンジニアの研修を設計していて、こんな壁に当たったことはないでしょうか。テキストも用意した、講師役の先輩も決めた。でも、肝心の「手を動かす場所」が無い。

現場にあるのは本番環境と、本番とほぼ同じ扱いのステージング環境だけ。新人に触らせるわけにはいかないので、結局は先輩の画面を後ろから眺めるだけの研修になってしまう。

これ、実はかなり多くの現場で起きています。そして育成がうまくいかない原因のうち、根性論では絶対に解決できないタイプの問題でもあります。

今日は、新人インフラエンジニアのための「壊していい環境」をどう用意するか、という話をします。技術の話というより、予算と権限をどう設計するかという、育成担当者や情報システム部門の方に向けた話です。

なぜ新人インフラエンジニアは「見ているだけ」になってしまうのか¶

まず、なぜこうなるのかを整理しておきます。原因は新人側ではなく、環境側にあることがほとんどです。

本番しかない現場では、そもそも手を出させられない¶

インフラの仕事の怖いところは、ミスの影響範囲が広いことです。アプリケーションのコードなら、バグを埋め込んでもテストやレビューで止まります。

でもインフラは違います。ファイアウォールのルールをひとつ間違えれば全社の通信が止まりますし、ディスクの操作をひとつ誤ればデータが消えます。取り返しがつく範囲が、極端に狭い。

だから先輩は、良かれと思って新人にキーボードを渡しません。これは判断としては正しいのです。正しいのですが、その状態が半年続くと、新人はいつまでも作業できるようにならない。

つまり悪いのは先輩でも新人でもなく、「触ってよい環境が用意されていない」という前提条件のほうです。ここを変えないかぎり、研修の中身をいくら磨いても結果は変わりません。

見ているだけの学習は、驚くほど残らない¶

もうひとつ。人は、自分で失敗しないと覚えません。

サーバーにログインできない、という状況を考えてみてください。手順書を読んで理解したつもりでも、実際に自分でつまずいて、鍵の権限が緩すぎて弾かれていたと気づいた経験があるかどうかで、次に同じ場面に出会ったときの速度がまったく違います。

自転車の乗り方を動画で100本見ても乗れるようにならないのと同じです。転ぶ経験が要る。ただし、転んでも大怪我をしない場所で転ばせる必要がある。その場所が、検証環境です。

厚生労働省の令和7年度「能力開発基本調査」によると、OFF-JT（通常の業務を離れて行う研修）を受講した労働者は37.3％で、正社員に限っても44.5％にとどまります。研修の機会そのものが十分とは言えない中で、その貴重な時間を「眺めるだけ」で消費してしまうのは、あまりにもったいない話です。

検証環境（サンドボックス）とは、本番から切り離され、壊しても誰にも迷惑がかからない実験用の環境のこと。砂場という語源のとおり、崩して作り直すことを前提にした場所です。

「壊していい環境」は三段構えで用意する¶

では具体的に何を用意すればいいのか。ひとつの大きな環境を作ろうとすると、費用も管理も重くなって頓挫します。

おすすめは、目的別に三段構えにすることです。それぞれ、壊れたときの影響範囲とコストがまったく違います。

一段目は、自席で完結させる¶

最初の一段目は、新人のPCの中で完結させます。仮想マシンでもコンテナでも構いません。

ここでやるのは、Linuxのコマンドに慣れる、設定ファイルを編集して壊して直す、といった基礎の反復です。壊れてもPCの中の話なので、誰の承認も要りませんし、費用もかかりません。

具体的な作り方は個人の学習でも同じなので、自宅で作るインフラ学習ラボの作り方やDockerをLinuxにインストールする手順がそのまま使えます。研修担当者が一から手順を書き起こす必要はありません。

ここを飛ばしてクラウドから始めると、コマンドの練習に課金が発生するという妙なことになります。無料でできることは、無料の層でやりきるのが鉄則です。

二段目は、複数台がつながった構成を触らせる¶

一段目だけでは学べないことがあります。それは、サーバーが複数台あって、その間をネットワークがつないでいる状態です。

Webサーバーとデータベースサーバーを分けて、通信ができない原因を切り分ける。この経験は、1台のPCの中だけでは得にくい。

ここで初めて、チームで共有する検証環境や、クラウド上の小さな構成が必要になります。AWSのEC2とは何かのような基本を押さえたうえで、実際に自分でインスタンスを起動させてみる段階です。

三段目は、本番に近い構成を「期限つき」で¶

三段目は、本番に近い構成をまるごと作らせる段階です。ロードバランサーがあって、冗長化されていて、監視も入っている。

ここは費用がかかるので、常時用意するのではなく、期間を区切って払い出します。「この2週間だけ、この構成を作り切ってください」という形です。

期限を切ることには、費用以外の効果もあります。締め切りがあると、新人は分からないところを自分で調べるか、先輩に聞くかを判断するようになる。無期限に用意された環境は、なぜか使われないまま終わります。

なお、三段目まで全員に用意する必要はありません。一段目と二段目を全員に配り、三段目はチーム単位で1セットを共有する、という配り方でも十分に回ります。

コストの不安は、根性ではなく仕組みで抑える¶

「新人にクラウドアカウントを渡したら、消し忘れで請求が跳ね上がるのでは」

この心配、まったく正しいです。実際に起きます。ただ、これは新人の注意力で防ぐものではなく、仕組みで防ぐものです。

予算の上限とアラートを、環境より先に用意する¶

順番が大事です。アカウントを作ってから予算を考えるのではなく、予算の上限とアラートを設定してからアカウントを渡します。

AWSであれば、AWS Budgets で月額の上限としきい値を決めておきます。実績が上限に近づいたときだけでなく、この使い方を続けたら月末にいくらになるかという予測値でも通知できるので、気づいたときには手遅れという事態を避けられます。

しきい値は、非本番環境ほど厳しくして構いません。研修用アカウントで月に数万円を超えたら、それは学習ではなく消し忘れです。

使い終わったら返す、を自動化する¶

もうひとつ効くのが、環境を「貸し出す」という考え方にすることです。期限が来たら自動で回収する。

AWSには Innovation Sandbox on AWS という公式のソリューションがあり、期間や予算の上限に達したアカウントを自動でクリーンアップしてプールに戻す仕組みが用意されています。研修のたびに手作業でアカウントを掃除している現場には、考え方だけでも参考になります。

そこまで作り込まなくても、まずは夜間の自動停止だけで効果が出ます。研修は基本的に日中しか行われないので、夜と週末に動いているサーバーは、ほぼ全部が消し忘れです。

# 研修用のタグが付いた EC2 を、毎晩まとめて停止する
INSTANCES=$(aws ec2 describe-instances \
  --filters "Name=tag:Environment,Values=training" \
            "Name=instance-state-name,Values=running" \
  --query "Reservations[].Instances[].InstanceId" \
  --output text)

if [ -n "$INSTANCES" ]; then
  aws ec2 stop-instances --instance-ids $INSTANCES
fi

タグを付けるルールさえ徹底すれば、あとはこれを毎晩動かすだけです。研修環境のコスト管理でいちばん効くのは、高度な最適化ではなく、使っていない時間に止めることです。

「いくらかかるか分からない」を先に潰しておく¶

予算が通らない理由の多くは、金額が高いことではなく、金額が読めないことです。従量課金は上振れの可能性がある、という一点で稟議が止まります。

なので、環境の申請を出す前に、上限額を先に決めてしまうのが近道です。ひとり月あたりいくらまで、研修期間の全体でいくらまで、と決めてしまえば、それは従量課金ではなく固定費として説明できます。

上限に達したらどうするのかも、あわせて決めておきます。自動で停止するのか、追加を承認するのか。ここまで書いてあれば、稟議はかなり通りやすくなります。

権限は、どこまで渡すのがちょうどいいのか¶

環境を用意したら、次は権限の線引きです。ここを曖昧にすると、せっかく作った検証環境が「結局こわくて触れない環境」になります。

考え方はシンプルで、新人が自分の環境の中で何をしても、外に影響が出ないようにします。逆に言えば、その範囲の中では、消すのも作り直すのも自由にさせます。

大事なのは、削除の権限まで渡すことです。作れるけど消せない環境だと、新人は失敗を恐れて何も作らなくなりますし、消せないリソースがそのまま課金され続けます。

削除させることには、学習上の意味もあります。作り直しの回数がそのまま習熟になるからです。一度しか作れない環境では、手順を写経して終わってしまいますが、何度でも作り直せるなら、二回目からは自分の頭で組み立てるようになります。

そのうえで、本番環境の権限は別枠にします。いつ渡すかは、期間ではなく行動で決めるのが安全です。検証環境で同じ作業を手順書なしで完遂できたら、次は先輩の立ち会いのもとで本番、という段階を踏みます。

このあたりの進み具合を感覚で判断すると、人によってばらつきます。研修の進捗とスキルを見える化する方法で書いたように、何ができたら次に進むのかを事前に決めておくと、権限の受け渡しも揉めません。

環境を用意しただけでは、育ちません¶

最後に、いちばん見落とされがちな点をひとつ。

検証環境を用意して「自由に触っていいよ」と伝えるだけでは、多くの新人は何もできません。何をすればいいのか分からないからです。

必要なのは、環境とセットの課題です。しかも「Webサーバーを立ててください」ではなく、完成の状態が自分で判定できる課題にします。ブラウザでこのページが表示されたら完了、という形です。

そして、壊れた状態から復旧させる課題を必ず入れてください。正常に作る練習だけでは、障害対応はできるようになりません。あらかじめ設定を壊した状態のサーバーを渡して、原因を突き止めさせる。これが実務にいちばん近い訓練になります。

壊し方は、凝らなくて大丈夫です。設定ファイルの一行をコメントアウトする、サービスを停止しておく、権限を変えておく。現場で実際に起きるトラブルは、だいたいその程度の単純な原因から始まります。

このとき、答えをすぐに教えないのがコツです。詰まっている時間そのものが訓練なので、15分は自力で粘らせて、それでも進まないときだけヒントを出す。この線引きを先に本人と共有しておくと、聞くタイミングで悩ませずに済みます。

このとき役に立つのが、ブレームレス・ポストモーテムを新人育成に組み込む設計の考え方です。失敗を責めずに、何が起きたかを一緒に振り返る。検証環境は、そのための安全な舞台でもあります。

課題そのものを一から作るのが負担であれば、既製の教材を土台にするのも手です。InfraAcademy では、Linuxやネットワークをブラウザ上で手を動かしながら学べる講座を用意していて、Linuxの学習ロードマップに沿って進められます。環境構築でつまずく時間をゼロにできるので、一段目の代わりとしても使えます。

自社の新人インフラエンジニア研修に組み込む形での導入をお考えでしたら、法人プランのご案内もご覧ください。研修の設計そのものからご相談いただけます。

まとめ¶

新人インフラエンジニアが育たない原因の多くは、本人のやる気ではなく、手を動かせる環境が無いことにあります。

用意するときは、いきなり大きな環境を作らず、自席のPC・チームの共有環境・クラウドの期限つきアカウントの三段構えにする。費用は予算の上限と夜間の自動停止という仕組みで抑える。権限は、自分の環境を壊す自由まで含めて渡す。

そして、環境と課題はセットで用意する。ここまでやって、ようやく「見ているだけ」の研修から抜け出せます。

新人が最初にサーバーを壊した日は、実は歓迎すべき日です。壊していい場所で壊せたということですから。そういう場所を先に用意しておくことが、育成担当者にできるいちばん確実な準備だと思っています。

研修の全体像から見直したい場合は、インフラ未経験の新人研修をどう設計するかもあわせて読んでみてください。

参考記事¶

• 令和7年度「能力開発基本調査」の結果を公表します｜厚生労働省
• Best practices for AWS Budgets - AWS Cost Management
• Create temporary sandbox environments with configurable security and spend monitoring controls - Innovation Sandbox on AWS
• aws-solutions/innovation-sandbox-on-aws (GitHub)
• Best practices for creating and managing sandbox accounts in AWS｜AWS Cloud Operations Blog