納得のいかない仕事をしていることくらい、技術者として辛いことは無いだろう。仕方なしにやっていますというのではモチベーションが揚がらないし仕事の精度も下がってしまうわけである。自分達の取り組んでいる仕事の意義や技術的なテーマについて自身で納得がいけば、ある意味どんなことにでも立ち向かっていけるのだと思う。納得のいかない仕事をしなければならない板ばさみで悲鳴や咆哮をあげている知己がいる。彼らは、それでも立ち向かっていっているようなので幾ばくかの意義を見出して仕事にまい進しているようだ。そんな意義も見つからないような仕事に自我を忘れて家族との生活を犠牲にしてまで出来るはずはないからだ。同じ仕事をするのでも視点を変えて取り組むだけで如何様にでも変えられるのではないかというのが私の経験には幾つかある。

技術屋というものの中には、仕事に対して取り組む算段や方法から先に考えてしまい、割と固定観念に固まった考え方をする人が多いように思う。幾つもの仕事の可能性を欠片からでも取り組んでみようというのも、会社としては容認されるべき姿なのではないか。まあ、そこまでの余裕がないのだといってしまえばお終いなのだが・・・。遊び心を糧に仕事をすることばかりではないにしても、四角四面に自分のテリトリーを固めてしまう必要はないと思うのである。開発などの過程で呆然とするような事態に遭遇したりすると自身がプラス思考で取り組めるのかどうかが鍵となってしまうのだろう。あまりにも仕様が未確定で次々と変わりながら、納期と性能との双方に課題があるという中で担当しているソフトウェア屋が蒸発してしまったという事件が起こった。

蒸発してしまったというのは、大袈裟なのだが要するに会社に来なくなってしまったのである。当時の組み込みソフトウェア開発業者の規模からいえば、開発依頼しているほうも受託するほうもスペアや予備の人材などが居ようはずもなかった。そして担当していたソフトウェア屋の二人とも連絡がつかなくなってしまったのである。この端末開発には、実は会社の威信が掛かっていたような実情があり、それでも外人部隊の二人のソフト技術者と仕様をまとめていた私の上司さらにハード担当のロジック技術者一名であり、私自身は外人部隊の二人の技術者が会社の開発環境の中で仕事が出来るように世話をしていたというのが実情であった。問題の仕事というのは、フルターンキーで無線電話機と電子交換機ならびに基地局装置などを開発納入するという一大プロジェクトなのであったのだが１００人ものソフトウェア技術者が担当して開発没頭している電子交換機と比較するのに無理はあるにしても温度差の激しい仕事であった。

ともあれ火中に飛び込まざるを得ない状況になり、困ったのは仕様の最終のやり取りが不明であったということだった。自らが起草して開発推進されているがゆえか、最新のシステム仕様が明確に仕様書に落ちていない箇所がおおく、端末と基地局の間の処理シーケンスについての定義としての信号説明などがあるものの固有機能として実装しなければならないというアイテムが記載されていないのである。愚痴をいっても始まらないので二人の技術者が書き残したソフトウェアソースリストと彼らが参照していたドキュメントを手がかりにすることにした。自身の心の拠り所となったのは、周囲や上司からのプレッシャーよりは、他人の書いたソースコードをどれほど理解しつつ改善が可能なのかという課題として捉えたことだった。そして落ち着いてソースコードを読みつつ理解できたのは個々の機能は満たそうという設計ではあったが、後述するような性能が満足する内容ではなかったということだった。言い換えれば要求仕様が不明確だったということなのだろう。

失敗するプロジェクトというものが定義分類されるとすれば、そうしたカテゴリーの仕事となっていた。開発威信が掛かっている仕事ゆえに、周囲の支援を得やすい状況ではあったのだが開発リソースとしての支援ではなくハードの仕様変更などの無理をお願いしたりするといった程度であった。なにせソフトが動作してシステムが稼動しないかぎり、歴史的にも専属ソフトハウスの会社を興してまで取り組んだ最初の仕事は、失敗してはならないプロジェクト分類なのであった。とはいえ、開発のプロセスが未成熟な初期マイコン搭載の組み込み機器開発ではメモリサイズの読みも処理能力の読みも実験などから割り出す経験値なども無かった時代だった。メモリ配置の設計なども高いからという理由で4ビット幅でRAMが実装されていたりする時代であったし、ようやくEPROMが一般化していく中で一つ五万円もするような高価な部品として4KBのEPROMが買ってあったりした時代背景である。仕事の仕方が定義されていないなかで縛られているいるルールはといえば、納期に物を開発納入するということが一番のルールだったかも知れない。

粛々と開発を進めてきたと思われる自動車電話機のソフトウェア開発に途中から参加して、難しいテーマを仕上げなければならないという割が合わない仕事ではあったが、ある意味で事業部の威信が掛かっている仕事のチームとして取り組んでいるということでモチベーションのキープは出来たと思う。それは誰もが中に立ち入らない世界でともかく仕上げるということのためにあらゆる考えられることに挑戦できた体験でもあった。性能追求という意味で最も限界まで辿り着いた感があった。なにせハードウェアの制限からいえば松葉杖をつきながら短距離走を走れといわんばかりの4ビットしかない外付けRAMとワーク領域とスタックだけでも不足してしまうような内蔵の8ビット幅のRAMの上で設計が進められてきた製品を突然倍の性能で動作させろというのは、技術者としてのチャレンジ以外の何者でもなかった。まともに走りきれないコードをチューニングするための方策は際限なく毎日いつもトライしてきた。当時話題となっていた惑星直列問題などになぞらえたタイマーの多重処理が起こらないような工夫などもしてきた。FIFOの考え方で構成しなおした割込み処理とデコーダ処理の関係など以降のリアルタイム設計の雛形としてもよい事例だった。

ハードウェアで唯一改善してもらったことといえば外付けのSRAM領域の上位ビットをゼロマスクする回路の追加であった。これにより16進で動作する小さなカウンター領域に少ないメモリと処理速度とで実現できるコストとのトレードオフであった。マゾと言われるのかもしれないが、困難に挑戦するということでますますアイデアは沸いてくるものである。機能や性能を満たすための実現方法からシステム仕様を値切ってもらったり変更してしまったこともあった。単なるタイマー値の変更などもあったが、次の点はとんでもないショックな事態だった。システムの呼処理として600bpsと1200bpsの差異はシステム性能からの差異はなく、アナログの無線機での伝送系統の群遅延特性の観点からみて後者のほうが信号伝送にとって有利であるということがシステム構成として必要な伝送特性補正回路を基地局において不要と出来るのかどうかということに過ぎなかった。アナログ回線の上で中継などを行っていくことで波形が崩れればシステムが成立しなくなってしまうから、波形伝送の維持は必須でありコストも重要なファクタだった。

ようやく伝送速度への対応について最善な性能チューニングを果たして出来あがったバージョンは、電話機本体が周辺機器である表示ユニットやハンドセットなどに供給するクロックにジッタが見られるほどの有様となっていた。ページングを受けると表示ユニットの輝度が揺らぐのである。にも関わらず呼び出し音が鳴動した、やったと快哉を自身にかけつつもフックアップすると、それは暴走してしまったのである。要するに全二重で1200bpsの送受信が出来ないということなのである。なにせまともなRAMも付けてもらえない端末設計をしてしまっていたお粗末なハード設計とシステム設計の力量不足が招いた結果であった。誤り訂正処理すらもワーク領域は4ビットRAMを使わざるを得ないのでこれ以上の性能改善には端末ハードの再設計を必要とすることが明白になった。性能面の追及はしたものの白旗を揚げて基地局システムの追加ユニットを手配してもらうことにしていただいた。システムを完遂することが第一の目標であることであり、今から端末のハードを改修してメモリを倍増して8ビット幅にするだけのコストをかけることよりは、端末のコストを抑えて基地局で初期コストのみで必要な機材コストを投入したほうが良いというトップ判断を取り付けたのである。

性能追求が終わったからといって、機能実装は終わっていなかったのである。入れなければならない機能はまだまだあり改善しなければならない機能もいくつも残っていた。といって最大の課題は、こんどはROMが足らないのである、幸いにして4ビットRAMですむ限りは1024ニブルもの空間があったのでRAMは十分あった。機能を実現するロジックには実は性能はあまり要らないのである。このことはJavaなどでも遅くても機能実装が果たせるということなどと同様のことである。性能を高めるための設計と、機能を網羅するための設計にはデザインルールを変えてよいということに他ならない。メモリ圧縮のためのアイデアはアセンブラソースで見る限りはコードの相関なども含めて可能な限りの改善を施していた当初の設計ルールのままでいえばおそらく個々のモジュールで出来る改善はやりつくしていた。テーブル構造だった当初の設計は、テーブルが拡張されていて仮想命令的な印象を持ち始めていた。いつもROM領域の残りは二バイトとか三バイトで入れたいロジックはまだまだ残っていた。毎日のように「後、何バイト残っているのか」と聞かれるのが日課となっていたし、それでも機能追加は少しずつ進んでいったのだが、アセンブラソースを見る限りは、これ以上アイデアが出なくなってしまった

限界の思いもあったが、気を取り直して機械語のダンプリストを片手にコーヒーを呑んでいると気になることに気が付いたのである、テーブル部分のコードが規則的に並んでいた部分なのだが規則的な事以外に気がついたのはデータの偏りだったそれもアドレスがおおいのでアドレスの偏りといえたのだが、どうにも偏っているデータの為に割かれている16ビットの情報自体が冗長であるというのが辿り着いた結論だった。たしかにアドレス空間は8kBしかないので上位の3ビットは余っているけなのだが、テーブル構造を解釈しているインタプリタ部分に手を加えれば上位ビットに意味を持たせて仮想命令としての完成度を上げて効率改善が出来そうだということだった。機械語の視点に立つことでCPUの気持ちからみて冗長な設計をしることができて最適化が果たせてそれまで16ビットのコードを割いていた命令をある意味で3ビットに圧縮することが出来たのでテーブルサイズから領域は、この後に気づいたテーブル自体のサブルーチン化という素直な発想などにつながり凡そ1kBちかくの改善が果たすことが出来た。

たかが8kBと現在では笑われそうな話ではあるが、こうした経験を通じて、マイコン処理の限界を極めた感覚が自分の意識には芽生えていた。たかが8kBに込められたデータの意味はソースコードに戦いの後が刻まれていて10000行におよぶものとなっていた。仮想命令で書かれていたこのコードの部分はマクロ命令で記述していたためにアセンブル時間にも事欠く事態となっていたので専用のマクロ命令を擬似命令として処理するようにアセンブラを拡張することにして、劇的なアセンブル時間の短縮も果たしていたちなみにこのときのアセンブラに指示するターゲットCPUの名称はプロジェクトとなっていた中近東の国名となっていた。納得できない状況で始まった仕事だったが、会社の威信をかけた仕事の中に向けて難しい技術に取り組んだという状況が自身のキャリアアップと会社にとっての良い結果となった。最終的には納得づくで取り組むことが出来た私にとっては平社員からの意識昇格に繋がった歴史的なことになった。

この経験から無線組み込み機器でのアプリケーション開発をしばらくインタプリタで実装することの追及というある意味で脱線めいた状況になったのは開発ラッシュの台頭となったパーソナル無線が立ち上がろうとしていたからでもあった。アナログ通信の時代のマイコン性能とのバランスは、現在のJava以上のバランスといえたのかもしれない。自己の深堀りを進めていくという仕事にうまく会社を利用したというのが私自身の感想なのだが、人によっては「そんな酷い仕事に向かってよく前向きに進めましたね」といわれるかもしれない。でも技術者として飯をくっていくからには、インプットとアウトプットがいつも同じ結果になることを期待されているのでは満足出来ないのではないかしらと私は思うのである。確かに全てを達成できたわけではないのだが、可能性に向かって前向きに取り組んでいくということはやりがいのある事なのだと私は理解しているのだが・・・。