第25回コラム
「不可視性とアーキテクチャ」
情報アーキテクチャ専攻 教授 南波幸雄
銀行や郵便局に行くと、顧客が待合スペースにあふれていて、用がすむまでに数10分かかることがよくある。顧客は整理券をもらい、開いている窓口の数と待っている人の数とを考え、自分の持ち時間内に何とかなりそうな場合は仕方なく待っている。人気のあるゲームソフトや機器の販売において、初期の生産終了が需要に間に合わないため、発売数量が制限されることがある。そのようなときには是非ほしい顧客は、徹夜して並んで待つのもいとわない。
これがeビジネスの場合は、様子が全く異なってくる。数に限りのある人気商品をネットで売ったりすると、販売開始と同時に顧客が一斉にアクセスする。そのため販売システムの負荷が急増してキャパシティの上限に近づいてくると、処理効率の低下を招いたり場合によってはサーバーがダウンするような事態に結びつくこともある。このような場合システムの運営者は、対応が悪いと顧客の非難の的になる。
筆者は大学に来る前に、オンライン証券会社に勤務していた。証券会社の場合も、対面販売や電話による注文は、基本的に人間対応のため、注文受付に多少の時間がかかってもさほど非難の対象にはならない。しかしオンラインの場合は、事情は全く異なってくる。そもそもログインできないのは論外で、注文処理に数10秒遅れが出るだけで、顧客からお叱りを受ける場合もある。
通常このような状況は、対象の不可視性で説明することが多い。リアルの世界のものは目に見える。何人待っているかは、一寸見ればすぐに分かる。しかしインターネットの向こう側にあるバーチャルな世界の設備や仕組みは、目に見えずイメージすることもできない。データセンターを見学したとしても、見えるのはサーバーやネットワーク機器、配線などであり、それらがどのくらいの処理能力があるかは、専門家でなければ推測できない。まして内部でどのような仕組みが動いているかについては全く分からない。これは情報システムのような論理的人工物の特徴である。
ひとは目に見えるものは、直感的に状況を理解できる。しかし目に見えないものは、感覚的に把握できない。特にネットを介した状況では、その瞬間に何人の人がアクセスしているかは把握できない。そのためバーチャルな世界においては、顧客は自分一人だけがアクセスしているように感じる。この点を上手く活用すれば、顧客とサービスの提供側は、ワンツーワンの関係になれるので、「個客」を対象にしたワンツーワンマーケティングが成り立つ。半面、自分の受けているサービスが良くないと思えば、自分だけが質の悪いサービスを提供されていると感じてしまう。
元IPA所長の鶴保さんは、講演などで逆の見解を述べられている。「物理的な建築物は、壁などで隠されてしまえば、内部がどのようになっているかは見ることができない。しかしソフトウェアはソースコードを見ればすべて分かる」というものである。たしかにビルなどで、コンクリートに覆われてしまった部分の内部の鉄骨や鉄筋の状況は見ることができない。見ようとすれば、その箇所を壊さなければならない。その点ソフトウェアならば、基本的にソースコードを見れば、どのような処理をしているか分かる。ソースコードがなくても、リバースエンジニエアリングの手法をつかえばソースコードの解析は可能である。
しかしそうはいっても、見えるはずのソフトウェアの不備に起因する不具合やバグは出続ける。システムトラブルを報じる新聞記事がなくなることはない。最近ではハイブリッド型自動車のソフトウェアに起因するトラブルの話も報道されている。これは何が問題なのであろうか。テストが甘い、作る人の技術がない、そもそも設計が悪い等など、いろいろなことが言われている。
しかしこれらの問題の本質は、規模が大きいことによりシステムの複雑性が増大することであろう。一人の人間が認識するには、対象が大きすぎることである。いいかえれば部分を見ることはできるが全体がどうなっているか分からないほどに、システムのサイズが大きくなり人間の認知の限界を超えているという事である。ではどうすれば良いのであろうか。ここにアーキテクチャの出番がある。
アーキテクチャは簡単にいえば、対象を意味のある構成要素に分け、それを目的に合わせて統合するための設計思想である。大規模なシステムを構築しようとするときは、当然一人ではできないので、複数の要素に分割しなければならない。このときに個別の要素がお互いに強い関連を持っていると、一つの要素の問題点が、他の関連する要素に影響を与える。そのためいかにして独立性の高い構成要素に分割するかが鍵になる。その上で、各要をどのようにして目的に適合させて統合するかである。
アーキテクチャおよびアーキテクチャ化のプロセスであるアーキテクティングは、複雑な対象物を可視化するために必須である。しかしながら当初はきちんとしたアーキテクチャに従って設計され構築されたシステムが、時間とともに変更要求に応じて、場当たり的な対応を繰り返した結果、各要素が複雑に絡み合ったいわゆるスパゲッティ構造にしてしまう事例を良く見かける。またこのことがビジネスの要請にたいしての、情報システムの対応の遅さの主因になっているのである。
情報システムがビジネスの必要性に合わせて、タイムリーに適合でき、ビジネスのイネーブラーとして貢献するためには、情報システム自身の構造が変化に適合できるようになっていなければならない。これはアーキテクチャをきちんと構想することを意味する。その為には、企業全体の視野でとらえた個別システムの有機的集合体である企業情報システムのアーキテクチャを構想し、その中での個別システムのアーキテクチャを考えることが有用である。