オフショア開発で言葉の壁は大した問題じゃない話

東ヨーロッパ バルカン半島のマケドニア共和国から東京にやってきたソフトウェア開発のWeb Factory MK 東京オフィスのシンゴです。どうぞご贔屓に。

海外開発拠点。早い話オフショア開発でプロジェクトを視野に入れる際、まず気になるのは言葉。時差。文化はどうだ、コストはどうだ、技術力はなど色々考えることが多いと思います。今日は言葉の壁とコミュニケーション体制について書いてみます。

例えばですが、貴方は日本側でwebアプリのサービスを構築するPM、そして社内リソースに追加して日本のアウトソースも使っていたが開発費高騰で腕の良いフルスタックエンジニアが月額150万円のおり、それでも見つかれば良いなんて言ってもいられない。オフショア開発拠点のオプションも検討して品質もコストも最適にする必要が出てきました。アジャイルで開発しているので柔軟性も必要。

どうするか。
まずはGoogleでオフショア開発でサーチ。ベトナム、ミャンマー、インド、バングラデッシュ、パキスタンなどなど、”日本と比較してXX%安い” ”技術力が高い” ”実績あり”など耳障りが良いキーワードでたくさん出てきます。 いくつかみていくと”日本語で対応” ”日本語対応のブリッジSE”が目に留まってそこにコンタクト。営業さんがやってきて概要話してスキルレベル等々要望出して見積もりがきます。
一番安いパキスタンの会社からはなんとフルスタックエンジニアが月額40万円、日本語ができるし日本に配置可能なブリッジSEが月額70万円でした。スキルシート見る限り、インタビューしたところ、まっ、これで行きましょう。オフショア側にはエンジニアをまとめるためのシニアエンジニアをアサインしますと言われて安心。

ここから少しドラマ展開ですがお読みいただければと思います。

プロジェクト開始。
アジャイル開発と称して仕様要求や設計書がゆるいまま来てしまい、ウォーターフォールが体に染み付いているので「指示待ち」が増え、そこに仕様変更が入りどんどん工程を圧迫していくうちに品質と開発の同時進行のウォーターフォールのような要求が顧客から来てしまう。

挽回を図るべくオフショア拠点のリーダ、ブリッジSEと社内チームのスクラムリーダー集めて工程の割り振りを行うが現実的じゃ無い見積もりでチームメンバーは不満だらけ。オフショア側から上がってくる機能実装は細かい期待値のずれも多い。そう、こうなると立場が強い、弱いがチーム内にできてしまいます。
アジャイルと言う免罪符の元、オフショアチーム担当の機能開発・実装とテストの工程はそもそも仕様が曖昧のままきてしまったので仕様変更・追加しながら工程短縮も機能実装でバグゼロの要求は後出しジャンケン状態。日本側から見るとなぜ要求通りにリリースして品質が保てない。なんならデグラじゃないか、と不満続出。いやいや話が違うよ、その矛先はブリッジSEに集中します。なぜなら「日本語が喋れる」と「オフショア側の言葉が喋れる」という理由で全てが集中してしまうからです。

ブリッジSEは全体プロジェクトの把握、機能や実装工程や品質期待値のすり合わせが曖昧、統合テストなどについては必要なレベルでブリーフィングすらされていないのに工程が圧迫されてプレッシャー与えられる。ついでにオフショア側はシニアのエンジニアがいたのは最初の数週間だけでメンバー入れ替わって取りまとめもナレッジ共有もイマイチ。こんな状況で大体起きるのはオフショア側もブリッジSEに集中砲火。

ちょっと最悪ケースを装飾して描写し過ぎと思われたそこの貴方様、実は結構ある話でして、なんなら日本の会社同士でも同じ事が起こるのを何度か見てきました。
ソフトウェアをオフショア拠点にアウトソーシングする際の言葉の壁はもちろんあります。ですが、明確な設計書、仕様書 (アジャイルでドキュメントは要らないって言った奴出てこい）、プロジェクトの初期段階でアウトソース側にプロジェクト全体のブリーフィング、設計書と仕様書に対してアウトソース側から”もういいよ”と思うぐらいの質問をさせて疑問点や可変要素のすり合わせをする事で上記のようなリスクをかなり低減できます。

では言葉の壁はどうするの？ですが、正直誰も知らない素晴らしい方法なんて無いのです。オフショア側が英語なら、日本側も英語でコミュニケーションをするのです。もちろん誰も完璧な英語なんてしゃべらなくてよくて、重要なのは共通の認識合わせをするためのドキュメント、そしてそれの共同での確認作業に必要な時間を充てる事です。コードレビューなん会話の９割お互いカタコト英語でできると思います。コードは万国共通ですから。

また、オフショア拠点と日本側のコミュニケーション体制はいろんなやり方あれど私が知る良き方法はブリッジSEを入れずにオフショア側に優れたPMを置いて窓口(シングルコンタクト)にするやり方。それも、アジャイルプロジェクトならアジャイルプロジェクトで経験値のあるPMで、オフショア側のマネジメントはオフショア側のPMに”任せる”のです。日本側のPMは製品・サービスローンチに向けて多くのタスク処理 (ビジネスタスクも含めて)が必要となるので少し極端に言うと日本側はプロダクト・サービスマネジメントに集中できる体制で良いと思います。
もちろん透明性をキープするためにオフショア側のエンジニアと日本のチームメンバーが話するのは全く問題は無いです。　マネージャーの皆様は組織マネジメントがどれだけ時間と工程がかかるか、はご存知とは思いますがそれをリモートで国境を超えてやるのは正直厳しいと思います。そこに時間をかけず、チームマネジメント含めてアウトソースして良いのです。デリゲーションの練習です。

もう一つ。オフショア側のメンバーはとにかく交代を避けましょう。いや、なんなら要望しましょう。最初だけシニアメンバー入れて立ち上がったらそのシニアメンバーが入れ替わるのは実はよくある話で (できる人がそんな揃う組織なんて。。。。。あればいいけど)、でもそれをやられると学習カーブも生産性も柔軟性も全て一旦リセットされます。業務の引き継ぎがどれだけ大変かは皆様ご承知の通りです。

アジアの開発拠点、東ヨーロッパの開発拠点と開発を行う場合 ”日本語対応ブリッジSE”の誘惑に簡単に乗ってはいけません。そうなんです。プロジェクト体制やプロセスはインハウスであってもアウトソース (日本 or 海外)であっても変わら無いのです。そして、誤解を最小限にする最適なツールはしっかりした共通のドキュメントがあれば言葉はお互いカタコトの英語で良いのです。

現場からは以上です。