IT日記

Webエンジニアの徒然草

システムエンジニアという名の不思議な職業

至る所で語られているが、今回はSE(システムエンジニア)という職業について書く。

この語の意味するところは多岐に渡り、明確な定義は難しいが、建築家と大工の違いをSEとプログラマの違いに例えた説明が時折見受けられる。

プログラマはコンピュータにいかに動作するかを指示するプログラミング言語を操り、ソフトウェアを構築する。大工が現場で材料を加工し、建築物を組み立てるように。

対して、SEはプログラマにどのようなシステムを作るかをプログラマに指示するのが仕事だ。全体の設計資料を作成するのが役割であり、実際に現場で手を動かすのは本義ではない。資料作成においても専門的なツールよりは、一般的な事務作業に用いられるMicrosoft製のExcelやWord、Powerpointといった汎用的なものを使うことが多い。その役割上、SEの中にはまともなプログラミング経験もなく、単独でソフトウェアを作り上げる力のない人間もいる。エンジニアの名を冠していながら、実際にはエンジニアと言えるか怪しい職業なのだ。

そして、SE達を擁する企業はSIerシステムインテグレーター)と呼ばれる。現状、こうしたSE、SIerといった語が好意的な文脈で用いられることはあまり無い。

官僚的な企業文化に起因する非生産的な会議の多さ、後から見返されることも無いような形式的な設計書作成などといった、意欲があり有能な人間にはあまり魅力的に映らない業務がその原因だ。

また、大手SIerが仕事を下請けのSIerに外注し、その下請けがさらに小規模なSIerに外注する多重下請け構造も一因となっている。例外もあるが、下層の企業に属する人間には細分化された作業しか任されないことが多く、やりがいやキャリア形成の面で不利なためである。もちろん、中抜きされているので給与面でも報われにくい。

仮に最上層の元請けSIerに所属したところで、実業務をすべて外注し、関係各所との連絡役に徹するようなエンジニアとは名ばかりの職務になりがちである。こうなると前述した自力ではまともにプログラミングもできない人間になり、ソフトウェア開発に関してスキルアップが難しい。

そして、SIer業界の報酬水準自体が年々下落傾向にある。人件費の安い新興国へのアウトソーシング、作り込みを必要としないクラウドの台頭などがその理由として挙げられる。加えて、開発ノウハウがコモディティ化しているため業務コンサルティングなど別領域にまで手を広げないと厳しいなどとは言われて久しいことだ。たとえ元請けであっても、ろくな差別化も出来ないのなら顧客企業よりも強い立場にはなり得ない。

そもそもが受託開発という労働集約的な仕事をこなしており、たとえ売上が上がったとしても収益性の面では旨味のある事業ではない。

産業の盛衰を見抜くのは至難とはいえ、有為な若手が今から就くべき職業にはとても見えないのだ。

ところで、SIerという業態は諸外国ではあまり見られない。一説には、その原因は日本の終身雇用的な雇用習慣である。

米国などではシステム開発が必要であれば、通常外部の開発会社に委託するのではなく自社のシステム部門で開発することを考える。外注よりも割安な上、自社の人員であれば柔軟で素早い対応が期待できるためだ。

一方、従業員の解雇が法規制上難しい日本では、一旦自社のシステム部門に人員を抱えると、開発が一段落して人員に余剰感が出てきたとしても、おいそれと首は切れないのである。こうなると、たとえ短期的には割高であっても外部へ開発を委託するニーズが出てくるという訳だ。

近年では、 IT業界の中でもSIerと対比してWeb系といった単語が出てきている。Web系企業においてはプログラマとSEといった役割分担がほとんどなく、一人の人間が自分で手を動かしてプログラミングをするだけでなく、設計までも求められる。そのため、ソフトウェア開発について網羅的なノウハウが身に付きやすい。

また、その企業文化もアメリカ西海岸のシリコンバレーの流れを組むような、自由なものが多い。たとえ受託開発であろうとも、形式的な会議や文書の大量生産は忌避される。そして、インターネット上で独自のサービスを展開して収益を上げる企業も多い。

意欲と能力のある若手を中心にSIerからこうしたWeb系企業への転職を望む者が増えているようだが、この傾向は強くなることはあっても弱くなることはないだろう。

 

システムインテグレーション崩壊 ~これからSIerはどう生き残ればいいか?

システムインテグレーション崩壊 ~これからSIerはどう生き残ればいいか?

 

 

ベンチャーという名の幻想

ベンチャーの定義は様々だろうが、一般的には革新的なプロダクトやビジネスモデルで急成長を目指す企業を指す。だが、実際にはベンチャー、スタートアップを名乗っていてもこの定義に当てはまるか怪しい企業も多い。

実態は単なる中小零細企業であり、ITの分野では例えば、革新的なことなどまともに出来ていない単なる受託開発会社も珍しくはない。名乗るのに免許が必要になるわけではないのだ。

なぜ、ベンチャーと名乗るのか。はっきりいって対外的な見栄えのためであろう。特に人材採用面においてその名は効力を発揮する。

近年は緩和されてきた感はあるが、株式の上場を第一とし、従業員の過剰な労働を正当化する社風を持つところもある。劣悪なところでは、従業員に自社株を付与していないにも関わらず、である。(上場して主に利益を得るのは、その株を保有している者だけである。)

仮に自社株を保有していたところで、上場まで成長する企業の方が結局は少数派なのである。そのつもりもないのに一種のギャンブルをするのであれば、自社株を付与してもらう代わりに現金で給付されたほうがマシというものだ。

また、早くから仕事を任されるためより成長できるなどという謳い文句を言う会社も多い。特にこれらは新卒や社会人経験の浅い若手に向けて発信される。

早くから仕事を任されるのは嘘ではないが、要は人手が足りないのである。まともな訓練や引き継ぎもなく業務を行うのは、満足な装備を整える暇もなく実弾の飛び交う戦場に駆り出されるようなものだ。もしくは、誰でもできるような雑用ばかりを任せられるかである。得てして、小規模な会社では経験の浅い人員に訓練を施す余裕など無い。

ベンチャーを名乗る全ての会社に当てはまるわけではないだろうが、結局のところ、実際の待遇の悪さを夢や希望、成長などという曖昧なものでごまかそうとしているのがその実態である。読者には、企業選びの際にはそうした表面的な言葉に惑わされないことを心がけて欲しい。

ITエンジニアの仕事なんてくだらない。

いきなりネガティブなことを書く。

エンジニアといえば一般には何かものを作る仕事だと思われるだろうが、ことソフトウェアエンジニアに関してはそれは些か誤りだ。少なくとも、創作物のすべてを自分で作るようなことはしない。

技術が成熟した現在、概ね当該分野のどのソフトウェアでも共通で使われるような部品(ライブラリやフレームワークと呼ばれる)がいくらでも出回っているため、毎回いちから作り上げるようなことは効率が悪過ぎて普通やらないからだ。木造建築を建てるのに、樹木を育てるところからはやらないように。

実際の仕事ではライブラリやフレームワークの使い方を調べ、それを動かすための、時に僅かなソースコードのみを自分で書くことになる。取扱説明書の通りに部品を組み立てる日曜大工と変わらない。大した創造性も必要ない。

では、そうしたライブラリやフレームワークといった開発基盤自体を開発する仕事をすれば良いと思うかもしれない。しかし、そうした共通化しやすい部品というのは大抵、とっくに誰かがオープンソースとして無料で公開している。

しかもライブラリやフレームワークといった部品は年々、洗練されたより使いやすいものが開発されている。プログラミング言語自体、より少ないソースコードでロジックが記述できるものが採用される流れもある。より簡単にソフトウェアが開発可能になる反面、ソフトウェア内部の複雑で開発難度の高い部分をやってもお金にはなり難いのだ。

一部のマニアたちが担っていた仕事から、誰にでもできる仕事に変容してきているのだろう。