クラウド: 2009年11月アーカイブ

ＳＯＡなんか使えない、そんな声も聞く。ある意味でそれは正しい。なぜなら、ＳＯＡ化を成功させる要素がいくつか欠落しているからだ。ＳＯＡそのものの目的と自分たちの目標とするものが一致しているのかという根本論からはじまって、（必要最小限の）ＢＰＲの欠落、機能仕訳の甘さ・・・などなど。しかし、最も大きいのは、優良なサービス、つまりサーバサイドの部品の選択肢が少ないことだ。ＳＯＡの真価はサーバサイドの汎用化、部品化によるコストと工期の削減にある。しかも、たとえばより処理性能のいいサービスと入れ替えたとしても、フロントであるユーザインターフェイスへの影響は少ないし、ユーザにとっての使い勝手は変える必要がない。しかし、サービス、つまり、サーバ側の部品の選択肢が、少数のパッケージベンダが提供する独自仕様のサービスのみであったとしたら、苦労をしてＳＯＡ化する意味も薄れてしまう。こればかりはユーザがいくら頑張っても、解決は難しい。

ＳＯＡに至るシステムアーキテクチャの流れは、小さな湖でせき止められてしまうかに見えた。しかし、やがて、この流れも、あふれて大きな海に流れ込む。インターネットという大海にだ。そこで、他の水と混ざり合い、新たな命をはぐくむことになる。

こうして、インターネットという海は、すべてのＩＴの流れを受け止めて、大海となり、水はまた空に戻って雲となる。この雲の中には、すべての川の流れによって持ち込まれた水が混在している。いや、存在していなければならないのだと私は思う。次の章では、雲の成分について、少し詳しく考えてみよう。

（１章終り）

ソフトウエアの生産性を上げるための取り組みの流れをもう一度考え直してみよう。標準化にしても、構造化にしても、オブジェクト指向にしても、すべてプログラムの再利用もしくはもう一歩進めて汎用的な部品化を行うための考え方だと言える。このためには、似て非なる処理に共通した部分と違う部分を徹底的に洗い出し、分離することや、必要に応じて、プログラムの構造を、それに適した形に変えてやることが必要になる。

ビジネスロジックの部分でも、それは同じだ。後者がＢＰＲならば、前者はビジネスロジックの汎用化である。幹と枝葉をきちんと分離できれば、多くのビジネスロジックは共通化できる。これまでパッケージではこの作業が行われてきた。それにより、ユーザのカスタマイズ要求に対して、変更が必要な部分を局所化して、カスタマイズ作業の負荷を減らすことを目指してきたわけだ。ただ、パッケージという、ある意味で閉鎖的な環境の中では、この共通化という作業はそれ以上の意味をもたない。だから、案外、この仕分け作業は中途半端に終わってしまい、時にはユーザの要望に応じるために、本来共通化されているはずのロジックにも手をつけざるを得なくなってしまう。だから、こうした作業そのものが無意味だという極論を言う人もいるわけだが、むしろ、パッケージという閉じた世界では、無意味というよりもそれを徹底的にやるだけのメリットが、ベンダにはないのだろう。カスタマイズの余地が多いほど、そのパッケージを使ってカスタマイズする仕事が増えるからだ。つまりは、パッケージを担いでくれるＳＩ会社の仕事を増やすことにつながり、そのパッケージが好んで提案される理由となる。ユーザにとって使い勝手をよくするカスタマイズが柔軟に可能である・・・という理由が表向きの話だが。

これはベンダ目線にほかならない。ユーザ側から見れば、工期や工数を削減する目的でパッケージを選んでいるはずなのに、実際は、カスタマイズに大きな費用がかかり、工期もどんどん長くなる。ユーザから見れば、こんな馬鹿げた話はない。おまけにビジネス環境はめまぐるしく変わるのだから、それになかなか追い付いていけないＩＴは常に経営陣の悩みの種になってしまう。ユーザから見れば、最初の段階でシステムのそれぞれに機能に選択肢があり、それを組み合わせると必要なシステムが出来上がるような、いわば、システムのＢＴＯ（Build To Order）モデルがあるといいわけだ。パソコンのＢＴＯは、ＣＰＵ，メモリ容量、ＨＤＤの容量、周辺機器など、様々な仕様をユーザが指定したとおりに組み立てるものだが、必要なパーツは規格化、標準化されていて、メーカーはそれを組み合わせて組み立てるだけである。（厳密にいえば、これはＣＴＯ（Configure To Order）とも言えるが、CTOは標準製品の一部だけを別仕様に変える、もしくは選択する・・という意味のほうが強いのではないかと思うので、パッケージのカスタマイズに近い）　要するに、システムのＢＴO化が望まれるわけだが、残念ながら、情報システムのパーツは業界レベルでは標準化されておらず、ユーザにとって自由に選択できる状況には程遠い。たとえば、各パッケージベンダが自社のパッケージの一部分を標準化したいと思っても、意外と敷居が高い。記述されている言語も違えば、使っているデータベースも違う。たとえば、ユーザがＡ社の営業系パッケージとＢ社のＥＲＰパッケージの会計部分を組み合わせてシステムを作りたいと思っても、単純にそれを張り合わせることは不可能だ。こうした違いを乗り越える、新しいアーキテクチャが必要だ。

違う言語やデータベースを使って作られた「機能」をうまく連携させて使うにはどうしたらいいのか。こうした違いを超えて、互いにその機能を「呼び出せる」ようにできればいいのだが。たとえば、ネットワーク上のサービスとしてその機能が定義されていて、その呼び出しのインターフェイスも通信手順として標準化されていたなら・・・。

私の目線から見たＳＯＡ（Service Oriented Architecture）とは、このようなものだ。

（続く）

部品化はその粒度が大きくなるに従って難しくなる。様々な要素が加わって、オプションがどんどん増えていくからだ。特に、ビジネスロジックに至っては、その組織ごとに昔からの「やりかた」があり、システムは、それに合わせる形で作られてきた。

ＩＴが補助的な、つまり省力化の役割しか持たなかった時代はそれでよかっただろう。しかし、いまや、ＩＴがなければ不可能な仕事も多い・・・・、というよりＩＴをいかに使いこなすか、ということが会社の生命線にもなりつつある。

ビジネス環境の変化はどんどん加速していく。それはあくなき利潤追求という資本主義の本質と結びついている。他より効率よく、どんどん新しいことを進めていかないと会社は生き残っていけない。ＩＴはそれを支えてきたのだが、いまや、ＩＴ化をどんどん加速しなければ環境の変化についていけない主客転倒な時代になってしまったようだ。

そんな中で、システムのライフサイクルはどんどん短くなり、かかるコストもどんどん膨らむ。そんな状況下では、業務とＩＴを別々に考えているわけにはいかない。人とＩＴを含めた全体を「システム」と考えることが必要になる。これは、ＩＴを仕事にあわせることでも、仕事をＩＴにあわせることでもない。仕事全体の最も効率のよい形を考え、その中で人とＩＴの分担を決めるのだ。つまり、業務全体に対する見直し（ＢＰＲ)が必須になってくる。これは簡単ではない。ともすれば、ＩＴ屋は人の側をシステムに合わせようとする。いわゆるパッケージ文化はシステム開発は効率化しても、往々にして人にストレスをもたらす。パッケージが提供するモデルは、あくまでその業種の標準的なモデルであり、その組織によって適合度が違う。だったら業務をパッケージに合わせれば・・・と思うのがＩＴ屋のあさはかさ。業務の流れは、長年のノウハウでもある。多くの会社は漫然と同じやり方を続けてきたわけではなく、それなりに自分たちの仕事に合った形を確立させている。したがって、双方の歩み寄りは必須だ。この歩み寄りを合理的に行うために、業務全体の見直し（ＢＰＲ）が必要になるわけだ。これをきちんとしないと、結局、システムへの不満が残ったり、過剰なカスタマイズが発生したりする。

仕事のインプットとアウトプットを明確にしたうえで、その間のプロセスを細分化していくと、複数の業務で類似の作業の存在が見えてくる。これら類似の業務を「手間を増やさずに」どう共通化するかというのがポイントだと思う。共通化したことにより、作業の手間が増えてしまっては本末転倒だ。手間を減らす方向で考えられるかどうかがポイントである。

この共通作業の部分をＩＴ化して効率を上げれば、複数の業務の効率を上げられる。また、逆に、似て非なる処理を作りこむ必要もなくなり、ＩＴコストの削減にもつながる。

言うのは簡単だが、実際には難しい問題が多いのも事実。こうしたＢＰＲをコンサルタントにたのむ会社も多いのだが、多くの場合、「まる投げ」が発生する。結果として、コンサルタントは、その会社のすべての部門を相手にして、ヒアリングやらとりまとめやら、ひどい時には部署間調整までやらされるハメになってしまう。これではコンサルタントはそれに見合う費用をもらうか、どこかで線を引いて「腰が引けた」作業に徹するかのいずれかを選択するしかなくなってしまう。少なくとも、会社側にも取りまとめ役、それもある程度ＢＰＲのやりかたについて知識、経験と必要な権限がある人間が必要だ。自前で全部やれればいいのだが、一般の会社で、ＩＴまわりの最新情報をフォローしていくことはなかなか難しいから、その部分はコンサルタントにまかせ、業務まわりは自社で考えることを基本にすべきだろうと思う。

特に日本はこうした「まる投げ」傾向が強いように思う。世の中が、今よりゆっくりと進んでいた、古き良き時代の名残ともいえる「まる投げ」を続けていたのでは、今のグローバル化した経済の中で企業は生き残っていけないと知るべきだ。会社は、それ自身でＢＰＲのエキスパートを最低限の人数持つべきだと思う。ＢＰＲはそれ自体がひとつのマネジメントサイクル（ＰＤCAサイクル）でもある。決して一回きりで終わるものではなく、継続的に改善されるべきものだからだ。経営陣も少なくともそうした知識は持つべきだ。長年の経験は宝ではあるが、それを体系化できなければ伝承もできないし、応用もできない。そういう意味で経営者はＭＢＡくらいは持っているべきだ。特に、経営判断の基準をぶれさせない、という意味では体系化された知識は重要かもしれないと思う。もちろん、経営者特有の「動物的なカン」も必要だが、往々にしてそれは、知識によって体系化された長年の経験から生まれる。

ちょっと話が脱線気味だが、これからの話は、こうした本当の意味でのＢＰＲが前提になってくる。これなしでは、「使えない考え方」になってしまうからだ。せっかく、ＪＳＯＸ対応で業務フローを書いたのだから、一度それを全部並べて見比べながら、業務の非効率な部分を見直してみるといいのではないだろうか。その上で、今のシステム（人＋ＩＴ）の問題や足りない点、共通化できそうな点を洗い出してみるといいだろうと思う。

さて、こうした前提で、ＩＴのアーキテクチャを考えてみよう。

（続く）

システムの構造化といっても、やりかたはプログラムとよく似ている。個々のサブシステムの機能を出来るだけ単純化し、共通化できるものは共通化する。でも、これは言うほど単純ではない。もともとスパゲティーなシステムは、そのプログラムから見直していく必要がある。

特定のデータの検索や登録・変更などの基本的な処理と、そのバリエーションや表現や使い手の利便性を向上させるための処理は可能な限り分離する。たとえば、品物の見積もりを依頼された場合、在庫を調べ、在庫があれば「即納可」として、必要数量を仮押さえ（予約）する。在庫がなければ、標準納期を検索するか、仕入先に問い合わせて在庫と納期を確認する。それから、単価、顧客ごとの仕切り率などを検索して、それらの情報から見積もり書を作成し、内容を確認してから上司のハンコをもらって・・・・。という手順だとしよう。

ここで在庫の検索、標準納期の検索、品物の予約、単価や仕切り率の検索などは、基本的な処理であり、他の作業でも利用される。一方、見積書の作成、印刷もしくはその承認という作業は見積もり作成に固有の作業だ。（もちろん承認などの統制過程は汎用的なワークフローにできるが、その際も、見積もり固有の業務フローは基本ロジックからは分離しておく）

ＤＢＭＳの多くにはストアードプロシジャー呼び出しという機能が用意されている。こうした基本処理をサーバ側に手続きとして用意しておき、それを呼び出すというのが綺麗な形だ。こうした汎用的な手続きをデータベースサーバ側に用意しておくことで、アプリケーションの処理はかなり綺麗なものになるはずだ。

しかし、依然として問題は残る。たとえば、そのような方法で作られた２つのシステムを統合することを考えてみる。企業の合併などの場合だ。しばらくは２システムの並行運用は必要になるが、最終的には統合したい。その際に、既存のシステムのパーツを利用したい。だが、同種の機能をたばねたくても、インターフェイスがまったくことなっているため、アプリケーション側にはそれぞれの異なる呼び出しを実装しなければいけない。まして、こういう整理すらされていないシステムの統合は、ほぼ不可能に近い。

経済状況の変化でＭ＆Ａなどが急激に増加し、また、その規模も大きくなってきた今日、こうしたシステム統合の問題は経営からのプレッシャーも強く、ＩＴ部門関係者の地獄絵図をもたらしがちだ。これをなんとか解決できるアーキテクチャはないだろうか。

（続く）

情報システムは常にビジネス環境の変化に対して後手にまわってきた。結果、屋上屋を重ねるようにして追加、変更を繰り返したシステムはメタボ化し、そのうち命にかかわる事態に陥る。これまで、そうなるのに約３年から５年かかってきたから、システム自体もこのくらいのサイクルで最初から作りなおす、ということが行われてきたのである。

３年から５年といっても、開発に莫大な費用がかかる企業の基幹システムをこのサイクルで作り直すのは大変だ。どうにか開発を効率化すべく、最初に考えられらのが、標準化である。これはどちらかというと保守性を向上させ、システムのライフサイクルを延ばすことが目的だったと言える。あわせて、プログラムの部品化も行われるようになった。単純な例は、よくつかわれる処理を共通化し、サブルーチンにしてライブラリとしてまとめることだ。たとえば、Ｃ言語の標準関数などはその典型だし、アプリケーションのカテゴリごとに、さらに上位の処理をライブラリ化しておけば、開発効率は大幅に上がる。

スパゲティー化を阻止するたえの構造化が言語自体に組み込まれていく話は、先に書いたが、この部品化も同様に、開発環境に組み込まれていくことになる。いわゆるオブジェクト指向の登場だ。プログラムをライブラリ化して標準にしようとすると、同時にそのプログラムが取り扱うデータ構造も標準化する必要がある。ならば、特定のデータ構造に固有の処理を紐付けて一体化できないだろうか、そういう発想から生まれてきたのがオブジェクト指向だ。たとえば、Ｃ＋＋やＪＡＶＡの「クラス」はＣの構造体に、その構造体を取り扱うための関数ライブラリをメンバとして組み込んだような形をしている。クラスで定義されたデータ構造を取り扱うには、そのメンバである関数を使うしかない。だから、データに対して設計者が想定していないような処理をプログラマーが書いてしまうことも防止できる。

オブジェクト指向も、プログラマーの意識変革を必要とした。とりわけ設計者にとっては、いかに整然としたクラスの体系を定義するかということが最も重要になってくる。クラスは、継承が可能だから、基本的なデータ処理のクラス、たとえば、ツリー構造やリスト構造のポインタ処理のクラスを定義しておき、それを継承して、実際にツリー化やリスト化したいデータ構造とその取り使いを行うクラスを作るといった整理が可能になる。こうしてけば、テスト済みのクラスを継承すれば、その部分は追加のテストは不要になる。保守性も上がる。実際、私もＣ言語でプログラムを書く場合は、まず頭の中で全体の処理を描き、必要なパーツを洗い出してから、まずそうしたパーツとなる関数から書きはじめることが多い。オブジェクト指向はこのやりかたを必須としたものだ。だが、これは言うほどやさしくはない。私がそのような書き方ができるのは、何度もプログラムのスパゲティー化に苦しんできたからであって、どうすれば共通化や標準化がうまくいくかを体で覚えているからである。しかし、いきなりオブジェクト指向をつきつけられた開発者の中には、こうした本質を理解できず、結果的にクラスを体系化できないまま、似て非なるクラスを量産するものも出てきた。こうなってしまうとせっかくのオブジェクト指向も意味なしだ。つまり、これらの考え方は、大規模な開発を前提に、トップダウンで効率よく開発を進めていくことを前提にしているわけで、少数精鋭の設計者とその他多くのプログラマーが存在するプロジェクト向けのモデルなのである。つまり、製作と保守を容易にする反面、設計者は、スキルと経験をより要求されることになる。この点が理解できていないと、プロジェクトは悲惨な末路をたどる。

これは、プログラミングという一段低いレイヤの話である。システム全体のアーキテクチャとしてはどうだろうか。先にも書いたように、プログラムのスパゲティー化は阻止できても、システム全体としてスパゲティー化していたのではしかたがない。そういう意味ではシステムにも、ある種の構造化が必要になってくる。

（続く）

アプリケーションの肥大化は、なにも今に始まったことではない。アーキテクチャを問わず昔からずっと継続的に発生している。アプリケーションを機能単位で整理して区分けするようなことはメインフレームの時代から普通に行われてきた。ＩＴの利用が進むにつれて、ビジネスサイドからＩＴに要求される内容がどんどん増えていくのだから、システム側もそれに対応した開発や運用の方法を考えていかないと、パンクしてしまうからだ。

しかし、不幸なことに、オープン化、クライアント・サーバ化の流れの中で、アーキテクチャとそれを扱う技術者、カルチャーの変化に伴い、これまでの流れが一旦途切れてしまったように思う。ともかく、データベース以外のほとんどの処理を、ＰＣ上のアプリケーションに押し込んでしまったため、アプリケーションが複雑怪奇なものになってしまったわけだ。Ｗｅｂアプリケーション化で、これらの処理をサーバ側に戻した時も、同じようにサーバ側アプリは、当初は肥大化し、混とんとした状態になってしまったようだ。

しかし、Webアプリの良い点は、１ページの処理単位で、プログラムを分割できる点だ。１本のプログラムがスパゲティー化する危険性は低くなる。しかし、これは、また一方でこれまでのプログラミングに慣れたプログラマーにとっては、悩みのたねになる。１ページごとに処理が途切れるのだから、その流れの管理、つまりセッション管理を別枠で行う必要が生じるからである。これをきちんと考えてやらないと、処理の遷移が複雑になり、システムとしてのスパゲティー化をもたらしてしまう。おまけに、サーバは１台ではない。対象となる業務単位に冗長系を含む多数のサーバが置かれ、しかもその裏側には巨大なデータベースサーバが存在している。ビジネスロジックは依然としてユーザ向けの画面処理と一体化しており、プログラムが細分化されてしまったぶん、似て非なる処理があちこちに分散してしまって、システム全体としてのコードサイズはふくらんでしまう。おまけに、クライアント・サーバの時と同様に、同時利用者数分のアクセスがランダムにデータベースに集中することで、データベースの負荷は大きくなる一方だ。

結局のところ、クライアント・サーバ型からサーバ集中型に戻したことで、クライアント側の運用は楽になったものの、サーバサイドが肥大化、複雑化し、情報システム、とりわけその改良や保守・運用のボトルネックとなってしまったわけだ。特に、近年、会社の合併などでのシステム統合があいつぐ中、いつまでたってもシステム統合がうまくいかない背景のひとつにもなっている。それもそのはず、情報システムの作り方がバラバラでは、機能の共通化や統廃合ができず、とりあえずは、間でデータ交換をする連携プログラムを作ってお茶をにごしておいて、次の開発で一から作り直し・・・・となってしまうからである。経営統合による効率化という掛け声は、こと情報システムに関して言えば、むなしく聞こえる。

さて、これを解決するいい手段はないのだろうか。

（続く）