半導体を作っていたお客様は工場の移転を決意されました。それまで作っていた半導体のラインを一新し最先端の工場として稼働させ、世界におけるトップ集団に位置することを狙われていました。22-23年前くらいの話です。その頃のシステムは、クライアント・サーバーという言葉がで始めた頃だったと思います。主流はまだメインフレームを使ったシステムでした。といっても、メインフレーム全盛時代の終焉の頃だと思います。そして半導体産業は日本のメーカーが世界でトップ集団を構成していた時代でした。

　新規の工場ということで、土地を整地するところから始まり、仮の建物ができ、設備を入れるための本格的なビルが建設されました。半導体の製造は、ウェハーと呼ばれる円盤のようなものを作って半導体メモリー、いわゆる集積回路をウェハー上に加工する前工程と加工された回路を一つずつ切り離す作業の後工程に大きく分類されます。私が担当したのは、前工程の工場でした。前工程は製造ラインに埃などが入るのを防止するために厳しい入室管理がなされます。当然我々は入れません。製造ラインを担当する人は入り口で衣服を脱ぎ、白い服に着替え、消毒をし帽子を被り二重のエアカーテンをくぐって塵や埃を除去してからでないと製造している部屋には入れないほどです。そんな製造ラインの業務を部品の調達や製造計画などの業務を通して支援するシステムを構築するのが我々の役割でした。

　新規の工場ということもあり、システムを最初から構築できるということは過去に縛られず、当時のテクノロジーでできうることに挑戦しやすい環境でした。そこで最初の挑戦は、メインフレームでのシステム運用を目指しながら、オペレーターは最初から配置しないことでした。お客様のIT子会社から2名の運用SEの方が常駐することにはなっていましたがマシン室内での運用は最初から計画されていませんでした。

　メインフレームを利用したシステムで無人での運用という形態は経験したことがありません。しかも、何かあった場合の代替機があるわけでもなくコンピュータは1台のみでした。また、当時のメインフレームの運用では必ずといっていいほどテープのオペレーションが存在していました。これがあると無人化は不可能となるので、まずはシステム上からテープの処理を無くす挑戦から始まりました。もちろん、運用SEの方が在籍している昼間には利用可能なので、夜間のバッチ処理からテープ処理を一掃するということです。これは、新しく設計するということが功を奏しました。(現在では、テープ処理の仮想化ということでディスクをテープのように利用することが可能になっているので技術的にはテープ処理における無人化は実現可能となっています。)

　従来は以前からのシステムでバックアップやつなぎの処理としてテープが必須になっているケースが多くありました。ただ、問題はプリンターによる印刷でした。これは現場に配布する資料を明け方までに印刷する必要があるので止めることはできません。しかし、この処理をなんとかしないと夜間無人運転は実現できません。ならば、無人で印刷することに挑戦しようということになり、議論を重ねました。そうです。無人のマシン室で無人で印刷をはじめ、自動的に終了させる方法が必要だったわけです。

　検討したのは、昼間に印刷しても間に合う分と、朝一番で印刷されていないと業務に支障をきたす分に分離することです。そして、後者の印刷量を調査し、事前セットする紙の量で賄えるかを計算し、その範囲で出力できる分だけを出力することで業務が開始できるようにシステム設計したのです。しかし、無人で印刷というのはかなりハイリスクです。もしかすると紙が詰まって燃え出す可能性もゼロとは言えないわけです。そこで、夜間定期的に見回ってくれる守衛さんと連携することにしました。もし、マシン室の中に置いてあるプリンターなどが異常を起こすとパトランプが点滅するようにしました。そして夜間警備の方が赤いパトランプが点滅して異常を確認した場合は、主電源を切る処理を依頼したのです。まさしくチームオペレーションです。しかも最小人数です。本番運用後、1度だけパトランプが点滅したことがありましたが、警備員の方がIT担当へ電話をしてくれたため、幸いにも電源オフは免れたことを思い出します。

　この時に利用したプリンターは、実は紙をストックしておく部分とプリンター本体の間に隙間が数センチできる仕様でした。その隙間は横から見ると紙が機械の間を飛んでいるように見えます。最初はそこに空調の風が当たり、紙にたわみができて上手く印刷できないケースが発生していましたが、機械の置き場所の微調整や空調の調整をして、直接風が当たらなくなったことで安定するようになりました。とてもアナログですね。

　夜の問題に対する対応は完全ではないながらも計画できたので、次はメインのオンライン・システムそのものの構成方法を検討しました。

　オンラインは、深夜の3時間程を計画的に自動停止したあとバックアップを取得しバッチ処理を実行、その後自動的に再稼働させなければなりません。構成する考え方の原点は、もしオンライン区画に問題が生じたら、待機している区画が代わってサービスを継続する構成を作るということでした。採用していたオンラインシステムは、CICS(Customer Information Control System : IBMが提供しているオンラインで稼働するための管理システム)であり、当時の私の専門領域でした。そこで、提案した構成は、端末を管理する区画、データベースと連携する区画、アプリケーション(トランザクション)を稼働させる区画の3区画を相互に連携して稼働させ、さらに、それぞれに待機区画を設け、合計6区画で稼働する構成を採用しました。待機区画は普段は表に表れていませんが、相対する区画がなんらかの理由で停止した場合、ユーザーに気づかれずに自分自身が稼働区画にとって代わり業務継続を可能にするためのものです。

　端末を管理する区画が異常を検知して待機システムに置き換わると、仕様上、TCPIP接続の端末のみが初期メニューに戻ってしまうということになってしまうのですが、処理は継続させることができるのでお客様も容認してくださいました。本来であれば、OSレベルも待機区画を作れば良かったのですが、製造業のお客様としてはそこまで投資しても効果の回収は困難ということでオンラインシステムのみの対応で運用を開始しました。つまり筐体はひつとでその中で本番システムが稼働し、その本番システムの中で通常稼働しているシステムと待機しているシステムを常駐させたわけです。もし、筐体に異常が発生すれば全て影響を受けますが、お客様は、そこまでのリスクを考えるよりコンピュータのハードの信頼性を考慮し、予防保守を確実に実施して異常発生を未然に防ぐための投資の方に重きを置くという舵をきられたわけです。この考えを尊重し、システムも稼働開始することができました。

　サービスインした後は順調に稼働し、停止することはありませんでしたが、一度だけお客様から連絡が入りました。「誰も気づかないうちに待機区画が立ち上がってサービスが継続されていました」という連絡を受けた時は、思わず、拳を握り締め「よしっ」と思った記憶があります。お客様も気づかないうちに待機システムに切り替わったということは業務への影響がほぼないと言っていい状態で切り替わり、そのまま業務続行できていたということです。

　今でこそ自動化を目指した検討が多く進んでいますが、30年近く前でも同様のことは検討していたということですね。特にメインフレームはSEの工夫による自動化が多くあり、それをサポートする機能もメインフレームには多く搭載されていました。お客様担当SEによる創意工夫が提案という形を通して実現しやすい時代だったのかもしれません。そして、我々SEも自分のスキルを存分に発揮できる環境が整っていた時代だったように思います。新しいスキルを身につけると、それがお客様業務に適用することでもっといいシステムにすることはできないかということを四六時中考えていた時代でした。お客様とともに我々SEも大きく成長することができていたと思います。

他のSE経験記事は以下のマガジンに入っています。よければ覗いてみてください。