この連載の趣旨と目次のページへ

jig.jp
代表取締役社長,CEO兼CTO
福野泰介

 私たちは,携帯電話機の上で利用できるWebブラウザである「jigブラウザ」を開発し,2004年10月1日から有料サービスとして提供しています(図1)。jigブラウザは「iアプリ」「EZアプリ」など,携帯電話機にダウンロードして利用するJavaアプリケーションです。私たちは,このようなアプリケーションを「ケータイアプリ」と呼んでいます。


図1 jigブラウザの画面例

 jigブラウザは,パソコン用に作られたWebサイトを,携帯電話機の小さな画面に収まるように表示する“フルブラウザ”と呼ばれるソフトウエアです。「ケータイアプリ」として作られたフルブラウザは,このjigブラウザが最初でした。

 jigブラウザは,2006年1月現在で約3万人の有料利用者がいます。携帯電話の利用者数全体から見れば小さいと思われるかもしれませんが,jigブラウザの利用者の多くはNTTドコモのFOMAで提供される「パケホーダイ」など定額制の料金システムを選択して3G携帯電話機を使い込んでいるヘビー・ユーザーです。彼らの要求に応えて作ったjigブラウザは,将来の携帯電話機によるサービスを先取りした要素を持っていると思っています。

4つのポイント──ニーズ,ケータイの進化,定額制の登場,C/Sアーキテクチャ

 jigブラウザが利用者に支持された背景は何でしょうか。以下の4つの要素があります。

  1. 潜在的な需要。「携帯電話専用サイトでは物足りない。パソコン向けWebサイトを携帯電話機で見たい」という利用者のニーズがありました。
  2. 携帯電話機の高速化・高精細化。jigブラウザが登場した時点で,従来より2ケタ以上高速なデータ通信が可能な3G携帯電話サービスが本格化し,携帯電話機の処理性能も高速化していました。
  3. パケット通信の「定額制」の登場。データ通信機能を,通信料金を気にせず使うことが可能になりました。
  4. jigブラウザがクライアント/サーバ型アーキテクチャを採用すること。ブラウザ機能の一部をサーバ側に持たせることで,通信時間の短縮や,プログラム・サイズの小型化を図っています。

 jigブラウザを提供するタイミングで,これらの各要素のどれか1つが欠けても,成功はなかったと思います。今回の第1回目の記事では,jigブラウザの開発に至るまでに私たちが工夫した点を説明します。

jigブラウザは「道具」を目指した

 iアプリは,汎用的なプログラムを開発できる環境を提供しています。しかしiアプリの公式サイトを見ると,いまだにゲーム・コンテンツばかりが目立ちます。ツールとしてのiアプリの利用はあまり広がっていないのがjigブラウザの開発に着手した当時の状況で,それは今も続いています。

 理由は何でしょうか。iアプリが登場した2001年には,ケータイ自体の処理能力はまだ低く,iアプリのサイズも10Kバイトまでという厳しい制約がありました。さらに,実用的なプログラムを作ろうとすると,サーバ・サイドと連携して動作させる仕組みも必要となります。

 このことは,iアプリの提供者が,携帯電話機という制約の上で動くソフトウエアを開発・販売するソフトウエア・ベンダーとしての役割と,サーバを運用してサービスを提供するサービス事業者という2つの役割を果たさなければいけないことを意味します。パッケージ・ソフトの開発や受託開発を主な業務とするソフトウエア会社では,なかなかサーバの運営やサービスの提供まで手が回りません。ビジネス用のツールとしてのiアプリがまだまだ少ないのは,こうした事情によるものではないかと考えています。

 これに対してjig.jpは「ケータイツール」に挑戦することにしました。受託開発はせずに,ケータイ向けのソフトウエアを作りサービスを提供する会社として立ち上げました。こうした体制の下,便利な機能を盛り込み,道具として使えるソフトウエアの開発を目指しました。

定額制の登場で状況が変わった──「フルブラウザ」前夜

 ではなぜ,ケータイツールの中でもフルブラウザを作ろうと考えたのか。それを説明するには,私たちが2003年9月30日に開始した「jigアプリ」から説明を始める必要があります。jigアプリのビジネスは,予想外に苦戦を強いられました。この打開策を考えたことが,jigブラウザの誕生につながっていくのです。

 jigアプリとは,携帯電話サービス向けWebコンテンツの閲覧に要するパケット通信料を削減するブラウザ・アプリケーションです。サーバでコンテンツを圧縮し,通信する量を減らすことでパケット通信料金を安くし,しかも通信時間を短縮でき,端末側の動作も高速になります。より快適なブラウジング環境を提供できるツールだと考えていました。しかし,思惑とは異なり,利用者になかなか受け入れてもらえない状況が続きました。

 苦戦の原因は,まず「携帯電話用Webサイトの使えなさ」にあるのではないかと考えました。自分自身がそう感じていたからです。人に利用を勧めても「そもそも携帯電話でWebサイトを見ていない」と言われることが多く,反応が薄かったのです。自分の周囲の人たちがパソコン・ユーザーが多いということもあるかもしれませんが,少なくとも自分が使って便利だと思えるアプリケーションを作りたい──そう思いました。

 さらに,2003年の半ばころから「携帯電話サービスにパケット料金の定額制が導入される」という話が聞こえ始めていました。実際に定額サービスが開始されると「jigアプリ」利用者が定額制への加入を理由に退会する動きも目立ってきました。何らかの手を打たねばならない時期でした。

 ここで始めたのが携帯電話向けサイトではなく,パソコン向けWebサイトを閲覧できるフルブラウザの開発です。3G携帯電話の普及により,できるだけ使用量を抑えようとする従量制から,使わないと損になる定額制に移行するユーザーが増加し,それに伴い少々重たいWebサイトであっても閲覧したいという需要が生まれると考えたのです。

 フルブラウザを検討するにあたって前向きの材料になったのは,携帯電話機の性能が急上昇していたことです。携帯電話のコンテンツ・ビジネスの発展と共に,液晶パネルの可視性も向上し,画素数は4倍になり,iアプリの実行速度も登場当時の「503i」と現在主力の「900シリーズ」とで比較すると,計算速度で約100倍以上,描画速度で約10倍以上もの向上が見られます(図2,jig.jpの独自ベンチマークによるテストの結果)。つまり,前述の4つの要素がそろったわけです。


図2 携帯電話機のJava実行性能は4年で100倍以上に向上した

クライアント/サーバ型の仕組みでフルブラウザを実現

 フルブラウザは,携帯電話サービス向けに作られたWebサイトという限られた情報ではなく,一般的なインターネット上のWebサイトの情報をすべて見ることを目的としたブラウザです。調べたいと思ったことを持ち帰らずにその場で調べる。いつもチェックするサイトを,ちょっとした空き時間に確認する。フルブラウザは,「jigアプリ」では成し得なかった利便性を提供するアプリケーションにきっとなるだろうと考えました。私たちは,この着想を得た時点で,早速試作に取りかかりました。

 この時点で心配していたことは「実用に耐える操作性を得られるか」という点です。描画機能を作り,実際に携帯電話機の上でスクロールさせてみてから「これならいける」と安心して開発を進めました。

レンダリング処理をサーバ側に置く

 フルブラウザ開発で一番のポイントは,レンダリング・エンジンと呼ばれるプログラムです。Webページを構成する文字や画像といった各要素の大きさや位置を決めて並べる処理のことです。WebサイトはHTMLを使って表現されていますが,その表記方法にはあいまいな部分が多いという問題があります。規則通りでないHTMLに関しては,あるブラウザではきれいに見えるのに,他のブラウザでは駄目だったりします。パソコン上でのブラウザであってもWebサイト作成者の思いを100%再現することは困難な中で,いかに最善の形に近づけるか。いくつもの実際のサイトを表示しレンダリング・エンジンに修正をかけるという地道な作業を何回も繰り返しながら,現在に至っています。

 次のポイントは,サーバ側に何をやらせて携帯電話機側でどのような処理をするかという切り分けです。まずレンダリングは非常に時間がかかる処理なので,演算能力が高いサーバに置く形を採りました。レンダリング済みのデータから独自のバイナリ形式のデータを生成し,携帯電話機側に送るところまでをサーバ側で処理しています。その後,携帯電話機側のiアプリで画面描画などを行います。つまり,サーバ側の処理と携帯電話機上のiアプリが1セットでブラウザとしての機能を果たすわけです。このサーバとiアプリを分離する仕組みは,以前のjigアプリにおける圧縮の仕組みを拡張する形で開発しました。今までのノウハウや運用実績を活かすことができました。

 クライアント/サーバ型の仕組みを選んだ背景としては,iアプリの仕様上の制約もあります。iアプリが通信できる相手はダウンロード元のサーバに限定されています。フルブラウザではインターネット上の任意のサイトからファイルを取得する機能が必要ですが,この機能はサーバ側に持たせる必要がありました。

jigアプリを拡張,jigブラウザへ

 図3は,jigアプリとjigブラウザの仕組みを図解したものです。両者の構成を見てみましょう。jigブラウザはjigアプリとたいへん似た構造であることが分かると思います。


図3 jigアプリとjigブラウザのアーキテクチャの比較

 もう少し詳しく説明しましょう。まず以前のjigアプリの動作から見ていきます。初めにサーバ側処理は,携帯電話機側から要求のあったWebサイトのHTMLファイルを取得します。そして字句・構文解析を行います。HTML中で指定されている画像ファイル群も,サーバ側で取得します。jigアプリでは,これら1ページに必要な情報を,バイナリ形式のファイル1つにまとめ,圧縮します。これにより,サーバからブラウザに転送する時間を短縮できます。ブラウザ側では,受け取ったバイナリ形式のファイルから,文字情報や画像情報を取り出し,画面表示のため展開していきます。

 図3の右側はjigブラウザの構成です。jigアプリに対して追加した部分は,サーバ側にある「スタイルシート取得」と「レンダリング」の2つの機能です。

「スタイルシート取得」では,CSS(cascading style sheet)を取得します。「レンダリング」では,HTMLファイル,CSS,imgタグなどで指定された画像ファイル群のそれぞれの情報に基づき,文字や画像をレイアウトします。このとき,ターゲットとなる携帯電話機のスクリーン・サイズを意識して,うまく横幅に収まるようにレンダリングします。このように,文字情報や画像情報をどこに配置するかを指定する情報は,サーバ側で作られ,ブラウザに送ります。

 ブラウザ側では,先と同様に,バイナリ形式の1ファイルとして送られてきた情報を展開し,サーバ側でレイアウトされた通りに画面の上に並べていきます。

サーバを持つことのメリット

 このような構成を取ることによるメリットは,通信時間(それにパケット代)の節約と,ブラウザ側の処理の負荷を小さくできることです。一方,サーバ側の負荷は高くなります。

 jigブラウザはサーバ側に多くの機能を持たせる仕組みを採用しましたが,このことによりいくつものメリットが生まれました。レンダリングと圧縮をサーバ側で行うことで,利用者がWebサイトを閲覧するときのレスポンスを高速にできました。また定額制でない利用者にとってはパケット削減効果があります。サーバ上に「お気に入り」を自動バックアップする仕組みがあるのですが,これを利用することで,パソコン上からブラウザを使って「お気に入り」を管理する機能を実現でき,またパソコン用ブラウザ・ソフト「Sleipnir2」との間で「お気に入り」連携を実現しました。

 閲覧できないWebサイトへの対応は,サーバ側で動くソフトウエア側を修正すればよいため,ユーザーに新版のiアプリのダウンロードをお願いすることなく随時行うことができました。一方,携帯電話機で動くブラウザ側(iアプリなどの側)も,バージョンアップ通知機能を使うことで,常に最新版に保つことが可能です。

 一方,サーバ側に多くの機能を持たせることに伴う課題もあります。利用者数が増えると,その分サーバを増強する必要があるのです。私たちは,現在約100台のサーバを運用しています。

初日にサーバがダウン,利用者のニーズを体感

 こうして出来上がったjigブラウザですが,実は当初はあまり多くの人に使ってもらえるとは思っていませんでした。まだ始まったばかりのパケット定額制に入っていて,なおかつパソコン用のWebサイトを携帯電話で見たいと思う人となると,そうは多くはいないだろうと考えていたのです。しかし,発表した当日,アクセス過多による利用障害とダウンロード受付の一時停止が起きてしまいました。サーバ側に機能を持たせたシステム構成の弱点が出てしまった形です。お客様に対して大変申し訳ない事態となってしまいました。それと同時に,利用者の強いニーズを感じました。さらなる利便性の向上と,安定した環境を提供しようと誓った瞬間でもあります。

 その後,利用者に少しでも満足していただこうと機能追加や改善を重ねました。RSSリーダー,パソコン用メール・リーダー機能,タブ・ブラウザ機能などを追加していきました。その結果として,利用者の喜びの声,期待の声,応援などが電子メールで寄せられ,それを励みにさらに改良を重ねるという好循環が生まれたのです。気が付くと,1年で80回ものバージョンアップを行っていました。前述したように,2006年1月で3万人の有料利用者を数え,ユニーク・ダウンロード数は24万6000となっています。

移動中の空き時間にも調べ物ができる

 jigブラウザの主な利用シーンは,まずはパソコンと同様の検索です。しかし,それだけでなく,携帯電話機ならではの部分もあります。例えば,相手先の会社やお店などの場所が分からず迷った場合,検索エンジンで探して,会社案内から地図を見て,それでも分からない場合電話する,といった使い方を考えてみましょう。ショートカット7番でGoogle検索し,お店のページを表示すると,ページ内の電話番号は自動的に識別して電話リンクになります(図4)。クリックひとつで電話をかけることができます。


図4 Google検索結果から電話をかける様子

 ほかにも友人との会話で話題になった有名人の顔が思い出せない場合のイメージ検索や,ニュース,乗換情報,地図,天気,株価,ブログ,気になった情報はその場でチェックし時間を有効活用するといったニーズもあるでしょう。

 ここに挙げた利用シーンにとどまらず,利用者それぞれ様々な使い方をしていただいています。その中で発生した不満や要望を送っていただき,対応する。こうして利用者の方と共に育ててきたのがjigブラウザです。ほんの少しの時間でもさっと取り出して使える携帯電話機だからこそ,利用者の方々はちょっとした利便性を非常に重視します。

 しかし,この利便性の改善を進めようとしたとき,ある問題が生じました。第2回では,遭遇した問題と,それを克服した「jigブラウザ2β」に関して説明します