ＳＣＭパッケージソフト 開発勉強日記です。
SCM / MRP / 物流等々情報を集めていきます。
×
[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。
NECネクサソリューションズ／ERPシステムに生産管理アドオンモジュール発売
NECネクサソリューションズ（株）は、国産型完全ウェブERPパッケージの「グランディット」に、生産管理業務機能を追加した「グランディット生産管理アドオンモジュール」を発売した。
生産管理アドオンモジュールは、マスタ統合・データベースの一元化を図り、販売と調達・在庫にシームレスに連動した生産管理を行えるシステムで、中堅製造業向けのERP導入を可能する。
製品のコンセプトは、需要の変化に柔軟な対応ができるよう、受注生産・先行着手生産・在庫補充生産・受注引当生産・FTO生産・BTO生産など、多様な生産形態を混在して生産計画を立案できる点。
また、完全マスタ統合、統合DBの構築で業務システムの複数構築を回避し、製造業の販売、調達・在庫、生産、会計業務の情報共有、一元化が可能となる。
生産管理アドオンモジュール機能は、基準情報管理、部品構成管理、基準生産計画・在庫補充計画、資材所要量計画、工程管理、購買外注管理、支給品管理、進捗管理、納期回答――の9機能。生産管理アドオンモジュール単体は500万円で、導入には別途グランディット販売、調達在庫、製造モジュールの購入が必要。
NECネクサソリューションズでは、今後3年間で約50本の販売を見込んでいる。
NECネクサソリューションズ（株）は、国産型完全ウェブERPパッケージの「グランディット」に、生産管理業務機能を追加した「グランディット生産管理アドオンモジュール」を発売した。
生産管理アドオンモジュールは、マスタ統合・データベースの一元化を図り、販売と調達・在庫にシームレスに連動した生産管理を行えるシステムで、中堅製造業向けのERP導入を可能する。
製品のコンセプトは、需要の変化に柔軟な対応ができるよう、受注生産・先行着手生産・在庫補充生産・受注引当生産・FTO生産・BTO生産など、多様な生産形態を混在して生産計画を立案できる点。
また、完全マスタ統合、統合DBの構築で業務システムの複数構築を回避し、製造業の販売、調達・在庫、生産、会計業務の情報共有、一元化が可能となる。
生産管理アドオンモジュール機能は、基準情報管理、部品構成管理、基準生産計画・在庫補充計画、資材所要量計画、工程管理、購買外注管理、支給品管理、進捗管理、納期回答――の9機能。生産管理アドオンモジュール単体は500万円で、導入には別途グランディット販売、調達在庫、製造モジュールの購入が必要。
NECネクサソリューションズでは、今後3年間で約50本の販売を見込んでいる。
PR
卸がシンクタンク／産地との関係性改革を
掲載日：2007-3-13 12:36:36
花きの大手卸売会社がシンクタンク（頭脳集団）とも言うべき研究所を設立した。長い間に蓄積された情報を体系的に活用して、産地や小売り支援を強める。卸売市場の卸はこれまでも、販売担当者が独自に必要情報を取引先に提供してきた。研究所の役割はそれを多角的な分析で深化させ、新たな事業にする狙いがある。花きは農産物の中でも需要動向の変化が激しいだけに、素早く対応できる情報の提供は競争優位を確保するためにも貴重といえる。
シンクタンクを設けたのは花き卸最大手の大田花き。先月１日に子会社として「花の生活研究所」を発足させた。産地と小売りの間にいる中間業者には、生産から消費まで幅広い情報が集まる。それを研究・分析して川上、川下支援に役立てようというのだ。消費トレンドに合わせた花づくりを的確に実践したい産地や、商圏分析に基づく販売を試みたい小売りが増えてきたこともあり、新たな収益源を確保する狙いがある。
花を取り巻く環境はいま、劇的に変化している。生産サイドでは高齢化による担い手不足が深刻化する一方、販売では零細な小売りからチェーン化された小売りへと比重が移ってきた。加えて、消費の低迷は依然として続き、嗜好（しこう）品である花きの購入金額は年々減少の一途だ。その上、需要動向は急激な変化を繰り返し、不確実性をとみに増してきた。トレンドと思われたものが、数カ月後には寿命を終えてしまう商品さえ出ている。
作る側と売る側の連携はそれだけに重要といえるが、現実には的確な消費ニーズが適切に産地に伝達される仕組みや、ニーズに合った花きを生産する態勢はまだまだ不十分だ。大田花きではこうした現状を克服するため委託生産方式を導入したほか、生産者サポートシステムをつくり対応してきた。今回の研究所設置は、情報分析を通して体系だった産地・小売り支援の在り方を探るもので、将来的には生産・経営指導のコンサルティングとして事業化する。
ただ、そこまで踏み込むなら一つだけ注文したい。サプライチェーン・マネジメント（ＳＣＭ）の構築だ。消費の実態に合った生産、ロスの少ない流通、商圏に対応した販売体制を鎖のようにつなぐ仕組みを、大田花きが軸になってつくったらどうか。人口減少社会の到来で、花きを購入する消費者が減るのは確実。産地にとって安心して乗れる協業が欠かせないだけに、卸への期待は大きい。
市場では２年後に委託手数料自由化を迎える。卸と産地との結び付きは、これまでの延長線ではあり得ず、新たな局面に入る。せり人一人に任せていた仕入れと販売の機能を、大田花きが一昨年、分化させたのもその表れだろうが、一歩進めて花き卸らしいＳＣＭの構築にも取り組んでもらいたい。
掲載日：2007-3-13 12:36:36
花きの大手卸売会社がシンクタンク（頭脳集団）とも言うべき研究所を設立した。長い間に蓄積された情報を体系的に活用して、産地や小売り支援を強める。卸売市場の卸はこれまでも、販売担当者が独自に必要情報を取引先に提供してきた。研究所の役割はそれを多角的な分析で深化させ、新たな事業にする狙いがある。花きは農産物の中でも需要動向の変化が激しいだけに、素早く対応できる情報の提供は競争優位を確保するためにも貴重といえる。
シンクタンクを設けたのは花き卸最大手の大田花き。先月１日に子会社として「花の生活研究所」を発足させた。産地と小売りの間にいる中間業者には、生産から消費まで幅広い情報が集まる。それを研究・分析して川上、川下支援に役立てようというのだ。消費トレンドに合わせた花づくりを的確に実践したい産地や、商圏分析に基づく販売を試みたい小売りが増えてきたこともあり、新たな収益源を確保する狙いがある。
花を取り巻く環境はいま、劇的に変化している。生産サイドでは高齢化による担い手不足が深刻化する一方、販売では零細な小売りからチェーン化された小売りへと比重が移ってきた。加えて、消費の低迷は依然として続き、嗜好（しこう）品である花きの購入金額は年々減少の一途だ。その上、需要動向は急激な変化を繰り返し、不確実性をとみに増してきた。トレンドと思われたものが、数カ月後には寿命を終えてしまう商品さえ出ている。
作る側と売る側の連携はそれだけに重要といえるが、現実には的確な消費ニーズが適切に産地に伝達される仕組みや、ニーズに合った花きを生産する態勢はまだまだ不十分だ。大田花きではこうした現状を克服するため委託生産方式を導入したほか、生産者サポートシステムをつくり対応してきた。今回の研究所設置は、情報分析を通して体系だった産地・小売り支援の在り方を探るもので、将来的には生産・経営指導のコンサルティングとして事業化する。
ただ、そこまで踏み込むなら一つだけ注文したい。サプライチェーン・マネジメント（ＳＣＭ）の構築だ。消費の実態に合った生産、ロスの少ない流通、商圏に対応した販売体制を鎖のようにつなぐ仕組みを、大田花きが軸になってつくったらどうか。人口減少社会の到来で、花きを購入する消費者が減るのは確実。産地にとって安心して乗れる協業が欠かせないだけに、卸への期待は大きい。
市場では２年後に委託手数料自由化を迎える。卸と産地との結び付きは、これまでの延長線ではあり得ず、新たな局面に入る。せり人一人に任せていた仕入れと販売の機能を、大田花きが一昨年、分化させたのもその表れだろうが、一歩進めて花き卸らしいＳＣＭの構築にも取り組んでもらいたい。
SOAを導入する前に知っておくべき7つの“真実”
関連トップページ：業務改革／ビジネス・プロセス改革 | IT基盤 | システム開発
ビジネス・ニーズに迅速に対応できるITシステムを実現することは、CIOが取り組むべき主要課題の1つである。SOA（Service-Oriented Architecture：サービス指向アーキテクチャ）は、この課題にこたえることのできる戦略的なアプローチとして大きな注目を集めている。しかしながら、国内での導入事例が少ないこともあって、SOAで何がどこまででき、具体的にどんなメリットが得られるかについて、さまざまな疑問を抱いておられる読者も少なくないはずだ。そこで、本稿では、実際にSOAの導入に取り組んでいる米国ユーザーの証言を拾いながら、そうした疑問に答えていくことにしたい。
クリストファー・コッホ ● text by Christopher Koch
ビジネス改革の特効薬
我々の目標は、SOAを導入することではなく、生産性を高め、サプライチェーンから無駄をなくすことだ。ベンダーが宣伝するような最新性や優位性にとらわれる必要はまったくないと考えている――オーウェンズ・コーニングのCIO、デビッド・ジョンズ氏
多くのCIOは今、「ビジネス・ニーズに迅速に対応できる柔軟なIT基盤の構築」という目標に向けて邁進している。だが、その目標は近づくどころか、かえって遠のいているかのようにさえ見える。
米国の研究団体であるビジネス・パフォーマンス・マネジメント・インスティチュートが最近発表したある調査結果によると、「ビジネス部門から出されるビジネス・プロセスの変更要求に、IT部門がきちんと対応できている」と答えた経営幹部は全体のわずか11％にとどまった。しかも、36％の経営幹部は、ビジネス部門からの要求に対するIT部門の対応力を「かなり弱い」（27％）ないし「まったくできていない」（9％）と評価している。さらに、変更に際してIT部門の協力が必要になるとされているプロセスは全体の約4割でしかない。つまり、ここからは、「ITこそがビジネスのボトルネックとなりつつある」という、CIOにとっては目を背けたくなるような現実が透けて見えているのである。
そうしたなか、ビジネスとITとの間に厳然と存在するギャップを埋めるための戦略的アプローチとして、CIOが熱い視線を注いでいるのがSOA（Service-Oriented Architecture）である。
SOAに基づくシステム開発では、企業は重要なひとまとまりの業務（例えば「信用調査」や「顧客情報管理」など）をサービスとして切り出し、それらの組み合わせによって自動化されたビジネス・プロセスを創出するというアプローチをとる。それによって、システムの開発期間を短縮したり、コストを大幅に圧縮したりといったことが可能になると考えられているわけだ。
SOAは、言ってみれば、オブジェクト指向設計とコンポーネント・ベースのソフトウェア開発という、CIOにとって比較的なじみの深い方法論に基づいたアーキテクチャであり、その考え方自体は特段目新しいものではない。だが、上述したようなビジネス・サイドの“不満の高まり”を感じているせいか、SOAに対してCIOが寄せる関心の度合いには、技術トレンドの枠をはるかに超えたものがある。
フォレスター・リサーチが実施した調査の結果によれば、大規模SOAユーザーの46％（ならびに中小規模ユーザーの27％）は、SOAの導入目的として「戦略的なビジネス改革の達成」を挙げている。この傾向は、他の調査でも同じだ。サミット・ストラテジーズの調査では、SOAを導入する目的として最も多くの回答が寄せられたのは「競争優位の実現」であった。また、アバディーン・グループの調査でも「新しい機能や商品の開発力の強化」が最も多くの回答を集めた。さらに、CIO Magazine米国版とComputerworld米国版が共同で実施した調査でも、77％の回答者が「SOAはビジネスの柔軟性を向上させる」と回答した。
こうした調査結果を見れば、CIOが今、SOAに期待している効果が「ビジネス改革」にあることは明らかだ。
SOAを実践する難しさ
IT部門に対するビジネス部門からの不満の高まりと、その不満を解消する可能性があると期待されるシステム開発手法の登場──この2つの事実を重ね合わせて考えれば、SOAの将来は約束されたも同然だと言える。しかしながら、現状を見ると、必ずしもそうした状況には至っていない。
先に紹介したアバディーン・グループの調査結果によれば、米国でもSOAを2年以上継続して利用している企業の割合は16％にすぎない。確かに、SOAの導入によって一定の成果を上げている先進ユーザーも出始めてはいるが、実はその多くは、潤沢な予算を持ち、ITの活用で絶えず市場の先頭を走ってきた通信会社や金融機関である。そうした企業は、ITに関する高度な専門知識を社内に蓄積しており、なおかつIT戦略をバックアップしてくれる経営陣にも恵まれている。つまり、「SOA以外の分野」でも十分に成功を収められる企業なのである。裏を返せば、予算や経営陣からの支援といった面で十分な条件が整っていない企業にとっては、SOAの導入は敷居が高い取り組みであるとも言えるのだ。
事実、SOAの真の効果を得るためには、多くのCIOが考えている以上に多額の資金と長期にわたる戦略的コミットメントが必要になる。単にサービス指向でソフトウェアを開発するというだけであればさほど問題はないが、サービスの全体最適を目指すとなると、CIOは、エンタープライズ・アーキテクチャ（EA）、統一的な開発手法の導入、およびITスタッフ（プロジェクト・マネジャー、アーキテクト、開発者、ビジネス・アナリストを含め）を中央集権的に配置するための組織体制への移行といったことにも並行して取り組まなければならなくなる。そうしたことが実現されないと、SOAの最も重要なメリットの1つである再利用性が損なわれたり、機能的にまったく的外れなものになったりするおそれがあるからだ。とはいえ、あまりに壮大なアーキテクチャを描こうとすると、計画作業に時間を取られすぎて、実際のビジネス・メリットが得られないまま終わってしまうというリスクもある。そのバランスをとるのがきわめて難しいのだ。
また、多くのCIOがSOAの導入目的として挙げるビジネスへの貢献──すなわち、ビジネス部門の要求に迅速にこたえるという目標は、その効果が定量化しにくいという側面を持つ。
「具体的な数字を出さずに、『SOAを利用すれば、従来よりはるかに柔軟なシステムを実現できる。したがってSOAに取り組むべきだ』といった話をビジネス部門にしても通用しない。SOA導入における最大の障壁は、ROI（投資利益率）を数値化するのが困難であるということだ」と、ガートナーのリサーチ担当副社長、ダニエル・ショラー氏は指摘する。
実際、統合ソフトウェア・ベンダーのウェブメソッドがユーザー企業を対象に行った調査では、SOA導入の障害として「知識不足」と「ROIが定量化しにくい」の2つが上位を占めた。
「そこで重要になるのは、ROIを事前に定量化することではなく、IT戦略をどのように業務に適用し、どのような成果を上げるかだ」と指摘するのは、住宅建材・ガラス繊維メーカー大手、オーウェンズ・コーニングの副社長で、CIOと最高サプライチェーン責任者を兼務するデビッド・ジョンズ氏である。
「我々の目標は、SOAを導入することではなく、生産性を高め、サプライチェーンから無駄をなくすことだ。ベンダーが宣伝するような最新性や優位性にとらわれる必要はまったくない」（ジョンズ氏）
ユーザー企業の中にはSOAに対してより懐疑的な見解を示す向きもある。その1人が、金融サービス会社のインストリーム・フィナンシャルでCTOを務めるトーマス・ガニエ氏だ。
「各社が進めているSOA導入プロジェクトを端から見ていると、複雑で杓子定規な中央集権型の仕組みを作ろうとしているだけのように見えることがある。まるで、物事を決めるのに本来の10倍も時間がかかるような仕組みでもつくろうとしているかのようだ」（ガニエ氏）
このように、SOAに対する見方は企業によって大きく異なる。もしも、あなたがSOAを利用したビジネス改革に本気で乗り出そうとしているのであれば、その前に、少なくともこれから挙げる7つの質問に対して明確な答えを用意しておく必要があるだろう。次節以降で、ユーザーやアナリストらの意見を紹介しながら、その7つの質問に対する答えを探っていくことにしたい。
質問｜その1 ビジネス部門に対してSOAをどう説明すべきか？
開発者2人で6人分の作業をこなせるようになり、アーキテクトやプロジェクト・マネジャーは、開発者の作業ペースについていくのが大変になる。いま我々がこなしている仕事は、3年前に比べて50％くらいは増えているはずだ――プロフラワーズ・ドットコムのCIO、ケビン・ホール氏
フォレスター・リサーチのアナリストであるランディ・ヘフナー氏は、「ビジネス部門に対して、SOAという言葉の意味や考え方までを説明する必要はない。SOAを導入することによって得られるコスト削減効果や、パフォーマンスの向上といったビジネス面の価値を分かりやすく提示してやればそれでよい」とアドバイスする。
このうち、コスト削減効果をアピールするには、1つのサービスに統合することが可能な、機能が重複したアプリケーションの数を挙げるのがよいだろう。生命保険会社、トランザメリカ・ライフ・インシュアランスで年金商品／サービス部門のIT戦略担当ディレクターを務めるジェフ・グリーソン氏は、同一のデータが少なくとも26個の異なるアプリケーションによって利用されているという事実を発見し、それをビジネス部門に対する“セールス・トーク”として利用したという。
「データがアプリケーションごとに異なる場所に保存されていたため、その管理費用はかなり高くついていた。私は、複数のアプリケーションが持ついくつかの機能をサービスよって統合することで、そのコストを省くことができると説明した」（グリーソン氏）
一方、SOAを基幹のビジネス・プロセスに適用することによって、システムの柔軟性とパフォーマンスを高めることに成功したのが、生花のインターネット販売を展開するプロフラワーズ・ドットコムである。同社には、機能が重複する余分なアプリケーションも、部門間でサービスを共用したいというビジネス部門からの要望もなかった。ただし、バレンタイン・デーの直前など年に数回、注文が殺到して膨大なトランザクションが発生し、システムがその負荷に耐えられなくなるという問題を抱えていた。
「原因は、花の注文処理プロセスを単一のアプリケーションで処理していたことにあった。そのため、トランザクションの増加に対応するべくプロセスを1カ所でも変更すると、システム全体を再構成しなければならなかったのだ。年々増大する負荷に対応するためには、常に強力なハードウェアに買い換える必要があったわけだ」（プロフラワーズ・ドットコムのCIO、ケビン・ホール氏）
そこで、ホール氏は分散型アーキテクチャであるSOAの利点を生かした提案をビジネス部門に対して行ったという。つまり、注文処理プロセスを複数の個別のサービスに分割すれば、負荷に応じてコンピューティング・リソースを動的に割り当てられることを強く訴えたのだ。この考えに基づく新システムは2002年から稼働を開始しているが、いまだに1度も停止したことがないという。
「新システムでは、注文処理のある段階で負荷が急増すると、サーバ・ファームが、トランザクションが集中しているサービスに対して優先的にストレージを割り当てて対処するという仕組みを採用している。これによって、水平方向（サーバ・リソースの割り当ての拡大やサーバの追加）、垂直方向（サービスの分割による負荷集中の緩和）の両面で、負荷に対応することができるようになった」（ホール氏）
質問｜その2 SOAが適さない企業とは？
質問その1に対する答えからも分かるように、SOAを導入して効果があるのは、複雑なIT環境を抱えている企業である。逆に、すでに社内インフラをマイクロソフトのWindowsプラットフォームなどで統一していて、複雑なアプリケーション統合を行う必要がないような中堅以下の企業では、SOAを導入するメリットがないため導入するには及ばない。
同様に、SAPやオラクルなど、特定のベンダーのアプリケーションを一定以上の割合（今回取材した専門家たちの意見を総合すると、その目安は60％以上）で利用しているような大企業の場合も、SOAを導入する必要があるかどうか、十分に吟味すべきだ。
前出のオーウェンズ・コーニングでは、利用しているアプリケーションの75％がSAP製品で占められている。これは、CIOのジョンズ氏が、製造と販売の工程を世界規模で統一するという戦略を長年にわたって進めてきた“成果”である。「SAP製品を活用することが我々の統合戦略だ」と言い切るジョンズ氏は、当然ながら、SOAの導入には慎重な姿勢を見せる。
また、総合家電メーカーのワールプールも、SAP製品の活用と、グローバル規模でのビジネス・プロセス統合を積極的に推進している企業である。そのうえ同社は、アプリケーション統合をすべてSAPにアウトソーシングしている。
同社のCIO兼コーポレート副社長のエサット・セザー氏は、「特定のベンダーに依存することになっても、私がそのベンダーのソリューションで会社に価値を提供しているかぎり、何も問題はない」と断言する。
質問｜その3 SOA導入によって発生する追加コストは？
SOAのコスト削減効果に過度に期待しているCIOの方にはお気の毒だが、実は、このアプローチを採用することによって“確実に増えるコスト”も存在する。フォレスターのへフナー氏は、SOAに基づくシステム開発では、設計段階における作業量が従来よりも30～100％増大すると推計している。これは、それぞれ固有のニーズを持つさまざまな業務分野で利用できる最適なサービスを設計することが非常に困難であるためだ。この設計段階のコストは、平均するとプロジェクト全体のコストの10％ほどを占めるとされる。
例えば、トランザメリカのグリーソン氏によると、同社で顧客の保険料支払いを処理するために利用されているサービスは、Webサイト、銀行間送金、コールセンターなど、さまざまなチャネルをカバーしているという。となると、当然ながら、サービスの設計時点において、各部門がこのサービスをどのように利用しようとしているかを明確に理解しなければならない。共用するサービスの使用方法について、関係者の同意を取りつけることは、SOAにおいては不可欠な作業なのである。
さらに、ここではもう1つ、開発コストの問題にも注意が必要だ。グリーソン氏が言うように、ビジネス部門は、往々にしてサービスの構築に必要な追加コストを負担したがらないのである。同氏によると、ビジネス部門のプロジェクト・スポンサーは、次のような言い分で出費を渋るのだという。
「サービス開発の費用を払うと、プロジェクトで得られるはずのコスト・メリットが吹き飛んでしまう。そんなお金の使い方はできない。ただ、そのサービスの機能自体は必要なので、より低コストなハード・コーディングによってシステムに統合してほしい」
グリーソン氏は、そのような意見が出てきたときこそ、ITディレクターが本来の役割を果たすべきときだと認識している。
「私はそういうときにはいつも、構築するサービスはビジネス・インフラの要素であり、再利用や変更が可能であるということを説明する。その有効性をビジネス部門に理解させることができれば、彼らは、初期コストがハード・コーディングを行うよりも高くつくかどうかといったことについては心配しなくなるものだ」（グリーソン氏）
質問｜その4 サービスはどの程度再利用できるのか？
初期費用が高くつくのであれば、CIOとしてはなおさら、開発したサービスをできるだけ再利用したいと思うことだろう。この点について、フォレスターのヘフナー氏は、「サービスの再利用性は、設計の厳密さによって大きく異なる。したがって、そのコスト・メリットも、開発者やプロジェクト・マネジャーの能力や経験に大きく左右されることになる」と強調する。
また、サービスのベースとなるアーキテクチャ計画のレベルによっても、再利用性の度合いには幅が生じる。当然ながら、包括的なSOA戦略の一環として開発されたサービスほど再利用性は高く、特定のビジネス・ニーズに特化したサービスになると再利用性は低くなる。
トランザメリカのグリーソン氏は、次のように注意を促す。
「特定のビジネス部門の意見を盛り込んだサービスは、変更するのに時間がかかるため、時間に余裕がない場合には補完サービスを開発しなければならなくなるようなケースもある。だが、それでは二度手間だ。長期的に考えれば、包括的な視点からサービスを設計しないことには、ビジネス・プロセス統合やビジネス・プロセス管理の実現は望めないだろう」
とはいえ、仮に1回でもサービスを再利用することができれば、絶大なコスト削減効果が得られることになる。
へフナー氏はこう指摘する。
「サービスを開発する際には、事前の設計作業に多くの時間を費やすことになるが、既存サービスを再利用するのであれば、設計やコーディング、単体テストのコストは一切かからない。ちなみに、これらの工程の合計コストは、ソフトウェア・プロジェクト・コスト全体の約40％を占めている」
この再利用に関しては、SOAで長い利用経験を持つ企業であっても、将来におけるサービスの再利用を前提に開発を行うのは困難であると認めている。というのも、サービスの“粒度”を適切に設定し、サービスに含まれる処理を多すぎもせず少なすぎもしないようにするには、高度な技量が必要とされるからだ。
自らSOA関連製品を開発／販売する立場にあるIBMで社内IT部門の統合アーキテクチャ担当副社長を務めるハウイー・ミラー氏でさえ、粒度を設定するのがきわめて難しい作業であることを認めている。
「当社の社内システムでは、サービス資産の30％がリターンの90％を生み出しているといったような状況にある。これでも、サービスの粒度の設定がきわめてうまくいっているケースと言える。すべてのサービスの粒度をしっかりとそろえるのは至難の業だ」（ミラー氏）
フォレスターのへフナー氏も、次のようなエピソードを明かす。
「私が以前会った自動車メーカーの関係者は、個々のサービスの利用頻度に最大で20倍もの開きがあると話していた。利用状況にあまりに差があるようでは再利用は難しい」
質問｜その5 アーキテクチャ計画と開発プロジェクトの最適なバランスは？
ここまで、サービス開発の土台となるアーキテクチャ計画の重要性を指摘してきた。だが、この作業は多くの時間と労力を必要とするものだ。それに対して、サービスの開発作業は、すでに実績のあるプログラミング原理や広く普及した技術標準（SOAPやHTTPなど）を利用して行われるため、比較的迅速に進めることができる。では、その両者はどのようにバランスを取りながら推進していけばよいのだろうか。
この点については、「アーキテクチャ計画と開発プロジェクトは並行して進めるべきだ」というのが、今回取材したアナリストやユーザー関係者の共通した意見である。
電力会社アメリカン・エレクトリック・パワー（AEP）で、エンタープライズ・アーキテクチャ兼開発担当マネジング・ディレクターを務めるカート・ウィスナー氏は、「必要に応じて開発プロジェクトを実施しつつ、複数年計画の中でビジネス・プロセスを調査し、エンタープライズ・レベルでサービスの統合を図っている」と自社の体制を説明する。
「このようなプロジェクトの進め方をとっているのも、ビジネス部門に対して、SOAのメリットを早期に示す必要があるからだ。実際にサービスを開発しないことには、我々がSOAに取り組む意義を具体的にアピールできるものが永遠に手に入らないわけだ」（ウィスナー氏）
サービスの開発に手をつける前の段階で、入念にアーキテクチャ計画を策定してプロセス・マッピングを行うのは、確かにセオリーである。だが、“生もの”であるビジネスを支援するうえでは、時として短期間で目に見える成果を上げることも必要だ。そのため、ウィスナー氏のような現実的な選択肢をとるCIOが多いのである。
実際、ウィスナー氏はAEPの前に勤務していた企業で、アーキテクチャ計画に注力しすぎた結果、プロジェクトを失敗させたという苦い経験を持っている。
「何百万ドルもかけて全社的なアーキテクチャ計画の作成に取り組んだが、途中で、作成している内容が既存のアーキテクチャと大して変わっていないことに気づいた。そこで作業が行き詰まってしまい、結果として具体的な成果を何も示せずに終わってしまったのだ。このときに、最初から全社を対象としたアーキテクチャ計画を作成するのは意外にリスクが大きいということを身をもって学んだ」（ウィスナー氏）
こうした経験を踏まえ、同氏は現在、アーキテクチャ計画の作成を小規模な業務領域ごとに進めるようにしている。そうすれば計画の対象が限定されるため、大きな問題になる前に軌道修正を図ることができるという。ウィスナー氏は、「アーキテクチャ計画は、対象を単純な要素に分割すれば進めやすくなる」とアドバイスする。
質問｜その6 どんなサービスに投資をするべきか？
どのサービスを優先して開発すべきかで判断に迷った際には、・顧客にかかわる分野、・売上げに直接かかわる分野、・ビジネス上の課題を解決する分野──の順でビジネス・プロセスを洗い出し、それらに対応したサービスから着手するのがよいだろう。
ビジネス・パフォーマンス・マネジメント・インスティチュートが2006年に実施した調査でも、これらの項目がサービスの優先度ランキングで上位を占めた。例えば、同調査で「ビジネス・プロセスの変更や新しいアプリケーションを導入する理由」を尋ねたところ、1位となったのは「顧客のニーズや嗜好が高度化したため」。以下、「競争上の脅威に対抗するため」、「新しい売上げの機会を得るため」と続いた。ちなみに、「コスト削減を図るため」は、上位3項目とはかなり差が開いて4位だった。
ガートナーのショラー氏は、「顧客に直接関係するようなアプリケーションは、最大のビジネス価値を提供するものであると同時に、多数の変更要求が非常に頻繁に発生するものでもある。したがって、こうしたアプリケーションを10％改良することができれば、他のアプリケーションを50％改良するよりもはるかに効果的だ」と主張する。
質問｜その7 SOAの導入はIT部門にどのような影響を与えるか？
もし、あなたの会社のIT組織が分散型であるとしたら、CIOは組織再編に奮闘する覚悟が必要だ。SOAの導入は中央集権化を促進する、というより、SOAを導入するには中央集権的なIT組織が不可欠だからだ。
工業／建設用品を販売するファステナルで、シニア・システム・エンジニアを務めるマイク・フォールズは、次のように語る。
「SOAプロジェクトでは、先頭に立って組織をリードする人材がどうしても必要になる。また、特定の個人あるいはごく少数のチームによって、全体のアーキテクチャが絶えず管理されている必要もある。これは、中央集権的なIT組織でなければとても実行できるものではない。個々のチームに裁量権を与えてしまうと、おそらくそれぞれが独自のサービス構築手法をとってしまい、収拾がつかなくなってしまうだろう」
このような体制を確立して、各サービスのポートフォリオを充実させていくと、開発プロセスもおのずと様変わりすることになる。AEPのウィスナー氏によれば、それはあたかも「工場の組立ライン」のようなものになるという。
「さまざまなプロジェクト・チームの作業を経るなかで、部品が組み合わされてモジュールになり、モジュールが組み合わされて最終成果物になる、というような流れが生まれるだろう。そして、その工程の中で、需給に応じて作業量を増減させ、製造を調整していくことになる」（ウィスナー氏）
プロフラワーズのホール氏は、このような“SOA工場”が軌道に乗ると、開発者の生産性が向上し、それに伴って、アーキテクトやプロジェクト・マネジャーを増員する必要に迫られることになるという。
「開発者2人で6人分の作業をこなせるようになり、アーキテクトやプロジェクト・マネジャーは、開発者の作業ペースについていくのが大変になる。いま我々IT部門がこなしている仕事量は、おそらく3年前に比べて50％くらいは増えているはずだ」
また、サービス指向開発に携わるプログラマーは、オブジェクト指向プログラミングと分散アプリケーションを理解していなければならない。これは研修への投資が必要になることを意味する。ちなみに、CIO Magazine米国版とComputerworld米国版の共同調査では、「SOAへの取り組みに必要なITスタッフを確保している」とした回答者は25％にとどまっている。また、回答者の49％は、現行スタッフに必要な教育を提供する研修プログラムを計画または実施しているという結果も示されている。
以上見てきたように、SOAに基づくシステム開発手法を導入する際には、ビジネス部門の説得に始まり、アーキテクチャ計画の策定、さらにはIT部門の改革と、さまざまな局面でCIOのリーダーシップが必要になる。
「SOAによるビジネス改革」を目指す取り組みは、CIOにとって長く険しい道程になるだろう。しかしながら、その困難を乗り越えた者だけが、真のメリットを享受することができるということもまた事実なのである。
関連トップページ：業務改革／ビジネス・プロセス改革 | IT基盤 | システム開発
ビジネス・ニーズに迅速に対応できるITシステムを実現することは、CIOが取り組むべき主要課題の1つである。SOA（Service-Oriented Architecture：サービス指向アーキテクチャ）は、この課題にこたえることのできる戦略的なアプローチとして大きな注目を集めている。しかしながら、国内での導入事例が少ないこともあって、SOAで何がどこまででき、具体的にどんなメリットが得られるかについて、さまざまな疑問を抱いておられる読者も少なくないはずだ。そこで、本稿では、実際にSOAの導入に取り組んでいる米国ユーザーの証言を拾いながら、そうした疑問に答えていくことにしたい。
クリストファー・コッホ ● text by Christopher Koch
ビジネス改革の特効薬
我々の目標は、SOAを導入することではなく、生産性を高め、サプライチェーンから無駄をなくすことだ。ベンダーが宣伝するような最新性や優位性にとらわれる必要はまったくないと考えている――オーウェンズ・コーニングのCIO、デビッド・ジョンズ氏
多くのCIOは今、「ビジネス・ニーズに迅速に対応できる柔軟なIT基盤の構築」という目標に向けて邁進している。だが、その目標は近づくどころか、かえって遠のいているかのようにさえ見える。
米国の研究団体であるビジネス・パフォーマンス・マネジメント・インスティチュートが最近発表したある調査結果によると、「ビジネス部門から出されるビジネス・プロセスの変更要求に、IT部門がきちんと対応できている」と答えた経営幹部は全体のわずか11％にとどまった。しかも、36％の経営幹部は、ビジネス部門からの要求に対するIT部門の対応力を「かなり弱い」（27％）ないし「まったくできていない」（9％）と評価している。さらに、変更に際してIT部門の協力が必要になるとされているプロセスは全体の約4割でしかない。つまり、ここからは、「ITこそがビジネスのボトルネックとなりつつある」という、CIOにとっては目を背けたくなるような現実が透けて見えているのである。
そうしたなか、ビジネスとITとの間に厳然と存在するギャップを埋めるための戦略的アプローチとして、CIOが熱い視線を注いでいるのがSOA（Service-Oriented Architecture）である。
SOAに基づくシステム開発では、企業は重要なひとまとまりの業務（例えば「信用調査」や「顧客情報管理」など）をサービスとして切り出し、それらの組み合わせによって自動化されたビジネス・プロセスを創出するというアプローチをとる。それによって、システムの開発期間を短縮したり、コストを大幅に圧縮したりといったことが可能になると考えられているわけだ。
SOAは、言ってみれば、オブジェクト指向設計とコンポーネント・ベースのソフトウェア開発という、CIOにとって比較的なじみの深い方法論に基づいたアーキテクチャであり、その考え方自体は特段目新しいものではない。だが、上述したようなビジネス・サイドの“不満の高まり”を感じているせいか、SOAに対してCIOが寄せる関心の度合いには、技術トレンドの枠をはるかに超えたものがある。
フォレスター・リサーチが実施した調査の結果によれば、大規模SOAユーザーの46％（ならびに中小規模ユーザーの27％）は、SOAの導入目的として「戦略的なビジネス改革の達成」を挙げている。この傾向は、他の調査でも同じだ。サミット・ストラテジーズの調査では、SOAを導入する目的として最も多くの回答が寄せられたのは「競争優位の実現」であった。また、アバディーン・グループの調査でも「新しい機能や商品の開発力の強化」が最も多くの回答を集めた。さらに、CIO Magazine米国版とComputerworld米国版が共同で実施した調査でも、77％の回答者が「SOAはビジネスの柔軟性を向上させる」と回答した。
こうした調査結果を見れば、CIOが今、SOAに期待している効果が「ビジネス改革」にあることは明らかだ。
SOAを実践する難しさ
IT部門に対するビジネス部門からの不満の高まりと、その不満を解消する可能性があると期待されるシステム開発手法の登場──この2つの事実を重ね合わせて考えれば、SOAの将来は約束されたも同然だと言える。しかしながら、現状を見ると、必ずしもそうした状況には至っていない。
先に紹介したアバディーン・グループの調査結果によれば、米国でもSOAを2年以上継続して利用している企業の割合は16％にすぎない。確かに、SOAの導入によって一定の成果を上げている先進ユーザーも出始めてはいるが、実はその多くは、潤沢な予算を持ち、ITの活用で絶えず市場の先頭を走ってきた通信会社や金融機関である。そうした企業は、ITに関する高度な専門知識を社内に蓄積しており、なおかつIT戦略をバックアップしてくれる経営陣にも恵まれている。つまり、「SOA以外の分野」でも十分に成功を収められる企業なのである。裏を返せば、予算や経営陣からの支援といった面で十分な条件が整っていない企業にとっては、SOAの導入は敷居が高い取り組みであるとも言えるのだ。
事実、SOAの真の効果を得るためには、多くのCIOが考えている以上に多額の資金と長期にわたる戦略的コミットメントが必要になる。単にサービス指向でソフトウェアを開発するというだけであればさほど問題はないが、サービスの全体最適を目指すとなると、CIOは、エンタープライズ・アーキテクチャ（EA）、統一的な開発手法の導入、およびITスタッフ（プロジェクト・マネジャー、アーキテクト、開発者、ビジネス・アナリストを含め）を中央集権的に配置するための組織体制への移行といったことにも並行して取り組まなければならなくなる。そうしたことが実現されないと、SOAの最も重要なメリットの1つである再利用性が損なわれたり、機能的にまったく的外れなものになったりするおそれがあるからだ。とはいえ、あまりに壮大なアーキテクチャを描こうとすると、計画作業に時間を取られすぎて、実際のビジネス・メリットが得られないまま終わってしまうというリスクもある。そのバランスをとるのがきわめて難しいのだ。
また、多くのCIOがSOAの導入目的として挙げるビジネスへの貢献──すなわち、ビジネス部門の要求に迅速にこたえるという目標は、その効果が定量化しにくいという側面を持つ。
「具体的な数字を出さずに、『SOAを利用すれば、従来よりはるかに柔軟なシステムを実現できる。したがってSOAに取り組むべきだ』といった話をビジネス部門にしても通用しない。SOA導入における最大の障壁は、ROI（投資利益率）を数値化するのが困難であるということだ」と、ガートナーのリサーチ担当副社長、ダニエル・ショラー氏は指摘する。
実際、統合ソフトウェア・ベンダーのウェブメソッドがユーザー企業を対象に行った調査では、SOA導入の障害として「知識不足」と「ROIが定量化しにくい」の2つが上位を占めた。
「そこで重要になるのは、ROIを事前に定量化することではなく、IT戦略をどのように業務に適用し、どのような成果を上げるかだ」と指摘するのは、住宅建材・ガラス繊維メーカー大手、オーウェンズ・コーニングの副社長で、CIOと最高サプライチェーン責任者を兼務するデビッド・ジョンズ氏である。
「我々の目標は、SOAを導入することではなく、生産性を高め、サプライチェーンから無駄をなくすことだ。ベンダーが宣伝するような最新性や優位性にとらわれる必要はまったくない」（ジョンズ氏）
ユーザー企業の中にはSOAに対してより懐疑的な見解を示す向きもある。その1人が、金融サービス会社のインストリーム・フィナンシャルでCTOを務めるトーマス・ガニエ氏だ。
「各社が進めているSOA導入プロジェクトを端から見ていると、複雑で杓子定規な中央集権型の仕組みを作ろうとしているだけのように見えることがある。まるで、物事を決めるのに本来の10倍も時間がかかるような仕組みでもつくろうとしているかのようだ」（ガニエ氏）
このように、SOAに対する見方は企業によって大きく異なる。もしも、あなたがSOAを利用したビジネス改革に本気で乗り出そうとしているのであれば、その前に、少なくともこれから挙げる7つの質問に対して明確な答えを用意しておく必要があるだろう。次節以降で、ユーザーやアナリストらの意見を紹介しながら、その7つの質問に対する答えを探っていくことにしたい。
質問｜その1 ビジネス部門に対してSOAをどう説明すべきか？
開発者2人で6人分の作業をこなせるようになり、アーキテクトやプロジェクト・マネジャーは、開発者の作業ペースについていくのが大変になる。いま我々がこなしている仕事は、3年前に比べて50％くらいは増えているはずだ――プロフラワーズ・ドットコムのCIO、ケビン・ホール氏
フォレスター・リサーチのアナリストであるランディ・ヘフナー氏は、「ビジネス部門に対して、SOAという言葉の意味や考え方までを説明する必要はない。SOAを導入することによって得られるコスト削減効果や、パフォーマンスの向上といったビジネス面の価値を分かりやすく提示してやればそれでよい」とアドバイスする。
このうち、コスト削減効果をアピールするには、1つのサービスに統合することが可能な、機能が重複したアプリケーションの数を挙げるのがよいだろう。生命保険会社、トランザメリカ・ライフ・インシュアランスで年金商品／サービス部門のIT戦略担当ディレクターを務めるジェフ・グリーソン氏は、同一のデータが少なくとも26個の異なるアプリケーションによって利用されているという事実を発見し、それをビジネス部門に対する“セールス・トーク”として利用したという。
「データがアプリケーションごとに異なる場所に保存されていたため、その管理費用はかなり高くついていた。私は、複数のアプリケーションが持ついくつかの機能をサービスよって統合することで、そのコストを省くことができると説明した」（グリーソン氏）
一方、SOAを基幹のビジネス・プロセスに適用することによって、システムの柔軟性とパフォーマンスを高めることに成功したのが、生花のインターネット販売を展開するプロフラワーズ・ドットコムである。同社には、機能が重複する余分なアプリケーションも、部門間でサービスを共用したいというビジネス部門からの要望もなかった。ただし、バレンタイン・デーの直前など年に数回、注文が殺到して膨大なトランザクションが発生し、システムがその負荷に耐えられなくなるという問題を抱えていた。
「原因は、花の注文処理プロセスを単一のアプリケーションで処理していたことにあった。そのため、トランザクションの増加に対応するべくプロセスを1カ所でも変更すると、システム全体を再構成しなければならなかったのだ。年々増大する負荷に対応するためには、常に強力なハードウェアに買い換える必要があったわけだ」（プロフラワーズ・ドットコムのCIO、ケビン・ホール氏）
そこで、ホール氏は分散型アーキテクチャであるSOAの利点を生かした提案をビジネス部門に対して行ったという。つまり、注文処理プロセスを複数の個別のサービスに分割すれば、負荷に応じてコンピューティング・リソースを動的に割り当てられることを強く訴えたのだ。この考えに基づく新システムは2002年から稼働を開始しているが、いまだに1度も停止したことがないという。
「新システムでは、注文処理のある段階で負荷が急増すると、サーバ・ファームが、トランザクションが集中しているサービスに対して優先的にストレージを割り当てて対処するという仕組みを採用している。これによって、水平方向（サーバ・リソースの割り当ての拡大やサーバの追加）、垂直方向（サービスの分割による負荷集中の緩和）の両面で、負荷に対応することができるようになった」（ホール氏）
質問｜その2 SOAが適さない企業とは？
質問その1に対する答えからも分かるように、SOAを導入して効果があるのは、複雑なIT環境を抱えている企業である。逆に、すでに社内インフラをマイクロソフトのWindowsプラットフォームなどで統一していて、複雑なアプリケーション統合を行う必要がないような中堅以下の企業では、SOAを導入するメリットがないため導入するには及ばない。
同様に、SAPやオラクルなど、特定のベンダーのアプリケーションを一定以上の割合（今回取材した専門家たちの意見を総合すると、その目安は60％以上）で利用しているような大企業の場合も、SOAを導入する必要があるかどうか、十分に吟味すべきだ。
前出のオーウェンズ・コーニングでは、利用しているアプリケーションの75％がSAP製品で占められている。これは、CIOのジョンズ氏が、製造と販売の工程を世界規模で統一するという戦略を長年にわたって進めてきた“成果”である。「SAP製品を活用することが我々の統合戦略だ」と言い切るジョンズ氏は、当然ながら、SOAの導入には慎重な姿勢を見せる。
また、総合家電メーカーのワールプールも、SAP製品の活用と、グローバル規模でのビジネス・プロセス統合を積極的に推進している企業である。そのうえ同社は、アプリケーション統合をすべてSAPにアウトソーシングしている。
同社のCIO兼コーポレート副社長のエサット・セザー氏は、「特定のベンダーに依存することになっても、私がそのベンダーのソリューションで会社に価値を提供しているかぎり、何も問題はない」と断言する。
質問｜その3 SOA導入によって発生する追加コストは？
SOAのコスト削減効果に過度に期待しているCIOの方にはお気の毒だが、実は、このアプローチを採用することによって“確実に増えるコスト”も存在する。フォレスターのへフナー氏は、SOAに基づくシステム開発では、設計段階における作業量が従来よりも30～100％増大すると推計している。これは、それぞれ固有のニーズを持つさまざまな業務分野で利用できる最適なサービスを設計することが非常に困難であるためだ。この設計段階のコストは、平均するとプロジェクト全体のコストの10％ほどを占めるとされる。
例えば、トランザメリカのグリーソン氏によると、同社で顧客の保険料支払いを処理するために利用されているサービスは、Webサイト、銀行間送金、コールセンターなど、さまざまなチャネルをカバーしているという。となると、当然ながら、サービスの設計時点において、各部門がこのサービスをどのように利用しようとしているかを明確に理解しなければならない。共用するサービスの使用方法について、関係者の同意を取りつけることは、SOAにおいては不可欠な作業なのである。
さらに、ここではもう1つ、開発コストの問題にも注意が必要だ。グリーソン氏が言うように、ビジネス部門は、往々にしてサービスの構築に必要な追加コストを負担したがらないのである。同氏によると、ビジネス部門のプロジェクト・スポンサーは、次のような言い分で出費を渋るのだという。
「サービス開発の費用を払うと、プロジェクトで得られるはずのコスト・メリットが吹き飛んでしまう。そんなお金の使い方はできない。ただ、そのサービスの機能自体は必要なので、より低コストなハード・コーディングによってシステムに統合してほしい」
グリーソン氏は、そのような意見が出てきたときこそ、ITディレクターが本来の役割を果たすべきときだと認識している。
「私はそういうときにはいつも、構築するサービスはビジネス・インフラの要素であり、再利用や変更が可能であるということを説明する。その有効性をビジネス部門に理解させることができれば、彼らは、初期コストがハード・コーディングを行うよりも高くつくかどうかといったことについては心配しなくなるものだ」（グリーソン氏）
質問｜その4 サービスはどの程度再利用できるのか？
初期費用が高くつくのであれば、CIOとしてはなおさら、開発したサービスをできるだけ再利用したいと思うことだろう。この点について、フォレスターのヘフナー氏は、「サービスの再利用性は、設計の厳密さによって大きく異なる。したがって、そのコスト・メリットも、開発者やプロジェクト・マネジャーの能力や経験に大きく左右されることになる」と強調する。
また、サービスのベースとなるアーキテクチャ計画のレベルによっても、再利用性の度合いには幅が生じる。当然ながら、包括的なSOA戦略の一環として開発されたサービスほど再利用性は高く、特定のビジネス・ニーズに特化したサービスになると再利用性は低くなる。
トランザメリカのグリーソン氏は、次のように注意を促す。
「特定のビジネス部門の意見を盛り込んだサービスは、変更するのに時間がかかるため、時間に余裕がない場合には補完サービスを開発しなければならなくなるようなケースもある。だが、それでは二度手間だ。長期的に考えれば、包括的な視点からサービスを設計しないことには、ビジネス・プロセス統合やビジネス・プロセス管理の実現は望めないだろう」
とはいえ、仮に1回でもサービスを再利用することができれば、絶大なコスト削減効果が得られることになる。
へフナー氏はこう指摘する。
「サービスを開発する際には、事前の設計作業に多くの時間を費やすことになるが、既存サービスを再利用するのであれば、設計やコーディング、単体テストのコストは一切かからない。ちなみに、これらの工程の合計コストは、ソフトウェア・プロジェクト・コスト全体の約40％を占めている」
この再利用に関しては、SOAで長い利用経験を持つ企業であっても、将来におけるサービスの再利用を前提に開発を行うのは困難であると認めている。というのも、サービスの“粒度”を適切に設定し、サービスに含まれる処理を多すぎもせず少なすぎもしないようにするには、高度な技量が必要とされるからだ。
自らSOA関連製品を開発／販売する立場にあるIBMで社内IT部門の統合アーキテクチャ担当副社長を務めるハウイー・ミラー氏でさえ、粒度を設定するのがきわめて難しい作業であることを認めている。
「当社の社内システムでは、サービス資産の30％がリターンの90％を生み出しているといったような状況にある。これでも、サービスの粒度の設定がきわめてうまくいっているケースと言える。すべてのサービスの粒度をしっかりとそろえるのは至難の業だ」（ミラー氏）
フォレスターのへフナー氏も、次のようなエピソードを明かす。
「私が以前会った自動車メーカーの関係者は、個々のサービスの利用頻度に最大で20倍もの開きがあると話していた。利用状況にあまりに差があるようでは再利用は難しい」
質問｜その5 アーキテクチャ計画と開発プロジェクトの最適なバランスは？
ここまで、サービス開発の土台となるアーキテクチャ計画の重要性を指摘してきた。だが、この作業は多くの時間と労力を必要とするものだ。それに対して、サービスの開発作業は、すでに実績のあるプログラミング原理や広く普及した技術標準（SOAPやHTTPなど）を利用して行われるため、比較的迅速に進めることができる。では、その両者はどのようにバランスを取りながら推進していけばよいのだろうか。
この点については、「アーキテクチャ計画と開発プロジェクトは並行して進めるべきだ」というのが、今回取材したアナリストやユーザー関係者の共通した意見である。
電力会社アメリカン・エレクトリック・パワー（AEP）で、エンタープライズ・アーキテクチャ兼開発担当マネジング・ディレクターを務めるカート・ウィスナー氏は、「必要に応じて開発プロジェクトを実施しつつ、複数年計画の中でビジネス・プロセスを調査し、エンタープライズ・レベルでサービスの統合を図っている」と自社の体制を説明する。
「このようなプロジェクトの進め方をとっているのも、ビジネス部門に対して、SOAのメリットを早期に示す必要があるからだ。実際にサービスを開発しないことには、我々がSOAに取り組む意義を具体的にアピールできるものが永遠に手に入らないわけだ」（ウィスナー氏）
サービスの開発に手をつける前の段階で、入念にアーキテクチャ計画を策定してプロセス・マッピングを行うのは、確かにセオリーである。だが、“生もの”であるビジネスを支援するうえでは、時として短期間で目に見える成果を上げることも必要だ。そのため、ウィスナー氏のような現実的な選択肢をとるCIOが多いのである。
実際、ウィスナー氏はAEPの前に勤務していた企業で、アーキテクチャ計画に注力しすぎた結果、プロジェクトを失敗させたという苦い経験を持っている。
「何百万ドルもかけて全社的なアーキテクチャ計画の作成に取り組んだが、途中で、作成している内容が既存のアーキテクチャと大して変わっていないことに気づいた。そこで作業が行き詰まってしまい、結果として具体的な成果を何も示せずに終わってしまったのだ。このときに、最初から全社を対象としたアーキテクチャ計画を作成するのは意外にリスクが大きいということを身をもって学んだ」（ウィスナー氏）
こうした経験を踏まえ、同氏は現在、アーキテクチャ計画の作成を小規模な業務領域ごとに進めるようにしている。そうすれば計画の対象が限定されるため、大きな問題になる前に軌道修正を図ることができるという。ウィスナー氏は、「アーキテクチャ計画は、対象を単純な要素に分割すれば進めやすくなる」とアドバイスする。
質問｜その6 どんなサービスに投資をするべきか？
どのサービスを優先して開発すべきかで判断に迷った際には、・顧客にかかわる分野、・売上げに直接かかわる分野、・ビジネス上の課題を解決する分野──の順でビジネス・プロセスを洗い出し、それらに対応したサービスから着手するのがよいだろう。
ビジネス・パフォーマンス・マネジメント・インスティチュートが2006年に実施した調査でも、これらの項目がサービスの優先度ランキングで上位を占めた。例えば、同調査で「ビジネス・プロセスの変更や新しいアプリケーションを導入する理由」を尋ねたところ、1位となったのは「顧客のニーズや嗜好が高度化したため」。以下、「競争上の脅威に対抗するため」、「新しい売上げの機会を得るため」と続いた。ちなみに、「コスト削減を図るため」は、上位3項目とはかなり差が開いて4位だった。
ガートナーのショラー氏は、「顧客に直接関係するようなアプリケーションは、最大のビジネス価値を提供するものであると同時に、多数の変更要求が非常に頻繁に発生するものでもある。したがって、こうしたアプリケーションを10％改良することができれば、他のアプリケーションを50％改良するよりもはるかに効果的だ」と主張する。
質問｜その7 SOAの導入はIT部門にどのような影響を与えるか？
もし、あなたの会社のIT組織が分散型であるとしたら、CIOは組織再編に奮闘する覚悟が必要だ。SOAの導入は中央集権化を促進する、というより、SOAを導入するには中央集権的なIT組織が不可欠だからだ。
工業／建設用品を販売するファステナルで、シニア・システム・エンジニアを務めるマイク・フォールズは、次のように語る。
「SOAプロジェクトでは、先頭に立って組織をリードする人材がどうしても必要になる。また、特定の個人あるいはごく少数のチームによって、全体のアーキテクチャが絶えず管理されている必要もある。これは、中央集権的なIT組織でなければとても実行できるものではない。個々のチームに裁量権を与えてしまうと、おそらくそれぞれが独自のサービス構築手法をとってしまい、収拾がつかなくなってしまうだろう」
このような体制を確立して、各サービスのポートフォリオを充実させていくと、開発プロセスもおのずと様変わりすることになる。AEPのウィスナー氏によれば、それはあたかも「工場の組立ライン」のようなものになるという。
「さまざまなプロジェクト・チームの作業を経るなかで、部品が組み合わされてモジュールになり、モジュールが組み合わされて最終成果物になる、というような流れが生まれるだろう。そして、その工程の中で、需給に応じて作業量を増減させ、製造を調整していくことになる」（ウィスナー氏）
プロフラワーズのホール氏は、このような“SOA工場”が軌道に乗ると、開発者の生産性が向上し、それに伴って、アーキテクトやプロジェクト・マネジャーを増員する必要に迫られることになるという。
「開発者2人で6人分の作業をこなせるようになり、アーキテクトやプロジェクト・マネジャーは、開発者の作業ペースについていくのが大変になる。いま我々IT部門がこなしている仕事量は、おそらく3年前に比べて50％くらいは増えているはずだ」
また、サービス指向開発に携わるプログラマーは、オブジェクト指向プログラミングと分散アプリケーションを理解していなければならない。これは研修への投資が必要になることを意味する。ちなみに、CIO Magazine米国版とComputerworld米国版の共同調査では、「SOAへの取り組みに必要なITスタッフを確保している」とした回答者は25％にとどまっている。また、回答者の49％は、現行スタッフに必要な教育を提供する研修プログラムを計画または実施しているという結果も示されている。
以上見てきたように、SOAに基づくシステム開発手法を導入する際には、ビジネス部門の説得に始まり、アーキテクチャ計画の策定、さらにはIT部門の改革と、さまざまな局面でCIOのリーダーシップが必要になる。
「SOAによるビジネス改革」を目指す取り組みは、CIOにとって長く険しい道程になるだろう。しかしながら、その困難を乗り越えた者だけが、真のメリットを享受することができるということもまた事実なのである。
