オフショア企業、特にベトナムのオフショア企業との協業は、コスト削減や質の高い労働力の確保など、企業に多くのメリットをもたらします。しかし、こうしたメリットとともに、オフショア企業との協業は、注意深く慎重に行わなければ、多くのリスクも伴います。

この記事では、ベトナムのオフショア企業と協業する際の一般的な失敗から学んだ30の教訓をご紹介します。これらの教訓は、同様のミスを避けつつ、オフショアパートナーとの協業の効果を高めることを目的としています。

教訓1: 書類や仕様不足による不完全なオフショアプロジェクト

問題点：

ドキュメントや仕様不足: 事業において、機能の要件、システム設計、プロジェクトの実施過程を説明する詳細なドキュメントや仕様が不足しています。

成果物の説明不足: 各開発フェーズの成果物が明確に記述されていないため、何が完了していて、何が未完成であるかが不明確になっています。

解決策：

• 前のオフショア企業に連絡：前のオフショア企業と情報交換し、開発されたシステムについて情報を収集します。

• 仕様書の作成：収集した情報に基づき、事業が残りのプロジェクト部分に対する詳細な仕様書を作成します。

• 開発の継続：完成した仕様書に基づいてソフトウェアの開発を進めます。

教訓2：テストなしの納品 - 受け入れテスト後のバグ修正の却下

問題点：

不完全なテストケース： ハッピーパスのシナリオだけに焦点を当てると、異常な使用ケースでソフトウェアがエラーを起こしやすくなります。

未定義のOSバージョンサポート： サポートするオペレーティング・システム（OS）のバージョンを明確に定義していないため、デバイスによってはソフトウェアが不安定になります。

解決策：

• 包括的なテストケースの実装： ソフトウェアの品質を保証するために、複雑なシナリオや異常なシナリオなど、必要なテストケースをすべて含めます。

• サポートするOSバージョンを明確に定義すること： 一般的なOSバージョンを特定し、そのバージョンを使用するデバイスでソフトウェアをテストします。

• 適切なベンダーを選ぶ： リーズナブルなコスト、高い技術力、効果的なコミュニケーション能力を持つベンダーを探します。

• 一部の古いOSをサポートしないことを受け入れる： すべてのOSバージョンをサポートすることが不可能な場合、顧客に通知し、適切な解決策を提供します。

教訓3：セキュリティ情報漏洩の問題

問題点：

同社は、AWSメールサーバーのIDとパスワードが流出し、同社のネットワークセキュリティとデータに高いリスクをもたらすという深刻な事態に直面しますた。

解決策：

• IDとパスワードを変更します。

• Github、本番環境、ステージング環境、開発環境、AWS設定などのセキュリティ脆弱性を調査し、パッチを適用します。

教訓4：入力データの引き渡し拒否

問題点：

会社は、オフショア会社がリリース準備のために顧客がシステムに入力したデータを引き渡すことを拒否したとき、大きな問題に直面しました。オフショア会社が提示した理由は、修正したバグに対する追加の支払いを求めたためです。しかし、オフショア会社とサーバープロバイダーとの間で署名された契約のため、顧客はこの問題に直接介入することができませんでした。

解決策：

粘り強い交渉： 同社はオフショア会社と継続的に交渉し、データ引渡しの責任を説明し、契約を遵守するよう要請してきました。

教訓5：オフショア会社が3ヶ月の遅延の後、プロジェクトを完了できず

問題点：

オフショア企業は納期を守ることの重要性を認識しておらず、その結果、プロジェクト・タスクの実施に遅れが生じています。

解決策：

• プロジェクトの評価： 現在のプロジェクトの状況を詳細に評価し、完了したタスク、進行中のタスク、遅れているタスクを特定します。

• 代替案を探す 適切なオフショア会社を積極的に選択します。

• 効果的なコミュニケーション オフショア会社との効果的なコミュニケーションを維持し、毎週進捗会議を開き、スケジュールや発生する問題について話し合います。

教訓6：間違った技術選択によるコスト増加

問題点：

オフショア企業がバックオフィスシステムのプロジェクトにVue.jsを選択した場合、開発者がこの技術に精通していないため、修正や新機能が必要になるたびにコスト増につながるという問題に直面します。

解決策：

プロジェクトの要件と開発者の能力に見合った技術を選択する。クライアントが開発したいシステムに適した技術をアドバイスします。

教訓7：「完成日」の定義の違い

問題点：

クライアントは 「完了 」をサービスリリースの日と理解しているが、オフショア企業はテスト前の開発完了日と解釈している。この違いは、日本のクライアントが開発後のテストの必要性を認識していないため、プロジェクトのスケジュール遅延につながります。

解決策：

• ベトナムのソフトウェア開発プロセス（開発、テスト、リリース段階を含む）について、日本のクライアントに詳細な説明を行います。

• プロジェクトの「完了」の定義について日本のクライアントと合意し、双方がこの定義を理解し、同意することを確認します。

教訓8：能力プロファイルの虚偽表示

問題点：

オフショア企業が自社の能力を誇張した結果、要求通りにプロジェクトを完了できないケース。このケースでは、オフショア企業は自社のシステム向けにビデオ・ストリーミング機能を開発する契約を取り付けたが、実際の能力は不足しています。

解決策：

• 別のオフショア会社を選ぶ: 会社は、ビデオストリーミング機能を開発する実際の能力を持つ別のオフショア会社と契約を結びました。

• オフショア会社に対して: 自分の能力を誇張せず、できないことを自慢するのはやめましょう。

教訓9：ブラウザでの表示確認の不完全さ

問題点：

モバイル版Safariでウェブサイトのインターフェイスが完全に表示されないというトラブルが発生しました。原因は、オフショア会社がこのブラウザでの表示確認を徹底していなかったことと、クライアントの経験不足で見落としていたことにあります。

解決策：

クライアントのテスト範囲を明確に定義します。知識のないクライアントには、どのブラウザでテストすべきか積極的にアドバイスします。

教訓10: ドキュメント不足による引き渡しの困難さ

問題点：

オフショア会社は、クライアントが文書作成を契約で縛っていないため、文書を作成しません。

解決策：

• 別のオフショア会社を探す： 次のシステムの開発をサポートし、完全なドキュメントをクライアントに提供できる能力と経験を持つ別のオフショア企業を探します。

• 文書化の範囲を明確にする： ドキュメントの種類、内容、完成時期など、会社が提供するドキュメントの範囲をクライアントと明確にします。

教訓11：誤った機能の実装

問題点：

機能がクライアントの要求通りに開発されていません。画面フロー、テキストサイズ、データ表示位置などが間違っています。原因は、テスト・プロセスの不備、不完全なテストケースがエラーを検出できないことにつながります。

解決策：

• 包括的なテストケースを作成する： 包括的なテストケースは、最も小さく、最も詳細な機能を含む、すべてのシステム機能に対して作成する必要があります。

• 顧客とデモ・ミーティングを行う： 製品を紹介し、フィードバックを集めるために、顧客とのデモ・ミーティングを開催します。

教訓12: システム生成のメールがスパムとして分類される

問題点：

クライアントはシステム生成のメールが受信者によって自動的にスパムとして分類されるという問題に直面しています。原因は開発プロセスの欠陥にあり、オフショア会社はメールの送信成功にのみ注力し、スパム分類を回避する最適化を行っていません。

解決策：

• 電子メールの送信者認証を追加します。

• メール送信機能については、スパムと分類されるリスクに注意を払う必要があります。

教訓13：プロジェクト開発に最も安いオフショア企業を選ぶことの結果

問題点：

要件と成果物のコミットメントを適切に定義しないと、オフショア企業は要件どおりに製品を完成させることができません。

解決策：

• 顧客は、機能、特徴、性能、品質評価基準など、プロジェクトの要件を明確に定義する必要があります。

• 未完成の製品を受け入れ、さらなる開発のために別のオフショア企業に引き渡します。

教訓14: 曖昧な機能による発生コスト

問題点：

初期要件で明確に定義されていない機能のために予算を超える費用が発生すること。その原因は、開発前の要件決定が詳細でなかったために、当初プロジェクト範囲になかった要求機能の追加コストが発生することであります。

解決策：

開発前に詳細な要件を決定する： 設計、サーバー、テストケース、品質評価基準など、プロジェクトの詳細な要件を確立する必要があります。

同時に、いくつかの機能を削除することを受け入れる準備をしておきましょう。

教訓15: iPhoneアプリはiPadでサポートされていません

問題点：

オフショア会社はiPad向けアプリの開発経験が不足しているため、iPhoneアプリがiPadデバイスで動作できず、アプリのリリースが遅れてしまいました。

解決策：

iPhoneアプリをリリース前にiPadで動作するように調整してください。

教訓16: 日本語の理解不足によるラボ・アプローチの失敗

問題点：

Laboプロジェクトでは、言葉の壁により日本のクライアントとのコミュニケーションが難しい。要件の誤解が作業の繰り返しを招き、プロジェクトのタイムラインを長引かせ、プロジェクトのコストを増加させます。

解決策：

• BrSEとして日本人を活用する：ブリッジ・システム・エンジニアとして日本人を活用し、日本の顧客との効果的なコミュニケーションを図り、要件を明確に理解します。

• 日本の顧客との業務経験が豊富なオフショア企業と協力し、コミュニケーションやプロジェクト管理をサポートします。

教訓17: ラボ型プロジェクトの非効率性

問題点：

日本のクライアントとのラボ型プロジェクトでの失敗。クライアント側のテストケースが不足しているため、プロジェクト開発に多くのエラーやバグが発生し、プロジェクトの進行や品質に影響を与えます。

解決策：

• 4、6ヶ月経っても機能の1/3しか完成していない場合は、契約を終了して他社に乗り換えることを検討します。

• 文書、スケジュール、テストケースを徹底的に準備する： 受入企業が要件を理解し、効率的にプロジェクト開発を進めるために、プロジェクトの包括的な文書とテストケースを準備する必要があります。

教訓18: バグ修正の失敗

問題点：

同社は、ラボ・プロジェクトのバグ修正がうまくいかず、トラブルに直面しています。原因は以下の通り：

- バグ修正の完了が報告されているにもかかわらずバグが多く残っている場合、テストとバグ修正のプロセスが効果的でないことを示しています。

- テストケースが不完全なため、テスト中にバグを見逃します。

- テストケース作成者のスキル不足により、テストケースの作成効率が悪く、隠れたバグを検出できません。

解決策：

• 発注者側の責任者を交代させる： 発注者側の責任者は、Labo with Offshoreの経験がないため、Laboの経験と理解がある日本人BrSEに交代させます。

• 日本側によるテストケースの作成: 日本側は、テストケースの品質を確保し、隠れたバグを発見するためにテストケースを作成する責任を負います。

• ベトナム側で実施： 日本側から提供されたテストケースをもとに、ベトナム側でバグフィックスを行います。

教訓19: 画像の無断使用によるトラブル

問題点：

プロジェクトで著作権のない画像を使用したことによるトラブルが発生している。原因は画像の著作権チェック不足で、著作権法違反の画像を使用してしまいます。

解決策：

• 著作権保護された画像を販売しているウェブサイトから画像を購入する： Shutterstock、iStock、Adobe Stockなど、著作権保護された画像を販売している評判の良いウェブサイトはたくさんあります。

• フリー画像を使う： Pixabay、Pexels、Unsplashなど、無料で画像を提供しているサイトもあります。

• 自分で写真を撮る： 可能であれば、会社は著作権遵守を確実にするために写真を撮るべきであります。

教訓 20: 契約要件と開発スキルの不一致

問題点：

開発者のスキルが契約に記載されたジョブ要件と一致していません。具体的には、開発者はバックエンドの作業を行うために雇われましたが、フロントエンドのスキルを使って仕事を完了しました。

解決策：

• 履歴書の徹底的な見直し：候補者の履歴書を入念に見直し、職務に必要な経験やスキルがあるかどうかを確認することが重要です。

• 能力評価面接の実施: 候補者の技術的な能力とソフトスキルを評価するために、構造化された面接を実施します。

教訓21：BrSEの欠如による失敗

問題点：

同社はコスト削減のためにBrSEを雇わず、代わりにグーグル翻訳を使って英語でのコミュニケーションを支援しました。

解決策：

BrSEは、クライアントとコミュニケーションをとり、クライアントの要求を理解する役割を担うため、BrSEを活用します。BrSEはまた、開発者のためにクライアントの要件を明確かつ正確に説明します。

教訓22：ステージング環境でのデータの誤削除

問題点：

クライアントは本番移行に備え、ステージング環境にデータを入力した。しかし、ベトナム側はそれをテストデータと勘違いし、削除してしまいます。

解決策：

• データの再入力： データのバックアップがなかったため、同社はクライアントに連絡してデータを取得し、ステージング環境に再入力する必要がありました。

• プロセスを見直す： 操作を行う前にデータをバックアップします。

教訓23：仕事の空白期間を生む長期ラボ契約

問題点：

クライアントとラボ契約を長期間締結した結果、従業員に仕事の空白期間が生じました。具体的には、契約期間は6カ月だったが、仕事量は最初の4カ月に集中し、残りの2カ月は従業員に仕事がありませんでした。

解決策：

追加プロジェクトを割り当てる： ラボの仕事量が減少した場合、同社はラボの従業員に追加プロジェクトを割り当て、仕事を確保し、能力を最大限に発揮できるようにしました。

教訓24：デザイナーが日本のクライアントを誤解する

問題点：

日本のクライアントの考えを十分に理解できないため、デザイナーとのコラボレーションが難しい。両者の文化や美意識の違いが、オンラインでの作業と相まって、コミュニケーションやアイデアの交換をより困難なものにしています。

解決策：

コラボレーションにはFigmaを使用: Figmaはデザイナーとクライアントがリアルタイムでデザインを閲覧・編集できるオンラインデザインツールです。これによりデザイナーはクライアントのアイデアを簡単に把握でき、クライアントもデザインに直接フィードバックを提供できます。

教訓25：デザイナーのスキルがプロジェクトの要件を満たしていない

問題点：

デザイナーのスキルが要件を満たしていないため、デモ・プロジェクトを完了することが難しいです。具体的には、このプロジェクトでは製品の中核となる機能のデザインに焦点を当てる必要があるが、デザイナーはこの分野での経験が不足しているため、プロジェクトの遅延や目標達成の失敗につながっています。

解決策：

適切なデザイナーを選ぶ デザイナーを雇う際には、十分な経験とプロジェクトに適したスキルを持ち、ウェブサイトデザインの経験が豊富な人物を選ぶことが不可欠です。

教訓26：テストケースを書かないことによるトラブル

問題点：

ソフトウェア開発プロセスにおいて、テストケースを作成しなかったために発生した問題です。テストケースがないためにソフトウェアにエラーが発生し、デバッグが困難で時間がかかり、プロジェクトのスケジュールに影響を与えました。

解決策：

• 要件を正しく理解し、包括的なテストケースを作成することが重要であります。

• バグ修正を優先する: ソフトウェアの主要な機能に影響を与える重大なエラーを修正することを優先することが重要です。

教訓27：無理な人員配置による高額ラボ価格

問題点：

オフショア企業がラボ・プロジェクトの見積もり価格を予想以上に高く提示したため、問題が発生しました。分析の結果、契約書に記載された人員数が、実際のプロジェクトの必要性に比べて多すぎることが判明しました。

解決策：

• 他のオフショア会社を探す 他のオフショア会社を検索して価格を比較し、最もリーズナブルな価格の会社を選びました。

• オフショア会社と交渉すること： 実際のプロジェクトのニーズに合わせて、契約の人員数を調整します。

教訓28：日本語での情報共有による誤解

問題点：

口頭でのコミュニケーションが主流だったため、日本人パートナーとの共同作業が難しかったです。文書がないため誤解が生じやすく、仕事の効率にも影響ました。

解決策：

• 情報共有方法の標準化 重要な情報の共有には書面を使用し、話し合いの記録を残すなど、日本のパートナーとの情報共有方法を標準化することが重要であります。

• 支援ツールを活用する： 電子メール、チャット、共有ノート作成プラットフォームなどのツールを活用して、情報を共有し、仕事の進捗状況を把握します。

• 日本語能力の向上 従業員の日本語能力を向上させ、専門的な日本語の語彙や日本人個人のコミュニケーションスタイルを理解できるようにします。

教訓29： タスク管理の問題

問題点：

スプリントの準備が不十分だったため、タスク管理に問題が発生。開発ドキュメントの不足により、開発者が何も作業できず、プロジェクトのタイムラインに影響を与えました。

解決策：

• 開発ドキュメントを完全かつ期限内に完成させることで、スプリント準備の質を向上させます。

• 各スプリントにおいて、仕様作成-開発-テストのフローを効果的に実行します。

教訓30：システム利用許可申請の間違い

問題点：

システム使用許可の申請が遅れ、承認に時間がかかり、プロジェクトのスケジュールに影響を与えるという困難に直面ました。

解決策：

プロジェクトはすでに遅れており、追加的な解決策もなかったため、今後のプロジェクトのためにこの経験から学ぶしかなかったです。

これらは、ベトナムのオフショア企業と協力する際によくある失敗から学んだ30レッスンである。これらの教訓が、オフショアパートナーとの協業を効果的かつ成功に導くことを願っています。