プログラムのサービス化ともう一つのメリット

こんにちは

ＳＯＡという言葉を最初に聞いたとき、システム構築の世界に、なぜサービスという概念をもってくるのだろう、また変なことを言い出しなあと、最初は思った。

しかし実際にやってみたり、調べてみたりした結果、今は逆に、なぜ今までこうしなかったのか？と思う。

サービス指向でシステム作りはエレガントである

私が初めてサービス指向でシステムを作ったのは、prototype.jsを使ったときだった。
JavascriptでＵＩを操作する処理を作るためdom(document object)をごりごり操作するプログラミングを書くと、ものすごく難解で冗長なソースコードとなる。少しの機能を作り込むだけでも大変なのに、少しの変更を加えるだけでも、気が遠くなり、うんざりする。私は当初、prototype.jsを利用するためのリファレンスを読み込む手間を考えると面倒だったが、結局、その手間の方がどれほど楽だろうと思い始め、リファレンスを読み利用してみた。

ところが、prototype.jsは驚くほど素晴らしかった。ソースは５分の１以上になり、ソースは少なくなり、シンプルになった。バグは減り、しかも、処理速度はむしろ早くなったようだった。
最初は、prototype.jsのリファレンスを読む手間を面倒がっていたのに、次第に、リファレンスを隅々読み込み、さらに利用できるような機能はないかと探すまでになった。

それはまるで、水道やガスが整備され、椅子やテーブルが用意され、冷えた飲み物や食材を提供するサービスをやっているキャンプ場で、バーベキューをするような快適さであった。

prototype.jsを使うためにリファレンスを読み込む手間はあまりかかってないし、使うための特殊な文法のコードも書いていない。部分によっては自前で書いた冗長なコードを書いたり、自分で書いたロジックを組み合わせることもでき、すべてがprototype.jsを使う必要もなかった。

なぜprototype.jsを使うと、Javascriptでソースを書くのがこれほどまでに楽になったのか？を考えてみたら、prototype.jsがリッチなサービスを提供してくれたからである。リッチなサービスとは、シンプルで速く品質の高いサービスである。プログラマが細々とした品質の悪い冗長な処理をうんざりしながら自前で書くことから解放してくれたのである。

サービス指向とは

サービス指向という言葉じりで考えるからややこしくなる。サービス指向は、オブジェクト指向やコンポーネントのプログラミングと異なり、サービス指向は形式としてはもっと緩い。たとえば、prototype.jsは、Javascriptで書かれたソースファイルであるが、複合したサービスであると言える。
サービスとは、より大きなまとまったコンポーネントやオブジェクトやパーツなどを形式にとらわれない呼び名と考えればよい。

サービス指向設計は、３つの意味がある。
１．システムが外部にサービスを提供している
２．システムが既存のサービスを利用している
３．システム内部がサービス化された構造を利用している

サービス指向が重要なのは、１ではなく、むしろ２や３である。１は、サービスを利用する側ではなく、サービスを提供する側になるというものであり、２次的なものにすぎない。

なぜサービスなのか？

私たちは、快適な都市での暮らしを求める。たとえば電車などの交通機関であり、道路であり、ショッピングモールであり、コンビニであり、エステやスポーツジムやスパ、レストランである。さらに、学校や育児施設、電気や光ファイバーなどのインフラ。快適な都市とは、いわばサービスが集まった環境である。

サービスが集まっていて、それが利用できる環境にいれば、利用者は自前でそれをやらなくてすむ。自前でやるとなると質が低いものになってしまう。質の高いサービスをリーズナブルな価格で利用できれば快適である。

リッチでリーズナブルなサービスが集中していれば、相乗効果でさらに優れたサービスも生まれる。基本的なインフラが充実しているところでは、より上位レベルの複合的なサービスも充実しているものだ。

システム設計も同じ

システム設計も同じである。かつてのシステム作りとは、まるで荒れ地に水道を引き、ガスを引き、道路造りから始まり、商店街を作り、電話線を引き、というようなものなのだ。

それは個々のプログラマーにフロンティア精神を鍛えるにはよかったかもしれないが、プログラマーは、その荒れ地に水道を引く作業を延々とやらされてばかり（もしくは、自ら好んでやってばかり）だ。

基本的なインフラを自前で組んでみることは、基盤となる物事の多くのことを学ぶ上で大事だ。だが、よほど時間やエネルギーがあまっているか、よりよいインフラを構築できるという力があるならともかく、自前で作るのはやめたほうがいい。基本的や充実したサービスをうまく利用し、エネルギーと時間はユーザへのおもてなしの部分にもっと使えるからだ。

サービス化するか

サービス化には３つ方法がある
１．新規にサービスを作る
２．サブルーチンを集約してサービス化する
３．ロジックからサービスを抽出する

２，３は、サービス化されていないもののサービス化である。
２は簡単である。プログラムを１つのサービスのなのもとに集約化してみる。分類し、集約すること。それは、ＪａｖａやＶＢでいうところのＣｌａｓｓになる。
３のロジックからサービスを抽出するとは、ロジックを以下の４つの部分に分けて、切り分けるということである。

１．プログラムに共通する普遍的な処理
２．他システムとの連携部分
３．外部のＡＰＩやＤＬＬやライブラリを利用する部分
４．ビジネスロジック

もう一つのメリットとは

プログラムのアセット化（知的財産化）である。

日本の重要文化財である寺などの建築物には、職人の洗練された技術が十二分に組み込まれているそうだ。寺は施設ではなく、その施設を使って職人が技術を集約化し、保護し、補修し、さらに発展させ、残そうとしたのだと思う。

現在、プログラマーによって書かれたプログラムは、各システムのために最適化されカスタマイズされ、各システムに組み込まれてしまっている。プログラムとは、知恵やノウハウの成果物である。プログラマのノウハウや技術が、各システムの中にばらばらに埋め込まれ、そしてシステムの廃止とともに、消えてなくなってしまう。

それはまるで、職人の後継者がいなく、技術の伝承が行われないまま、職人の技術が廃れてしまうのと同じくらいもったいないことである。私は、よく人が書いて公開された洗練されたプログラムを読み、そこから組み方を学び、それを利用することがある。洗練されたプログラムは、文学や芸術とも言えるほど素晴らしい。プログラムは、知的財産である。それらが失われてしまうことは、プログラマーたちだけでなく、人類全体にとっても損失である。

サービス化をするとは、ばらばらに組み込まれてしまうロジックを集約化することである。ロジックをばらばらに組み込まず、各システムにはサービスメニューとして提供するようにする。
今までにないサービスを提供する必要がある場合は、サービスメニューをより充実させて対応させていくうちに構築したサービスは、多種多様のニーズに応えたリッチで洗練されたサービスができあがる。

それが、プログラマーにとってのアセットつまり財産になるのである。

プログラムをサービスという１つの集合体に集約化し、保護し、補修し、拡張し、そして充実させていくことは、プログラムという知的財産を守り発展させていくことである。

もちろん、ソースコード自体をプログラマーのものになるかというと、そうとも言えない部分もあるが、サービスはそのソースコードやコンポーネント自体に価値があるのではなく、設計そのもの、サービスモデルに価値がある。サービスモデルとは、ビジネスでいうところのビジネスモデルである。
サービスを設計すると、そのサービスをどのように作り上げ、そして利用し、拡張していくか、というノウハウができる。上記で言えば、４つのタイプのサービスノウハウができあがる。そのノウハウは、ソースやプラットフォームに依存もあるが、依存しない部分もある。

プログラムには、出来がよいのも出来が悪いのもあるが、それは作る人が考えることではない。駄目なものは自然と消えるから気にしなくていい。まず、すべてのプログラムには価値があるかもしれないと思って、保護し、財産として残していきたい。

ではまた

＜関連記事＞
本当は単純な「SOA」という考え方 - ZDNet Japan

SOA（サービス指向アーキテクチャ）とは - IT用語辞典 e-Words
サービス指向アーキテクチャ - Wikipedia