見出し画像

1995年と2000年のSIの架け橋

この話は1995年のダウンサイジングと2000年の2000年問題への対応でのERP導入の話だ。
最初に書いておこう。この2つは密接にかかわりがある。そして、いまの事業会社のITシステムはこの頃からコアな技術はそんなに進化していない。
当時のエンタープライズUNIXがLinuxになり、オンプレミスがクラウドになったが、アーキテクチャそのものは、そこまで変化していない。
RDBMSもインメモリーデータベースを採用しているアーキテクチャはあるが、RDBMSでデータを管理していた頃と思想そのものは変化していない。
画面がHTMLのWebを使うようになったが、3層構造であること自体は2000年から変わりない。

ERPは基本的には当時のRISC-CPUのエンタープライズUNIXのサーバで動作していた。これはダウンサイジングでメインフレーム以外の選択肢としてUNIXサーバが出てきたのだが、これはERPとUNIXサーバのどっちが先かは卵と鳥の問題だ。
ERPがあったからUNIXサーバが普及したとも言え、メインフレームより買いやすい価格のUNIXサーバがあったからこそERPの普及が進んだのもある。
さらに言えば、このダウンサイジングの時に2000年問題が出てきたこともある。また、まだ家庭へのインターネットというかTCP/IPの普及はまだだったが、企業へのTCP/IPの導入が進んだのもこのERPの時だ。
しつこいが続く。そこにWindows 95以降のいまのWindowsに続いているモダンなWindowsが発表されたこともある。この時に企業の本社業務なら全員の机の上にPCが置かれるようになった。

だいたい、2000年に30歳前後だったエンジニアは、いまも現役などころか、2000年対応への経験がいまだに買われて人材市場では評価されるぐらいだ。
それでも、当時、おおむね40歳以上だったエンジニアはこの数年で現役を引退している。だが、スキル的にはいまでも通用する。
このあと、リーマンショック、東日本大震災、Covid-19があり、大規模な開発プロジェクトが少なくなり、2000年対応ほどの大きな経験をしたエンジニアは思っているより少ない。
最近、ERPを中心に据えた基幹系システムのエンジニアを見ていると改修すらもしたことがなく保守の経験しかないエンジニアが多い。
この話から外れるが、これで2027年問題を日本は対応できるか?はい、できません。本当にコードの保守をしていただけのERPなのに簿記いや業務そのものも理解しない/しようとしないで惰性で仕事をしていたエンジニアには無理です。

本題に入ろう。
まずは、1995年のダウンサイジング。
僕のクライアントは東証プライム上場企業(当時の一部)でメインフレームからダウンサイジングしてEUC(エンドユーザーコンピューティング)などをやりたいので、UNIXサーバでRDBMSを使った品質管理システムにリプレースしたい要望への対応だった。
僕は、この時、はじめてOracle RDBMSをさわった。そして、SQL-92とC言語を覚えた。
C言語はもう組み込み以外ではあまり使われなくなった。とはいえ、その後のJavaはC言語の影響が大きい言語のため、Javaへの僕の移行はかなり楽だった。
Javaのオブジェクト指向を学ぶのに苦労した覚えもない。文法などは僕は関東人だが関西弁を使うぐらいの程度のものだった。
C言語はポインタを使いメモリ操作が必要な言語だった。これは勉強になった。いまでも、メモリの確保を意識したコーディングができる。どんな変数の型や構造体などがどんなメモリの使い方をしているか、Java以外でもだいたい見えている。
phpでもサーバでどんな動きをしているかは想像できる。いまでも、このC言語をやった知識は生きている。
そして、SQL-92。
この後、SQL-99を採用したOracleを使用しているプロジェクトにも僕は関わるのだが、この時もSQL-92を使いこなさないとどうにもならなかったので、ここで鍛えられていたため、苦労をしなかった。
Oracleのチューニングもここで覚えた。ただ、この知識RDBMSが高性能になり、クラウド化したので、いまはあまり利用しない知識だ。
この時、覚えた技術で2010年ぐらいまで食い扶持を失うことはなかった。
まずは、これが技術との出会いだ。

そして、人との出会いになる。1995年の技術との出会いが、2000年対応での人との出会いにつながる。
プロジェクトによるのだが、2000年対応は2000年になる前には完了していなければならなかった。
2000年になってから2000年対応をしても無意味だった。
僕は97年の4月から2000年対応で東証プライム上場企業にERPを導入するプロジェクトに関わりはじめた。
この時、僕は世界的なSIコンサルティングファームに転職した。この時、役にたったのが1995年の技術との出会いだった。
僕はまだ25歳の若さながらレギュラー打者となった。
まだまだ、現場にはメインフレームのCOBOLerが多くオープン系システムの経験者が少なかった。
僕はダウンサイジングで育ったが、まだまだ、メインフレームと連携するシステムは多く、知識としてはメインフレームのシステムもわかっていたのもあった。
当時、このプロジェクトに参加していた多くはメインフレーム経験者と、そして金融機関から転身してきた人だ。
97年は山一、拓銀破綻など日本のバブル崩壊で日本の金融システムががたがたになった時だ。
そのため、金融機関からSIコンサルティングファームに転身してきた方が多かった。
彼ら・彼女らは優秀だった。現在でも活躍している。
この時、このSIコンサルティングファームで大規模なERPの導入ははじめてだった。そんなプロジェクトに集められたメンバーなので、くせものばかりの野武士の集団だった。
トップにも考えがあったのだろう。メインフレームで優秀な成績を残したメンバーだけではプロジェクトが成功しないと。
この時のメンバーとはいまでも付き合いがあり、SNSではひんぱんにやりとりをする。
集まり飲み会をやることもある。
同じ飯を食べ、同じ時の経験を共有したからだけではない。
くせものの野武士どおしでわかりあえることがあるからだろう。
これが人との出会いだ。

技術との出会いがあったから、人との出会いがあった。
キャリアというのは積み重ね。ビジネスを単発でやっていては出会いは生まれない。
ビジネスでの成功のキーファクターは同じ志の仲間と出会うこと

この記事が気に入ったらサポートをしてみませんか?