日経バイトの囲みを書いてから質問・意見をいただいた。同様な感覚をお持ちの人もいるようだった。爆発する携帯がインセンティブレスな時代になったときにどれだけ安く楽しい端末を提供できるかというのが課題である。ある人は、Javaの組込み機能が改善されるので気にしなくても良いという意見だった。おそらく来年には、Ｊａｖａの速度は改善される時代になりダウンロードアプリ以外でも利用可能な範囲が増えてくるだろう。

携帯業界は、機種展開のスピードアップと競争激化で「何が何だか判らない」というようなのが素直なところだろうか。一つのアーキテクチャにまとめて綺麗にアプリケーションを開発していきたいという思いもいろいろなのだろうが・・・。端末のコストダウンの取組みの中で現在の積算型構築手法での８ＭＢ越えの容量を是としているのは、技術者としては疑問を抱いている人もいるようだというのが、当該記事への意見などからも判りほっとしている。

しかし技術者の流動化は、実際にはかなり発生しているようである。問題意識を持たずに、忙しさに埋没しているタイプＡの技術者や意識を持ち改革に走るというタイプＢの技術者、これ以外のタイプＣが流出している技術者達である。タイプＣの場合には、同業他社や関連の会社に移籍することや、旅行などをしてリフレッシュして自分を見つめるなどの後に考え直したいという人がいるようだ。

さて、懸案のお題にアグレッシブな答えを寄せてくれた人がいた。最近では記事にかかれていたＦＯＲＴＨ自体がＯＯＰの機能を盛り込んで拡張して進化しているらしいのだ。ＦＯＲＴＨといえば旧リギーの片桐さんを思い出す方も居るかもしれないがＧＵＩな環境でローリソースで動作するＢＴＲＯＮなどとの親和性なども追求している人もいるらしい。そう考えてみると、同様なスタックマシンであるＪａｖａコードをＦＯＲＴＨのコードへの変換する事の可能性があるようだ。

ガベージコレクションの問題などが内包されていることは明らかなのだが・・・。こうした取組みを検討してみるといった話を進めるには、またどこかの学校との共同研究でも進めてみることが必要なのだろう。狙うアプリケーションはＯＯＰな作りでＯＬＥではないにしても連携動作の得意なＷＯＲＫＳのような携帯電話としての機能集合である。気が付くとＢＴＲＯＮのようなものを作ってしまう事になるのかも知れないが・・・。

本来こうした研究などをメーカーが進めているべきだと思うのだが、デフレスパイラルがここにも影を落としているようだ。物作りという点でいえば、そのままＯＯＰなＦＯＲＴＨで書き起こしてみるというのが第一段階かもしれない。ＶＬＳＩ開発でＯＯＰ言語を書き起こしていた御仁を知っているが、傑出した人材を多数抱えているメーカーの現在には映し出していないようだ。

技術者という職業をつらい物だとか、夢を語れないものだとか思っている技術者が増えているのではないだろうか。会社としての生産ラインの位置付けになっているのだとすれば確かに不幸な話ではある。大学周りを再開して産学協同の話をまた始めなければならないだろうか。ベンチャーでやりたい人であれば出資の話も含めてやっていけるのかも知れないが。やりたいといって飛び込んでくるような人は、まだ居ないのだが・・・。

アプリケーションのダイエットメニューについて物作りの方法論も、出来の良いソフトウェア構造なども含めて攻めて行くことが必要なのだろう。難しいテーマではあるが取組みのしがいのある仕事でもある。アイデアをまとめてバジェットを押えて日本で進めていくテーマなのだろう。ＦＥＰもメーラも電話ＤＢも一体として絶妙の連携を達成していくことには、アプリケーションデザイナーの感性も問われるテーマでもある。