大きな会社で組織の壁に阻まれて変わりたくても変われないでいるという人がいる。お客様の立場を駆使して仕事を得てうまく会社の方向性を変えていこうという動きにはなれないのだろうか。次の一手を読みつつ自己修正をしながら取り組んでいくという姿が必要なのだと思う。トップメーカーとして果たすべき役割を認識して、時代を捉えて次代に繋がる開発をしていくという観点で見た場合に技術と営業の接点は限りなく密接な連携を取るべきだ。一時代をなしたリーダー達が、営業費用を散財していたという非難は的を得ていない。彼らは投資のための情報収集に投下していたのである。結果として得られた情報には、正しい方向性と必然性のやり取りの結果として入手してきたことにより意味を持つのだが、そうした意識なく取り込まれた軽薄な情報では会社の方向性を見失ってしまうだけだろう。

過去を振り返るシリーズが続く中で、アセンブラーベースの開発から高級言語に移行していく過程で考えて取り組んできたことについて記していく事には幾ばくかの意義があると考えてのシリーズ化となっている。大規模なシステムとなった分散マイコンによるシステム開発の成果はアセンブラーベースであった当時でも、隙間産業としてコンピュータメーカーに対抗しうる製品をくみ上げられることを教えてくれた。アプリケーションを開発する意識の人たちにトランザクションベースのソフトウェア設計を考えさせることの難しさもあったしアプリケーション設計とシステム設計といった階層の違いについて肌で体験することが出来てきた時期でもあった。機能が、高級化するなかで細かい対応をアセンブラーベースで追いかけていくことが難しいと感じつつもC言語でのコード効率やデバッグなどには手が引けている実情もあった。

そんな状況下でトップが示した新環境・開発スタイルへの移行ということについて成功した理由は、次のようなものではなかったか考える。新環境(UNIX)利用者への便宜を図り、旧環境の拡大を禁止する。新環境利用者のフィードバックを推進していく、支えていくためのチームを作る。次世代の若者を最初から新しい環境で育成する。ディープでコアな開発を新環境で進めさせて開発スタイルでの問題点を洗い出していくといったことである(であったらしい)。当事者という立場で、私はコアな開発をしていた。ツールが無いので自作しながら臨むというのがＵＮＩＸのスタイルであり文化でもあったようだ。毎日のように開発ツールを作りつつ実際の開発を進めていった、どちらもＣ言語で書くことにより言語への習熟にとっても意義のあることであった。

当時の組み込みターゲットはソフトウェアのサイズとしては８ｋや４ｋの世界であり、初期のCコンパイラーが作り上げるコードの冗長性は問題でもあったが、将来の改善も含めてコーディングやデバッグスタイルが変わり確実に生産性が向上していくことを体感することができた。アーキテクチャ的にC言語にマッチしないマイコンでの難しさやアプリケーションの増大基調での中では時期尚早ということもあったかも知れない。コアな開発はまさにコア部分のみが成功して製品にはなりえなかった。しかしコア部分のみを使い商品には活用することになった。失敗の理由はターゲットチップ(4bit)でのアプリケーション組み込みとサイズとのミスマッチであったので、次のステップとしてよりC言語と親和性の高い8ビットマイコンでの取り組みを申し出て許可を得る事ができた。やらなければ判らないことに取り組んで失敗したからといって卑下することは何も無い。

コアな開発をしていた私は8ビット向け組み込みコンパイラの評価というテーマを許可してもらいHP社の提供したCコンパイラの評価をした。端末向けチップであるモトローラ6800用のコンパイラはベースチップである6800の命令コードにあわせて書かれていたのでC言語としての文法は通る物の実際の速度については問題がありリアルタイムなシステムでの処理時間としては使い物にならなかった。この結果を報告するにあたり私が考えたのは、次の一手をどうするのかという点であり、自分としてこの結果を踏まえて次に打つべき方向性を考えた上でトップの方針を仰ぐということであった。使い物にならない理由は明白であり、自分たちで使う日立のマイコンの命令セットを活用できれば解決できるものだった。サブセットのCコンパイラーとしてソースコードが公開されていた事例について思い起こしていたこともあり次の方向性を提案した。

このまま既製コンパイラの適用は見送るか、新たに使えるコンパイラを作るというものの二つだった。前向きな後者の取り組みについてトップからの意見が求められたので、手に入る内容とそのターゲット性能とをうまく勘案すれば作れそうだということを説明して、結果として説得できた。少し古い雑誌の記事について探しそうした雑誌を綺麗に溜め込んでいるという殊勝な人物が社内にいることが判明し、その彼から借用して複写を取り、パンチ入力業者に依頼してソースコードを入力してもらいソースのフロッピーを作成してもらった。フリーフォーマットのCソースコードのコピー原稿に升目が書き込まれていてカラム確認を求められたのには苦笑してしまった。打ち出されていた原稿は当時はやりのインクジェットプリンターの物らしく、読み難い文字のいくつかはコンパイル時点ではじく事ができた。(これらのコードは現在ではインターネット上のＬｉｎｕｘ文化のようにソースで公開サイトからダウンロードできる時代となっている。)

UNIX端末を駆使しつつ、コードをコンパイルしてデバッガを仕掛けながら実際のターゲットコードを入力しつつクロスコンパイルしつつブレークポイントを仕掛けつつ実行してコードの実態を追いかけていく一週間ほどで性能はともかく実際のターゲットマイコンで動作するコンパイラーにすることが出来た。1984年の暮れのことである。年明けにはさらに最適化を進めていくことについて許可を貰い製品開発者の目で必要なコード展開性能がなぜ出来ないのかという視点で構造の見直しや改善を行いつつ実際の製品開発に適用すべく二足の草鞋を履いた生活を続けた。VAXでコンパイルしてHPの開発マシンでアセンブルビルトアップするといった環境からツールとして同一マシンでアセンブルまで出来るようにするためのツール開発も行った。使える技術に仕上げていくという視点でのその仕事は研究所の仕事ではなかったし、無論事業部としての仕事の範囲からも逸脱していたかも知れない。

無論トップの考えていたＵＮＩＸ環境をベースにした開発環境への移行プロジェクトには、コアなコンパイラー開発やリアルタイムシステムでの適用などを経つつ全体への浸透を図ることが考えられていた。米国ベンチャーとの提携や国内のUNIXに造詣の深いソフトハウスなどからの技術供与なども視野に入れての取り組みだった。利用が進まない中で新人を全てUNIXベースで教育するなどの取り組みなども始めていたのだが、彼女らが配属されて活用が徐々に始まり、社内での部署毎の利用度合いを競争させるといったこともひとつの方策だった。本当のねらいは利用の活性化により社内のコミュニケーションを良くするということでもあっただろう。新たな取り組みをしていくための当時の技術トップの方たちの懐の深い取り組みには、今でも参考になるべきことが多いように感じる。全社での次世代で取り組むC開発へのシフトといったテーマにも先進事業部として積極参加していたのだ。

幸いＵＮＩＸ開発環境への習熟という目的や、広がりを期待して教育していた新人たちが配属されてきたことも手伝い時代はC言語の黎明期に突入しようとしていた。会社内部でもＶＡＸを高価なシステムでありながら率先導入したことを鼓舞する目的で取り組み事例などを啓蒙しつつ実開発に繋げていく時代になっていた。１６ビットマイコンに初期製品として登場したコンパイラを適用して開発した事例を手がけたのは若手技術者のS君だった、彼は米国ベンチャーとの共同開発プロジェクトに参加した経験がありＵＮＩＸをそうした中で学び国内に戻ってからの最初の実務として取り組んでいた成果でもあった。ＲＴＯＳをＣから呼び出すための問題点などについてアセンブラー側とのインタフェースなどを中心に取り組んできた成果を披露していた。私は、開発してきたコンパイラーを紹介したし、その成果での8ビットマイコンのC言語開発シフトを何とか果たすことが出来た事例も紹介できた。

日立のエンジニア以上に、そのマイコンをいかにC言語にマッピングすべきかというノウハウを一年あまりのうちに蓄えてコード生成の効率化のノウハウも蓄えることが出来た。生憎とそうしたビジネススタイルから残された資料はソースコードでしかないのだが・・・。私はソースコードを見て学んだので、続く人にもソースコードを読めといいたいのである。最適化のアイデアはいくつも思いつき可能な限り盛り込みいつしか、生成したコードには手が入れられなくなってしまっていた。もともとの開発目的は、無線機に搭載するデータ通信カードの開発であり、RS232のインタフェースで小さなパケットデータを飛ばすというものであった。このシステム構築に必要なプロトコル開発はパケット単位での誤り訂正や、その再送といったものであり現在のＴＣＰの原始的なものだといえばよいだろう。当時は５バイト程度のデータを誤り訂正符号をつけて飛ばしていた時代なので100バイト以上の伝票のようなデータを飛ばしたいという時代要請は大きなビジネスが控えていた。

専用のシステムという見方をすれば、流通業界向けに開発した宅配便の集荷注文指示を無線で飛ばしてトラックにあるプリンターに印刷するというシステムは出来ていたのだが、このシステムでは全国規模でトラックを多数保有しているような会社でなければシステム導入が出来ないというコストからの敷居の高さがあった。小口のお客様に応えていくようにするには自分たちの業態を変えていくことが必要なのだ。当時はBasicで動くパソコンが街中のシステムハウスで扱えるものであり、まだＣＰＭになるのかMSDOSになるのかは誰もわからなかった時代でもある。そんな時代に合わせてとりあえずＢＡＳＩＣで対応できそうな通信手順を開発提案して、伝票程度の量のデータを無線で飛ばすようにするという今考えればｉＭＯＤＥで済みそうなシステムを大袈裟に作っていたといえばいえるのかもしれない。問題は、自分たちがお客様の立場に近づいて対応できるように自己変革出来るのかということでもある。

データ通信カードの機能向上は、実はコンパイラ開発の機能性能向上の歴史ともなっていてコンパイラのコード生成効率の追求や性能向上の追求は、ライフワークとして私の仕事の一部と化していた。上司に申し入れた専用の開発スーパーミニコンの導入は受け入れられて部署単位での事業ビジョン毎の投資という観点が通用していたのは健全な時代だったともいえる。そうして充実してきた開発環境を通じて、無線データ通信カードが完成していく中で、通信方式の追求挑戦というものもニーズから派生してきた。関西空港工事向けの専用無線システムを開発するというテーマが降って沸いてきたのである。一対一でデータ通信をすることを考えてきた自分たちに突きつけられたテーマは、ある程度のデータを無線放送といった形で一対Ｎで実現するというものであったのだが、基本的に連送しながら再生出来たパケットでデータを再構成していき全部が揃った段階で外部パソコンにデータを受け渡すというパケット送信カードという構成を目指した。

しかし残念ながらパソコンとの接続以外に問題が起こり、現地に既に導入されていた気象設備との通信手順にあわせて現地で接続する段階で問題が起きたのである、残念ながら開発ツールであるコンパイラは会社の開発用のスーパーミニがないと使えないのでモデムを利用して呼び出して利用するしかないのである。他社製品であり現地にしかない機器との接続での効率という見方をすればプロトコルアナライザで通信手順の実情を追いかけながら、ソースコードを広げて問題点を確認してソースの修正を考えるというサイクルをまわしていたのだが、コンパイルするためには1200bpsの高速モデムを使ってもｖｉの画面更新が出来ないような状況で遠距離電話をかけてしこたま電話代の請求書をもらった記憶が懐かしい。自身で開発したコンパイラがコンパイルできるようなコンパイラはMSDOSにはまだ無かったのである。

そんな状況の中ではあったが、これを利用してユーザー自身にソフトウェアを作ってもらうというビジネスモデルに思いが行き始めたのである。いわゆるソフトウェアデベロッパーズキットと最近では呼ばれるものである。頭に擡げたそうした思いにとらわれるのは、C言語で自分自身で開発する限りにおいてはICEもなしで開発が数日で完了するようなものが続いていたからである。高々8kB程度のシステムではあったが従来のアセンブラーベースで開発していたのでは効率が悪くてしょうがないと自分自身で積極利用していた結果でもあったのだが・・・。新人に使わせてみてもＩＣＥ無しでリアルタイムシステムを簡単に構築することが確認できたのである。となると課題は作ったコンパイラを早期にまずは、ＤＯＳで動作させることが必要だったのだが、当時の非線形のCコンパイラではスモールモデルで作れるサイズにはコンパイラーが大きすぎて入らなかったし、ラージモデルというメモリスタイルにはＵＮＩＸのリニアなコンパイラのコードは合わなかった。

DOSでまともに使えるコンパイラーとして使えそうなものは、当時事業部のＵＮＩＸマシンの技術顧問をしていただいていた（？）ペンギンソフトの筒井さんが作った南極ペンギンコンパイラぐらいだったようで、実際に初期のためしに彼からソフトを貰って動作させてみたりはしたもののオリジナルのコードとＤＯＳの親和性はないようで構造の見直しが必要だった。筒井さんからは、小窓作の組み込みコンパイラーのＵＮＩＸ版を売りたいという希望もあったようだが当時の時代背景からも浮いていたようで引き合いにきたのは日立とHPの二社だけだったようだ。開発マシンとしてＶＡＸをもち、ＨＰの開発環境をも持ち合わせているという会社がどれほどあったのかは知る由も無かったのだろう。しっかりとした開発環境が必要だと考えている上司がいたというのは大変な幸運であったのだ。自宅にＭＳＤＯＳマシンを持つことも無かったので、怪しげなマシンを出版社から記事投稿の引き換えに借り受けたりしたりしたのだが、完成をみたのはまともなコンパイラであるTurboCが利用できるころだった。サザンパシフィックの片山老師との出会いなども悩んでいたから故の必然だったと思い返すのである。

基本的に１６ビットマシンの上で３２ビットの処理で動作しているコードを動かすという矛盾ではあったが、取り扱いデータを１６ビットに統一しながら大きなデータが取り扱えるようにするという地動説的なアイデアにたどり着き解決することができた。ソースコードはどこのマシンの上でも動作するようにメインラインとしての構造を書き改めてＵＮＩＸとMSDOSの何れでも動作するように出来たのは自身のコード対応力などにとってもプラスとなった。難しいテーマであればあるほど技術屋としては楽しめるものなのだし、解決策は必ず生まれるものだ。ソースコードを共有しつつ師弟関係を達成するという姿は、直接に面と向かって指導しなくともコードを紐解いていけば達成できるものだなと私自身は感じている。しかし、そうした実情に到達するまでに仕事を深めていけないのが最近の実情なのだろうか。いろいろな仕事をしながら漸くたどり着いたコンパイラ開発ということは、中堅技術者のアセンブラのテクニックを実際のCユーザーには即座に活用できるので誰が書いても高性能というスタイルを果たせた。その時代の渦中で技術者として加速度を体感できるような仕事を残せるように、自身の技術カテゴリーを確立してＳＥとしての意識もあわせて進めていくのが技術者の姿だと私は思っているのだが・・・。

コンパイラーＳＤＫ編に続く・・・