watermint.org » architecture

SOAについて考える, その1

Takayuki Okazaki — Sat, 30 Aug 2008 23:18:44 +0000

まずはものすごく大雑把に仮想的な目標を考えてみることにします．まず家の中を見回してみて，そこにあるものを仮にITシステムと見なすことにしましょう．たとえば，冷蔵庫やテレビ，本棚，洗濯機，勉強机，いす，ソファ，ステレオ，クローゼットなどです．私たちは普段あまり意識しませんが，日常生活において実に多くの道具を使っていることに気づきます．さて，これらの家財は普通，引っ越しをしたり，新たに買いそろえたときに機能的に使えるよう配置します．本棚や，勉強机は勉強部屋や書斎におくでしょうし，冷蔵庫や電子レンジは台所に配置します．もちろん，大掃除をするときには配置を換えてみたりすることもあります．

引っ越しをして荷解きが一段落した後や，大掃除をした直後には，家財は本来のもつべき役割を最大限発揮しています．たとえば，本棚には本が格納されているでしょうし，勉強机はノートや本が広げられるよう十分スペースがあります．ところが，ある程度時間が経つと，本棚に本が入らなくなったり，新たに陶芸の趣味を始めたりすると，今までは整然と本が並んでいた本棚に，本のかわりに陶芸の道具が格納されたり，勉強机の上に本が積み上げられたりと，すこしずつ本来の役割とは別の使われ方にかわっていくことがあります．場合によっては，面倒くさがって陶芸の道具さえも机の上に出しっぱなしになるかもしれませんし，家族の誰かが物を移動させたり，別のものをおき始めるかもしれません．

この状態が進むと，家財は本来の便利さを急速に失い始めます．ものがどこにあるか分からなくなったり，勉強のためのスペースが十分に確保できなくなる場合もあります．このため，ある段階を超えると大掃除の実施を強いられ，丸一日の労力が必要になります．新たに本棚を買いそろえたり，作業机を買い足すならば計画を含めもっと多くの時間が必要かもしれません．家族とスケジュールをあわせるために仕事を休む必要があるならなおさら大変でしょう．さて，そろそろ問題点と目標がなんとなく，想像できそうです．

問題点は，ある程度時間がたつと部屋が散らかってしまうことです．また，部屋自体も使いにくくなります．さらに，できれば大掃除のために休日をつぶすのもさけたいでしょう．目標はこれらの問題点を解決することです．具体的には，部屋が散らからないように維持することや，部屋自体の使いやすさを保つこと，さらには大掃除をしなくてもよくすることです．

さて，話をITシステムに戻して，問題点と目標をおさらいしましょう．企業や組織のITシステムは家の家財道具と同様に，多くのサブシステムで構成されており，それぞれの役割を担っています．ところが，新たな商品を扱うなどの新しい要件が生まれると，場合によっては予算や時間的な制約により既存のシステムでだましだまし要件を満たすように使ってしまう場合があります．この状況が続くと，サブシステムの持っていた本来の便利さは失われ，場合によっては全く使われなくなり，手動で業務が行われてしまうかもしれません．このような状況を想定するなら，目標は部屋の掃除と同様に

サブシステムが散らからないように維持する．
サブシステムの使いやすさを維持する．
システム全体をできれば総入れ替えなど，大規模な修繕はしない．

といったところになるでしょうか．問題点をもう少しブレークダウンすると目標は修正されるかもしれませんが，現時点での仮想的な目標はこの3つにおいておくことにしましょう．それではまた次回．

SOAについて考える前に。訴求したいことと、知りたいことの差

Takayuki Okazaki — Tue, 26 Aug 2008 17:30:49 +0000

SOAについて考えるの記事で、早速jack_sparrowさんに貴重なコメントをいただいたので、これをふまえて、SOAを考える前の準備をしておきます。SOAを訴求する上で苦労する点は、前回のエントリーで紹介した通り、利用者にとってSOAの正体があやふやでわかりにくいところです。この原因はいくつか考えられます。

SOAの定義が語る人によってぶれる。
しばしば、ほかの流行り言葉と組み合わせて語られる(例: Web 2.0やクラウドコンピューティング、ビジネス・プロセス・モデリング)。このため、全体の話の中でSOAがどこを占めているのかがわからない。
にたような言葉や、関連キーワードがたくさんある(例: SCA、ESB、BPM、BAM)
話が抽象的である。
メリットが具体的に想像できない。
どのようなアクションをとってよいのか見当がつかない。

SOAミドルウエア製品を開発しているソフトウエア・ベンダーやオープンソース・コミュニティーの立場からすれば、他製品との差別化のために新たな機能や性能を付け加えることで競争を勝ち抜かねばならず、それらの新たな機能や性能といった特徴を宣伝キーワードとして取り込むことを考えます。この、新たな機能や性能といった特徴を訴求するために、既存の概念や問題点、解決方法と対比させていきます。こういった思いのもとに作られた広告やパンフレット、セミナー資料などをみると、それぞれのベンダないしコミュニティーの「訴求したいこと」がベースとなり、その一部としてSOAが語られることになりがちです。

このため、各ベンダーやコミュニティーから発信されるSOA関連情報は、ぼんやりとした核を保ちつつも、周辺の特徴はどんどんと曖昧なものになっていきます。さらに追い討ちをかけるのが、SOA + Web 2.0や、SOA + Cloud Computingなどのようなニコイチ作戦で訴求される場合で、こうなってはSOAの特徴もわからなくなれば、Web 2.0の特徴を知ることも難しくなります。ニコイチ作戦は、流行り言葉が生まれては消えやすい、IT業界では常用される方法で、造語(例: Web 3.0)と比べて本質を大きく曲げることはないものの、もともとの意味をあやふやにしてしまうことは間違いないだろうと思っています。

一方、利用者側として知りたいのは、SOAとは何なのか、とか、自分の抱えている問題についてSOAを使えばどのような解決が期待できるのか、とか、問題を解決するためにSOAではどのようなアプローチをとるのか、といったことです。上記のように、開発側と利用者側の間には訴求したいこと、知りたいことの内容でギャップがあり、特に今回のテーマSOAについて、わかりづらい、というレッテルが定着してしまったのではないかと思っています。

難しいところは、SOAは購入すればすぐに効果の出る魔法の薬ではない点です。SOAのねらいや目的を知らないまま使っていては、具体的な問題を解決することはできないでしょうし、場合によってはかえって冗長な作業を強いられSOAの導入効果が得られるどころか、非効率かしてしまう可能性もあります。
自分にとってのメリットをすぐ知りたいのは利用者として当然の主張です。とはいえ、メリットばかりを追い求めてしまうと、近視眼的な判断に陥りやすく、よりハデに広告されていたり、流行していそうなキーワードに心を奪われ、最初に興味を持ったSOAの本来の目的を見失ってしまったり、流行を追求することのみに傾倒してしまうかもしれません。

ようやくjack_sparrowさんのコメントに戻りましょう(jack_sparrowさん、知り合いということで勝手な引用ご容赦ください (^^ゞ

SOA ≒ Cloud

私の中での論理はこんな感じです。

「SOA ≒ Cloud」という認識は、SOAとCloudをよく知っている人には共感が得られる表現であるかもしれませんが、この「○○は△△の拡張だ」のような表現は、しばしば本来の意味を過度に省略しすぎていると思っています。SOAをよく知っている開発側の立場としては、このような表現はいくつかのキーワードをうまく結びつけて訴求するにあたって好都合であり、タイポグラフィーとしても収まりが良いのでこれが最高のSOA表現だと思い込んでしまう傾向があるのではないかと思っています。

たとえば、アインシュタインによる「E = mc²」という有名な式はとてもシンプルで、見栄えが良いのですが、その背後にある特殊相対性理論をきちんと理解していなければ何の役にも立たない式でもあります。SOAはアーキテクチャであり、ITシステムを設計する上での理論でもあります。今回予定している一連のエントリの目標は、岡崎のここ数年の活動のとりまとめとして、SOAというアーキテクチャを説明することです。あわよくば、SOAをうまく訴求できるキャッチコピーも考えてみることにします。そこでは、利用者として期待すべきこと、考慮しなければならないこと、開発者として注意すべきことをなるべく含めていくつもりです。とても一般的なテーマで、時間がかかるかもしれませんが、ゆっくりとみていってください (^^ゞ

SOAについて考える, その0

Takayuki Okazaki — Tue, 26 Aug 2008 07:04:22 +0000

今月末でSunを退職することになりますが、今までやってきたことの振り返りもかねて、一番最後まで関わっていた仕事でもあり、一番苦労したキーワードでもあるSOAについて考えてみることにします。ちょうど、岡崎にかわってその仕事を引き受けられた寺田さんも最近はブログでSOAについて解説されています。

あと、担当していたSun Java CAPSもちょうど、米国でリリースされていたRelease 6が日本でも発表されましたのでそのメディアの反応も参考までに。

SOAを売る、という立場で一番難しいことは、利用者側にとって、SOAの正体はあやふやでわかりにくいことです。このため、たいていの場合、売り方としてはSOAと冠したプロダクトの機能をベースに、売り込みをかけようとします。これは、お客様にとってもわかりやすい内容で、それらがコスト上それが妥当なのかを判断しやすく話もスムーズに進みます。まあ、これはこれで商売として一つアリな形態だろうとおもいますが、SOA好きな自分にとってはやや不満の残るやり方です。せっかく時間もできましたし、来週にはSunの社員ではなくなり、自由な発想をもとにSOAを考えることができるようになると思います。