こんにちは、Tetoatomです。
私の経験として、はっきり言って成功していないと思いますので、今後このようなことがないように頭の片隅にでもおいていただきたいと思います。
オフショア開発とは
ソフトウェア業界において簡単にいうと、海外の事業者や子会社にソフトウェアの一部などを委託することを言います。 最大のメリットは、日本人よりも人件費が安いため、大量の人材を確保することができることです。
しかし、自身の経験、また周りの経験者の情報から、とても成功したとは言いがたい状況であります。 それでは、具体的に何が問題なのでしょうか。
言葉の壁
まず、一番は言葉の壁です。
多くの場合、オフショア先の企業（海外事業者または子会社）側は英語によるコミュニケーションをメインとする場合が多いと思います。
これははっきり言って当然のことでしょう。
中国やインド、またその他の国の企業でも英語を主体としています。
これは、オフショア先に問題があることではありません。 むしろ、中国語やインドの言語（ヒンディー語？）で話さずに、自国の公用語ではない場合でも、ほぼ世界共通語である英語を習得し日本の企業に対しているのです。
それに対して、日本側は日常会話に加えて、ソフトウェア業界の場合、技術的な英単語なども存在します。 そのようなことについてあまり知識のない技術者が少なくないとは思います。
それにより、適切にオフショア先に仕様について説明することができず、次や次の次のフェーズで認識齟齬があらわになって、問題となるのです。
しかし、これは日本側に問題があるとも私は思いません。 言葉の壁は徐々に埋まります。最近では優秀な翻訳ツールも存在しますし、これらの会話を必ず記録することで、後に間違いに気づいた時に適切に指摘することができます。
そのため、言葉の壁が心配な場合は、チケット駆動モデルは最適と考えます。 仕様書にはすべての情報が記載されていない場合が少なからず、あると私は思います。 （もちろん書いてあることがベストですが、いろいろとあるのですよ。。）
しかし、チケット駆動モデルの場合、簡単な疑問もチケット化しそれが解決することで次のフェーズに進むことができます。 立ち話などがすべて記録されているようなイメージです。
もちろん、オフショアにかぎらず効果的な方法ですが、私は言葉ひとつひとつがより重要なオフショア開発ではさらに効果を発揮すると思います。 巨大なプロジェクトの場合は、ウォータフォールとチケット駆動モデルとを組み合わせて開発を進めていくことが重要でしょう。
作業工程の分担
これは私とその周りの経験上なので、その他の例も存在すると思いますが、私の経験の話をします。
以下のような工程があるとします。
- 要求仕様 システムやプロジェクトで必要な機能の要求をまとめたものです。 この段階ではまだ、具体的な関数名や機能名は登場しません。 どのようなことが出来れば良いのか、できなくて良いのかを表現します。
- 基本仕様 要求仕様から一つブレイクダウンして、要求機能についてどのように実装で実現していくかをまとめたものです。 具体的な機能名による機能分担や外部に公開する関数I/Fを記載する場合もあります。 なお、要求仕様と基本仕様を決めることを外部設計といいます。これだけではプログラムは作れませんが、プログラムを作る人ではなく要求機能実現のための妥当性を判断するために必要な情報でもあります。
- 詳細仕様 基本仕様をさらにブレイクダウンし、プログラムを作成するために必要な情報を記載します。 リソースについてやシーケンスについて、またフローチャートなどで表現する場合もあります。 この詳細仕様を決めることを内部設計と言います。内部設計によりプログラムの作り方、また単体試験の妥当性確認を行うこともできます。
- プログラミング 詳細設計書を元にソースコードを作成します。
- 単体試験 関数レベルや機能レベルの試験を実施します。
- 結合試験 システムやプロジェクト全体としての試験を実施します。
これらの工程がある中で、オフショア先には詳細仕様以降を担当させます。 要求仕様と機能仕様は日本側で実施します。
日本側の作業としては特に問題なく進みます。（もちろん仕様策定ための問題は山ほどあるでしょう） そして、日本側がおこなう基本仕様をオフショア先にインプットします。 そして、日本側は待つだけです。
と、いきたいところですがここからが日本側が大変な工程に突入するのです！！！
品質管理などの関係や、物理的な作業場所の違いから、オフショア先にはリアルタイムの情報を渡せない場合が多くあります。 その場合、日本側がほぼ詳細仕様と同等な情報を作成して、オフショア先にインプットすることになります。
また、上記の理由のため、タイムラグもあり、質問に対する回答から成果物の修正がかなり遅くなります。
日本側はただひたすら待たなければなりません。 また、当然時間は進みますので、状況や仕様が代わりまた新たな情報をオフショア先にインプットしますが、タイムラグから以前の情報と新しい情報が混ざり、混乱することとなります。
ここで、日本側はオフショア先の技術力を疑うような錯覚に陥ります。 日本側は情報が膨大にあり、必要な情報はリアルタイムで入ってきます。 しかし、それを理解しないオフショア先。。
これは単純にタイムラグなのです。 実際、オフショア先はかなり優秀な人材が揃っています。情報の理解は非常に早いです。
問題はオフショア先の技術力不足という濡れ衣にしてしまうのです。。。
担当機能を完全に任せることはできないのか？
結局日本側は少なくない工数をかけて、オフショア先の対応を行います。 詳細設計からはオフショア先なのですから、日本側はらくできないのでしょうか。。。
楽をする方法はあります。 機能仕様書を完璧なものにすることです。
オフショア先は本当に伝えたことに関しては必ず実施します。 言ったこと、書かれたことは必ず成果物となりますが、言わないこと、想像力が必要なことについては全く触れません。 しかし、これは経験の問題でしょう。
自分も新人の頃は書いてあることや上司の指示どおりにしか動けませんでした。
オフショア自体も成長中でしょうから、徐々に解決されていくことを期待します。
それでは、何が問題なのか？
私が思うオフショア開発における問題は、「日本側はオフショア先企業を舐めている」ことではないかと思います。 先にも書いたように、海外の技術者も非常に優秀です。理解も早いです。 もちろん、経験が浅い場合もありますが、すでに数プロジェクト経験しているような技術者に関しては、日本人と同等以上に信頼して良いと考えます。
その為、「外部設計からオフショア先には担当させる」ことが重要になると思っています。
外部設計と内部設計の境目で担当者を変えるという事自体は日本人でもだいぶハードルが高いことです。 要求仕様と基本仕様は担当者がちがう場合もあります。 やはり、外部と内部の境目は重要な遷移するフェーズなので、同一担当者が自分の目で見たほうがよいと思います。
詳細仕様からコーディング、プログラミングは増員して担当者を増やすなんてこともあると思います。 だからどっちかでしょう。
基本仕様からやらせるか、コーディングや単体試験以降からやらせるかです。 私の中での結論は基本仕様から実施可能だと思います。
でも、でも、でも、、
しかし、品質管理やセキュリティ、技術輸出などの観点から、このような担当分けになってしまう場合もあるかと思います。 もう少し、オフショア先企業を内部に取り込んで親密にすることで、このあたりの問題も解決されればなぁと思っています。
まあ、結局のところ、日本人が語学にしろ設計能力にしろ成長しなければならないとは感じています。。。 あっという間においこされますよ！！！