ＳＯＡは、技術面での大きな動きではなく、個人的には今までの技術の集大成ではないかと考えています。つまり、Ｗｅｂサービス、ＸＭＬ、ＥＲＰなど、個別にあったいろいろな動きをもう一回サービスという切り口でまとめあげたアーキテクチャーがＳＯＡだということです。ですから、個々の要素技術でいくとあまり新しいことはないし、それほど大きなものではありません。ただ、集大成になったときの位置づけは一体どういうものか、どんなふうに役に立つのかということがあると思います。

　1987年にあったＳＩＳという動きから、経営にとってＩＴとは単なる合理化・省力化をするためのものではなく、もっと経営を支えるものであり、例えば戦略的に優位になるためにそういうシステムを使うということがありました。ＳＩＳはその後ブームを作って消えていったのですが、そのときの経営とＩＴとは何なのかというところと今のＳＯＡとはリンクしているのではないか、つまり、最適解といえるかどうかは分かりませんが、ユーザー企業、コンサルタント、ベンダーなどいろいろなかたにお話をお聞きしたうえで、やはりそれがＳＯＡではないかと個人的には認識しています。

　ところが、ではＳＯＡとは何なのかというと、微妙に各社で定義が違っています。例えばＡ社のニュースリリースによると、ＳＯＡとは「各種のＷｅｂアプリケーションをサービスという単位であらかじめ部品化し、それらの再利用や相互連携を行うことで、Ｗｅｂシステム構築を効果的に効率的に行う設計手法」となっています。しかし、同じＡ社のホームページの中の説明を見ると、「あらゆるアプリケーションやソフトウエアをサービスとして連携することで、ビジネス環境の変化に柔軟かつ短期間で対応できるようにする企業情報インフラの実現」とあります。

　さらに、Ａ社の関連会社のニュースリリースでは、「グローバルでオープンな標準仕様をベースとし、かつビルディングブロック方式によりサービスの組み換えが容易な高い柔軟性と拡張性を備えたＩＴ基盤」と、ここでは「標準仕様」がベースになっています。これはこれで確かに重要な点ですが、このような短い文章でＳＯＡを説明しようとすると、やはり微妙に違うような感じがします。

　また、Ｂ社の説明では、「１対１の疎結合関係を持つ、サービスとサービス・コンシューマーから成るアプリケーション・ソフトウエア・トポロジ。ここで言うサービスは、ビジネス完結型の論理作業単位であるソフトウエア・コンポーネント」となっています。かなり言葉が難しく、確かに切り分けてインターフェースを築くという点ではそのとおりかと思いますが、少しＳＯＡの定義としては狭いような気がします。

　Ｃ社は、「稼働しているサービスを統合技術を使って組み合わせ、システムを構築する考え方。ここで言うサービスは、ビジネス的に意味のある形で切り出したシステムの機能」としています。

　これは、どこがいい悪いと言っているわけではありません。各社それぞれ頭をひねって書かれているのではないかと思うのですが、ニュアンスが微妙に違うというところを実感としてとらえていただければと思います。

　前提としては、企業のシステムと言ってもいろいろあるわけですが、その中の会計システムや販売システムといった一つのシステムを指すものではなく、もう一段大きな、会社の主要なシステム全体を貫く設計思想だということです。「全体最適」という言い方はエンタープライズ・アーキテクチャーが出てきたときより言われるようになりました。もちろんやりたい企業はもっと前からずっとやっているのですが、そのようなベースとなる企業全体のシステムの中での話です。

　要は、個別のシステムではなく、システム全体をサービスの集合体としてとらえる考え方がＳＯＡです。ここで言うサービスとは、一つあるいは複数のプログラムに関して出入り口の仕様を標準としてきちっとまとめておき、それらを共通で使えるようにするというものです。このサービスをどのように切るかは、基本的には業務管理であるといわれています。この辺が、経営とＩＴの一体化を考えたときに、ＳＯＡがどうして重要な意味を果たすのかという一つの理由になっています。

　非常に単純化したＳＯＡの例として、受発注システムを見てみましょう。もちろん受発注システムを一つのサービスとして使うというパターンもあると思うのですが、一般的にはもう少しブレークダウンしたものをサービスと見なしていますので、まずは受発注システムを構成する構成要素をサービスという形で扱います。

　サービスの裏側には、使う人、例えば受発注システムの直接的なエンドユーザーは考えません。飽くまでもアーキテクトのかたがたがどんなサービスをどう組み合わせたり順番につなぎ合わせていくかを考えるのであって、基本的に使う人はそのサービスがどんなシステムで実現されているかといったことは全く考える必要はありません。

　サービスの裏側は、メインフレームのシステムである場合もありますし、あるシステムの一部の機能とあるシステムの一部の機能を組み合わせて一つのパーツを作っていくパターンもあるかもしれません。場合によっては自社のシステムとは限らずに、いわゆるＡＳＰ、または協力会社のシステムといったネットワークを介してのシステムという場合も考えられます。いろいろな作り方ができるのですが、どちらにしても、それをサービスとして扱う人にとっては関係のないことで、そこは気にせずに使えるようにできるというのが基本的なＳＯＡの考え方です。

　キーワードの一つめは「統合性」です。要は、システムをサービスとして全体規模で自由に組み合わせられる、ある基幹系という領域だけではなく、全社システムを容易に統合できるということです。もちろんサービス化しなくても統合はできますが、システム全体として考えることがしやすいという点はまずあると思います。

　二つめは「仮想化」です。この言葉も最近のキーワードの一つで、いろいろな意味で使われています。例えば、先ほどサービスの裏側にはいろいろなシステムがあり、それで動いていると言いました。それがあるサーバーで動いているのか、複数のサーバーで動いているのか、別のサーバーで動いているのかを隠してしまうようなハードウエアレベルでの仮想化もありますが、ＳＯＡで言う仮想化はもう一段上のもので、実装形態を気にせずに、しかも余計なことを見せないという意味があると思います。

　三つめは「柔軟」です。サービスとは基本的には業務単位でできており、必要に応じてそのサービスを入れ替えたり、外したり、付け加えたりということがしやすい仕組みになっているということです。当然のことながら、それができるためにはデータの一貫性などいろいろな仕組みが必要です。

　四つめは「オープン」です。先ほどＳＯＡの定義例のところで標準仕様という言葉が出てきましたが、基本的にベースとしている技術には標準仕様をできる限り使うということです。もちろん、そうしなくてもＳＯＡの実現はできるのですが、標準仕様を使っていれば、Ａ社のサービスを実現するために、Ｂ社のミドルウエア、Ｃ社のデータベース、Ｄ社のアプリケーションを使っていくことができるという点で、オープンな技術を使うということもキーワードの一つではないかと思います。

　これは柔軟ということですが、場合によっては注文受付と在庫照会を引っ繰り返すこともあると思います。業務の要件のうちで必要になる場合もあるでしょうし、ほかのところで使っている受発注システムをＷｅｂでの販売システムに変えるときに必要性が出てくるケースもあるでしょう。また、例えばこれまでは自社の基準で与信をしていたけれども、それをアウトソーシングしようというようなことをしやすくなります。これは従来のシステムでもできましたが、テストが必要だったり、手間がかかったりしました。できるのだけれどもなかなか困難だった部分がやりやすくなる。これが、ＳＯＡのよさだと思います。

　ただ、今出ているＳＯＡのソリューションで、すべての業務変更に対応できるという意味ではありません。ＳＯＡが目指すところ、100％できればこんないいところがあるのだという例です。ＳＯＡの場合は、理想と現実にまだかなりギャップがあるということが問題で、それについては課題のところで詳しく申し上げます。

　ＳＯＡの構成要素は本来各社で違うように思いますが、一例としてご紹介しますと、最初にＥＩＰ（企業情報ポータル）があります。ユーザーに一貫したインターフェースを提供するということですが、ここで言う一貫性とは、デザインを統一するというだけの意味ではなく、例えば人が替わったとしても業務のレベルを下げずに進められるようにするということです。この辺に関してはあまり議論されていないように思いますが、我々としては基本的にはユーザー企業の視点でいろいろな動きを取り上げ、それはどういうものかを説明するというスタンスをとっておりますので、ＳＯＡをもし実際に企業のシステムとして使うならこんなことも重要だということで、あえて挙げています。

　それから、ＢＰＭ（ビジネス・プロセス・モデリング）、作ったサービスをどういうふうに並べて使うのかというところです。最近モデリングの重要性がいろいろなところで叫ばれていますが、日本では、自分の業務をちゃんと価値化する、モデル化するということをしていない企業のほうが多いのではないでしょうか。しかし、それをやらないとＳＯＡのメリットは出てこないのではないかということで、モデリングについても非常に重要だと考えています。

　それから、ＥＳＢ（エンタープライズ・サービス・バス）があります。サービスどうしはどんなふうにやり取りするのか、やはり共通のバスみたいなものが必要だということで挙げていますが、その実装形態はばらばらです。例えばＷｅｂアプリケーションサーバーの中にＥＳＢの機能を持たせるというパターンもあれば、ＥＳＢだけ独立したものであるべきだと主張するベンダーもいらっしゃいます。ですから形はばらばらなのですが、やろうとしていることは同じで、基本的には、データ形式や通信プロトコルが異なるサービスどうしをうまくやり取りできるようにすることが必要だと思います。

　もう一つはＭＤＭ（マスター・データ管理）で、データの整合性をちゃんと取るということが非常に重要です。もちろん、いろいろなサービスでデータを全部一つにしてしまえば苦労はないのかもしれませんが、そういうことは現実にはありえないわけで、顧客のデータ一つを取っても、けっこうばらばらになっています。しかし、やはりそれは一貫したものとして扱うようにしないとＳＯＡのメリットは出てきませんので、データの整合性をとる仕組みも重要です。マスター・データ管理といってしまうと、いわゆるマスター・データ、メタデータの管理という狭い意味になってしまうのですが、言いたいことは、マスター・データに限らず、ＳＯＡのシステムの中で使うデータの一貫性をとる仕組みが必要ではないかということです。

　全体像としては、ＥＩＰ機能がいちばんユーザーに近いところにあって、真ん中にＢＰＭ、そしてＥＳＢ、ＭＤＭとあるのですが、実際はきれいに切り分けられるものではなく、ＢＰＭといってもほとんどＥＳＢに近いのもありますし、その逆もいえるわけです。要は、実際にサービスの処理を動かすところにＢＰＭ、ＥＳＢがあって、その裏側のデータベースを管理するところでＭＤＭがある。そして、それぞれでＵＭＬ、ＳＯＡＰ、ＷＳ-Securityなどのいろいろな標準仕様が出ており、それに準拠したものになっているということです。

　ＳＯＡについて最近の動きをざっと見てみると、例えば日本オラクルは、つい先日、「ＢＰＥＬ Process Manager」を出しました。これはＢＰＭに当たるところで、ＢＰＥＬという標準仕様に完全準拠していると言っています。このほかにも日々動きがあり、今、ベンダーがこぞって出しているという感じです。

　ベンダーの中では、いちばん上から下までそろえているのはＩＢＭのようなイメージがあります。区分けについてはいろいろな議論があると思いますが、先ほど申し上げた四つの構成要素に当たる製品をすべて出していますし、個人的にＳＯＭＡ（Service-Oriented Modeling and Architecture）にも興味があります。

　サービスをどんなふうに切るのがいいかという部分は、恐らく会社によっても違い、どういう使い方かによっても違いますが、この問題は部品化再利用をどうするかというところで割と昔からあり、最適解は出ていないように思います。残念ながらＩＢＭは、ＳＯＭＡに関して我々メディアに事細かにはあかしてくれないのですが、聞くところでは、トップダウンのアプローチとボトムアップのアプローチの両方から、どんなサービスが必要で、そのサービスの大きさなり形をどう決めていくかという手順をちゃんと示したものだということです。

　このようなサービスはこれから他社も出してくると思うのですが、自己流でやると、結果的にはこれまでの部品化再利用がうまくいかなかったのと同じようなことになりかねませんので、こういった動きも重要ではないかと思います。

　ＳＡＰはＥＲＰベンダーの最大手ですが、基本的にはアプリケーションに非常に大きな強みを持っています。企業のシステムをすべてＳＡＰ製品でそろえてしまえばいいのでしょうが、それは現実的ではありません。既存システムや他社のパッケージなど、ほかのシステムとの連携が不可欠です。では、他社システムを交えた全体のシステム・アーキテクチャーをどんなふうに作るかというと、ＳＡＰも、顧客も、パートナーもハッピーになるというところでいろいろ考えた結論が、今出しているＳＡＰ版ＳＯＡ、ＥＳＡだと思います。

　ＥＳＡはミドルウエアが非常に充実されており、NetWeaverと呼んでいるものの中に、ＥＩＰ、ＢＰＭ、ＭＤＭといったものがいろいろ入っています。しかも、最初はばらばらで出していたものをまずはNetWeaverの中に統一したのですが、単に統一しただけではなく、統合して、ＳＡＰ自身の製品もサービスとして扱えるようにしています。それをエンタープライズサービスと呼んでいるのですが、常に300種類のサービスを用意しています。自社のシステム、あるいは他社のシステムもサービスとして使えるようにする、それを束ねる仕組みをNetWeaverというミドルウエアで提供するということです。

　もう一つ、ほかと違ってユニークなのは、コンポジット・アプリケーション、要はサービスをあらかじめ組み合わせてアプリケーションを作るということです。例えば京都議定書にのっとったことをするためのマネジメントシステムとか、ちょっと変わったアプリケーションが多いのですが、そういうサービスを組み合わせたパッケージ、xAppsを出しています。基本的には、やはりいちばんの強みである自社のアプリケーションを生かす形でどんなふうにＳＯＡを実現させていけばいいかということで、NetWeaverやxAppsを出しているというところです。

　ご存じのように、オラクルはピープルソフトというＥＲＰのかなり大きなベンダーを買収しましたが、ピープルソフトはＪＤＥという別のＥＲＰベンダーを買収しています。そのピープルソフトを買収したことで、オラクル自身もOracle EBSというＥＲＰのパッケージを出しているのですが、それとピープルとＪＤＥを全部くっつけたものを創造しなければいけなくなりました。そのプロジェクト名が「Project Fusion」で、Fusion Middlewareというものが、ＳＡＰでいえばNetWeaverに当たるようなオラクルのミドルウエアです。

　ＳＡＰにとってはアプリケーションがいちばん強いのでそこを軸に考えるのと同じように、オラクルにとっていちばん強いところはやはりデータベースのところです。データベースを持っているということは情報を集める仕組みがあるということで、ではそれを生かす形でＳＯＡを実現するためにはどうしたらいいかを考え、それで出したのがFusion Middlewareだということと、もう一つはCustomer Data Hubという、顧客データをいかに取っていくかという製品を出しています。

　要は、先ほどの四つの要素で言ったＭＤＭのところ、データをいかに統合していくかというところから、その技術を生かした形でＳＯＡを実現し、さらに自分たちのすでにあるＥＲＰのパッケージをアプリケーションサービスとして扱えるようにするにはどうしたらいいかというところで、Fusion Middlewareを出したということです。

　富士通も、つい最近ＳＯＡのソリューション体系を出しました。個人的にはちょっと分かりにくかったのですが、コンサルティングからその下のミドルウエアのところ、業種別のソリューションをちゃんと出しており、その下の実行基盤、TRIOLEの中でＥＳＢ機能も強化していくというところで、全体としてＳＯＡをやっていくという意思表示をしていますので、国産ベンダーの中では割とよくやられていると思います。

　経営にとって、ＩＴはどんどん重要になっています。リアルタイム経営ということもありますし、特に通信系、携帯などはビジネスの動きが激しいので、絶えず新しいことをしていかなくてはならない。これまでのビジネスを微調整しながらやっていかなければいけない。ドッグイヤーという言葉もありますが、ビジネスのスピードはどんどん加速しているわけです。

　一方で、企業は直接的に本業のことだけではなく、いろいろなことを考えなくてはいけません。まずセキュリティ問題があります。個人情報漏洩が毎日のように起こって、個人情報保護法ができましたし、日本版ＳＯＸ法という動きも着々と進んでいます。これはどういう形でやるかまだ分からないのですが、2008年３月までには、企業は何かの形で対応しなければなりません。例えば、これまでの業務の仕組みを変えたり、履歴を残しておく仕組みを作らなければいけないのですが、当然のことながら紙で取っておく時代ではありませんから、ＩＴが必要なわけです。ですから、経営にとってＩＴがどんどん重要さを増していくことは間違いありません。

　我々が実施した調査で、経営トップに「経営戦略を遂行する上で、情報システムをどう位置づけているか」という質問をしたところ、「重要視していない」と答えた人は４％で、「欠かせない」と断言したかたが80％近くいらっしゃいました。その点では、経営トップも非常に意欲があるということが分かります。

　この調査は1600社を対象に行ったのですが、有効回答が251社ということで少し戻りが少なく、多少バイアスがかかっている点は考慮しなければいけないのですが、それにしても、経営者の多くのかたがＩＴの必要性を自覚しているといえるでしょう。

　では、情報システムはどの程度役に立っているかということで、複数回答でしるしをつけてもらったところ、昔からいわれているように、人を減らす、仕事を減らす、いわゆる効率化というところが大きくなりました。もちろんこの役割は変わらないと思うのですが、それだけでしょうか。本当に経営を支えるという点では、例えば顧客サービスの向上や業務改革の推進、意思決定スピードの向上といったところが多くなってしかるべきではないかと思います。

　情報システムを開発していらっしゃるかたは、恐らく単なる効率化ではなく、会社の力を増やす、売り上げを伸ばす、利益を増やすためのシステムが比較的できたと思っていらっしゃるように思いますが、トップから見て現実的にどう役に立っているかというと、昔と変わらないではないかという思いなのかもしれません。

　このフレーズはご存じのかたも多いと思いますが、意訳をすると、「ＩＴは経営にとってもはや重要ではない」ということです。これは直接的には「ハーバード・ビジネス・レビュー」という雑誌に２年前にニコラス・カーというかたが出したのですが、なぜこういう話になるかというと、ＩＴ投資は皆さんすごいお金を使ってやっています。日本でも大手金融機関ですと1000億以上投資をしていたり、お金としてはかなり使っているわけですが、「その割にはそんなに効果は出ていないのではないか」という問いかけなのです。

　先ほどのアンケートの結果と非常に関係しているのですが、経営にとってＩＴはどれだけ効果があるかというと、会社の差別化や顧客の囲い込みといった要因にはあまりなっていません。ＩＴ戦略といって何か新しいことを始めたというと、すぐほかもキャッチアップして追いついてしまい、結果的にはやるのが当たり前のような世界になってしまう。これはごく自然な流れともいえるのですが、その割には金がかかりすぎているのではないか、リスクも大きすぎるのではないかということです。システム開発プロジェクトが予定どおりにいかないという話は、非常によくあるお話だと思います。ですから、ＩＴをそれほど重要視する必要はないのではないか、ＩＴに関しては、ほかに先駆けてやるよりは、ほかの企業がやって安全だと思うことをやっていればいいのではないかという説を展開しているのが、この論文です。

　これに対する反応はどうだったかというと、ベンダーは当然渋い顔をします。「おれたちの商売をじゃまする気か」「ＩＴはやはり重要ではないか」と言うのですが、ユーザー企業、特に経営者の多くのかたがうすうす感じていたことを言葉にしたという点で、ニコラス・カーには大きな功績があるのではないかと思います。

　やはり、ＩＴ投資はこれでいいのか、これだけ金を出しているけれども本当に役に立っているのかという点では、皆さん疑問に思っているのです。すべてとはいいません。実際にＩＴ投資をうまくやっている企業も少なくありませんが、多くの人たちを見ると、やはりＩＴ投資疲れといいますか、投資している割には効果が上がらない、思ったほどではないと考えているかたが想像以上に多いようです。

　なぜそういうことを引き起こしているかというと、一つは、得られる効果はしょせんその程度で、ＩＴは効率化・合理化の道具なのだというところが大きいと思います。その裏にあるのは、もちろんシステム領域の話もありますが、そもそも経営者自身がＩＴとは何か、本当はどんなふうに使えばいいのかということが分かっていない、関心がないということです。また、組織ぐるみでＩＴを生かす仕組みをちゃんと持っていないということもありますし、ベンダーとのつきあいがどうもよくない。頼り切って、「我々は分からないから任せますよ」というところもあれば、逆に、やたら高圧的な場合もあります。コミュニケーション不足ということも含めて、ほかにもいろいろ要因があると思います。

　「情報化疲れ」「IT Doesn't Matter」という言葉で代用されるようなものは、けっこう業界全体にあると思います。先ほどユーザー企業の中での問題点を示しましたが、もちろんベンダー側にも問題点があります。例えば、プロジェクトをきちんと進めるために組織としての仕組みづくりをやっているのですが、よく見ると、結果的に人任せ、個人に頼りすぎるところが相変わらずある。素晴らしいプロジェクトマネジャーに頼ってしまうとか、何かあると火消しのかたが問題を解決するとか、ある種属人的な解決の方法がいまだにけっこう多いようです。

　業界全体としても問題があります。よく指摘される下請け構造の問題もありますし、また、この業界は徹夜や休日出勤、長時間勤務が当たり前のようになっていて、過酷な３Ｋの職場というイメージで、いい人が来ない、魅力的にならないという問題もあります。結果的に属人的で、工業化という言い方が正しいかどうかは分かりませんが、もう少し業界として成熟して先に進むことがなかなかできないということが問題になっています。

　個別にはそれぞれ努力しているのですが、本当にちゃんとできているところはほんの数％で、特に地方に行くとかなり悲惨な状況です。いいプロジェクトマネジャーもいない、ユーザー企業もほとんど分かっていないということで、かなり悪循環に入っているのではないかと思います。

　解決への道としては、いろいろなことが必要で、例えばシステムをＳＯＡにしたからといってそれが解決することにはならないのですが、少なくとも情報システムを経営に生かすためには、やはり俊敏な形でなければなりません。ビジネスは２か月後、３か月後に始めなければいけないのに、システム開発に半年から１年かかってしまうのでは話にならないわけで、やはり俊敏さが必要です。

　それから、システムどうしの連携が図りやすいことも重要です。直接的には保守コストを下げるという点もありますし、新しいビジネスにもちょっとした手直しですぐ対応できるという点でも重要ではないかと思います。

　もう一つ、既存のシステム資産を生かせるという点も大きなポイントだと思います。システム資産というと、ＣＯＢＯＬとかＰＬ／１だけと思われがちですが、今、オープン系の資産もばかにならないぐらいあるわけです。もちろん、そういうものを全部スクラップしてしまって新たにやるという形もありますが、現実問題としてコストやいろいろな面を考えれば難しいこともありますので、既存の資産を生かすという選択肢もある形のソリューションでないと受け入れられないのではないでしょうか。そういうところで、ＳＯＡは有力な選択肢ではないかと思うわけです。

　ただし、課題はいろいろあります。ユーザーにＳＯＡをどう思うか聞いてみると、現状では、総論は賛成です。それが今必要か、３年後に必要か、５年後に必要かというところは業界や企業によって違いますが、こんなシステムはいいね、こういうふうに行きたいねという点ではまず間違いありません。

　ただし、実際には様子見の企業が非常に多いのです。それは、今すぐシステム化する必然性がないということと、「また３文字の言葉か」とうんざりして、疑いの目を持っていらっしゃるということがあります。また、今は財布のひもがものすごく堅くなっていて、余計なところに金を出さないのです。景気は多少上向きになっていますが、ＳＯＡに関しては成功事例がまだないので、そういうものが出てこないと、ＳＯＡが現実のものとして広まるまでにはいかないような感じがあります。

　製品としては、先ほど例に出したＩＢＭやＳＡＰ、オラクルなど、パーツはそれぞれ少しずつ出し始めていますが、全部が全部そろったとはいえないように思います。見方によっては全部そろっているともいえるのですが、本当に使いがってのいい形にするためには、まだ何年かかかるのではないでしょうか。しかも、必要だと思っているところは、例えばＫＤＤＩのように、相当なお金と時間をかけてＳＯＡと呼べるようなことを自分でやってしまっているので、すぐに普及するかというところに関しては、多少疑問視せざるをえないような気がします。

　それから、これを実行するためには組織的なＩＴガバナンスの問題がありますし、できる人を育てなければいけません。従来のプログラマー、プロジェクトマネジャーももちろん必要なのですが、ビジネス・プロセスをどうたぐるべきかというところがかなり大きなカギなので、どんなシステムが社内にあるか、どんなデータがあるかというだけではなく、業務の流れがどうあるべきかもちゃんと見たうえで、上流の業務のプロセスをくっつける役割、アーキテクトが重要になってきます。ではそういうかたはどこにいるのかというと、もちろんいらっしゃるのですが、数は非常に少ないのではないでしょうか。ですから、うまく人材を育てていくということも大きな課題だと思います。

　あとは、サービスのよさは分かるが、ではそれをどうやって作るのか、どこにあるのか、再利用可能にするにはどんなふうに設計すればいいのか。サービスそのものをどんなふうに作るかという点では、恐らく解決しなければいけないところがあるように思います。その辺はユーザー企業、ベンダー企業、そして業界全体でそれぞれ着実に考えながら進めていくしかないのではないでしょうか。

　我々はＳＯＡという言葉を使っていますが、ＳＯＡのアーキテクチャーで実現される、経営者が「このシステムがあるからこそ、うちの経営は支えられているのだ」と実感が持てるようなアプリケーションのことを、コンポジット・アプリケーションと呼びます。私は、これからはやはりコンポジット・アプリケーションの時代へ変わってくると考えています。

　まず、世の中が今どのぐらい変化しているかということで、Ｍ＆Ａの動きを見てみたいと思います。最近は年に約2000件という大変多くの合併・再編が行われており、これだけでもかなり動きが激しいことが分かるかと思います。さらに述べれば、ライブドアがフジテレビとニッポン放送の買収合戦をしかけたということで最近身近なテーマになっていますが、その背景には、規制緩和や手続きの簡素化など、いろいろな意味で合併・再編しやすくなったということがあります。

　ただ、お互いの会社の強みを出し合いながら、または享受しながらやっていかないと、一つの会社が存続していくこと自体が非常に難しくなってきているといえます。

　もう一つの動きとして、例えば自動車会社などにありがちな系列会社は、親会社が主にセットメーカーで、子会社・孫会社がサプライヤーという関係で、親会社に部品を供給して、親会社がそれを組み立てて販売していくという構図になっていましたが、５年ほど前から、脱系列会社という逆の傾向が出てきました。

　今は市場が厳しいので、親会社はコストや納期的なことを含めて子会社にプレッシャーをかけ、子会社は孫会社に同じようなプレッシャーをかけていきます。そのときに、下の系列会社がとる動きは大きく二つあり、一つは市場を中国やインドネシアのように人件費の安いところに求めていくという動き、もう一つは親会社からの依存性をだんだん薄くしていくという動きです。受注率を50％以下にして、一つの会社が傾いても自分たちの会社が引きずられないようにする、あるいは、全く違う業種を系列に組み込んで、他社と組むことによって力を強めていくということです。１週間ほど前、「系列会社への回帰」という見出しの記事が日経新聞に載りましたが、こういった動きがまだあるということはご記憶いただきたいと思います。

　ではＣＥＯのかたがたの関心事は何かということで、アンケートを取りました。その結果から分かるのは、変化への迅速な対応力を相当意識しているということ、ビジネスモデルそのものを改革しなくてはいけないと感じているということです。

　例えばビジネスモデルという部分をとらえたときに、「フォーチュン」の200社がベスト50に入って脱落していくまでの平均期間は約4.3〜4.4年というデータがあります。これは、一つのビジネスモデルは２〜３年で見直していかないと生き残っていけないということを示唆しています。つまり、ＣＥＯのかたがたはそういったことを察知していて、この二つのことに関心を強く示しているといえるのではないでしょうか。

　こういった世の中の市場変化を敏感に感じて、ビジネスモデルを変えていった一つの例をご紹介します。Ｐ＆Ｇは食料品を主に扱っている会社でしたが、今やヘルスケアやビューティケア事業に主軸をシフトしています。いわゆる「選択と集中」の象徴例だと思います。

　2002年から2003年のセグメント別の成長率を見てみると、スナックやビバレッジ関連は業界的に伸びていないのです。一方、ビューティケアやヘルスケアは、それぞれ14％、16％の伸びとなっています。このような状況下で、Ｐ＆Ｇは食料品関係からどんどん撤退し、ヘルスケアやビューティケアでは積極的に買収をしています。そうやって体力を蓄えて、食品・飲料関連から健康関連の商品に変えていっているという会社です。

　ＣＥＯのかたは、自分たちの強みは商品の開発部分とマーケティング、そしてチャネルマネジメントだと言っています。それ以外の重要な部分、例えば調達、製造、物流に関しては、アウトソーシングすると言い切っています。今までのように、企業の体力に合わせながらすべてのものにフォーカスするのではなく、自分たちの力を集中すべきところとアウトソースして特に強化しない部分とを明確に切り分けていくという一例です。

　ある電機メーカーの情報システム図を見ると、一般的にいわれているように、システムどうしがかなり複雑に入り組んでいます。あるＣＥＯのかたは、ものにはすべて減価償却という概念があるのに、どうしてシステムにはそういう概念がないのだろうと話されていました。つまり、10億なら10億を投資して、あるシステムを作った場合に、当然、回収するわけです。ただ、その会社の人たちは、それをメンテナンスするのに毎年５億必要だと。いろいろな仕様変更や仕様要求にこたえているわけですから、そういう微細な費用はあると思うのですが、大きくとらえると、先ほどの「IT Doesn't Matter」ではありませんが、なぜこんなに金がかかるのだという感覚を素直に持たれています。

　一方、ＩＴ側の実務担当を率いている責任者のかたに聞きますと、そういうことは分かっている、ただ、その時代時代で最善のことをやってきているのだとおっしゃいます。それから、スピードに対する要求が非常に強くなってきていますので、それにこたえるためにもアプリケーション改修の部分である程度目をつぶらなければいけないところもあると。例えば、より汎用的に改修をしたいのだけれども、そこを見詰め直している時間がない。他のプログラムへの影響等を考えると、むしろ共通の部分を切り出したり、オブジェクト思考的に言えば、その部分を洗練して継承し、影響がないような形に持っていくようなことをしている時間がない。そうすると、影響がないような形である部分をパッとコピーして、まず動くことを確認することになる。それから、管理項目が増えますから、取り扱うデータ項目も増える。つまり、テーブルに対する列が増える。これも、やってできないことはないのだけれども、やはり影響がないようにするということをどうしても重要視しなければいけない。そういう積み重ねで、スピードにはこたえてきているのだけれども、３年、４年たつとだんだん重たいシステムになってきているというような感覚を持たれています。

　私自身、何件かのお客様に話を聞くと、その瞬間瞬間を見ると決して大きなミスはしていないのだけれども、５年たって見ると何となく重たいシステムになっていて、昔だったら２週間でできた改修が、同じような変更に２か月ぐらいかかってしまうというようなイメージを持たれています。

　ＳＯＡはこういうところにフォーカスを当てているのかというと、後ほど述べるお話の中から皆さんにある程度感じていただけると思うのですが、少なくともこの解が解ければ、「IT Doesn't Matter」といわれる部分に対しての一つの解答になるかもしれません。このような負のスパイラルから抜け出した企業は、恐らくＩＴに対する投資が非常にすっきりして、ビジネス側からの要求にもこたえられるのではないでしょうか。企業はみんなそうしたいに決まっています。それを実現するのがＳＯＡなのかどうか。ここではコメントできないのですが、ＳＯＡが最有力視されているということは間違いないと思います。

　次に、いよいよＳＯＡ（サービス指向アーキテクチャー）の話をしたいと思います。今日のセミナーのサブタイトルに「ＳＯＡの定義」とありますが、ＩＢＭも含めて各社いろいろな定義があり、ＩＢＭの中でも解釈は分かれています。ガートナーという有名な調査会社も、ちょっと変わった定義をしています。ですから、今日、ＳＯＡの定義を持ち帰りたいと思っているかたがいたとしても、それは難しいかもしれません。

　1980年代半ばから90年ぐらいにモノリシックといわれているメインフレームとオフコンが登場して、90年代前半ぐらいまでにクライアントサーバー、1990年代から2000年にかけてはネットワーク中心型、そして、今はＳＯＡだといわれています。

　その中で、先ほど言いましたように、ビジネス側の要求は非常にスピード感を増し、ＩＴもそれにすぐこたえることが要求されています。もう一つは、矛盾をはらんだことを言いますが、2000年の前ぐらいから盛り上がりながら、ミッション・クリティカルな世界には入り込んでこなかったＷｅｂサービスという技術要素が、だんだんと成熟してきました。それからもう一つは、いわゆるオープンスタンダードがいろいろなところに認められてきて、ＷｅｂサービスないしはＳＯＡにまつわるいろいろな規格が、大きな潮流としては統一されようとしています。

　ＳＯＡとは、別に新しい技術があるわけではなく、今までの技術の集大成です。では、今この時代になぜＳＯＡが注目されているのかというと、その中の強い要素は標準化です。これなしではＳＯＡというアーキテクチャーは語れないのではないでしょうか。必ずしも標準化だけがいいと言っているわけではないのですが、十分条件ではないにしても、必要条件として標準化技術はこれからもどんどん必要になってくると思います。そこで、サービス指向のアーキテクチャーが出てきました。

　今もそうかもしれませんが、1990年代にはもう一つ大きな動きがあって、この10年間、いわゆるＥＲＢパッケージ、業務パッケージが各企業にどっと入りました。ＳＡＰ社が中心となって入れた業務パッケージは、これを入れることによって、全体の網羅性も含め、整合性も含め、お客様にとって間違いないシステムができるということです。

　ＳＡＰ社は、今年ＥＳＡと呼ばれるサービス・オリエンテッドなアーキテクチャーを本格的に発表したときに、今までの10年間を否定するわけではないが、このサービス指向に打って出るということは、ＳＡＰで閉じているモノリシックな世界からより柔軟な世界へ、例えばＳＡＰではないところとＳＡＰとを組み上げることも含めた部分で、「門戸を開く」と宣言しています。そういった時代に来ているのです。

　したがって、ＳＯＡという言葉が語られるときに、モノリシックという言葉を一つの反対名詞のように使い、その中に業務パッケージが現れることがあるのですが、それは言い過ぎだと思います。明らかに業務パッケージそのものの一つのコンポジット・アプリケーションといわれている考え方を導入して、こういったＳＯＡの世界で組み上げられるようなアーキテクチャーを提供しようという動きになっているので、少し注意が必要でしょう。

　縦割りになっていて、それぞれのシステムのプラットホームは違うという現状の世界から、ＳＯＡのステップの第一段階にいくと、業務のプロセスの一つの構成要素をサービスという形でとらえます。それによって、オープンスタンダードの世界に入ると、お客様やビジネスパートナーから言うと取り出しやすくなる、こちら側から言うと提供しやすくなるという状況が実現できます。

　これを、さらに業界スタンダードに持っていくと、垣根が取れて全部シームレスになり、サービスといわれている一つ一つのコンポーネントが透過的に見えてきます。ロケーションも含めて、どこにあろうと関係なくなってくるわけです。

　その世界が実現できると、例えば、ビジネスの要求に応じてあたかも積み木を組み換えるがごとく、ビジネス・プロセス、あるいはビジネスを組み換えることができる。ＳＯＡは、このようなことを目指しているアーキテクチャーです。

　抽象的な話をしたので、実際にオンライン・ショッピングの例でお話をしたいと思います。サイトで買い物をし終わったあとに、サブミットボタンを押した瞬間、ＳＯＡ以前の考え方では、基本的にはビジネス・プロセスと実際のシステムが直接リンクを張るような形で設計されていましたので、極端に言うと、例えば在庫確認のアプリケーションは、在庫管理システムのテーブルに向かってアプリケーションコードが入っていくというイメージでした。そうすると、例えば新配送システムを組み込みたいというときに、当然硬直した設計になっていますので、幾つかに影響が出ます。この影響が大きな問題でした。

　それに対して、ＳＯＡの世界に入ると、もはや直接話はしません。それぞれのビジネスプロセスで、システムのことは一切忘れて、例えば在庫状況を知りたいという要求をサービスに向かって発信するだけです。サービスは、例えば在庫管理システムのＡかＢ、どちらか適正なところに検索をかけて、結果を返します。１番めのセッションの言葉で言うと「仮想化」です。サービス層のアプリケーションは、裏側のシステムを意識させないように作成されています。

　ビジネス・プロセスと業務システムの間を取り持っているのは、サービスという一つのインターフェースです。このインターフェースは、業界で定めたオープンスタンダードによって規定されていますので、ベンダー依存はありません。したがって、一つの業務システムに変更が生じても、ほかの部分に影響が起きないように構築することが可能です。配送システムを変えたい場合には配送手配のサービスだけを変えればいいということで、サービスがアプリケーションの変更を吸収し、利用者に影響を及ぼさないというところがＳＯＡ以前の設計とＳＯＡ後で大きく変わってきます。

　「仮想化」という考え方は、ある本では「隠蔽」、あるいは「カプセル化（encapsulation）」という言葉を使っています。またある本では「関心事の分離（Separation of Concerns）」と、三つの言葉がいろいろ出てきて困惑してしまうのですが、大体似たようなことだと思っていいでしょう。このような世界が構築されるのであれば、さまざまな変化に柔軟に対応できるという考え方です。

　これにさらに柔軟性を保たせるのがＥＳＢ（エンタープライズ・サービス・バス）です。考え方としては、こういったサービス間どうしをどう心地よく連携させるかということで、例えばルーティング機能や変換サービスといった考え方があります。ルーティング機能とは、本当はこのサービスのあとにこちらのサービスへ行って、さらに次へ行くというルート関係があるのですが、それをいちいち要求側が意識する必要がないというものです。「届けて」と言ったら届けてくれる。やはりある意味、仮想化されていて、中身の面倒なところは隠しているということです。

　ＩＢＭは、ビジネスの変化に俊敏に変化して対応できるオンデマンド・ビジネスを目指しているわけですが、それを実現するためのオンデマンド・オペレーティング環境（ｏｄＯＥ）というものを明確に定義しています。その中にはインテグレーションとインフラストラクチャー・マネジメントという二つの大きな軸があり、その一つ、インテグレーションという部分にＳＯＡという考え方をすでに導入しています。

　オンデマンド・オペレーティング環境というＩＢＭの考えるリファレンス・アーキテクチャーの中で、アプリケーション側の部分に対してはＳＯＡを全面的に採用しています。裏返すと、ＩＢＭ自身はＳＯＡというアーキテクチャーに対してかなり本腰を入れているということです。ＩＢＭの考えるリファレンス・アーキテクチャーの２分の１がＳＯＡだということは、少なくともここに大変な力点を置いているといえるでしょう。

　次に、ＢＰＭ（ビジネス・プロセス管理）についてご説明します。ＩＢＭのｏｄＯＥというアーキテクチャーで、ＢＰＭはビジネスプロセス・コレオクラフィサービスとしてマッピングされています。

　もともと、1980年代の後半ぐらいにＴＱＭ運動があり、1990年代には有名なマイケル・ハマーによるＢＰＲにシフトしてきました。既存のビジネス・プロセスを短期間に再構築しようという動きです。大変なブームを巻き起こして、フォーチュン500社は数百万ドルを費やしたと言われていますが、そのうちの60〜70％は期待される成果を出せませんでした。マイケル・ハマーは、変化に対する抵抗、ビジネスモデル自身の理解不足、内部統制の失敗といったものが原因だったのではないかと分析していますが、ＢＰＲという言葉は1990年の前半を最後に影を潜めました。

　そして2002年に『第三の波』ということで、ハワード・スミスとピーター・フィンガーが突然ＢＰＭを言い始めたのです。ＢＰＲとＢＰＭはどこが違うのかというと、ＢＰＲがゼロから全部作り直すという考え方なのに対して、ＢＰＭは既存のものも生かしながら段階的に最適化を図っていくということを主張していました。共通しているのは、ビジネスのプロセスに着目しているということです。よくＢＰＲの延長線上にＢＰＭがあるといわれているのは、こういった経緯からだと思います。

　このＢＰＭという考え方を支援するためのＩＴ基盤が、ＢＰＭエンジン、ビジネス・プロセス監視、デザイン・ツール、シミュレーション機能です。こういったものを搭載した、ビジネス・プロセスを管理するためのＩＴとしてのメカニズムを作っていきましょうという動きが出てきました。これがＢＰＭＳで、ビジネスとＩＴのギャップを埋めるものとして位置づけられています。

　＠ＩＴなどを見ると、先ほどのＢＰＭエンジン、シミュレーション、デザイン・ツールなどに加えて、分析・設計・実行・モニタリングというマネジメントサイクルを適応し、継続的なプロセス改善を遂行しようというコンセプトとされています。ＩＴ用語としては、前述のコンセプトを実行するために複数の業務プロセスや業務システムを統合・制御・自動化し、業務フロー全体を最適化するための技術やツールと定義されていますが、まさに『第三の波』に書かれているＢＰＭというところの、全部取り替えるという考えではなく、少しずつよくしていくという考え方です。

　ＳＯＡとＢＰＭの関係は何か、どちらが上位概念かとよく聞かれるのですが、ＢＰＭ、もっと言うとＢＰＭＳに関しても、標準化の流れはあったのです。まずプロセスに関しては、ＢＰＥＬというビジネス・プロセスを表現するためのランゲージがあって、今いろいろなところで出てきているビジネス・プロセス・モデリングツールは、ビジネスモデルを描くと、最終的にはＢＰＥＬに落ちるようになっています。

　これはどういう意義があるかというと、例えば弊社のコンサルティングファームが支援して、お客様の新しいビジネス・プロセスを定義したとします。今までですとパワーポイントやビジュアルで書いて納品していたのですが、これからは様相が変わって、ＢＰＥＬでファイルで差し上げる形になるのではないかと思います。

　標準規格ですから、ＢＰＥＬを載せるランタイムの製品、ミドルウエアは各社できているわけです。そうすると、例えばコンサルティングファームがアウトプットした新しいビジネス・プロセスを直接ＢＰＥＬとして導出して、他のベンダーのミドルウエア上のＢＰＭＳにぽんと載せるというシームレスな動きが可能になってくるということです。

　それから、グラフィカルに描く以上、標準機能がどうしても必要になりますが、その標準規格も出てきています。どういう表記を用いれば、ビジネス・プロセスの森羅万象を全部表記できるのか、これはＵＭＬ2.0で全部できるのかできないのかという議論が今も繰り広げられていますが、その中でも一般的にこうやって表現しようというのが、ＢＰＭＮ（Business Process Modeling Notation）です。

　ＳＯＡとＢＰＭの関係では、ＢＰＥＬ上で表現されたビジネス・プロセスの一つ一つのアクティビティやタスクも、ＳＯＡから見ると一つのサービスになるというとらえ方が起きようとしています。

　いずれにしても、ビジネスの世界とＩＴの世界をよりシームレスにつなげようとする動きには違いないというところで、一般的にはＳＯＡを実現するためにＢＰＭが必要なのではないか、違う言い方をすると、ＢＰＭを実現するためにはＳＯＡというアーキテクチャーがドライブをかける意味では向いているのではないかといわれているようです。

　結論めいて言うと、ＳＯＡでは、ビジネスを制御するＢＰＥＬの部分とその中のビジネスロジックは完全に分離するような発想に立っています。ですから、ビジネス・プロセスを変化させても、コア部分のビジネス・ロジックには影響がないような形になるのです。

　まとめますと、ビジネス環境の変化がいろいろ起こっていて、その中の一つにプロセスの変化があります。これに対応するためには、プロセスとそれを構成するビジネス・ロジックが分離され、プロセスの変化にアプリケーションが影響を受けにくい構造に持っていく必要があります。これは、現実にその方向へ持っていこうとしていますし、製品もそうなっています。

　もう一つ、＠ＩＴなどでも提唱しているように、ＢＰＭＳという考え方があって、先ほどの構造をベースにした、プロセスの分析から再構築までのマネジメントサイクルを目指しています。

　そして、ＳＯＡは、プロセスの構成をサービスというシンプルで標準なインターフェースを持った要素で実現して、そのプロセスをもＢＰＥＬという標準言語で記述し、実行可能な構造を提供しているということで、以上、ビジネス・プロセスとＳＯＡはかなり親しい関係にあるということをお伝えして、私の説明とさせていただきます。

①ＢＰＲ

　ＢＰＭは、基本的にはＢＰＲ（Business Process Reengineering）という問題から派生してきていると考えています。ＢＰＲが行われた理由として、いろいろと追加されることによってプロセス自身がだんだんと冗長かつ非効率になってくるのを改善し、新しく作り直そうという動きがありました。マイケル・ハマーの本は、いろいろな事例を取り上げて、それを体系化していくというようなところでＢＰＲという名前をつけてきています。

　当然のことながら、あるプロセスを作ると、時間とともにどんどん不適合度が大きくなってきます。最初はそうでもないのですが、あるところで不適合度が非常に大きくなり、融通が利かない状況になると、もう一回プロセスを見直そうという検討段階に入ります。この段階からある時点でのＴＯ−ＢＥを作ると、いったん不適合度は戻るのですが、実際には導入されるまでにタイムラグがあります。ＢＰＲのモデルを作るのに半年から１年はかかりますし、それをＳＡＰで入れようとすると、とても１年では終わりません。ですから、入れたころにはまた不適合度が出てきてしまいます。

　昔のように商品やビジネスモデルの息が長い時代には、こういうやり方でも間に合ったのですが、ハマーが本を出してしばらくするとｅ−ビジネスが主流になり、期間がどんどん短くなってしまいました。そうなると、もうＢＰＲでは対応しきれなくなっているのが現実だと思います。

　また、それまでのビジネスは、自分たちがいろいろなアセットを持っていました。一つの企業体がそれぞれの役割を持ちながら、みんなで協力してグループ企業としてモデルを作っていくというような、Asset Companyの色彩が強かったわけです。ところが、ｅ−ビジネスが出てきたことによって、アセットを持たない会社が出てきました。バーチャルカンパニーという言い方をしましたが、基本的にはビジネスモデルだけを持っていて、製造・販売・流通は持たずにビジネスができるようになってきました。

　そういう会社は物を持っていませんから、変わり身が早いのです。ですから、参入障壁が低くなって非資産の会社が入ってくると、彼らはどんどんプロセスを改善して顧客へのサービスを向上していき、それに耐えきれない会社は消えていくことになります。そこで、資産を持つ大手の倒産がこの時代に幾つも出てきました。つまり、現在はＢＰＲだけでは対応しきれない部分が出てきているということです。

②ＢＰＩ

　ＢＰＩ（Business Process Integration）は、あまりプロセスに関係なく、いろいろなビジネスを分析してつながなければいけないときの最適化をするためのツールとして、ギャップを埋めるためのシステム・ソリューションとして、そういうことができますという形で、リアルタイムの連携やワークフローその他を使ってプロセス・インテグレーションを行うというようなところで出てきた言葉です。

③ＢＰＭ

　ＢＰＭ（Business Process Management）とは、業務プロセスを見直して改善・向上を行い、顧客サービスの向上を行う、もしくはコストの削減を行うなどいろいろあるのですが、ここでキーになるのは「常に見直す」ということです。基本的にはマネジメントをするということで、マネジメントというと日本的には経営や管理と考えるのですが、アメリカ的には、プランに対して実行し、評価して、それをまたプランにフィードバックするというサイクルを回すことを言います。ビジネス・プロセスも、このようなマネジメントサイクルでやっていくというような形で考えていきたいと思います。

　先ほどのＢＰＲが市場に対しての不適合度を戻すという行為だったのに対して、ＢＰＭは市場価値を上げるためにあるのではないかと思っています。つまり、不適合だから調整するのではなく、より積極的に新しいサービスを作ったり、行っているサービスを改善・向上するための手段として、こういうマネジメントサイクルを回すのだということです。

　ですから、いったんＢＰＭでプロセスを作ると、他社と比べて競争力が上がります。市場価値も上がってきます。ただ、どこかが同じようなことをしてきますので、追いつかれて、だんだん市場の動向に等しくなってしまいます。そこでおしまいになると、その会社はまた普通の会社に戻ってしまうのですが、マネジメントサイクルを回している会社であれば、次のことをもう考えるわけです。今度は何でやるか、もしくは、自分たちが今持っているコンピテンシーであれば、より向上させなければいけない。そのためには、市場からフィードバックとして戻ってきたものを分析して、次のプランに役立て、次のプロセスを作っていくというような形のプロセス・ライフサイクルを回していくというのが、ＢＰＭのやり方です。

　ですから、かなりの覚悟を持ってやらないとＢＰＭはできません。日本の会社のマネジメントサイクルは、よくて四半期、悪ければ半年、１年というところがあると思うのですが、こういうプロセスのライフサイクルを回そうとすると、１か月、長くても２か月で次のことをやっていかなければならないので、慣れるまでは追いかけられる気分になる部分もあると思います。ただ、それが成果として出てくれば、落ち着いていくのではないかと思っています。

　先ほど出ましたが、ＢＰＭという言葉は『第三の波』という本で体系化されているのですが、基本的にはそんなに古い話ではありません。これもやはりアメリカ的なところで、いろいろな企業がやっているケーススタディをした結果、こういうことがプロセス・マネジメントではないかという形でまとめられていますが、別の本に、ＭＩＴの教授によるデルコンピュータの話があります。

　その教授が行ったとき、デルはけっこう広い工場の全体を使って物を造っていましたが、デルはそのころ急成長していますから、半年後にはトランザクションが倍になったそうです。日本の経営者なら、もう一つ工場を建てなければいけない、物を買わなければいけないと考えるでしょう。そうすると、非常にリードタイムがかかるわけです。しかし、半年後にそこを訪ねたときには、同じ工場なのですが、ラインは半分だったそうです。倍のトランザクションを半分のラインでやったということは、生産性を４倍に上げているということです。デルは常にそういうマネジメントをやってきたという話でした。

　ご存じのとおり、デルはＢＴＯというモデルで、インターネット受注で無店舗、短納期、お客様に一台一台カスタマイズして渡すというビジネスモデルでやっています。当然、こういうものが売れると分かった途端に、いろいろなＰＣメーカーがインターネット受注を始めました。デルは最初は値段で対抗していましたが、納期をさらに短縮して、コストを下げて、値段を下げてというようなことを、常に他社に先駆けてやっています。他社が追いついたときにはもう次のことをやるということで、いつまでたっても追いつけない。そうすると、相手はどんどん撤退していく。そういうことをモデルと常なる改善で実現し、まだ油断をせずに一生懸命回しているという状況だと思います。

　ＢＰＭについて、今までベンダーは、プロセスをＧＩツールでお絵かきできます、プロセスを可視化できますという説明をしていました。モデリングツールを使って書いて、その下にあるプログラムやサービスをコンポーネントとして取り込んでいけば、それが自動的に流れていきます、これを変えたいときにはＧＩ上でこうやって変えられます、便利でしょうという話しかしていないのです。

　それでどうなるのかというところで、今日はお話をさせていただいているわけですが、結局、ＢＰＭの最終的な目的は付加価値を創造するということで、経営に対してのインパクトを前面に立てた形のプロジェクトをやらなければいけないと考えています。

　では、もっと具体的なベネフィットは何かというと、まずスピードです。ＢＰＭをやるためには、プロセス・モデリングのツール、プロセス連携のためのツールなどが必要になるのですが、それを入れることによって自動化ができ、並列処理で期間を短くすることができます。

　それから、プロセスの可視化です。マネジメントがしっかりした大きな会社ですと、業務プロセスを文書化されているところもあると思いますが、文書化にはお金がかかりますから、そういう投資にあまり重きを置かないような会社ではなかなか文書化が進まず、人から人へ口伝えで伝えられることになります。そうすると、業務改善をしたいときに、この人は今このプロセスをやっているから、この人を引きはがしたら動かないから待ってくれということで、非常に大変なのですが、そういうものがなくなってくるということです。

　それから、プロセスのアカウンタビリティということで、私どもも100％アメリカの外資ですので、弊社のプロセスはどうか、アカウンタビリティはどうかということが全部文書化されています。それにのっとっていない売り上げがブッキングされると、監査が入って、これはエビデンスが足りないから売り上げとしては認められないというようなことを議論していたわけですが、日本にもこれからそういうものが入ってくると思います。それに対して、「当社はこうやってやっています」というようなことが絵として出せるということです。

　それから、フィードバックとコントロールということで、ＢＰＭをやるときには、プロセスの実行時間やプロセスの属性データと、その中を流れているトランザクションのデータの二つが取れるようになります。トランザクションのデータは、だれでも注意を払うのです。経営者は非常に大きな売り上げが上がったときには喜びますし、それが解約されれば「なぜだ」とどなります。それに対して、プロセスの時間が変わっても、だれも喜びません。マイクロソフトのコマーシャルで、１セント安くなった、それが年間100万件あるから３億円安くなる、コストが下がると言っていますが、そういうことをなかなか日本の会社はやりません。そういうものが見えるようになってくるというベネフィットが出てくると考えています。

　では、具体的にどうやってＢＰＭをやるのか。『第三の波』という本にあるモデルは、基本的には、現状分析から始まって、デザインして、システムに載せる、ＩＴ化する。そして、実行して、分析するという形です。

　この本には、もう一つ、実行としての土台をどうやって考えるかというような形で書かれていて、サーバーが要るとか、実際はそういうものが一元的に見えなくてはいけないという、ユーザーインターフェースの統合という意味ではポータルが要るとか、このシステムをどう管理していくかというようなコンソールも必要になってきます。これはアメリカ人のいちばん得意とする部分だと私は思っているのですが、いろいろな企業のケーススタディをベースにして、それを体系化して絵にしています。こういうやり方があるということです。

　このようなモデルが書かれていて、常にプロセスマネジメントをしているような会社が出てきて、今またなぜＢＰＭなのか。今、ＳＯＡが非常に盛んになっているのですが、そういうもののコンポーネントの中に、モデリングツールやワークフローというものがあります。モデリングツールやワークフローは昔からあったのですが、今やっとエンタープライズワイドに使えるようなものになったのです。

　昔は、モデリングツールで企業全体を書いたとき、それを管理することができませんでした。それが、階層化などの機能がついたおかげで、やっと全社的なものを解析できるようになりました。

　ワークフローツールに関しても、前はどちらかというとフロントのドキュメント・ワークフローの部分がほとんどだったと思うのです。それに対して、最近はインテグレーションツールとのインターフェースがちゃんと取れるようになってきたというような形で、エンタープライズレベルでのワークフローも考えられるようになってきました。

　さらに、２〜３年前からＢＡＭ（Business Activity Monitoring）が出てきたことによって、今、本当にＢＰＭができるようになったというのが正直な感想です。モデリングツールだけでは、お絵かきしてきれいになりました、よかったですねということです。次は、どうやってそれを維持したらいいのか、どこを改善したらいいかというボトルネックが分かるのかというところですが、それまでのモデリングツールでは取りきれない状態だったわけです。ワークフローツールなら取れるのかというと、一部持っていますが、全社には適用できませんし、ドキュメント・ワークフローみたいなものでしかないということで、肝心なところのデータがどちらもうまく取れない。それが、ＢＡＭのツールでやっとカバーできるようになってきたのです。

　そして、トータルには、ＥＡＩというインテグレーションツールの上にそういうものが載ってきたことによって、全社的にインテグレーションからビジネス・パフォーマンス・マネジメントができるようになってきた。ですから、今なぜＢＰＭと言っているかというと、それなりの理由があるのです。

　そうはいってもまだ高いのですが、これをコモディティ化した値段になったときに始めたのでは、競争には勝てません。ですから、全部買えとは言いませんが、どこかを自分たちでやろうとしたときに、やはり先に手をつけてビジネスのアドバンテージを取るというところで、どこまでなら投資として認められるのかというようなことをお考えになる必要があるのではないかと思っています。

　先ほどの田中さんの話にもあったように、ＩＴは要らないのではないかという説が出てきています。なぜかというと、ＩＴではＲＯＩがなかなか見えないではないかということがあるのですが、ＢＰＭであれば、どれだけプロセス改善ができたかということが、非常によく見えるようになります。指標の選び方もいろいろあるのですが、指標の中で選んだものと、プロセスツール上で書かれている、モデリングツール上で書かれている、それを実行する人のコストなどがみんな乗せられて、それがどのプロセスで幾らかかって、トータル１トランザクション幾らかかっているかが見えるようになりますから、そういう意味でいくと、非常に改善の効果が分かりやすくなります。

　それが実際の経理上の数値になるかどうかというと、日本の会社が人を切れるかという話になってしまうのですが、ＩＴとしてはこれだけのコスト削減ができるというところがはっきりできるということです。

　ちょっと話は横道にそれますが、ＩＴが本当に役に立ったかどうかということを考えると、いろいろあるのですけれども、30年前からやっているビジネスを今の時代に同じように続けてきたとき、データボリューム、トランザクションボリュームは何万倍になっているはずですね。30年前には非常に小さい都市でしか仕事をしていなかったような人たちが、今はグローバルに展開するようになっていますので、何万倍にも膨れあがったトランザクションは、人手だけでは処理できません。ＩＴがあって初めてそういうビジネスが可能になったわけです。ですから、世界の労働生産性向上の中にＩＴは全然加味されていないのですが、ＩＴは必ず何らかの役割を果たしています。見えないから計られていないのですが、企業内においては、ＢＰＭを導入することによって可視化できるのではないかと思っています。

　『Business Process Management 'A Practical Guide'』という本では、開発のやり方をModel、Automate、Manage、Optimizeに分けていますが、いちばん大事なのはモデリングです。

　どこの会社も、業務プロセスのモデリングをやると言うと、非常に嫌がります。コンサルティング会社も非常にお金が取れるところなのですが、非常にリスクも高いのです。先ほど言いましたように、業務は属人的になってしまっていますので、その人を呼び出さないと分からない、でもその人は日常の業務をやっているから時間を割けないというような話に必ずなって、つまらない小さなプロセスマップを10枚書くにしても、２〜３週間かかってしまうのが現実的だと思います。そういうようなことがあって嫌がるのですが、こういうプロセス・マネジメントやインテグレーションをやるときには、必ずこれをきっちりやらないと手戻りも多くなってしまいますので、非常に大事です。

　モデリングの責任はプロセスオーナーであって、やるのはプロセスの実務担当者です。プロセスの文書化のために、プロセスマップやフローチャートという流れと、どういうルールでそういう作業しているのか、だれがそれをやっているのか、それから、大事なのは、何のためにやっているのかということがあります。そうすると、二つ三つ同じようなことが出てきて、同じ目的のために三つの仕事を走らせている、３人の人がいろいろなことをやっているということが分かるわけです。その３人の人たちがそれぞれに責任を持ってやっているのならいいのですが、同じ責任のもとで上位レイヤーと下位レイヤーの人が三つも同じことをしていると、それでいいのかというようなところが見えてきます。

　そういうものをきっちり書いて、次にＩＴデザイナーが作業の電子化をします。まずデータとして取り込んで、そのうえで、人がやっているところを紙でつないでいるのをデータでつなぐのか、機械で自動的にできるのかというようなところのシステム化のデザインをしていきます。

　これを導入して、動いたからいいというわけではなく、ＢＰＭはここから先がいちばん大事になってきます。これはまだ第一ステップをやっとクリアしたぐらいのレベルです。

　続いて運用です。プロセスサイクルを回しますから、そういう意味でいくと次はマネジメントになるのですが、日本で問題になるのは、このマネジメントをするときのプロセスマネジャーはどんな人がやるのかというところです。今の日本でプロセスオーナーといったときには業務のマネジメントクラスのかたが多いと思うのですが、ではその人たちが本当に見るのか。見せるのがＢＰＭの目的なのですが、今自分たちのプロセスがどうなっているのかということをマネージする。それから、当然、モデリングしたときに抜け落ちるものがありますので、その例外処理のハンドリングをしていかなければなりません。

　最終的に、Optimizeという形で分析をします。マネジメントを課長がやっているとしたら、分析は部長クラスの担当になるでしょう。自分たちのビジネス・プロセスにはどれぐらいのコストがかかっていて、人が足りているのかいないのかといったことを分析し、その権限で人を動かしたりしながら、仮説に基づいて次のアクションをとるというようなところです。分析した結果、仮説を立てて、その仮説に基づいたモデルに組み直して、また実行していくというようなプロセスサイクルを回す形になります。

　では、どういう指標を取ったらいいのかという話ですが、トランザクションのデータに関しては会社によっていろいろありますので、ちょっと置いておきます。ここではプロセスの指標としてはどういうものがあるかということで、まず、経過時間があります。あるタスクを実行するに当たって、前のタスクが終了してから自分のタスクが終了するまでの間、現実的には前の人からもらって次の人に渡すまでどれだけ経過したかという時間です。この経過時間の内訳の一つが、作業時間です。これは人が作業している時間です。それに対して、作業を頼むまでの伝達時間、作業にかかるまでの待ち時間もあります。時間軸的にはこのようになります。

　あとはコストを見なければいけないのですが、Ｂというステップの作業をする人の役割、例えば承認者なのか、ただの作業者なのか、単価は幾らなのかというようなことを全部押さえなければいけません。それから、その作業自身が付加価値のある作業なのか。付加価値があるから社員がやるとか、単純作業でただの処理だから派遣やアルバイトの人にやらせるというところと、判断が入るなら判断のできる役割のかたにやっていただかなければいけないというような属性をとらえていきます。

　プロセスマップを書く分析の中で、ここまで基本的に押さえます。待ち時間や作業時間はシステムを動かして始めてみないと出てこないと思いますので、それが正しいかどうかはそのあとの分析の中でやっていかなければいけないのですが、とにかくこのようなところを押さえていくということが大事になります。

　アプリケーション的に見れば、ＢＰＭはミドルウエアで大体組み上がるのですが、それを動かすもとになっているシステムがけっこう大事です。弊社もフロントからバックエンドにつなげるためのワークフローの仕組みなどをやっているのですが、オートメーション化をしたり、ワークフローでトランザクションに乗せてしまうと、システムにトラブルがあるとすべての業務が止まってしまいます。代替手段はとりにくいので、それが起こらないようにしなければいけないということです。

　そこで、まず拡張性が必要です。これは、データ量が増えたら拡張するのではなく、データ量が増えるのを予想して拡張しておくということです。データ量が予想以上に早く増えてシステムのキャパシティを超えてしまうと、トラブルが起きやすくなりますから、その前に何か手を打たなければなりません。そのためには拡張性が大事だということです。それから、プロセスという形でいくと、時間軸的に早く処理しなければいけません。そういうところで、ハードウエアやアーキテクチャーなどを処理の規模や複雑度に合わせた形で設計することが大事になってきます。

　それから、ワークフローにトランザクションが入って電子化されてしまうと、そこが中断したら後続につなげられません。手入力するという代替手段は、いろいろな意味で時間もかかるし、複雑度も高いので、システムをダウンさせないということが第一の目的として出てきます。そういうところで、信頼性の高いシステムを作らなくてはいけないということがあります。

　とはいえ、やはり障害が起こってしまう可能性はあります。そうしたときに、障害検知の仕組みをきちんと作っておかなければいけません。サーバーがダウンしてしまったら立ち上げるしかないのですが、サーバーがつながっているいろいろなところの障害検知をして、相手側が障害を起こしていてつながらないときには、どれぐらいの障害許容時間があるかということも決めておかないと、いけない状態になっているのか、いい状態になっているのか分かりません。ですから、検知方式と障害の許容時間をきっちり決めておくことが、設計上、非常に大事になってきます。

　弊社は、ＥＡＩのインテグレーション、それからモデリング、ビジネスアナリシスの部分といった形でのソリューションをご提供しています。今日のトピックで言えば、インテグレーションの部分がサービス・バスですけれども、こういうものを提供して作れるようになりました。あとは、企業がどこまで本気になってやるかというところだと思います。パイロット的に限られたエリアから進めるというのは当然のやり方だと思うのですが、その辺をうまくやって成果を出していくことが必要になってくるのではないでしょうか。

　ＳＯＡでは、今、いろいろな標準が作られています。もともとはＳＯＡＰとＸＭＬだけだったのですが、それだけではシステムにならないということで、ＢＰＥＬ、Portals、ＢＡＭなど、いろいろな標準が決められています。Interoperabilityでは、それぞれで作ったものが相互運用できるかというようなことをやっています。このような標準のもとで、時間軸的にいくとまだ先の話になるかもしれませんが、今までのＢＰＭなどのソリューションまで取り込む形でＳＯＡに乗っていくというところまでできてきていると思います。

　弊社の事例ですが、古くから弊社のＥＡＩをお使いいただき、インテグレーションやプロセス・オートメーションをされているお客様がいらっしゃいます。しかし、データの精度に問題が出てきており、そのために注文の検証エラーやＥＲＰへのインポートエラーなどが出ているので、ビジネスのモニタリングをして何とか精度を高めていきたいということでした。この対応には当然人件費などお金がかかりますので、そういうところを何とかしていきたいというような形でやられています。

　この会社はSibelとオラクルＥＲＰを使っていて、その間に注文のインターフェースがあるのですが、この三つのところにデータを監視するポイントを作りました。１件当たり問題を発見して解決するコストは85％減りました。それまではエラーが起こってからやっていたのを、取り込む前にエラーを検知して、早い段階で解決することにより、機会損失も25％から75％減りました。逆に、お客様へのサービス面としては、納期を守れるようになったという形で改善されてきています。

　どうやったかというと、システム的に先ほどの三つポイントでデータを取り、それをＢＡＭの機能でモニタリングしていきます。データに不具合があれば、その時点でアラームが出るので、結果として、最初は非常にばらつきがあった出荷までの時間が、だんだん短いところに収束してきました。

　これによって、年間300万ドル、約３億円のコスト削減が可能になっています。しかも、お客様へのサービスも向上しました。190万ドルの誤った注文を回避することができ、問題解決に要する時間が24時間から４時間になっています。納期の遵守率が5.5％増えて、滞留注文も最大75％まで削減しました。

　これまでは、エラーがあるために処理できないというトランザクションがあったのです。これは、経営から見ると大きな問題だと思います。受注としては上がっているのですが、ＥＲＰに入らないということは、ブッキングできない。そうすると、営業が言っている数字と経理が言っている数字が全く違ってきます。しかも、営業が言っている数字が、キャンセルされたら減るわけです。そうするとマネージできない世界になるのですが、そういうところが減ってきました。

　このお客様は、ＩＴ部門主導で、ある事業部と組んでこのプロジェクトを進められました。最初のプロジェクトだけはＩＴ部門がある程度コストを持ってやり、非常にいい結果が出たので、そこから先は事業部のほうがコストを持って、横展開しています。これで、大体１サイクル３か月です。当然、継続的にマネージされていくのですが、３か月たつと新しいエリアに移っていって、マネージエリアを３か月ごとに増やしていくというようなことを今されています。

　このような形で、アメリカでは、徐々にではありますが、ＢＰＭによる成功事例が徐々に増えてきています。