新人インフラエンジニア研修の最終課題は「構築して引き渡す」形にする。総仕上げ課題の作り方と評価のしかた

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

新人インフラエンジニア研修の最終日、何をしていますか。

筆記テストを解いてもらい、アンケートを書いてもらって終わり。そんな研修は少なくありません。

もちろんテストにも意味はあります。ただ、テストで分かるのは「知っているかどうか」までです。配属先が知りたいのは「任せたら動けるかどうか」のほうです。

この2つの間には、思っている以上に距離があります。chmod の意味を正しく答えられる新人が、実際のサーバーでは権限の問題に気づけない、ということは普通に起こります。

今日は、研修の最後に置く総仕上げ課題（最終課題）について考えます。要件を受け取ってから、構築して、手順書を書いて、引き渡すところまでを一人でやってもらう形です。

最終課題を「構築して引き渡す」形にする理由とは？¶

研修の途中で行うハンズオンは、たいてい手順が決まっています。テキストのとおりに打てば、同じ結果になるように作られています。

これは学び始めには必要な形です。ただ、手順どおりにできたことと、自分で組み立てられることは別の力です。

現場の仕事は、手順が渡される前の段階から始まります。何を作るのかを確認し、手順を考え、作業して、確認して、人に渡す。この流れを一度も通しで経験しないまま配属されると、最初の案件で手が止まりやすくなります。

最終課題は、この通しの流れを研修の中で一度経験してもらうためのものです。テストの延長ではなく、小さな実案件の模擬だと考えると設計しやすくなります。

実技試験の考え方が参考になる¶

この考え方は、資格試験の世界にもあります。Red Hatの認定資格RHCSA（試験番号EX200）は、選択式の問題がなく、実際のシステムで作業を行う実技試験です。

RHCSAの試験は、実際のRed Hat Enterprise Linuxのシステム上で、現実に近いタスクを行う実技形式の試験です。 （Red Hat「Red Hat Certified System Administrator exam」より意訳）

Red Hatの実技試験では、設定が再起動後も保たれていることが求められ、採点は試験終了時点のマシンの状態に対して行われます。

GoogleのSREが新人の育成について書いた章にも、Break Real Things, Fix Real Things（本物を壊して、本物を直す）という節があります。実際に手を動かして確かめる経験を重く見ている点は共通しています。

研修の最終課題でも、Red Hatの試験の2点はそのまま使えます。「再起動しても動くこと」と「最終的な状態で評価すること」です。作業の途中経過ではなく、引き渡されたものが要件どおりに動くかを見る、ということです。

筆記テストと最終課題で見えるものの違い¶

筆記テストと、構築して引き渡す形の最終課題では、評価できる範囲が違います。整理すると次のようになります。

採点の手間が増えるのは事実です。ただ、配属先に「この新人はここまでできます」と具体的に伝えられる材料が手に入るので、その分の価値はあると考えています。

総仕上げ課題の作り方¶

ここからは、実際に課題を作るときの手順を見ていきます。いきなり大きな課題を作るより、次の4つを順番に決めていくと形になりやすいです。

1. 題材（何を作ってもらうか）
2. 要件の渡し方（どこまで書いて渡すか）
3. 提出物（何を引き渡してもらうか）
4. 採点基準（何をもって合格とするか）

題材は「研修で習ったことの組み合わせ」で選ぶ¶

題材は、研修で扱った技術を3〜4つ組み合わせて作れるものが適しています。新しい技術を覚えないと解けない課題にすると、最終課題ではなく追加の学習になってしまいます。

たとえば、Linuxとネットワークを中心に学んだ研修なら、次のような題材が考えられます。

研修期間が短いなら、いちばん上の1台構成で十分です。大事なのは規模ではなく、要件を読んで、作って、渡すところまでを一人でやり切ることです。

構築に使う環境は、本番と切り離された研修用の環境を用意します。壊しても作り直せる環境の作り方は、新人インフラエンジニアには「壊していい環境」がいるで詳しく書いています。

要件は「仕様書」ではなく「依頼」の形で渡す¶

課題の渡し方にも工夫がいります。設定値まで全部書いた仕様書を渡すと、ただの手順作業になってしまいます。

おすすめは、現場の依頼に近い文章で渡すことです。たとえば次のような形です。

【依頼】社内の勉強会資料を置くWebサーバーを1台用意してください。

・社内ネットワーク（192.168.10.0/24）からだけ閲覧できること
・管理者は study-admin というユーザーでログインし、sudo が使えること
・サーバーを再起動しても、Webサーバーは自動で起動していること
・不要なポートは閉じておくこと
・作業手順と確認結果を、別の人が読んでも分かる形で残すこと

期限：3日後の17時
不明点があれば、作業前に依頼者へ質問してください。

あえて決めていない点も残しておきます。Webサーバーの種類や、ファイアウォールの設定方法は書いていません。

最後の一文も大事です。不明点を質問してくるかどうかも、評価の対象になります。現場では、分からないまま作業を始めてしまうことのほうが問題になりやすいからです。

提出物は「動くもの」と「書いたもの」の両方¶

提出物は、構築したサーバーそのものと、作業の記録の2つに分けて考えます。

作業ログは、script コマンドなどで端末の操作をそのまま残してもらうと集めやすいです。採点のときに、どこで迷ってどう解決したかを後から追えます。

手順書の書き方そのものは、研修の途中で一度は教えておく必要があります。何も教えずに最終課題で求めると、書き方の差がそのまま点数の差になってしまいます。

期間中に講師が手を貸すかどうかを決めておく¶

もう1つ、事前に決めておきたいのが、課題の期間中に講師がどこまで手を貸すかです。ここが曖昧だと、質問に答えてもらえた新人とそうでない新人で、結果に差が出てしまいます。

おすすめは、要件についての質問には答え、作業のやり方についての質問には答えない、という線の引き方です。たとえば「閲覧できる範囲は社内ネットワークだけで合っていますか」には答えます。「ファイアウォールの設定コマンドを教えてください」には、マニュアルや研修資料のどこを見ればよいかだけを伝えます。

これは現場の依頼者と作業者の関係に近い形です。依頼者は何を作ってほしいかには答えられますが、作り方までは知らないことのほうが多いからです。

どうしても先に進めなくなった新人には、ヒントを出してもかまいません。その場合は、どこでヒントを出したかを記録しておき、採点のときに考慮します。

最終課題の採点基準はどう決める？¶

採点で迷いやすいのは、「動いたけれど、やり方が気になる」場合です。結果だけで見るか、過程も見るかで、評価が大きく変わります。

ここでは、結果の確認と、過程の確認を分けて採点することをおすすめします。

結果は確認コマンドで機械的に見る¶

結果のほうは、採点する人によってぶれないように、確認の方法を先に決めておきます。たとえば先ほどの依頼なら、次のような確認になります。

# 再起動後、Webサーバーが自動で起動しているか
systemctl is-enabled httpd
systemctl is-active httpd

# 管理ユーザーが存在し、sudo を使えるか
id study-admin
sudo -l -U study-admin

# 開いているポートと、ファイアウォールの許可設定
ss -tlnp
firewall-cmd --list-all

確認項目を表にして、満たしているか満たしていないかの2択で付けます。ここに部分点は付けません。現場では「だいたい動く」は動いていないのと同じだからです。

採点の前に、採点者がサーバーを一度再起動しておくのも効果があります。手で起動しただけのサービスは、ここで止まります。

過程は観点ごとに段階で見る¶

過程のほうは、手順書と作業ログを読んで、観点ごとに段階で評価します。

この表は、合否を決めるためのものではありません。配属先に渡す、新人一人ひとりの申し送りとして使います。

作業のレビューを育成に使う考え方は、新人の作業、ダブルチェックで終わらせていませんかでも書いています。最終課題の講評も、同じ考え方で進められます。

最終課題の結果を配属先につなぐには？¶

最終課題は、点数を付けて終わりにするともったいないです。結果を配属先にどう渡すかまで決めておくと、研修の価値がはっきりします。

研修評価の考え方として有名なものに、カーキパトリックモデルがあります。研修の効果を4つの段階で評価する考え方です。

レベル1：反応（受講者の満足度） レベル2：学習（知識やスキルが身についたか） レベル3：行動（職場で行動が変わったか） レベル4：成果（組織の成果につながったか） （Kirkpatrick Partners「What is The Kirkpatrick Model?」をもとに整理）

アンケートはレベル1、筆記テストはレベル2の評価です。最終課題は、レベル2を「実際にできるか」という形で確かめつつ、レベル3につなぐための材料になります。

具体的には、最終課題の評価表を配属先の教育担当に渡し、配属後1〜3か月で同じ観点をもう一度見てもらいます。研修で「2」だった観点が、現場で「3」になっていれば、研修が現場に効いていると言えます。

研修の効果をどう測るかについては、新人インフラエンジニア研修のROIはどう測る？で詳しく扱っています。

講評の場は必ず設ける¶

採点が終わったら、新人一人ひとりに講評の時間を取ります。30分ほどで十分です。

講評では、できなかった点よりも先に、なぜそう判断したのかを本人に説明してもらいます。判断の理由が筋の通ったものであれば、結果が要件に届いていなくても、次は直せます。

逆に、たまたま動いただけのケースもあります。どうして動いたのかを説明できない場合は、配属後に同じ作業でつまずく可能性が高いので、申し送りに書いておきます。

最終課題を作るときの注意点¶

最後に、最終課題を初めて作るときに起こりやすい失敗をまとめておきます。

もう1つ、最終課題は障害対応の訓練とは分けて考えたほうがよいです。構築と障害対応では、求められる力が違います。障害対応の練習については、机上で回す障害対応訓練の始め方を参考にしてください。

なお、課題の題材や採点基準を一から作るのは、育成担当者にとって小さくない負担です。InfraAcademyの法人プランでは、Linuxやネットワークのハンズオン環境と学習の進捗管理をまとめて用意しているので、研修の土台づくりにかかる手間を減らせます。内容はInfraAcademyの法人プランで紹介していますので、研修の設計を見直すときの選択肢の1つとして見てみてください。

まとめ¶

新人インフラエンジニア研修の最後に置く、総仕上げ課題の作り方について見てきました。

要点を振り返ります。

• 最終課題は、テストの延長ではなく、小さな実案件の模擬として作る
• 要件は依頼の形で渡し、不明点を質問するかどうかも見る
• 提出物は、動くサーバーと、手順書・確認結果・作業ログの両方
• 結果は確認コマンドで2択、過程は観点ごとに段階で評価する
• 評価表は配属先に渡し、配属後にもう一度同じ観点で見てもらう

研修の最後に一度でも「一人で作って渡した」経験があると、新人は配属後の最初の案件で落ち着いて動けます。今年の研修の締めくくりを決めるときに、参考にしてもらえたらうれしいです。

参考¶

• Red Hat Certified System Administrator exam（Red Hat）
• What is The Kirkpatrick Model?（Kirkpatrick Partners）
• Accelerating SREs to On-Call and Beyond（Google SRE Book）