オフショアがうまく行かない理由(1/2)　～海外進出ってどうよ8

みなさんは、ジュラシックパークという映画を見たことがあるでしょうか？

私的にはあの手のパニック系の映画はかなり好きな方でして、先日もTVでやってたのでついつい見入ってしまいました。

で、恐竜とかは今回どうでもいいのですが、その映画の中で私がずっと心に残っている言葉があります。

という言葉。

これは、先端の科学技術によって現代によみがえらせた恐竜たちが、パーク内で勝手に増殖しないように、研究者達がメスしか生まれないように遺伝子操作してあったのですが、ある生物学者がそれを見て、

と予言したものです。

で、実際それが的中するわけなんですが、これ、とても示唆に富んだ言葉です。

...この言葉は会社を経営しているとよく頭をよぎります。

会社とはまさに生き物で、様々な困難な環境を前にして、なんとか生き残る方法を模索しています。そこには必ずしも1つの正解がある訳ではなく、ただ死なないために必死で知恵を絞るというのが会社経営というものです。

あ、すみません、大上段から会社経営を語ってしまいましたが、場末の小さな会社の経営の話です。

今日はそんな"Life will find a way."なお話を絡めつつ、ベトナム訪問で改めて考えた、オフショア開発がうまくいかない理由とその打開策の一案などをまとめてみたいと思います。

------------

2000年代の初頭から、にわかに開発業界でにぎわっていた手法に「オフショア開発」というのがありました。ありましたというか今でもあるのですが、要するに、日本国内の高い人件費を避けて中国や東南アジアで開発を行ってより多くの利益を出していこうじゃないか、というスタイルです。

"岸を離れて"

などというのですから、これ和製英語でしょうね。

で、わたくし、基本的に『そんなのうまく行くものか』と思ってきました。

いや、日本国内で日本人を使ってもなかなかうまく回っていかないのに、なぜ海外でうまくできようか、ということで、ウチ的には選択肢的に無いわーと決めつけていたわけです。

ちょっとこのあたり真面目に考えてみます。

たとえば、楽天やmixiなど、自社サービスを展開している会社が開発をアウトソースして外注に任せようとすると、日本国内の業者であるとこんな感じになります。

ウチでもこのようなスタイルで開発を受けているのですが、登場プレーヤーがオール日本人でもかなり熱いものがあります。

何が熱いかというと、

この赤いあたりが熱いのです。

クライアント側でどこまで設計するかは会社によっていろいろですが、大抵は図のように仕様を策定するエンジニアというのが発注窓口に立って、開発業者のシステムエンジニアと協議しつつ仕様を確定します。

が、これがサービス策定の部門と微妙に温度差があったり、実装面から見て要求自体に無理があったり、業者に要件を伝え漏らしたり、逆に業者側が間違って捉えていたりで、仕様に齟齬(そご)が発生します。

これはどんな案件でも100％発生しまして、それを紙の仕様書なんかで防ごうとすると、ろくなものができないのはこれまで何度も言ってきた通りです。

それでアジャイル、、っていう流れもあるのですが、オフショアに開発を出すとなると、アジャイルは採りようがないので、今回そっちの議論は割愛します。

ただアジャイル開発はこの先の話でも引き合いに出てきますので、簡単に説明しておきますと、今ウチがやっているような、案件ごとに成果物を決めて見積りを書いて発注を頂き、社に持ち帰って開発する手法を「（持ち帰りの）受託開発」とするならば、案件ごとにお客さんのところに開発チームを送り込んで、納期や成果物は曖昧なまま作業の進捗や成果を確認しつつ次の指示を出してもらう手法が「アジャイル開発」です。

いや、定義はいろいろあって、これはアジャイルの中のスクラム開発だという人もいますし、うちでやってるのもアジャイルに極めて近いプロトタイプ開発だという人もいるでしょうが、本記事では、「アジャイル＝客先に開発チームを送り込む開発手法」としておきます。

ということで、海外で開発をするオフショアと、客先に開発者を送り込むアジャイルはかなり相反しているのです。

------------

で、オフショアの話です。

魅力的ですね。

ということで、先の受託の開発スタイルをオフショア開発になるとこうなります。

まず日本の開発会社のシステムエンジニアが要件を聞き、設計をして、海外のブリッジSEに投げます。

ブリッジSEというのは、大抵は現地のシステムエンジニアでありつつ日本語の出来る人がつくようです。(ちなみに図で、青と緑の寒色系が日本人、赤や橙の暖色系が外国人です)

すると、一目見て、二つの問題が分かると思います。

まずは、日本人システムエンジニアと外国人ブリッジSEの言語の壁、文化の壁の問題です。

まあ、ただこれは海外でやろうというのですからある程度予測している話ですが、もう一つあるのがSEが二人になってしまっている問題です。

国内の開発でも、1つのプロジェクトにSEが二名居るということがたまにあるのですが、同じ機能の設計に携わるのであれば、相当に設計思想的に合致してないとうまく行きません。

いわゆる『船頭多くして船山に上る』状態になるからです。

ということで、設計者を1人にしますと、こんな感じです。

少なくともお客さんのところには、誰かしら日本語が達者な人が行かなければいけないので、こんな感じで営業(セールスエンジニア)が出向くことになると思います。

このスタイルを採るとお客さんの仕様策定エンジニアは、日本人で、頻繁に顔を合わせ、人当たりが良く、サービス精神旺盛な営業に次々要望を言ってしまい、どうしても海外のブリッジSEとは情報伝達が希薄になります

そして、言った聞いてない誰に言ったんですか彼に言った私聞きましたっけの状態になって、まとまらなくなる可能性が高いです。

やはりこのようなオフショア開発の一番の問題は、開発でもっとも熱いお客さんと開発会社の接合部分で、余計なパーツが一つ多く挟まったり、管が細くなったりし、そこに言葉や文化の違いを含んだ精度の悪い情報が流れるところです。

9回失敗しても、、、というのは確かにそうなのかも知れませんが、だいたい4回失敗したくらいで仏よりも温厚な方でもキレます。

そもそもが、自社サービスをやっている会社というのはスピードが命ですから、安さを求めたので半年間失敗し続けてます、なんていうのを許してくれるはずがないのです。

（次回に続く）

島田 徹 2013/04/08 00:30:19 Comment(0)