オン・デマンドの波をキャッチしろ：The Rational Edge

[Dave West（Group Manager, Segments Rational Software IBM Software Group），＠IT]

　The Rational Edgeでは、エンタープライズアーキテクチャ、Integrated Product Development Capability Maturity Model（CMMI）、システムエンジニアリング、そしてシステム開発を主なテーマとして取り上げてきた。

　実は、これらの記事にはどれにも共通したテーマがある。つまり、“システムと開発チームの双方は、新しいアプローチによって構築し直されるべきである”というものだ。そして、これらの新しいアプローチすべての中心にあるのがプロセスとアーキテクチャだ。アーキテクチャはシステムの構造、さらには、そのシステムの構築に適したチームを定義し、プロセスは開発プロジェクトのライフサイクル（とその基本的な動き）を定義する。

　Software Engineering Instituteのような組織が、これらのアプローチを官民双方の間で推進（システム開発におけるスパイラルモデルのサポートのほか、CMMIも提供）する中、政府プロジェクトではこれらの（新しいプロセス）導入に対する興味が高まりをみせている。また、民間企業にも同じことがいえる。これらの動きは、元々民間企業から発生したものだが、現在の最優良事例の多くが、決してそこで幅広く利用されているわけではない。そして、利用されている場合でも、うまく利用されている例はあまりない。

　本稿では、これらの新しいアプローチが重要な新しい波を示しているのかどうか探究してみたい。具体的には、オン・デマンド・コンピューティングに対するIBMのビジョンが、より良いシステムやソフトウェアの構築に対する一貫した目的に向けて結合したさまざまなトレンドの論理的拡張である理由を詳しく探っていきたい。

　問題は、すべてのソフトウェア関連組織が、この波を捉えられるのかどうかだ。その答えを出すためには、ソフトウェア開発の分野に変化をもたらせている最も大きな力についてみていく必要がある。

■最小限の努力から最大限の効果を

　経済が低迷を続ける中で、企業はコスト削減に重点を置き続け、ソフトウェア開発組織は、最小限の努力から最大限の効果を引き出そうと務めている。これが、システム開発をはじめとする最もコストのかかるビジネスプロセスを一段と細かく監視する動きへとつながっている。偉大な技術革新を活用したいと願う企業の願望と相まって、この財務の監視がおそらくは、現在の変化の波の背景にある重要な原動力となっているのだろう。アーキテクチャやプロセスの改善に対する投資が、コスト削減につながることを証明できれば、会社の上司もおそらくそれを承認することだろう。

　Donald Reifer氏は自著、「Making the Software Business Case」（注1）の中で、下記の表のようなソフトウェア組織の改善に向けた枠組みを定義している。

短縮 製品化までの時間	回避／削減 コスト
生産性 向上	品質 向上
表：ソフトウェア開発組織の改善に向けた枠組み（Donald Reifer案）

　「これら4つの特質が組織によるシステム開発方法論の変更を正当化するためのカギを握っている」とReifer氏は断言する。

　筆者はこのほかに、相互運用性に対する要求、ライバルに対する優位性の維持、そして新市場を活用する力といった変更を正当化するための重要な理由をいくつか加えたい。業界や政府には次のようないくつかの重要なトレンドがある。

　エンタープライズアーキテクチャ：エンタープライズアーキテクチャ構築の背景にある最大の（顧客側の）動機は、政府関連組織と民間企業では変わってくる。政府関連組織では、相互運用性を保証することと、システムの数を削減することが取り組みを最も大きく左右する（2003年1月号の筆者による記事「Unifying Systems and Software Teams：A Holistic Approach to Systems Development」参照）。一方、民間企業では、エンタープライズアーキテクチャが、（自社が）保有するものを理解し、望むものを明確にし、その実現に向けた計画を実行することでITシステムを掌握できるようにしてくれることを望む。エンタープライズアーキテクチャがあれば、レガシーシステムを活用し、これらを利用しやすい情報資産に変えられるようになるのである。

　プロセス改善（CMMIおよびCMM）：組織的な開発能力を向上させるには多数の鍵がある（2003年1月号のRolf ReitzigのCMMIに関する記事「Using Rational Software Solutions to Achieve CMMI Level 2」と続編「Achieving CMMI Level 2 in the Configuration Management Process Area Using IBM Rational Software Solutions」を参照）。多くのシステムインテグレータは、公共事業獲得という動機のためにCMMIに取り組んでいるし、IT事業と開発能力の標準化に対するニーズを集中化する組織もあり、Reifer氏が指摘するように、大半の組織では製品の品質改善とコスト削減の必要性を感じている。

　サービス中心アーキテクチャ（SOA）：ソフトウェアデザインにおいて急速な成長を続けるトレンドが「サービス中心アーキテクチャ」（SOA）モデルである。これは現在、Webサービス経由で社内システムの統合もサポートするようにもなりつつある。SOAは、企業がコンポーネントベースのデザイン原則に基づいて社内のシステムを統合できるようにするだけでなく、選択されて公開された機能に社外のカスタマーがアクセスできるようにもしてくれる。

■オン・デマンドの時代

　これらのトレンドをさらに詳しく説明することは本稿の範囲を超えてしまうが、ここで考えることのできる疑問として、これらのトレンド（そして業界内のほかの各種トレンド）が、今後どのような方向に向かって行くのかという点がある。IBMのビジョンはかなり明確で、これらのトレンドは、IBMの言う「オン・デマンドe-ビジネス」という新たなビジネス状況における企業の成功を支援する。（理想的な）オン・デマンド・コンピューティング・システムは密接に統合され、非常に高機能で、根本的に無駄が少ない。オン・デマンドの世界においては、企業は全体が統合された形で動き、不況を乗り切り、好況のときも費用効果の高い業務を継続しなくてはならないインフラを持つのだ。

　IBMのテレビCMには、「ユニバーサル・アダプタ」を使えば、社内のすべてのシステムが統合できるようになると説明するSEが登場する。皆さんもおそらくご覧になったことがあると思う。このCMを見た政府関連機関に勤務する友人は、「それよりまず人の統合が先だ」とあざけるようにコメントしている。この友人が理解していなかったのは、システムの統合も、実際のところ人から始まるという点だ（人とシステムを別々に考えるのはそもそも間違い）。オン・デマンドコンピューティングは単なる技術（ハード）指向の戦略ではなく、人に重点を置いたものであり、技術がさまざまな人員やチームの間にあるスキルのギャップを埋めてくれる。これについては後ほど説明する。

　では、IBMによるオン・デマンド組織の本質的特質を考えてみよう（注2）。

　高い応答性：組織は需要、供給、価格設定、労働力、そして市場自身などの変化に対応できなくてはならない。例えば、原子力業界の変化に対するGEの対応を考えてみよう。GEは、1960年代に原子力発電所を多数開発したが、1970年代後半から1980年代半ばにかけて事故がいくつも発覚すると市場がほとんどなくなってしまった。GEは即座に対応し、サービス指向の燃料供給会社となることで方針を転換、原子力全盛の時代より現在の方が利益が増えているというのが現状だ。

　多様性：組織の応答性をサポートするシステムやポリシーは柔軟かつ変更しやすい。GEの場合のように、開発部門、営業プロセス、そしてマーケティング業務は新しい業界でチャンスを追い求めるのに十分な早さで変化できなくてはならない。

　フォーカス：これは自分のコアビジネスを熟知することを意味する。これが機能し、競合各社と大きく差別化できるようにするためには、補足的な長所を持つパートナーがビジネス全体を支える補助的機能をすべて実行できるようにしなくてはならない。オン・デマンドの世界では、ビジネスプロセスの実現は、実際には多数の組織によって可能になる。このような統制の欠如が気がかりなため、高い応答性と多様性を取り入れる社内の取り組みを土台から揺るがす複雑な承諾プロセスを導入する組織もあるかもしれない。このようなシステムでは、需要や価格設定に対する最初の変更が取引関係のネットワーク全体を崩壊させる可能性もあるのだ。

　弾力性：オン・デマンド環境は、常時利用可能で非常にセキュリティの高い統合システムの提供がすべてだ。製品投入までのスピードが品質と同じくらい重要なオープンかつ柔軟な世界ではこれが難しい問題になる。さらに、オン・デマンドコンピューティングを成功させるためには次のような新しい運用環境が必要になる。

　統合：オン・デマンド環境は、単に種類の異なるコンピューティング関連資産を接続するだけでなく、社内や複数の企業間でもビジネスが流れるようコアプロセスとシステムを統合できるようにしなくてはならない。

　オープン：環境は導入する技術だけでなく、開発するシステムサービス面でもオープンでなくてはならない。例えば、独自にメッセージング標準を作成するのではなく、業界標準を使って事実上、誰とでもコミュニケーションが取れるようにする。

　仮想化：組織では企業全体のコンピューティング資源（ハードウェアとソフトウェアの両方）を、相互接続の必要な別々のシステムではなく、1つの仮想環境として考える必要がでてくる。

　自動化：エンタープライズシステム全体には（人間の身体システム同様に）問題、変化、脅威に自動的に対応する機能が組み込まれていなくてはならない。

　オン・デマンドコンピューティングの要求が一部のプロジェクトマネージャを非常に神経質にするのは明らかだ。システムを構築するだけでも十分難しいのに、柔軟性と相互運用性を実現し、統合し、セキュリティも高くするとなると作業は一段と難しくなる。筆者には、オン・デマンドの形をサポートするには、上から下まで新しいタイプのマネージャ、つまりシステムの問題としてすべての問題にアプローチし、そのソリューションにシステムの考え方を適用するマネージャが必要であると断言できる。

■システムがすべて

　統合された企業を作り出すために、マネージャは自社が企業としてどのようなビジネスプロセスをサポートしなくてはならないのか、そこにどのような制約があるのかを理解する以外に、サポートするプロセス、コンピュータシステム、ハードウェア、そしてこれらのビジネスプロセスと制約に影響を受ける関係者を徹底的に理解する必要がある。これらがビジネスにおけるシステムの展望の要素だ。これらを別々の要素として理解することも重要だが、オン・デマンドビジネスを成功させるには企業の業務目的を支援するようこれらを結びつける必要がある。

　通常、ビジネスプロセスは、市場（簡単には変えることのできない外力）によって明確に決まる。ビジネスプロセスは、相当な理由のない変更がマーケットシェアの低下につながる競争の激しい環境で業務を行えるようデザインしなくてはならない。しかし、機能を付加するシステムがユニークな機能を提供する（その機能が新しい市場を開拓してくれる）ことでビジネスプロセスに影響を与えることができるのも事実だ。例えば、企業が携帯電話とGPS技術を小売システムに付加して在庫やサプライチェーンの管理に役立てることもできるが、この新しい機能によって小売業者が近くにいる顧客の場所を知り、自社までの道順を教えるなどして、通常は営業に耳を貸さないような重要な人々と直接電話で話す気にもさせてくれるのだ。

　システム面からビジネスにアプローチすれば、相互運用可能な新しいシステムの開発に対して要求管理、アーキテクチャモデリング、シミュレーションなど、完全に実証済みの多数のアプローチを用いることができるようになる。米国政府ではエンタープライズ・アーキテクチャを作成するにあたって、すでにこれを実践している。EAは根本的にはシステム・アーキテクチャであり、システム・アプローチが必要とされる。新しいシステムエンジニアリングに関する米ラショナルソフトウェアの作業はまだ初期の段階ではあるものの明確な記載がある（http://www.rational.com/solutions/systems/index.jsp参照）。これにはソフトウェア開発で完全に実証されたラショナルの6つの最優良事例（注3）が一段と広い範囲で適用されている。

　オン・デマンドの世界を本当に活用するにはシステムの問題として、社内でアプローチし、これらの最優良事例を適用するしかないというのが筆者の意見だ。

■さあ波に乗れ

　筆者が紹介したのは現在の業界トレンドと、その原動力のごく一部だが、これらは数的には少ないものの、最も重要なものだし、オン・デマンドのビジョンはこれらを論理的に拡張したものだと思う。「最小限の努力から最大限の効果を得る」ことを至上命令とし、企業の競争力を維持するため、開発組織は今、オープンで仮想化および自動化され、オン・デマンドの世界で活躍する統合システムの作成に励んでいる。それにはシステム思考を開発手法に適用する必要があるのだ。

　さて、大半の組織はこのように考え、行動に移しているのだろうか？ われわれは実際に新しい波に乗っているのだろうか？ 私はそうだと言いたいが、われわれの業界では（どこのサーフィン場でも同じだが）、波は1つ通り過ぎても次があると言われる。おそらく多くの組織では、今、この波に乗るべきか、ほかのサーファーが乗るのを待つべきか、あるいは次の波を待つべきか、と考えていることだろう。それに対する筆者の答えは「良いと思ったら迷わず乗れ」だ。波は浜辺に近づけば近づくほど乗るのが難しくなることを忘れてはならない。

---

---