2000年頃から現在までのSE変遷を振り返ってみた

これからシステムエンジニアになりたいと思う人向けに、自分の経験を元にしたことを少し書いてみたいと思います。

2000年頃のSE事情

私がこの業界に入った2000年頃は、クラサバと言われるシステム構成が主流だったように思います。

VisualBasicやVisualCというプログラム言語を、VisualStudioというSDKでコーディング。それを同SDKでコンパイルすることでEXE、OCX、DLLという形式に変換して実行環境で動かす感じです。

クラサバは、クライアント・サーバ・システムの略で、主に画面系の機能はクライアント、つまり使用するパソコン（PCと呼称）にプログラム実装され、サーバ側にはデータベースやバッチ処理系が実装されている方式です。
ですので、PC側にはビジネスロジックを含むプログラムの他に、データベースとの接続を補助するためのプログラムも実装し、ビジネス機能実態はPC側に主体が置かれているイメージです。

クラサバ構成のメリット

これは後発するWebシステムを経験して気付くことですが、画面が非常にリッチに作れます。
なにしろ機能実態がPC側なので、ネットワークを介さずに画面制御はPC内で全ての処理が完結します。
これにより一時期はMDIという１つのアプリケーション内に複数の画面を同時に見せるような複雑な画面構成が流行りました。画面同士は依存しあったりもするので、それを実現させられたのもクラサバのメリットと言えるでしょう。

クラサバ構成のデメリット

小規模なシステムであれば問題はなかったのですが、例えば利用者が数百名ともなるようなシステムだと、当然そのアプリケーションを実装するPCも数百台ということになります。
そうなると、システム変更が発生した場合のプログラムの再配布なども一苦労です。

SDKのメリット

VisualStudioでの開発では、GUIが非常に有効に使われており、画面レイアウトを作るのはGUIで部品を置いていくような感覚でできました。

2010年頃のSE事情

実際にはそれより前あたりからですが、Webシステムというのが主流になってきました。
依然としてクラサバシステムを継続しているところはあるにしても、シェアとしてはWebシステムに変わってきたと思います。

当然これより前からWebサイトというものは世の中では使われていたものを、社内システムなどでも同じ方式を使って構築するという動きですね。なので、Webサイトとは画面デザインは異なっていますし、一般的にWebサイトは静的サイトが多い中で、社内システムはデータベースを扱っての動的な機能が求められますので、似て非なるものという感じです。

SDK／言語としては以前としてVisualStudioでのVisualBasicやVsisualCがある一方で、Eclipse等のJava系のSDKや言語も当たり前になり、言語やSDK、フレームワークの種類が非常に多くなってきました。また、Webシステムの根本はHTMLとJavascript、あとはサーバサイドではASPというところもあるので、SDKを使わずテキストエディタで開発するプロジェクトもありました。（一般的な用語かはわかりませんが、クラシックASPという言い方をしていましたね）

Webシステムは、機能実態はサーバ側になります。サーバ側にはビジネスロジックを含むプログラムとデータベースが実装され、サーバ側のビジネスロジックで生成されたHTML、JavascriptをPC側のブラウザで画面表示するという方式です。

慣れれば普通でしたが、初めの頃は、サーバサイドで動く処理とクライアントサイドで動かす処理をまとめてプログラミングするというところにすごく苦労した記憶があります。

また、プログラムをリリースモジュールの考え方も変化がありました。
Windows系であれば以前としてEXE、DLLなどですが、原理としてはサーバサイドでこれら実行ファイルがクライアントに向けてHTMLを出力するというところになり、Windows以外でも何らかの実行ファイルに変換したものをサーバに配置して同様の原理で動くもの、もしくはプログラミングしたファイルをそのまま配置して直接HTMLをクライアントに出力するものと、言語やフレームワークによってまちまちです。

Web構成のメリット

なんといっても保守性の簡素化です。
クラサバでは、PC側のプログラムリリースが、規模が大きくなればなるほど大変でしたが、Webシステムはサーバ側へのリリースになるので、その点の苦労がありません。

Web構成のデメリット

画面がリッチに作れないというところがデメリットになります。
Javascriptで画面の動きを作れるものの、基本的にはリクエスト／レスポンスで画面遷移する仕組みなので、表示を変える場合には一度サーバサイドへのPOSTが発生し、画面全体のリフレッシュが発生しました。逆に言えばPOST発生による画面リフレッシュを軽減するためのロジックを講じる必要がありました。
Ajax等も、この画面全体のPOSTを軽減し、画面操作のぎこちなさを解消するための技術でしたが、これ自体ではなかなか広く定着しなかった印象です。

当然クラサバシステムで可能だったMDIが向かないので、SDIが主流になります。

画面作成作業の変化

Webシステムでの画面はHTMLになるので、SDKによってGUIで画面を作るプロジェクトも一部残る反面、HTMLをテキストエディタで書くというスキルも求められるようになってきました。実際にはHTML、CSS、Javascriptですね。

2020年頃のSE事情

最近はやはりクラウド化というのがトレンドワードになってきます。
でも「クラウド化」って意味合いは捉える人によって、結構違いがあるように感じますね。
身近な人だと、Webシステム＝クラウド化だと思っている人がいますが、非常に狭義としては間違っていないのですが、私としては「この人解ろうとしてないな・・・」という印象です。

最初の解釈としては、これまでWebシステムであっても基本的には各企業のLAN内に構築するいわゆるオンプレと言われるインフラ環境だったのに対して、クラウド化はインターネット上にWebシステムを配置するということになります。
言葉にすると、これだけですが、これが意味するところは非常に大きいです。

Webシステムをインターネット上に配置するということは、これまで企業内に提供していた機能が、一般もしくは広く利用者に提供できるということになります。つまり社内機能という考え方がBtoB、BtoCというサービスという考え方に変わるということです。これが一般的にいうクラウドサービスですね。

他の側面では、完結したシステム、例えば顧客管理システムとか、人事給与システムとかの単位ではなく、もっと小さな例えば地図情報を検索するとかの単一機能でのサービス提供であれば、利用する側がそれを組み合わせることによって、セミオーダー的なシステムを構築することができる。これを最近ではマイクロサービスという考え方として提供する企業も増えています。（参考までに、従来のように完結したシステムをモノリスという言い方をします）

そして、ビジネス的なサービスだけでなく、もっとインフラ的なサービス提供がされているのがAWSや各社VPSなどのサービスです。インフラを物理ではなく仮想として用意することで、利用者がシステム構築する上で、必要な時に必要な分だけというメリットで提供を受けるサービスですね。対象はネットワークからサーバ、データベースに至るまで多岐に渡ります。

これまでのSEは、プログラムを作ること＝システムを作ることだったのに対して、現在のSEはプログラムを作ることではなく、市場にあるあらゆるサービスを理解し、適材適所として考え、それを補完するために最低限のプログラムを作るというイメージになってきてると思います。

プログラミング的な目線で言えば、クラサバからWebを経て、API＋フロントエンドというシステム構成が主流になっていると思います。
クラウドサービス化によって、機能（＝サービス）はAPIという形で提供され、それをUIとしてどのように利用者に表現するかをフロントエンドシステムで実現する形です。
Webシステム時代のサーバサイドに機能主体を置いていた方式を踏襲し、その出力をHTMLからJSonを代表するデータ形式に変えています。一方でフロントエンドシステムは、Ajaxを含むJavascriptを強化したフレームワークが登場することで、クラサバ時代の画面並みにリッチな制御が可能になりました。体感的には、クラサバシステムとWebシステムのハイブリットという感覚です。

API＋フロントエンドシステムのメリット

Webシステム同様に保守性の簡素化があります。
ベースはWebシステムですので、同じです。

フロントエンドシステムは、フレームワークが充実したことにより、従来のJavascriptよりもコーディングがわかりやすくなった印象があります。その上で、処理の記述が１次元的（Webシステムではサーバサイド処理とクライアントサイド処理を理解しながらコーディングしていたのに対して、クライアントサイド処理のみを意識すれば良い）になっている点もメリットと言えます。

あとはAPIとフロントエンドでシステムが疎結合であるため、メンテナンス性も良く、且つ作業の分業化が容易というのもあります。

API＋フロントエンドシステムのデメリット

APIとフロントエンドシステムは、Webシステムとしては別々に構築するのが一般的です。（非モノリス）
結果、WebサーバやAPサーバ、あとはhttp通信の制限的な部分にも知識が必要になってきます。
プログラムだけという視点から、インフラ寄りの視点も必要になってくるということです。

また、メリットで挙げた分業化の逆説になりますが、言語／フレームワークの多様化があると思います。
つまりAPIとしてプログラミングする上でも言語／フレームワークが多様にあるものを選択し、フロントエンドとしてもフレームワークが多様にあるものを選択するということで、スキルが多様化する傾向があると考えます。
（だからフロントエンド技術者という専門性も出てくるのかと）

まとめ

この20年で技術動向はものすごい勢いで変化しています。
しかし、ずっと携わっている者としては、結局は何が一番有効かという命題に対して、行ったり来たりして最適解を探している印象があり、これからも変化は続いていくのでしょう。

SEとして大事なのは、常に変わり続けること。変化についていくことなのだと思っています。

今回はプログラミング技術に視点を置いて、時代変遷を書いてみましたが、これはほんの一部だと思います。

自己学習は続ける一方で、書き物／読み物としてのアウトプットをしていくことも続けていきたいと思います。