orangeitems’s diary

クラウドで働くインフラエンジニアの日々の感想です(ほぼ毎日更新)。

IT業界のヒエラルキーはなぜ生まれるか

f:id:orangeitems:20191112124110j:plain

 

IT業界のヒエラルキー

20年もの間、いわゆるSIer業界を見ているとこの、IT業界に根付くヒエラルキーの存在はいくら弊害が叫ばれても変わる気配がありません。それを見事に見える化した記事がありますのでご紹介します。

 

blog.ryo-okui-assign.com

今回は、SIerからのキャリアアップや転職先について詳しく解説をしていきたいと思います。

ビジネスとデジタルが融合し一体化している昨今では、SIer出身の人材、SEは転職市場でも非常に需要が高まっています。しかし、不用意な転職は、結局やることが変わらなかったり、やりたいことに注力できない環境だったりとリスクをはらんでいます。
そのため、正しくSE・SIerの転職市場を把握をしたうえで、転職活動を進める必要があります。

一般に出回っていない情報も沢山お伝えするので、是非参考にしてください。

 

SIerと区切ってはいますが、ユーザーサイドや事業会社にいたとしてもこの秩序は常に意識することになります。というのは、SIerと全くつきあわないでITを動かすのは無理じゃないかと思うからです。クラウドを使えばどうか、ですがクラウドもSIerが使いこなす時代に入っていますから、何が基盤であってもSIerは絡んでくるのではないかと思います。完全に内製、という企業もスタートアップ中心にあるとは思いますが、成長してくればどこかでアウトソースしたり協業したりするのが自然だと思います。もしくは外から増員のためリクルートするにしても、職務経歴書を見ながらどの辺の仕事をしていたか、このヒエラルキーを見て推察するのです。

 

考察

コーディングってどんなイメージを持たれるでしょうか。一般には、高度な最先端技術を想像されると思います。

しかし、実際にSIの現場に立つとわかるのですが、必要なのは設計書通りに作り動くことです。設計書の意図に完全に沿うことが重要です。何か違う動きでも入れたらテストで全て弾かれてしまいます。

ベテランの方が言うには、言語や仕様が変わっても、同じことの繰り返しだと。その仕様自体は特に最先端でもなんでもなくシステムなのでその通り動けばよい。それをコーディングするということを長年やっていると、全てはパターンに見える、と。

この辺りの動きは更に加速してきて、設計書を書くとコーディングまで自動で済んでしまうようなツールもあります。システム構築においてまずは要件がお客様の希望を満たすことが大事。要件をうまく導き出せないと、その通りに作っても不満だらけのシステムとなってしまいます。その後、それを設計書化し、コーディングする。このSIの流れにおいて設計書からコーディングまでがパターン化してしまっているのは、システムが扱う事柄にパターンがあるためです。だからコーディングまで自動化できるというのも事実です。

この業界も、初めはコーディングをおぼえ、そこから設計書を書けるようになり最後は要件定義までやれるようになる。これが伝統的なキャリアパスとして信じられてきましたがだんだんと、設計書をいきなり書きコーディングは自動化、というところまで実現できるようになってきています。

これが、ヒエラルキーを生むロジックとなっています。上流に行けば行くほど人間がやらなければいけないこと。コーディングは下流でできれば自動化したいこと/アウトソースしたいこと、との考え方です。

 

さて、これらの考え方は伝統的で古典的なものです。最近のモダンな考え方として、アジャイルのような、作って変えて作って変えて、という開発手法が一般化してきました。

なぜそうなったかの理由には二つあると思います。

一つ目は要件自体が大きく変わってきたこと。既存の開発手法、ウォーターフォールモデルでは後戻りができないため、世間の激しい変化についていけないということです。要件がふにゃふにゃするので、今までのカチッとしたやりかたではニーズを満たせないこと。

二つ目は、言語自体が高度化したことです。要件定義と設計とコーディングを何度も繰り返すために必要なことは、コーディング自体が要件定義と一体化することです。設計書を書くようにプログラミングができるようになってきたこと。そうなると、経営者はプログラミングができるべきだ、という概念につながるのをお気づきでしょうか。ビジネスの変化はコーディングそのものです。コーディングでできることがビジネスでできることと同義。

 

旧来のヒエラルキーとは、重厚長大なシステム構築ありきの話です。まだそういうシステムはこれからも残り続けます。一方で、ビジネスの変化によってどんどん変えていく、CI/CDという言葉に象徴されるような軽いシステムが今後主役になっていくのも事実です。そうなるとこれまでのヒエラルキーは通用しなくなってきます。むしろ世の中の変化を最も反映しやすいのが言語側で、それを使える経営者がいて、そこから仕様が決まっていくということが起こりえます。

そうなると、これまでのヒエラルキーは通用しない世界が、パラレルに生まれてくるということです。

 

ヒエラルキーを気にしないこと

最近思うのは、インフラエンジニアとか、開発者とか、マネージャーとか言う職制は、かなりこのヒエラルキーに影響を受けた部分があるのではないかということです。

言語がどんどん誰にでも理解可能なほど高度化し、かつインフラもクラウドやコンテナによって取り回しが簡単になっていく。そうすると、縦割りの職制って本当に意味があるのか。インフラエンジニアでも言語をおぼえていいし、開発者もコンテナやネットワーキングを取り扱ってもいい。そしてシステムエンジニアが経営を語ってもいいし、何でもありの世の中というのも一方で生まれつつあるのではないか。

ということで、「自分はインフラエンジニアだ!」という呪縛をあまり気にせず、いろんなことに挑戦してみようかなあとも思っています。ヒエラルキーが厳然と存在していることを知りつつ、巻き込まれない方向に向かおう、と。ITエンジニアがブログを書くのだってその一環でもあります。