旧い話を持ち出して、今更ながらのYacc/Lexといったコンパイラ構築の為のツールによりアプリケーションの書き方を改善しようというのは長らく染み付いた日本の組み込みソフト開発力強化の流の残骸の収容でもある。携帯やＮＡＶＩに限って言えば、既に組み込みという域を外れているのであるのだが、経営者も昔の技術者であった技術トップも認識できていないようだ。システム設計の感覚を忘れて個別機能の実現のみに腐心して開発してきたものを、合わないフレームワークであるITRONの世界に当てはめようとしているところに問題がある。このことをハードウェア的に解決しようといういかにも日本的な取り組みがDualChip化の動きである。

そうしたデュアルチップ化で問題が解決するのかといえば、問題の本質は違うところにあるようで実際には解決策にもならなかったりする。問題はRTOSのフレームワークにあるようなのだ。こうした問題を解決するフレームワークを目指して開発されてきた携帯向けのOSもあるし、ある意味でいえばWindowsCEもそうした範疇だとマイクロソフトは宣言するだろう、過去のXenixベースのカーネルを保有してきたという歴史から見ても彼らは真剣に目指しているのかも知れない。マッチするのかどうかは別だが・・・。実際問題知己の開発している次世代NAVIなどはWindowsCEを駆使しているようだ。過去から議論の多くにプラットホーム化が達成すると撤退してしまうという図式がある。差別化が出来ないからだという。自社としてそのプラットホームの上で工夫して使いきろうという気概は恐らくないのだろう。

製品での特徴としての差別化といえぱ、ハードウェアとしての自社ＩＰを敢えて使うように推進することで、自社IPを必要条件に組み入れようとしたりすることであったりする。確かにプラットホームがオブジェクトで提供される限りにおいて、されらをトリッキーに拡張したりすることよりも安全策ともいえるのかも知れない。赤外線ＩｒＤＡの開発の歴史は携帯端末などとの接続が目的であり提供されるハード性能や期待するアプリケーションに根ざして多彩な開発が行われてきたのだが離陸する直前にトンビにさらわれたようなBlueToothの出現などがあり叶わなかったりもしてきた。ある意味で枯れた技術を再登場させて暗くなった携帯業界の一筋の光明として利用しようということが国内では始まったようだ。

実は、国内よりも欧州では既に必要条件として挙げられているほどポピュラーな機能であったりもする。利用者の注目の矛先をいろいろと変えて行くのが目的になりかけているのは、本命視されてきた先行版WCDMAの不発が原因であると見ている。最大の目的はユーザープラットホームの切り替えを狙っているのである。デュアルプロセッサを搭載させてＪａｖａでの機能実現を高速化して配布アプリを高速に稼動させるといった試みと共に、無線区間でのオーバーフローをデュアルバンド化対応機に載せ替えさせることでアクセス不良を解決したいということだろう。メーカーとして赤外線を取り組んできていた仲間などが再度フォーカスされたりしているようだ。

ソフトでの差別化という視点は、なぜ生まれないのだろうか。冒頭に述べた、ソフトウェアでの取り組みを紹介したさまはある意味で、その取り組みである。残念ながら、国内の組み込み開発においてこうしたプラットホーム基幹技術への取り組み意識は希薄であるように感じる。そうしたことを必要に感じて長期的なテーマとして取り組むという風潮自体がなくなってしまったからであろうか。あるいは、もとより無かったのだろうか、開発効率化という姿を目指して一切合財をリニューアルしたStarのような開発に当たってはSmalltalkの開発までも行われてきたわけだが、そうした意味においての携帯でのそれはJavaなのだろうか。

アセンブラでのスタック操作ミスのような間違いは、高級言語で消滅したのだが、逆にいえば機械語で出来る可能性を摘んでしまったともいえるのである。RISCチップのような単純化した命令で出来るマイコンに変わってしまったのも高級言語で動くようになったからだとも言える。効率化という面で見てみると、CISCマイコンは特定の言語にフォーカスしているともいえるかも知れないし、RISCマイコンでは複雑な書き方をしても結果に大差が無かったりもするのである。こうした事実を知るものは実際にマイコン向けのコンパイラを開発している担当者だけだったりもするのだが・・・。CISCマイコンの命令はアセンブラでの効率を目指してきたりしていて、高級言語では使い切れて居なかったりもする。

実際にCISC仕様のマイコンに向けてチップメーカー自身が開発してきた最新コンパイラをみてみたら、命令ではなくて使われていないアドレッシングモードがあったりして驚いたこともあった。ある仮定に基づいて構築されているコード生成指針が伺えたりもしたのであるが、逆にいえば使いこなしていけばよりよいコード効率が得られる可能性もあるのだが、そうした指針はアプリケーションからの使い方などから追求していかないと浮かんでこないという実情もあるのかも知れない。言語開発とアプリケーション開発の双方を追求するということは中々得られない状況かも知れないのであるのだが、化石と化した議論なのかもしれない。事実Yacc/Lexの教科書などは書店から消えているようだ。そんなことを学ぶよりも今は、スクリプティング言語やJavaあるいは認定資格取得に走ったりするのだろう。

組み込みの世界にVBをちゃっかり使った会社もあった、VBの環境はそのまま使い、生成されたコードを利用して更にコンパイルをして自社用に使うのである。まさにソフトウェアによる差別化技術の表れといえよう、こうした有用な技術が出てくる会社の文化には敬意を表したいとおもうし継続に期待もしたい。基盤技術としてのソフトウェアが商品化出来るような組織であれば良いのだが、製造業という範疇では自社開発したソフトウェア製品自体を登録する商品体系自体が無かったりもするようだ。自前の開発環境を売るくらいの気概で開発されている状況であれば甘えも無く進むように思えるのだが、まずは開発の主体を自身の舵取りとして行っているのかどうかが一つの尺度であろう。

C++を範に取った開発環境を構築したQuad社の事例などはWindowsとAPIや考え方をあわせるなどの進め方をしている。結果として確かに多くのアプリケーションベンダーが生まれ易い状況になったようだ。Javaの技術者を探すよりも、Windowsベースのソフト技術者を探すことが容易なことなどが挙げられるのかも知れない。マルチメディアなアプリケーションの実態がイベントドリブンである訳なので、条件分岐などに縛られた中でのスパゲッティ状態での一般的なとろんとしたコーディングでは合わないのも事実なのだろうが、なぜかITRONだというメーカーの方が多いのは何故なのだろうか。無論Windowsでの実装としてアプリケーションが多数同時動作するといった特徴までも追及できているのかどうかアプリ環境とベース環境との間にギャップも見られるのは致し方ないのかも知れない。

スレッドライブラリを提供して一時避難的な実装を試験したりしたアプリ環境部隊では、結局スレッドコーディングでの並行処理記述には無理やスタックなどのリソースが増加するなどのRTOSベースからリソース拡大といったデメリットなども合わせて共有するようになり結論から言えば奨めはしないといった結果になったりする。スレッドコーディング自体が自身でRTOSカーネルの設計をしつつシステム設計をするといったような性格になってしまうからだろう。RTOSの開発などに長けている人ならば負担なく取り組めることなのだろうが、昨今の端末開発の環境では複数のアプリケーションを統合していくといった背景からタスクでいえば40近いタスクで構成されていたりもする実情で、RTOSに信奉して利用している実情からいえばスレッドでの記述などは更に大きなハードルであったりするようだ。

アプリ環境で必要とするスケジューラというかOSの在り様と無線システム構築するためのOSの在り様とを考えていくと確かに異なった要求事項があるように見られる。イベントモデルにあったカーネルとしてとろんとしたOSを作り変えるという命題は、かなり取り組み甲斐のあるテーマといえよう。カーネルを開発してきた通信プロトコル側のチームとアプリ開発側のチームとが共同になって要件整備をして分担して開発していくべきかも知れないし、誰かが天才的な手腕で一気に設計してしまうというオプションもあるのかも知れない。そうした優秀な人材も沢山いるような雰囲気であるので、出来るだけ核分裂反応が起きやすいような刺激的なキーワードやアイデアを投入して刺激を与えるのが良いのではないかと考えているのだが、技術屋の虫が騒ぎ出して張り合ってみようかなどとも考えたりしている。

チップやソフトを供給する立場としての取り組みでは、他のプラットホームや部品を提供するメーカーとの差別化に腐心するのは当然といえるのだが、ではメーカーでのソフトの差別化とは何をなすべきなのだろうか。PCベースでのアプリケーションメーカー同士の競争ではやはりそれぞれの技術となる点が異なっているのだと思うわけで、端末メーカーでも同様なことが可能なのだと思っているのだがいかがなものだろうか。もし私が端末メーカーだとすれば、同じプラットホームを使っても使い込んで自分の技術として昇華させることをしたいと考えるのだが・・・。書いてないAPIをリバース解析してまでやるというメーカーもあるかも知れないし自分達のアプリ開発の言語処理系を別建てで作り上げるかもしれない。差別化を貪欲に取り組まないと何が起こるのかは明白で同一プラットホームでの戦いにおいて、戦場は既に国内からワールドワイドに拡大してしまっているから自身の技術屋としての存在意義を賭ける戦いといえよう。