１９８０年中頃に私が仕事で関わった、マイクロコンピュータ応用システムには、１つの不思議なプログラムがありました。決して表舞台に現れない、まさに黒子のようなコンピュータ・プログラムでしたが、その応用システムの新規開発期間においてはなくてはならないコンピュータ・プログラムでした。私が要求・システム設計したのではありませんが、仕事でそのプロジェクトに参加を命じられた私は、その『擬似ホストテストプログラム』という耳慣れないプログラムをその詳細設計から、コーディング、プログラム動作テストまでを、そのプロジェクトリーダーの指導のもとで、一人で担当させてもらいました。
その頃までの私はというと、会社では、主にＰＬ／ＭやＣというプログラミング言語でＯＡ機器のマイクロコンピュータ応用システムの一端を担うプログラムを開発していました。一方、家では、会社の仕事とは関係の無い、ＢＡＳＩＣのプログラムを作って一人で遊んでいました。そのうち、８ビットコンピュータのアセンブリ言語にも手を出して、８６系や６８系のマシン語プログラムを組むことを趣味でやっていました。それまでは、ＢＡＳＩＣもマシン語も、会社の仕事では使う機会がなかったので、家に帰ると、勝手に一人でそういうことを趣味としてやっていたのです。
その『擬似ホストテストプログラム』の仕事も、プロジェクトに参加した当初は、全体のシステム設計をおおまかに理解して、プロジェクト・リーダーの人と一緒に、フローチャートを書きながら詳細設計を１ヶ月ほどやっていました。その間に、ＳＣＳＩ（スカジー）というインターフェースを学んで、『高速データ伝送通信カプラ』というハードウェアとどういう手順でデータをやりとりするのかを新たに学んでいました。また、その通信データのやりとりを、パソコン側で制御あるいは処理するための詳細を、フローチャートを使って詰めていく作業を続けていました。
実は、その『高速データ伝送通信カプラ』は、私の勤めていた会社のハードウェア開発部によって作られた新規のハードウェアでした。専用回線と大型ホストコンピュータとの間に接続されて、専用回線にはイーサネット（EtherNet）でデータ通信し、大型ホストコンピュータとはスカジー（ＳＣＳＩ）インターフェースでつながってデータをやり取りするというものでした。大手電機メーカーＯ社を通じての、某地方銀行からの発注で、本店の大型ホストコンピュータと支店の大型ホストコンピュータを専用回線で結んで、オンライン処理を実現するためのシステムだ、と私は聞いていました。すなわち、本店のホストコンピュータ＋通信カプラ＋専用回線＋通信カプラ＋支店のホストコンピュータと一直線につながって、本店と支店のオンライン処理をスムーズに行うコンピュータシステムでした。プログラム詳細設計がある程度進んでから、私は、その通信カプラの実物を見たことがありますが、８０８６の１６ビットマイクロチップが１つの本体に２つ装着されていました。いわゆるデュアルＣＰＵで、１つの通信カプラで送受信を同時に高速で行えるしくみになっていました。私はそのハードウェアが直接動くためのファームウェア担当ではありませんでしたから、その中身を詳しくは知りません。しかし、おそらく、同じプログラムソフト（この場合は、ファームウェア）が、それぞれのＣＰＵで動作しているしくみだったようです。
しかし、このクライアント側（某地方銀行の担当者）からは、大変大きなシステム要求仕様がありました。それは何かと申しますと、専用回線は手配できるものの、現時点で開発中の、本店と支店の大型ホストコンピュータ・システム完成前に、発注した『通信カプラ』の開発を先行して完了させるというものでした。つまり、オンラインシステムを可能とする（完成された）新規の通信システムを、大型ホストコンピュータが出来上がる前に欲しいという、ある意味、無茶な要求だったようです。確かに、クライアント側からすれば、大型コンピュータの開発が終わってから、オンラインシステムの開発を始めると、全体の開発期間が延びてしまいます。少なくとも、両者の開発を同時に進行していかないと、システム全体の開発スケジュールを効率よく進めることはできないということでした。
そこで、ＳＥ（セールスエンジニアではなくてシステムエンジニア）の立場にあった、私のプロジェクトリーダーになるその人が考えて、そして、クライアントに提案したのではないか、と私は以下のように想像しています。それは、開発中の大型ホストコンピュータの代わりに動く『にせもの』のプログラム（擬似プログラム）を作る、という提案でした。つまり、そのプログラムでいろいろなパターンをテストして、新規開発の『通信カプラ』システム動作上のハードとソフトの両面の不具合（バグ）を可能な限りつぶして、より完成されたシステムを提供する、という提案でした。それが発注側に了承されて、偶然そのタイミングで社内で手が空いていた私に、そのプロジェクトリーダーの人の声がかかったのではないか、と思いました。
その時に私が担当した『擬似ホストテストプログラム』とは、具体的にどのようなコンピュータシステムに構成されて利用されたのかと申しますと、次の通りでした。クライアント側で開発中の大型ホストコンピュータの代わりに配置されたのは、Ｏ社自社製のパソコンでした。私の担当したプログラムは、そのパソコンのＭＳ－ＤＯＳ上で動作しました。また、パソコン＋通信カプラ＋イーサネット回線＋通信カプラ＋パソコンというハードウェアの接続が組まれて、そのシステムテストを行っていました。
その実機テストに使われたパソコンは、Ｉｆ－８００と世間には公表されていたオールインワン・パソコンでした。１６ビットＣＰＵ（８０２８６）で動作し、キーボードとＣＲＴディスプレイとプリンタと８インチフロッピーディスク装置がパソコン本体で一体化している贅沢な業務用パソコンで、１台が１２０万円以上しました。それだけ周辺機器が本体にくっついていると、当時のＮ社の同じく１６ビットＣＰＵ（８０２８６）で動作していたＰＣ－９８０１などと比べて、少し処理動作が遅く感じられました。だから、私を含むプログラマたちの間では、そのパソコンのことを、Ｉｆ－８００じゃなくてウソ８００だと、しばしば冗談で言っていました。
しかし、そのオールインワン・パソコンは、ＭＳ－ＤＯＳが使えて、プログラム開発用のソフトウェアも充実していて、しかも拡張ボードのソケットも便利に付いていて、本当は屈指の国産マシンだったのです。その証拠に、そのマシンのＭＳ－ＤＯＳ上で、ＳＣＳＩを制御するプログラム部分を８０８６アセンブラで、また、キーボードとディスプレイで通信テストデータを扱えるようにするプログラム部分をＭＳ－ＢＡＳＩＣコンパイラで、それぞれマシン語にできました。さらに、それらをくっつけて（リンクして）、一つになったプログラムをそのまま動作実行させるところまでを、一貫した作業としてできてしまいました。つまり、そのパソコンたった１台で、プログラム開発用マシンと、（『通信カプラ』とＳＣＳＩで接続された）実機とを兼ねていました。インターネットが普及していたり、パソコン間通信が当たり前かつ簡単に出来る現在とは違って、当時は、このような場合でも、ソフトウェア開発用のマシンと、高スペックなシステムで実際に使われるマシンとは、別個であることが多かったのです。そんなご時世に、開発用にも、実機用にも使える万能パソコンというのは、珍しかったと言えましょう。やはり、Ｉｆ－８００の本当の姿は、ウソ８００などではありませんでした。
さて、いわゆるＭＭＩ（マン・マシン・インターフェース）の部分をＭＳ－ＢＡＳＩＣ（マイクロソフト・ベーシック）言語で組んで、新規に開発された『通信カプラ』をＳＣＳＩ規格インターフェイスで制御する部分を８０８６の１６ビットＣＰＵのアセンブリ言語で組んで、その両者を同一のマシン語にして一つにしたのが、『擬似ホストテストプログラム』でした。フローチャートでプログラムの詳細を検討し、明らかにしていくうちに、どの部分をＭＳ－ＢＡＳＩＣにして、どの部分を８０８６アセンブリ言語で書くのかが決まりました。もっとも、ｔｈｉｎｋ＆ｍａｋｅをいわゆる売り物にしている現在の一般的なプログラム開発の手法からしたならば、こんなやり方はしないのかもしれません。作ったフローチャートを検討しながら、コンピュータの処理の一つ一つを机上でデバッグして（つまり、バグ不具合を取り除いて）いくなどというやり方は、現在のＩＴ技術では時代遅れとすら見られてしまうのが明らかでしょう。
しかしながら、そうしたプログラマの地道な努力を、できれば笑ってほしくはないものです。そんな現代社会において、時々、世間に広く公開されたアプリが誤動作したり、巨大コンピュータシステムがダウンしたり、端末ＡＴＭが停止してしまうような事故が起こるたびに、私には思うところがあります。設計時やテスト時に発見されなかったバグ不具合がたった一つあったとしても、それは確実に起こります。とすれば、机上デバッグや実機テストの段階で一つでも多くのバグ不具合が見つかっていれば、コンピュータシステムに対する不安や不満や疑念を、世の人々から減らすことができます。逆に、そのシステムに対する信頼度が増して、自ずと安心して利用したくなるのが人の情というものです。結局、プログラムを組む上で一番大切なのは、規制や強制を厳格な管理の下に行えば正解にたどり着く、というものではないと私は思います。そこに、ＳＥやプログラマたちがどれだけの思いを詰め込んで、システムの開発やプログラミングの作業に打ち込めるのかにかかっている、と言えましょう。
確かに、この『擬似ホストテストプログラム』は、そのコーディングの工程では、ＢＡＳＩＣコンパイラとアセンブラのおかげで、私のこれまでの趣味が生きる形になりました。けれども、とにかく机上デバッグとプログラムの動作テストで一つでも多くのバグ不具合をつぶすことが、私のコンピュータ・プログラマとしての、主たる重要な仕事でした。それが、クライアント側で開発中の大型ホストコンピュータが完成するまでの、短い寿命のプログラムだと私もわかってはいましたが、私は手を抜く気にはなれませんでした。コンピュータの開発システム上の、その身代わり感に、あるいは、その成りすまし感に、世の中に貢献することへの大切さがあったからです。つまり、ＩＴ技術とは、デジタルな何かを開発することが重要なのではなくて、何の目的で開発されて実際に使われるのかが重要なのです。
たとえば『成りすまし』について申すならば、昨今は、大学入試のカンニングごときに使われたり、あるいは、人をだましてお金を巻き上げる、ネット上のサギの目的に利用されたりなどしています。そもそもデジタル化というものは、データ情報の簡素化であり、その限定されたデータ情報によってシステム運用の効率化をはかるものです。しかも、それはＩＴ技術だからこそ、なせる技と言えましょう。それを悪用しようと、しなかろうと、結局それは人間の心がけ次第で悪くもなり良くもなります。カンニングやサギに心が向くのは、その人の生きている環境が悪いせいであって、高度な技術のせいではないと思います。したがって、もっといいことにその人の心や目が向いて、もっといいことに興味がわけば、そのような悪知恵を働かしている場合ではないことに気づくはずです。そのような教訓と反省から、ＩＴ技術を初めとする知識や情報や技術がまっとうに使われるようになることを、私は願ってやみません。
