ＩＴ業界においてオフショアの大半が失敗する理由
「うちは成功したよ！」と言う声が聞こえてきそうですが、えぇもちろん成功例も知っています。ただ、成功した現場って
・「大きな」問題は起きなかった（小さなものはいっぱいあった）
・コミュニケーション抜群のスタッフがいた
とかそんな感じのことが多い気がします。
そして私がいう大半の失敗は「コトバ」の壁を、日本人が理解していないがために起こしているものを指しています。裏を返せば、この「コトバ」の壁を何らかの形で取り除けていれば成功率はグッと上がるとは思っています。
私も昔いた会社で、海外に子会社を作ったためにそこに開発プロセスの浸透を目的とした技術講師として３～４か月ほど出張していたことがあります。ちょうどどの大手SIerも「オフショア！オフショア！」とお祭り騒ぎになっていた頃です。
しかし私の知る限り、少なくとも私の周りではオフショア開発でまともに成功した事例をあまり知りません。トラブルにならずに終わったプロジェクトならいくつかは知っていすがそれはトラブルにならなかったと言うだけで、設計通りになっていないことはもちろん、プログラムの中身は目も当てられない作りになっていたり、進行過程でバグだらけだったせいか完了時点ではつぎはぎだらけでとても新規開発とは思えない形になっていたり。
プログラム（プロダクト）のライフサイクルは納品した後からであって、その後のビジネスモデルの変化に応じた改修・改造や再構築(リプレース)を考えると、保守性や移植性、再利用性の乏しい作りになっている時点で、本気で「成功」と呼べるものはまず０（ゼロ）だったと言っても過言ではないでしょう。
…１件だけ「前回、同じ規模で成功した」という実績を携えて入札に加わってきた大手SIerというのを知っていますが、結果としてその大手SIerが結局受注できましたけど、結果は惨憺たるありさまで大トラブルを起こしていました。
そのSIerはおよそ半年遅れでとりあえず納品まではこぎつけたようですが、その後はさすがにお客さまからの信用も失って任されることはなく、私のいた会社でも一部引き取りましたが中身を見たらビックリ、
・新人の平均値より酷いプログラム構造
・実装後に作成したと言われている設計書がプログラム内容と一致しない
・と言うか、設計書だけ見て「何作れというの？」と言うレベル
これを解析して保守とか、改造とかしてほしいと言われても…って内容でした。たった数年前の話です。
そして、冒頭の記事にあるように、その多くの失敗している理由はオフショア先にあるのではなく
日本人エンジニアが、オフショア先に対する理解が乏しい
と言うことが原因だと私も考えています。そもそもオフショア…つまりは海外に目を向けた時点で、日本語を（忖度も含めて）理解してくれていると勘違いしている時点で、オフショアの半分は失敗です。
マネージャーが理解していても仕様書や設計書等を作成しているエンジニア一人ひとりが理解していなければ、オフショア先へ提供する中間成果物自体がオフショア特性に準拠していないので結局失敗確率は上昇します。
設計のやりとりやプログラムのインターフェース仕様において、その決定権は今までも説明してきましたように
「呼びだされる側」つまりは受け手
にあります。読み取れるもの（引数）は呼び出される側が判断できるもの、返せるもの（復帰値）は呼び出される側が用意できるものでなければ絶対に成立しないからです。
このあたりはたとえばC#やJava言語など、オブジェクト指向言語のinterfaceの概念を理解していれば常識と思える部分でしょう。特にオブジェクト指向言語だけに特化した話ではありませんが、ソフトウェア工学について調べるよりは楽だと思います。
こうした考え方はインターネットのプロトコルの概念でもそうですし、人間のコミュニケーションにおけるインターフェースでも同じことが言えます。
しかし、日本人エンジニアの多くはそのことを理解していません。
だから上位成果物作成者は下位成果物作成者のことなんて考えません。
自分の考えた設計を行い、自分が正しいと思う設計様式を正にして下位成果物作成者に引き渡します。渡された相手が、その内容を正しく読み取ることができるかどうかなんて考えもしないのです。でも、多くの日本人エンジニアは
「読めないヤツが悪い」
と考えているでしょう。何度も言うように、「インターフェース仕様を決定する権限があるのは『受け手』のはず」なのに、オフショアに限って言えば設計者…すなわち送り手に権限があり、それを読めないヤツが悪い、読めるようになれという発想になってしまうのです。
なぜ、このような考え方になってしまうのか？
おそらくは、古くから続いてきた多重下請け構造が原因なのでしょう。
「下請け」と言うと、ものすごく上下関係があるように錯覚しがちです。たしかに製造業の下請け構造はそう言う側面もあります。ですがＩＴ業界の場合、そもそも元請企業に開発能力はなく、下請け以降の企業が実質的なモノづくりをしている関係上、彼らの存在は必要不可欠なのです。
ですから、厳密には「下請け」ではなく、「ビジネスパートナー」なのです。
これは仕様書→設計書、基本設計→詳細設計、詳細設計→プログラミング、どのフェーズでも同じです。あくまで（技術力が不足していたり、あるいは人数が不足していたりと言った理由で）自分たちでできない部分を補ってもらっているにすぎません。その代わり元請企業は仕事を提供・斡旋したり、マネジメントの一部を引き取ったり、顧客企業との窓口を担当したりするわけです。
このことは『元請⇔一次請け』だけに限った話ではありません。『一次請け⇔二次請け』の関係でも同じことが言えます。もちろん、オフショアによって海外企業に委託する場合も同じです。
ですが、「下請け」という言葉が勝手に上下関係を連想させてしまいます。結果、対等なパートナーではなく、自分たちを格上、相手を格下に見ようとしてしまうのです。そう見てしまう心の贅肉がコミュニケーションにおいて、
送り手の都合でインターフェース仕様を決定したがる
といういびつな関係を生み出しているのでしょう。オフショアというと、古くは中国、インド、タイ、ベトナム、ミャンマー…と「とにかく人件費が安いところ、安いところ…」へとシフトしていますが、日本には
安かろう悪かろう
安物買いの銭失い
等といった言葉があるように、安いには安いなりの理由があります。今でこそ、古くからのオフショアによって多くの技術が流出し、中国市場では日本企業に出すのと変わらないくらい単価が高くなってしまいましたが、以前は「設計書に書かれたことは、書かれたとおりに実装する」ことしかしていませんでした。
「設計書に書かれたことは、書かれたとおりに実装する」
決して間違ったことはしていません。契約上もそういう契約なのでしょう。書かれていないことを勝手に実装していい理由なんてありません。
ですが、日本人であれば「行間を読む」「言葉から背景を読む」などを行い、設計上の誤りがあったら確認したり、指摘したりすることもあります…が、以前の中国オフショアでは「とにかく言われたとおりにやりさえすれば金はもらえるんだから、それ以上のことは絶対にしない」という姿勢が徹底されていました。
だから、動かないプログラムであっても、設計からそう読み取れるのであれば文句を言われる筋合いはないって企業も多かったように思います（今はどうか知りません）。
結局、日本に持ち帰って別の下請け企業に回し、一から作り直す…そしてスケジュールが間に合わずトラブル大炎上なんてプロジェクトはとても多かったのです。それだけで、年間何十、何百億のお金を無駄にしてきたのかわからないほどです。
とにもかくにも、そうした格上/格下という潜在的な心理のもと、オフショア先の国の文化、風土、言葉の壁、性格、etc.…何一つ理解しようとしないため、まずコミュニケーション面で認識齟齬が発生するわけです。
私は、外注（外部発注）は
何かしらの理由で自分たちに「できない」ことを、
他の会社（人）に依頼する
ものだと認識しています。
理由は「人がいないから」かもしれません。
「適切なスキルを持つ要員がいないから」かもしれません。
あるいは「安いから」かもしれません。
理由はそれぞれですが、「相手が格下だから」と考えたことは一度もありません。派遣契約でない限りはお互い法的に善管注意義務であったりやPM義務⇔協力義務は必ず求められますから、そこに発注/受注の関係があっても上下関係があるとは考えていません。あくまでビジネスをするうえでの対等なパートナーです。
お客さまの要件を満たすためのルールは守ってもらいますが、受注側が「発注側の要求する成果」を提供しやすくなるためにルールを作成するのも、それを適切に伝えるのも、そして理解してもらう努力をするのも、すべて発注側の責任だと思っています。
ですから、言葉の通じにくい海外の方を相手にする場合、
「どんな形で渡してほしい？
さすがに言語は変えられないし、大幅に様式も変更できないけど、
最大限要望には応えるよ？
絵がいるなら絵を挟むし、図がいるなら図を挟むよ」
とよく聞いていました。
受注側の責任は、契約を履行することと、そのために必要な条件を整えること、そしてその条件を整えるうえで不明点があれば速やかに発注側に確認することです。
それ以外のグレーな部分に対して「空気を読め」的なものを強制するのは、日本文化の悪い癖です。日本国内ではそれが通用するとしても、欧米やインド、他の多くのアジア地域では、ビジネスが成立しません。
今でも、受注するプロジェクトの背景などを聞くと、
「以前のベンダーが大トラブルを起こした」
「オフショアで失敗した」
と言うシステムの改造や改修、再構築をすると言う話を毎年聞きますが、その都度思います。
オフショアと委託は似て非なるものなんだよ。契約上は「委託」であっても、オフショアの特性を無視してただ押し付けるだけの契約で上手くいくわけがない。
オフショアの場合は、契約形態に関わらず「順調に進む」ための最大限の情報共有や教育は絶対必須に決まってる。文化や風土、言葉の細かい壁を無視した時点で無計画すぎる。最悪の場合、管理面の支援だって必要になる。
そもそも、そんなこともわからず「委託」を選択してる時点で自殺行為。
コミュニケーションか開発プロセス、どちらかに不安要素がある時点で「請負(=丸投げ)」はあり得ない。「請負」を選択せざるを得ないのであれば、それでも大丈夫と言える最大限の取組みを。そうでなければ「準委任」契約にして、善管注意義務を強化すればいいのに。
前のＩＴ業者はいい規模してて、何やってんだろう。
と。
まぁビジネスなんて、どれをとっても相互理解の努力を怠ればそれだけで失敗確率がグッと上昇するので自業自得と言ってしまえばそれまでなのですが。せめて、これからオフショアを始めようとする人たちはそんなエゴまみれの進め方をして、後悔するようなことが無ければいいなー…と思います。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。