ここから本文です
CMS Watch：ECMのオフショアリング /オフショアリングというコンテクストでのECM
2007年11月 2日 掲載
けれども一方で、オフショアリングが期待に100％応えているとは言えないという見方も出されている。その理由は、オフショアリングそのものが駄目だからではない。企業が何をオフショアリングするか、それをどう管理するかに問題がある。
ECM（エンタープライズコンテンツマネジメント）のプロジェクトで採用されるプロセスや、その過程で起こってくる問題点は、他のITプロジェクトと比べても大差がない。にもかかわらず、ECMプロジェクトのオフショアリングには、特有の難しさがある。これから私が説明するアドバイスは、欧米のクライアントのECMプロジェクト（私自身は、コンテンツ、ドキュメント、レコード、アセット管理などの幅広いプロジェクトを指してECMと呼んでいる）に、在インドのスタッフとしてかかわってきた自分の経験に根ざしている。
オンサイトとオフショアの賢いバランス
ECMプロジェクトでは、ライフサイクルの全過程を通じてコンテンツをよく知っている専門家の存在が非常に重要だ。コンテンツマネジメントのプロジェクトが、たとえ商用パッケージ製品の導入だけを目的としたものであったとしても、コンテンツ作成者のほとんどは、導入前に具体的な機能（例えばワークフローなど）を詳細に見る機会がない。それゆえに、プロジェクトを通じてこうした人々に介入してもらうことが重要になる。これは、ユーザビリティやトレーニング、そして最終的なCMSの活用という観点から、決して欠かせない。プロジェクトの最初の時点からビジネスユーザの信頼を獲得していくことが、大きな課題だ。
次に考えるべき点としては、プロジェクトがテスティングや実装段階にある間、オンサイト、つまりクライアントの職場に誰か人を置くという点が挙げられる。納品が段階的に行われるのであれば、オンサイトの担当者は、プロジェクトの全過程を通じて必要だ。私はこれまでの経験で、このオンサイト＆オフショアのモデルを採用するにあたって、コストを削減するためオフショアのコンポーネントを増やそうとするベンダーを目にしてきた。その典型的なやり方としては、オンサイトにわずかのリソースだけを残し、それすらプロジェクトの全ライフサイクルにわたるものではないかもしれない、というやり方がある。けれども、このアプローチが招くものは、さらなるクレーム、ソリューションのない電話会議に費やすさらなる時間、そして結局のところ、さらなる胸焼けでしかない。
同じような問題は、一般的なアプリケーション開発のプロジェクトでも起きる。けれども、アプリケーション開発で起きる状況は、ECMほどひどくはない。多くの場合は、問題の争点が、ビジネス部門の人たちがイメージしたとおりに機能が開発されているか、という点にあるからだ。しかし、ECMプロジェクトでは、製品が最初に決まっていて、コンテンツを扱う人たちが実際に機能（例えば、ワークフローがどのように組まれているのか）を見るのは、導入された後になってから、ということがほとんどだ。
プロジェクトが完了するまでの間は、重要な機能を司る担当者（プロジェクトマネジャーやQA担当者）を相当数オンサイトにおいておくべきだ。これにより、最終的にそのシステムを受け付けるか拒絶するかを決めるクライアントのビジネス担当者と、スムーズなコーディネーションができるようになる。
ECM製品のライセンス
ECM製品の価格設定は、救いがないほど複雑だ。ほとんどのライセンスは、CPU1基、ボックス1個、あるいはユーザ1人あたりという価格設定の何らかのコンビネーションで決められている。このせいで、オフショアのインテグレータがその製品をライセンス使用しなければならない場合に、莫大な付加コストが生じることがあり、多くの場合、それはクライアントが負担することになる。
理想的には、クライアントが取得したライセンスが、距離を超えてインドまでカバーすべきだ。けれども時として、ライセンシング体系に制約があり、クライアントが持っているライセンスを外国に移行するのが難しいことがある。3カ月のプロジェクトで、もしもCPU1基につき5万ドルもする製品のライセンスを追加購入しなければならなくなるとしたら、総コストとしては、うんと魅力が薄れてしまうだろう。
開発ライセンスを外国に移行できるのかどうか、あるいは何かほかのやり方（Citrixを通じたアクセスなど）があるのかどうかを、知っておく必要がある。私の個人的な意見だが、ECMベンダーは、一部のアプリケーションサーバ・ベンダーがやっているようなアプローチを採用すべきだ。つまり、プロダクション用のライセンスを購入した顧客には、開発ライセンスを無料で提供するというやり方だ。
ECMソフトウェア製品を評価する際は、ベンダーに送るリクエスト一覧に必須条件を付け、そのベンダーのライセンシング体系が「オフショア・フレンドリー」かどうかを確かめるべきだ。
何をオフショアリングすべきか
プロジェクトのどの部分であれば、コストパフォーマンス良くオフショアに出せるかを見極めるのは、きわめて重要だ。一般的に言って、削減できるコストというのは、オンサイトのリソースと低コストなオフショアのリソースの単純な差額ではない。物理的に分散したチームをまとめるために必要となるコミュニケーション、コーディネーション、そしてセットアップ費などを考えなければならない。
例えば、アップグレードのプロジェクトでは、少なくとも2つの環境（新旧、そして多くの場合は他の環境も）をセットアップしたうえで、高速接続、VPNなど、もろもろの状況を確保する必要がある。さらに、コストメリットを相殺してしまうコミュニケーションやプロジェクト管理の費用もある。大手のインテグレータは通常、オフショア開発センター（ODC）を持っていて、クライアントのシステムへの高速接続を確保できるが、小さな企業になるとこのようなセットアップはないため、接続が確保しにくいこともある。
オフショアリングのコスト削減効果を計算する際は、コミュニケーション費、追加環境のセットアップ費、高速接続のセットアップ費などを常に加味して考えるのが懸命だ。
コンテンツ入力のタイミング
時には、クライアントが新しいシステムをすぐにも使いはじめたいと言うことがある。膨大な量のコンテンツの処理に迫られているか、コンテンツ担当者が暇にしているかのどちらかの理由からだ。こうしたシナリオで一般的に用いられるアプローチとしては、コンテンツ入力テンプレートを定義して、システムの他の部分を開発している間に、コンテンツ担当者にコンテンツの入力を始めてもらう、というやり方がある。けれども、これは全体の手間を増やしてしまう可能性がある。開発要件が変わるのに応じて、我々開発者は、コンテンツの構造を変えざるを得ないためだ。例えば、フィールドを追加もしくは削除する、メタデータのフィールドを追加するといった変更が生じる。これが起きるたびに、すでに入力したコンテンツは再入力しなければならない。
開発が完了した時点で、古いシステムやプロセスは、新しいシステムに切り替えなければならない。しかし、この切り替え作業中にコンテンツ入力が続いていると、そのコンテンツはすべて、新しいシステムに入力しなおさなければならなくなる。
プロジェクトの初日から最終日までコンテンツ入力を続けるというアプローチは、開発者とコンテンツのオーナーが顔をつき合わせて作業できるのであれば、うまくいくかもしれない。けれども、オフショアリングのシナリオでは、コンテンツ担当者と開発者が地理的に離れ離れになっている。要するに、オフショアリングの状況では、「小回りの利く」ECM開発が通常よりも難しいのだ。
プロジェクトのライフサイクル中、どのタイミングでコンテンツ・マイグレーションを実行するかをあらかじめ決定し、そのタイミングでのみ、コンテンツ入力は行うべきである。
多言語のコンテンツマネジメント
プロジェクトの一環として、コンテンツの入力や翻訳がアウトソーシングで行われるということであれば、ベンダーが適切な言語スキルを持っているかどうかを確認すべきだろう。大手のベンダーは通常、言語スペシャリストと提携関係を築いている。そうでない場合は、言葉のニュアンスまで理解でき、文化的な違いのせいで起きる問題を処理できるクライアント側の担当者が、間に入ることになる。
同様に、グローバルな利用者に向けて作られるアプリケーションも、オフショアリングに際して、それ独自の難しさを持っている。一般に、標準的な技術に基づいてインターナショナライズしたアプリケーションを作るのは比較的簡単だ。けれども、ローカリゼーションは、より多くの困難を伴う。オフショアのインテグレータには、その言語、あるいはその言語が持つ重大な意味合いを理解できる人がいないかもしれないからだ。ゆえに、アプリケーションのテスティングにあたって、彼らが確認できることと言えば、アプリケーションが別の言語を表示するかどうかだけであって、表示された内容が意味のあるものであるかどうかではない。
さらに、オフショアリングの場所についても、検討の余地がある。インド以外でITアウトソーシングの人材源として浮上している国には、中国、フィリピン、東欧諸国、メキシコ、ブラジルなどがある。中国は、中国市場に事業を展開しているクライアントのほか、日本や韓国に展開しているクライアントにとって、有力な候補となるかもしれない。
適切な言語スペシャリストを抱えたベンダーを使うか、さもなければ社内の言語エキスパートを開発チームの一員として登用することで、プラス効果が期待できる。
マルチベンダーのアウトソーシング
我々の大口クライアントが、我々にCMプロジェクトを発注しようとしたことがあった。彼らはすでに、ODC（つまり、もろもろのセットアップ）をインド内の別のインテグレータのオフィスに設置していたが、その会社は、奇しくも我々の競合だった。クライアントは、ライバル企業のオフィスを使って、我々にプロジェクトをやってほしいと考えていたのだ！ 容易に想像できるかもしれないが、こんなことをすれば、大変な「なわばり荒らし」の問題が起こりかねない。IP、アクセスコントロール、施設の利用だけでなく、製品知識やその他の点で、我々の競争力に影響する危険性すらある。とはいえ、マルチベンダーのアウトソーシングをするクライアントが増えていることを考えれば、このようなシナリオは、将来もっと増えるだろう。似たような問題は、国内のアウトソーシングにも起こり得る。しかし、オフショアリングの場合は、問題がもっと大きい。通常、オフショアリングのプロジェクトは、特定のクライアントから、ひとにぎりの優良インテグレータに発注されていて、そのインテグレータ企業は、たいてい規模やスケールの点で互角、しかも直接の競合（WiproとInfosysのように）ということが多いからだ。
オフショアリングのベンダーを決める前に、業界の状況を分析し、インテグレータ間でかち合う可能性がある時は、仕事がオーバーラップしないよう注意すべきだ。
プロダクションシステムへのアクセス
多くの場合、オフショアの開発環境は、オンサイトの開発環境とは異なる。設定、パッチ、サービスパックの違いのこともあれば、場合によっては、オフショアではすべてのアプリケーションが手に入らないこともあるからだ。こうした違いがあるために、オフショアでは完ぺきに機能しているシステムが、オンサイトではうまく動作しないこともある。
最近やったあるプロジェクトで、オフショアで開発されたCMSを、ある統一認証製品と統合して、すべての顧客向けアプリケーションのゲートウェイとして使う、というプロジェクトがあった。ところが、これをオンサイトに納品したところ、統合がまったく機能しなかったのだ。このクライアントは、アウトソーシングは初めてという会社で、プロダクション環境へのアクセス提供を躊躇したため、なぜCMSが動作しないのかをオフショアチームが解明するのは不可能となってしまった。アクセスがない状況で、チームは、Eメールで送られてくるログファイルに頼って、問題を究明していくしかなかったのだ。結局のところ、非常にシンプルな問題だったことが分かったが、コンソールへのアクセスがあったなら、すぐにも解明できていただろう。単に全体の作業量を増やしたにすぎなかった。同じような状況が国内のアウトソーシングで起きていたら、地理的な近さゆえに、トラブルシューティングは比較的簡単だっただろう。また、統合チームがクライアントのオフィスに行ってログを見るだけでも、事は容易になっていたはずだ。
ゆえに、プロジェクトを始める前に、適切なシステムに対するオープンアクセスの重要性について、お互いに理解している必要がある。理解が得られないとしても、たいていは、説明すれば分かってもらえる程度の誤解にすぎないことが多い。また、インテグレータが、クライアントのデータ保護について厳格なガイドラインと規則を策定していれば、さらに役立つだろう。
まとめ
今回のコラムで取り上げたような問題は、伝統的なアプリケーション開発のプロジェクトでも起きている。しかし、ECMプロジェクトには、特有の難しさがある。それは主に、ECM製品それぞれが独自の方法で特定の機能を導入していることに原因がある。このため、コンテンツ担当者は、プロジェクトの全ライフサイクルを通じてかかわっていく必要があり、また、他のほとんどのアプリケーション開発プロジェクトと比べても、より多くのユーザ参加が必要になる。
これらの問題のいくつかは、国内のアウトソーシングでも頻繁に起きている。しかし、国内のシナリオでは、ベンダーとクライアントがたいていは同じタイムゾーン、同じ地域にいて、言葉や文化のせいで起きる一部の問題も緩和できる。コミュニケーションやチームが地域的に分散していることに伴う問題点は、オフショアリングの時ほど浮上してこない。
世界は本当に、日々、フラットになりつつある。オフショアリング全般、そしてECMのオフショアリングは特に、メリットが大きい。けれども、オフショアリングのプロジェクトを決定する前に、慎重を期して、適切な分析をすることも必要だ。また、優れたプロジェクト管理、コミュニケーション、コーディネーション、そしてサプライヤ選択も、やはり欠くことができない。
アプールブは、Wipro Technologies[wipro.com] のポータル・コンテンツマネジメント（PCM）グループで、プラクティスマネジャーを務めている。クライアント向けのPCM戦略策定を手がけるほか、製品購入・製品構築の決定に際してのアドバイス提供、製品評価、PCMの各側面でのコンサルティングにも積極的にかかわっている。
この記事の原文「ECM in an Offshoring Context」は、2006年6月6日、「cmswatch.com」に掲載された。
本サイトに掲載している CMS Watch の記事は、CMSWatch.com より許可を得て、翻訳・転載しているものです。
CMSWatch.com は、ウェブ・コンテンツマネジメントおよびエンタープライズ・コンテンツマネジメント・ソリューションについて、ベンダーから完全に経済的独立をした形で、利用者の立場に立って、独自の情報やトレンド、意見、評価を提供しているサイトです。
CMS Watch はまた、最新の CMS 関連の製品分析やアドバイスが掲載されている The CMS Report の販売(無料サンプルあり)もしています。
・The CMS Report について
トラックバック
このページのトラックバックURL
http://www.designit.jp/mt/mt-tb.cgi/1052