2007 年 09 月 20 日 : ソフトウェアの威力
総務省「モバイルビジネス研究会」の最終報告書案によると、もう数年もすれば、携帯電話も従来の電話機と同様、電気店で購入して自由に携帯電話会社を利用者が選択できるようになるそうだ。
弊社にとっては、携帯電話向けソフトウェア製品を開発しているので、このオープン化のトレンドは大きなチャンスと言えるのかもしれない。
ソフトウェアは、ハードウェアと比較して姿かたちがないので、それ故、捉え難い概念の一つと言えるだろう。
ソフトウェア無くして、ハードウェアの存在価値も決して有り得ないのだが、その目に見えぬ性格が災いしてか余りにも過小評価されている気もする。
それこそがベンチャービジネスとしてのチャンスの要因でもあるのだが ・・・。
ハードウェアの世界では、18 ヶ月毎に半導体の集積度が 2 倍になるというムーアの法則が 2020 年頃には限界を迎えるかもしれないというゴードン・ムーア氏の発言が最近の話題でもある。
けれども、ソフトウェア業界では、それに類似するような法則はいまのところ存在しないのではないかと思うようになった。
半導体に相当するものは、ソフトウェアにおいては、プログラミング言語であったり、ライブラリであったり、フレームワークであったりするのかもしれない。
そういったものが仮に従来より、 2 倍、3 倍以上のパフォーマンスを発揮するとすれば、どんなシナリオができるだろうか？
同じ機能を果たす携帯電話が、 2 分の 1、3 分の 1 以下のハードウェア コスト、サイズで実現できることを意味するのである。
利用者が選ぶのは、性能面以外にデザイン的な要素など、様々な側面があるのも事実である。
しかし、携帯電話メーカーが今後生き残っていくためには、従来のソフトウェアを何倍も上回るソフトウエアテクノロジーの革新なくして有り得ないような気がする。
2007 年 08 月 23 日 : クラシカルなソフトウェア
427 ファイル、テキストだけで 15 メガバイトにも及ぶ大量の HTML ファイル(製品マニュアル)を駆け足で英訳してきたためか、まだまだ改善の余地がたくさんある。スタッフがまず翻訳した英文を推敲につぐ推敲で、文章の洗練化を図る日々が相変わらず続く。
『クラシカルなソフトウェアを創造する』のが、事業の最大の目標であり、目的でもある。
"classic"を辞書で調べてみると、"judged over a period of time to be of the highest quality." とか、"a work of art of established value." などの説明がされているが、そんなイメージのソフトウェアを創り出せるかどうかなのだ。
短期的ではなく長期間に渡って永続的に最高のクオリティを維持し続けるソフトウェアは、どうすれば生み出せるかという問題である。
ベンチャー業界では、時間を金で買うというような発想で、多くの資金を調達し、必要な人と物を集めて短期間で事業計画を達成するという考え方が大勢を占める。
けれども、歴史を振り返れば、何百年にも渡って生き永らえる「クラシカルな芸術作品」が金で創られた話はほとんど聞かない。そんなものを創造するには、何か別次元の座標軸から世界を眺める必要があるのではないだろうか。
些細なことなんだけど、フィーリングがなんとなくでも合わないところがあると、すぐに改善して行く。そんなサイクルを延々と繰り返している。
自己の感性を深く信じて、これまで 5 年以上もの時間をかけて研究開発してきたものの最後の仕上げを成し遂げたいと願う。
2007 年 07 月 26 日 : 世界マーケット向けに BREW C++ フレームワーク 製品出荷開始
本日、SophiaFramework というソフトウェア製品の英語化を完了しプレスリリースを発表した。このソフトウェアの海外対応は、昨年の 10 月からスタートしたので、概ね 10 ヶ月の時間を要したことになる。
リファレンス マニュアルが圧縮形式のファイルで 18 MB もあって、翻訳が専門でない社内スタッフだけで英語化したので大変だった。僕も 1 月以降は翻訳 & 翻訳の日々が続いたが、ようやくこの苦しい仕事からも解放されると思うと、ホッとしている。
世界全体のグローバルマーケットのポテンシャルは、国内のマーケットのそれと比較して 30 倍もある。日本語を英語に翻訳するだけで、マーケットが 30 倍もひろがるのだから、絶対にすべきであると決断して今日まで頑張ってきた。
文章を書くというのは、行間に込められたメッセージが想像以上に大きな意味を持つと考えている。そのためにも、製品の開発やマーケティングに携わるスタッフが翻訳にあたるプロセスが何より肝心に思えた。
［Press Release］
ソフィア・クレイドル、世界マーケット向けに BREW C++ フレームワーク "SophiaFramework" 製品出荷開始
〜 GUI フレームワークと WSDL / SOAP / XML ミドルウェア を含む、世界唯一の BREW 向け C++ ライブラリを海外対応 〜
■概要
携帯電話向けソフト開発の株式会社ソフィア・クレイドル（本社：京都市、代表取締役社長：杉山和徳、以下 ソフィア・クレイドル）は、 2007 年 7 月 26 日から世界マーケット向けに BREW C++ フレームワーク SophiaFramework の製品出荷を開始します。 SophiaFramework は、GUI フレームワークと WSDL / SOAP / XML ミドルウェア を含む、世界唯一の BREW 向け C++ ライブラリであり、携帯電話向けソフトを従来より数分の 1 程度でシンプルにプログラミングできるという点が最大の特長です。
詳細：/news/pressrelease/2007/20070726.html
2007 年 07 月 02 日 : ソフトウェアの進化
DNA はデオキシリボース、リン酸、塩基という物質から構成される。
地球上のすべての生命が持つ DNA の基本的な構成要素はこれだけに過ぎない。DNA を調べるだけで取り違えされないでそれがどんな生物であったのか分るらしい。
それがどんな風にして生まれ、発展したか知る由もない。けれどもそこには想像し得ないほどの長い歴史があって今日へと至った。
コンピューターの世界も、最小単位は 0 と 1 という本当にシンプルな要素から構成される。そんな基本要素からさまざまな用途に応用されている。地球上の生命ほどでないにしても、それは個人的には生命の発展過程に極めて類似しているようにも思えてくる。
果てしなく続く時の流れの中で、数多くの生命が生まれては消えていった。
何故絶滅した生物の種があって、今日まで生き残ったものもあるのか？
いろんな管理などの要因もあるかもしれないが、生命の設計図と言われる DNA がどんな構造していたのかというのが大きな決め手になったようにも思える。
ソフトウェアの歴史はまだまだ浅く、ソフトウェアそのものを一元的に特定する DNA そのものは存在しえない。けれどもソフトウェアというものは、設計して、プログラミングして、完成するものであって、どんなソフトウェアにも設計図は存在する。
生物の種と同じく、個々のソフトウェアも生まれて消えの連続である。
貴重な時間を割いて創ったものだから、願わくば長く生き残ってもらいたいものである。
そんな思いでいつも仕事をしているわけだが、その願いを実現するためのヒントは DNA にあるように思えて仕方ない。
今のところ、様々なソフトウェアを特定するための DNA のようなものは存在しない。
すべてのソフトウェアに共通する設計図に相当するものがないということである。
生物の DNA には何億年にも渡って生存し続けられるほどの情報が記されているが、ソフトウェアにもそれほどのものが存在したときに、きっと変革は現実のものとなるだろう。
2007 年 06 月 29 日 : 毎日が英作文
ひとつ残されたソフトウェア製品を海外マーケットでも利用してもらえるように、今年に入ってから毎日が英作文という日々を過ごしている。
大学受験以来、何年振りのことになるのだろうか。
SophiaFramework という製品のマニュアルを翻訳している( 日本語版・英語版 )。ソフトウェア本体の英語対応は既に完了しているので、残された作業はこれだけ。
日本語版マニュアルのボリュームは zip 圧縮して 18.3 MB ( メガバイト ) もある。このブログもボリュームはあるものの、圧縮せずに 1 MB 強程度。
最初、"翻訳"のプロにお願いしていた。しかしニッチな製品の特性のためか、僕自身が納得できる英文に仕上がってこない。
英文のスタイルは良くても、海外のお客様の心に響くような英文になっていないと感じた。
製品の提供者の思い(想い)を、お客様にダイレクトに伝えるためには、例え素人であったにしても、実際に製品を開発したり、僕よりわかい家族など、当節に即してマーケティングする者が英文にするのが良いと考えた。
80 ％くらいは英訳を終えたように思う。引き続き、残り 20 ％もお客様の心に届く英文を目標に翻訳を頑張りたい。
インターネットの最大のメリットは情報発信した瞬間に、世界と繋がる点にあると思う。その時、海外のお客様にも良い感情をもってもらう事が大切だろう。
2007 年 06 月 26 日 : マルチウィンドウに対応した BREW
『 BREW に関する Google ニュース アラート 』によれば、『 マルチウィンドウに対応した BREW 4.0 』がまもなくリリースされるらしい。
弊社では、2002 年 8 月 1 日に『 ソフィア・クレイドル、BREW 向け GUI フレームワークを開発 』というプレスリリースを発表している。
今から 5 年程前に BREW 上でマルチウィンドウを実現していた。営業活動なるものを一切していないので、実際にご利用いただいているのは一部の先進的なお客様に限られているが、概ね満足していただいているものと思う。
現在は、単なるマルチウィンドウに留まらず、アプリケーションを全体的な視点から展望した上で様々な最適化を施している。
アプリケーションのスピードやメモリ使用量だけでなく、時と共にアプリケーション自体がスムーズに進化できることも含めてである。
2007 年 06 月 21 日 : SAX Parser for BREW
BREW 携帯電話で、Amazon のサイトから XML 文書をネット経由で取得して処理する BREW アプリ（本棚アプリ Books Application ）を公開した。
SAX パーサーを使っているのが最大の特徴である。
BREW 上で SAX パーサーを実現している会社や団体は他に存在しないので、BREW では世界初の SAX アプリかもしれない。
Webサービスでやり取りされる XML 文書を処理を処理するためには、その文書がどんな構造になっているのかを解析する必要がある。
そのためのソフト技術として DOM パーサーと SAX パーサーがある。
DOM パーサーでは、XML 文書を DOM(Document Object Model) という木構造の形式で文書全体をメモリ上に展開して処理する。SAX パーサーでは、SAX(Simple API for XML) という API によって XML 文書を先頭から順番に読み取って処理する。
SAX パーサーの場合、文章を一行一行読んで処理するので、 DOM パーサーに比べるとメモリ消費量がきわめて少ないのがメリットと言える。
実際に、BREW プロファイリング ツール Bleuet de BREW でメモリ消費量について調査した。
その結果分かったのは、解析対象の XML 文書にも依るものの、DOM パーサーで 300 KB 必要だった処理が SAX パーサーでは 3 KB の場合があるということだった。
国内の高機能携帯電話では、300 KB といっても問題にならないサイズかもしれない。けれども、海外のマーケットを見渡せば、300 KB のメモリを持たない携帯電話も多数存在する。
世界全体で考えると、日本のマーケットは 10 ％にも満たない。だからマーケットの大半は、日本の状況とは全く逆であると考えるべきだと思う。
そういう意味において、高機能携帯電話に合わせてソフト技術を研究開発するのではなく、グローバルスタンダードとも言える携帯電話で、利用可能なソフト技術を、シンプルに創造するのがベターではないだろうか。
2007 年 06 月 15 日 : 携帯にもXML
最近、最も力を入れて研究開発しているのは、携帯電話で XML を処理するためのインフラの構築である。
XML とは、異なるシステムやソフトウェア間で情報を交換するためのデータ標準化技術。
世界中に氾濫する膨大な情報が XML で表現され、それらの情報を交換する手順(プロトコル)も XML で記述されるようになった。
企業の情報システムに限らず、Google、Amazon、News、… 様々な情報が、 XML という技術を使ってネットを駆けるようになってきた。
しかしながら、携帯電話からそれらの情報に簡単にアクセスできる術は無きに等しい。
携帯電話でそれが実現できれば、ネットに繋がった情報によって、新しいジャンルのアプリケーションも生じるかもしれない。
そして携帯で XML を実現すれば、ネットに繋がった多種多様なコンピューターを携帯電話から自由自在に操作できる新しい世界がひろがってゆくだろう。
2007 年 05 月 21 日 : ソフトウェア設計
『………このディスク・コントローラ・カードのチップの数は、他の競合製品よりずっと少なくてウォズニアクはその点を「私の生涯でもお気に入りの設計だ」と考えた。………』（『アメリカン・ドリーム』、マイケル・モーリッツ著）
ウォズニアクとは、ジョブズと共にアップル社を創業し、コンピューターの設計をしていた人物である。
アップル社が今日に至るにはいろんな要素があったと思うが、僕は技術的な観点では最少の部品からコンピューターを設計する思想、すなわち抽象化の概念にあったと感じている。
そういった考え方を持ってソフトウェアを設計する人は多くないように思う。それは何故か？
理由は単純である。
目先の売上とか利益を追い求めるからではないだろうか。というのは、ソフトウェアを抽象化して最少のサイズにして設計するには、何回も何回も設計し直して、プログラミングしテストするというサイクルを繰り返さねばならない。
その結果、同じ機能のソフトウェアが他よりも 10 分の 1 のサイズで実現できたりするのだ。
家中に散らばっている家電製品のリモコンが一つに集約されればどれくらい便利だろうか？
ソフトウェアでも同じことが言えると思う。
ソフトウェアを構成する個々のモジュール(部品)が様々なアプリケーションで利用されることで革新が起こるだろう。
僕たちは今、過去 5 年間もの歳月を費やして研究開発してきたソフトウェアの集大成のフェーズに入っている。
ソフトウェアそのものの抽象化を徹底し、革新的にコンパクトでスピーディなものとし、リファレンスマニュアルの推敲の上に推敲を重ね、世界の人々に届けるため、何千ページにも及ぶドキュメント類の英語への翻訳作業に余念はない。
2007 年 01 月 30 日 : バベルの塔でない共通の言語
創業した当初は、スタッフの国籍は全員日本であった。
いまやスタッフの半分は海外の国籍を有する。特に研究開発部に至っては 8 割が海外の人材であり、寧ろ日本人は少数派の部類に相当するようになった。
世界で通用するハイクオリティなソフトウェアをアウトプットする。ただその一点の目標を達成するために行動した結果、自然とそうなったのである。
ゆとり教育が影響しているのか、あるいは日本の中学や高校では、プログラミングについての教育が等閑になっているのか原因は定かでない。
確かに言えるのは、超一流のソフトウェアを世に送り出せる人材は国内だけでは得がたくなったということである。
逆転の発想をするならば、世界から人材を募ればそんな想いの達成される確率はアップするのだろう。
スタッフが操れる言葉は人それぞれ、日本語、中国語、英語、フランス語、ドイツ語、ルーマニア語、ヒンディー語などさまざまである。
オフィスやメールでは多様な言語でコミュニケーションが交わされる。
研究開発部は、大半が国籍が違う者同士でのコミュニケーションなだけに、苦労が偲ばれていたが、意外にもコミュニケーションはうまくいっているようである。
何故なんだろうと思って気付いたのは、唯一お互いに理解し合えている言葉の存在であった。
それは 「C++」 というプログラミング言語である。
「C++」 というプログラミング言語によって記されたコンテンツは理解し得るものであるらしい。
超一流のソフトウェア製品とは、世界中の人々に利用されることを着地点に置いている製品であって、そのために日々ソフトウェアの研究開発に明け暮れている。
それが目指すのは、携帯電話のような情報端末向けのソフトウェアを C++ 言語で表現できるようにする辺りにあることが興味深くもある。
