[最前線]

2010年3月4日(木)藤本 卓司

日本国内の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リスクに対する対応策の効果はすぐに現れないものも多いからだ。