私的環境における検証作業
メーカーやキャリアにとって未知のバグが、ユーザーから報告される事がどういう意味を持つのかは今でも分かりませんが、しかし今にして思えば、これが無用な刺激を与えたのかもしれません。
今なら少しは分かりますが、V401Tは2006年当時で既に登場から２年が経過していたモデル。市場出荷まもなくならともかく、今更報告された所で迷惑千万以外の何物でもない。
ユーザーへの発表。場合によっては回収＆修理。もしくはそれに変わる機種変更などの措置。それらに掛かる費用などを考えると割りの合う話じゃない。
キャリアやメーカーの本音は「みんな黙っときゃ誰にも分からなかったのに、余計なことをするなよ」だったんじゃないかなぁ？？
しかし当時の私にそんな事を知る由も無く。未知のバグを発見した事で、ガキのように有頂天になっとりましたわ（笑）。その上更に、メーカーに有益な情報をあげようと、嬉々として独自に調査をしてみました。
とは言っても、専用の計測機器があるわけでもない単なる一ユーザーですから、大した事ができるわけもありません。
ただ、私は仕事柄ケータイwebサイトの構造はある程度知っているつもり。そこで簡単なwebサイトを立ち上げて、文字入力が成功するときと失敗するときのwebアプリ側のログとか、流れてくるパケットの違いを調べてみました。
その結果分かったことは二つ。
・一つは、字数が同じでも文字数チェックに掛かる場合とそうでない場合がある。
「%」や「#」など、いわゆる特殊文字の時に起こる傾向が強い。
※例
「1234567890123456789012345678901234567890」
字数は40/40・・・チェックに掛からない
「123456789012345678901234567890123456789#」
字数は40/40・・・チェックに掛かる
・もう一つは（※こっちのほうが重要かもしれませんが）
文字数チェックに掛かる場合は、webサイト側に一切パケットが流れてこない。
まがいなりにもパケットがwebサーバに届いていれば、サーバ側の事情も考えられます。しかし、パケットが一切やって来てないと言う事は、携帯側だけの事情と言う事になる。そういやそもそものキッカケとなった証券会社へログインするためのライセンスキーは特殊文字がよっけ含まれとったなぁ・・・。だから制限文字数以内でもオーバーと計算されたのか。やはり「サイト側に問題はないし、他のユーザーからもクレームはないよ」と言う証券会社側の言い分は正しかったのだ。
ここまで分かってしまえば事象再現は簡単。要は文字入力を発生させ、特定文字列を含んだ制限文字数ギリギリの入力を行なえばいいわけだ。
ボーダのポータルサイトで仮説の通り行なうとアッサリ再現。どうやって個人情報を漏らさずにキャリア・メーカーに事象再現方法を伝えようかとあんだけ悩んでいたのがバカらしくなる（笑）。
まあとにかくこれで障害原因が携帯電話にある事がハッキリした。
いや、正確には携帯電話「側」と言うべきか？
これは一般論ですが、通常、携帯電話がwebサイトとやり取りする際には、一旦キャリアのゲートウェイが収容し、ゲートウェイとサイト間で通信が行なわれる構造になっている。
◎メチャメチャ簡単なイメージ図（笑）
文字数チェック機構が誤作動して通信が行なえない場合はサイトまでパケットがやってこないのだから、この時点での被疑箇所から外せるのはサーバのみ。残る携帯電話〜キャリアのゲートウェイ間全てが残された被擬箇所と言う事です。
しかしエラーが瞬時に返ってくる事から考えても、おそらくは携帯端末固有の問題だろうとは思う。まあここから先はメーカーの東芝とキャリアのボーダで調査してもらう事でしょう。
この間のパケットの流れはキャリア施設内だし、ケータイから最寄りの収容局までの電波は暗号化されているので解析は不可能。
この辺りが一ユーザーとしては限界かな？
以上の調査内容を報告書にまとめて、修理から上がってきた時にでも渡す準備をしておいた。おそらくケータイ固有の問題だとすれば事象が直るはずは無い。だからそう遠くないうちに泣き入れの連絡が来るだろうから、その時にでも渡してあげようと思ったのだ。
まあ障害内容が内容だからすんなりとは行かないだろうけど、事象を100%再現できるなら必ず原因は掴めるはずだ。
あ、これは私の職務上の経験からくる信念なんですけどね。
私の本職はネットワークの障害対応です。
事象発生時のデータさえ取得できれば後は解析さえ行えばよく、時間は掛かっても何らかの結論には辿り着ける。
一番イヤなのは何時起きるか分からない、データを取りたくても取れないようなケースであり、こういうのが一番タチが悪い。また、そういうのに限ってエンドユーザが何とかしろとうるさいんだ。これが（笑）。
まあそんなわけで、事象を100%再現する方法を見つけたのは結構収穫だと思った。これを解析すれば何らかの糸口を見つける事ができる筈だから、あとはメーカーの奮闘に任せたい。
しかし後日、そんな私の期待をよそに驚きの知らせがやってくる事になる。
（次回へ続く）
ランキング参加しています。宜しければ下記↓のクリックをお願いします。
人気ブログランキングへ
今なら少しは分かりますが、V401Tは2006年当時で既に登場から２年が経過していたモデル。市場出荷まもなくならともかく、今更報告された所で迷惑千万以外の何物でもない。
ユーザーへの発表。場合によっては回収＆修理。もしくはそれに変わる機種変更などの措置。それらに掛かる費用などを考えると割りの合う話じゃない。
キャリアやメーカーの本音は「みんな黙っときゃ誰にも分からなかったのに、余計なことをするなよ」だったんじゃないかなぁ？？
しかし当時の私にそんな事を知る由も無く。未知のバグを発見した事で、ガキのように有頂天になっとりましたわ（笑）。その上更に、メーカーに有益な情報をあげようと、嬉々として独自に調査をしてみました。
とは言っても、専用の計測機器があるわけでもない単なる一ユーザーですから、大した事ができるわけもありません。
ただ、私は仕事柄ケータイwebサイトの構造はある程度知っているつもり。そこで簡単なwebサイトを立ち上げて、文字入力が成功するときと失敗するときのwebアプリ側のログとか、流れてくるパケットの違いを調べてみました。
その結果分かったことは二つ。
・一つは、字数が同じでも文字数チェックに掛かる場合とそうでない場合がある。
「%」や「#」など、いわゆる特殊文字の時に起こる傾向が強い。
※例
「1234567890123456789012345678901234567890」
字数は40/40・・・チェックに掛からない
「123456789012345678901234567890123456789#」
字数は40/40・・・チェックに掛かる
・もう一つは（※こっちのほうが重要かもしれませんが）
文字数チェックに掛かる場合は、webサイト側に一切パケットが流れてこない。
まがいなりにもパケットがwebサーバに届いていれば、サーバ側の事情も考えられます。しかし、パケットが一切やって来てないと言う事は、携帯側だけの事情と言う事になる。そういやそもそものキッカケとなった証券会社へログインするためのライセンスキーは特殊文字がよっけ含まれとったなぁ・・・。だから制限文字数以内でもオーバーと計算されたのか。やはり「サイト側に問題はないし、他のユーザーからもクレームはないよ」と言う証券会社側の言い分は正しかったのだ。
ここまで分かってしまえば事象再現は簡単。要は文字入力を発生させ、特定文字列を含んだ制限文字数ギリギリの入力を行なえばいいわけだ。
ボーダのポータルサイトで仮説の通り行なうとアッサリ再現。どうやって個人情報を漏らさずにキャリア・メーカーに事象再現方法を伝えようかとあんだけ悩んでいたのがバカらしくなる（笑）。
まあとにかくこれで障害原因が携帯電話にある事がハッキリした。
いや、正確には携帯電話「側」と言うべきか？
これは一般論ですが、通常、携帯電話がwebサイトとやり取りする際には、一旦キャリアのゲートウェイが収容し、ゲートウェイとサイト間で通信が行なわれる構造になっている。
◎メチャメチャ簡単なイメージ図（笑）
文字数チェック機構が誤作動して通信が行なえない場合はサイトまでパケットがやってこないのだから、この時点での被疑箇所から外せるのはサーバのみ。残る携帯電話〜キャリアのゲートウェイ間全てが残された被擬箇所と言う事です。
しかしエラーが瞬時に返ってくる事から考えても、おそらくは携帯端末固有の問題だろうとは思う。まあここから先はメーカーの東芝とキャリアのボーダで調査してもらう事でしょう。
この間のパケットの流れはキャリア施設内だし、ケータイから最寄りの収容局までの電波は暗号化されているので解析は不可能。
この辺りが一ユーザーとしては限界かな？
以上の調査内容を報告書にまとめて、修理から上がってきた時にでも渡す準備をしておいた。おそらくケータイ固有の問題だとすれば事象が直るはずは無い。だからそう遠くないうちに泣き入れの連絡が来るだろうから、その時にでも渡してあげようと思ったのだ。
まあ障害内容が内容だからすんなりとは行かないだろうけど、事象を100%再現できるなら必ず原因は掴めるはずだ。
あ、これは私の職務上の経験からくる信念なんですけどね。
私の本職はネットワークの障害対応です。
事象発生時のデータさえ取得できれば後は解析さえ行えばよく、時間は掛かっても何らかの結論には辿り着ける。
一番イヤなのは何時起きるか分からない、データを取りたくても取れないようなケースであり、こういうのが一番タチが悪い。また、そういうのに限ってエンドユーザが何とかしろとうるさいんだ。これが（笑）。
まあそんなわけで、事象を100%再現する方法を見つけたのは結構収穫だと思った。これを解析すれば何らかの糸口を見つける事ができる筈だから、あとはメーカーの奮闘に任せたい。
しかし後日、そんな私の期待をよそに驚きの知らせがやってくる事になる。
（次回へ続く）
ランキング参加しています。宜しければ下記↓のクリックをお願いします。
人気ブログランキングへ
コメント
コメントの投稿
トラックバック
http://voudaphone.dtiblog.com/tb.php/39-e2dbeab1
