» 【第87号】情報システムのスケールアップ問題

株式会社データ総研 データ総研のオンサイト教育
製品案内 DMBOK ITコンサルティングサービス ITコンサルティング事例 紹介セミナー 教育コース 技術情報 DRIブログ 会社概要
技術情報
【第87号】情報システムのスケールアップ問題

DRI通信87号「情報システムのスケールアップ問題」 2003.12.1
日が短くなって、葉が落ち、平地の紅葉も終盤戦になりました。気を抜かず注意していると風邪も引きにくく、また引いても早めに対策が打て、軽症で済ますことができます。元気にお正月を迎えましょう。
すでに案内申し上げましたが、正しい先進的DOAを普及しようと、幹事会社22社とDOA+コンソーシアムの立ち上げを企画し、12月12日(金)にDOA+コンソーシアム設立記念セミナーをひらくことになりました。会場の都合で人数に限りがありますので、お断りする可能性もありますが、そのときはどうかご容赦ください。1月以降、月1回くらいのペースで開く2つの分科会を中心に活動を展開する予定です。皆様のご協力をお願いいたします。
■ スケールアップ問題
ナイロン、テトロン、ポリエチ、ポリプロ、合成ゴムなどが工業化された、もう半世紀も前の石油化学時代、われわれケミカルエンジニアは、ビーカーの中で起きた化学反応がプラントの中ではそのとおり起きないからと、スケールアップ問題の重要性を教えられました。「規模/量の問題と質の問題は決して独立ではない」ということです。
情報システムにはたくさんのプログラムが含まれています。これを1本1本作って繋いでいけばうまく大規模システムができるか、というのが今回の情報システムのスケールアップ問題かと思われます。


■システムの信頼性/品質
今2つのプログラムA、Bがあって、それぞれの信頼性が0.999、またそのインターフェースの信頼性が0.998だったとします。するとA、Bからなるシステムのトータルの信頼性Rは、次のようになります。
R=0.999*0.999*0.998
 =(1−0.001)2*(1−0.002)
 ≒(1−0.002)*(1−0.002)
 ≒1−0.004=0.996
そこでこれをn個のプログラムから構成されるシステムの問題に拡張してみます。プログラム間のインターフェースはnC2=n(n―1)/2個ありえますが、実際に発生する割合をaとし、a*nC2=an(n―1)/2個あるものとします。個々のプログラムの信頼性を1−x、インターフェースの信頼性を1−yとすると、x、yは1に比し十分小さいので、システムの信頼性Rは次のように計算できます。
R=(1−x)n*(1−y)an(n―1)/2
 ≒(1−nx)*(1−an(n−1)y/2)
 ≒1−(nx+an(n−1)y/2)
さらにnが1に比し十分大きいとすると、次式が得られます。
R≒1−(nx+an2y/2)
ここで、x=0.001、a=0.01、y=0.002とし、n=10、100、200について計算してみると、次のようにnの増大によって急激に信頼性−特にインターフェースの信頼性−が下がることが分かります。
n=10 :R≒1−(0.01+0.002)=0.988
n=100:R≒1−(0.1+0.2)=0.7
n=200:R≒1−(0.2+0.8)=0.0
x、a、yの値が妥当か、また「個々のプログラムの信頼性のバラツキ」や「インターフェースの発生するメカニズムを無視している」など、問題を抱えた式による計算なので、どれだけ説得力があるか不明ですが、当初より計画のスコープの中になかったプログラムを、後追いで次々と繋げていった場合の信頼性の劣化を、かなり良く示しているようにも見えます。
■スコープの拡大
「当初よりスコープに入っていて計画した」とは、「そのスコープ内でのインターフェースをしっかり計画した」という意味が大きいと思われます。従来一般にはアプリケーション1個しかスコープにありませんので、これはアプリケーション間をまたがる大規模システムにおいて、常に配慮しなければならない、システムのスケールアップ問題ではないかと思われます。
「CSV方式よりXMLが良い」、「Webサービスで簡単につながる」などといって、後追いでシステムを繋ぎ、結局大規模システムを作ってしまいますが、これが可視化されてしっかり把握されていないとき、この後追い統合は、1箇所のトラブルが全システムのダウンにつながる危険性をはらんだ、かなり危険なアプローチのように思われます。大手金融機関のトラブルなどを聞くとき、すでにシステムの複雑さが人間のコントロールできる限界に近づいているのではないかと心配になります。
一般の工業製品でも出荷前にテストを行いますが、不良品は例外的にしか発生しません。しかしソフト開発においては、バグは初めは出るのが当たり前、テストしながら完成させていくといった異例の世界です。そしてそれが必ずしも異例だとは認識されていない怖さがあります。あらゆる使われ方を想定したテストが要求されますが、人間業としては難しい。やはりシステム作りに発想の転換が必要な段階に差しかかっているのではないでしょうか。
■ 発想の転換
「成功は失敗の元」と言われます。それまでの成功体験が、変革を拒み失敗につながることが多々あるとのことです。プログラムを作り合理化ができた。これを次々と広範囲に展開すれば、そのメリットが拡大できる。このスケールアップの論理に限界が生じ始めているとのではないでしょうか。必ずしもはっきり認識されていないのでしょうが、問題は「システム=?プログラム」の哲学に潜んでいるように思われます。小規模プログラムのときは、そのロジックに比し、その入出力インターフェースはあまり問題ではなかった。それを引きずったまま大規模システムと取り組んでいるのではないでしょうか。
私の仮説に過ぎませんが、やはり「システム=?(データ&インターフェース)」、「システムの骨格はインターフェースのとれたデータが造る」という哲学に変わらなければならない。人間の身体にたとえると、データが骨、インターフェースは関節、プログラムは肉のように思われます。インターフェースが食い違っているのは、関節が外れているようなもの、外れたままガムテープで繋いでシステムを運用しているためトラブルが発生する。そんなことが多々あるのではないでしょうか。
勿論これは、販売・生産といった業務アプリケーション、これを統合した企業全体システム、さらにSCM・DCMなどの企業横断システムと拡大してきた、スコープに歯止めのかからない、業務システムでの話です。OS、DBMS、WPといったプラットフォームやユーティリティのシステムではありません。これらはあらかじめ歯止めのかかったスコープを持っています。これらには「システム=?プログラム」の哲学がふさわしい。そこではオブジェクト指向が有効です。メーカーやソフトベンダーは、ここでの成功体験を業務アプリケーションに適用しようとして、たくさんの孤島システムを作ってきたように私には見えるのですがいかがでしょうか。