実プロジェクトから学ぶオフショア開発のリスクと解決策のフレームワーク

※本記事は日本ＩＢＭ発行の「PROVISION No.63/Fall 2009」の論文紹介記事に一部加筆・編集して掲載しています。 筆者の経験に基づく個人の意見であり、ＩＢＭを代表する見解ではありません。

日本国内のITエンジニア不足が深刻な問題となる中、海外へITシステムの開発を委託するオフショア開発は当たり前の形態となっている。しかし、残念ながらビジネスとしての実態を見る限り、オフショア開発のすべてが成功しているわけではない。理由は文化や商慣習の違いからくる各種の摩擦、言語面でのコミュニケーション不備、そこから生じるさまざまなトラブルなど実に多種多様である［1］。

IBMもグローバル・デリバリー（海外IBM要員との協業：GD）という形で積極的にオフショア開発を推進している。だが、GDに関しても問題は多種多様であり、いまだに個々のプロジェクトだけでは解決できない問題が数多く発生しているのが実情である。

プロジェクトの集合体であるプログラムの中で、中長期的にGDの問題を解消するにはどのようなアプローチを採ったらよいのだろうか。GD化が進んでいない組織においては、問題自体を認識できていない場合もあれば、認識していても発注先の問題と捉えてしまい、発注元に関しては放置している場合もある。そこで本稿では、GDに関する問題そのものを潜在リスクの1つと位置づけ、図1に示すような従来のリスク・マネジメント手法の流れに沿って、「識別（P1）」「定量化（P2）」「対応（P3）」「管理（P4）」の観点でリスクを解消する方法を提案する。

最初にGD活用で発生しやすい問題を列挙したうえで、IBMが考案したフレームワークを活用してリスクを漏れなく識別し、正しく把握する方法を述べる。続いて、リスク対応策を立てる際に注意すべきポイントについて解説する。さらに、IBM社内アプリケーション開発・保守部門におけるGDの適用事例を基に、対応策の有効性について検証・考察する。

発注元と発注先に見られるオフショア開発の課題

ひと口にGDリスクといっても大小さまざまな問題がある。一般的なオフショア開発においては、以下のような問題があるといわれている［1］。

発注元（日本側）が感じるオフショア開発の問題点

• 言葉が通じない
• 顧客の声や重要度が伝わらない
• 仕様変更に対応してもらえない
• 予想以上にオーバーヘッドがかかる
• 品質に関する意識が低い
• 品質管理レベルが低い
• バグ判定の基準が違う
• 開発プロセスが異なる
• スキルが低い
• 業務知識がない
• せっかく教えてもチーム内で共有してくれない
• 残業に対する意識の差がある
• 離職率が高く、すぐに辞めてしまう
• 機密漏えいの対策が取られているか心配

発注先（オフショア側）が感じるオフショア開発の問題点

• ドキュメントの表現があいまい
• 仕様が不明確なままプロジェクトが開始
• 発注先の意見を聞いてくれない
• 徐々に仕様が決まっていく開発スタイルで生産性が低い
• 間接文書が多すぎる
• 日本側の設計が弱い
• 技術的な提案を受け入れない
• 契約時の計画合意が不十分

これらの問題の多くは識別が容易なものの、すぐに解決が見込めず、長期的な対応策が求められるものが少なくない。またGDの問題においては、このような中長期的な潜在リスクだけではなく、日々のプロジェクトや作業の中に潜む短期的な潜在リスクも確実に発見することが重要になってくる。

GD Frameworkを活用してリスクの候補を識別

短期的な潜在リスクを漏れなく発見すると共に、中長期的な潜在リスクも含めてすべてのGDリスクを管理するには何が必要か。その方法について詳しく見ていく。

前述の通り、GDの問題は文化・言語の違いに起因するものから単純な誤解まで実に幅広い。それらの問題を漏れなく識別するために、確認項目（リスクの候補）を種別・整理した「GD Frame-work」を作成した（表1）。

GD Frameworkでは、GDに関する問題を発生頻度の多い順に「Resource」「Skill」「Project」「Program」「IT Infra」「Finance」「Other」のカテゴリで構成している。ここで示す確認項目およびカテゴリは、あるITシステム開発プロジェクトにおける事例の抜粋であるが、参照し活用していただくことで大いに役立つと考える。

発注元と発注先との間で定期的に開催される会議などのコミュニケーションの場では、各々のカテゴリ内で発生し得る潜在リスクを識別するために、表1の確認項目について毎回確認を行う。そして識別されたリスクは、リスク管理台帳などに記録保管し、確実にフォローしていく。

このようにGD Frameworkを活用することで、発注元で感じるリスクだけでなく、発注先で感じる中長期的なリスクや見逃されやすい短期的なリスクまで、すべてのリスクを識別することが可能となる。

洗い出したリスクの発生確率や影響度を定量化

GDリスクの識別に次いで実施するのはリスクの定量化である。リスクの定量化とは、洗い出したすべてのリスク項目を対象に、発生しそうな時期や発生する確率、影響の大きさなどを評価する作業だ［2］。

ここでは先に個条書きしたリスクを基に、プロジェクトにおいて発生しがちな項目を洗い出し、それぞれについて定量化を実施する。定量化の際、GD Frameworkを用いてリスクを選別するとよい。後工程で対応策を立案しやすくするためだ。こうして定量化した一覧が表2に示す「GD Frameworkリスク比較検討表」である。

GD Frameworkリスク比較検討表の見方を簡単に説明しておこう。発生確率と影響度はそれぞれ、複数年にわたる過去の実績値の蓄積や事例などの統計データを参考にして導出した。リスクの優先度は基本的に発生確率と影響度を掛け合わせたものだ。表3のように、あらかじめ定義した対応表に従って評価している。

このうち発生確率と影響度は、客観的な指標を用いて評価すれば大きな問題はない。しかし、リスクの優先度に関しては発注元と発注先の双方で事前に合意しておくようにしたい。双方で優先度に対する考え方に少なからず相違点が存在し得るからだ。

また、リスクの識別と定量化はプロジェクトの提案時や計画時など、早い段階で実施するのが一般的である。だが、今回のようにプログラムとして長期的に取り組む場合は四半期や半期、1年などの期間で継続的に実施することが望ましい。このことは組織の育成においても非常に重要になる。

なお、表2と表3の項目と値は、あるITシステム開発プログラムと、それに関連する個別プロジェクトの特性や傾向を踏まえ導出した内容を再編集したものである。他のプロジェクトにこのまま適用できる内容ではないものの、項目や値を同様のフォーマットで整理するうえで大いに役立つだろう。

優先度を見極めリスク対応策を立案

GDリスクを定量化した後は、優先度の高い項目から順にリスク発生の可能性あるいはリスクが発生した場合の影響を最小限にするための対応策を立案する［2］。

一般に、リスク対応策としてよく用いられる方法には(1)「回避策」、(2)「軽減策」、(3)「受容策」、(4)「転嫁策」の4通りがある。このうちGDリスクの対応策として、(1)すなわちGDの活用自体を回避するような方法を採るケースはあまりない。GDの活用はITシステム開発組織の組成方針である場合が多く、(4)のように第3者に「転嫁」することも難しい。したがってGDのリスク対応策では、(2)と(3)の策定をすることが多い。

リスク対応策を策定する際に忘れてはならないのが、実施責任者と期日の設定である。実施責任者には該当リスクの対応に一番ふさわしい人間を選ぶことになるが、GDリスクでは大抵の場合、実施責任者が発注先になる。

もちろん、発注先にリスクに対応するための余裕がないケースも少なからずある。その場合は発注元の協力が不可欠になる。発注元はリスクの実施責任が発注先だとしても、資金面などで発注先をサポートし、共にリスクを回避していく姿勢を持たなければならない。

すべてのリスクを網羅して対応策をあらかじめ策定することが、必ずしも現実的ではない点も意識しておきたい。繰り返し述べたように、GDに関するリスクは多岐にわたるからだ。網羅しようとすれば、特に財務面で無視できない負担を抱えることになりかねない。現実的には、立案したリスク対応策ごとに、対応に要するコストやリスクに対する効果、実現の容易性（可能性）などをリスク優先度と共に考慮し、最終的に実施するリスク対応策を決定することになる。

短期・長期のサイクルで的確かつ継続的にリスクを管理

最後はGDリスクの管理である。管理には実施状況の確認と対応策の確認という、大きく2つの意味がある。前者は、実際に発生した、あるいは発生する兆候を検知したリスクの状況を正確に把握し、計画に従って確実に対応策が実施されているか否かをトラッキングする。後者は、発生の有無にかかわらず、定期的にリスクと対応策を検証して、必要に応じて更新する。

言い換えると、起こり得るリスクとその変化に対し、的確かつ継続的にリスク・マネジメントを実施すること。そしてリスクの識別、定量化、対応策の立案・実施、対応策の管理という一連のサイクルを繰り返すこと。GDリスクの管理では、この両面を兼ね備えるのが重要だ［3］。

特にサイクルについては、その頻度に注意を払いたい。GDリスクの状況は日々変化する。そのため週次の定例会議を設け、GD Frameworkを活用しながらGDリスクの状況を確認する。それと同時に、四半期や半期、1年などの比較的長期のサイクルも繰り返すのが望ましい。GDリスクに対する対応策の効果はすぐに現れないものも多いからだ。

GDリスク対応策の有効性を実プロジェクトで検証

先に挙げたGDリスクの対応策については、その有効性を検証済みである。筆者自身が実際のITシステム開発プロジェクトで各種対応策を実施している。

筆者が所属する社内アプリケーション開発・保守部門（IBM Global Account Application Service：IGA.AS）では、1999年から2008年にかけて中国IBMとの協業（GD）割合が増加傾向にある（図2）。現在は中国だけでも数百名と協業し、全体要員の約6割を占めている。

2004年以降は組織内にGD 推進チームを作り、GD関連のさまざまな問題に取り組んできた。筆者自身も2006年4月から中国大連に赴任し、前半は中国側から、後半は日本側からGDリスク対応策の策定に深く関わってきた。

以下では、実際に実施した中から、他のケースでも発生確率が高いと思われるGDリスクに関する対応策の具体例を紹介する。

例1： アサイン計画の作成などで要員をタイムリーに配置

a）リスク：日本の要求通り要員をタイムリーに配置できない。

b）対応策：（1）年間のプロジェクト・プランを共有することで、発注先の要員計画を可能にする。（2）要員計画では発注先の全メンバーのアサイン計画を作成し、要員の過不足を把握する。（3）日本からの要員要求が計画外の場合は、配置できない場合もあるが、その際には既存プロジェクトとの優先順位を付けて解決する。

c）分析と考察：要員要求に対する適正な要員配置は、プロジェクトの初期段階における最大の課題である。基本的には日本側の要員と同様、発注先の要員についてもできるだけ早い段階で計画することでリスクを軽減することが重要になる。

例2： 離職率の高さを受け止め要員やスキルを固定化

a）リスク：発注先の離職率が高く、要員およびスキルが固定しない。

b）対応策：（1）キャリア・モデルを導入し、発注先メンバーのモチベーションを高める。（2）メンバー・ローテーションの年間計画を日本と共同で作成し、影響のない異動を実施する。（3）主要メンバーのバックアップ要員を育成し、万が一の離職に備える。

c）分析と考察：発注先の離職率が日本に比べて高い（中国の場合2007年当時で15〜20％）ことは社会的要因であるため、まずは事実として受け止める必要がある。そのうえで、こうした環境下で彼らを引き止めるために、彼らにとって魅力的な仕事を用意することを考慮する必要がある。

しかしローテーションなどを実施すると、現在の仕事に必ず影響が出るので、どこまで実施するかは判断を要する。また、施策を実施しても離職するメンバーは必ずいるので、万が一のバックアップ要員を育てておくことが重要になる。

例3： 研修や目標の設定を通じてスキルや業務知識の水準を向上

a）リスク：発注先のスキルが要求するレベルに達しない。経験や商習慣の相違から、要求する業務知識レベルに達していない。日本の業務に対する理解の食い違いがある。

b）対応策：（1）メインフレーム、Web、Notesなどの研修実施。（2）アプリケーション勉強会の実施。（3）全メンバーのスキル管理と四半期評価の実施。

c）分析と考察：発注先の開発・保守要員は若く、経験年数が浅いことが多い。それゆえ、スキルが不足しているメンバーが多いのは事実である。

このリスクを軽減する目的で、発注先でも研修を実施しているが、日本の業務知識などのスキルを上げるのには限界がある。そのため日本側でもスキル育成に向けて投資し、さまざまな研修を展開している。

スキル育成については発注先に責任を持たせるために、発注先で毎年明確なスキル目標を立て、目標達成に向けた支援と監視をする。その際にスキル管理データベースを活用し、発注先の全メンバーの育成計画、研修受講履歴、四半期ごとのスキル評価を管理している。

例4： 意思疎通の正確さを高める計画的な語学研修と用法の配慮

a）リスク：発注先の日本語が堪能ではない。

b）対応策：（1）日本語教育の実施。（2）日本側が意識して、分かりやすい日本語を使う。（3）コミュニケーション・ツールの活用。

c）分析と考察：言うまでもないが発注先にとって日本語は外国語である。しかも多くのメンバーは、IBMに入社してから日本語を勉強する。GDC（IBM Global Delivery Center）Chinaでは外国語教育に力を入れており、日本向けITシステム開発チームに配属されたメンバーは、入社と同時に日本語教室に参加する。

日本語教室は計画的に運営する。例えば必須受講時間（週当たり4時間が標準）や、定期的な受講時間帯をあらかじめ決めておき、参加必須としている。こうすることでGDC社員は、多少の個人差こそあるが、1年で読み書きができるレベル、2年で話せるレベルに成長していく。

彼らがこれだけ努力しているのだから、足りない部分は日本側で補うしかない。「カタカナや二重否定は使わない」「依頼の際は、回りくどい表現や丁寧すぎる表現をしない」といった意識を持つことで、相手には格段と伝わりやすくなる。

例5： 見積もりの研修やひな形を用い正確な作業内容の合意を図る

a）リスク：契約時の計画合意が不十分。

b）対応策：（1）発注元の作業依頼内容の精度向上。（2）発注先の作業見積もり精度の向上。（3）作業依頼書のひな形を提供。

c）分析と考察：発注先との協業においても、作業依頼書で作業範囲を合意してから作業を開始する。しかし、欧米式の契約社会に慣れていない日本人は、明確な作業依頼を出すのが苦手な場合が多い。そこで、まずは日本側を教育する必要がある。

次に発注先の見積もり精度の問題が出てくる。前述の通り発注先には若いメンバーが多いため作業の見積もりができない、もしくは見積もりの精度が低い社員が少なくない。そのため発注先には見積もりに関する研修を実施する必要がある。作業依頼書のひな形を用意するなど、工夫を凝らして品質を高めることが大切だ。

例6： プロセス共通化と文書整備で成果物の品質を上げる

a）リスク：日本側のドキュメントの表現があいまい。開発の中で間接文書が多い。

b）対応策：（1）開発プロセスの共通化。（2）保守ドキュメントの整備。（3）ドキュメント以外のスキル継承。

c）分析と考察：IBMは2007年度から、「IGSDF（IBM Global Solution Delivery Framework）［3］」と呼ぶ共通フレームワークに、全世界のITシステム開発プロセスを統一した。これにより開発に必要なドキュメント類が全世界で共通化できた。

筆者の組織ではアプリケーション・システムの保守作業を中国側に依頼しているが、その際に必要となるアプリケーション保守ドキュメントの整備にも力を入れている。最近は、動画ツールを利用した効率的な引き継ぎの試み「スキル継承タスク」にも取り組んでいる。

話は少しそれるが、中国駐在中の筆者の先輩が現地での経験から得たという教訓を紹介したい。「発注先の成果物（アウトプット）の品質を上げるには、日本側からの要求（インプット）の品質を高める必要がある」。考えれば当たり前のことだが、この重要なポイントを多くの日本人はあまり意識していないように思う。

例7： 品質改善は1日にしてならず基準の明確化や定期研修を実施

a）リスク：発注先に顧客の声が伝わらない。発注先の品質に関する意識が低い。発注先の品質管理レベルが低い。

b）対応策：（1）品質基準の策定と合意。（2）品質課題の具体事例の収集と教育。

c）分析と考察：品質の話をする前に、海外と日本では常識や認識にズレがある点を理解しておく必要がある。発注先となる海外では、より有利な条件の職を得ようとする競争が激しいため、「仕事をできる」と主張する傾向が強い［4］。

ここで、前ページの表4を見てほしい。仕事の出来具合に点数を付けた際、100点、90点、80点をどのように評価するかを示したものだ。海外では100点は優秀、90点は合格、80点はギリギリ合格と捉える。これに対し、日本は100点以外は不合格と考える。こうした海外と日本の感覚の相違は文化や常識の違いからくるもので、変えるのは困難である。そのため前向きに受け入れることが肝要だろう。

そうかといって、品質のリスクに関して打つ手がないわけではない。何より、何ができれば合格かという基準を作成し、発注先と合意することが重要だ。筆者の経験では、インスペクション範囲や欠陥数などの品質基準と評価基準を明確に定めることで、文化や常識のズレによる品質リスクが生じにくくなる。

また、単に「品質が悪い」と言うだけでは、何が悪いのか理解できない。そこで、プロジェクトの具体的な事例を通して「何が悪いのか」「どうすべきだったか」を考えてもらう品質改善研修を定期的かつ頻繁に実施している。“品質改善は1日にしてならず”である。

互いに尊重し信頼関係を築けば成功への道が切り開ける

オフショア開発におけるリスク・マネジメントは、「現状を認識し、リスクを正しく識別する」ことから始まる。そしてリスクを日本側だけでなく発注先と共に評価する。さらには、リスクの対応においても発注先のみに押し付けるのではなく、相互に協力する。そのいずれかが欠けてもGDリスクは解決できない。

反対に、すべてを実施できれば、GDリスクの軽減において一定の成果が期待できる。現に筆者が経験したプロジェクトでは、GDリスクを管理してきた結果、品質や技術力は上がり、離職率は大幅に低下するという数値になって成果が現れている（図3）。

もっとも、本稿は筆者と中国IBMとの協業経験を基に執筆したものであり、すべてのGDに適応できるかを検証するのは今後の課題である。ただ、ここで提案したフレームワークによるGDリスク管理は、グローバル化を目指す組織、特に我々と同様にアプリケーション保守案件をサポートするチームの参考になるだろう。

最後に、一言だけ付け加えておきたい。

オフショア開発は多くの課題が指摘されていることから、積極活用を避けるための理由を探そうとする人がいるかもしれない。しかし世界がフラット化され、例えばインドのITベンダーが世界の開発拠点となりつつある今、グローバル企業を目指すかどうかに関係なく、海外との協業は避けて通れない道だ。

もちろん、違う文化で育った者同士が一緒に仕事をすることは容易ではない。しかし相手の立場や考え方を尊重し、互いを理解し合う。そうすることで信頼関係を築ければ、GD成功の道は自ずと切り開けるはずである。その点を肝に銘じて、今後も海外との協業を進めていただきたい。

参考文献

［1］ S-open オフショア開発研究会：ソフトウェア開発 オフショアリング完全ガイド、日経BP 社、ISBN4-8222-2970-X、（2004）
［2］ 布川 薫：リスク・マネジメント─潜在するリスクを識別・評価し対策を立てて管理する
http://itpro.nikkeibp.co.jp/article/COLUMN/20080222/294453/?P=1&ST=bizskill（2008）
［3］ 日本アイ・ビー・エム：ガラパゴス日本からの脱却 http://itpro.nikkeibp.co.jp/as/ibm_gid/page03.shtml（2008）
［4］ オフショア開発エクスプレス、技術評論社、ISBN978-4-7741-3443-7、（2008）
［5］ Project Management Institute：プロジェクト・マネジメント知識体系第3版（PMBOKガイド）、（2004）