変わっていくスタンダードと、振り回されるエンジニア | A Day In The Boy's Life

A Day In The Boy's Life

とあるエンジニアのとある1日のつぶやき。

当たり前のことですが、技術や世の中のスタンダードって変わっていきますよね。

それは、技術の進化だったり、意識の変化・浸透だったり、自分の成長だったり、何れにせよその時代によって求められるレベルというのは変化しています。


それは、進化のときもあれば、解体と再生でプラマイゼロという場合もあるでしょう。

ただ、そのスタンダードの変化に振り回されるエンジニアも多いのでは、と思ったり。



求められる技術平均


求められる技術レベルの平均値というのもどんどんと押し上げられていってるのかな、と感じたりします。

それは全体のレベルが上がっているというより、世の中に情報があふれたり、ユーザーの意識の変化であったりして、技術の成長はしていなくても、ここまでできればOKという感覚だけがかなり一人歩きしている気もします。

ユーザーの目が肥えたせいなのかもしれませんし、インフラの発展によって開発のスピードが上がった結果なのかもしれませんし、技術先進の企業が凄いサービスを打ち出し続けたことによるものなのかもしれません。


ただ、エンジニアのスタート地点というのはいつの時代も一緒だったりもします。

Linuxエンジニアならコマンド覚えて、プログラマーならHello Worldからとか。

教育する方もスタート地点を理解していないわけではないのですが、情報過多な時代とひどくマニュアル化された環境が、スタート地点をレベル1と捉えると、次のマイルストンがレベル3だったり


そして、その成長の過程で、「これなら戦力になる」というお墨付きをもらえるレベルというのだけは、高くなっていってたりします。

PHPer歓迎というところから、セキュリティやアーキテクチャ、デザインにいたるまでごった煮でやれないとダメというような感じで、単にその技術を知っているだけというのでは、なかなか合格点をもらえなかったり。

世の中、これだけ変化しているんだから「ここまでできて当たり前でしょ」という感覚の道程だけが伸びているというか。


例えば、自分から見た新人エンジニアのレベルと、2年目3年目のレベルというのはより高い方向に向いていきます。

自分のスキルの半分ぐらいのレベルは持ってて欲しいと思っても、年々自分も経験値が増えていっているわけで、そのレベルは高くなっていきます。

また、世の中の技術が安定していく過程で、ここレベルまで達成するのは難しいというレベルから、「それは今では当たり前」というレベルへ変化したりもします。


なので、自分たちが新人だった頃に求められたレベルへの過程と、今の新人エンジニアが求められるレベルへの過程というのは随分と違うものになっているのではないかなと。



合格レベルの過程


もちろん、その合格点のレベルに行き着くためのコストというのは、昔と比べて格段に下がっていると思います。

インターネットで調べれば情報が出てくる場合も多いですし、書籍も豊富になってきています。

技術はより安定し、便利で簡単になっていくと、そのレベルに行き着くまでに階段三段飛ばしぐらいの勢いで駆け上がることもできたりします。


先に書いたレベル1の次がレベル3の教育というのも、レベル2の知識は自分で調べましょうね、という具合にひどく個人任せにされているような気もします。

あくまで当面の業務で使う知識レベルが前提ということで、今の技術がカプセル化してしまった要素というのは興味を持ったら調べてみようね、とか。


しかし、その飛ばした分はやはり後々求められる要素というものが含まれていて、「ここまでたどり着いたら、このレベルのことはわかっているよね」ということにギャップが生じたりもします。

とりあえず動くアプリケーションを作るということに専念した結果、セキュリティやアーキテクチャ、アルゴリズムもちゃんと理解しているんだよねぇ、と。


短期間で今のスタンダードな知識レベルを求めれ、それに達したかと思うとそのスタンダードなやり方の中に含まれない知識を求められたりします。

そういうことは求められる状況の中で理解したり、経験の中で身に着けていったりするもんだと思ったりもしますけど、ゴールに達成したならそれは理解しているのだろうという勝手な判断が出来上がってたり。



失敗する環境が無い


求められるレベルに達するには、より深いところに掘り下げていく必要があったりもしますが、その環境というのはなかなか用意されていなかったりします。

ユーザーの求めるサービスレベルが高くなれば失敗できない環境になるでしょうし、開発環境といえど好き勝手にやって良いよ、というわけにもいかなかったりします。


お客さん先に常駐してたりすると余計無いことはしてくれなと言われる割に、トラブルが起きた際の対応マニュアルを書けとかいわれたり。

なので、理論上そうなるであろうということだけで、例外的なことは切り捨ててしか書けないわけですよね。


自分たちの時代ではITの不安定さを理由にしたりもできたりしましたが、今はユーザー目線のスタンダードの変化によってそういうことが許されなくなったりもしています。

(自分としては、システムなんて落ちるもんだと思ってたりもしますけど)

経験豊富なエンジニアであれば、今の環境でどう対処するかということを考えたりもできますが、経験が浅いエンジニアではなかなかその答えがわからなかったりもします。


とりあえずトライしてみる、失敗する、リトライするということを容易にできる環境がなかったりするわけです。
それに対処する方法を知らない、存在しないのに、求められるレベルだけは年々高くなっていっているのではないかな、と。


ここに書いたことは、ひどくマニュアル化したエンジニアを育てようとする企業によって生み出されているのかもしれません。

エンジニア側としては、企業内に自分の自由にコントロールできる環境がないのであれば、それを外に求めるのもいいのかもしれません。

昔と比べ、その環境を持つコストというものは随分と下がっています。

そして、情報豊富なこの時代なりのスタンダードなスキルアップ法というものを身につけていかなくてはならないのかもしれませんね。