何をしに三週間も出張に来ているのかと言えば、幾つかの複合的な理由がある。本来ならば個別に往復するところなのだが、航空券の費用も身体への負担も高くつくので途中の一週間は通常の作業を米国で行うことになったのである。お客様と協同の作業が先週の一大イベントであった。デザインレビューの実施なのである。キーカスタマーへの注力は着実な展開を図って、米国技術者のリソースを最大限に活用してもらうという意味においても訪米してもらうのがベストなのである。枯れた商品であれば、そこまでする必要も無いのだが新分野の商品技術を適用していく上では慎重を期するのである。こうした携帯電話業界にあってビジネスクラスで五名の技術者を送り込んで来られたメーカーの意気込みもうかがえる。

広範にわたる携帯電話技術において、提供する技術範囲も広がりを見せてきていて三年前にジョイントしたときには手薄に感じられていたアプリケーション開発にも専任部署が生まれていて、チップ開発部門と共同で分担するようになってきた。しかしながら、チップ部門で彼らのミドルウェアを提供する上での理解については実際にアプリケーションを開発していないメンバーにとっては理解や意識を共有することは難しいように見受けられる。実際のお客様の開発支援作業をしているとお客様からの素直な質問の投げかけが、互いの責任分担をクロスオーバーすることが発生した場合も含めて提供している技術については相互理解を進めておくことは肝要である。

クロスオーバーしている範囲の仕事を進めていく上での壁は、仲間に対して「なぜ、その活動が必要なのかを言明しておく」という事さえしておけば、オープンドアな文化であるので事業部が異なっていても問題はない。互いの意見交換をしていく上では、ホワイトペーパーの交換ならびにミーティングが必要であると思う。今回は、お客様支援の週の後半に当該事業部の仲間も米国に来ていることもあって予めマネージメントを通じて意見具申をしておいてミーティングを取りつけておいた。チップ開発という立場でプロトコル開発に注力しているQuad社ではあるが、アプリケーション開発というスタンスでの理解については部品事業部ではもう一息という感がある。

パワーポイントで書いておいたのは、適用するアプリケーション構築技術についてのアイデアである。実は、このアイデアは以前から実践していたものなのだが殆ど理解されないで前の会社では腐っていたものである。説明する力が無いと言われればそれまでだし、時期尚早だったのではと言われればそうかも知れないとも思う。RTOSの問題に言語処理から取り組んだという複合的な技術だからだったかも知れない。アプリケーション開発の現場で遭遇するモジュール独立性を損なってしまう元凶のRTOSの本質について一つの答えを出していたのだが、これが今回はアプリケーションプラットホームのチームに福音になりそうな直感があり東京オフィスでは事業部を越えて認識しはじめていたからだった。

ITRONは日本では標準語として普及しているのだが、この事実は外部からみると殆ど知られていないし、そうであることの必要性について疑問を投げかけられてもいる。私自身は、前の会社においてTRON黎明期を過ごしてきていて、そうした渦中でuITRON仕様ならびにITRON仕様のRTOS開発に携わってきた。東大の坂村研究室の方々とTRON展示会などでお会いした折に次のような意外な質問を受けたのだった。「ITRONっていったいどういう意義があるのでしょうか」・・・。彼ら曰くは、通常のRTOSの機能を集約したようなものであり取り立てて新しい概念があるわけではないからだということだった。その時の私の回答はというと「その事が大切なのです。共通語を用意することで開発に携わる協力会社の人たちとの理解が同一になるからです。」・・・と。

思い出してみると確かに当時の認識を鮮明に覚えている。そして今、そうした背景にあるメーカーと協力会社という当然のような図式を当時から国を挙げて目指していたのではないかと今では思えるのだ。RTOSの技術追求ということを標準という形で辞めてしまったことのつけは坂村研究室が負ってくれたのだろうか。そして、そうした事をあの頃の研究員の方達は危惧していたのではないのだろうか。実装現場で起こっている事実からのフィードバックを標準化という形で失ってしまって進めてきた組み込み技術は、溢れかえるアプリケーションの時代で破綻を迎えてしまった。坂村研究室も追いかけT-engine構想を発表したのだが、マイコンまでも取り込み開発に取り組もうという以前の勢いではない。日本は今ではマイコンという意味からいえば負け戦に陥っているように見える。

これは別にITRONを批判している訳ではなくて、組み込みからアプリケーションベースでの広がりのあるパソコンのような様相を呈してきた現状にはそぐわないといっているのである。当時私が注目してきたのはアプリケーション開発でのモジュラリティを損なっているのはRTOSとスタックの関係であると考えてきたからである。無論メモリプロテクションがかかるような状況にあってMMU配下で動作させれば問題がないというのかも知れないのだが、少なくとも当時の私が取り組んできたデジタル化業務用無線機において採用しようとした16ビットマイコンにはMMUは無かったし、現在の主流であるARM7TDMIでも同様である。ライブラリ開発を進めているメンバーとの共同作業をしていく上で当初に予測していたスタック見込みを越えてしまう場合には、システムテストでしかなかなか知り得ないということなどが問題であり、またRAMの容量の制限もあり潤沢なスタック領域の割りつけということがデバッグでも出来なかったことが背景とも言えるのだが。

当時のアイデアでは、スタックをゼロにするというアイデアなのである。並行処理をするタスクあるいはプロセスというものがスタックを浪費しないということであれば、スタック侵犯という事態は起こり得ないのだ。しかし、この事はタスク設計という立場からは並行処理という概念をRTOSによって確保したいと考えてきた人たちからは、受け入れ難いものだったようだ。スタックを抜きにしてC言語は語れないのだろうか、どうしたらスタックゼロでRTOSを利用できるのかという天動説に陥ってしまうようだった。逆転の発想でRTOSからタスクあるいはプロセスが呼び出されるという形にすることでさらりと書いたメモを見て当時本当に理解してくれたのは実際の仲間内ではただ一人だったようだ。彼は、このアイデアに心酔してくれて関連ツールの開発やカーネルの開発に当たってくれた。

カーネルのベース自体はuITRON仕様の物があった為、かなり流用できたのだが、タスクスイッチングのメカニズムや関連ツールの開発にはてこずっていたようだった。まだ、この時点での製品開発にあたっては、通信プロトコルとアプリケーションとのスケジューラを分けるという考え方はなかったのである。この開発方法でゼロスタックとなったタスク処理は、二機種に渡って実装開発された。続く別目的の機種では、マイコンを変えるという段階で継承されなかったようでその際にはカーネル移植までの工数が開発費用に計上出来なかったようだ。果たしてマイコンを変える必要があったのかどうか・・・。マイコンを部品の一つとして捉えていて開発環境などについての投資などが理解の範疇にあったのかどうかは一般に理解の外なのであろう。基本要素技術というものが部署あるいは事業として考えられていれば移植したのだろうが・・・。

そんなことを思い出しながら、別の事業部の仲間達にパワーポイントのプレゼンテーションを行いに向かっていた。チップ開発の事業部とはビルディングが異なるので、同僚に車を出してもらい彼らのビルまで送ってもらった。C++ベースでウィンドウズ志向のアプリケーション環境を目指していた彼らの前身母体は、実はQuad社の端末開発事業部であった。端末事業自身は事業移管という形で分社してしまったのだが、開発チームは残っていたのである。チップ事業のビルと同様に低層階の構成のビルはアメリカ特有のゆとりがある。アメリカの消費文化の根底には広い国土と多様な民族性を受け入れて出来ている歴史がある。メールで示された会議室には他と同様にコーヒーポットが配備されていた。常置されているプロジェクターにPCを接続してもうすこしパワーポイントを仕上げていると皆がやってきた。

アプリケーション開発環境のボスともう一人はマルチスレッドの担当者だというメンバーと日本から来ていたアプリ担当の技術者である。環境のボスは状況と方針を提示して途中までしか時間が取れないが、Mr.MultiThreadに委託するから大丈夫だといっていた。もう一人くるといっていたが、白人系列のライオン丸とおぼしきMr.MultiThreadと向こうのボス相手に日本のユーザーからの現況に対する要望と展開に対してのアイデアを説明していった。大風呂敷の感のある向こうのボスは、開発途上の技術と現況との間のギャップについてはあまり関心がなく、「その制限は解決している」とか、そういったコメントを直に挟むのだが、前日にチップ事業部で開発にアプリ開発を手がけている仲間に確認していたことも有り、現状の現場認識とは違うからねと釘を刺しておいた。こうした場ではへこんではいけない。現状分析に伴い課題を明らかにしつつアイデアを説明するに至った。途中からもう一人インド系技術者が参加してきていた。

アイデアの説明をしていると、もう一人の増えた技術者とライオン丸とが頷きつつ前のめりになってきているのが見て取れた。彼らは一通りの説明を終えると同様な移植事例をいくつかサンプルとして行い同期型アプリから非同期型アプリへの移植ガイドラインという取り組みをしてきたと語り始めた。私の提案した方法論が型破りであるのは確かなのだがしっかりと理解して受け止めてくれたのはとても嬉しい体験だった。「お前たちは、判ってくるんだなぁ」という内心ガッツポーズの瞬間でもあった。理解される仲間に向けて発したアイデアは、大きな波紋を投げかけたらしかった。畳みかけるように、「部品事業として取り組んでいる我々のスタンスとアプリを中心に取り組んでいる貴君達の方法論が一つである必要はない」と問いかけた。OSinOSの考え方である。リアルタイム制御として通信プロトコルの実装を完了させてきた部品事業の上に、彼らがアプリケーション環境を一つのタスクとして振る舞うようなかたまりとして彼らのマルチスレッドアプリが動作すれば良いからだ。

彼らはアイデアに納得すると共に、疑問も投げかけてきた。「なぜ部品事業の君がそういう認識を持つのか」という物だった。端末開発をお客様の支援という形で続けてはいる物の、次に控えている世代のチップも含めてアプリ環境チーム達の提供する部品群のお客様からの評価が現場からは移行性に難有りとして評価されていることへの対策として捉えているからさと答えた。彼らの疑問は氷解すると共に次のステージに移っていた。アイデアを具現化する為の方策といくつかのIP問題であったのだが、残念ながら元の会社からIP訴訟が起こるほどの反応があれば喝采を送りたいくらいだと説明した。評価もなければパテントも無いのだからと回顧しつつ説明した。「新たな君らのより良いアイデアと共に纏めてパテント化してパテントウォールにでも入れてくれ」と頼んだ。後は君たちの仕事だし、必要な手伝いがあればするだろう。」・・・。事業部を越えた先進の取り組みが動けば未来は変えられるのだから。後先になったがビジネスカードを交換して手応えのある握手で終わった。

説明を終えてからオフィスに戻ると直に、ライオン丸からメールが届いていた。彼らの取り組んでいたスレッドライブラリによる移植例に伴うガイドライン解説といった資料だった。彼らは提案した物の、その困難さに直面していたようすだった。そして私の提示した技術アイデアで補完することにより、よりロバストなダイナミックなゼロスタックテクノロジーとでも呼べる彼らの考える技術がPOSIXやITRON互換のライブラリも踏まえて提供してくれそうな展開となった。こうした技術展開の愉しさを前の会社でも一時は感じられたものだが、結局の所それは会社の文化ではなくて偶々そうした偶然が重なって起こっていたことのように思われる。会社の方針や文化がそうした、技術上の突然変異や融合を産み出す必然性を持っているのだと強く感じることができた。少しはでなリアクションが自分にも降りかかってきそうな嬉しい悲鳴もありそうな予感ではあるが納得する未来に向けて進むというQuad社の文化が私自身の感性と融合してきたように感じる。

意識共有で高みを感じてきた、もとの仲間達が遭遇する変われない会社文化や風土と相対して辞めるに至っていったのは仕方のない事だったのかも知れないと思い返している。逆に言えば技術追求を行うことも文化風土の創造醸成も併せて行っていくことが必要なことなのだと強く思うのである。昨今のCMM活動や技術者気質といったことの追求などを行っていくことに対してのもっと強い会社側の理解が得られるように、現場ならびに経営者の双方からの努力を続けて欲しいものだと感じている。どこにいても結局の所同じような意識で仕事をしているんだなと変われない自分にも驚いていたりもする。もっとドライに生きられれば気楽なのにと思われるかもしれないのだが、これはもう四半世紀以上の技術者生活で染みついた私のライフスタイルなのだ。