私、渡辺和宣が、エンジニアリングを実現したビジネスアナリシス方法論GUTSY-4を開発するに至った、IT人生を振り返ってみます。一貫して、自動化とかエンジニアリング化に取り組んできた気がします。

プログラマ時代:1971-76年、ミニコンピュータのアセンブラでの開発を半自動化。

SE時代1:1980年前後、事務用コンピュータでの画面処理プログラムの自動生成。

③SE時代2:1985年頃、分散オンライン処理での各種ツールの開発。

 

  今回は、SE時代2です。1987-88年頃(約25年程前)、ある企業にオンライン処理を提案して、そのシステム構築を受注しました。私も管理職にはなりましたが、マネジメント専任では、将来つぶしが利かなくなると、一貫して「プレイイングマネジャー」を通し、このシステム開発にも係りました。

  当時は、今と異なって、通信回線が想像できないほど遅く、また回線料金も馬鹿高い時代。そこで、多くの出先を持つ企業には、そこにインテリジェント端末を設置し、日中は端末で業務を処理し、一日が終わると本社のホストコンピュータにデータを送信し、ホストではすべての出先からのデータを受信してバッチ処理をするというスタイルが一般的でした。

1.インテリジェント端末の欠点

  この方式は、ほとんどの処理をインテリジェント端末側で行うため、通信回線料金は安いものの、インテリジェント端末側に以下の欠点を痛感していました。

①独自の言語のプログラムを開発しなければならない

  ホストコンピュータとインテリジェント端末とでは、当然、OSやプログラム言語が異なっていました。したがって、出先の日報など、ホストと端末とで、似たようなプログラムを重複開発せねばなりません。開発に倍以上の工数がかかるのと、保守も2重の作業が必要になってしまう。うんざりです。

②端末側のプログラムの入れ替えのため、遠く離れた出先に行かなければならない

  人間が作ったプログラムですから、当然、誤りもあります。もちろん、緊急でない場合、メール便でプログラムを送ります。出先が30カ所を超えた時に、緊急でプログラムを入れ替える必要ができた場合には、何人もの人を手配して出先に向かわせねばなりませんでした。システム開発作業よりこちらの方が大変。

③端末側のプログラムバグによるファイル復旧のため、離れた出先に行かなければならない

  プログラムの修正は大した時間ではありません。しかし、それによって、おかしくなったファイルを復旧せねばなりません。プログラムには様々な機能を持っているので、これが特定の出先において発生します。東京、横浜から静岡、浜松、名古屋まで出先があり、単なるプログラム入れ替えではないため、特定のSEしかこの作業ができません。

 2.オンラインシステムでの工夫、挑戦

  オンラインリアルタイム処理に移行した際に、ホストや通信回線のダウン時には、インテリジェント端末だけでも処理できるような方式としました。したがって、前述の3つの欠点がそのまま残っている。又も、私の中の虫が動き始めました。そこで、以下の対策を考え、自分の本来の仕事+アルファとして自ら担当。

①帳票プログラムはなるべく端末側には持たせない

  プログラムを開発するからバグや入れ替えが発生する訳で、ならばホスト側だけに持たせればいい。そこで、ホストのスプールファイルから帳票ファイルを読み込んで、圧縮して端末側に送信し、端末側ではこれを解凍してそのまま印刷すれば様々な種類の帳票を作成できる。スプールファイルの処理のためには、汎用機のアセンブラ言語で開発しました。端末側のプログラム開発の受注は減りましたが(笑)。

②端末側プログラムの自動入れ替え

  更新すべき端末プログラムをホストにセットしておけば、毎朝の端末起動時にこれから自動受信して、自動的にプログラムの入れ替えができる。緊急時には、端末側から起動してもらえばよい。圧縮形式の送受信システムは、帳票のと共通利用。これによって、プログラム入れ替えのために出先に行くことは全くなくなった。せっかく、親しくなった出先の責任者も増えたのに、全く行けなくなって、さびしい(笑)。

③端末側ファイルの調査・修正

  やはりプログラムバグは残ります。このせいで、おかしくなった端末側ファイルをどう調査して修正するか? このため、ホスト側と端末側の両方にプログラムを立ち上げて、それらが会話する。まず、ホスト側からの読込みコマンドを端末側で受信して、該当するファイルとレコードを読み込んで、ホスト側に送信。ホスト側では、これを画面上に16進表示し、いろいろ調査する。そして、これを修正して書込みコマンドと共に端末側に送信すれば、端末側はそのレコードを上書きしたり、追加したりする。この仕組みのおかげで、いくらプログラムバグがあっても安心していられる(笑)。

  これらのシステム開発は、日中は管理職の仕事もあるので、多くは夜間での仕事です。自分の仕事では、「10%ルール」として、チャレンジャブルな目標を設定して、自分の時間の10%をこれに費やした。もちろん、無給です。顧客企業もこの挑戦によるメリットがあるため、コンピュータ室長が、夜間に入って仕事をする私のために、合いカギをくれました。古き、よき時代でした!

  この後、1990年代に入ると、もうシステム開発する時代ではないと、パッケージ、ERPに移って行きました。それから、SCMやコンサルティング、そしてビジネスアナリシスのエンジニアリング化として現在に至っている。

 

カテゴリ