2005 年 11 月 25 日 : 携帯 Java と BREW の独自開発ノウハウをソースコード付きで無償公開
[PRESS RELEASE]
ソフィア・クレイドル、携帯 Java と BREW の独自開発ノウハウをソースコード付きで無償公開
−携帯JavaからBREWへの移植、C++によるBREWアプリ開発、BREW での浮動小数点演算など−
[概要]
携帯電話向けソフト開発の株式会社ソフィア・クレイドル（本社：京都市、代表取締役社長：杉山和徳、以下 ソフィア・クレイドル） は、2005年11月 25 日より同社サイトにて携帯Java【※1】とBREW【※2】に関する情報サイト ”Tech Cradle” の運営を開始します。”Tech Cradle” では携帯 JavaアプリのBREWへの移植方法、 C++【※3】によるBREWアプリ開発、BREW での浮動小数点演算など、これまで公開されることがなかった、携帯ソフト開発ノウハウがソースコード付きで無償提供されます。
[詳細]
FeliCa、地上デジタル放送、デジタルオーディオプレイヤーなど携帯電話の利用シーンの幅が広がっています。携帯ソフト開発には、大規模・複雑化やサイズ制限など携帯ソフト特有のさまざまな問題があり、実際の経験などに基づくノウハウが不可欠です。しかし実践的なノウハウがインターネット上に公開されることはほとんどありません。
2005年11月25日、ソフィア・クレイドルは同社サイトで運営中のデベロッパページを ”Tech Cradle” （テック・クレイドル）としてリニューアルし、これまでインターネット上で公開されることが無かった、携帯ソフト開発に関する、実践的な独自ノウハウをソースコードも含めて無償公開します。
公開されるのは、
［ 1 ］携帯 JavaアプリをBREWに移植する方法：
携帯 Java とBREW の違い、移植時の注意点を含め移植方法を解説
［ 2 ］C++を用いたBREW開発のポイント：
BREW C++ プログラミングの解説と、文字列クラス/ヒープクラス実装などの実践的テクニック
［ 3 ］BREW での浮動小数点演算の使用方法：
BREW の仕様範囲外である浮動小数点演算を扱う方法
などの実践的なノウハウです。また、BREW 3.1 を中心にBREW FAQも加筆されました。
ソフィア・クレイドルでは、今後も掲載記事の充実をはかり、携帯ソフト開発者コミュニティーに貢献していく計画です。
“Tech Cradle” のURL: リンク
本プレスリリースURL : リンク
以上
■用語説明
【※1】携帯 Java
サンマイクロシステムズ社のプログラミング言語環境 ”Java” のひとつで、携帯電話で動作するJava。 Java言語で作成したアプリケーション (Javaアプリ) が実行できる環境が搭載されており、Javaアプリを携帯電話にダウンロードして利用する。携帯電話のハードウェア的な制約で、通常、携帯Javaのプログラムにはサイズ制約がある。2001年1月、NTTドコモが「iアプリ」という名称で携帯Javaアプリのサービスを世界で初めて開始した。現在、欧米、アジアなど世界中で携帯Javaアプリのサービスが広がっている。
【※2】BREW
読み方：「ブリュー」または「ブルー」
2001年1月に米国クアルコム社が発表した携帯電話向けソフトウェアの規格。「ブリュー」もしくは「ブルー」と読む。異なる携帯電話機のOSの仕様差を吸収し、単一のコンパイル後のプログラムをインターネットからダウンロードし、さまざまな携帯電話機でそのまま高速に動作できるように設計されている。日本ではKDDIが2003年2月よりBREWサービスを提供開始。NTT ドコモの一部の機種でBREWが採用されている。2005年11月現在、世界で29ヶ国56 の通信キャリアが採用しており、世界的な規模でその普及が急速に進んでいる。
【※3】C++
読み方：「シープラスプラス」または「シープラプラ」
再利用可能なモジュールを組み合わせてプログラミングする、オブジェクト指向アプローチの観点からC言語を拡張したプログラミング言語。モジュール性と再利用性の観点から、C++ によってプログラムの開発生産性が向上するに止まらず、保守性にも優れるというメリットがある。プログラムのスピードが遅くなり、サイズも大きくなるという点をデメリットとして挙げることができる。
■ 会社の説明
株式会社ソフィア・クレイドル
代表者： 代表取締役社長 杉山和徳
設立日： 2002 年 2 月 22 日
所在地： 京都市左京区田中関田町 2 番地 7
資本金： 2645 万円
事業内容： モバイルインターネットに関する：
1.ソフトウェア基礎技術の研究開発
2.ソフトウェア製品の製造及び販売
3.システム企画及びインテグレーション
ホームページ： リンク
2005 年 11 月 25 日 : ソフトウェアの進化
ソフトウェアとハードウェアの間には隔たりがある。
ハードウェアと違い、ソフトウェアは完成した後もメインテナンスすることで時々刻々と変化する。
要するにソフトウェアとは進化する概念なのだ。
ソフトウェア企業の明暗を分かつポイントは、これについての認識の差によるのではないかと思うほどである。
ソフトウェアの売れ方で特徴的なのは、ジャンルごとに売れるソフトウェアが決まっていて、一極集中型であることに尽きる。OS も、データーベースも、メーラーも、ブラウザも・・・すべてのソフトウェアについて実際に世界で使われているものは 3 種類以内に限られる。
では、利用者は何を持ってそれを選択しているのだろうか？
勿論、"クオリティ"である。
"クオリティ"とは、機能、スピード、使いやすさ、ルック＆フィール・・・、それらを総合したものである。
ソフトウェアは時を経て進化できる。
それでは、どうすればソフトウェアのクオリティを、自ずと高まるように進化するのかを洞察すれば良いだろう。ソフトウェアのクオリティは、メインテナンスのフェーズで、プログラムコードが綺麗なものに書き換えられることによって飛躍するのである。
多くの組織では、製品を研究開発する者とメインテナンスする者が別であることが多い。
その傾向は大企業ほど顕著である。
「プログラマーの仕事」でも述べたが、ソフィア・クレイドルでは製品を研究開発する者とメインテナンスする者は同一人物。
製品の設計思想を初め、隅から隅までよく理解している者がメインテナンスするので、何処をどう直せば良いかのプロセスがスピーディであり適切だ。
しかも製品への愛着もある。製品の産みの親でない者がメインテナンスするのとでは雲泥の差が出てくるものである。
超一流の作品を創造するには、メインテナンスという泥臭い仕事も喜んで引き受けるくらいの心意気というものが求められる。
ソフトウェアというものは、メインテナンスを経て洗練されてゆくというのは事実である。
2005 年 11 月 24 日 : プログラマーの仕事
ソフィア・クレイドルのプログラマーは、製品の企画、デザイン、プログラミング、テスト、ドキュメンテーション(含む Web 制作)、メインテナンスまで幅広く業務を担当する。単にプログラミングだけをしているわけではないのだ。
大きな組織では、それぞれの業務ごとに担当者が決められていて、プロジェクトチームとして運営される場合が多い。
何故そんな運営方法を採るのか？という疑問を抱かれるかもしれない。
その答えは、単により早くよりクオリティの高い製品をお客様にお届けしたいからという点に尽きる。
例えば、システムの設計をする人( A )とプログラミングする人( B )が異なる場合を想定してみてほしい。A と B の間に必ず何らかのコミュニケーションが発生するはずである。
何故なら、少なくとも A から B へシステム設計に関する情報を伝達しなければ、B はプログラミングに着手できないから。
実は、この時の A から B への情報伝達が"スピード"と"クオリティ"に重大な影響を及ぼすのである。
大抵の場合、設計書と称される詳細なドキュメントによって情報伝達がなされる。ドキュメント作成が大変な作業で不要なオーバーヘッドとなる。A と B が同一人物であるのならば、詳細なドキュメントではなく覚書程度で十分。
しかも A が設計情報を間違いの無い完璧にドキュメントとしてまとめるのは不可能と言っても良い。どこか情報が欠落していたり、間違いがあったりするのが常である。これが原因で不具合が発生したり、後戻りの作業が多発するのである。
いわゆる、伝言ゲームである。
この時、A と B が同一人物ならそのような問題は発生しない。
どんな仕事でもそうかもしれない。システム開発では予期せぬ仕様変更は日常茶飯事。大きな組織では柔軟に仕様を変えながら開発するのは極めて困難である。
アナリスト、システムエンジニア、プログラマー ・・・ と職種を分けてプロジェクトを運営するよりもすべての業務を同一人物が担当する方が、スピードとクオリティという観点からは大幅に改善がなされる。(テストだけは他の人が担当することで効果がでる場合が多い。プログラマーの想定外のケースでテストを行えるからである。)
ベンチャーの最大の強さは、圧倒的な"スピード"と"クオリティ"である。
"スピード"と"クオリティ"は開発のプロセスにおいても徹底追求すべきであり、創意工夫の余地は至るところにある。
2005 年 11 月 23 日 : Ajaxと Blog
AJAX という技術を使えば、ユーザーインターフェイスを中心とした BLOG の革新が起こりそうだ。
数え切れないほど、さまざまなベンチャーが BLOG を提供している。" WEB 2.0 "なんていうキーワードが巷では囁かれたりするけれど、デファクトスタンダードになる Next BLOG は、テクノロジーの観点では AJAX が最大のキーになるだろう。
AJAX とは Asynchronous JavaScript + XML という言葉の略である。
難しそうな言葉の響きがそこにはある。
でも具体的にイメージするには、Zimbra 社のサイトにいってデモを体験するのが一番。
未来への扉を開けてくれる。
新しい発想が閃く。
それから洞察できる未来は、BLOG の編集もマイクロソフトの Word のような感じになるだろうということ。
- 広い編集ウィンドウの上に WYSIWYG で直感的に文章を書ける
- いちいち"確認ボタン"を押さなくてもサーバーに途中の文章が保存される
- スペルや文法、"て・に・を・は"のチェックをしてくれる
- 辞書が参照できる
- " UNDO(アンドゥー：元に戻す) "ができる
- 文字列の検索や一括変換ができる
- エトセトラ
ワープロソフトのソフトテクノロジーを持つマイクロソフトに有利なはずではあるけれど世界は広い。Zimbra 社みたいなベンチャーが出てくるかもしれない。
AJAX による BLOG のユーザーインターフェイスの革新が待ち遠しい。
続きを読む "Ajaxと Blog" »
2005 年 11 月 23 日 : 未来への架け橋
ソフィア・クレイドルはベーシックなことを大切にし、それをビジネスにする会社。
何故ならベーシックなことには"永続"という性質が付随するから。
会社が永くその名を残すための基本的な原理原則でもある。
事業運営の根本的な思想はそんなところに置いている。
では、変化の激しい IT 業界にあって、何十年、何百年にも渡って存続し続けるものはあるのだろうか？という問いかけが自然な発想だろう。
例えば、100 年後の日常生活を想像してほしい。
過去に存在し得なかった、全く新しい言語で会話をしている姿は想像しにくいのではないだろうか。おそらく、日本語としての純正さを持ちながらも、未来風に多少アレンジの掛かった日本語で会話をしているはずである。
タイムマシンがあったとして 100 年後の未来に旅立つとする。
辿り着いた先が日本であれば、きっと日本語で未来の人びとと意思相通できるだろう。
現に、何百年、何千年も前の古典を読んでも理解できる。
そういう発想で IT 業界を眺めて事業戦略を練り、その通り遂行すれば良い。
浮き沈みの激しい世界の中でも、磐石な基盤を持つ企業として永続できるに違いないと思う。
コンピューターと人びとを繋げるものは、人と人を繋げるものと同じで"言語"である。コンピューター用語で"プログラミング言語"と呼ばれるものである。
最近の"プログラミング言語"は、人びとが会話で使う日本語や英語などと同じく、語彙や構文を増やすことで進化する仕組みが備わっている。
ベースになるものがあり、未来の風に乗って、そこから臨機応変に進化を遂げる。
日本語や英語のような自然言語に近いものを直感して、研究開発事業の根幹を、何十年、何百年も存続できる"プログラミング言語"に関わる内容に集中特化している。
2005 年 11 月 20 日 : 好きなことをするためには
自らの才能を活かして、得意なこと、好きなことに集中して一生を過ごせれば、人生は素晴らしく充実したものとなるだろう。でも資産家でもなければ生きていくためには収入が必要だ。
理想とするビジネスは、スタッフの才能が潜在能力も含めてフルに活きるという形態である。スタッフが会社で過ごす時間を有意義に思い、安心して生活できる財産を築けるようにすることは、社長のスタッフへの大きな責任と思う。
そのために売上を極大化し経費を極小化する。利益を最大にするビジネスモデルを創らなければならない。儲かるビジネスモデルを創るには少しは考えないといけない。楽して儲かるビジネスはその辺に転がってない。
ソフトウェアビジネスには、受託開発型と製品開発型という 2 つのビジネスの形態があって、それぞれに一長一短がある。(ソフィア・クレイドルのビジネスは製品開発型)
受託開発型ビジネスでは、顧客の仕様に合わせてソフトウェアを開発し納品して収益を得る。
利益が見込める案件を受注できれば経営は安定する。事業を拡大するためには多くの案件を処理する必要がある。人手と設備がそれに比例して増えてくる。製品開発と比較して、受託案件には創造性や独創性が要求される割合が低い。
開発したソフトウェアの特許や著作権などの知的所有権は顧客に帰属する。それらをストックしてビジネスを効率化する手法がとりにくい。
製品開発型ビジネスでは、自社のオリジナル製品であるソフトウェアを開発し顧客に販売して収益を得る。
自ら製品仕様を決め、開発計画を立案し、創造力と独創力を頼りにしてアウトプットする。そこに仕事に対する生き甲斐を見出せる。ソフトウェアは、一度開発すれば、全く同じものをインターネットで世界の人びとに何度も繰り返し販売できる。やり方次第では、事業拡大するのに人や設備を増やさずに儲かるビジネスに繋がる。
製品開発型ビジネスの場合、次の式が成立する。
利益 ＝ 製品単価 × 販売本数 − 経費
ソフトウェアの場合、製品が完成するまではたくさんの研究開発費用がかかる。一旦完成して販売するとなると、仕入れは発生せず、人手も販売本数に比例して必要という訳でもない。経費は固定である。
ソフトウェアをネット配信すれば、製品を記録するメディアも運送も不要。販売本数を増やすことで、損益分岐点を越えた時点から利益は果てしなく伸びゆく。
しかし、製品開発型ビジネスは、音楽や映画などのビジネスと同じで駄作であれば売れない。たとえ素晴らしい作品であったとしても、売り方が悪ければ売れない。
ほとんどのソフトウェアは失敗作である。世の中には販売本数ゼロという製品がところ狭しと転がっている。成功する確率が極めて低いビジネスである。それはミュージシャン志望の人が成功するのと同様なのである。
製品が売れる原因や理由を慎重に検証してからでないと、手痛いしっぺ返しを食らってしまう。
製品を研究開発するために投資したとしても、製品が売れなければ資金を回収することはできない。何も考えずにするのは無謀な賭けというもの。ベンチャーは資金が限られている。売れなければ倒産である。売れる要因を作ってから製品開発に入るべきだろう。
それで重要なことは次の 3 つ。
- 製品ジャンルの将来性
- 売れる製品を創れる才能
- 製品の売り方
ニーズがなければ創っても製品は売れないし、売れる製品でも欠陥があれば売れない。イメージで買われてゆく製品も多い。
好きなことをするためには、何はともあれ、売れるように製品をうまくプロデュースしなければならないのである。
2005 年 11 月 18 日 : スクイーク
"スクイーク"をご存知だろうか？
20 年前、日常生活でパソコンを利用する人は稀有な存在だった。現在では逆にパソコンを使わない人の方が珍しい。パソコンなくして現代の高度情報化社会における快適な生活シーンは想像できないほどでもある。
しかし自分で思う通りにアイデアをプログラミングして、パソコンを自由自在に操れる天才プログラマーは例外的な存在と言えよう。パソコンはプログラムによって制御されるのだから、普通の人でもプログラミングできれば何かが起こりそうだ。
"スクイーク"があれば、コンピューターの動作原理を知らない小学生でも自由自在にコンピューターがコントロールできてしまう。"スクイーク"とはコンピューターの素人でもプログラミングができるプラットフォームなのだ。
「誰もが自動車を運転して何処でも行けるように、小学生でも無意識のうちにプログラミングできてコンピューターを自由に操れるとしたら」という発想から新しいビジネスは生まれる。
ソフィア・クレイドルの究極の目標地点はそんなところにあると考えている。
宣伝も営業もしない Google という 1998 年に生まれたばかりの新興ベンチャーが、何故あれほどまでの利益率で巨額の売上と利益をあげているのか？
その答えに新しいビジネスチャンスを誰もが見出せる。
数十円からの予算で小学生でも広告が出せる。塵も積もれば山となるという言葉がある。小さな量でも"−∞〜＋∞"のすべての範囲で積分すれば天文学的な数字に積み上がる世界が新しい現実なのだ。
ソフトウェア業界にそれを置き換えて考えてみると・・・。誰もが自分のアイデアを簡単に自由自在にプログラミングできるプラットフォームがあって、そのプログラムを数十円の価格で世界中の人びとにネット配信できるとすれば、その時どんな未来が僕たちを待ち構えているのだろうか。
パソコンに止まらず、携帯電話、自動車、テレビ・・・様々な機器が見方を変えればコンピューターでもある。ソフトウェアのマーケットは計り知れないほどの規模で急拡大することが想像できるだろう。
その時、最大のビジネスチャンスは、小学生でも簡単にプログラミングできて、そのソフトをただ同然の安い値段で世界のあらゆる人びとが利用できるプラットフォームである。
