
目次
昔と違って、IT環境が複雑になってきています。そんな中、どうやってエンジニアを育成すればいいの?という悩みは尽きないかと思います。実際、弊社で数XX年、教育エンジニアを担当していますが、昔と今ではエンジニア育成のための技術研修フローも大きく変わっています。
そこで、今回は「いまどきのエンジニア育成(技術編)」をテーマにして書いていきます。
第1回のテーマは「いまどきのエンジニアに必要な知識」と「入門コースの罠」です。
1.いまどきのエンジニアに必要な知識
かつてはネットワークエンジニアはネットワークだけを、サーバーエンジニアはサーバーだけを把握していればよかったのですが、最近ではそうはいきません。
例えば、「業務アプリケーションの都合でOSのパッチ適用ができない」という場合、Firewallで脆弱性防御の機能を利用すれば、カバーすることができます。
しかし、サーバーエンジニアは自社のFirewallにそういった機能があるのかどうか知っていないと、その機能を利用することを思いつきません。また、ネットワークエンジニアも端末側の事情を知らないと、脆弱性防御の機能がFirewallで必要なのかどうか判断つきません。
また、最近では必要な通信のみを許可するWhitelist方式でFirewallのfilterを設定することが理想とされているため、どのようなアプリケーション通信があるのかネットワークエンジニアも把握する必要があります。また、トラブルシューティングするにはアプリケーションデータの中身までを把握することが必要になることもあります。
このように、エンジニアは他のジャンルの機能や特徴を知らないと、適切なシステム環境を構築することが難しいと言えます。結局、「システムの全て」を知る必要があります。
2.全てを知る。。。は神業。
一部の神と呼ばれる存在は確かにいますが、システムの全体の詳細を把握することは1人ではとても困難です。自分の担当ジャンルでさえ、日々技術は進化しているので確認しなければならないことが山程あるのに、他のジャンルについても同等の知識を身に着けるのは神業です。
全員が全てのジャンルに同じ深さの知識が必要でしょうか?
例えば、ネットワークエンジニアにとっては、IPアドレス設計はとても重要です。IPアドレスは無限にあるわけではないので、各サブネット内に必要なIPアドレスの数やネットワーク全体に必要なサブネット数、集約を考慮したサブネット配置などの配慮が必要です。
では、なぜそういう配慮が必要になるのか?というのは、IPアドレスの制約やお約束事、ネットワークという単位をどう決めていくのかを知る必要があります。
しかし、サーバーエンジニアにとっては、端末に割り当てるIPはとても重要ですが、ネットワーク全体のIP設計を意識する必要はありません。
このように、担当ジャンルにより1つの技術の知識に対して知るべき「深さ」が異なります。
なので、全てを知るとは言っても、担当分野でない部分は「ちょっと知ってる」と言えるくらいの知識で十分です。
3.入門コースの罠
「ちょっと知りたい」と思って、他のジャンルを勉強するために、「入門」の記事を読んだり、教育コースを受講しに行ったりすると思いますが、大抵の「入門」は専門家になるための入門コースです。
その場合、入門は全体のほんの一部分の紹介で、全体の概要とは異なります。例えば、「家を建てて下さい」と言われてもいきなりは、できませんよね?
それには、諸々の部材や設計が必要になってきます。手に入る部材の種類によっては設計を変更する必要が出てくることもあります。また、気候特性によって部材を変更した方がいいことも出てきます。
となると「始めに知るべきものはどんな部材があるか」ということです。
IT技術も考え方は同じで、入門コースではそれぞれのジャンルでこれから使うこととなる主な部材の種類/特徴を知ってもらう、ということを目標としています。
例えば、ネットワークエンジニアのための「ネットワーク入門」では、IPアドレスの話を細かく説明します。
それはネットワーク設計をできるようになった頃に、なぜそこまでの知識が必要なのか、重要なのかが分かりますが、入門レベルでは、それがなぜ重要なのかは分かりません。ただ使える部材を見ただけで、状況によって変更した方がいいとはまだ思いつかない段階だからです。
そのため、「入門」だけで学習が終了すると、「よく分からない・・・」という結果になります。
部品や道具だけが目の前に並べてあるだけだからです。
では、もっと先(応用編)まで勉強しないと意味ない?となるかもしれませんが、
応用編は「ちょっと知りたい」(広く浅い知識)ではなく「もっと知りたい」(深い知識)に応えた内容です。そもそも今までの技術トレーニングは「専門家」を育成することを目的として作られていますから。
では、どうすれば?
解決策は次回記事で紹介します。
※本記事の内容は執筆者個人の見解であり、所属する組織の見解を代表するものではありません。