例外処理の一般化

投稿日: Nov 09, 2013 1:15:48 AM

エージェントに向かう

コンピュータのシステムを考える際に問題になるのが、利用上のサポートする範囲をどこまでにするかであって、これは文字種から扱う品目から利用者数から…何から何まで制限をつけるとか、言い方を変えるとレギュラーなやり方を決めることになる。昔はコンピュータのハードウェア資源が非常に限られていたので、文字数や数字の桁数も利用最低限を決めなければならなかったからである。これは今日では随分緩和されて、商品名も1行で収まらないくらい相当長いものがつけられる場合もある。著者名にしても昔の日本人名は最大７-9字で収まっていたのが外人のカタカナ表記などで非常に長いものもある。特にWebになってからは、表示が入らないものは強引にちょん切って、クリックすればフル表示するような方法がとれるので、表示幅は気にしなくなったといってもいいだろう。

しかし実際にデータを格納するところでは、どこかでエリアは定義しておかなければならない（可変長であっても）。また外字など解決しない問題もある。食品の材料成分に関しても表示すべき項目がどんどん変化していく場合もある。こういったシステム構築の後でもシステムの制約と抵触しそうな問題というのは多くあり、それはそのシステム外に別のシステムを作って管理とか利用することになる。例えばアレルゲンなどに関する情報は、一般の人には関係ないが、アレルギー体質の人はなるべくチェックしたくなるだろうし、そのために手間をかけなければならなくなる。人名外字の場合も手間が増える。

従来のシステム化の際に切り捨てられたところは、どうしても手間が増えてしまうわけだが、後で作った別システムも手間をかけずにあわせて利用するというような、例えばマッシュアップのような方法が出てきたにもかかわらず、ビジネス分野では意外に浸透していない。記事『宣伝の一人歩きの弊害』では食材の仕入伝票システムに食材のコンテンツ情報を入れるようにすればメニューが適性かどうかを内部でチェックできることを書いたが、従来のビジネス用のシステム設計ではマッシュアップのようなことは考慮していないのが問題である。

GoogleMapは最初からいろんなシステムとの連携で地図上に重ねて表示して使ってもらうことを考えてあったわけで、それは個人のランニングコース管理とか非常にプライベートな利用までも可能にした。だからかつてのシステム屋が悩んだ、少数の人のためにシステム全体の容量を大きくして複雑にしなければならないのか、ということの答えはでているわけで、かつてのどのような例外処理も例外名部分は別に処理しておいて、結果データだけを一般的に使われているシステムとやり取りをすればよい。これを利用者側からみれば、一般的な食品の材料成分表示では納得できない時には、クリックすれば別のアレルゲンとか産地情報を見れるようになる。

こういう背景の情報が充実してくると、今度はアプリの側が利用者の要求に合わせる設定がされて、例えばQRコードで食品の情報をチェックする際には特定アレルゲンが含まれるかどうかチェックするとか、原産地が何々であったらマーキングするなどのカスタマイズがされるようになるだろう。

消費財に関しては、生産・流通過程でこういったサービスが可能になる連携ができつつある。今はトレーサビリティの問題で税関・安全・廃棄/リサイクルなどの個別のテーマがあるが、きっともっと商業寄りの応用も増えていくだろう。ネットでつながってシステム間連携ができるならば、利用者のエージェントという視点でアプリやシステムの見直しが必要になり、従来例外処理として省いていた分野こそが、これからの情報サービスの競争分野になる。

Articles デジタルメディアビジネスの記事 過去記事→Archive