研修の実績からのポエムであり、特定の業務の内容に言及していないことに留意されたい
結論
スキルとは、資格＋実務経験をどれだけ現場にコミットできるか、である
インフラの知識・技術があると嬉しいこと
- Webアプリを作るスクールが多いが、サーバーの知識がないままにアプリを作る勉強しかしていないので、差別化を図りやすい
- クラウド技術（AWSやGCP,Azureなど）をはじめ仮想化の重要性は叫ばれつつも、その根幹となるインフラの知識がなければ障害発生時などの原因の切り分けが困難
- AIの需要がますます高くなっている中、AIを運用に載せるための土台も知っておくことの重要性が高まっている
特にAWS研修やAI,DX研修の要望は多いが、その実としてAWSで何をやっているかを正しく理解している（させる）研修は多くないのが実情である。
筆者ロール解説
- フリーランスエンジニア 兼 IT講師(toB, toC)
- 開発歴10年以上、講師歴5年
- 得意領域はフロントエンド・バックエンドなどソフトウェアエンジニアリング領域
- 直近ではAI開発が主
- LiONコミュニティにて本勉強会の学習支援のほか、教材開発にも参画
- 育成指導のため認定試験開発にも興味はあるが、指導する立場の人間が試験問題や答案を知っているのは問題と考えており、こちらは泣く泣く不参加…！
- 趣味と実益を兼ねてAI利活用の勉強会やハッカソンにも参戦
【本題】 Linux学習の必要性
筆者が担当するプログラミングスクールではWebアプリエンジニア養成コースの受講者が多いため、アプリエンジニア目線で語る
Webアプリにおけるサーバーの役割を知り「動かせるようになる」
当たり前だが、サーバーは作って終わりではない。
たとえば個人開発でもサーバーを作ったら動かして、その上で開発をしていくことになる。
特にWebアプリの場合「この機能を追加するために特定のライブラリが必要になる。そうなるとシステムパッケージが必要になる」という流れがある。
具体例で考えてみよう。
メール送信機能を作りたい！
とりあえず動けばいいや！を目標に内容をかなり簡単にしても、これだけの要件を考える必要がある。
- メール送信画面を作る: これはフロントエンドの領域
- メール送信のプログラムを書く： フロントエンドでも書けるが、分業しているならバックエンドの領域になりがち
- メールサーバーが必要: ここからがインフラエンジニア。本題
- メールを送信するための仕組み（ルール。色々な方法がある。専門用語でプロトコル）に従う必要がある
- メール送受信ルールに準拠したサーバー設計を行う
- メールサーバーを利用するための権限設計を行う（アプリケーションからサーバーを使用するための交通整備）
- これらの設計要件を満たすようにシステムにパッケージをインストールする
- インストールしたパッケージを活用してメールサーバーを構築する
- メールサーバーを起動・停止する。必要であれば自動化する
今回は同一端末内（自前の端末でのローカルホスト）でのサーバー構築を想定しているため、セキュリティなどはザルな状態である事は認識されたい。
実装順の違い
インフラ知識もあるアプリエンジニアの場合、メールサーバーがなくてもメール送信画面や送信プログラムを書く事ができる。
当然、送信時にエラーになるが「メールサーバーがないので実際にメール送信処理がされない」理由を正しく理解できているため、エラーになったからといって慌てることはない。
ただし、メールサーバーの仕組みを知らなかったら？
コードには問題がないし、色々なサイトを見て回ってもメール送信ルールの解説サイトを延々と巡回するだけでエラーの根本的な原因に気付くのに時間がかかってしまうだろう。
エラーメッセージはあくまで、何行目にどういう理由でエラーになったかを教えてくれるだけで、エラーの解決方法までは教えてくれないためである。
こういう時にAIが頼りになるが、AIへの質問を学ぶ必要があることに気付くだろう。専門用語ではプロンプトエンジニアリングといわれるスキルだが、本稿では扱わない。
参考： AIに聞いてみた（意味はわからなくてOK）
AIとLinux
キーワードは「実装力」
これまでは、メールサーバーを例に解説してきたが「設計はできても、実装ができないよね」という問題に向き合おう、というメッセージと考えてほしい。
確かに優秀な設計者もいるし、問題を解決する方法として外注するという選択肢はあるのだが、個人レベルで見た場合に、外部に任せるより自力で解決できた方がメリットも大きい。
特に自身と社内にノウハウが蓄積されるという点は見過ごせない。障害が発生するたびに外注に頼っていては費用も時間も掛かってしまうからだ。
そこで、AIに聞けば解決できるのでは？という話になるのだが、実際問題として設計できるレベルの人がようやく作業もできるというレベルだろう。
たとえば、設計者（実装は未経験の方）だと「AIに質問する方法は分かるし、回答内容から何を言っているかは分かる。ただし、具体的な手順として自環境に適用するためにどうするか？」まで到達できる人は少ない。
ある程度の操作方法を習得すればこの問題も解消できるが、問題はどうやって操作方法を習得するか、である。
AIに操作方法を聞く事もできるが、個別具体のケースであるため、平気でハルシネーションが発生する。そして、AIの回答も特定の環境下では問題なく動く可能性が高いため、結果として解決に結びつかない事が多くなってしまう。
LinuCの認定試験では、「個別具体のケースには特化しないが、汎用的な環境下であれば動く方法をハンズオンレベルでの知識を求められる」ため、ここから個別具体のケースにフォーカスしていく事で解決を目指すというアプローチを検討していく事ができるのが強みと言える。
LinuC認定試験について
ほとんど引用になるため、公式ページを案内する。
- 4段階のレベルに応じてスキルを評価・認定する
- ベンダー資格に依存しない内容での専門性（どんな現場でも通用するスキル）を学べる
ポイントをまとめるとこの二つだと筆者は認識している。
最終的には汎用スキル＋ベンダースキルで幅広と特定スキルを伸ばす、いわゆるT字型のスキルセットを持っていけば良いと考える
とはいえ、昨今のIT業界のスキルセットはTでは足りず、幅広に深くしていくアプローチが必要になってくる。
また、技術的な分野だけでなく業界や開発言語、サービスなど尖ろうと思えばどの分野からでもチャンスはあるので、LinuCの認定資格を取った上で、たとえば金融業界に強いJavaスペシャリストというロールを目指したり、同じくLinuCの認定資格がある物流システムに詳しいC#エンジニアなど、色々なやり方ができるのがポイントだ。
IT人材のタイプについては以下が詳しいので参照されたい。
資格を取る動機づけを考える（筆者の場合）
私も恥ずかしながら実務経験至上主義者であるため、経験＞資格という考え方ではあるが、実務経験至上主義者だからこそ「他社での経験は弊社では通用しません」を強く意識するようにしている。
実際、開発経験や講師経験が長かろうが、特定の現場に参画した時にほとんどパフォーマンスを発揮できなかった、という事はあるあるで、私にも歴が長いしいくつも修羅場を乗り越えてきた自負があるだけにとても悔しい思いをしたものだが、これはひとえに「実務経験」が標準化されていないからこそ起こっている問題とも考える事ができる。
つまり、現場経験でもある程度普遍的な知識や実力はつくが、幅が狭い状態になるし現場に特化してしまう「現場依存になる」問題があるため、別現場に行けば、過去の現場経験を認めてくれるものはいないという事だ。
現役ほど現場依存症（造語）になりがちな傾向があるので、現場「だけ」に特化しないためにも、認定資格を持って汎用性を示すべきだと、最近考えを改めたので展開しておく。
とはいえ、実務経験至上主義者を辞めたわけではない事は記しておく。