トラブル対応

システム・エンジニアとなることを期待されて入社した会社に属していた頃、COBOLというコンピューター言語でプログラムを組めるようになり、世界を動かしている産業のシステムの概要がまあこんなものだろうとわかってくると、システム構築のためにプロジェクトに加わる。
そして、流通・製造・金融・品質管理等の専門知識を得ると、すぐにではないけれどプロジェクトの大きさを問わず、プロジェクトを率いる立場に籍を置く。

しかし、僕の場合、この道を歩んでいかなかった特殊な例でもある。
いくつかのプロジェクトの元、COBOLというコンピューター言語でプログラムを組んだことは確かだけれど、僕は入社した頃から先輩のシステム・エンジニアに連れられて、大型汎用機でシステムを動かすためのプログラムの不具合を修正する作業を行っていた。

PTF(ピー・ティー・エフ/Program Temporary Fix)と言って、ソフトウェアの個々の問題に対処する「個別PTF」や「個別PTF」を集めて1つにまとめた「グループPTF」やある時点までのPTFを蓄積した「累積PTF」などがあって、これは大きな磁気テープで供給された。
定期的にPTFを適用すればいいかといえばそうでもなく、そのPTFを適用することによって生じる問題点を事前に調べだし、「個別PTF」「グループPTF」「累積PTF」のどれを適用するか決めなければならなかった。

そして、現地に行って、業務終了時から、システムのバックアップを行い、夜間や休日にPTFを適用し、不具合がなくなるか、既に導入したシステムの他の部分に影響がないか、チェックする。
僕は主にそんな作業を任された。

もちろん、事前にチェックしても、PTF適用後の再起動時の瞬間は鼓動は早くなり、息苦しいほどの緊張を持ってディスプレイに流れていくメッセージに「エラー」がないかどうか見つめる。

再起動しない場合もある。システムに何らかの問題が生じる場合もある。
そんなときは原因を追求すべく、ログを出力し、バックアップからシステムを復元し、ログを持ち帰り、メーカーに問い合わせる。
大型汎用機に携わっていた頃、僕のボスには大変お世話になった。

大阪に転勤後、そんなこんなで、僕はパーソナル・コンピューターが導入されても、OSの不具合や、ハードディスクの障害やネットワークのトラブル対応に強いエンジニアとなる訳だけれど、これは会社にとって何の利益にもならない孤独な作業となる。大型汎用機の時代とは異なる。

今、このblogを不運にも読んでるみんなさん自身にも問いかけて欲しいことなのだけれど、ユーザーの立場からするとトラブル対応にお金なんて払いたくないわけで、僕は会社にとって何の利益も生み出さない。
しかしながら、ユーザーとしてはトラブル対応を迅速に行ってくれなければ、19分後の作業だってできないし、その日の作業だって、日付が変わるまでに終えることができない。

現場で対応し、組織の中枢から遠く離れた部分で作業してきた僕のような人たちは多く存在する。
そして多くの場合、そんな僕らよりはるかに地位が上のボスたちは現場に足を運んだりしない。
彼らはアルコールのねっとりとした時間に取り込まれるか、ゴルフという競技を優雅に参加するか、のんびりとタバコをくわえてテレビを観たり、豪華なクルマを走らせ、僕の見知らぬ異性とベッドを共にしていたりする。

“フィナティーはかぶりを振った。「医者はおれをまんなかへひきもどそうとするだろう。ところがこっちは落っこちさえしなけりゃ、できるだけ縁に近くでがんばっていたいんだ。縁にいると、まんなかでは見えないいろんなものが見える」うなずいて、「夢にも思わないようなものが見える – 縁にいる人間が、それを最初に見るのさ(カート・ヴォネガット・ジュニア「プレイヤー・ピアノ」、翻訳:浅倉久志、1952年、早川書房)」”

トラブルが解決すると、ユーザーは僕にいつも優しく接してくれた。そんな僕は”まんなかでは見えないいろんなものが見え”た。

* blog内、全て敬称略です。