オルタナティブ・ブログ > 森崎修司の「どうやってはかるの?」 >

計測できそうでできない多くのこと。エンピリカル(実証的)アプローチで。

携帯サイト

»

ちょっと前の話になりますが、番号持ち運び制導入に伴い新機種ラッシュになりました。

端末(電話機)本体をリリースできた携帯電話メーカがほっと胸をなでおろしている間、新機種の大量投入により、携帯電話むけサイトも大きな影響を受けました。

コンテンツだけの携帯電話むけサイトもありますが、サーバサイドにプログラムを含むものが多く、携帯電話に搭載されたブラウザから利用するのが一般的です。標準はあるものの、標準があることと製品や実装がその標準を満たしているかどうか、という部分には(残念ながら)ギャップがあるので、新機種が出るたびに全体の動作確認が必要になります。ほかにも、

  • 携帯電話むけサイト業者は携帯むけ情報提供システムを、手元で改変や更新のコントロールが比較的簡単なサーバ部分と、改変や更新のコントロールが難しいクライアント部分(携帯端末に搭載されたクライアントソフトウェア)の2つで構成されるため、サーバ側がクライアントに合わせて修正することが多い。
  • PCのブラウザを利用したASPと同様の構成だが、PCのブラウザが比較的少ないソフトウェアとバージョンで多くのシェアを占有しているのに対して、携帯電話の場合は(クライアントのコア部分が共有されていたり、サーバサイドにミドルウェアがあるものの)PCよりも組合せが多い。
  • 携帯端末のリリースはバースト性があるのに対してPCにはバースト性は今のところない。

クライアントソフトウェアである携帯電話に搭載されたブラウザは、基本的には携帯メーカ固有のものであるため、携帯電話がリリースされれば、1機種ずつ期待通りの動作となるか検証する必要があるでしょう。クライアント固有の方式や要素を吸収するミドルウェア(機種依存/キャリア依存部分を吸収するようなミドルウェア)が存在するため、開発の全てにおいて、機種/キャリア固有の部分を意識する必要はないのですが、ユーザから費用を直接徴収するサービスとして提供しているような場合、全ての組合せをチェックしておく必要があるでしょう。

検証/テストの計画/管理/実施、検証/テスト結果に基づく修正にはそれなりの工数がかかります。一般的な携帯電話向けサイトの開発体制から考えると、一度に多数の機種がリリースされれば大きな負荷になるでしょう。ページが意図通り表示されているか、ハイパーリンクをクリックしたとき期待通りの動作をするかをはじめとして、サービスの内容によっては、ユーザが送信したテキスト情報などがきちんと受け取れているか、セッション維持のための仕組みが期待通りの動作をするか検証しなければなりません。たとえ、クライアントソフトウェアの実装の問題であったとしても、不具合がみつかれば、サーバソフトウェアで可能な限り対応をすることになるでしょう(クライアントから送信されるクライアントの機種を示す識別子による条件分岐がかなりあるのではないでしょうか)。ある機種から利用できないことは、その機種を利用している顧客を失うことになってしまうからです。

そのような状況なので、携帯サイトのテストを専門とする企業もあります。しかしながら、携帯電話がラッシュでリリースされるとそのテストはたいへんであることにはかわりがないようです。

Comment(0)