
オフショア開発を成功させる4つの原則
「エンジニアの単価が高すぎる...」
毎月の開発費用に頭を抱えていませんか?今朝も新規開発案件の見積もりを見て、ため息をついたのではないでしょうか。
日本のエンジニアの単価は年々上昇を続け、今や東京では一人月70万円を超えることも珍しくありません。
このままでは新規案件を受注しても利益が出ない...。そんな悩みを抱えながら、オフショア開発という秘密兵器にたどり着いたのではないでしょうか。
ただし、この秘密兵器、使い方を間違えると大変なことになります。
私はベトナムのホーチミンのオフショア企業で2年働き、様々な案件でベトナム人エンジニアと働いてきました。
そしてジェットコースターのようにプロジェクトが上がったり下がったりする様子を間近で見てきたのです。
しかし本記事で紹介する4つさえ押さえれば、9割のプロジェクトは成功します。
今回は、涙と笑いの現場経験から得た失敗しないためのポイントをお伝えしていきます。
窓口は日本人同士にするまたは英語を使用
「日本語が話せるベトナム人がいるから大丈夫」
この言葉、まるでフラグのように開発の現場で突然立ちはじめます。私が担当していた某ECサイトのプロジェクトは、まさにこのフラグに引っかかってしまいました。
日本語が話せるベトナム人エンジニアのフォン(仮名)さんを窓口にしていたのです。最初は「おはようございます」「お疲れ様です」と、まるで丸の内で働いているかのような日本語力。しかし、システムの複雑な要件を説明する段階で、突如として悲劇が始まりました。
「カートの仕様についてはPOの動向を見ながら柔軟に対応できるようにしたいと思います」という日本側ベンダーの要件が、気づけば「カートは固定仕様で実装します」と180度違う解釈で進んでいたのです。まるでブラウザのオート変換機能のように、日本語が別の意味に変換されていました!
結果、1週間分の実装が水の泡に。この経験から、日本人を窓口にしているオフショア企業を選ぶか、お互いの担当者が英語でガッツリ会話できる体制を整えることをお勧めします。
要件を伝えるためという目的もありますが、やはりコミュニケーションがとれないと親密な関係構築は難しいですよね。
※ちなみに、フォンさんとは今でも良い友人です。彼は今、日本語の「頑張ります」を克服すべく奮闘中とのこと。
設計書の提出は求めない
日本の設計書って素晴らしいですよね。
美しいテーブル、使い分けられたMeiryo UIとtimes new roman、フォントや文字サイズ、インデントの微細な調整…まるで芸術作品のような美しさです。
でも、この芸術作品を求めてしまうと、オフショア開発では思わぬ落とし穴に転げ落ちることになります。
ある金融系システム開発。ベトナム人エンジニアのミン(仮名)さんが、日本式の設計書作成に挑戦しました。表のレイアウトを整えること2日、フォントの統一に1日、図の配置に3日...。まるでデザイナーになったかのような没頭っぷり。その情熱は素晴らしいのですが、実装開始が2週間遅れるという代償を払うことになってしまいました。
ウォーターフォール開発は避ける
ウォーターフォール開発とはその名前の通り、滝のように上から下へと流れていく開発手法です。
しかし、ベトナムでこの手法を採用すると、その滝は途中で干上がってしまうことが多々あります。
あるシステム開発で私は痛い目に遭いました。要件定義から設計、実装まで、すべて完璧な計画を立てました。
まるでレゴブロックのように、1から100まで順番に組み立てていく予定だったのです。
ところが開発が始まると、ベトナム人エンジニアたちの目が次第に泳ぎ始めました。
「次の工程はこうなるはずだから、ここはこう作る」という未来予測が苦手なのです。
結果、プロジェクトは予定の2倍の期間を要することに。まるで蛇のように、予定がどんどん長く伸びていってしまいました。
この経験から、私たちは開発を小さな単位に分割し、アジャイル開発に切り替えました。
すると、まるで目の前のごはんを食べるように、目の前のタスクに集中してもらえるようになったのです。
直接の顔合わせは必須
「オンラインミーティングで十分」
テクノロジーの進化した現代だからこそ、このトラップにハマりやすいですね。私も最初はこの感覚でした。
あるシステム開発で、私は日本から3ヶ月間オンラインだけでコミュニケーションを取っていました。チャットでは「はい、わかりました」と返事は良いものの、実装は遅々として進まない。まるで、その「はい」が「全力をつくしますが保証はできません」の暗号だったかのように思えるくらいです。
そこで私がホーチミンに行き食事会を開催しました。タイガービールを片手にエンジニアたちの本音が見えてきたのです。
「実は、このシステムの目的がそもそもわからなくて...」
「もっと明確にゴールを指定してほしい」
「制約は明確に箇条書きにして下さい!」
オンラインでは決して話せなかった本音が、ビールの泡と一緒に溢れ出てきました。
その後、毎月1回は必ず顔を合わせる機会を設けるようにしました。すると、まるで魔法をかけたかのように、チームの雰囲気が変わり始めたのです。

まとめ
オフショア開発、実は料理に似ています。材料(チームメンバー)が良くても、調理方法(開発手法)が間違っていれば、美味しい料理(良いプロダクト)は作れません。
私の経験では、これらのポイントを守ることで、9割のプロジェクトが成功しています。
小難しい言葉を使わず、同じ言語レベルで会話し、柔軟な開発スタイルを採用し、そして何より、実際に会って一緒にご飯を食べる。
シンプルですが、これが最強の成功メソッドなのです。さあ、あなたもオフショア開発の波に乗って、新しいステージへ進んでみませんか?きっと、想像以上の成果が待っているはずです。