最近の携帯業界のメーカーの多くが出荷端末のルールとして、ソースコードの検査ツールを通して合格することを必要条件としているらしい。端末ノコードレビュアーとしてツールが活躍していることになるのかもしれないのだが、果たしてツールが指摘した内容が、実はコード設計者の意図どおりの結果であるとしたら、彼らの追求は行き詰まってしまうのである。購入して利用するこうしたツールを使いこなしていく上では指摘した内容についての理解が求められるわけである。まあ、これを接点にしてソースコードを理解しようといった趣には良い教材提供ということになるかもしれない。大規模にわたるソースコードによるシステム動作にあっては数多いフィーチャー同士のコンフリクトなども考えられるのでツールが手助けになることもあるのは事実なのだが。

仕事をしていく上で前例がないという事態にも遭遇することもあるだろう、対処すべきルールが無いのである。ルールが無い場合には、最も近いルールを意訳あるいは拡大解釈として前向きに処するのが一つの処方箋といえる。事なかれ主義というような気風では、技術屋としての看板を下ろしてしまったようなものであるからだ。私が遭遇した時代においては、幾つかの事例があげられるので参考になるかも知れないのだ。デバッガーというものが製品として8ビットマイコンの登場にあわせて国産品で出てきたのは、79年のころだっただろうか、マイコンというものを使いこなしていく上でデバッガを自作していくのは当時としては普通だった。製品化されるということで自作の労が軽くなるというのが当時の位置付けでもあった。アセンブラベースで8kbほどのソフトウェアを開発していくというスタイルには開発ツールからのデータチェーンが準備される市販ツールの意義は大いにあったといえる。何しろモニタROMを製品に組み込まなくてもよいことになるからだ。

ルールが無い事態として突入したのは、自分達の意図する開発環境とツールの開発環境とが合わないことに端を発していた、今で言うところの貸し出しメモリが機能としてなかったからだ。私が最初に取り組んだ仕事は、ソフトウェアの開発環境としてこのデバッガの外部端子の仕様から、フラットケーブルで接続するという仕様で動作させるというプライベートメモリーサブシステムを製品デバッガに合わせて設計製作することであった。クロックジェネレータ、小容量の内蔵ＲＡＭ代替部(128バイト)、さらにはEPROM代替部となる貸し出しメモリ(8キロバイト)といったところであった、マイコンのシステムクロックが1M程の時代であり、のんびりとしたものではあったがとりあえず新入社員の仕事として回路設計とP板の設計依頼そして検図、部品手配、製作といったことをこなしていた。適当なケースを探してきて２台ほど組み立てたような気がする。試作ラインも無い時代なので自分で半田付けで作ろうとしたところ、庶務の社員にさせるように上司から指導をうけた。半田付けをしたこともない庶務の社員にさせた結果は高くつき結局半田付けの指導教官とあいなってしまったようだ。

自分達の道具作りというものは、試作の範疇のルールとして取り組めばよいことなのだろうからここまでは良かったのだが、一通り出来上がり使い始めてから問題として表面化したのはEPROMのエミュレーションをするという貸し出しメモリ機構について書き込みプロテクションとして設けたロック付のトグルスイッチが使いにくいということだった。当時のデバッグ風景といえば、ソースファイルを編集するパンチカードをパンチして磁気テープのソースを前世代から新世代のテープに転写しながらの編集作業を行う。出来る編集内容は簡単明瞭で挿入と削除の二つだけである。そして出来上がった新世代の磁気テープを使ってアセンブル作業を行いアセンブルリストを作成して、さらに出来上がったオブジェクトファイルをリンクして最終形態としてインテルフォーマットやＳフォーマットの紙テープに出力するのである。この紙テープを巻取り機で巻取り、開発したデバッガシステムに接続した紙テープリーダに繋いでターゲットメモリにローディングするのである。このサイクルが済む頃には毎日午後三時頃になってしまっていた。

デバッグ風景はといえば、アセンブルリストにマーカーペンで書き込みつつ、１６進電卓でバイアス計算してブレークポイントを求めつつ更には、パッチで書き換えて空き領域に飛ばしながら修正をしつつのデバッグということである。書き換えの都度トグルスイッチを切り替えるのは不便極まりなかった。ユーザーの立場から言えば、デバッガを使って操作しているときにだけ自動的にプロテクションが解除される仕組みが欲しかったのである。上司を説得して測定器メーカーから回路図を入手してもらい、中を読み解いて内部の状態信号を理解して当該信号を引き出すことに成功したのである。今では当たり前の話であるが、当時としては画期的なことであったかもしれない。パテントの申請でもしておけばよかったかもしれない。まあ回路図と言っても物理的に7400シリーズが並んでいるような時代なので読み解くのは容易な時代であった。その後この測定器メーカーは開発支援ツールからは撤退してしまったようであるが、ソフトウェア開発というパンドラの箱に取り組むのは大変な時代だったのだろう。

当時開発環境を自分達で整えてきたのは、マイコン初期利用メーカーは皆やってきたことだろうと理解している。私の先輩は8080と6800そしてZ80と三世代のクロスアセンブラーの開発を進めてきていた。最初に作ったのは絶対番地出力の8080用のアセンブラーであり、パナファコムのミニコンの上で動作するようになっていた。ソフトハウスとの協力開発で彼+二名のソフトハウスの技術者とで半年掛けて作成していた。開発ツールを作るというルールは存在していなかったので会社としての予算確保などもきっと色々なことがあったに違いないと思う。逆に軌道にのり、会社が戦略的に取り組むマイコンとしての6800版の開発ではモジュール開発の効率などを考えてリロケータブルアセンブラーの仕様にして作りこんだりしてきた。技術が進歩していく中でのこうした仕事をルール化するのは難しいといえるので、どんどん変わっていくことに対応していけるようにするということ位をルール化するに留めておいたほうがよさそうだ。実は第三世代のZ80にあっては、開発はしたものの周辺の開発ツールの充実やら、大規模開発へのマシン能力などの問題などルール化されて皆が納得して進めた割には使われないものとなっていたのである。

端末開発が進み、動作の解析などに腐心するなかでアセンブラベースでの机上デバッグ+ブレークポイントダンプだけでは複雑な動作の検証というものに必要な機能が不足してきた。そんな頃アドバンテストが投入したマイコンアナライザはタイミングとステートの相互関係を解析するという機能で現象とマイコン動作の関係からデバッグ解析を進めていくという目的に照らしてリアルタイムトレースが必要だということになってきた。自分の作り出したマイコンデバッガ支援システムの終焉は一年余りで訪れることになった。そうした双方の技術を重ねて持ち込んだ完成度の高い機器が米国メーカーから次々と発表されていき、特別組織として集っていたソフトウェア課というセクションの役目も終えて大規模プロジェクトとして専用システムハウスを会社として興すほどの勢いの中に発展的解消を遂げていった。ソフトウェア課という組織の中で開発ツールなどへの対応もしていたという歴史は、結構いけていた組織ではなかったかと思う。ルールから外れた組織を生み出して、仕事をさせてきたことが新たな仕事の扉を開けてきたのかもしれない。なによりも、その組織の中で仕事をしてきた自分達は、取り組むテーマに意識を高く持つことが出来、以降のそれぞれの各開発部門に離散しつつも、ルールに根ざしても必要に応じて新たに変えていくということを理解できたことが大きな成果だったといえるようだ。