IT業界がいつのまにか羨望になってる件
かつては残業が多く、賃金も安く、理不尽な仕事が多く、結果うつ病も多かったりして、新3K職場なんて言われていましたが、いつのまにかIT業界が就職先として有力（羨望は言い過ぎ）な分野になってる件。
まあ、不況の中でも（だからこそ）IT需要はなくなりませんし、リモートワークとなればインフラエンジニアも必要になります。そんな中、「なぜブラックの代名詞だったITが羨望の業界となったかについて、少々昔話などを。
2000年代初頭までのIT事情
アテクシの就職したのは2002年、まだインターネットバブルの残照在りし頃で、IT業界が必死に人をかき集めていた頃でした。ほーむぺーじ（）とジャバ（スクリプト）とPerl（掲示板ソースの改変程度）とFTP、サーバースクリプトを少々知っているというだけで、即戦力対応でした。アテクシは一応工学部ですが、他の同期は大半文系でした。
で、入った企業というのが、日立の孫請けを主事業とするIT会社でした。当時は汎用機（要するにスパコン）をメインに据え、そこに物理専用線やVPNを通してPC端末でアクセスするシステムが色々な企業で使われていました。今では銀行・金融系と官公庁ぐらいにしか残ってないんじゃないかいう気がしますが、当時は大きめの会社の勘定系とか基幹業務はだいたいこれでした。個人向けPCの性能が（今と比べたら）ウンコだったからね。
何千万円、何億円とする汎用機を売る＝動くOSも自社で作って売る＝汎用機にアクセスする端末も売る＝汎用機で動くプログラム（だいたいCOBOL）開発も売るというビジネスモデルなので、プログラム開発は概ね汎用機販売会社の系列会社が元請けし、そこから子請け孫請けひ孫請けと仕事を配っていました。
当時の開発手法はウォーターフォールモデルが主流でした（本当はそのころ既にIT工学では否定されていた）。これはざっくり言うと「基本設計」→「詳細設計」→「画面設計」→「開発」→「単体テスト」→「結合テスト」→「連携テスト」という流れを上から下まで流し、それぞれのフェーズごとに納期を割り、進めていく感じです。
ところが、PCサーバーの性能が向上したことで、汎用機のビジネスモデルが取って代わられるようになってきました。インターネットと汎用機の相性が悪かったこともあり、UnixやWindowsが動くPCにリレーショナルデータベースとアプリケーションサーバーを配置して、インターネットで各地からアクセスする仕組み（オープン系）が流行ってきました。これなら高い汎用機や抱き合わせの開発・PCなどを買わずに済み、（セキュリティの問題は出るものの）専用線を引かなくて済みます。当時は信頼できる（というか、企業が採用してくれる）DBがマイクロソフトのSQLServerとOracleのOracleDatabaseぐらいでしたが、数千万の汎用機と比べれば桁が一つ二つ違うので、中小企業でも気軽にITシステムを採用できます。
いわゆる「ITバブル」というのは単に2000年問題とwebサイトブームだけではなく（それもかなりボロかったようですが）、それまで大手汎用機ベンダーにロックされていたIT開発が、上記理由で開放・小型化され、能力さえあれば誰でも作れる時代になったために、中小独立系ベンダーが増えていったという側面が大きいと思います。
その結果なにが起きたかと言えば、「汎用機開発要員のオープン系転向」です。これがその頃のITを腐らせた原因だと思っています。
方法論に対応できなかった悲劇
（以下の説明は当時のシステムに基づく私の理解になります。誤っている可能性と、現在は異なる仕組みとなっている可能性が常にあります。）
汎用機開発要員達は、経験で言えば長いため、当然上長の立場となります。必然的に、開発のルール、システムの選定、設計、意思決定は、彼らがすることになります。）
しかし、汎用機開発とオープン系では以下の点で決定的に異なります。
・データ記憶が固定長ファイルかリレーショナルデータベースか
・オブジェクト指向か否か
まずデータ記憶ですが、磁気テープベースだったせいか、当時の汎用機のデータ記憶はほぼ固定長データを「ファイル」に保存するものでした。固定長データとは、予め項目ごとにバイト数が定められているもので以下のような形でファイル定義がされます。
ＮＮＮＮＮＮＮＮＮＮ9999999X999999
氏 Ｉ 元生月日
名 Ｄ 号年 内容は「氏名（全角10文字）」「会員ID（数字7桁）」「生年元号（半角1文字）」「生年（数字2桁）」「月（数字2桁）」「日（数字2桁）」を管理するためのものです。数値に桁があるのは、10進数の桁数です。COBOLはByteではなく、物理的な（？）10進数でデータを管理します。DateTime形などないので、生年月日の管理は年月日で別れて管理されます。年齢計算も大変そうです。西暦で管理している場合もありますが、当時はファイルの容量制限があってByte数をケチるためだったり、処理速度の問題があったので、下二桁のみで管理している場合がありました。（それが2000年問題を引き起こしたわけですが。）
このファイル定義に応じて、COBOL側でもそれをまるごと受ける形の構造体を用意します。ファイル定義を変更すると、データベースの項目を受けるCOBOL側の項目もすべて変更になるので、気軽にデータベースの更新はできませんでした。
また、私の経験した限りでは、ファイルの少なからずはデータの正規化がされておらず、そこを「繰り返し項目」という形でサブの構造体を用意してデータを受け止める仕組みになっていました。（これは開発ごとに違うんでしょうか？）
一方、リレーショナルデータベースではこうなります。
id (integer) name varchar(10) birthday(date)
こちらは日付型があるので、まともな開発部署なら元号管理などはしません。元号表示する際はふつう、「日付をどのような形で表示するか」という処理で行います。（どうしても元号単位で素早く集計したいときのみ、元号のフィールドを追加することもあるかもしれませんが。）
データは原則として正規化され、必要な項目をSQLでJOINして取得します。DB側の実装に関係なく、実装の要求に応じたデータ構造を持ち、それをこねくりまわすことになります。
シーケンシャルデータファイルとリレーショナルデータベースの違いを説明するには文字数が足りないので省略しますが、上記のようなファイル定義を念頭にデータ構造を作ってきた人が、シームレスにリレーショナルデータベースの設計をするのは無理があるのは想像に難くありません。
そして、プログラムのクラス設計です。オープン系のJavaや当時出たてのC#はオブジェクト指向言語であり、比較的強いシェアを持っていたVisualBasicも、オブジェクト指向言語ではないものの、そのような設計は可能でした。
「オブジェクト指向」も簡単に説明するのは難しいですが、「データを保持する部分と、データをどう表示/集計/加工する実装を別物として管理する」ぐらいに思ってください。
上記のように汎用機COBOLはファイル設計ありきで開発されていました。一方でオブジェクト指向では、データベースのデータ型はある程度どうでもよく、不要なデータは受け取らないことも可能だし、何ならデータの型が決まらなくても表示/集計/加工の設計だけ先に実装してしまうことも可能です。
ここで更に問題となるのが、前述のウォーターフォールモデルでした。オープン系やオブジェクト指向よくを知らないお偉いさんがたが、汎用機COBOLの方法論で「基本設計（ハードウエア構成）」「詳細設計（機能・DB設計）」をしてしまいます。
基本設計ぐらいは元請けも参加しますし、ざっくりしたところなので力業でなんとか対応できるのですが、詳細設計でのそれは致命的です。当然、以降の課程で問題が発覚し、詳細設計をしなおすことになります。特にDBの設計は絶望的で、リレーショナルデータベースなのに固定長フィールドの仕様書を出してきたので、上司に怒鳴り散らして若手でDBを切り直したことさえあります。
もっと問題となるのがwebアプリの開発です。今ならwebはHTMLとCSSで画面をデザインすることは常識となっていると思いますが、当時のCOBOLはキャラクターベースのCUIでしたから、いわゆる「神EXCEL」のようなフォーマットで画面設計を提出してきます。（というか、「神EXCEL」自体が汎用機文化だと思います。）一方で当時のHTMLでの画面設計ではTableぐらいでしか横幅の設定が出来ず（IE4.0、5.0、5.5、6.0が混在していた時代です。）頭を抱えたりもしました。
しかし、設計フェーズのスケジュールは既に消化されているので、手戻りとなると無駄な手待ち期間が増え、締め切りはタイトになります。まずDB設計がうんこ、データの取り扱いがうんこ、機能と画面の切りわけ方がうんこ、差し戻すと時間がかかる上に「プロジェクトを遅らせる原因」呼ばわりされて究極にうんこ。そりゃブラック労働にもなります。この頃COBOLerへの憎悪が育まれました。
開発会社側も上述の通り納期が遅れることを見越して人員を用意しているフシもあり、おそらくそういう契約なのでしょう、大規模プロジェクトには開発開始の日付から大量に単価の安い新人がアサインされていました。で、実際にある程度固まってきてからベテランやプロの派遣（その頃の派遣IT要員はプロフェッショナルしかいませんでした）が投入されるという。まあ、新人くん達も新人なりにやってもらうことはあるんですが（ほぼ雑務）、あの頃の「就職に困ったらIT業界に行け」というのはたぶんそういうカラクリです。カカシでもいるだけで人月にカウントされますからね。
かくして当該プロジェクトは炎上、労働環境は悪化し、嫌気がさして離職者続出となりました。その会社では別の現場のCOBOLも似たようなものでした。おそらく似たような経験をした人がいっぱいいたからだと思いますが、きょうびのITエンジニアのCOBOLへの拒絶反応は、こういう経験が礎になっているんじゃないでしょうか。
もちろんすべてのCOBOLerがダメだったわけではなく、独学自習してリレーショナルデータベースやオブジェクト指向開発に対応していた人もいっぱいいます。が、そういう実務スキルの高い人ほど実務に回され、ダメな人ほど管理側になってひっかき回していたのが私の所属していた会社です。40歳前後の皆さんのところはどうだったでしょうか？
＊
幸いなことに、いまIT業界で偉い人になっている世代は、オブジェクト指向ネイティブだと思うので、少なくともJavaとC#が生き残っているしばらくの間は上記のような問題はないでしょう。（ScalaやHaskellが覇権を取るまでは。リレーショナルデータベースに対してもNoSQLとか出てきていますが、今のところスケーリング以外のメリットあるのかな……←老害？）
企業が設備投資をしないせいでITエンジニアの単価が削られている面もあるかもしれませんが、現状では開発工程もスパイラルアプローチやプロトタイピングが取り入れられ、テストの方法論も確立され、00年代初頭のような理不尽なブラック（目の前に氷山があるとわかり切ってるのに突っ込むタイプのブラック）はかなり減少しているでしょう。というか、してない職場はヤバいよ。
本質論としては、これはCOBOLや汎用機の話ではなく、エンジニアの新技術・方法論への対応の話だと思っています。アテクシもアンテナは鈍い方なんですが、少なくとも5年単位、できれば3年単位ぐらいで、現在のトレンド言語や方法論を確認しておく必要があるように思います。それが厳しいなら若い人に仕事を任せて怒られ役に徹しましょう。いつパラダイムシフトが来るか（あるいはもう来ていて自分が乗り遅れているか）わかりませんからね。
この記事が気に入ったらサポートをしてみませんか？