相変わらず大型案件の話が来ると「SOAでやりたい」という声を聞きます。でも、皆さん言われるのが「SOAをやる時にビジネスプロセス分析から始めたいけど、ユーザーにそんな体力がない」ということ。SOAの導入で最も問題になるのがユーザーのITリテラシという調査を見たことがありますが、あながちウソでもないなと思ってしまいます。
それでもSOAを導入するのはユーザーの理解を得ないといけません。しかし、それはビジネスプロセス分析でも、Webサービスでも、モデリングでもありません。大事なことは「選択する」ということです。
システム実現手段の選択の幅を広げる
SOAの基本は標準的なインターフェースを持ったコンポーネントをプロセスとして組み合わせることです。これが何を意味しているのかというと、コンポーネントの切り方やコンポーネントの作り方が選択可能になったということです。
たとえば変化が激しく重要な業務をコンポーネントとして切り出して信頼できる開発者にまかせる。逆に法律に従えばよいところはコンポーネントを買ってくる。あるいはどうせ変更するところはRFPを出して価格重視でSIer選定をする。
（多少、問題はありますが）コンポーネントの実装方法も自由ですから、価格重視ならSIerの好きにさせれば良いし、自社でコントロールしたいところはフレームワークを提供すればいい。
僕は、このようにシステム実現手段の選択の幅を広げているのがSOAの本質的なアイデアだと思っています。
選択は自分でするしかない
この選択は自分でするしかない。ビジネスの上で何が大事で何が大事でないかを他人に選んでもらうなんてありえないのです。
大事なところと大事じゃないところを選択して、それぞれにかけるコストと期待収益を選択するということです。その分離する手法としてビジネスプロセス分析やモデリングが重要になるだけ。
別にRonRでSOAでもいい
その上で技術は最適なものを選べばいい。だからSOAという概念から考え始めてRonRが使われてもかまいません。変化が激しくて分離可能な部位があればRonRが適切という判断はあり。使えなくなったら捨てても良いし、RonRががんばっている間に本格的な実装をしてもいいわけです。Webサービスを使うことは大事ではありません。
選択は経営の基本
こうした「選択」というのは経営を行ううえでは当たり前のはずです。事業の分割を行い、リソース投下量と期待収益率の調整するというのは経営の基本です。が、これがITに対してはできていない（ま、会社の経営としてできないところも多いわけですが）。
よくITのオーナーは経営陣が良いといいますが、それは判断がトップダウンでできるというよりも経営的なセンスで判断を行えるではないかと思っています。別に課長でも部長でも、こうしたセンスがよい人と仕事をすると非常にうまくいきます。
このブログで何度も書いていますがSOAは概念です。Web2.0でも、RubyでもSOA的な概念を見ることができます。何のためのSOAなのかをきちんと考えていきたいです。
