【エンジニア向け】プログラムを書けないSEがヤバイと思う2つの理由

【エンジニア向け】プログラムを書けないSEがヤバイと思う2つの理由

「エンジニア」というと、プログラミングをバリバリこなすイメージがあると思うが、実際はそうではない。この記事でもお伝えした通り、エンジニアにはいくつかの職種があるということをお伝えした。

今回は、その中でもシステムエンジニア(SE)に絞り込み、普段プログラムを書かないSEの将来がなぜヤバイのか?をお伝えする。

なぜプログラムを書けないとヤバイのか?

なぜ、SEはプログラムをかけないとヤバいのか?

それは、主に以下の理由だ。

  1. 技術革新の障壁になる
  2. 顧客のビジネス進化のスピードに追いつけなくなる

では、順に説明していこう。

理由1:技術革新の障壁になる

普段プログラミングをしているエンジニアは体感していることだが、プログラミングは語学学習に近い。つまり、読み書きが基本なのだ。例えば、サンプルコードを読んで実際にプログラムを書くことで、プログラミングスキルは上達していく。

ソースコード(プログラムの原文のこと)を書かないとプログラミングスキルは上がらないし、ソースコードを読むのが辛くなってくる。

近しい例として、3~5年ほど昔、とある案件で、リフレクション(※)という実装方法を採用するか否かの議論があった。

※リフレクションという実装方法を使えば、ソースコードを機能単位で別々にしやすくなるので、疎結合化(お互いに依存しないこと)を図ることができる。

結局、その当時はリフレクションは採用されなかった。

その理由は、なんと、

他のエンジニアやソースレビュアーが、ソースコードを読めなくなるから

という理由だった。

プログラムが書けないSEは、後述の通り大手SIerほど多い。海外にはソースコードを読み書きできないエンジニアはほとんどいないので、日本特有の現象の様だ。

システム開発の元受けにプログラムの読み書きができないエンジニアが増えると、採用されるアーキテクチャが旧態依然のものとなりシステムの進化も鈍くなる。彼らSE達が分からない仕組みで納品されると、品質の最終チェックを行えなくなるからだ。

さらにそれが進むと、ソースコード自体が負債(技術的負債)となり最新技術を導入しづらくなる。つまり、自社製品の技術革新スピードが、日に日に遅くなってしまう。

その結果、今まで苦労して開発してきたシステムが、近い将来AmazonやMicrosoft、Googleが提供しているサービスに安価で置き換わってしまう、ということだってありうるわけだ。

顧客も、大金出してシステムを1から作るより、彼らの安いクラウドサービスのほうがよい、という話になってしまうだろう。

理由2:顧客のビジネス進化のスピードに追いつけなくなる

次に、システムの提案が、顧客のビジネスの進化に対応できなくなることが考えられる。

レガシー(旧世代)の技術では難しかったことが、技術の進歩によって可能になったということは珍しくない。

特に、最近では、機械学習やビックデータ基盤がクラウド化し、いとも簡単に既存システムにアドオンできるようになった。優秀な経営者は、そういった技術的進歩をマクロの視点から常にキャッチアップしている。

私の顧客は中小企業の経営者が多いが、彼らはAI(人工知能)や機械学習、AWS・Azureといったクラウドシステムのことを非常によく調べている。特に、

いかに、最新の技術をフル活用して、人的コストを抑え生産性を上げるか?

を常日頃から模索しているのだ。

普段からプログラムを書いて技術の進歩を体感しておかないと、いざシステムの提案を行う際に、顧客の要求に対して充足する提案を考えるのが難しくなってくる。

大手SIerの実態

大手SIerは、Google、Amazon、Microsoftをはじめとした情報通信大手との取引があるため、日頃から最先端の技術や知識を学べる環境にある。情報処理のさまざまな資格を取ることもできるし、仕事も安定しているし給料も高い。安定を優先する人であれば、是が非でも入社したいと願う。

ところが、徐々に社内で昇進していくと、プログラムを全くといっていいほど書かなくなってくる(中には書き続けるツワモノもいるが・・・)

プログラミングやソースコードレビュー、テスト工程については外部に丸投げするケースが多いので、自分でプログラムを書いて最先端技術の裏付けを行ったり、バグが出やすいポイント等を体感的に経験できない。

つまり、せっかく学んだ最先端の技術や知識が、机上の空論で終わってしまうことがあるのだ。

大手SIerのSEになってしまうと、0からプログラムを書いてシステムを開発できる人がめっきり減ってしまうのだ。

上流ほど危険

それもそのはず。彼らSEのメインの仕事は上流工程、すなわち顧客との要件定義や設計レビュー、開発プロジェクトの進捗状況の管理である。

SEの中には、設計書やガントチャート(タスク管理表)をExcelで書き続けたあまりに、Excelマスターになってしまう人もいるくらいだ。

その結果、プログラムを書けないだけでなく読めないエンジニアが増えてくる。

それでは、エンジニアは顧客に出来上がりイメージや仕様上の注意点を共有できない。

まるで、素材の性質を知らずに家の図面を作成する建築士と同じだ。

特に、パッケージソフトウェアのカスタマイズ担当として、要件定義や設計書ばかり作成しているSEは要注意だ。せめて、パッケージの内部構造(処理フロー、データの持ち方など)がどうなっているか?ソースコードを読んでおいた方が良いと思う。

プログラムは書けたほうが良いに決まっている

これからAIがどんどん導入されるようになると、人間の単純作業はAIに置き換わっていく。単純なプログラムコードもAIが自動で実装できるようになる時代が来るとも言われている。

しかしながら、どのような職種であれ今従事している専門的業務を効率化・AI化する上では、プログラミングを学んでおいた方が、

AIを使う側ではなく、所有する側にまわることができる

という点で、先行者利益を得られるだろう。

日に日にプログラミングの参入障壁は下がってきているので、少しでも勉強しておくことをおすすめする。