新入社員にインフラエンジニアとしての基礎を身につけてほしい。しかし、ITの知識がほとんどない状態から、Linuxサーバーやネットワークの構築まで学べるのだろうか。研修を検討する企業の人事・育成担当者や配属先の上司の方にとって、学習内容だけでなく、受講生が何につまずき、どのように成長していくのかも気になるところだと思います。
本コラムでは、文系出身でプログラミングもインフラ構築も未経験だった新入社員Aさんが、神田ITスクールの「ITインフラ・2ヶ月コース」を受講した様子を紹介します。最初の1ヶ月はLinuxの操作からWebサーバー構築へ、続く1ヶ月はネットワークの仕組みから機器の設定へと進み、それぞれの終盤にチームでの模擬構築演習に取り組みます。同期と協力し、講師の助言を受けながら、知識だけでなく報告・連絡・相談や計画管理も学んだ2ヶ月間の記録です。
本文の一人称の語りや会話は、研修の流れを伝えるために再構成した表現です。学習の進み方や到達度には個人差があります。
目次
0.はじめに
本コラムの設定・シチュエーションは以下の通りです。
| 設定事項 | 内容 |
|---|---|
| 受講者 | 同じ会社の新卒社員2名。Aさんは文系・IT未経験、同期のBさんはプログラミング経験があるもののインフラ構築は未経験 |
| 研修の目的 | Linuxサーバー・ネットワークの基礎知識と構築手順を学び、問題解決、報連相、計画管理、説明・コミュニケーション力を養う |
| 受講コース・期間 | ITインフラ・2ヶ月コース |
| 主な学習内容 | Linuxの基本操作、ファイル管理、ユーザー・権限管理、Webサーバー構築、シェルスクリプト、TCP/IP、ルーティング、スイッチング、VLAN、セキュリティ、ネットワーク機器の操作 |
| 最終演習（Linux） | 2名で取り組む6日間のLinuxサーバー構築模擬演習 |
| 最終演習（ネットワーク） | 2名で取り組む7日間のネットワーク構築模擬演習 |
1. Linuxサーバーの基礎・構築｜ Linuxの基礎知識とCLI操作を学ぶ
最初の1ヶ月は、Linuxの基本操作、ファイル管理、ユーザー・権限管理、Webサーバー構築、シェルスクリプトを学びます。
入社して間もない私にとって、「インフラエンジニア」はまだぼんやりした職業でした。Webサイトを作る人なら何となく想像できても、そのサイトが動くためのサーバーやネットワークを整える仕事については、正直なところほとんど知りません。研修初日に「まずはLinuxの操作から始めます」と聞いたときも、画面に並ぶ英語の文字や記号を見て、「これを2ヶ月後には自分で扱えるようになるのかな」と不安になりました。
最初の1ヶ月で学ぶのは、Linuxの基礎、サーバー構築、シェルスクリプトです。まず、OSやオープンソースの考え方、学習環境の仕組みを知り、コマンドラインインターフェース（CLI）で操作する練習を始めました。普段のパソコンでは画面上のアイコンをクリックして操作してきたので、文字で指示を出す方法は新鮮でした。同時に、スペルを一文字間違えるだけで思うように進まなくなる難しさもありました。
慣れないうちは、講師の説明を聞いているときは理解できた気になるのに、いざ自分で入力すると、コマンド名の打ち間違いや、指定する場所の勘違いでエラーになることが多かったです。最初は「動きません」とだけ伝えていましたが、その聞き方では何を確認してほしいのか、相手にも分かりません。講師から「どの操作をして、何が表示された？」「コマンドとエラーメッセージをもう一度見てみよう」と質問され、ようやく入力した文字の違いに気づくことが何度もありました。 そのうち、「実行したコマンド」「期待していた結果」「実際に表示された内容」を順番に整理してから質問するようになりました。間違いを指摘してもらうだけならその場で終わりますが、自分で原因を探す習慣がつくと、次に同じようなエラーが出たときの対処が変わります。目の前の操作に必死だった私にとって、これは技術と同じくらい大きな学びでした。
※当スクールの特徴：講師が重視する、つまずきの確認
この段階で重要なのは、受講生Aさんが「分からない」と感じている箇所を具体化することです。
講師は問いかけを通して受講生が確認すべき箇所を絞り込めるよう支援するとともに、自分の状況を整理して質問する方法も指導します。
ファイルやディレクトリの扱いに慣れてくると、ユーザーとグループ、パーミッション（アクセス権限）、テキストファイルの編集、ファイル操作、プロセス管理へと学習が進みました。最初はコマンドを覚えるだけで精いっぱいでしたが、「誰がこのファイルを読めるのか」「どのユーザーがこの処理を動かすのか」と考えると、一つひとつの設定がシステムを安全に使うための決まりだと分かってきます。権限の記号や数字はなかなか頭に入りませんでしたが、2進数や8進数の考え方を学び、実際に設定を変えて結果を確かめることで、少しずつ理解できました。
続くサーバー構築では、学んだコマンドが実際の用途につながり始めました。パッケージ管理でソフトウェアを導入し、SELinuxやfirewalldなどのセキュリティ設定を確認する方法や、Sambaによるファイル共有、FTPによる転送、SSHによる接続などを通じて、サーバーが外部とどのように関わるかを学びました。さらにApacheとPHPの環境を用意し、MariaDBなどのデータベースを扱いながら、Webアプリケーションを動作させるための構成を理解していきました。他にもTomcatとJavaでのWebアプリケーション構築や、NTP、Linuxの保守やトラブルシューティングについても学ぶことができ、必ずしも1つの手順だけが正解なのではなく、要件に応じて組み合わせを変えることも大事なのだということを知りました。
初めて自分が立てたWebサーバーでちゃんとWebページが表示されたときは、うれしくて思わずBさんに画面を見せました。とはいえ、表示できれば終わりではありません。サービスが起動しているか、設定ファイルは適切か、通信を許可する設定になっているか。画面に変化がないときも、確認する場所は一つではないのです。講師に「ブラウザだけを見ず、サーバー側では何が起きているか考えてみよう」と助言され、設定ファイルや動作状態を確認してから操作をやり直すようになりました。
シェルスクリプトの学習では、さらに別の壁にぶつかりました。複数のコマンドを一つのファイルにまとめて実行できることは便利そうですが、変数、入力、演算、条件分岐、繰り返し、配列、関数といった考え方は、未経験の私には初めてのものばかり。正規表現やsed、awkといった文字列・テキスト処理の内容も、最初は呪文のように見えました。処理の順番を紙に書き、「この条件ならどちらに進むのか」を確認してから入力すると、ようやく課題を整理できるようになりました。
一方、Bさんは大学時代に別のプログラミング言語を学んだ経験があり、シェルスクリプトの課題を比較的スムーズに進めていました。少しうらやましい気持ちもありましたが、行き詰まったときに「この条件のとき、どうしてここを通るんだろう」と相談すると、考える順序を一緒に整理してくれました。ただし、同期同士の説明で理解したつもりにならないよう、最後は講師にも確認します。認識が合っているかを確かめ、補足の知識を教えてもらうことで、「何となく動いた」という状態から、「なぜこの処理が必要なのか」を理解した状態へと一歩進めました。
研修では毎日の進捗を意識し、週次面談の機会もありました。面談担当の方は学習の進み具合だけでなく、生活リズムや困りごとも気にかけてくれます。私は当初、予定より課題が遅れていても「もう少し頑張れば取り戻せる」と考え、一人で抱えがちでした。しかし、遅れを早めに共有したほうが、復習の優先順位や翌日の進め方を相談できると面談担当の方からアドバイスを受けました。そして、物は試しにと実践していくことで、担当講師から具体的なアドバイスを受けやすくなりました。そうしているうちに、自分でもある程度見積もりや優先順位を判断できるようになりました。予実管理とは単に予定表を埋めることではなく、計画と実績の差を見て次の行動を決めることなのだと実感しました。
※当スクールの特徴：週次面談
普段質問対応している講師とは別のスタッフが、学習の状況や日々の出来事を週次面談という形でヒアリングしています。
担当講師には直接相談しづらいことも、別のスタッフが話を聞くことで、受講生の不安や悩みを把握しています。
必要に応じて関係者と情報を共有し、受講生への適切なフォローや研修全体の品質向上につなげています。
1ヶ月目の終わりが近づいても、まだコマンドをすべて暗記できたわけではありませんでした。それでも、目的に応じて資料を調べ、どこを確認すべきか考えながら設定を進められる場面が増えました。「何を入力するか」だけでなく「何のための設定か」を意識できるようになったことが、次の模擬構築演習への小さな自信につながりました。
2. Linuxサーバー模擬構築演習｜要件定義から発表までを経験
Linux単元の最終演習では、顧客役へのヒアリング内容をもとに要件を整理し、チームでLinux仮想環境内にWebサーバーを構築していきます。ここで目指すのは、研修で学んだ基礎知識を組み合わせることと、周囲と相談・協力しながら開発を進める経験を積むことです。
本演習を通して、顧客役へのヒアリングから設計、構築、テスト、成果発表までを経験します。
| 工程 | 取り組み・成果物 |
|---|---|
| 要件確認・設計 | 顧客役へのヒアリング、設計・レビュー |
| 構築 | 設計をもとにWebサーバーを構築 |
| テスト | 想定通りにアプリが起動するか、権限割り振りができているのか動作確認 |
| 発表 | 発表資料の作成、リハーサル、上司や参加者からの質問への回答 |
Linux単元の最後には、Bさんと二人で6日間のWebサーバー構築模擬演習に取り組みました。それまでの学習は、教材に沿って一つずつ課題を解く形が中心です。ところが演習では、顧客役の講師に必要なことを聞き、要件を整理し、設計し、Linuxの仮想環境に構築して、テスト結果を示すところまで自分たちで進めます。技術の復習であると同時に、仕事として相手の要望に応える練習でもあります。
開始前に私が心配していたのは、構築の難しさだけではありません。限られた6日間で二人の作業をどう分けるか、顧客役に何を質問すればよいか、進捗が遅れたときにどう報告するか。授業で学んだ内容を組み合わせるだけでなく、自分から考えて動かなければならないことに緊張しました。
1日目：顧客との打ち合わせ・要件定義
初日は顧客役の講師との打ち合わせです。普段の授業を担当する講師とは別の方で、特にビジネスマナーを厳しく確認すると聞いていたため、その日は朝礼の時から気持ちが落ち着きませんでした。最初の挨拶や相手の話を途中で遮らないこと、確認したい内容を簡潔に伝えること。技術以前に、社会人として当たり前に求められる振る舞いを意識しました。
打ち合わせでは、利用者や運用方法について確認し、後から認識違いが生じないようメモを取ります。私は話を聞きながら書くことに精いっぱいで、聞くべきことを一つ飛ばしそうになりましたが、Bさんが用意していた質問項目に気づかせてくれました。終了後は議事録と要件定義書を作成し、WBSに工程と担当を整理しました。顧客役にレビュー日時を確認するメールも、件名、宛名、用件、締めくくりまで見直して送信しました。
「質問できなかったことがあれば、構築時に困るかもしれない」。そう考えると、曖昧な表現をそのまま残す怖さが分かりました。打ち合わせ後も二人でメモを照らし合わせ、確認事項と決まった事項を分けてまとめました。
2日目：要件定義レビュー、設計
要件定義書のレビューでは、限られた時間の中で作成内容を説明し、顧客役と認識を合わせます。前日に挨拶や説明の順番を練習したおかげで、緊張しながらも最後まで話すことができ、ビジネスマナーについても問題ないと評価してもらえました。ただ、要件そのものには細かな抜けや認識違いがありました。相手の発言を自分たちなりに解釈した箇所ほど、確認が必要だと痛感しました。
レビュー後は指摘事項を一覧にし、修正する内容と担当を決めました。私が要件定義書の修正を進める間、Bさんは先に着手できる設計書の準備を担当する分担になりました。設計書作成では、システム全体の構成、仮想サーバーの構成、ユーザー管理、データベースサーバーとWebサーバーの設定を、文章と図で具体化していきます。講師からは「設計書は書いた本人以外にも伝わる必要がある」と言われ、設定値だけでなく、その設定が必要な理由や、他の人から見ても読みやすいかどうかまで意識するようになりました。
3日目：構築
いよいよ構築作業です。仮想OSを準備し、ユーザーを作成し、ファイル転送やSSH接続の設定を行い、データベースサーバーとWebサーバーを構築して、確認用のWebサイトを配置します。机上では理解していたつもりでも、一連の作業として順に行うとなると、「先に何をしておく必要があるか」を考えることが欠かせません。順番を取り違えると、後の工程でエラーの原因になってしまいます。
私は作業のたびに設計書と照らし合わせ、実行したコマンドと結果をメモしました。途中で画面の表示が想定と違うことがありましたが、すぐに設定を変更するのではなく、どこまで正常に進んだかを確認します。以前の私なら「とにかくもう一度やってみよう」としていたところです。Bさんとも進捗を共有し、困っている作業がないか確認し合いました。また、二人の間で認識がずれていることがあった場合はすぐに担当講師に質問し、正しい方向性を確認しながら進めました。
4日目：構築（続き）・テスト
4日目は、構築できた環境を別の仮想環境でも再現できるかを試しました。Bさんの環境に同じ手順で構築し直したところ、途中でインストール時のエラーが発生。最初は環境の違いかと思いましたが、二人で手順書と作業履歴を突き合わせると、手順書に書き起こす際に記載漏れをしていた引数があったことが原因でした。自分の環境で動いていても、手順が正しく残っていなければ、他の人は同じものを作れません。
修正した手順で再構築できたので、運用を想定したテストケースを整理し、実行結果を記録しました。Webサイトにアクセスできるか、想定したユーザーが必要な操作をできるか、逆に権限のない操作が許可されていないか。項目を一つずつ確かめるうちに、一部のユーザー権限が期待どおりになっていないことが分かりました。残り時間も考え、原因調査は翌日の優先事項として共有しました。
5日目：テスト（続き）・発表準備
朝の進捗確認では、未解決の権限の問題を担当講師に報告しました。「設定した値と、実際にアクセスしているユーザーは一致している？」というヒントをもらい、設定ファイルと確認手順を順に見直します。原因になりそうな箇所を絞って再度テストすると、期待どおりの結果になりました。答えをそのまま教わったのではなく、自分たちで確認して解決できたことがうれしかったです。
テストが一段落したら、発表資料の作成に移ります。Bさんと分担し、要件、設計、構築した環境、テスト結果、苦労した点を盛り込みました。資料を並べるだけでは伝わりにくかったため、「依頼されたこと」「実現したこと」「確認したこと」の順に構成を整理。画面の説明に専門用語が多すぎないかも、お互いに読み返しました。
6日目：リハーサルと最終発表
午前中はリハーサルです。説明の持ち時間を測り、画面を切り替えるタイミングや、デモンストレーションに使うコマンドを確認しました。
午後の発表会では、会社の上司の方々も見守る中で成果を説明します。練習を重ねたつもりでしたが、デモンストレーションの途中でコピーするコマンドの範囲を間違え、エラーが表示されてしまいました。頭が真っ白になりかけたものの、入力内容を見直すと貼り付け漏れに気づき、落ち着いて修正できました。
発表後は構成や権限設定について質問を受けました。答える前に少し考える必要がある場面もありましたが、設計書やテスト結果を根拠に説明できました。演習初日には、顧客役に話しかけるだけで緊張していた自分が、失敗への対処まで含めて人前で説明している。小さなミスはあっても、最後までやりきれたことが自信になりました。
※当スクールの特徴：中間発表・報告会
神田ITスクールでは1ヶ月目の単元が終わる頃を目安に、中間発表・報告会を設けています。
発表会では、受講生自身の発表を通して、理解度や習熟状況を確認できます。
その後の報告会では、その時点での進捗や理解度、受講態度をもとに、今後の指導方針などについてご報告・共有いたします。
3. ネットワークの基礎・構築｜実機を使って構築をしてみる
2ヶ月目は、TCP/IP、ルーティング、スイッチング、VLAN、セキュリティ、ネットワーク機器の操作を学びます。
2ヶ月目に入ると、学習の中心はLinuxからネットワークへ移りました。教室にスイッチ、ルーター、LANケーブル、操作用のPCなどの機材が用意されたときは、少しわくわくしました。日常生活でインターネットを使っていても、その裏側でどんな機器が働いているかを考える機会はほとんどありません。目の前のケーブルを接続し、自分で設定した結果が通信に反映されるのは、テキストを読むだけとは違う面白さがありました。
まず学んだのは、ネットワークが通信を届ける仕組みです。OSI参照モデルや物理層・ケーブル、イーサネットなどの基礎から始まり、2進数・10進数・16進数の計算、IPv4アドレス、ネットワーク層、TCPとUDPの役割へと進みます。最初はIPアドレスの数字を見ても、何を意味しているのか分かりませんでした。サブネットの範囲を計算する課題では、桁を読み違えて答えがずれることもありましたが、図に書き込んでネットワーク部とホスト部を区別していくと、少しずつ整理できました。
Cisco IOSの基本操作に触れてからは、実際の機器に設定する機会が増えました。ポートやインターフェース、IPアドレスの設定を一つずつ確認し、通信が通るかを確かめます。設定を入れたのに疎通できないときは、ケーブルの接続、機器の状態、設定値、通信経路など、考えられる原因がいくつもあります。最初は手当たり次第に設定を変えていましたが、それではどの変更が影響したか分からなくなります。まず現在の状態を表示して、変える前の情報を残す大切さを学びました。また、最初は複数のルーターのうち一台だけ電源を入れ損ねていてリモート接続できなかったこともあり、慣れ始めの頃こそ基本的な作業や確認を疎かにしないことが大事だと痛感しました。
ルーティングでは、データがどの経路を通るかを考えます。スタティックルーティングとダイナミックルーティングの設定を学び、経路情報を見ながら結果を確認しました。スイッチングやVLANでは、物理的には同じ機器を使っていても、論理的にネットワークを分けられることが印象的でした。「同じスイッチにつないでいるのに、設定によって通信できる相手が変わる」という体験で、構成図と設定の関係が分かり始めました。
さらにACLによる通信の許可・制限、NATによるアドレス変換、DHCPによるIPアドレスの自動割り当て、DNSによる名前解決、IPv6の考え方を学びます。例えば通信がうまくいかない場合でも、IPアドレスの設定に問題があるのか、経路がないのか、ACLで止めているのか、名前解決ができていないのかで調べ方は異なります。学ぶ項目が増えるほど、現象を一つの原因に決めつけないことの重要性を感じました。
応用的な学習では、スイッチの冗長化、FHRPによるデフォルトゲートウェイの冗長化、QoSによる通信の優先制御、機器管理用プロトコル、ネットワーク設計モデル、無線LAN、セキュリティ対策、SDN、自動化などにも触れました。すぐにすべてを実践で使いこなせるわけではありませんが、「通信をつなぐ」だけでなく、「安定して、安全に運用する」ための設計が必要なのだと理解できました。
ネットワークの学習が始まってから、質問の仕方も変わりました。Linuxでは一つの端末の操作を説明すればよいことが多かったのに対し、ネットワークでは、どの機器のどのインターフェースに何を設定し、どこと通信しようとしたのかまで伝えなければ、状況が分かりません。私は構成図に対象機器を書き込み、入力したコマンド、確認した表示、エラーの内容をメモしてから相談するようになりました。講師からのアドバイスも具体的になり、自分でも次に確認すべき点を考えやすくなりました。
※当スクールの特徴：質問に至るまでの確認手段を増やす
処理やロジックが複雑になってくるにつれて、確認箇所も増えていきます。
受講生がより効率的に原因を調査・確認できるよう、質問対応の際にもデバッグ機能や図解を活用し、処理の流れを自分で追えるように指導しています。
ある課題に取り組んでいるときに、Bさんと話し合っても原因がすぐに分からないことがありました。以前なら経験のあるBさんに頼りきりになっていたかもしれません。でも今は、私は接続やIPアドレスの確認、Bさんはルーティング情報の確認というように、調べる観点を分けられます。最後に二人の結果を合わせ、設定が意図した構成と一致しているかを確かめて原因を探り当てることができました。この進め方ができたとき、少しずつチームの一員として役割を果たせていると感じました。
また、研修で学んだことの応用として、AWSを扱う1日セミナーも受講しました。これまで手元で構築してきたWebサーバーやネットワークの知識が、クラウド上でシステムを扱う際の理解にもつながると気づけたのは新鮮でした。新しい用語に戸惑いながらも、LinuxやIPアドレスの基礎を知っているからこそ説明を追える場面があり、最初の1ヶ月に学んだ知識が、ここでも役立っていると実感しました。
※当スクールの特徴：研修修了後も学び続けられるフォロー体制
神田ITスクールでは、研修修了後のスキルアップ・キャリアアップを支援するため、10以上のフォロー講座を無償で提供しています。
新人研修で得た基礎を土台に、配属後の業務や本人の課題に合わせて、学習を続けられることが特徴です。
例えば、SpringによるWeb開発を復習する、データベース設計やテストの理解を深める、インフラ系の知識（AWS、Linux、ネットワーク）を学ぶなど、実務で必要になった分野を選んで学習できます。
生成AI、Python、プロジェクト管理など、将来のキャリアに応じて学習領域を広げる選択肢もあります。
また、まとまった時間を確保しにくい方や、SAP認定資格などの取得を目指す方向けに、eラーニングも用意しております。
1日セミナー・フォロー講座を見る
eラーニングを見る
4. ネットワーク構築模擬演習｜要件定義から発表までを経験
ネットワーク単元の最終演習では、顧客役へのヒアリング内容をもとに要件を整理し、チームでCisco IOSを扱う仮想環境でネットワークを構築していきます。ここで目指すのは、研修で学んだ基礎知識を組み合わせることと、周囲と相談・協力しながら開発を進める経験を積むことです。
本演習を通して、顧客役へのヒアリングから設計、構築、テスト、成果発表までを経験します。
| 工程 | 取り組み・成果物 |
|---|---|
| 要件確認・設計 | 顧客役へのヒアリング、設計・レビュー |
| 構築 | 設計をもとに仮想ネットワーク構築 |
| テスト | 想定通りのアクセス許可ができているのか動作確認 |
| 発表 | 発表資料の作成、リハーサル、上司や参加者からの質問への回答 |
ネットワーク単元の最後は、7日間の模擬構築演習です。授業で実機に触れた経験を踏まえ、演習ではCisco IOSを扱う仮想環境を使用し、顧客役のヒアリングから設計、設定、テスト、発表までを二人で進めます。工程の大枠はLinuxの演習と似ていますが、今回は通信経路や機器間の関係を考える必要があり、確認する内容が大きく変わります。
前回は「Bさんの足を引っ張りたくない」という気持ちが先に立っていました。しかし今回は、苦手を隠して任せきりにするのではなく、「自分が責任を持つ範囲を決め、困ったら早めに共有する」と考えました。二度目の模擬演習だからこそ、技術面だけでなく、仕事の進め方の変化も確かめたいと思っていました。
1日目：顧客との打ち合わせ・要件定義
顧客役の講師と顔を合わせるのは、Linuxの演習以来です。初回ほど緊張せず、挨拶から打ち合わせの開始まで落ち着いて進められました。今回は「どの支社の端末同士を通信させたいのか」「どの通信を制限したいのか」など、ネットワークの構成に結びつく条件を意識して質問しました。技術的に分かったつもりで話を進めず、相手の意図を自分の言葉で言い換えて確認するよう心がけました。
作業を進める際は、前回とは異なる役割分担に挑戦することを二人で決めました。私は要件整理やWBSの更新など、これまでBさんに頼ることが多かった作業を中心に担当しました。Bさんは議事録と連絡メールを担当しながら、私の整理した内容を確認してくれます。得意なことだけを続けるよりも、お互いの作業を経験しておいたほうが、どちらかが手いっぱいになったときにも助け合えると考えたからです。
打ち合わせ後は、その日のうちに未決事項と確認済み事項を区別してまとめました。やるべきことをWBSに書き出し、予定と実績の差を毎日確認する方針も二人で決めました。前回の反省を、今回は開始時点から生かせたと思います。
2日目：要件定義レビュー、設計
要件定義レビューでは、前回より落ち着いて説明できました。それでも、顧客役の講師から質問を受けると、自分たちの想定が曖昧だったことに気づく場面があります。「つながればよい」だけでは、誰がどこにアクセスできるのか、障害時にどう考えるのかまで十分に表せません。また、イメージ図なども、見やすく描いたつもりでも伝わりにくい部分がありました。説明しながら気づいた不足点をメモし、レビュー後に文書を修正しました。 設計では、基本設計書、ネットワーク構成図、パラメータシートを作成します。構成図には機器と接続関係を、パラメータシートにはインターフェースやアドレス、必要な設定値を整理しました。数字や機器名の書き間違いは、構築時のトラブルに直結します。Bさんに自分の担当分を確認してもらい、私もBさんの資料を読み返すことで、作成者だけでは気づきにくい不整合を減らしました。
3日目：構築
構築作業では、仮想環境にネットワーク機器を配置し、設計に沿って設定していきます。IPアドレス、ルーティング、VLAN、必要な通信制御など、学習した項目を一つの構成に組み合わせる作業です。コマンドを覚えているだけでは足りず、前後の設定がどう影響するかを考えながら進めなければなりません。
私は入力前にパラメータシートの該当箇所を指で追い、機器名、対象インターフェース、設定値を声に出さずに確認してから実行するようにしました。単純な方法ですが、最初のLinux学習で打ち間違いを繰り返した自分には効果的でした。また、設定の節目ごとに状態を表示して記録し、一度に多くを変更しすぎないよう注意しました。
作業中、予定していたところまで進められない時間帯もありました。以前なら遅れていることを言い出しにくかったと思いますが、今回は「どこまで終わったか」「何を確認しているか」「いつ判断が必要か」をBさんに伝え、WBSを調整しました。進捗報告は、単に遅れを伝えるだけではなく、チームで次の対応を考えるためにも大切なのだと感じました。定期的に行っている担当講師への進捗報告でも、遅れの原因やそれへの対処をしっかり説明できたことで、その進め方が適切かどうかを確認してもらい、アドバイスを受けることができました。
4日目：単体テスト
4日目は機器ごとの設定が設計どおりかを確認する単体テストです。設定内容を表示し、インターフェースの状態や必要なパラメータを一つずつ照合しました。すると、一部の機器で想定した状態にならず、手順書に記載した設定の順番と確認項目に不足があることが分かりました。
このとき大切だったのは、どこか一か所を勘で直すのではなく、「設計書」「手順書」「実際の設定結果」を比較することです。間違いを修正してからもう一度手順を通すと、同じ状態を再現できました。さらにテストケースの実施結果を残していると、特定の条件下で通信制御が期待どおりになっていないことが分かりました。原因の切り分けが必要だったため、翌日の確認事項として記録しました。
5日目：単体テスト（続き）・結合テスト
前日見つかった通信制御の問題を、設定内容とテスト条件の両方から確認しました。影響する範囲を構成図上でたどり、個々の機器の設定や通信制御を確認して必要な箇所を修正することで単体テストを終えました。
続いて結合テストのケースを作成し、端末間の疎通やアクセス制限など、構成全体の動作を確かめます。機器ごとの設定が正しくても、複数の機器を通したときに期待する経路を通れなければ、ネットワーク全体としては完成していません。確認結果は良好でしたが、発表当日に使う仮想環境のアカウントで問題が起きた場合を考え、Bさんの別アカウントでも予備環境を用意しようと相談しました。私から「コマンドの操作履歴や出力を記録し、それを参照しながら再構築できるか試そう」と提案できたのは、以前より自分でリスクを考えられるようになったからだと思います。
「テストで通ったから大丈夫」だけで終わらせず、再現できる手順があるかを確かめる。Linuxの演習で経験した手順書の記載漏れが、今回の判断につながりました。学んだ内容が別の演習でも生きていることを感じました。
6日目：結合テスト（続き）・発表準備
6日目は予備環境の構築と動作確認を進めました。設定履歴を参照しながら二人で確認することで、必要なコマンドや手順の抜けがないかを見直せました。予備環境でも予定した通信ができ、本番用の構成と結果が一致したときは、単に「動くものを一つ作った」以上の安心感がありました。
発表資料には、顧客の要件、構成図、設定の考え方、テスト項目と結果、発生した問題と対応を盛り込みました。資料の作業も、テストが終わった人から手伝うだけではなく、全体の流れが自然か、技術を知らない方にも目的が伝わるかを確認し合います。特に通信制御の説明は、コマンドを並べるより「どの通信を許可し、どの通信を制限したか」を図で示すほうが分かりやすいと気づきました。
最終チェックでは、発表担当者が説明できる部分だけでなく、相手の担当部分についても質問してみました。答えに詰まるところがあれば資料と設計書に戻る。二人で同じ全体像を持つことが、最後の仕上げでした。
7日目：リハーサルと最終発表
最終日の午前中にリハーサルを行い、発表の順序とデモンストレーションの操作を繰り返し確認しました。午後の発表会では、前回のようにコマンドの貼り付けを焦って間違えないよう、入力前に対象機器と操作内容を見直しました。結果、今回はエラーなくデモを進めることができました。画面の動きを見ながら、どの設定によって期待した通信が実現しているのかも説明できました。
質疑応答では、上司の方々から構成やテストの考え方について質問をいただきました。練習していない表現の質問もありましたが、構成図やテスト結果を手がかりに、自分の言葉で答えられました。発表後には取り組みを褒めていただき、Bさんと顔を見合わせてほっとしました。前回の発表ではミスを立て直すことに精いっぱいでしたが、今回は事前の準備と確認を生かして落ち着いて発表できたのが、何よりうれしかったです。
7日間を振り返ると、最初からすべて順調だったわけではありません。設定の確認漏れやテストでの不具合もありました。ただ、そのたびに情報を整理し、役割を調整し、結果を記録して進めることができました。研修開始時の私なら、エラーが出た瞬間に手が止まり、誰かが答えを教えてくれるのを待っていたと思います。今は「まず何を確認すればよいか」を自分で考えられるようになりました。
5. 総括｜研修前後で変わったこと
2ヶ月間で一番変わったのは、「分からないこと」への向き合い方です。最初はコマンドを打つだけで精いっぱいで、エラーが出るとすぐに講師に助けを求めていました。今でも知らない設定や難しい用語はたくさんありますが、操作した内容、表示された結果、設計との違いを確認し、原因を少しずつ絞り込めるようになりました。理解できていない部分を具体的に説明できることも、以前にはなかった成長です。
技術面では、Linuxの基本操作やユーザー・権限管理を学び、Apache、PHP、データベースを組み合わせたWebサーバー構築を経験しました。シェルスクリプトでは条件や繰り返しを考え、処理を順序立てて組み立てる基礎にも触れました。ネットワークでは、IPアドレスやルーティング、VLAN、ACLなどを学び、実機で設定を試し、仮想環境での構築演習へとつなげられました。まだ一人で実務のあらゆる場面に対応できるわけではありませんが、基礎を学び、調べながら構築するための土台ができたと感じています。
仕事の進め方も変わりました。作業前には目的と設定値を確認する。予定と実績を比べ、遅れがあれば早めに共有する。相手が理解しやすいよう、結果だけでなく根拠も示して説明する。これらは研修の最初から大切だと教わっていたことですが、二度の模擬演習で実際に苦労したからこそ、必要性を実感できました。同期のBさんとは、助けてもらうだけの関係から、それぞれが役割を持って確認し合える関係へと変わっていきました。
研修を終えるにあたり、受講生アンケートでは、分かりやすかった指導や苦労した点を振り返りました。自分の課題を書き出すと、ネットワークの設定をさらに練習したいことや、説明をもっと簡潔にしたいことなど、配属後に取り組みたい内容も見えてきます。研修修了後は新しい環境での学びが始まりますが、この2ヶ月で身につけた確認と相談の姿勢を忘れずにいたいです。
※当スクールの特徴：受講生アンケートと修了報告会
研修修了時には受講生アンケートを行い、研修の良かったところや改善要望を確認しています。
受講生が苦労した点や役立った指導を振り返ることは、次の学習課題を整理する機会になります。
また、修了報告会では、報告書を用いて受講生の理解状況や受講態度を企業担当者にご報告します。
配属後のOJTや継続学習を検討する際に役立つ情報も共有しています。
6. 終わりに｜2ヶ月間で得られた成長
本コラムでは、インフラ構築未経験の新入社員が2ヶ月間の研修を通じて、Linuxサーバーとネットワークの基礎を学び、模擬演習に取り組む過程をご紹介しました。研修前はコマンド画面を見ることにも戸惑っていた受講生が、構築手順を確認し、問題を調べ、同期と協力しながら成果を説明するところまで進んでいきます。技術の習得とともに、主体的に行動すること、報連相や計画管理を意識することにも取り組んだ事例です。
ご紹介した内容は実例をもとに再構成した一例であり、受講生の経験や理解度によって進み方は異なります。また、研修修了は実務に必要なすべての技術を習得したことを意味するものではありません。基礎の理解度を把握し、配属後のOJTや継続的な学習につなげることが大切です。
ご紹介した内容は実例をもとに再構成した一例であり、習熟度や感じ方には個人差があります。
研修前後の受講生の変化
| 観点 | 受講前 | 研修修了時の変化 |
|---|---|---|
| 技術 | Linuxのコマンドやネットワーク機器の役割をほとんど知らない | Linuxサーバーや仮想ネットワークの構築・テストを経験し、調べながら設定を確認できるようになった |
| 問題解決・主体性 | エラーが出ると手が止まり、「動かない」とだけ相談しがち | コマンド・ログ・構成図から状況を整理し、原因を切り分けて質問・対応できるようになった |
| 計画管理 | 予定より遅れても一人で取り戻そうとしがち | WBSで進捗を見える化し、課題や遅れを早めに共有して担当と作業順序を調整できるようになった |
| 説明・協働 | 人前の説明に緊張し、経験のある同期を頼りがち | 顧客役への確認、レビュー、発表・質疑応答を経験し、役割分担と相互確認を意識するようになった |
新人インフラ研修を検討している企業の皆様へ
新人インフラ研修では、「どの技術を扱うか」に加え、「どのように理解度を確かめるか」「つまずいたときにどう支えるか」「企業へどのような情報を報告するか」も重要です。本事例のように、基礎学習、構築演習、発表を段階的に重ねることで、受講生の習熟状況や仕事の進め方の変化を把握しやすくなります。
神田ITスクールでは、企業の育成方針と受講者の経験に合わせて研修をご案内します。受講者の経験、人数、研修期間、配属後に求める役割をお知らせください。新人インフラ研修の内容と到達目標について、お気軽にご相談いただけます。
