SOAの進め方
Hitoshi Ozawa
夏休みの季節ですね。今日みたいなよい天気の日は、会社では家族を持って人が続いて急に「病気」になったり。（＾＾；
最近、ちょっと忙しかったことについて簡単に説明。
正しいSOAの進め方はトップダウン、それともボトムアップ？だけど考えてみると、SOAのために組織を変えるのって変ではないでしょうか？ITのためにビジネスを変える？SOAはビジネスのためではなかったのでは？それに組織を変えるイニシアティブの約７０％が失敗に終わってしまうというし。もしSOAを成功させるために組織を変える必要があったら、失敗に終わってしまう確率が高い。
しかしもし組織を変えるイニシアティブをSOAを支援する概念でしたら？実はこの課題を議論してきました。私としては、もうSOAの課題はITではなく、経営的な課題だと思っています。そのためにも海外の経営関係者と連絡を取り続けて行く予定をしています。
ビジネス変革の成功率は、プロジェクトの期間、メンバーのスキル、重要人物からのコミットメント、社員の努力で左右される。SOAはこの確率を上げて、ビジネス変革の成功率を上げることができる。
このような時世、ビジネスは変わり続けなければならない。Web
ServiceやESBの議論をしていたら、失敗の７０％に入ってしまう。具体的にビジネスをどのようにしたら変革に成功した３０％に入れることができるのかがキーだと思う。
だけど、ここのグループとちょっと観点が違うかな？（＾＾；
小沢
Yoshinori Ichikawa
組織についてなんですが、SOAの推進組織を作ろう、
という話はよくあると思います。いわゆるCoE (Center of
Excellence)のことですよね。BPMについても、IBMのRedpaper
なんかを読むと、BPM CoEを作れ、みたいなことが
書いてありました。
http://www.redbooks.ibm.com/Redbooks.nsf/RedbookAbstracts/redp4495.html?Open
ただ、実際に組織を変えるとか、とりわけ各部署のエースを
集めた専任組織を継続的に運用していくのは大変ですよね。
そういう方たちは引っ張りだこだと思いますし。本当の意味での
CoEを作ったり運用するのはハードルが高いよなぁ、という
のが素直な感想です。
業務改革の話ですが、業務改革の成功率をSOAで向上させる
というのは実に興味深いですね。どうしても私なんかはSOA
とシステムを切り離して考えられないのですが…（その点、BPM
はシステムと切り離して考えられます。業務をモデル化して、
効果を算定するところはシステムを利用しますが、別に業務
規定や組織を変えることで効果を出しても良いわけですから。
この辺りの秘訣はどこにあるのでしょう？どういうわけで
SOAが業務改革の成功率を上げますか？）
--
--------------------------------------------------------
Yoshinori Ichikawa(市川 義規)
Oracle Corporation Japan
Oracle Consulting Services
Technology Consulting
--------------------------------------------------------
Hitoshi Ozawa
SOAでCoEの話ができますが、本当にSOAを推奨している会社が責任を持って会社を変えることを支援するような話は少ないと思います。技術をもっと有効に活用できるようにする話は何か、宝くじを買ったらお金持ちになれるような話みたいな気がしてしまいます。外れたら、顧客が正しい番号を選択しなかったと他人事みないに。
顧客へのSOAの価値は、実際に実施して利点を得てからだと思っています。ただ、製品を導入したり、宝くじを買ったらお金持ちになれるようなアドバイスではないと思っています。勿論、宝くじを買ってお金持ちになる人もいますが。。。
会社を変える運動の７０％が失敗するのは、CoEのような推進チームを作ってを含めてのことだと思います。実際にSOAの組織論の多くは、以前からビジネス学校で教えられていることを引用しているため、経営軍にとっては新しい概念は少ないと思います。既に失敗率が高いのを知っているので、経営者になかなか相手にされないのだと思います。
例えて言うと、宝くじを買ったらお金持ちになるっと言うのではなく、具体的にどの番号を選んだら当たるかを教えて欲しいのだと思います。（＾＾）
話は変わりますが、推進チームで重要とされる要素は、今までは人間関係のようなソフト面が中心に調べられていましたが、調査では具体性のあるハード面も重要とさるようになりました。SOA概念をこのハード面に利用した場合の推定成功率の変化が課題です。（＾＾）
小沢
2009/08/14 14:41 に Yoshinori Ichikawa<yoshinori...@oracle.com> さんは書きました:
> 市川です。お疲れ様です。
>
> 組織についてなんですが、SOAの推進組織を作ろう、
> という話はよくあると思います。いわゆるCoE (Center of
> Excellence)のことですよね。BPMについても、IBMのRedpaper
> なんかを読むと、BPM CoEを作れ、みたいなことが
> 書いてありました。
>
> http://www.redbooks.ibm.com/Redbooks.nsf/RedbookAbstracts/redp4495.html?Open
>
> ただ、実際に組織を変えるとか、とりわけ各部署のエースを
> 集めた専任組織を継続的に運用していくのは大変ですよね。
> そういう方たちは引っ張りだこだと思いますし。本当の意味での
> CoEを作ったり運用するのはハードルが高いよなぁ、という
> のが素直な感想です。
>
> 業務改革の話ですが、業務改革の成功率をSOAで向上させる
> というのは実に興味深いですね。どうしても私なんかはSOA
> とシステムを切り離して考えられないのですが...（その点、BPM
Hitoshi Ozawa
柔軟なプロセスについて少し説明します。
ITがいうプロセスの柔軟性とは曖昧すぎて投資対効果がありません。何でも柔軟にするには投資が多すぎます。ビジネスが要求するのは特定の目的を達成することへの柔軟性であります。例えば、在庫を減らすために入出庫をいまよりも多くするなど。また、よくIT側が勘違いするのが、「エンドユーザの要求を答える」と言う表現です。実際には最終的にお金を出す顧客のニーズに柔軟に応じられることが必要であります。
ニーズの変化には４種類があります。まず、予定されているニーズの変化。次の結果が予測できる変化。三番目に、変化することは予測できるが結果が予測できない変化、最後に予測できない変化。このらの変化の割合を計算して、対応に必要な投資額と投資しなかった場合のリスクを割り出します。
対応候補のニーズ変化を挙げた後に、対応策とそれを実施する場合に対面する制約を洗い出します。制約は大きく４分類に分けることができます：資源制約（人、物など）、市場制約（販売など）、方針制約（法律、会社規則など）、社会的制約（人間関係など）。これらの制約は関連し会って、実際には小数の原因を元にしています。先ずは制約の関係を簡素化して、元となる原因を究明する必要があります。この原因を改善するのがプロジェクトの目的になります。SOAの概念を利用して対策を考えるとよいと思っています。
最後に、実際の原因対策プロジェクトの計画を立てる場合はスケジュール、メンバーのスキル、組織が提供できるコミットメント、メンバーの気（努力）を考慮するとプロジェクトの成功率が上がります。プロジェクトを成功させるためには定期的にこれらの４要素を計って、プロジェクトを進めていきます。
ESBやWebServiceを使えば、何が、どのように柔軟になるのかを考えずに、魔法的に何でも柔軟になるという発言がSOAをダメにしたとも言われています。（＾＾；
ま、お金が余っているときは、宝くじや馬券を買うのも良いか。
話は変わりますが、今週末に富士登山オフはどうでしょうか？ここだと興味を持つ人はいないかな？（＾＾；
小沢
2009/08/15 9:43 に Hitoshi Ozawa<htsh...@gmail.com> さんは書きました:
Hitoshi Ozawa
もう少しSOAについての問題をいうと、SOAはアーキテクチャであることを理解していない人が多いことです。理解しているとしてもアーキテクチャをソフトウエアスタックを勘違いしている人が多いと思います。家を建てる場合でも、実際に家が建たなければ何にも意味がないように、ただ設計だけして、実際に建てようとしたらその設計では建てられないことが判明したら困ってしまつ思います。
家を建てる場合に台所のカウンターのどの会社のどのモデルにするか、風呂はどこの会社のにするかなど最初に考える人は少ないと思います。
また、設計者の事務所に行って、急に在来工法にするか、それともツ－バイフォ－工法にするかなど聞かれても訳が分かりませんと思います。
現状と将来どのようにしたいのかを話すのではないでしょうか？だけど、もし設計者が言われた通りに設計してしまったても問題がありますよね？やっぱり経験からどのようにしたらもっと良いのかのアドバイスなどなど。言われた通りの要求で建てるのであれば、直接大工にお願いした方が、安くなると思います。
SOAの場合でも、先ず現状がどのようにお金を頂いている顧客と接しているのか、また将来どのようにしたいのかを聞き出す必要があります。その情報を元にサービス間の関係を設計し、その関係を実現できる環境を設計するのだと思います。
っと言っても、建売住宅って物もあります。基本的な部分は番号付きの柱や板を組み立てて、部屋のレイアウトなどを少し変えることはできます。このように考えると、SOAの問題は、建売住宅向けのアーキテクトが多いことかな。だけど、元の設計者もSOAを理解していなかったので、家がグラグラ揺れるなど。（＾＾；
小沢
2009/08/17 21:36 に Hitoshi Ozawa<htsh...@gmail.com> さんは書きました:
Hitoshi Ozawa
顧客のことろでコンサルしていて、気が付きましたが、SOAのもう一つの問題はOOを勉強されている人です。SOAを勉強しようとOOを勉強してサービスの設計をOO風にしている場合があります。
例えば、ビジネスモデルを作ると言って顧客を継承して個人と法人を定義したとします。サービスは荒く定義すると言われて、サービスの対象を顧客にしてしまうと問題になる場合があります。例えば、個人と法人で行う処理が違う場合は、サービスの実装で個人用の処理と法人用の処理を行うようにします。これらの処理のために、勿論サービスのインターフェースに個人用と法人用のパラメータを引き渡すようにします。サービスを呼ぶ利用者は個人と法人を識別しなくて済むと便利なように思いますが、実際は個人の属性か法人の属性を変えた場合にサービスのインターフェースが変わるので、個人と法人用の利用者を変える必要があります。即ち、保守性が悪くなるだけなのです。
問題は、OOで再利用と言うと、初期開発で一つのクラスを多くの別クラスから使うことを指すことが多いです。再利用とは、このような初期開発の他に、将来の利用があります。またこの将来の利用には、他利用者からの利用と、既存サービスを利用しているプロセスの変更した場合に継続的にサービスを利用する場合があります。プロセスの柔軟からだと、この将来の再利用がSOAの対象になります。OO風の再利用を目的に設計してしまうと、プロセスの柔軟性がなくなってしまいます。
＃SOAを行うのであれば、サービス思考を勉強して欲しいものです。間違ってオブジェクト指向を勉強しないで欲しいです。（＾＾；
小沢
2009/08/18 7:21 に Hitoshi Ozawa<htsh...@gmail.com> さんは書きました: