オフショア職人の朝は早い。
「まあ好きで始めた仕事ですから」職人はそう答えながらも素早い手付きで捌いていく。
「このショア感がね、普通は出せない」 「ああ、そのオフショアは駄目だよ。ほらぜんぜんショアショアしない」と職人は言う。
彼くらいになると、見ただけで良し悪しがわかるのだそうだ。問題は後継者探しだと職人は寂しそうに言う。
「いや、僕は続けますよ。
――――こんな僕でも待ってくれている人がいますから」
さて、茶番はこれくらいにして、開発チームのテクニカルディレクターのキー坊です！ 茶番でも少し触れましたが（触れたといえるかはさておき）、今回の話題はオフショア開発です！
「オフショア開発」って聞くと、コスト削減や人材確保の容易さといった大きなメリットがあると思います。でも「うちでもやろう！」みたいな軽い気持ちで乗り出すと簡単に失敗しちゃいます。
この記事では、オフショア開発で起こりがちな課題を主軸に弊社開発チームの取り組みについてご紹介させていただきます。
目次
オフショア開発の課題
ここではオフショア開発における課題を挙げていきます。よくいわれる課題ではありますが、それだけ解決も難しいことが多いです。
言語の壁
言わずもがなですが、オフショア開発をするには「英語力」が必要になります。さらにはシステム開発をお願いするのですから、エンジニアリングにも長けていないと、現地の開発メンバーと正しくコミュニケーションをとるのはかなり難しいでしょう。
そこで、オフショア開発のために「英語も開発もできる国内の人材が欲しい」と考える方が非常に多いんじゃないかと思います。
しかしオフショアの大きなメリットのひとつは「コスト削減」。そのコスト削減を行うために人材の確保が必要となれば本末転倒で、なかなかオフショア開発に参入できない方もいらっしゃると思います。
また、オフショア開発では現地の「ブリッジSE」や「コミュニケーター（トランスレーター）」などとコミュニケーションを取ることも多いと思いますが、彼らが日本人でない場合もあります。
そうすると、納品されてきた仕様書やマニュアルの「てにをは」がおかしくて使いものにならない！ というようなことが出てきたりします。そんな言語に関する失敗事例がWeb等で多く公開されているので、オフショア参入しようとするとすごく不安だと感じるのです。
文化の壁
文化と一口に言ってもピンとこないですが、まず日本と海外には時差があります。それと、当然ですが祝日が違います。
「なにを当たり前なことを」と思うかもしれませんが、日本で始業しても、向こうが始業しているとは限らないんです。「明日の朝一で確認とれば、午後の会議に使う資料作りには間に合うな」なんて考えは通用しません。つねに時間がズレていることを意識して、どういうことに波及していくのかを考えていく必要があります。
最近は日本でも働き方改革で長時間労働を是正しようという動きもあります。しかし、ITの世界ではまだまだ「納期がすべて」という価値観が強くあって、睡眠時間を削ってでも納品するということもあると思います。しかし、海外ではこのような価値観はまったく通用しません。
このように、根付いている考え方がそもそも違うので、思ったとおりに仕事が進まないということがしばしばあります。
仕様の理解
これは「言語の壁」とも絡むのですが、システム開発のなかで処理方法について以下のような仕様を決めたとします。
「AがBを処理する」
これが、ブリッジSE不在のオフショア開発で、コミュニケーターも外国人で日本語もそこそこ話せるというレベルですと……
「AをBが処理する」
などと翻訳されてしまって、まったく違うものができてしまうこともあるのです。
ブリッジSEがいれば、前後の流れからおかしいと気づくこともできたりします。しかしコミュニケーターは非ITの人材でシステムエンジニアリングには長けていないこともあるので、このようなことが起こってしまいます。
また、実際にプログラムを行うエンジニアもおかしいと気づくかもしれませんが、それを指摘するかどうかは別問題だといえます。なにせ彼らの仕事は「依頼を叶えること」なので、「依頼が間違っていることを指摘すること」は彼らの仕事の範疇にはありません。
つまり、日本語と英語、それからシステムエンジニアリングに通じていないと仕様を落とし込むことができず、正しい納品物が制作されないということです。
これを解決するのがLIGのシステム開発の仕組み
いや、こう言われると魔法のように聞こえるかもしれませんね。
一口に言うと、「クライアントとLIG、LIGフィリピンのメンバーを一つのチームとしてシステム開発に取り組む」ということです。
日本とフィリピンでは画像のような役割で分かれています。チームですので役割分担はあれど、同じ視点で働いています。
なので、エンジニアから仕様について「これあってる？」って言われたりもします。いや、僕がうっかりしてたところとかをフォローしてくれてホント優秀で助かっていますｗ
（おっと、僕が間違った仕様を出しちゃったことは内緒にしておいてください）
LIGのシステム開発の強みについては、以下で記事にしてくれていますので、そちらもご覧ください！
“DX with Global Team” LIGのシステム開発の強み
Noriaki Iwata
では、実際に上記の課題への取り組みをご紹介していきたいと思います。
なぜLIGのシステム開発ならうまくいくのか
上述したように、僕らはチームとして稼働しています。受託のような仕様に沿った開発がゴールではなく、クライアントに満足してもらうために「システム開発」という手段を取っている感じです。
なので、「仕様の理解」のところでご紹介したような、依頼が間違っていることが指摘されないということがそもそもありません。誰もが「間違っている」と口にできるので、僕のようなうっかりをやらかしても皆がフォローしてくれます。
日本のテクニカルディレクターがクライアントとエンジニアの窓口に立つ
オフショア開発の難しいところは、英語とエンジニアリングがそもそもできないとオフショア開発のスタートラインに立てないことです。
しかし、LIGのシステム開発であれば課題の分析や、要件定義、仕様書の作成など、いわゆる開発における上流工程と、クライアントの窓口全般にテクニカルディレクター（以下TD）が立ちます。
また、現地にも日本人のブリッジエンジニアや、コミュニケーター、ディレクター等がいるため、何らかの理由で直接エンジニアとやり取りする必要があったとしてもフォローに入ってくれます。英語ができない僕もコミュニケーターには足を向けて寝られません。
ということで、「言語の壁」による課題は解決です！
そして、「確認したいことがあって連絡したら、現地は祝日で1日連絡待ちでした」とか、オフショア開発ならあるあるだと思うんですが、LIGのシステム開発はクライアント窓口が日本なので基本的にこういうことが起こりません。つまり「文化の壁」もクリアですね。
時差もフィリピンは1時間しかないので、ほとんど意識することはありません。
LIGが管理してコミュニケーションミスを少なくする
プロジェクトにおけるすべてのタスクは「Asana」というツールを使って管理するので、エンジニアたちは事前に納期がわかります。なので、それに向けて邁進しますし、難しい場合は「なぜそれが難しいのか」という報告と相談が入ってきます。
それを受けてTDはどうするかを考えて、取れる手段があれば実施しますし、優先度的に低いものであればクライアントに連絡して調整を行ったりします。
また、開発フローの要所要所でTDのレビューが入るため、TDとエンジニアの「仕様の理解」にギャップがあっても早期に気づいて指摘できます。
つまり、クライアント目線で見ると……
- クライアントはTDと日本語でコミュケーションが取れる
- オフショア開発で失敗しがちなところをLIGが勝手にやってくれる
え、なにこれ。メッチャ良いですやん。
手前味噌だけど、メッチャ良いですやん（大事なことなので2回言いました）。
まとめ
僕のふだんやっている仕事と一般的にいわれる「オフショア開発の課題」を照らしてみると、なぜLIGのシステム開発がうまくいくのか、なんとなくわかってもらえたかなと思います。
いまから同じようなことをはじめようとしても、相当のお金と時間がかかると思います。まず海外に信頼できるパートナー企業を見つけたりするところからはじめて、日本と海外とのメンバーがチームとして働けるところまで持っていかなければならないことを考えると、大変なのは明らかですよね。
クライアントから見て、これらを手っ取り早くすっ飛ばしてオフショアの美味しいところだけ味わえるのがLIGのシステム開発だと思います。
さらに、僕の担当している仕事とは縁遠いのでこの記事では触れませんでしたが、オフショア開発にはほかにも法務や労務、財務など字面を見ただけで気が重くなる問題が山盛りあります。
正直これらを請け負ってくれる企業があるなら頼った方が良くない？ て考えますよね。もしLIGのシステム開発でどんなことができるのかご興味がありましたら、お気軽にご連絡ください！
