オフショア企業、特にベトナムのオフショア企業との仕事は、企業に多くの利点をもたらす可能性があります。例えば、コストの節約や高品質の労働力へのアクセスが挙げられます。しかし、これらの利点の裏には、慎重で丁寧な実施がなければ多くのリスクも潜んでいます。
この記事では、ベトナムのオフショア企業との仕事でよくある失敗から得られた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: iPadでサポートされないiPhoneアプリ
問題：
オフショア企業にはiPad用のアプリを開発する経験がないため、iPhoneアプリがiPadデバイスで動作しない状況が生じ、アプリのリリースが遅れています。
解決策：
iPhoneアプリがiPadでも動作するように修正してからリリースしてください。
レッスン16: 日本語の理解不足によるLabo形式の失敗
問題：
ラボ形式でのプロジェクト実施において、日本の顧客とのコミュニケーションに多くの困難が生じています。言語の壁により要件を誤解し、何度も作業をやり直すことが必要となり、プロジェクトの時間とコストがかかります。
解決策：
- 日本人をBrSEとして雇用する：効果的な日本の顧客とのコミュニケーションと要件の理解を確保するために、日本人をBrSEとして雇用する必要があります。
- 他のオフショア企業と協力する：日本の顧客との作業経験がある他のオフショア企業と協力し、コミュニケーションとプロジェクトの管理をサポートしてもらいます。
レッスン17: Labo型プロジェクトが効果的でない場合
問題：
日本の顧客とのラボ型プロジェクトの実施が失敗に終わりました。顧客側からのテストケースが不足しており、プロジェクトの開発が多くのエラーやバグに直面し、プロジェクトの進捗と品質に影響を与えました。
解決策：
- 契約を終了し、別の企業に移行する：4〜6か月経過しても、機能の1/3しか実装できていない場合は、契約を終了し、別のオフショア企業にプロジェクトを引き継ぐことを検討してください。
- 文書、スケジュール管理方法、テストケースの準備：プロジェクトを引き継ぐオフショア企業が要件を理解し、効果的にプロジェクトを進めるために、十分な文書、テストケースを準備する必要があります。
レッスン18: 不成功なバグ修正
問題:
プロジェクトのラボでのバグ修正がうまくいかないトラブルが発生しています。以下の要因があります：
- バグの数が多い: バグの報告は完了したとされていますが、未解決のバグがまだ多数残っており、テストとバグ修正のプロセスが効果的でないことを示しています。
- テストケースが不十分: テストケースがすべてのテストケースをカバーしていないため、テスト中にバグが見逃されています。
- テストケース作成者の能力不足: テストケースを作成する人のスキルが不足しており、効果的なテストケースが作成されず、潜在的なバグが検出されていません。
解決策:
- カスタマーフェースを置き換える: オフショア担当者がラボを実施する経験がないため、経験豊富でラボに精通している日本人のBrSEに交代しました。
- 日本側がテストケースを作成: テストケースの品質を確保し、潜在的なバグを検出するために、日本側がテストケースの作成を担当します。
- ベトナム側が実装: 日本側から提供されたテストケースに基づいて、ベトナム側がバグ修正を担当します。
レッスン19: 版権のない画像の使用によるトラブル
問題:
プロジェクトで版権のない画像を使用したことでトラブルが発生しています。これは、画像の著作権を確認しなかったことに起因し、著作権法に違反する画像を使用してしまいました。
解決策:
- 著作権付きの画像を購入: Shutterstock、iStock、Adobe Stockなど、信頼できる著作権付き画像のウェブサイトから画像を購入します。
- 無料の画像を使用: Pixabay、Pexels、Unsplashなど、無料の画像を提供するウェブサイトを使用します。
- 自社で写真を撮影: 可能であれば、自社で写真を撮影して著作権を確保します。
レッスン 20: 開発者のスキルが契約と一致しない問題
問題:
開発者のスキルが契約で指定された仕事要件と一致していません。具体的には、バックエンドの仕事を行うように雇われた開発者が、フロントエンドのスキルを使用して仕事を完了しました。
解決策:
- 履歴書を注意深くチェック: 開発者の履歴書を注意深くチェックし、仕事に必要な経験とスキルが十分に備わっていることを確認します。
- 能力を評価する面接を行う: 開発者に対して、専門的な能力やソフトスキルを評価する面接を行います。
レッスン 21: BrSEの不足による失敗
問題:
企業がコスト削減を図るために、BrSEの雇用を省略し、代わりにGoogle翻訳を使用して英語のコミュニケーションをサポートしました。
解決策:
BrSEを使用する: BrSEは、顧客とのコミュニケーションを担当し、顧客の要件を理解する責任があります。BrSEはまた、顧客の要求を開発者に明確かつ正確に説明します。
レッスン 22: ステージング環境でのデータ誤削除
問題:
顧客が本番環境にデータを移行する準備のためにステージング環境にデータを入力しましたが、ベトナム側がその内容を理解せず、テストデータと誤解して削除してしまいました。
解決策:
- データを再度入力: バックアップがなかったため、会社はデータを顧客から取得し、ステージング環境に再度入力しました。
- プロセスの見直し: データに対するすべての操作の前にバックアップを取るように、プロセスを見直します。
レッスン 23: ロングタームラボ契約が仕事の空白をもたらす
問題:
長期間の顧客とのラボ契約が従業員に仕事の空白をもたらしています。具体的には、6か月間の契約がありますが、最初の4か月での作業量が集中し、その後の2か月間、従業員には仕事がありませんでした。
解決策:
他のプロジェクトを追加する: ラボの作業量が減少した場合、会社は従業員に他のプロジェクトを追加して、彼らが仕事を持ち、最大限の能力を発揮できるようにしました。
レッスン 24: デザイナーが日本のクライアントの意向を理解できない
問題:
デザイナーとの協力に難航しています。デザイナーが日本のクライアントのアイデアを理解できないためです。これは、両者の文化的および美的な違いに加えて、オンラインでの作業がコミュニケーションとアイデアの交換を難しくしています。
解決策:
Figmaを使用して意見を交換する: Figmaは、デザイナーとクライアントがリアルタイムでデザインを共有し、編集できるオンラインデザインツールです。これにより、デザイナーはクライアントのアイデアを容易に把握でき、クライアントもデザインに直接意見を提供できます。
レッスン25: デザイナーのスキルがプロジェクトの要求を満たさない
問題:
デモプロジェクトの完了が難しいです。デザイナーのスキルがプロジェクトの要求に応えていません。具体的には、プロジェクトは製品の主要機能の設計に焦点を当てる必要がありますが、デザイナーはこの分野での経験が不足しており、プロジェクトが遅れ、目標が達成されていません。
解決策:
適切なデザイナーを選択する: デザイナーを採用する際には、プロジェクトに適した経験とスキルを持つ人物を選択する必要があります。特に、ウェブデザインの経験が豊富な人材を求めます。
レッスン26: テストケースの作成がないことによる問題
問題:
ソフトウェア開発中にテストケースを作成しなかったことによる問題が発生しました。テストケースが不足しているため、ソフトウェアにいくつかのエラーが発生し、修正が難しく時間がかかり、プロジェクトの進行に影響を与えました。
解決策:
要件を正しく理解し、十分なテストケースを作成することが重要です。
エラーの修正を優先する必要があります。ソフトウェアの主要な機能に影響を与える大きなエラーを修正する必要があります。
レッスン27: 人員配置が不適切でラボの見積もりが高額化する問題
問題:
オフショア企業がラボプロジェクトの見積もりを予想以上に高く出している問題が発生しました。分析の結果、契約で見積もられた人員数がプロジェクトの実際のニーズよりもはるかに多いことが判明しました。
解決策:
- 他のオフショア企業を探す: 他のオフショア企業と価格を比較し、最も適切な価格の企業を選択しました。
- オフショア企業と再度交渉する: 契約の中の人員数をプロジェクトの実際のニーズに合わせて調整するために再交渉しました。
レッスン28: 日本語での情報共有の誤解
問題:
口頭でのコミュニケーションが主体であるため、日本のパートナーとの協力が難しい状況に直面しています。文書が不足していると、誤解が生じ、仕事の効率に影響が出ます。
解決策:
- 情報共有方法の統一: 日本のパートナーとの情報共有方法を統一する必要があります。例えば、重要な情報の共有には文書を使用し、議論の結果を記録します。
- サポートツールの使用: メール、チャット、共有ノートなどのサポートツールを使用して情報を共有し、作業の進捗状況を追跡する必要があります。
- Comtorの日本語能力向上: 従業員の日本語能力を向上させ、専門用語や日本人の情報共有方法を理解できるようにする必要があります。
レッスン29: タスク管理に関する問題
問題:
スプリントの準備作業が不十分でタスク管理に問題が発生しました。開発者が仕事を持たないため、プロジェクトの進行に影響が出ました。
解決策:
スプリントの準備作業の質を向上させるために、開発文書が十分かつタイムリーに完成することを確認する必要があります。
各スプリントでの Create Spec – Dev – Test フローを改善する必要があります。
レッスン30: 支払いシステムの許可申請の遅れによる問題
問題:
支払いシステムの許可申請が遅れ、承認待ちの時間が長引き、プロジェクトの進行に影響が出ました。
解決策:
プロジェクトが遅れており、追加の解決策がないため、次回に教訓を生かすしかありません。
以下是从与越南离岸公司合作中常见的失败中获得的30个经验教训。希望这些经验教训能帮助企业有效且成功地与离岸合作伙伴合作。
以下はベトナムのオフショア企業との協力から得られた30の失敗からの経験則です。これらの教訓が企業がオフショアパートナーと効果的かつ成功裏に協力するのに役立つことを願っています。
この情報は、お客様のビジネス結果を最適化するのに役立ち、本書「ベトナムでのオフショアプロジェクトを開始する際に知っておくべき30の経験」に基づいています。著者はNaoya Hanai氏で、ベトナムでのBrSEとして5年以上の経験があります。