【オフショア開発】は今でも効率的なのか ?

皆さん、海外でソフトウェアを開発する、【オフショア開発】を検討した事はありますか?

【オフショア開発】と言えば、「安い、早い、旨い」ではなく、システムが安く作れる、と言うイメージがあると思います。

今回は、【オフショア開発】に関して、その費用対効果を、次の点から検討してみたいと思います。

【オフショア開発】とは何か
【オフショア開発】のメリット/デメリット
【オフショア開発】の成否の分かれ道
【ソフトウェア/システム開発】の現状
【オフショア開発】の費用対効果

【オフショア開発】の「安くて速い」神話の信ぴょう性を確認したいと思いますので、今回も宜しくお願いします。

- - - - -

■【オフショア開発】とは何か

最初に、【オフショア開発】の意味が解らない方のために、【オフショア開発】とは何かを説明します。

もともと【オフショア】とは、「Off(離れる)-Shore(岸)」と言う日本語のため、「沖合」を意味する言葉なのですが、日本のIT業界では、1990年代の後半辺りから、「海外での開発作業」を意味する言葉として使われ始めました。

しかし、欧米のIT企業が用いる【オフショア】は、日本で使われている言葉の意味とは異なり、昼夜の時差を利用して、欧米が夜の時点で、昼になっているインド等で、ソフトウェアのメンテナンスやサポートを行う作業のことを意味していました。

この仕組みのお蔭で、インドでは、情報通信業が急拡大し、現在では、インドの主要産業になっています。

日本で【オフショア開発】と言う言葉が使われ始めたのは、中国が「世界の工場」として注目され始めた時期と重なります。

人件費が格段に安い中国で、大量に人材を投入し、安く、早くソフトウェアを開発しよう、と言うのが【オフショア開発】の狙いでした。

その結果、大手IT企業が、中国にシステム子会社を設立し、日本で高額で受注した案件を、中国の子会社で作成して、利益を上げる構造が作られました。

この構図は、IT業界に限らず、全ての業界で用いられており、現在では、さすがに中国は人件費が高騰したので、ベトナム、タイ、パキスタン等、人件費が安い国を求めて、東南アジア各国に拠点を設けています。

私自身、国内の産業人口の空洞化を招く主要因の一つが【オフショア】への生産拠点の流出であることは認めますが、経営者としては、仕方がないのではいかと思っています。

また、オフショア拠点が設置される地域の多くは、発展途上の地域と重なりますので、地域の成長を日本企業が支えている、と言う意味でも好ましいと思います。

このため、オフショアに拠点を設ける企業には、余計なお世話だとは思いますが、地域の文化や人権等に最大限の配慮を忘れない事を期待しています。

以上が【オフショア】の説明でしたが、理解頂けましたか?

それでは次に、肝心のIT業界における【オフショア開発】のメリット/デメリットについて検討したいと思います。

- - - - -

■【オフショア開発】のメリット/デメリット

次に、【オフショア開発】のメリット/デメリットについて、簡単に解説しますが、大方の予想どおり、メリットは次の3点に絞られてしまいます。

●メリット

(1)開発費用が安い
(2)(比較的)納期が短い (日本国内でも短納期の会社はあります)
(3) プロジェクトに大量の人材を一気に投入することができる

●デメリット

(1)品質に問題があるケースが多い
(2)メンテナンス(保守)に問題がある
(3)日本語ドキュメントが作成できない/作成できても文脈がおかしい
(4)仕様変更に柔軟に対応できない
(5)設計書を緻密に作成する必要がある/設計書の作成に時間が掛かる
(6)担当者と直接打ち合わせができない
(7) 担当者と会話ができない/日本語が通じない

その反面、上記の他にもデメリットは山ほど挙げることができます。

製造業では、ある程度、現地人のスキルアップが図れれば、後は同じ作業の繰り返しなので、【オフショア】での作業は、次第にメリットの方がデメリットを上回るようになります。

しかし、ことIT業界の【オフショア】作業においては、ドキュメントやコミュニケーションが最も大切な要因になりますので、メリット、つまり費用対効果を出すには難しいものがあります。

ある意味、IT業も製造業と同様、ソフトウェアと言う(無形)物を作成する業種なので、IT業界に身を置いたことが無い方は、【オフショア】での作業も、製造業と同じではないのか、と思われるかもしれません。

ところが、IT業の成果物である【ソフトウェア】と言う物が「くせもの」なのです。

部品や衣服等の有形物であれば、作った実物を見せて、簡単に不具合を指摘し、改善方法を伝授することができます。

しかし、ソフトウェアの場合には、まずは成果物を動かしてソフトウェアの動作を確認し、不具合があれば、プログラムのソースコードを分析し、その上で不具合(バグ)を指摘しなければなりません。

簡単なプログラムであれば、直ぐにバグを見つけることも可能ですが、ソースコードが「何万行」も存在するプログラムや、多数のプログラムを結合させて作成するソフトウェアでは、不具合箇所を特定するだけでも【至難の業】なのです。

それに加えて面倒なのは、ある処理結果を得るためのソースコードが、何通りでも作成できてしまう点があります。

例えば、「A」ファイルと「B」ファイルと言う2つのファイルから、「C」と言う別ファイルを作成するプログラムがあったとします。

「A」：出勤簿：社員名、出勤日、勤務時間
「B」：交通費請求書：社員名、外出日、外出時間、交通費
「C」：出退勤管理表：社員名、出勤日、勤務時間、外出日、外出時間、交通費

・プログラム「X」の処理

(1)	Aの情報を一度に全て入力し、別の領域に情報を保存して、Aの情報は破棄する
(2)	Bの情報を1件だけ入力して社員名を取得する
(3)	次に(1)で作成した領域から同じ社員の情報を取得
(4)	Bの社員情報と(3)で探し出した社員情報を結合してCの情報を1件作成
(5)	上記(2)〜(4)の処理を繰り返す

・プログラム「Y」の処理

(1)	Aの情報とBの情報を、あらかじめ社員名をキーにして昇順のソートする
(2)	Aの情報を1件だけ入力して社員名を取り出す
(3)	次にBの情報を1件だけ入力して社員名を取り出す
(4)	Aの社員名とBの社員名を比較し、社員名が一致していたら、Aの社員情報とBの社員情報を結合してCの情報を1件作成し、(2)の処理に戻る
(5)	Aの社員名とBの社員名の大小比較を行い、Bの社員名がAの社員名より大きければ、次のAの情報を1件だけ入力して社員名を取り出して、(4)の処理に戻る
(6)	上記(2)〜(5)の処理を繰り返す

上記2つのプログラム「X」とプログラム「Y」は、どちらも同じ処理結果が得られます。この場合、どちらのプログラムの方が、処理スピードが速いでしょうか?

答えは、プログラム「Y」です。(久しぶりに処理ロジックを考えたので間違えていたらゴメンなさい。)

プログラム「X」の場合、(1)の処理で、別の領域に保存した情報は、社員名をキーにしてソートされていませんので、常に、毎回、保存領域の先頭から社員名を検索する必要があります。

しかし、プログラム「Y」は、あらかじめ情報を社員名でソートしてありますので、無駄がありません。

同じ処理結果を得るだけでも、何通りものプログラムの作成方法がありますし、プログラムの作成の仕方により、処理結果は同じでも処理パフォーマンスが大幅に異なるケースがあります。

ちなみに、プログラム「X」の場合でも、最初にファイルのソートを行えば、取り扱うファイルの種類によっては、プログラム「X」の方が、プログラム「Y」よりも処理スピードが速いケースもあります。

このように、プログラムの作成は、他の製造業とは異なり、単純に、「そこを直せ」、「あれを直せ」と言う指示ができないので、ドキュメントの書き方や、コミュニケーションが重要になってきます。

- - - - -

■【オフショア開発】の成否の分かれ道

IT業界における【オフショア開発】の成否には、当然ながら様々な要因が関係しますが、大きくは、次の3点に絞られます。

設計書の内容
ブリッジ(仲介者)の選定定
契約書の内容

●設計書の内容

ソフトウェアの開発を行う際には、必ず設計書を作成します。そして、この設計書も、場面や要求事項に応じて複数作成する必要があります。

画面設計書：システムで画面を提供する場合に作成します
データベース設計書：システムでDBを使用する場合に作成します
帳票設計書：システムで帳票を出力する場合に作成します
詳細設計書：実際にプログラムを作成する人が作成します

日本国内で開発作業を行う場合、これら設計書は、(余り公言はできませんが)かなり大雑把な内容となっています。

しかし、開発作業を外注化する場合などは、割と細かな部分まで作成しますが、それでも細かい部分は省略されます。

これは、下記の内容を(暗黙の)大前提にしているからです。

プログラムを作成する人は日本人
プログラムを作成する人には、ある程度の必要スキルが備わっている
ある程度の説明さえ書けば、不足部分に関しては「行間」を読み取ってもらえる

しかし、これが【オフショア開発】となると、事情は全く異なります。

プログラムを作成する人は外国人
日本語など理解していない
説明の「行間」など解らない
どのようなスキルを持っているのかも解らない

このため、設計書には、事細かに、全てのケースを想定した内容を記載する必要があります。

また、設計書を完璧に作成しても、相手には日本語は通じませんので、これを現地の言葉に翻訳する必要があります。

翻訳自体は、通常は受注企業、つまり【オフショア】側の企業が行ってくれますので、日本企業が行う必要はありません。

しかし、設計書を完璧に作成しても、翻訳を間違えられてしまえれば、元も子もないのですが・・・

とにかく、全ての設計書を、漏れなく作成すれば、ある程度、【オフショア開発】の成功度合を高めることが可能です。

●ブリッジ(仲介者)の選定

【オフショア開発】を行う場合、日本側企業と【オフショア企業】との間に、【ブリッジ】と呼ばれる技術者を介在させます。

この【ブリッジ】と呼ばれる技術者は、言葉の通り、日本とオフショアの【橋渡し】を担う人材になります。

このため、【ブリッジ】が優秀でないと、【オフショア開発】は絶対に失敗します。

この【ブリッジ】は、発注者(日本側)の意向を、受注者(オフショア)に伝えたり、開発の進捗状況を発注者に報告したりします。

このため、【ブリッジ】が優秀でないと、日本側の意向が【オフショア企業】に正しく伝わらず、結果として開発作業が失敗してしまいます。

しかし、この【ブリッジ】の選定が非常に難しく、私も以前【オフショア開発】を依頼したことがあったのですが、この【ブリッジ】の選定に失敗したので、プロジェクトを失敗させた経験があります。

もちろん、【ブリッジ】が全て悪い訳ではありません。発注者側、つまり私が、【ブリッジ】の言う事を、全て【信頼】してしまったのが失敗の原因です。

さて、ここで、日本語の勉強です。

【信頼】と【信用】の違いは何でしょうか?

【信頼】とは、相手を信じて頼ってしまう事で、【信用】とは、相手を信じて用いる事だと、私は理解しています。

つまり、【ブリッジ】に全てを任せてしまい、日本側では、進捗だけを管理していたのが悪かったのだと、今では反省しています。

日本側で進捗状況の管理を行うだけでなく、作成中のプログラムを都度提出させ、中身までチェックしていれば、あるいはプロジェクトは成功していたかもしれません。

しかし、当時は、単純に、日本で外注に開発を依頼するイメージで【オフショア開発】を行っていたので、そこまでは気が付きませんでした。

その結果、出来たプログラムは全然動かず、最終的に、全て社内で作り直す羽目になってしまいました。

【ブリッジ】の選定には、次の様なチェックを行う必要があると思います。

(1)IT業界出身者か ?
(2)自分で設計書やプログラムを作成した経験があるのか ?
(3)プロジェクト管理の経験はあるのか ?
(4)現地の言葉を、ちゃんと話せるのか ?
(5)これまでの【ブリッジ】経験は豊富なのか ?
(6)成功した【オフショア開発】の事例は豊富か ?

当然、上記の確認事項に関しても、【ブリッジ】の言い分だけを信用せず、ちゃんと裏付けを取ることも忘れずに行う必要があります。

●契約書の内容

これは、別に【オフショア開発】に限った事柄ではありませんが、とにかく成果物が要求事項を満たしていない場合には、支払を拒否する条項を、契約書に明記すべきです。

また、要求事項を満たさない場合でも、程度に応じて費用を支払う条項を契約書に記載するケースがありますが、この条項は削除すべきでしょう。

日本側としては、【オフショア開発】を依頼するために、通常よりも時間を掛けて設計書を作成している訳ですから、その工数・費用を考慮すると、「プログラムの半分は動くのだから、費用も半分支払って」と言われても、「はい、そうですか」とは言えないと思います。

中途半端なプログラムを納品されても、結局は作り直しになる訳ですから。

それと、相手は海外の企業ですので、所轄の裁判所は、日本企業が存在する地域を選ぶべきです。裁判と言う、最悪の事態も考慮しておくべきだと思います。

これだけの準備を整えておけば、【オフショア開発】も、ある程度成功する確率が高くなると思います。

- - - - -

■【ソフトウェア/システム開発】の現状

ここで、現在のソフトウェアの開発スタイル(開発手法)について考えてみたいと思います。

一昔前までは、「システム開発」と言えば、次の様な過程を踏んでいました。

開発プロジェクトを開始
プロジェクトリーダーの選定
プロジェクト概要作成(成果物/開発期間/開発費用、等)
プロジェクトの承認
プロジェクトメンバー選定・作業開始
膨大な設計書作成
プログラム開発開始
システム試験実施
システム納品

少し大雑把ですが、システム開発では、上記の様な流れで、大きなシステムですと1年〜数年を掛けて、システムを作成していました。これを【ウォーターフォール型】の開発手法と呼んでいました。

この場合、開発プロジェクトをスタートさせた時期と、システムが納品される時期が、年単位でずれてしまいます。

企業を取り巻く環境に、余り変化が無い時代は、上記の様な開発スタイルでも問題はありませんが、現在では、数か月単位で企業環境が変動してしまいます。

プロジェクトの開始時期と、システムの納品時期が、年単位でズレてしまうと、当初必要と思えた機能が不要になり、別の機能が必要になってきたりします。

このような状況では、従来の開発スタイルで開発作業は行えません。必要な機能を、数週間、あるいは1〜2か月で作成し、直ちに本番稼働する必要があります。

そこで、現在注目されている開発スタイルが【アジャイル開発】と言う開発手法です。

【アジャイル(agile)】とは、日本語で「俊敏な」を意味する形容詞になりますが、IT業界では、迅速かつ適応的にソフトウェア開発を行う軽量な開発手法と言う意味になります。

つまり、必要な機能だけを素早く作成して本番稼働させ、その都度、必要に応じて機能追加、あるいは機能修正を行う、と言う開発手法です。

【アジャイル開発】にも、様々な手法が存在し、有名な開発手法としては、次の様な手法があります。

(1)	XP	小規模で非常に動的なプロジェクト
(2)	スクラム	全体を管理し、ビジネス価値を最大化し無駄を少なくする方法 (ビジネス価値優先)
(3)	リーン	スクラムと同様だが投資収益率（ROI）優先
(4)	FDD	スクラム、リーン、またはXPと組み合わせて統合する技法
(5)	AUP	大人数のチーム、分散チーム、重要度の高いシステムに適している
(6)	クリスタル	プロジェクトの規模と重大度によって変わる開発手法のファミリ

【アジャイル開発】に関しては、別の機会に紹介しようと思いますが、要は、ユーザの要求を直ちに取り入れ、短納期でリリースし、保守をしながら機能を追加して行く、と言う流れになります。

現在の企業状況では、1年も掛けたシステム開発は行えません。このため、短納期で、保守し易いシステム開発が求められています。

- - - - -

■【オフショア開発】の費用対効果

これまで、次の様な観点で【オフショア開発】を検証してきました。

【オフショア開発】とは何か
【オフショア開発】のメリット/デメリット
【オフショア開発】を成功させるコツ
現在求められている開発手法

以下に、日経ビジネス誌に掲載された「まつもとゆきひろ」氏(※)の記事を簡単に紹介したいと思います。

「オフショア開発/アウトソーシング」として、ソフト開発を製造業と同様、低賃金で作り上げる効果が日本企業のメリットとして取り沙汰されている
中国に開発を委託している企業にヒアリングを行うと「実は安く作れない」とこぼしている
その理由の1つは「コミュニケーション」の対価である
開発を委託するには設計書を詳細に作る必要があるし、設計書通りに作成しても、手直しが必要になるが、その際に日本と中国でコミュニケーションが障壁となる
間に入る技術者の能力次第で、費用がかさみ、結局高くついたと言う結末になる
ソフト開発手法も大きく変化し、以前は1,000人規模のプロジェクトも存在したが、巨大システムは開発期間が長期に渡り、その後の保守にも手間が掛かるし、その間にビジネス環境も変化してしまう
現在は2001年に提唱された「アジャイルソフトウェア開発」がトレンドになっている
大きな予算を注ぎ込んで大規模システムを開発するのではなく、企業内に小さなシステムを積み重ねていき、目的に応じて修正を加える手法である
少数精鋭で、利用者に近い環境で開発を行う手法で、低賃金で大量の技術者を使う手法とは異なる
ソフトウェアの生産は、自動車の生産工程にも例えられが、決定的な違いがある
「海外で作れば安くなる」そんな製造業の通説を鵜呑みにすると落とし穴にはまる可能がある

※以上：日経ビジネス2013年4月1日号「海外ソフトなら安く作れる」の嘘からの抜粋

私が、これまで説明してきた内容を端的に表現しています。最初から、この記事を紹介した方が良かったかもしれません。

弊社が、国内でシステム開発を行っていると言う事実もありますし、私自身が【オフショア開発】で心配したと言う苦い過去もありますが、やはり【オフショア開発】を行うには、リスクが高すぎると思います。

特に、中小企業が直接【オフショア開発】を行うのは止めた方が良いと思います。

ソフトウェア開発会社が【オフショア開発】で失敗している訳ですから、ソフトウェア開発の経験が無い企業が、直接【オフショア開発】を行うなど、もっての外だと思います。

但し、【オフショア開発】を行っても、唯一成功する可能性が高いケースとしては、国内に本拠地があるIT企業が、下請けとして【オフショア】企業を使っている場合は、大丈夫かもしれません。

この場合、あくまでも【オフショア】企業は下請けになる訳ですから、システムに不備があった場合の責任は国内企業になります。

但し、該当企業が、開発を【オフショア】で行うと明言していないケースもありますので、その点は、別途確認が必要です。

このケースであれば、【オフショア開発】のリスクは回避できますので大丈夫だと思いますが、それにしても開発契約だけは、しっかりとした内容にする必要はあります。

やはり【オフショア開発】は、成功すれば【費用対効果】は出ると思いますが、失敗の可能性が高いので、慎重に進めた方が良いと思います。

以上

【参考資料】
※まつもとゆきひろ氏：1993年にプログラミング言語「Ruby(ルビー)」を開発。1997年ネットワーク応用通信研究所に入所。現在フェロー職。

【株式会社 エム・システム】
本      社　 ：〒124-0023 東京都葛飾区東新小岩8-5-5 5F
 　 　 　 　 　 TEL : 03-5671-2360 / FAX : 03-5671-2361
盛岡事業所　 ：〒020-0022 岩手県盛岡市大通3-2-8 3F
 　 　 　 　 　 TEL : 019-656-1530 / FAX : 019-656-1531
E-mail　 　　： info@msystm.co.jp 
URL　　　　　： http://msystm.co.jp/
ブログ       ： http://d.hatena.ne.jp/msystem/ 
Facebook　 　： http://www.facebook.com/msysteminc