ソフトウェア開発を生業とするに至ったのは、母校で学んだ電子計算機との出会いだったか。ミニコンとの遭遇で始まった新たな世界は、オイルショックによる不況真っ只中での気まぐれな大企業での採用との出会いからだった。なにしろ不況下で採用したところで受け入れる先の事業部が無いというような時代である。大企業の威信にかけても継続は力なりを誇示する為に採用した当時の新入社員はミニマム級な採用記録となっていた。導入研修をして、販売研修、工場実習を行えば配属にいたるというサイクルを回せないでいた時代である。当時のJIS表記の変更が契機になったかどうかは別として時間潰しとは言わないまでもミニマム級の人員でのみ達成しうる挑戦をするのは大企業の中での採用部門としての気まぐれだったのだろうか。

時間潰しとしての提案は、まったく異なる実習先工場での第二次工場実習であり、製図・機械工作実習といった流れであり気がつけば次の年度の新入社員が入社するに至り採用部としては、山下飛びと揶揄されるような新たな経営陣の刷新も受けての配属作業にいたるようだった。まさか会社に入ってから高専で学んだような製図実習や図学実習あるいは機械工作の実習をするなどという事態を想像することはなかった。おそらく、そんな気まぐれを体験したこと事態が会社として封印されているのではないだろうか。ようやっと配属されるに至った事業部から、まさか次のステップが用意されているとは当時の新人としては、またまた想像の枠を超えていた。入社した翌年の五月に、あるコンピュータ会社の翌年の新人研修の中に投入されていたのである。

無論、新人研修に続いて二年間の出向研修という名前の実務が待ち構えていた。学校でFORTRANとアセンブラを学んだのも束の間、ミニコンピュータのシステムエンジニアとして、出向先のコンピュータメーカーの名刺を持ち、その客先の自動車メーカーに駐在して工場制御システムの更新プロジェクトに投入されていたのである。まさにOJTで既存システムのコードを確認しながら、ミニコンサポート部隊とコンタクトをとりつつ新たな機能実装に向けて新デバイスのドライバーやらミドルウェアを組み込みための作業を経験ある上司の下に現場で行うはめになった。といってもミニコンと小型コンピュータの二系統のソフトウェア更新で、開発は高卒の新人と私の二人で上司がシステムをまとめていた。

私はといえば、ミニコンのコンソールパネルでのデバッグ位しか知らない状況で、突然リアルタイムシステムの中のモジュール組み込みを行うのにはギャップがあった。開発環境としても、当時の組み込みミニコンの実情は、ある意味で現在のマイコン以下の部分もあったかも知れない。少なくとも救いは、現行のシステムが稼動していること・導入するドライバーミドルウェアは開発部門から提供を受ける事・自分としてはシステムとしてのインテグレーションの為のコード開発とその稼動確認を行うことであった。といってもビルドの方法は新橋のオフィスでミニコンを時間予約してシステムテープを手配して、所要のカードパンチを依頼してワークテープを右から左に転写しつつの編集とアセンブル、システム編集といった流れが必要だということを学びつつも現場である北関東のユーザー先の間を往復することになった。

出向の身の上ではいたし方ないものの、深夜にしかマシン時間が取れないといった作業環境が、当時の製造メーカーの人事環境からみて理解されることはなく、昼からの勤務などといった柔軟な体系もなく、朝からの仕事を続けて深夜の作業を行い、徹夜明けを迎える。柔軟な勤務の人たちとの仕事の流れと一緒に引き込まれてしまうのは致し方なかった。出向元の会社の人事規定から考えると、徹夜明けは帰宅することになっているので、そのまま作業をしているという事態は残業として計算するしかなかったようだ。幸いにして出向者は組合の対象とはならなかったようだ。ありえない残業時間として一ヶ月に180時間といったスコアを記録していたのもこの頃である。毎月の給与が賞与のような状況が続いた。ある時に振り込み額が減っていたので驚いたが気がつけば、それこそが賞与だった。

そんな悲惨な状況でもマインドキープが出来たのは、帰る先の会社があり、また同様の状況で他にも二名の仲間が同期として出向させられていたからでもある。三人とも似たような状況ではあったものの、お金の使い方はまちまちだった。全部呑んでしまったというメンバーもいるし、ローン返済に費やしたというのもいる。私は偏った趣味のレコードを買い込んだり出向先からの派遣先の寮に2セット目のオーディオをそろえたりといった具合で前向きな自己投資になったのは人的ネットワークの構築を目的に呑んでしまった仲間だったのかも知れない。北関東と新橋の間をビルドするだけの目的で往復するのはコンピュータに振り回されている感じがして何か納得が出来なかった。開発環境の改善は、当時からの課題でもあった。

当時のミニコン自体は、大型コンピュータのオマケとしての制御コントローラとしての位置づけだったりもしていたので、周囲を見渡しても、その新橋のコンピュータ会社での状況は似たり寄ったりだった。大型コンピュータのサービスパッケージの中にミニコンシリーズのシミュレータというパッケージがあり、よく資料を読むと外部機器としてホスト側のテープをサポートしているという記述があり、そのパッケージを使ってみようということを思いついた。といってもそんなツールを仕事のビルド環境として使おうと考えた輩は、そのコンピュータ会社には居なかったようで、開発元に問い合わせをしても動くかどうか分からないといわれたりもしていた。自分で開発したソフトをお客様にマニュアルまで提供しておきながら動かないかも知れないと言われたのは不思議な気が当時はしていたものである。

実際問題、ユーザー先の工場が夜中に終業した後にシステムを入れ替えて、この環境を整えてシミュレータを稼動させてシステム編集やらアセンブルなどを行ってみたりしたものの本来カクッカクッスーッといった感じで磁気テープが処理されるものが時々思い出したようにテープが動き出すといった状況で朝まで行っても終わることは無かった。こうしたトライアルが功をそうしてか見かねた上司が、顧客先の別の新工場に導入された少し規模の大きなミニコンピュータシステムの使用を口を利いてもらい北関東のお客様の工場間バスで移動してマシンを日中も使える環境になったのはありがたいことだった。まさか、将来シミュレータをまた使い込む羽目になるとは当時は思っていなかった。一晩かけても終わらない仕事は、リアルタイムシステムで稼動しながらのマシンのバッチ仕事とはいえ30分も掛からずにビルドが出来るような状況だった。

当時のミニコンも大型もプログラムの修正はパッチ(ALT)といった方法でモジュール単位のパッチを行うのが普通だった。そしてその修正はモジュールのIDをベースにして相対アドレスで指定したコードを修正するといったものだった。システム開発では、必ず新人にシステムテーブルのALTソフトを作らせるなどという時代であり当時は一般的な流儀だったらしい。考えてみれば、モジュール結合が、モジュールIDで行われている現実は最近のBREWなどのクラスＩＤで結合させること同じようなものでもある。限られたメモリー空間で多彩なモジュールを稼動させて実現させるためにデマンドベースで一時領域に読み出して実行させるといった機能もあり、最近の携帯電話で実現しようとしているものと状況が似たようなものであると感じたりするのである。

今、この原稿をポートランド行きの飛行機の中から書いているのだが、今回の仕事の中に駆け込みで入ってきた事態の一つに、最近流行りとなってきたエアー書き換えといった機能の実現での顧客サポートがある。これは、既に昨年から始まっている機能ではあるもののメーカーではない立場ではあまり立ち入ることも無かった経緯がある。お客様の困っている状況を確認するとマイクロカーネルの時代の中で実現したい内容をマッピングさせることに苦労しているようでサンディエゴ側のメンバーでは何が行われているのか良く理解できないといった部分を繋いで相互理解と問題解決の二つを進めることが新たな仕事として舞い込んでしまったのである。昔々のミニコンの時代には、モジュール単位でのパッチが出来たことから考えると果たして現在のモジュール結合方式をもってかえって複雑な状況を作りこんでいるのではないかと思ったりもするのである。

現代の解決策としては複数のセクションに分割させることで、エアー書き換えといった機能で対象となる差分のブロックを最小化することで現実的なサイズの追加メモリだけで機能実現を果たそうと工夫しているのであるらしい。既にこうした構成での実現を果たしていくためには、モジュールアドレスへの直接分岐が出来ないのは自明の理であり、ミニコンの時代のモジュール間結合方法であったトランスファベクターといったモジュールエントリーリストをモジュールの先頭に持った構造を作られているようだった。こうした話を持ち出すのははばかられるような人たちなので私自身は、彼らの工夫としての実装として話を感心しながら聞き流すだけであるのだが・・・。そして彼らいわく、目指す姿は、すべてモジュールは動的結合にすることを目指すのが正しい姿ですと言い切られてしまい、これはいみじくもQuad社が目指している新たなソフトウェア構造にも重なるのである。

何が本質で、何が問題で、何が分かっていないのかを互いに確認しあいながら現在としての解決策を導いていこうとしているのだが、答えは過去に既に出ているような気がしてならないのである。ミニコン時代の実装を再度現代の流れの中で実現しているのに過ぎないのではないかという気がしてならないのである。デジャブとはいわないまでも、果たしてこの30年あまりの間には進歩もあったのだろうが、何か失ってしまった部分も多いのではないかと思わせる回想であった。昔々のタイムカードで管理されていた二つの会社の狭間で多量な残業を強いられていた状況は、タイムソーンの狭間で同様な状況を作りこまれているのは皮肉ではあるものの、あいにくと年俸制の中での仕事として、より自身として効率的な作業を求めるのはかつての環境の悪い状況下での開発に取り組んでシミュレータを利用したりしてきた流れとも被っている。時差を越えての埋めるツールの架け橋は、VNCでのリモートデバッグも一つの方法であるかも知れないが、やはりタイムリーに現場で行うようにするのがベストであり、明日にはそうしたお客様も機中の人として来られる筈である。

そう問題は早く解決したいのはお互い様なのである。そして出来た時間は、家族や恋人と過ごすために使いたいのである・・・。