短期スクール出身者は即戦力じゃない？WEBエンジニアスクール卒業者が学ぶべき7つのポイント

最近、多くの企業が 「ITエンジニアスクール」 事業を手がけています。 昨今、IT人材の不足が各所で言われていますし、世の中の状況的にも、リモートワークができたり、人との接触機会の少ないエンジニア職に注目が集まっているのが大きな理由でしょう。 そんな中で、スクールに通ったものの 「結局仕事では使えない」 という話も聞きます。 通常、エンジニアになる際には、IT関連の専門学校や四年制大学に通ってある程度の基礎を習得し、その後新人教育などで徐々にスキルを付けていきます。 一方で、最近のスクールでは 「最短1ヶ月でWEBエンジニアに」 といった広告も目にします。 確かにこれだけ短期間での学習になると 「本当に現場で通用するスキルなのだろうか」 と疑問になるでしょう。 今回は、私自身がスクール出身者何人かと話をしたり、仕事を教える過程で感じた事について触れていきたいと思います。

スクールに依存するのは危険！現場で使えないエンジニア例

スクールに依存するのは危険！現場で使えないエンジニア例 スクール出身者の中には 「スクールを出たんだから大丈夫」 と考えている人も少なからずいます。 ここでは、現場で使えない・使いにくいエンジニアについて触れていきましょう。

自分で「なぜその機能が必要か」理解できない

スクールでは、基本的に詳細まで仕様の決まった課題を渡され、それを作っていくケースが多いようです。 その結果、 「なぜその機能が必要か」 という事を理解していないエンジニアが多いです。 個人的に驚いたのは、新人エンジニアとソースレビューを行う事を企画した時の事です。 新人エンジニアが作ったソースを、他の新人エンジニアと一緒に見ながら ・なぜこの作り方なのか ・この関数は必要なのか といった内容をお互いに議論してもらう場を持ってもらいたいと思って企画しました。 しかし、実際にやってみると、誰も疑問も持たず、意見が活発に交わされることは有りませんでした。 私自身が入って色々と質問をしてみるものの、 「そもそも質問そのものが出ない」 ということに少し危機感を感じました。 課題としては、わかりやすく一般的に利用されているネットショップなど、誰でもわかるような物を課題として作ってもらっていたのですが、なぜその機能が必要かを考えながら作っていないため、中々質問が浮かばないのです。 これは、仕様書がすでに決まっているシステムのプログラマーとしても、少し問題があると感じています。 昨今は、ウォーターフォール型の開発よりも、アジャイル開発の方が重視されており、仕様を詰めながら開発する事が大切になっています。 そんな中で、作りながら疑問を持てないエンジニアばかりになってしまうと、よほどレベルの高い要件定義や設計をしていかなければ、後々大きな問題になります。 そのため、機能の必要性を含めて「疑問を持つ」ということが、実際の現場ではかなり重要になります。

「ユーザー目線」が身に付いていない

システムの開発において「ユーザー目線」は非常に重要です。 BtoCで一般ユーザーが利用する場合はもちろんのこと、システム管理者用の運用画面を作るなど、BtoBのシステムであっても、殆どの場合「利用者」が存在します。 そんな利用者が使いやすいシステムを開発しようと思ったら、その利用者の目線で物事を考える必要性があります。 例えば、スマホのメニューボタンは右側と左側どちらが使いやすいのか。 最近のスマホは画面が大きいものが多いですから片手で操作することを考えると、すぐに押せる方が良いボタンは右手親指が届く範囲が理想です。 しかし、先入観で「メニューボタンは上の方にある」と思っている場合、下にメニューボタンがあった場合に、見つけられない・・・ということもあります。 この様に、ユーザーの目線で考えて配置を決めたり、画面のフローを考える必要性があります。 短期的にシステムの勉強をした人は、当然経験が足りていません。 また、多くのスクールではデザイン部分は重要視されず、サーバーサイドの開発だけに注力しているようです。 これは、短期間でそこまで多くの事を教えることが困難だからでしょう。 しかし、サーバーサイドの開発だけでは、フロントサイドであるユーザーインターフェースを考えるという経験は出来ません。 そのため、極端にユーザー操作を無視した開発がされることも多いのです。

コードを理解せずにコピペしてくる

今の世の中は、多くの人がネット上に情報をアップしています。 その中には、かなり有用なコードを展開している人もおり、コピペするだけで目的の仕組みが完成する・・・と言うことも少なくありません。 教える時間を短縮する上でも、短期スクールではネット上からのコピペで作成することを勧めることもあるようです。 確かに、現場でもわからないところは検索しながらコーディングしていきます。 しかし、それはあくまでも 「内容を理解しているコードに対して入力時間を短縮する目的」 でコピペするのです。 理解できずにコピペして動いたからといっても後々問題になる可能性があります。 それを理解せずに、単にコピペを繰り返すプログラマーは、個人的にもかなり不安になります。

用語を知らなすぎて自分で調べられない

短期スクールでは、短期間で最低限必要な知識を一気に教えます。 そのため、用語の説明などはされず、自分で調べておいて・・・というところもあると聞きます。 もちろん、出てきた単語でわからないものがあれば、それでも良いでしょう。 しかし、そもそも単語を知らないから調べられない・・・というケースがありました。

言われた物を作っているだけで応用が効かない

基本的にスクールでは、言われたものを作る経験はすると思いますが、 「自由に発想して作る」 という経験をほとんどできません。 また、スクールに通う人の多くが 「エンジニアとして就職すること」 を目的にしているため、スクール卒業後に自分で色々と作ってみる・・・という事をしない人の方が多いです。 そのため、今まで作ったものを応用してより良いシステムを作ると言う事が苦手な人もいました。 私の知り合いの話になりますが、スクール卒業後にシステム関連会社に就職した人がいました。 元々の採用は、システム開発を今後支店としても進めたいという話での採用でした。 しかし、その支店は当時開発を行なっておらず、サポートセンターのような仕事をすることになりました。 その人は、元々IT業界に就職する事が目的でスクールに通っていただけだったため、就職して1年以上経っているにも関わらず、全くシステム開発レベルが上がっていませんでした。 普段の業務でシステム開発を行わなかった上、自己学習も怠っていたため、折角スクールに通ったのに、スキルが身に付いていないのです。 これは、個人的に出会った人の話になりますが、スクール卒業者の全員がプログラマーになれるわけでは無いことを考えると、意外と多いのでは無いかと感じています。

フレームワークの使い過ぎで他言語を学びにくい

スクールで、フルスクラッチでの開発を教えている所は少ないのでは無いかと思います。 スクール期間が短期間であればあるほど、どうしてもフレームワークを活用した開発になるでしょう。 フレームワークを利用すれば、確かに簡単に短期間で出来る様になった気になります。 スクールとしても、参加者の満足度と、挫折する人数を減らすためには、導入するのが理想と言えるでしょう。 しかし、実際に現場に入ってくると、フレームワークしかできないというのは、非常に困ります。 同じ言語、他のフレームワークを利用するのもかなりハードルが高くなりますし、他言語を学ぶのであれば、かなり教えるのに苦労します。 反対に今までスクラッチ開発ばかりを行なっている人は、ある程度基礎ができているので、そこからフレームワークを覚えたり、他言語を学ぶとしても、ハードルは低いです。 また、フレームワークの影響で、自分が出来るプログラマーになった気になって慢心している人も少なからずおり、そういった人に新しい言語を教えるのは非常に苦労します。

悪質なスクールでスキルが全く身に付いていないケースも

最近は、コロナの影響もあって、多くの人がIT業界への転職を考えています。 特に接客業など、仕事が激減しているからという理由で学び始めたという人にも、かなり出会いました。 世の中の需要も多く、IT人材を欲する企業も多い。 だからこそ、スクールが乱立していると感じています。 中には、悪質なスクールも存在し、折角卒業したのにスキルがほとんど身に付いていない・・・というケースもあります。 もちろん、実務未経験という枠での採用にはなりますので、そこまで高い事は求めている企業も少ないでしょう。 実務未経験者を採用していると言うことは、ある程度長期的に育てる事を前提としているはずです。 しかし、それでも全くスキルが無い状態では、育てる側としてもかなり苦労してしまうのです。

自己テストが雑

システムの開発と、テストはいわばセットです。 どれだけ作るのが早かったとしても、バグだらけのシステムでは、チェックや修正に再度時間を取られてしまいます。 しかし、短期間のスクールでは、テストにそれほど多くの時間を使う事はないでしょう。 良くても、クロスサイトスクリプティングやブルートフォースアタックといった有名なものだけで、 ・サーバー情報などの機密情報を公開領域に置かない ・検証モードからデータを書き換えられて送られる事の想定 ・ボタンの連打などユーザーの想定外の操作方法 など、基本的な部分を意識して作れるエンジニアは少ないと感じています。 そのテストが雑な結果、修正の依頼をかけたり、そもそもの仕様を変更したりと、かなり手間がかかってしまうのです。

これだけは知っておきたいWEBエンジニアの7つのポイント

これだけは知っておきたいWEBエンジニアの7つのポイント では、短期スクールを卒業した人は、次にどのような事を学ぶべきなのでしょうか。

スクラッチ開発による基本文法

特にスクールでフレームワークを多用していた人は、個人的にスクラッチ開発を経験してみるべきでしょう。 特にSQLや画面の生成などは、多くのフレームワークで簡略化されています。 また、バリデーションに関しても、1つずつチェックをしていく必要があり、過去にフレームワークで作ったシステムを、同じ仕様でスクラッチ開発するだけでも、かなり勉強になります。 「単に簡単に作れるだけではなく、作業漏れや継承によるソースコードの簡略化が出来る」 など、フレームワークを利用する意義についても学べるでしょう。

変数の型と型変換

特にPHPを最初に勉強した人からすると、変数の型を意識していないケースが非常に多いです。 そういった人は、一度Javaなどを経験して、型を意識したコーディングや型の変換について勉強すると良いでしょう。 Javaなどは、型の定義や初期化をきっちりと行わなければ動かないため、最初は 「1つの画面を作るだけなのに、時間がかかりすぎる」 と感じるかもしれませんが、慣れてくれば ・どの言語にも対応しやすくなる ・PHPでの初期化忘れによるエラーがなくなる など、今まで勉強してきたものが一段階レベルアップするでしょう。

エラーコードの読み方

短期スクールなどの様に、答えを教える側が用意してくれている環境で勉強してきた人ほど、エラーに対する対応に慣れていないケースが多いです。 プログラムをする上で、エラーを全く出さずに開発すると言うのは不可能です。 そのため、エラーが出た際に、その原因を探すことが出来、その対処法が探せることは、非常に重要です。 そのため、実際にプロジェクトが始まる前に、様々なエラーを経験しておく事が重要でしょう。

関数・クラス

プログラムにおいて、すべての処理を1ファイルに記載するのは好ましくありません。 そうしてしまうと、処理が複数被っている所が出てくるなど、非常に非効率的なプログラムになり、ソースコードも膨大になってしまいます。 そのために関数やクラス・継承というものが存在しているのです。 しかし、プログラム初心者にはこの関数やクラスを利用する理由という事が、本当の意味では理解できていません。 そのため、それがわかるまではきちんと自己学習でプログラムを作っていく必要があるでしょう。 プログラミングをやっていくと 「この処理何回も作って面倒臭い」 「ちょっとした修正を複数のページでするのは面倒臭い」 「仕様がちょっとだけ違う似たような処理を作るのが面倒臭い」 と言うように、作るのが面倒に感じる様になります。 そういった面倒臭いと感じる機会を増やすことで、初心者は ・関数 ・クラス という概念と有効性に気がつくでしょう。 また、フレームワークでは既に様々な関数が用意されている事も多いので、その意味合いがわかってきます。

論理削除と物理削除

これは実際に私の知り合いが知らなかった事なのですが、データベースを利用するにあたって、データの削除方法には、 ・論理削除 ・物理削除 の2つの方法があります。 物理削除は、 「DELETE FROM user WHERE id＝1」 のような形で、直接データベースからデータを削除する方法です。 一方、論理削除とは、テーブルに「削除日時」のような項目を作っておきます。 その後、削除する際には 「UPDATE user SET 削除日時＝現在時刻　WHERE id＝1」 のようにして、削除日時の項目に削除した時間を入れてアップデートします。 そして、データベースからデータを取得する際には、常に削除日時がNULLであるもののみを取得します。 つまり、データを直接消すのではなく、 「消したことにする」 という削除方法です。 こうすることのメリットとしては、いつ削除されたデータなのかがわかることと、万が一削除が誤操作だった場合に、削除前に戻すことが出来るという点です。 実際に業務でシステムを利用する人は、システムの利用に長けた人ばかりではありません。 スマホもパソコンも苦手な人の可能性もありますし、お年寄りが利用するケースもあるでしょう。 その様な中で、操作ミスが起きるということは多々あります。 これを復旧できないと、業務上支障が出るケースが多いのです。 例えば、ネットショップのカートから商品を削除してしまったとしても、再度カートに入れるだけなので、それほど問題はありません。 しかし、間違ってお客様の個人情報を消してしまった場合には、お客様に迷惑がかかったり、情報を再度お客様に確認することで、会社としての信用が下がる危険性があります。 そのため、カート情報は物理削除で行うが、顧客情報は論理削除で消す・・・という設計になるわけです。 ここで重要なのは、 「全てを論理削除にするべきではない」 という点です。 データが復旧できるメリットがある代わりに、論理削除の場合、データが残っているため、データベースのデータ量が多量になります。 仮に、カート情報を論理削除にしてしまった場合、 10万人のユーザーがいるシステムで、1人当たり1000件の商品をカートに入れた（その後削除や購入をした）とすると、1億件のデータが存在することになります。 こうなると、カートを検索するにも一苦労ですよね。 このように、どちらの削除方法が適切かは、データの利用用途やデータの件数によって変わってきます。 この辺りをしっかりと考えながらシステムを作るのが良いでしょう。

リレーショナルデータベース

短期スクールでは、データベースの情報を取得する経験はあるでしょうが、そのテーブルの構造したいを自分で考えることは少ない様です。 そのため、あまりリレーショナルデータベースの概念が理解できていない人も多い様です。 データを管理する上では、1つの表に全てのデータを入れるのは非効率的です。 そのため、 ・顧客マスター ・商品マスター ・部品マスター ・商品構成マスター など、様々なマスターを用意して、それぞれのテーブルを結合させる事で効率的に必要な情報を手に入れます。 この概念についても、自分でデータベースの設計をして、何度も失敗してこそ身につくでしょう。

一般的なシステムの挙動をエンジニア目線で

エンジニアとしての力をつける上で、個人的に重要だと思うことの1つが 「世の中のシステムの挙動をよく見る」 という事があります。 例えば、「ログイン機能」。 ログイン機能一つとっても、 ・ログインID／パスワードが合っているか ・ログインID／パスワードを忘れた場合の処理 ・ログイン後に飛ぶページ など、様々な機能がついています。 この動きをしっかりとエンジニアの目線で見ていくことで、自分でシステムを作る際にも役立ちます。 一昔前は、ログインID／パスワードをチェックする際、 ・ログインIDが存在しない場合 ・ログインIDは合っていてパスワードが違う場合 によって、エラーメッセージを変えているサイトが多かったです。 しかし、その場合ログインID自体が存在することが悪意のあるユーザーにバレてしまう可能性があります。 そして、ログインIDがバレてしまうと、そのログインIDに対して総当りでパスワードを入れていく事でアカウント情報が流出する可能性があります。 そのため、現在ではほとんどのサイトが、 「IDもしくはパスワードが間違っています」 というエラーメッセージに統一しています。 そうすることで、ログインIDの存在を悪意のあるユーザーがわからなくなったのです。 他にも、多くのサイトではブラウザを閉じて、再度サイトを訪れた時に、自動的にログインがされていますよね。 では、この機能はどうやって作っているのか。 ログイン情報をセッションに持たせていると、ブラウザを閉じた際にセッションは切れてしまい、再度サイトを訪れた時には、再ログインが必要になります。 反対に、ブラウザを閉じても消えないデータであるクッキーを利用してログイン情報を保持してしまうと、ユーザーによって改ざんが可能になるため、危険性の高いサイトになります。 そのため、 1.ログインする際にランダムな文字列を発行し、それをデータベースに保管する 2.ランダムな文字列をクッキーに保存する 3.各ページ訪問時にクッキーを元にデータベースを検索し、その値が存在するならログイン中であると判断する といった手順を取る必要があったりします。 これも、システムをエンジニア目線で見ていくと、 「そう言えば、このサイト自動的にログインされているな」 といった点に気付くことが出来ます。 その手法を自分で考える・調べる・先輩に聞くといった積み重ねで、エンジニアとしての経験値を積むことが出来るのです。 この様に、しっかりと世の中に存在するシステムをエンジニア目線で見ることができれば、実務経験と同様に、エンジニアとして力を付けることが出来るでしょう。

遠回りも悪くない？初心者にスクラッチ開発をお勧めする理由

遠回りも悪くない？初心者にスクラッチ開発をお勧めする理由 多くのスクールや企業では、フレームワークを用いた開発が主になっているかと思います。 そちらの方が、開発工数も少なくて済みますし、細かいバリデーションなどで、抜け漏れが出にくいというメリットもあります。 また、初心者でもある程度簡単に、それなりの規模の仕組みを作ることが出来るので、モチベーションも高く保つことが出来るでしょう。 しかし、個人的には初心者ほどスクラッチ開発がお勧めです。 一見遠回りに感じるかもしれませんが、一つ一つ処理を自分で書くことで、ロジックを組み立てる力と、1つの機能でも様々な作り方があることを感じることが出来るからです。 また、フレームワークを使っていると見えづらい ・関数化のメリット ・SQLの構文 などもしっかりと勉強することが出来ます。 これらの技術は、数を重ねなくては身につかないため、スクラッチ開発にて様々なシステムを作ることで、着実に力を付けるのが良いでしょう。

ハイレベルなIT人材はAMELAに！

ハイレベルなIT人材はAMELAに！ AMELAでは、ハイレベルなIT人材を多数抱えています。 また、自社でITコンサルティングを行っているため、業務の流れを元にした提案や、問題の根本的な解決も得意としています。 「スクールで学んだと聞いたから採用したのに、思うようなスキルレベルが無い」 そう感じたことがある方であれば、是非AMELAにご相談下さい。 御社に合った人材を派遣する事も可能ですし、そもそもの開発自体を委託して頂くことも可能です。 また、ヒアリングを行った結果、 「既存のパッケージソフトを導入する方がコスト的にも、運用面でも良い」 という様に、それぞれの企業の状況を見ながら最適な提案を致しますので、是非ご連絡頂ければと思います。