オフショア開発ラボ型, オフショア開発会社, ラボ型開発

【オフショア開発ラボ型】 初めての依頼する時に失敗しない方法

18 View

こんにちはオフショア開発アカデミー・オフラボの花井です。
今回はオフショア開発ラボ型を初めて依頼する時に失敗しない方法について説明をしていきます。

オフショア開発アカデミーのご案内

オフショア開発について体系的に学べる情報サイト【オフショア開発アカデミー】では、オフショア開発の全体像やポイントを無料で学ぶ事ができます。

ご興味がある方はこちら

https://offshore-dev.com/

オフショア開発ラボ型とは?

オフショア開発ラボ型は期間を決めて、開発チームを作り、その期間内であれば、柔軟に開発ができるオフショア開発の開発方法の一つです。

オフショア開発ラボ型のような専用チームで開発を行う方法は日本では多くの費用がかかります。

そのためオフショア開発ラボ型でシステム開発やアプリケーション開発を行う経験が少ない方がほとんどでしょう。

オフショア開発ラボ型は柔軟に開発が行える反面、開発の生産性などに大きく差ができます。

また、様々な失敗が生じやすい特徴があります。

今回はラボ型を失敗しないために、注意するポイントについて説明していきます。

オフショア開発会社のブリッジエンジニアの経験やスキルを確認

オフショア開発ラボ型では開発チームを作成して開発を行います。

開発チームは複数人の開発者とブリッジエンジニア、通訳などで構成する事が一般的です。

オフショア開発ラボ型では上図のようにブリッジエンジニアを通して、システム開発の情報を開発チームと共有していきます。

また開発者からの質問や提案もブリッジエンジニアを通じて依頼者へと共有されます。

担当者からブリッジエンジニアを通じて共有される情報は、システム開発の品質に関わる非常に重要な情報です。

例えば開発したい内容がうまく伝わらないことや開発する機能を誤解するなどが発生するとラボ型は失敗します。

そこで、ブリッジエンジニアのタイプで大まかな傾向を掴むことが大切です。

ブリッジエンジニアのタイプは

  • 日本人開発者

  • 日本人営業担当

  • ベトナム人ブリッジエンジニア

で分ける事ができます。

日本人開発者

日本人開発者がブリッジエンジニアを行うタイプのオフショア開発ラボ型です。

日本人開発者がブリッジエンジニアになることで、システム開発に関わる重要な情報を誤解なく開発チームに伝える事ができます。

システムに関する情報を正確に整理し、開発チームに伝えることやスピーディな提案などを可能にします。

反面、日本人ブリッジエンジニアの費用は他のブリッジエンジニアのタイプに比べ高くなります。

予算などのバランスを考える必要があります。

日本人営業担当

ブリッジエンジニアのポジションで日本人営業担当が情報共有を行うオフショア開発ラボ型のタイプです。

システム開発の機能などを誤解なく伝える事ができますが、システムに関する知見が少ないため、機能の不備や不具合の発生など不安が残ります。

ベトナム人ブリッジエンジニアとの連携がポイントになります。

ベトナム人ブリッジエンジニア

ベトナム人ブリッジエンジニアが依頼者との情報の共有を行うタイプのオフショア開発ラボ型です。

日本語の誤解が生じやすく、もっとも問題が起きやすいオフショア開発ラボ型と言えるでしょう。

他のタイプに比べ費用は安くなります。しかし、失敗のリスクや情報共有のコストなどを考えると、小さいプロジェクトやシンプルなプロジェクト以外はお勧めできません。

上記のようにブリッジエンジニアのタイプによって、オフショア開発ラボ型は難易度が異なります。

プロジェクトの状態や予算などを考慮して、ブリッジエンジニアの対応を選択する必要があります。

スケジュールの確認と遅延の対策を確認

オフショア開発にかかわらず、システム開発ではスケジュールが遅延することは少なくありません。

しかし、オフショア開発では、ビジネス習慣の違いや締切の認識の違いなどが原因でスケジュールが遅延する事があります。

ベトナム人と日本人のビジネス習慣で大きく異なる点として、締め切りに関する認識の違いです。

よくある締め切りの認識の違いでは、締め切り時に開発を終了することを認識している事です。

これが説明が難しいですが、例えば、ある期日までに開発を終えたい場合に、通常、開発・テスト・納品チェックがあります。

しかし、開発者は自分の開発タスクが終了することの期日と認識していることが少なくありません。

プロジェクト全体のゴールを把握せず、自分のタスクのみを認識しています。

そのため、必ず締め切りの期日までに行う内容の詳細を伝える必要があります。

この開発者の個人の認識の違いや業務範囲の認識は後述するテストケースの確認でも影響しています。

スケジュール遅延の対策として、スケジュールをツールなどで管理しているか、前述したように締め切り時の状態の詳細を伝えているか、進捗を定期的に確認し、対策しているかが大切になります。

開発スケジュール・タスク管理ツール

オフショア開発アカデミーサポートやオフラボでは開発スケジュール・タスク管理ツールを使用して、オフショア開発の管理を行なっています。

このようなツールを使用して、対策をしてください。

テストケースの作成と確認

システム開発では開発完了後にテストを行います。テストの網羅性と実施の正確性がシステムの品質を決めると言っても過言ではありません。

テストの作成と実施はベトナム人の最も苦手としている業務です。

原因の1つとして、開発者とテスターのポジションが分離している習慣があります。

開発者は開発だけ行い、テスターがテストを行う認識があります。

しかし小さなプロジェクトでは、テスターが開発チームに参加する場合は多くはありません。

そのため、開発者がテストを行いますが、網羅性や正確性が低く、不具合が発生します。

ブリッジエンジニアやプロジェクトマネージャーがしっかりとテストの作成と実施を管理する必要があります。

オフショア開発アカデミーとオフラボではテストケースの作成サポートと管理ツールを使用してテストの管理を行なっています。

テストの実施には、注意が必要です。

まとめ

オフショア開発ラボ型を初めて行なう時に確認するポイントを説明しました。
今回紹介をした部分だけでも、対策をしておくだけでも、オフショア開発がうまく行く可能性は高くなります。
ご興味がある方はオフショア開発アカデミーサポート、オフラボ・オフミツをご利用ください。

関連記事

【オフショア開発失敗事例紹介】 決済サービスの申請トラブル

2022/11/28 オフショア開発の基本 詳しく

【オフショア開発失敗事例】決済システムの申請トラブル

2022/11/24 オフショア開発の基本 詳しく

【オフショア開発失敗事例紹介】テスト後の修正を拒否された事例

2022/11/23 オフショア開発の基本 詳しく

【オフショア開発失敗事例】タスク管理トラブル

2022/11/23 オフショア開発の基本 詳しく

【オフショア開発失敗事例】日本語での情報共有の誤解

2022/11/22 オフショア開発の基本 詳しく