SOAの効果を出すためのサービス粒度・体制・人材SOAアーキテクト塾(2)(2/2 ページ)

» 2009年04月30日 12時00分 公開
[岩崎史絵(トレッフェ),@IT]
前のページへ 1|2       

SOAプロジェクトを成功に導く体制とは

谷川氏 次に、非常に難しいといわれるSOAプロジェクトですが、これをどのような体制で進めていくのかという疑問もあります。この点についてはいかがでしょうか。

岩崎氏 トップダウン型の企業統治が、ガバナンス上最も好ましいとされていますが、運命共同体のような文化がある企業では難しいでしょう。とすると、社員全員で“高度”に統治できるようにすべきではないかと考えています。例えば社内システムであれば、一般社員の方でも、技術知識を持ってある程度判断・評価できるスキルを身に付けること。そういう意味では、もっとさまざまな方に、関心を持っていただきたいですね。

岡嵜氏 日本はSOAの普及について、欧米から大きく後れを取っており、アジア圏の中でも最下位という調査結果があります。その原因の1つに、ITアーキテクトという存在の有無が大きくかかわっているんですね。個々のプロジェクト単位ではなく、全体最適の観点でプロジェクトの目的を達成するために動く存在です。こうした観点から、少なくとも企業全体を見渡すPMO(Project Management Office)やCOE(Center of Excellence)が必要です。

谷川氏 そういったことは、日本では主にSI企業が担当していました。その理由として、体制作りのためのコストや工数などがネックとなっていたようですが、ここを解決する体制作りは可能なのでしょうか。

岡嵜氏 わたしがかかわった事例を2つご紹介します。1つは、COEを作り、ルールを決め、実装局面に入ってもCOEがその工程を支援したケース。もう1つは、個別プロジェクトのプロジェクトマネージャやアーキテクトを募ってCOEを作り、ルール作りから参画したケースです。個別プロジェクトが全体決定に従いにくいのは、そもそも全体決定に個別の担当者がかかわっていないという理由によるのです。なので、最初から参画させていく。最初の立ち上げ時は確かに苦労もありますが、年月がたつに連れ、人材も育ってきますし、それに伴ってCOE/PMOがスリム化していきます。このように、時間軸を考慮に入れて、体制を作っていくことも必要でしょう。

SOAの効果は、いつどのように分かるのか

谷川氏 さて、サービス粒度、体制に続き、問題となるのがSOAの効果です。単刀直入にお伺いしますが、SOAを作ったら即何らかの効果が出ると考えて良いのでしょうか?

岡嵜氏 SOAは、システムを作って終わりではなく、継続していくものなので、即効果を実感することは難しいでしょうね。システムを継続的に改善していく、そしてそのサイクルを迅速化するという点で、時間の経過と共に大きな効果を生み出すことは断言できますが。そしてこれは、開発生産性だけでなく、ビジネス的な視点でも大きな効果をもたらすのです。例えば通信業界では、顧客への新サービスの開発サイクルは3カ月といわれています。生産性が高まれば、より迅速に新サービスを市場に投入できますし、結果として多くの顧客獲得につながるでしょう。また、販売管理や生産管理など複数のビジネスプロセスをつなぐことで、販売機会のロスを解消するといった効果も見込めます。先ほど、ユーザーインターフェイスの話が出ましたが、例えば1人のオペレータが10も20もシステムを使っていた場合、インターフェイスが分離していると、使いにくくて業務に支障を来たしたり、教育コストが掛かるといった問題がありますが、SOAに基づいてバックエンドとフロントエンドを統一することで、教育コストを少なくしつつ、業務パフォーマンスを上げることができます。

岩崎氏 効果測定にはいろいろな考え方がありますが、何をもって効果と判断するかを事前に決めなくてはなりません。要件を定義し、開発が終わった後で「こんなはずではなかった」ということがよくありますが、これはそもそも要件定義の時に、効果を明確にしていなかったから起こるのです。開発時の効果とは、設計された様式を忠実に再現したかどうかが問われるものなので、これを理解していないと、効果は何なのかが分からなくなります。この解決手段として、ISOで定義されているV字モデルでは、「適合性確認」といって、要件定義の段階で「何が満たされているべきか」の判断基準を策定することが求められています。泥縄式に、ボトムアップで効果を捻出しても、大きな目的から外れていたら、「効果が出た」とはいえないでしょうね。

SOAの意味とは? アーキテクトの定義とは?

谷川氏 ここで、会場からの質問を受け付けましょう。まず「ITアーキテクトという言葉が頻発していますが、そもそもITアーキテクトの定義とは何か」という質問が来ています。

岩崎氏 もともとアーキテクトは建設業界から派生した用語で、具体的には建築事務所の総称と考えていいでしょう。つまり、設計士ということです。よく、スーパープログラマを「アーキテクト」と呼んでいますが、わたしは「作る人」と「設計する人」は別であり、設計する人=ITアーキテクトととらえています。これはITSSでも同様の考えのようです。

岡嵜氏 岩崎さんの意見に近いのですが、「システム要件から設計を考える人」だと定義しています。ビジネスプロセスを策定する人と開発する人は別にいて、この2つの間をつないで設計する職種です。

谷川氏 次に、「SOAより新規開発の方がいいのでは」「SOAはBPRのためのものなのか。ならばわざわざSOAを選択するより、ERPの方が安いのでは」という質問が来ていますが、この点についてはいかがでしょうか。

岩崎氏 企業がITを導入する動機には、2種類あると思っています。1つは業務コストの削減で、10人でやっていた業務を1人でできるようにする、といったものです。もう1つは、企業が飛躍するための起爆剤としてオンリーワンの仕組みを整えるというもの。強固なビジネスプロセスの確立も、この目的ですね。とすると、後者の場合、パッケージでカバーできるかといえば、答えはノーです。パッケージは固定業務の効率化には優れていますが、新しいビジネスの起爆剤としては、やはり不足する部分があります。そして現実は、2つの目的を選択しながらシステムを改善していくものであり、その手段としてSOAがあるのではないでしょうか。

岡嵜氏 わたしも同じ考えです。BPRのためでなく、SOAの結果としてBPRにつながることもあるでしょうし、BPRという目的を達成するためにERPが有用であれば、それも1つの解でしょう。ただ、それだけですべての領域を満たせるかというと、難しいと思います。当社の事例でも、ERP導入をきっかけにSOAに進むケースがあります。「固定領域はERPでカバーし、コアコンピタンスを独自開発したい。2つの領域を連携し、かつ迅速性を保証するために、SOAにしたい」というものです。

谷川氏 最後のテーマである「SOAの効果」についてですが、「具体的にどのような点を洗い出して効果を測定すべきか」という質問が来ていますが、その点はいかがですか。

岩崎氏 ビジネス的な側面だと、新規開発の場合、既存システムを組み合わせる場合のそれぞれで見積もりを取り、コスト面から効果を判断するという方法がありますね。同じことを実現するという前提の下、「コスト対効果」で考えた場合の一例です。

岡嵜氏 効果測定の勘所は2つあると思います。1つは、継続的に投資を続けるシステムをSOA化することで、生産性やスピードが上がるという点。もう1つは、前出のBPRの観点で効果を測定する方法です。先ほども申し上げたとおり、ERPだけですべてのビジネス領域をカバーするのは難しいですし、分断されていることで発生するビジネス課題があるはずです。そうした課題から、期待される効果を、定性的・定量的に洗い出すというのが有効な手段ではないでしょうか。

筆者プロフィール

岩崎史絵(いわさき しえ)

有限会社トレッフェ 代表取締役、ITライター、文章力向上コンサルタント

リックテレコム、アットマーク・アイティ(現アイティメディア)の編集者を経て2004年独立、2005年有限会社トレッフェ設立。ERP、SCMなど業務改革パッケージ製品の動向、事例取材・執筆のほか、SOA、グリッドコンピューティング、SaaSなどの技術トレンドの解説を手がける。近年は、ITエンジニアの働き方やキャリア育成をテーマにした取材企画・執筆も担当しており、またITエンジニアやコンサルタントのための「文章力養成講座」や「読書術」の講師、産学協同ロボット研究プロジェクトの研究員としても活躍中。



前のページへ 1|2       

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ