arclamp.jp アークランプ

　デブサミ2006のトリを飾ったObject-One。ディベート形式で争うものでしたが、ちょっと内容が深すぎたように感じます。「SOAによりアーキテクトと業務コンサルタントの合意形成はより容易になる」というのが最後のタイトルマッチのテーマですが、SOAが良いか悪いか、あるいはSOAとはなにか、という前提をすっとばしての議論だったので戦っている感じがしませんでした。
　が、こういうテーマは好きなので僕なりの意見を述べておきたいと思います。

肯定：SOAはアーキテクトと業務コンサルの共通言語
　まず、肯定派として。「アーキテクトと業務コンサルは合意形成すべき」なのは当たり前として、そのためには「共通の理解を得られる共通の言語を定義すること」が重要だと考えます。つまり話が通じるようにするというのが第一歩というわけです。そうすれば合意形成プロセスを進めることができます。英語と日本語で会話しても意味がないのと同じです。
　ですので、SOAがアーキテクトと業務コンサルの共通言語となりうるのか？というのがポイントだと思います。そのために使われているのが、サービスという概念とビジネスプロセスのモデル図です。
サービスというのはビジネス上意味のある処理の単位のこと。データとは異なり「ビジネス上意味のある」というところがポイントになります。データは「商品情報、全部で100万件」ですが、サービスは「昨日、売り上げが*****円以上あった商品情報」という感じになります。
　さらに、サービス間の関連性、ようはビジネスプロセスをモデルによって図示します。ビジネスプロセスというのはサービスを連続的に実行し、その結果を判定していくことで進むからです。
　SOAというのは、こうした概念をシステムに落とすための技術群の総称ということになります。ですから、SOAは、まさにアーキテクトと業務コンサルの共通言語であり、合意形成を行った結果をシステム化するための手法を前提としたコンセプトといえます。

否定：共通言語であっても、共通認識ができるわけではない
　で、否定派。まずはSOAが共通言語だとして合意形成が可能か？という部分を責めることになります。
　サービスやビジネスプロセスという概念には問題ないとしても、そのレイヤーがアーキテクトと業務コンサルでは大きく異なります。アーキテクトの考えるサービスやビジネスプロセスは、あくまでもアプリケーションです。一方で業務コンサルが考えるのは人の動きまでをふくめた概念です。
　アーキテクトの考えるサービスが「昨日、売り上げが＊＊＊＊円以上あった商品情報」だとすれば、業務コンサルが考えるサービスは「日別・週別で的確に売り上げを把握する」というレベルでしょう。もちろん図示もできるわけですが、じゃ、それって会話になるの？といえばそんなわけではありません。共通言語かもしれませんが、SOAの上で共通認識を作るのは無理です。所詮、アーキテクト寄りの発想でしかなく、そこに業務コンサルがコミットできる（すべきだ）というのはエゴではないでしょうか。

肯定：SOAでビジネスモデルから実装モデルへの変換を
　そして、またしても肯定派。であれば、レイヤーが違うとしても、そこを関連付ける仕組みがあればよいことになります。そもそもUMLには、そうしたレイヤー間の関連を管理するためのルールが用意されています。MDAにおけるPIM（Platform Independent Model）とPSM（Platform Specific Model）はそういう概念の言葉です（説明は端折ります）。
　ですから、業務コンサルが定義したビジネスモデリングに連携していくように詳細化をしていけば、確かにレイヤーは違ったとしても共通認識を持ちながら合意を形成することは可能だと考えられます。

否定：理想の業務が開発可能だとは限らない
　否定派。レイヤーの違いは簡単に解決できるようなことではありません。業務コンサルが望むモデルの最大の欠点は「システム化可能であるという保証がない」ことにあります。現状のIT技術力では解決できない問題です。
　例えば「時間別で的確に売り上げを把握する」ことが重要であっても、そこに100億円かけるかといえば、そういうわけではないでしょう。業務としてのあるべき論と現実性というのは別次元の制約であり、その関連が管理されているからといって動作するのか、ROIに見合うのかというものではありません。
　ですから、そもそもアーキテクトと業務コンサルというのはレイヤーもフィールドも異なるのです。そもそも業務コンサルにシステム的な制限を理解してもらうというのも難しいことです。SOAで共通認識を持ったとしても問題は解決されません。

肯定：SOAによる柔軟性が合意形成プロセスを促進する
　では肯定派は少し攻め手を変えてみましょう。そもそも共通の認識をいきなり作るのが難しいだけです。確かにシステムというのは作ってみなければわからないものです。それが現実でしょう。ですから、作る前に完全な合意をえることは難しい。であれば、動くシステムを変化させていくというようにすればよいのです。
SOAには柔軟性という大きなメリットを持ちます。コードによって作成されたサービスを柔軟に組み替えることで、従来よりも変化に耐えうるシステムを構築することが可能になりました。SOAを使うことを前提にシステム側からのボトムアップでサービスやモデルを定義してしまえばよいでしょう。もちろん、事前に業務コンサルがアーキテクトへ、もう少し別な方法で要望を伝えていることを前提とします。
　SOAによってアーキテクトと業務コンサルが同じフィールドでシステムを構築することが簡単ではないとしても、ある程度の共通言語の中で柔軟にシステムを作り変えていけるなら合意形成プロセスに大きなメリットを与えるでしょう。

　
　さて、こんなところで終わりにします。もちろん、最後の意見を否定するのは簡単です。現行のSOAはEAIやEDIの延長に過ぎませんから、ただのデータ連携技術です。ですから、そもそものサービスに柔軟性がなければ繋ぐ部分だけが柔軟でも意味がないからです。

　しかし、将来の方向性としては見据えるべき方向だと思います。そのためにはアーキテクチャの各部分ごとに柔軟性を確保していく方法を見極めなくてはいけません。
　小さいレベルではDIコンテナがありますし、大きなレベルでは現行SOAでいいでしょう。その中間となりうるのが、ServiceMixのようなDI×SOA的発想や、IBMやBEAが進めているSCA／SDOではないかと感じています。そしてWeb2.0だって立派な軽量SOAです。

　なんにせよ柔軟にアプリケーションを構築すべしという方向性は間違いないでしょう。ですから僕の意見は「アーキテクトと業務コンサルタントの合意形成はより容易になるように、SOAやWeb2.0などの技術要素を用いて柔軟なアプリケーション開発に努力しなくてはいけない」というところです。