マイナビ開発チーム「NAL SOLUTIONS」便り～ベトナムのオフショア開発依頼の前に知っておくべきポイント～

この記事では、ベトナムでブリッジエンジニアとして5年以上の経験をもつNaoya Hanai氏の「ベトナムでのオフショアプロジェクトを開始する際に知っておくべき30の経験」をもとに、ベトナムのオフショア開発を活用するためのポイントを紹介します。

まずは、オフショア開発の失敗事例を見ていきましょう。

技術に関連する失敗

モバイル開発

• OSのバージョンを事前に確認していなかった
• Safariでのテストが行われていなかった
• iPhoneアプリのリリースに関する経験がなく、リリースが遅れた

セキュリティ

• メールサーバーのIDやパスワードが漏洩した
• テスト用データと誤認し、顧客データを削除した

ビデオストリーム

• 実績がない状態で請け負った

メール

• 設定が不十分で、開発したシステムから送信するメールが、スパム扱いされた

支払い機能

• 支払いシステムの利用申請が後手になり、リリースが遅れた

準委任契約に関連する失敗

ブリッジエンジニア

• コスト削減のためにブリッジエンジニアを利用しなかった。その結果、技術を理解しない者が翻訳するコミュニケーションとなり、かえってコミュニケーションコストがかかった
• ブリッジエンジニアが要求を正しく理解していなかった

テストケース不足による遅延

• テストケースがないためバグとその修正が多発し、次のタスクの進行が遅れた
• 必要なテスト項目が網羅されておらず、あとからさまざまなバグが発生した

プロジェクトの人員

• フロントエンドのみ対応可能な人員を、バックエンドエンジニアとしてアサインした
• 工数を40％かさ増ししていた
• 4ヶ月分の工数に対して、6ヶ月分の工数を請求していた
• 資料が準備されておらず、開発者が作業できなかった

コミュニケーション、文書、スケジュールに関連する失敗

文書

• 仕様や成果物が曖昧になっていた
• 契約書に記載がないため、開発に必要な文書を作成しなかった
• あとから仕様変更扱いとなり、追加費用が必要になった

スケジュール

• 進捗を重視していなかった
• スケジュールの認識が異なっていた（発注側：完了日＝サービスのリリース日、開発側：完了日＝テスト前の開発完了日と認識していた）

デザイナー

• 日本とベトナムのデザインセンスの違いから、イメージのすり合わせが難しかった
• デザイナーのスキルが不足していた

コミュニケーション

• 口頭でのコミュニケーションが中心で、文書化されていなかった
• 報連相が徹底されていなかった

上記のような失敗を避けるため、マイナビの開発子会社であるNAL SOLUTIONSでは、ITサービス＆ソリューション業界で9年以上、75以上のパートナーと250以上のプロジェクトを手がけた実績をもとに、オフショアフレームワーク・コード品質・セキュリティの観点で対策を実施しています。

オフショアフレームワーク

開発プロジェクトの共通のフレームワークを構築し、開発プロセスの統一や標準化（文書、コミュニケーション、レポート、ミーティング、顧客管理プロセスなど）を推進しています。

コード品質

CTOや技術リーダーの指示に基づいて、コード品質を担保するための原則ルールを策定しています。

セキュリティ

開発プロジェクトごとにセキュリティチェックリストを作成し、メンバー内で定期的に確認しています。

この記事の内容が、貴社のオフショア開発活用に役立つことを願っています。