🖥️そもそもスクラッチ開発偏重がエンジニア不足の原因ではないか？🙄

ＩＴ業界は人手不足と言われて盛んですが、ではＳＥＳでアサインされる案件は何が多いかと言うと、事務代行が多いです。
一応名目的には《システム運用》なんて職種が割り振られてますけど、職業としての「システム運用職」なんてものは存在しないんですね。

一方で、本当に不足しているエンジニアは「マトモな（コードを書ける）エンジニアだ」と言われていますが、各方面の話を聞いてると「マトモにコード書けるエンジニアが少ないと分かってるのに何でカスタマイズやスクラッチ開発やりまくってるんですか？」って言う疑問にぶち当たります。

ぶっちゃけエンジニア不足と言うのは顧客起因によるものも多いと思うのです。

💻スクラッチ開発に拘れば人は不足します

思うに、なぜ日本でエンジニア不足が起こるのかの最大要因としてスクラッチ開発にこだわる会社が多いんですよね。

スクラッチ開発ともなれば要件定義からコーディングまでの間ですら、結構な時間は掛かります。
そこからコーディングして単体テストやら結合テストやらをするんですから、まぁ当初の見積もり通りに終わることは稀のまた稀でしょう。
時間も費用も膨らむのは当たり前なのですが、どうも日本企業は大きくなるほどスクラッチ開発に拘るように見えます。
スクラッチ開発に拘れば当然、現場のエンジニアは不足します。

📊意外に活躍し続けるオールドランゲージ

次にエンジニアが不足する要因ですが、これも「熟年世代が思うマトモなエンジニア」と「若手が思うマトモなエンジニア」には乖離がある気がします。
この辺は職業プログラマーでない私には実情がわかっているわけではありませんけども、妙に日本の会社では古い言語やフレームワークが役に立ってませんか？

代表的に厄介なオールドランゲージ（テクノロジー）がVBAです。
ミレニアル世代以前の世代にはマクロ職人がちょいちょいいて、マクロが神のように崇められていた時期がありました。
マクロができる人間＝重宝されるのですが、実はＱＣ視点で見ると、マクロは非常に不味かったりします。

日本の開発現場ではＪＡＶＡが非常に出番が多いと思いますし、現在もＪＡＶＡは進化し続けている言語ではありますが、実際の開発現場では最新のフレームワークやライブラリを使うのか、それもとオールドライブラリーなのか。

若手としては今流行りのPythonをメインに頑張って稼ぎたい。
ところが実際の現場（特にＳＥＳ）で求められるスキルが意外にオールディーなランゲージだったりして、若手の目指す（やりたい）方向性と、実際の現場で求められるスキルには差異が大きいんじゃないかなと言う気がします。
この辺はホント、実情はわかってるわけではないので、もし現役のプログラマーの方で実情わかってる方がいたら是非コメントをください。

🔧カスタマイズの多さが現場を圧迫する

せっかくパッケージソフトを入れたと思っても、カスタマイズが多かったりしますね。
これは前々社のサポセンでも本当に頭を抱えました。
てかぶっちゃけ何もできません。
カスタマイズだらけで⚪︎⚪︎社のことは⨀⨀エンジニアしかわからない。
こんなことが当たり前のようにあり、もうお手上げです。
日本の商習慣では｢働く人に合わせてシステムを変えてしまう｣んですね。
到底、こんなことではエンジニアは足りないです。

🌐業界毎に標準化されたシステムが必要

自治体に関してはガバメントクラウドによる業務標準化が為されようとしてますけれど、民間企業ベースで行くと、業界標準化は相当時間が掛かりそうです。

こう言ってはなんですが、例えば三菱重工と川崎重工の基幹システムが同じパッケージシステムだとしても、大きな問題は起こらないと思うんですよ。
何なら日立・川重・日本車両製造と新幹線車両製造会社が一律で同じ基幹システムを使ったとして、多分大きな問題は起こらないと思います。

もちろん三菱重工と川崎重工ではグループ形成の仕方が違いますけども、大雑把な括りで言えば「重工業である」と言う括りが同じで、少し細分化して「鉄道車両や自衛隊用の兵器を作る会社」と言う点でも一致しています。
業界としては同じなんですね。

いわゆるITが進んだ国っていうのはシステムの標準化が進んでると思います。
結局のところ「各社ごとにスクラッチ開発（カスタマイズ）」なんてやってたらエンジニアなんて幾らでも不足するし、業界毎に共通パッケージを設けて標準化／業界最適化をしていかないことには、エンジニア不足なんてどうにもならないし、何なら日本の経済体系（生産性向上など）は変わらないのではないかと思います。