スキル不足なエンジニアはマネージャと人事部で作られる

エンジニアの技術転換は何も『スキル不足で職場に居場所がないおじさん』のスキル不足だからとは限らない。

 

blog.tinect.jp

 

Javaがでてエンプラ系でわっと広がりを見せはじめて暫くした後、当時の組織ではJavaをやっていないエンジニア全員にJava研修を強制的に受けさせていた。いわゆる技術転換というやつである。できるかりぎ近寄らないようにしていたが、全員受講したかどうかトレースされ渋々受講した。そんな気持ちで受講しているから単に受講しただけでしかない。

中途半端に体力があるSIerだと絶滅すると言われて久しいCOBOLerのおじさんが生息していた。あれほどITなんとかというメディアなどでレガシーとか叩かれていた言語でもビジネスニーズがあれば細々と生きながらえる。中堅のエンジニアも見かけたから人的には補充するほどだったのだろう。言語の栄枯盛衰で言えば、エンプラ系で使われなくなった言語はPL/1くらいではないだろうか。

COBOLからJavaの前はCOBOLからCへの技術転換もあったはずだ。いずれにしろ、ビジネス的にいよいよ先がないと経営サイドが諦めざるを得ない判断した時点(その意思決定自体どうかと思うし、とても遅い)でエンジニアの技術(言語)を転換するという発想がおかしい。

屁理屈で言えば、言語は道具でしかない。業務の課題を解決する仕組み(アーキテクチャ)を実現するために適切な開発手法と合わせて言語を設定しなければならない。

エンジニアにとって必要なのは課題解決する業務は何か、何が課題か、課題を解決する仕組みはどうするか、そのアーキテクチャの実現性はどう評価するか、などなどのスキルが必要だし、実際に課題を解決する仕組みをプログラムで実現できなければならない。

今思い出しても、現場でレガシーで技術転換を必要とする技術的に塩漬けにしておいた過去のマネージャや育成を所管していた人事部が何をという今更感があるが、そもそもSEと呼ばれているITエンジニアは工員の延長線上の教育しかされてこなかったのである。

以前の新入社員の集合研修では開発フェーズしかやらない。これで何が起きるかと言えば、業務をOAつまりプログラム言語に置き換えることしか起きない。業務のOA化である。だから、業務の課題はどのようなものか、解決方法にどのようなアプローチがあるかなどと知る必要がない。狭い範囲での業務を知っていればいいのである。10個の手続きがあれば10個の手続きをプログラムに置き換える。これがOA化である。IT化するなら1→10に飛ばしてもいいのである。

それを必要だとやってこなかっただけの話である。今後、ITエンジニアは二極化、2種類に世界線が分かれるだろう。1つはOA化しかできないエンジニア。もうひとつは業務をITで実現できるエンジニア。

 

 

 

 

 

OAD付き 転生したらスライムだった件(13)限定版 (講談社キャラクターズライツ)

OAD付き 転生したらスライムだった件(13)限定版 (講談社キャラクターズライツ)