こんにちは、オフショア開発で多くのプロジェクトを進行して感じた
オフショア開発で失敗しないための方法についてまとめてみました。
自分の失敗を他の人がしないように。。
まずオフショア開発の説明です。
オフショア開発とは？
オフショア開発とは、情報システムやソフトウェアの開発業務を海外の事業者や海外子会社に委託・発注すること。営業や企画、設計、納品、サポートなど顧客に近い業務は本国で、実装やテストなどを海外で行なうといった形で分業することが多い。
引用：IT用語辞典
つまりオフショア開発とは、”物理的に別の場所”で開発をし、立地の物価差を活かし、”安く”開発をする手法のことを意味します。
日本では、物価の安い東南アジア(ベトナムやカンボジア)などに開発を依頼することが多いです。
ただし、近年では各国の発展に伴い、物価が上がっており、十分に吟味しないと、金額的なメリットを受けることが難しく、結局高くついた、というのはよくある話です。
・オフショア開発の相場
国やスキルによって差はかなり大きいですが、ベトナムのオフショア開発の場合、
人月単価20〜40万程度が多いです。
東京の一定規模以上の企業であれば、人月80万以上は発生するため、コスト的なメリットが十分にあります。
ただし、上述した通り、各国の発展に伴い相場は日々変わっており、定期的に各国の物価や、
経済状況をウォッチしてオフショア先を選ぶことが重要になります。
・オフショア開発の流れ
オフショアと一言に行っても多様にありますが、主なオフショア開発の方法は以下の2つがあります。
完全な遠隔コミュニケーション)
1つ目は、海外拠点のオフショアを提供している企業とSkypeなどを使い遠隔でコミュニケーションを行う方法です。
発注から契約まで基本的にメールベースで行い、開発もコミュニケーションツール/タスク管理ツールを用い、行います。
多くのオフショアを展開している企業には”ブリッジエンジニア”と言われるコミュニケーションの橋渡し(通訳と近いが正確には違う。後述)をする人格がいるため、英語が堪能でなくても基本的なコミュニケーションは可能になっています。
開発体制としては、いかになります。
発注した日本の企業のIT担当←–(skype/チャット)–→ブリッジエンジニア↔︎現地のエンジニア
ただし、この体制は物理的な距離があり、またブリッジエンジニアといっても国が違うため、細かなニュアンスを完璧には伝えられません。
結果多くのコミュニケーションロスが発生し、管理コスト非常にかかります。
熟練した進行能力がないと、計画通りに開発をすることが非常に難しいです。
現地に赴き、一緒にコミュニケーション)
2つ目は海外拠点のオフショアを提供している企業に発注側の企業のIT担当者が直接向かい、現地のエンジニアとコミュニケーションをとる方法です。
開発体制としては、いかになります。
発注した日本の企業のIT担当←–(FaceToFace)–→ブリッジエンジニア、現地のエンジニア
この方法1つ目と違い、物理的な距離がなく、現地エンジニアの顔も見れ、コミュニケーションを取れるため、
プロジェクトの成功率は格段に上がります。
可能であればこれがベストな方法です。
しかし、物理的にこれを実現することができる企業は少ないです。
なぜなら、
・発注企業のIT担当は複数の業務を掛け持ちしており、長期で海外に駐在することが難しい
・企業のIT担当自身の慣れない土地での精神的な負荷
があるからです。
オフショア開発のベストプラクティス
そのため、今回は上記の課題を解決できる、自分なりのオフショアの開発ベストプラクティスを提示したいと思います。
ベストプラクティスとは”コミュニケーションの高頻度化/超効率化”です。
上述もしましたが、オフショア開発の最大の課題は”コミュニケーション”です。
仕様を伝えたけど違うものができていた、というのが必ず発生します。(実体験ではほぼ100%。。)
そのため、十分すぎるほどわかりやすく、高頻度でコミュニケーション(意思疎通)をとる必要があります。
■解決策1：毎日始業時、就業後の提携フォーマットでの報告
毎日、必ず提携フォーマットで報告するようにルールづけます。
さらに認識ずれがないように、具体的な機能/仕様ベースで進捗頻度を共有してもらいます。
発注側のIT担当者にもし開発スキルがある場合は、ソースコードも毎日必ずチェックようにするとロスが減ります。
■解決策2：仕様は可能な限り図解し、プロトタイプツールで伝える
よくある形式でexcel形式で仕様書を展開しているプロジェクトがありますが、あれは非常に非効率です。
日本人の感覚で書いた仕様書は海外の人からすると非常に難解です。
仕様の伝達は基本的に以下をメインとすると効果的です。
・プロトタイプツールを用いる。
adobeXD、Prottoなどプロトタイピングツールを使い、伝達をします。
■解決策3：ロジックはマトリックスでアウトプットを明確に提示
細かなロジック・内部処理などがある場合でも、可能な限り図解します。
もっとも効果的な方法が”マトリックス”です。
縦横にマトリックスで条件を記載し、セル内に期待値を記載することがオススメです。
■解決策4：重要なタイミングでは現地に赴く
常駐は難しい場合でも、プロジェクト開始時、重要な開発の場面では現地に赴くことは必要です。
実体験ベースですが、現地に赴くことでプロジェクト全体に結束力が高まり、いざという時に助け合いができます。
遠くにいるからこそ、結束力を高めることが重要になっています。
■解決策5：できている”だろう”ではなく、できていない”だろう”で進める。
車の運転と一緒で、”だろう”運転は危険です。
伝わった”だろう”、理解している”だろう”、大丈夫”だろう”。。
オフショア以外にも当てはまりますが、失敗の素です。
信頼して任せることは必要ですが、甘く見積もると想定以上の狂いが生じます。
できていない”だろう”ぐらいの気持ちで進めなければ、成功は難しいと思います。
■解決策6：成果物の確認は、段階的に分ける
成果物の確認は段階的に分けることが効果的です。
1回目は大枠の意志が伝わっているか確認。(大きな軌道修正が必要な場合はこの時に検知)
2回目は機能の仕様が伝わっているか確認。(機能の用途、仕様はだいたい伝わり切っていなめ、再度伝達)
3回目になって、やっとエラー系や異常系などの普通の検証を実施するようにします。
なぜこのようなことをするかというと、やはりコミュニケーションロスの早期検知です。
可能な限りロスをさせないことが大事です。
■解決策7：自分たちの気持ちを伝え感謝を伝える。
上記で、国が違う、疑え、など色々書きましたがやっぱり相手も人間です。
開発にかける思い、その目的を伝えること、日々の仕事に感謝すること、それが一番大事だと思います。
ただ目の前の作業をさせるのではなく、同じ目線で全員が開発することが大事です。
以上、自分の実体験をもとにつらつら書きました。
ご参考になればと思います。