話は少しさかのぼりますが、筆者は社会に出て20年近くが経ちます。
社会人になったころは「バブル期」といわれ、経済が右肩上がりに成長していた時代です。今では信じられないかもしれませんが、就職活動で企業へ訪問すれば、交通費、食事代、場合によってはその会社の定める出張費まで出ることがあり、アルバイトをすることに疑問さえ感じる時代でした。そんな中、筆者はある金融系の企業に入社し、その後システム部門へ転属、それから何度となく転職を重ねておりますが、基本IT関連のキャリアを歩んでいます。
最初に転職を決意したときはすでに就職氷河期でした。転職活動はそれなり大変でしたが、仕事をする上でどうしても「規模」と「責任感」が両立するシステムに携わりたいと思っていました。当時はネットを使って情報収集というには早すぎる時代であり、なかなか多くの業種を見ることはできなかったのですが、結局のところ金融関連のIT部門に就職いたしました。当時は転職のエージェント等も一般化していなかった時代ですので、自分が好きな企業に片っ端から飛び込んでいろいろなお話を聞いて、志望企業をしぼることができたのは良かったのではないかと思います（もちろんたくさんのお断りもいただきました）。
まず、金融系でも（信託、企業向け含む）銀行系か、生損保系かという業種選択から入りました。転職をする際、何となく募集要項から待遇が良い方を…と考えがちですが、当時の筆者はシステムがどのように使われているのか非常に興味があり、たとえば、リアルな店舗とATM等の数は銀行系の方が莫大ですが、商品（流動性預金など）は生損保の方が複雑な気がしました。
また、実際のデータに関して、銀行系は口座番号、取引金額等数値が主ですが、生損保の場合は、氏名や住所等漢字データも多く、また、実際の証券発行もありますし、その証券に印字するデータは、日本で使われる文字（場合によっては2バイト以上）は全てサポートされていなければならないというストイックさに惚れ込み、実際、生保系企業にお世話になりました。
金融系システムの規模とは？
今でこそサーバの台数やトラフィック、ユーザ数等で規模を表す傾向もありますが、当時、このような業界でも、口座（契約数）、取扱高、場合によっては支店数等でインフラの規模を表していたかもしれません。この辺りは今も昔もといったところではありますが、筆者が感じる一番の違いは、金融等、経済、ライフラインに近い業種の大規模システムというのは、行政からの指導、ガイドラインの遵守等が求められたりします。「FISC準拠」のための案件等も多くありました。
また、最近ではソーシャル、ゲーム業界等でも「DR（ディザスタリカバリ）」などという言葉を聞きますが、実際には言葉にきちんとした定義があったり（その定義が実際の災害対策に有効かどうかは別議論ですが）そもそもプライマリセンタが自社所有センタでない時点で成り立たないという意見もありました。
数歩先を行っていたホストコンピュータ
さて、そのような中、おそらく今でも現役で稼働しているホストコンピュータですが、IA（PC）サーバの方が安いし速いのではないか？ というお話も聞きます。でも本当にそうなのでしょうか？
このような書き方をすると異論があるかも知れませんが、実際、筆者がホストコンピュータに触れて感動をおぼえたシステムが今では当たり前だったり、実現にはもう少し時間がかかったりしそうというものがあります。そういった意味で、研究、発展のための先攻投資というわけではありませんが、ホストコンピュータの技術的な点についてあげてみたいと思います。
当たり前になったRAID技術
ディスク装置はHDD（ハードディスク）と言う方が一般的でしょうか？ ホストコンピュータの世界ではDASD（ダスド:Direct Access Storage Deviceというほうが一般的でしょうか？ 筆者はその辺りに壁を作ることはせず、まぁ、どちらもデータを格納するハードウェアという認識です。ホストコンピュータの技術とは異なりますが、筆者が大規模金融システムのインフラエンジニアであっても、DASDが故障した際、自分達で保守パーツから交換……、なんてことはできず、あくまでも故障内容を精査して、メーカCEへ連絡するのが主業務でした。ただし、ボリューム名を聞いて、その用途から適切な判断をする必要もあります。
たとえば深夜バッチ中、DASDの故障でオペレータから緊急コールがかかってきます。そのボリュームがRAID対応でなければ、そのボリュームと、場合によっては「裏」のボリュームが被害に遭うので、対象バッチは全て停止、オンラインに影響があればアプリケーション部門担当とメーカCEへの連絡をお願いし、空いているボリュームを割り当て、バックアップ（テープなど）からリストアするJOBを起動、リストア後、停止したJOBまでのデータ（差分）を埋めるべく臨時で手動バッチを形成し、データを再作成し、通常バッチをリランする必要があります。
逆にRAIDの場合は、メーカCEへの連絡のみで、ご存知の通り、リビルドが構成されれば再び冗長構成が取れます。RAID技術ができたことだけでも大変便利になったと思っていましたが、それが今ではPC等でも気軽に利用することができるようになり、本当に良い世の中になったと思います。
当たり前になった仮想化技術
同時期にIAサーバがあったかどうか、それで同様の技術があったかどうかはわからないのですが、筆者がIBMのホストコンピュータで技術者として感動した技術の一つがPR/SM（Processor Resource/System Manager）の技術でした。PR/SMで分割した区画をLPERなどと呼びます。実際、作業のひとつとしてホストコンピュータの管理マシンで、OS/2上で稼働するHMCからターゲットのホストコンピュータにアクセスし、その中のCPUやメモリの割合をGUIで操作したときの感動を今でも覚えています。
とりあえず新システム用にOS、ミドルウェアの定義をするために作る、現状システムにPTFを当てるテストを行うために、区画を作成し、ターゲットシステムと同様の構成を作成し、テストするなどといったことが気軽にできるようになりました（とはいってもテスト関連の場合はリソースが非常に小さく、5mipsとかOS起動すら非常に苦しい中でやりくりしていた思い出があります）。
そのような技術は他にもあったかも知れませんが、時を経て今では、IAサーバ等でも気軽にでき、クラウド等と行った言葉へつながっていっているのではないでしょうか？
本当に感動したSysplex
Sysplexとは、複数のCECをCFがロードバランスを取り、データの入出力はESCON（今ではFICONでしょうか？）を経由して利用することができる構成で、高機能なホストコンピュータを並列に稼働させることにより、安定と性能を最大限に引き出すことができるシステムです。（大雑把な記述ですが）IA（PC）サーバでも物理的に分かれた2台以上のサーバを1台に見せる技術と言うのはあまり聞きません。この技術は理解するのにも時間がかかりましたが、コンセプトとか思想等を知り、さらに自社のシステムに適用する理由が理解できたとき、本当に自社のシステムに誇りを持てました。
この技術は今日のオープン系IA（PC）サーバに求められる主な（業務的）要件、性能から完全には採用される必要はないのかも知れません。その理由は、オープン系のシステムはスケール（たとえばアプリケーションサーバを横に並べて）対応できてしまうからです。金融関連の（勘定系含む）主要業務系システムがIA（PC）サーバで対応し難い点というのはこの辺りにあると考えます。
金融系システムがIA（PC）サーバに対応し難い理由（の一部）
少しだけ冒頭でも触れましたが、日本で利用される全ての文字を保持し続けるために、IA（PC）サーバだけでは少々不安な点があります。また、これはIA（PC）サーバと言うべきかプロトコルというべきか、その他かもというところもありますが、障害時における対応の方法を挙げるとわかりやすいかも知れません。
たとえば、ソーシャルゲームや携帯電話（通信・コンテンツ）向けのシステムが10時から5分間障害で停止した場合、復旧後、ほとんどはそのまま何事もなかったようにサービスが稼働します。 一部、重要課金まわりなどであったり、ユーザからの問い合わせによりログ等から調査し、個別で対応して何とかなると思います。
それに対して、たとえば銀行の場合、たびたびニュース等で報道されているので聞き覚えがあるかも知れませんが、未処理件数が○万件等と行ったことを耳にするかと思います。これは障害が起こった瞬間（断面）の処理を極力覚える仕組みをもっているため、再開後、未処理のトランザクションを消化することができるのです。
ユーザやセッション数こそソーシャルゲームや携帯電話向けコンテンツ等には叶わないこともありますが、そのほとんどが参照系の処理であるソーシャルゲーム等に比べ、金融、経済に関するシステムは更新や連携処理が多く、重要な処理はそのステータスを逐一記録したり、オープン系では考えられないほどのセッションの管理を行ったりし、障害が起こった際にユーザへ再処理を促したり、重複を避けるべく指示を行ったりと、世論（経済など）に影響を与えるほどの障害であった場合、その監督庁に対して被害の度合いを件数、処理の内容から回復までの時間を報告することもできるようになっている設計がほとんどだと思います。
“金融系”インフラエンジニアの仕事って？
前回、今回と記載させていただいた通り、その業種の内容（金融でもいろいろとあります）をきちんと理解し、適切なハードウェアを選択し、その特性を理解したシステム設計ができ、オペレータ、アプリケーション部門、場合よっては上長などを通じて同業他社や監督省庁が求める答えをきちんとアシストできること。 この辺りが金融系の事業会社のエンジニアとして働く条件になるかと思います。
実際の作業に関しても、（まだまだありますが）前回、今回の連載の内容でインフラの設計をし、利用用途ポリシーが決まり、この後は、OS本体周りの設計として、筆者は少々古い時代ですのでOS/390などから、利用用途に応じたミドルウェアの基本設計（通信はVTAM、TCP/IP、USSは必要か？ DBはDB2、バッチではなくオンラインならばCICSかIMSか？ TSOとJCLチェック系のサードベンダ製がいるか……？など）を行い、インストレーションを行っていくことで構築が完了します。
また、新規構築ばかりではなく、統合の計画であったり、定期または臨時で行われるPTF対応、サードベンダ系ではライセンス管理として、定期的にCPUIDなどからライセンスを作成して適用する等と行った作業を行います。また、比較的軽い作業に関しては土日や3連休等を利用して、大掛かりな作業に関しては年末年始やGWなどの長期休暇を利用して作業を行うのも金融系エンジニアの特色かも知れません。
いかがでしたでしょうか？ 今回の内容は現役金融系（でホストコンピュータを利用する）エンジニアの方々からするとまだまだ書き足りない部分もあるかと思います。ただ、読者の大部分はIA（PC）サーバを利用したオープン系のインフラエンジニアが多いのでしょうか？ そんな方々でももしかしたら過去にメーカやSIなどの立場で関わった方もいるかも知れません。私個人的には、どちらもその質が下がるとそのままサービスに影響する責任感あふれる職種だと思っています。もし、少しでも皆様の知らない部分が表現できていたらと思います。
