事故の無い交差点→ロバストなシステムを目指して

本当のラウンドアバウト（交差点）の運転は、最初は非常に難しいらしい（人伝の話ですが）です。なかなか入れない、下手をすればグルグル回ったり、違うところへ出ちゃったり…経験が無くても想像はつきます。

最悪、事故になることもあります。

[youtube=http://www.youtube.com/watch?v=Jesf4xFOg1Q]

でも、コンテンツ変換エンジンである製品では、事故はどうしても防がなければなりません。これが「ロバストなシステムを目指す」の意味するところです。

携帯サイト開発・運営では事故が日常茶飯事です。事故が多ければ、安全運転が必要になり、たくさんのルールができます。ルールはできても守れなければ意味がありません。そして、携帯サイト開発では、このルールが複雑すぎて守れる人が少なく、これが大きな問題です。

ラウンドアバウトのアプローチはルールの強化ではありません。むしろ、ルールの撤廃です。ルールが必要なのは、ある制約が存在しているためにそれを回避する術です。であれば、その制約自体を消してしまえばルールも要らず（もしくは一般的なルールだけで）、事故は起きません。ラウンドアバウトを使えばコンテンツが例えどんなものであっても、事故を引き起こすことがないように、作られています。壊れずに動き続けるというロバストネスという特性がラウンドアバウトの大きな特長です。では、具体的にどのようなものを指しているのか挙げていきます。

■コンテンツのHTMLが自由で、相互変換＆混合変換、何が入力されても良い
ラウンドアバウトは入力となる基準の言語を特定していません。docomo/au/softbank端末のどのXHTMLでもOKであり、chtmlでもOK、PC用のXHTMLでも大丈夫です。しかも、FOMA905用XHTML内で存在しないmarqueeタグを使ったり、言語体系を混合することも大丈夫です。これはなぜか？

実はラウンドアバウトの変換処理は、HTMLだろうが、TEXTだろうが、何を通しても解析エラーを起こすことがありません。更に言えばバイナリーデータを通過させてもエラーは起きない構造になっています。これはどんな入力をされても壊れてはいけない、常に出来る限りの変換をすべきだ、というロバストネスな考え方に基づいているためです。

■画像をいくつ載せても容量エラーにならない

おそらく端末ブラウザーキャッシュの問題はアプリケーションにとって最大の問題であり、画像制作のレギュレーションが非常に厳しく、多くのミスが起きる作業です。ラウンドアバウトでは、どんなに画像を載せてもアクセスしてきた端末の容量に応じてサイズ調整するので、画像容量については全く考慮する必要がありません。

特質すべきは、1ページ中に乗っている全て複数の画像それぞれのサイズを調整してページ全体で決して容量オーバーにならないようにすることです。これもまた、制約の撤廃によるロバストネスの実現の為の機能です。

■全ての画像を画面サイズ比率に合わせて連動変換し、デザインの崩れを起こさない

これまでは画面サイズの違いによるデザインの崩れを防ぐために、画像を並べたりして使用することはしませんでした。つまり、デザインの制約が存在したのです。ラウンドアバウトでは画像の使い方でデザインの崩れは起こしません。これも制約の撤廃と言えます。

この他、絵文字相互＆混合変換や非対応端末リダイレクト設定など、細かい仕様や機能の多くは、「止まらない・事故が起きない」というロバストネスの獲得の為に役立っています。

リアルなラウンドアバウトでは事故は起きてしまいますが、変換エンジンであるラウンドアバウトは事故の無いシステムを実現している極めて安全性の高いシステムなのです。