・原因
期日やスケジュールの重要性は文化によって異なります。例えば、インドの方は時間にルーズな傾向があります。また残業をするかどうかも文化によって異なります。海外では家族との時間を重要視するため、時間になると帰ってしまうということがあります。
・解決策
文化的な違いがあるため、依頼前に依頼先へ文化とともにメンバーの残業有無を確認すると良いでしょう。また残業代についてなど残業に関わる制度の確認をすることで、そもそも残業があるか？残業をエンジニアがしてくれる環境があるか？を判断ができます。
また1ヶ月などプロジェクトの初期で大量のタスクや連続性のあるタスクは依頼せず、単発のタスクを依頼すると事故発生の確率が減ります。例えばLP制作や機能一部分を作成など、様子を見ながら都度都度タスクを依頼していきましょう。
・原因
オフショア開発ではブリッジエンジニアと直接コミュニケーションを取りますが、手を動かすエンジニアと直接会話することは多くありません。そのため、伝言ゲームのような形で連絡を取ることになり、結果的に仕様が上手く伝わっていないということがあります。
・解決策
初期段階で適切な手法が決定していないため、指示をして作業する前に「どのような作業をしようとしているか？」テキストベースで共有をさせ、確認することをオススメします。また並行して適切な指示出しの方法を決定する必要があります。ブリッジエンジニアやエンジニアが優秀な場合はミーティングをするだけで、プロジェクトを問題なく進行していきます。ただし、いずれかが優秀でない場合は作業指示書を作成し、プロジェクトを進めながら型を作っていきます。
・原因
日本側のプロジェクト管理とブリッジエンジニアのプロジェクト管理が、別ツールであることにより連動していない場合などは想定以上に遅れている際の発覚が遅れることでスケジュールを巻き直せないという問題が発生します。
・解決策
プロジェクト管理ツールやスプレッドシートなど共通の画面でスケジュールやタスクを管理しましょう。またタスクにかかる工数が日本側とオフショア側で一致していない場合に事故が起こります。プロジェクト管理の中に組み込み、差分を減らすことで品質担保や期日厳守を実現できます。
・原因
オフショア開発では、どこまでの要件を定義すればエンジニアは要件通りにパフォーマンスするか判断されていない場合に、アウトプットの品質に問題を抱えることがあります。どこまでの要件は日本側で決め、どこからはブリッジエンジニア側で決めるかを決定する必要があります。例えば、サイト制作でデスクトップ版のみ作成してモバイル版は作成しない場合、モバイル版が想定外の仕上がりになる可能性があります。
・解決策
最初は工数をかけてでも詳細に要件定義を行い、徐々に粒度を粗くすることで、結果的にプロジェクトの事故を起こさずに必要工数を少なくすることができます。オフショア開発の開始初期は新卒が入った気持ちで進めていきましょう。初期で必要な要件の粒度を決定すると、その後人員を増加させた場合には問題が発生しなくなります。
・原因
文字通り必要な技術レベルや経験を持たないエンジニアがアサインされた場合に発生します。またブリッジエンジニアの実力も重要となります。現場のエンジニアのレベルが高くても、ブリッジエンジニアのレベルが不十分な場合は要件やスケジュールが適切に管理されず、品質の低下を生み出します。
・解決策
依頼前にエンジニアとブリッジエンジニアのスキルセットや過去のアウトプットを確認し、自社エンジニアとの面談などを行いアサイン人材や依頼先を決定しましょう。1ヶ月や1名などミニマム単位から始めることが可能な場合は、ぜひ一度検討をしてみてください。
・原因
タスクを依頼してはいるが、タスクの目的やプロジェクト全体の目的などの背景が伝わっていない場合には、エンジニア自身で要件を判断する部分に間違いが発生しやすくなります。特にバックエンド部分においては目に見えない挙動が多くあるため、既存機能へ影響を及ぼす場合があるので注意が必要です。
・解決策
オフショアではプロジェクト開始時にキックオフを行い、プロジェクトの目的、スケジュール、エンドクライアントのビジネス、既存構築物についてなど前提の情報を共有をしましょう。またラボ型の開発で複数のプロジェクトのタスクを依頼する場合は、工数をかけてでもプロジェクト開始の度に説明をすることで、最終的な手戻りを減らすことができます。
・原因
オフショア開発において、準委任契約やラボ契約の場合は損益分岐点を定めていない場合に開発コストが合わなくなることがあります。コスト削減を目的にオフショア開発を開始したものの、どこまでの仕事を任せるか理想の姿が決まっておらず、気づいたら自社内で完結してもコストは変わらないということはよくあります。
・解決策
最終的に1部署、1チームを作る形で役割を明確にする必要があります。例えば、サイト制作会社であれば LPは全てオフショア開発チームで納品するという形でチームとして機能させています。このように目的を明確にすることで、求めるパフォーマンスに近づいているか確認しながらオフショア開発チームを発展させましょう。
・原因
準委任契約やラボ型契約の場合は、品質不足の場合に自社内のリソースで対応しなければならないこともあります。そのような場合はアウトソースをしているにも関わらず、自社のリソースを活用するため、結果的に費用対効果が合わなくなります。
・解決策
前述の方法で品質を向上させること、またオフショアに業務を任せた場合の損益分岐点を考えることでオフショアの継続を判断しましょう。
・原因
準委任契約やラボ型契約の場合には、これまでの2つとは異なり、仕事が足りずエンジニアが暇をしてしまう場合もよくあります。アウトプット自体は問題ないが、自社内でどのような場合にオフショアチームに依頼するか明確でなく、結果的に誰も活用していないということはよくあります。ブリッジエンジニアとチャットで直接的に会話することが少なく、オフラインで関わることもないために発生する問題です。
・解決策
ここではオフショアチームを管理する社内担当者を決定することが重要です。その担当者以外から仕事を依頼する場合、まずは社内担当者が業務量の確認をしてアサインの可否を決定します。そしてアサイン可能な場合に、ブリッジエンジニアを社内の依頼者と繋いでプロジェクトを開始します。これによってタスクを依頼する場合に直近のものだけでなく、1週間先など未来のタスクも依頼されるため、タスクがなく暇になるという状態は軽減されます。
このようにオフショア開発を成功させるには、気を付けるべきポイントがいくつもあります。主にコミュニケーションの徹底、明確な要件定義、そしてコスト管理が不可欠です。リスクを最小限に抑え、プロジェクトを円滑に進めるために、この記事で紹介した解決策を参考にしてください。