メインフレームとの出合い

キャリア

» 2009/11/30

　さて、今回からしばらく、わたしとメインフレームの出合いについて、当時感じた驚愕を存分に交えながら、お伝えしていきます。

　若きメインフレーマーには参考になればと思うし、ベテランの方々にも昔をちょこっと思い出していただけるのではないでしょうか。

　それでは、しばらくの間お付き合いください。

■「メインフレームって単語くらいは知ってるんじゃないかな」

　こちらは今でもよく覚えているセリフです。

　研修を無事に卒業し、初めてのプロジェクト先が決まった頃、

　「サトマモさんは、どれくらいメインフレームのスキルがあるんですか？」

という、プロジェクト先のアドバイザーである先輩の質問に、当時の所属長がこのように答えていました……。かく言うわたしも、隣で頷いていたわけですが……。

　まずそもそも、驚くべきことかもしれませんが、わたしの入社した2006年の新人研修には、System z（IBMのメインフレームシステムの製品名です。IBMにはもう1種類のホストシステムがあるので区別のため、以降はSystem zと記載します）について、実際に触れるようなコースは、一切含まれていませんでした。

　かろうじて名前を知っていたのは、製品に関するコースがあり、一通りのハードウェアとソフトウェアの特徴について学ぶ機会があったからです。

　しかし、所詮は簡単な営業資料を読んだだけであり、System zに関するわたしの知識は、その時点で以下のようなものでした。

• とにかく信頼性が高い（Zeroダウンのzなので）
• でも、値段も高い（詳しくはいくらか分からない）
• 最新テクノロジーの塊

　……ええ、本当に適当なイメージしかなく、今書いていて恥ずかしいです。

　とにもかくにも、JavaでWebアプリを作ったり、ソリューション提案の研修ばかりやっていた新人が、ぽ～んっとSystem zの世界に放り込まれたのです。

　昨今の弊社新人には、こういうケースの人がけっこうかもしれないので、現場のベテランの方々はご容赦ください……。

■調べても調べても分からない単語を調べ続ける日々

　プロジェクトアサイン当初は、インフラの基本設計が終わり、ちょうど詳細設計の途中でした。データセンターを新たに構築するプロジェクトだったため、結構大がかりです。まず手始めに、と言わんばかりに、300ページあまりの基本設計書をドスンと渡されました。

　基本設計書というのは、その名の通り、プロジェクトのマスタースケジュールだとか、基本的な設計コンセプト、移行計画、技術要素の検討内容等について述べているものです。

　読み始めたは良いものの、当たり前ですが、System zに関連した用語がすっかり分かりません。どうしようもないので、とりあえず、分からない単語は片っ端からノートへメモすることにしました。

　インターネット世代の若者であるわたしは、ご明察の通り、拾った単語をGoogle検索へ突っ込みました。世界のGoogleやWikipediaのおかげで、たいていの分からないこともとりあえず調べられる世の中ですよね。

　しかしながら。

　System zに関する情報って、インターネットにはあまり落ちてないんです。もちろん、探すとたまに見つかるんですが、期待しているような分かりやすい、ドンピシャリな資料はほとんど出てこないのが現状です。

　お客様先にいて、インターネットくらいが唯一の情報源だったわたしにとっては、死活問題でした。

　そもそも、System zのマニュアルなどはすべてインターネットに公開されているので、それを読めばよいのですが、単語も分からない新人に、いきなりマニュアルはいささかレベルが高かったのも事実です。

　結局、会社に戻った際に、自習用の資料などを集めてもっていきましたが、結局、単語を調べたたり資料を読んでみたところで、机上の空論というか、全然イメージができず、理解するにはほど遠い状態で、1カ月が過ぎていきました。

　社内にはクラスルームの研修もあるので、行っても良かったのですが、アドバイザーの先輩曰く、

　「研修行くよりも現場の方が勉強になると思うし、行かなくていいんじゃない？」

　とのこと。なので、構築作業が始まるまでは詳細設計書のレビューに参加したり、資料の手直しを手伝う日々を過ごしました。

　今のわたしなら、研修に行って全体像を掴んでから、作業へ参加するところですが、ホストインフラの現場って、こういう根性論のような現場主義があったりするのも、また事実ですね。当然、このような方法が重要な面もあります。個人的には、新人の間に現場であれこれトライできて、良い経験だったと思っています。

■データセンターにてSystem z 構築開始

　年が明けた2007年。データセンターへSystem zが導入され、構築作業が開始されました。

　導入セットアップが終わった日、データセンターでの初電源オンをしたことを、未だに昨日のことのように覚えています。

　System zは常時稼働していることがほとんどですし、本当に電源までオフにすることは滅多にありません。そう考えると貴重な電源オンの瞬間でした。

　さて、実際の構築作業とはいっても、さすがに何して良いか分からない戦力外なため、最初は端末用パソコンのセットアップがお仕事です。

　これはこれで、マウスが使えないとか、いろいろと細かいトラブルがあったのですが、本編とは関係ないので割愛しましょう……。

　構築作業は進み、ついにSystem zの初回起動です。z用語では、システムを起動することをIPL（Initial Program Loading）と呼びます。システムを起動するための殻である区画を設定していくのですが、この辺の作業は、もうひたすら眺めているわけです。ひたすらメモを取りつつ。

　システムに触れていると、正確にメモを取ることが大事なことが良くあります。特に、データセンターではセキュリティ要件で、外部とのネットワークも遮断されていたり、そもそもエラーメッセージも保存できない状況があるからです。

　また、書くことで自分の勉強にもなります。ちょっと後で勉強してから見直してみると、あの事象はこういうことだったのか…と合点がいくことも良くあります。

　初回起動後もカスタマイズをしていく過程で、手順をメモしたり、エラーが発生してはエラーメッセージをメモしたり、ひたすらメモっていました。メモしたことは帰ってから、資料やマニュアルと突き合わせて、その都度「なるほど」と理解していきました。

　いわゆる、「何が分からないのかが分からない」という強烈な体験をした3カ月間でした。

■初めてのトラブル発生！

　構築作業も少しずつ進んで2ヶ月ほど経った頃。開発環境の構築という、新たな作業が始まりました。

　インフラ基盤の作業項目としては、開発環境を整備するというのは重要なことで、実施するテストに対して、必要なシステム資源（CPU能力、メモリ、ディスクなど）を見積って、準備していきます。今回の構築に関しては、そこまで詳細な見積もりはせずに、既存の開発環境をコピーして作成するというものでした。

　相変わらず、話を聞いても訳が分からないところは多々ありつつも、雰囲気を見ていると、うまくいきそうだなぁと楽観視していたのです。

　立ち上げ初日。データセンターで作ってきた手順通り作業を進めていきます。コピーしたシステムデータを使ってIPL。起動のログがコンソールという端末用パソコンへ出力されます。流れるのが早くて全部は読めないんですけどね。

　そのまま、無事に起動するかと思いきや……。真っ赤なエラーメッセージが出てきました！！

　構築チームのメンバー全員がビックリして、マニュアルをひっくり返し、コマンドを打ち込むのですが、いっこうにエラーは解消されず……。仕方なくシステムを停止します。ちなみに、わたしはひたすら実施したコマンドやメッセージをメモです。議事録同様、メモ取りも新人の仕事ですね。

　原因が分からず、みんなで頭を悩ませました。開発環境構築のスケジュールもあるため、失敗しましたとただ帰るわけにもいきません。

　プロジェクトのメンバーにも相談しながら、試行錯誤して、気づけばとっくに深夜になっていました。

　まだ開発環境だったので、お客様の業務には全く影響がなかったことは幸いだったのですが、大きなトラブルはこれが初めてということもあり、昨日のことのように鮮明に覚えています。

　これが噂に聞く、システムエンジニアの仕事なんだな、と感じた日でもあります。

■最初の3カ月を終えて……

　データセンターで四苦八苦した3カ月では、自分のスキル不足を痛感すると同時に、メインフレームの取っつきにくさも理解した時期だったと思います。

　見たことのない機械、見たことのない端末、見たことのない機能……。パソコンが当たり前だからこそ、余計に違うことが難しく感じてしまうのかもしれません。コンピューター＝パソコンの世界で育ったわたしたちには、その異質さは受け入れにくい巨大な存在であるとすら思うわけです。

　それでも、「コンピューターは何故動くのか」ということと、トコトン向き合えるメインフレームの世界は、エンジニアとして非常に有意義な勉強場所でもあり、ぜひ一度は触れてみて欲しい世界だと感じています。

　このときの体験から、現在は社内コミュニティで、若手System z担当の技術者がメインフレームのスキルを効率よく身につけていくためには、どんな工夫が必要か、ということを検討する活動に参加しています。少しでも取っつきにくさを少なくして、メインフレームを楽しいと感じてもらいたいんです。経験をその後にどう活かすのか、ということも大切なことですよね。

　メインフレームの技術は今もどんどん進化しており、System zではLinuxまで稼働することができます。お客様のシステムに対する要件が厳しくなればなるほど、信頼性に優れたメインフレームの出番はあり、当分はなくならないでしょう。

　そう考えると、メインフレームと今のエンジニアがどのように接していくべきか、昔を大事にしながらも、今はどうするべきか？ という温故知新の視点が必要だろう……というのが、このコラムのタイトルに込めた意味でした。

　特に締まりもなく、長々と書き綴ってしまいましたが、いかがだったでしょうか？

　メインフレーム担当でない方も、新人の頃は色々と苦労されたと思います。もし、このコラムで思い出すことなどがあれば、ぜひコメントください✏