会社を使いこなしてこそというのが、会社に勤めることの意義ではないだろうか。一人では出来ない仕事に携わっていけるということの価値を問い直してみることで会社に属するという意識から抜け出せるのではないだろうか。会社から与えられた仕事に取り組む上でも自分自身の技術者としての取り組みたいカウンタープロポーザルを提示しつつ工夫を凝らしてやっていくということだ。同じ仕事の仕方を続けているのならロボットと同じである。そうした流れに則って考えてみた上で障害になるルールがあるのならば、論陣を張って対抗してみてより良い結果が示せるのならば上長の許可を得てルールの一時的解除などを画策すればよいのである。良い結果を示せればルール事態が変わっていくはずである。新たな実績のない技術などでのチャレンジなどは失敗も考えられるが故に、別の対応を上長は考えた上で取り組ませるに違いないからだ。

組み込みソフト開発としてC言語を初めて使いこなそうとしたのは、実は４ビットマイコンでのことだった。８ビットマイコンでアセンブラを駆使してやってきた仕事を高級言語を使って４ビットにするという取り組みにはおそらく別の意味もあったようだ。マイコンチップの開発を始めてから当初より家電向けに特化してきたメーカーとして自社チップの最新型４ビットマイコンの強化を果たして来ていた。コスト力も含めて社内製品の活用は一つのあるべき姿といえたかも知れない。前哨戦として４ビットマイコンで作った小規模な無線端末装置のプロジェクトを経てメインラインの端末に乗せコストダウンを図るというストーリーを持った開発戦略をしいていた。８ビットマイコンで構築してきた業務用無線機器を４ビットで置換するという目的には完成度の高さが求められていたし、当時事業部として取り組もうとしていたC言語シフトに照らしてみても４ビットマイコン向けのＣサブセット言語の評価適用などの条件を出しつつ、会社側のハードコストダウンというテーマと技術者としてソフトウェア開発をC言語で実現するというテーマのこれら二つの挑戦をすることになった。

８ビットで開発してきた製品ボリュームを４ビットマイコン一つに押し込めることではなくて、二つの異なった周辺回路の特性をもつ４ビットマイコン二つによる分散処理での実現ということでのチャレンジでもあった。このほうがより難しくなることは自明ではあるのだが・・・。開発環境は、導入されたばかりのＶＡＸ１１−７８０であり他のユーザーは殆どいないという状況での取り組みだった。ビジネス戦略上の重要な位置づけの商品開発にこうした賭けに出たのには用意周到なトップの抜かりなさもあってのことだった。４ビットマイコンの評価を兼ねてハードシミュレータと呼ばれる評価ボードを使い、開発環境としてのＶＡＸでコンパイルした結果のコードをダウンロードする仕組みまでは作りこむ必要があったが、シリアルポート同士を繋ぎこみつつホスト側のツールコマンドをさらっと開発してモトローラＳなどのフォーマットをパースしてダウンロードというよりもメモリー書き込みのコマンド操作に置き換えてシリアルに出力することでダウンローダは完成してツールチェーンが出来上がった。

無線ユニットと評価ボードを繋ぎこみ無線データフレームの解読を試みてデータハンドリングが出来ることまでの評価完了にはあまり時間がかからなかった。無線制御系統のチップセット側の処理は無線機制御と信号フレームのレイヤ２までの処理である。といってもアナログの時代なのでレイヤ２というほどのことは無いのだが・・・。こうしたコマンドのやり取りを予め定義しておいたのでシリアルコマンドのアナライザを開発しておく必要を感じたので別途に開発を依頼していた。携帯ノートパソコンの拡張ボードに追加する形でクロックシリアルのキャプチャが出来る構成にしていた。当時のBASICで動作するノートパソコンで冶具を開発していくのが拡張性も含めて容易な時代であった。ルールから逸脱した分散処理構成でＣ言語ベースで動作するローコスト４ビットマイコンで作るというプロジェクトの下地開発は完了した。Ｃベースで書いたとしても４ビットマイコンでの動作性能に差異は見られなかったのである。これは一つの有益な経験となった。

製品化に向けて入る段階でＵＩ側の４ビットマイコンのソフトウェア開発の協力会社のメンバーを二人加えた、さらに既に小規模な端末を4ビットマイコンで仕上げた別の会社のメンバーを一人加えてシステムＳＥとして機能するような形にして開発が進められた。入れるべき機能については予め８ビットマイコンベースでの現行製品があり明らかだったし新製品としてローコストでありながらも液晶パネルにするなどの機能強化することで商品の魅力を高めようとすることも会社側の狙いにあった。無線モデムマイコンとUIマイコンというシステム設計で進めてゆくうちに、レイヤ３に相当するシーケンス制御などの実装を進めていく上では、開発に必要なツール作りが毎日のように必要になった。開発支援で入ったメンバーはUNIXとCに嵌り毎日のように有益なツールを開発しては提供しつつ開発プロジェクト全体の進捗を管理していた。

表示機能や単機能として必要な低歪トーン生成などの作りこみに問題はないものの開発を進めていくうちに雲行きが怪しくなっていった。シーケンス制御が大きすぎてROMに入らないのである。C言語だから入らないというのではなくて、今までの経験をもってしても4ビットマイコンというアーキテクチャ特性から工夫の余地がなかったのである。テーブル化とか様々な技法については可能な限りの検討を加えてはみたものの、機械語やチップマニュアルをくまなく見ても解はなかった。見積もりが甘かったといえるのだろう。ページという概念が思った以上にシーケンス実装には足かせとなっていた。全員がSEでありプログラミング設計までも実践しているチーム構成だったのでこれ以上は実現不能なのではという状況が共有できた。

開発中心ではない支援担当として入っているメンバーの意見「どう楽観的にみても無理です」が会社側に伝わり４ビットマイコン二つでの構成を諦めてUIマイコンを表示サブシステムマイコンのみにするという大転換を果たして従来の8ビット設計に追加する形で開発は数ヶ月遅れで実現させたのである。開発失敗という挫折感はあったにしても、開発に際して必要な道具作りも含めて開発環境としてのUNIXベースでC言語を使い切っていくということは一つの製品開発をしあげていくということ以上に派生するツール開発なども含めて有益な経験となった。会社側にとっては開発失敗で販売時期がずれてしまったことがあるだろうけれども、互いにチャレンジすぎたテーマだったのかも知れない。最初のC言語ベースの製品は、サブシステムマイコンにのみ残された形になったが開発プロジェクトの大転換ということもあってか公にはしなかった。

失敗の追及をするのではなくて始めてのC言語による開発取り組みをしてきたプロジェクトとして上司のケアは前向きだった。「どうすれば使えるのか、どうしていくべきなのか」、この上司の前向きな優しさというものは会社のルールにあるものではない。失敗を超えて会社にとって自分たちにとっての肥やしにして踏み出そうというのである。幸いにC言語ベースでの開発の過程で日常作業としてのツール作りなどになれてきたこともあり、8ビットでのC言語ベースでの開発の調査を進めさせてもらった。当時のツールメーカーが選定している8ビットマイコンではC言語において必要となる命令の直交姓などが不十分な旧いチップに向けたコンパイラ提供などをしていたために所要の性能をそのままでは満たさないことが判った。言語仕様を満足したとしても使えなければ仕方が無い。ソースコードで公開されていた上位チップセット向けのCコンパイラを改造する道を選択した。アーキテクチャ的な壁は、工夫で回避できそうな感触があったからだ。上司の内諾をもらい公開されたソースコード記事をキーパンチに依頼してフロッピーを入手して一週間ほど端末室に篭らせてもらった。

所要の指針に向けた、雛形が完成したのであとは改善のサイクルをまわすことで新たな技術分野として要素技術の範疇と開発方法論の範疇との両輪を回すことに繋がっていった。実績の無いものは使わないといったルールにとらわれることも無く自由に進めさせてもらった結果は、最初の4ビットマイコンでの挫折がバネとなり大きな成果を結ぶことが出来た。コンパイラにより完成度の高いコード開発が可能になったのは、その頃のICEベースで開発していたアセンブラによる開発とは大きな差別化が図れたし、まさかその後コンパイラ自身を製品の一部として配布することになるとは考えもしていなかった。ルールや型に嵌った仕事のみに従事している技術屋だけだとすれば、そのメーカーに将来は無いのではないかと考えてしまう。チャレンジという言葉は、自分でリスクを負い実績を作り出していくということなのである。そうしたチャレンジに踏み出せるのかどうかは、上司や会社を動かす技術者の熱意に掛かっているのだと信じている。