緊急提言：Webサービスの光と陰を考察する（1）
Webサービスを阻害するシステム開発の旧弊を絶つ
Webサービスは有望なテクノロジである。なのに、どうして普及が進まないのか。この問題はシステム開発が抱える根本的な問題から考察しなければ、満足のいく答えは見つからないだろう。この連載では3回にわたってWebサービスを成功に導くために必要な開発者の“意識改革”について提言を行ってみたい。（編集局） |
株式会社ビーコンIT
岩本 幸男
2003/11/20
「Webサービスする」。この一見不可思議な日本語をちまたで耳にされたことがあるだろうか。残念ながら私はこのような言葉がコンシューマから発せられる場面に遭遇していない。しかし、似た言葉で、「インターネットする」という言葉は頻繁に耳にする。コンシューマは、ブラウジングすることやメールすることを「インターネットする」と表現している。ネットワークを「する」という日本語は間違った使い方だが、インターネットの爆発的普及は、実態が具現化しにくいネットワークという存在を上手に（間違ってはいるが）コンシューマの言葉として定着させることに成功した。
Webサービスの普及過程においても、Web上のさまざまな機能がサービスとして提供され、自由自在にコンシューマ・アプリケーションから利用されるようになれば、「Webサービスする」という言葉が生まれるかもしれない。また、このような言葉が生まれることによって、初めて爆発的な普及曲線をたどれるのであろう。
 |
さて、現状のWebサービス普及速度は、ご承知のようにベンダの思惑を大きく下回り、お世辞にも普及しているとはいいがたい。このままでは、Geoffrey A. Mooreの「Technology Adoption Life Cycle」で示される「Early Adopters」とその次の段階である「Early Majority」との間にある大きなギャップ（Chasm）を越えられずに、既存の分散技術であるDCOMやCORBAと同様の運命をたどりかねない（下図参照）。
 |
| 図1 Geoffrey
A. MooreのTechnology Adoption Life Cycle 参考図書：Inside the Tornado: Marketing Strategies from Silicon Valley's Cutting Edge by Geoffrey A. Moore |
Webサービス推進派の立場を取る筆者としては、何とか普及させたいと願っているが、DCOMやCORBAそしてWebサービスの現状を考察すると、ある事実が浮かび上がってきた。Webサービスを含めた分散技術の普及を阻害する要因は、テクノロジ自体とはまったく別なところにある。詳しくは、本稿で説き明かすが、その要因は、Webサービスばかりではなく、システム間通信やシステム統合などを困難にしている要因とも共通である。
Webサービスの登場により、それまで考えられなかった低コストで企業間もしくは企業内のシステム間通信が可能になった。それにもかかわらず、Webサービスはユーザー企業になかなか受け入れてもらえない。ここには何か大きな障害が存在するはずである。それは文化に起因する障害なのか、過去からの慣習によるものなのか。または、Webサービスの技術的な困難さに起因しているのか。それとも、そもそもビジネスにおいてのニーズがないとでもいうのか。
連結経営やグローバル化を進める企業にとってシステム連携のニーズは存在しないどころか、増加の一途をたどっている。明確にITのニーズではなく、ビジネスのニーズとして企業内外のシステム間連携および情報統合のニーズは存在しているのである。
それでは、なぜWebサービスは受け入れられないのか。システム構築は、製造や建築と同様に「モノ作り」産業である。この「モノ作り」産業の長い歴史の中で、生産性を爆発的に向上させた要因は何か？ 誰もが標準手順によるオートメーション化と部品化という答えを1番目もしくは2番目に挙げることができよう。高度成長を支えた自動車産業などでも、組み立てラインを持つ本社工場を中心に、周辺には標準部品を供給する関連会社がまとまって産業を構成している。同じ「モノ作り」産業であるソフトウェア産業の問題点は、この標準部品を作成・供給するビジネスが存在していない、もしくは産業化されていないことである。
標準部品が供給されないため、システム構築は毎回部品の標準化策定から始めなければならないことが多く、何度も「同じような作業」を行わなければならないという点では、産業としてのレベルの低さを認識させられる。ここで問題なのは、「同じ作業」ではなく「同じような作業」という点である。似ているが少しずつ異なる部品が単一企業の中にもたくさん存在するということだ。当然、部品としての管理はされていない。
このような、低レベルで標準化のできていないシステム間をWebサービスでつなぐことに、ユーザー企業はどんなメリットを感じるだろうか？ つないだところで、意味のないデータが交換されるだけである。もちろんそれぞれの個別システム内では十分に意味のあるデータであるが、標準化されていなければ通信相手にはデータの意味が理解できない。
Webサービスには、通信というプロトコルの側面と、アプリケーションを部品化し、サービスとして公開するSOA（サービス指向アーキテクチャ）の側面があるが、結局のところ、普及を阻害している要因は、ソフトウェア産業そのものの未熟さ故に、標準部品化が遅れ、最新技術を活用できないところにあるように思える。インターネット上にWebサービスという最新のプロトコルを備えた国際通信網が提供されても、流通するデータや供給されるサービスが標準化されていなければ、コミュニケーションは成立しないのである。
|
|
ここでWebサービスが現行システムに受け入れられない諸問題について言及しておく。ビジネス環境の急激な変化に伴い、企業経営者はIT部門に対し、次のような2つの課題を提示していることであろう。
- ビジネス戦略とIT戦略をいかに融合させるかということの重要性は、昨今の金融機関統合の例が端的に物語っている。わが社を取り巻くビジネス環境は大変なスピードで変化している。従って、わが社のビジネス戦略も臨機応変に変化せざるを得ない。この刻々と変化するわが社のビジネス戦略をサポートするため、どのようにして柔軟性のあるIT戦略を構築すればよいのかを提示しなさい。（開発スピードの向上）
- この不況下、IT予算を継続して増やすことは不可能であるのはいうまでもないことである。しかしながら、新しい業務への対応ニーズは増えるばかりである。IT予算を抑えつつ、どのようにして増加一方にある新しいアプリケーションの開発を進めるつもりなのかを提示しなさい。（開発コスト削減）
これらの課題は、製造業に見られる工場の海外展開や、金融・自動車・半導体産業に見られる同業種の提携、そして規制緩和による新規事業の展開など、さまざまな経営判断に対し、柔軟にITサービスが提供できなければ、競争優位に立てないとの経営者サイドの深刻な危機感である。しかし、現状はご承知のとおりである。銀行や交通機関などの相次ぐシステム障害、そして複雑化する課金問題を抱え利用料金請求ミスのなくならない通信会社、これらは情報社会の中で見過ごされていた、あるいは先送りにされていた問題を浮き彫りにしているといえる。加えて急激に複雑化するビジネスを、完ぺきにサポートするシステム構築が困難になっていることも主な原因といえよう。
企業の外界、つまりマーケットは常に変化する。特にインターネットそしてブロードバンドの普及により、その変化のスピードは想像を絶するものとなった。企業経営者は、この外界の変化に合わせビジネスのかじ取りを行おうと努力しているが、経営レベルでかじ取りができても、その経営を支える肝心のシステムが曲がらない。つまり船は船長の思惑どおりに方向転換できずに沈没してしまう。金融機関をはじめとする企業統合におけるシステム障害は、まさにダイナミックに統合・合併を繰り返して経営基盤を強固にしたいという経営判断に、それを支えるシステム基盤が追従できなかったために起こったものといえる。
システムに携わるすべての方々が感じたことがあろう。
「なぜ、このシステムはこんなにも固定的（ガチガチ）なのであろうか」
「異なるシステムの連携は作り直すより大変だ」
「ちょっとした修正なのに作業の影響範囲の特定ができない」
そもそも、従来のITサイクルでは、ビジネスのスピードに追い付けないのである。現在でも主力であることに変わりはないが、ほんの数年前まではメインフレームを中心としたシステム構築がなされていた。この時代のシステム開発サイクルは「年」が基準であり、かなり大規模な数年にわたる開発プロジェクトであった。
その後クライアント／サーバの時代では、システム構築のサイクルが「半年から1年」へと短縮され、Web系のシステムでは「1カ月から3カ月」単位で機能をリリースしなければならないようなスピードになった。しかし、ビジネスの急激な変化はもっとスピードを要求する。このスピードに対応するには、システムをゼロから構築していては間に合わない。標準部品の組み合わせによって、つまり部品をプロセスでつなぎ合わせることによってシステム構築がなされる必要がある。このアプローチに必須なのが、WebサービスそしてSOAである。予測のつかない明日のビジネスに対応すべく、俊敏さと臨機応変な柔軟さを「標準部品の組み合わせ」と「プロセス」で実現しようとする試みである。
しかし、現状システムは長年の縦割り開発がもたらした排他性と低レベル産業の弊害により、さまざまな問題を抱えている。
一般に、システム構築プロジェクトは業務ごとに結成され、業務最適にデザインされる。この場合、開発者は既存の周辺システムをすべて見直し、再利用できそうなコンポーネントを探し出す行為をするであろうか。プロジェクトは時間との戦いである。膨大な過去の遺産から金貨を探し出すよりも、業務に合わせて新規に作成してしまった方が早く、しかも業務に則したコンポーネントが作れるという目前の建前論から部品化ができないという悪循環を繰り返すことになる。
業務に依存したシステム構築は、結果として個別最適化を目指したシステムとなる。また、部門担当者がどんなに頑張っても、企業全体あるいは企業をまたがってデータを共有し流通させることはできない。標準部品化は、その担当者の統制の効く範囲内でしか有効にならない。
個別最適に開発されたシステムも、業務を遂行するためにはほかのシステムとの連携が必要となる。結局、プロジェクトの終了間際になってから連携せざるを得ず、システム間で相互に複雑な絡み合いを生み出し、メンテナンスを難しくする。連携の数は、組み合わせの数だけ必要であり、
（システムの数）*（システムの数−1）/2
となり、気が遠くなるような作業がプロジェクト終了間際に残る。この連携作業が悪の根源ともいえるシステム間の密結合によって行われてきた。この密結合を誰も解くことができないために、既存システムの部品化が進まない。
また、複雑なシステムは人間の限界を超え、思いもよらない障害を起こすことになる。複数銀行の統合システムをすべて把握できる超人など存在しないのである。また、これらの複雑なシステムを人力により支えた優秀なSEは、2007年を境に一斉に定年退職を迎える。団塊の世代では常識と思われた事柄が、次の世代では常識ではない。
情報の引継ぎがなされなければ、大変なことになるのだが、混乱を極めたシステムには、もはや引き継ぐべき正確なドキュメントが残されていない。仮にすべてが標準部品の組み合わせで構築されたシステムであれば、部品交換で解決できるのであろうが、残念ながら、団塊の世代の知識は部品化という形で後世には残されていない。問題回避のために、ERP導入による完全再構築、もしくは自社運用をあきらめアウトソーシングを検討しなければならないのはまことに残念なことである。
保守の問題
システム構築のたびに保守作業が幾何級数的に増加し、IT予算の7〜8割が費やされ、新規ニーズにこたえることはもはや不可能である。しかも、ドキュメントがプログラムの保守に追従することは困難であり、ドキュメントと実際のシステムとの乖離は大きくなる一方である。もはや保守は開発者自身に頼らざるを得ない。もし10万行のプログラムに1万行の追加を行おうとするならば、11万行の見直しが必要となることを覚悟する必要がある。システムが理解されないのは、その特徴として物理的に見えないことにある。
巨大なシステムといわれても、それが六本木ヒルズのような壮大なインテリジェントビルなのか、つぎはぎだらけの長屋なのかが分からない。まして内部の構造などは外見だけでは分からない。UMLなどの標準的な図表現を使った現状システムの可視化が必要である。
部品化の問題
もう1つの要因として、再利用という部品化作業は高度な職人技術を要求される。部品化作業を行うと直面することであるが、困ったことに実際に作業を進めても、部品の粒度の大きさが適正かどうかはすぐに判断できない。構築中のシステムに合わせて、その都度部品の粒度を決めると一般に粒度は大きくなり、同じような部品がたくさん作られ、結果として再利用されない。
再利用されなければ、テストもやり直しであり、品質の保証もできない。また粒度が小さいと個々の部品を組み合わせるのが大変なうえにパフォーマンスに問題が出る。部品は疎結合による連携が前提となるため、システム間の通信速度は従来の密結合による連携に比べ格段に遅くなる。
実装時の手戻り
また、設計の段階では再利用可能と判断されていた部品が実装時にささいなことで再利用できずに、インターフェイスの変更を余儀なくされることがある。この場合、すでにプロジェクトは実装フェイズであり再設計の余裕もなく、その場での対応が行われる。これでは再利用といえず、まったくの新規開発と同じ工数が必要となってしまう。さらに、この共用性の高い標準部品は、ほかの部分に先行して開発されなければならないのだが、プロジェクトの計画にこのプロセスが抜けている場合も見受けられる。
スパゲティ状態であるから、データ・機能・プロセスが分離できるはずもない。しかし部品化を考える場合、重要となるのが、これら3要素の分離である。
例えば、企業と顧客の接点を考えた場合、個別最適な考え方による構築では、営業支援システム、コールセンターシステム、CRMシステム、債権管理システム、納品システム、etc.とさまざまな場面で顧客との接点をサポートするシステムが出来上がる。それぞれのシステムに顧客マスタが作られることになり、おのずと整合性は取れなくなる。また、顧客という管理項目が、企業名までなのか、事業所や部門までなのか、または個人まで管理する必要があるのかなど、各システムで押さえなければならない「顧客」の粒度が異なる。このような状況で、BPRをしようとか、他社との合併をしようといってもできるはずがない。
あらかじめ、顧客マスタがシステムから「外だし」で管理され、プロセスが機能から分離されていれば、BPRや統合は一夜の作業となる。この機能をサービスとして標準手続きで呼び出し可能にする仕組みがWebサービスである。
|
|
現行システムの抱える問題とともに、なぜWebサービスが土壌に浸透しにくいのかを述べたが、総論として、システム基盤は組織や業務に合わせた縦割りで作成してはならないということである。システム基盤は、全社横断さらには企業グループ横断的な横割りで構築される必要がある。
「ソフトウェア産業」と呼ばれても恥ずかしくないような標準部品化ができれば、Webサービスは爆発的に普及するはずである。そのためには優秀なITアーキテクトによる基盤設計が必要となるであろう。ここでは、標準部品の内容については言及していないが、部品とはアプリケーションレベルでの標準化と、データレベルでの標準化を含んでいる。
あらかじめ注意しておくがこれらの標準部品化は物理実装レベルではない。論理的な、または概念的なレベルでの標準化である。実装レベルでの標準化は、IT技術の進化とともに風化してしまうが論理レベル、概念レベルの標準化は不変である。
◇
本稿では部品の標準化を実現できないソフトウェア産業の未熟さを指摘した。次回はデータの標準化を担うXMLの有用性について議論しよう。（次回に続く）
■バックナンバー
1. Webサービスを阻害するシステム開発の旧弊を絶つ
2. データ標準化から目をそらす守旧派の罪と罰
3. データ指向とサービス指向、そして約束の地へ
 |
緊急提言：Webサービスの光と陰を考察する |
- QAフレームワーク：仕様ガイドラインが勧告に昇格 （2005/10/21）
データベースの急速なXML対応に後押しされてか、9月に入って「XQuery」や「XPath」に関係したドラフトが一気に11本も更新された - XML勧告を記述するXMLspecとは何か （2005/10/12）
「XML 1.0勧告」はXMLspec DTDで記述され、XSLTによって生成されている。これはXMLが本当に役立っている具体的な証である - 文字符号化方式にまつわるジレンマ （2005/9/13）
文字符号化方式（UTF-8、シフトJISなど）を自動検出するには、ニワトリと卵の関係にあるジレンマを解消する仕組みが必要となる - XMLキー管理仕様（XKMS 2.0）が勧告に昇格 （2005/8/16）
セキュリティ関連のXML仕様に進展あり。また、日本発の新しいXMLソフトウェアアーキテクチャ「xfy technology」の詳細も紹介する
 |
|
|
|
|
