日本では人材不足の課題がメディアに多く取り上げられていますよね。解決策としてオフショア開発を導入しようとする企業が多く見られます。しかし、オフショア開発に深く注意しないと、失敗に陥る可能性が高いように思えます。
オフショア開発を導入するプロセスでは、思ったより細かい事に気を配らなければなりません。実際に、失敗を積み重ねてきた企業しかそういう点が分かりません。そこで、本記事では、オフショア開発失敗を最小限にする方法をご紹介いたします。
1. オフショア開発とは？
オフショア開発とは？
オンショア開発とは、自社の国で活躍している企業に委託することです。例として、日本企業は新しいプラットフォームを構築する希望を持ち、ITサビースを提供する他の日本企業と協力することが挙げられます。両方とも同じ国で運営しているため、言語の壁がありません。また、エンジニアの現場が自社の場所から長く離れないので、直接相談することは難しいではありません。しかし、日本のような発展国では高い人件費が高コストに繋がります。
オフショア開発に関しては、考慮すべき要素がいくつかあります：
計画と戦略：それは何よりも重要なものです。まず、オフショアの段階と方法を慎重に準備する必要があります。 これによって、オフショアプロジェクトを効果的に管理できるし、需要や要件を満たす完成品を取得できるし、オフショア開発の成功を収められます。
機能: ほとんどすべての機能をオフショア ベンダーにアウトソーシングすることができます。
しかし、どの機能を外国のIT企業に委託するかを決める必要があります。
予算: 最も安い選択が最善であるとは限りません（「安かろう悪かろう」の場合が多い）。 高品質を維持しながら、オフショア開発チームと戦略に費やす適切な金額を確保します。
言語と文化の互換性: フィリピン、ベトナム、マレーシアのいずれにアウトソーシングする場合でも、文化と言語のハードルは依然として残ります。依頼先を選択する時、是非この問題に注意してください。
サービス契約: 各当事者の責任のために、契約を明確にすることも重要です。価格体系を含め、すべてがサービス レベル アグリーメント (SLA) に文書化されていることを確認してください。
バックアップ戦略: 最後に、オフショアリング アプローチが常に成功するとは限りません。 従業員が期待に応えられないか、会社の成長に合わせてオフショアリングの方法を調整する必要があります。
2．オフショア開発の失敗
2.1.コミュニケーションがうまくいかない
言語の壁
外国企業との取引を行うことは言語の壁を生み出します。異なる文化により、言葉の裏に隠された意味を相手に届けられないことがあります。
更に、言語の特徴が違う場合、コミュニケーションが取れない可能性が高いです。日本や英国の言語は文脈（身体言語や声のトーンなど）を基づいて意図を理解する高コンテクストです。一方、ベトナムや北欧、北米などの言語は言葉を基づいて意図を掴む低コンテクストです。高コンテクストでは、相手を当惑させたり怒らせたりしないように、丁寧な言葉遣いや言い回しを選びます。例えば、日本人は「よしなに」の話し方が好きですね。相手にどうぞよろしく、またはいい具合になるようよろしく、日本人は分かるが、低コンテクストの国から来た人はいい具合はどんな具合かが全然わからないと感じることが少なくありません。低コンテクストの場合、言い回しではなく、問題を直接に突き、自分の意思・欲望などをずばりと話します。それは日本人をビックリさせるのではないでしょうか。しかし、違いを受け入れないと成功を収められません。
日本側の話し方が曖昧すぎ
日本語は独自の曖昧さで知られていますね。自分の意思を端的に言えず、「これはあんまり…」や「これは良いだけど…」を話っぽいの日本人です。しかし、外国人と一緒に働くと、日本側は何が欲しいかを全然わかりません。そして、彼らは自分の考え方で相手の意図を理解して、結局は誤解してしまったことが多いです。また、ブリッジSEをアサインしたら、日本人と話したような表現で話してもいい思考を持ったら、危険の目にも遭えます。どんなに日本が上手にしても、外国から来たことは所詮変わりません。
委託された会社のブリッジSEは日本語がうまくできない
実際に、オフショア開発の小規模の会社はコスト削減の方法として低度のブリッジSEを活用する傾向があります。その会社には「相場より安い価格」という特徴があります。かけ橋の役割を果たすブリッジSEは日本語が下手なら、プロジェクトの失敗を避けるわけではありません。
2.2.上流工程が不明確になる
オフショア開発の上流工程と言えば、両側が話し合い、要件や契約の条件を交渉するイメージを思い浮かべます。我々が実行したアンケート調査では、相手の要件または仕様を明瞭にならなかったと同意した依頼先の数は過半数を占めました。それらが何を引き起こしたかを、同意者に質問した結果、42％のは「修正の頻度が多すぎて、時間が遅れてしまった」、31％のは「検収時に近い時、顧客の仕様を変更しなので、最初からやり直して大変」です。
実際に、オフショア開発のモデル（オフショア開発のモデルをまだ理解しない方は、このポストをおすすめ）によって最初の要件・仕様を変更できるかどうかを決めます。請負契約（プロジェクトベースモデルの契約）の場合、要件・仕様を変更することは不可能が、ラボ契約（オフショア開発センターの契約）には可能です。したがって、請負契約を結んだら、仕様・要件が詳しくなかったら、完成品が期待通りにならないはずです。それに、仕様・要件を新しくしたい時、新契約を結ばざるをえません。企業のオーナー・管理者はどのようなプロダクトが欲しいかを想像しない場合、ラボ契約が良い選択肢になるが、修正の程度により追加費用が違うことに要注意です。
2.3.メンバーが退職や休職することが多い
依頼先が提供した開発チームのメンバーが退職したら、後任者はプロジェクトに適応するのに時間がかかるため、進捗を保ちません。同様に、メンバーが休職する時期が長くてプロジェクトの進捗も影響を及ばします。それを徹底的に避けるために、契約交渉の段階で開発チームの人数または人材が変わらないようにすることに同意するよりほかありません。その点で、VTIグループはオフショア開発センター（ODC）の開発チームで定めらた人材の他に、代行のチームも提供します。開発チームのメンバーが急に退職や休職したら、代行のチームからの人が本人に代わって仕事をします。
2.4.価格が疑わせるほど安ぎる
オフショア開発を選択する主理由はコストを削減するのではないでしょうか。しかし、相場より安い価格を決めたら、高品質を確保できないものです。「安かろう悪かろう」ですから、値段を重視すぎると、ソフトウェア・システム開発の目的を忘れてしまいます。ところが、相場の価格はどのくらいかを事前に調べたら、低価格の罠に陥りやすいです。
2.5.完成品が低い
完成品が期待通りにならず、低すぎる場合もあります。ソフトウェア・システム開発を導入すると、どの問題が発生しても悪い完成品に繋がります。上記に話した理由の他、ソフトウェア・システムを実装する中で、ソースコードが良くないし、依頼先で人手不足によりブリッジSEがデベロッパーの一部の仕事を行うし、完成品の確認時間が短すぎて、修正が発生したら締め切りが遅れてしまうのでバグがあったまま完成品を受け取るし、様々な理由があります。
2.6.進捗を十分に管理できない
進捗がうまくいかないことには様々な理由があります。代表的な理由として、報連相が行わなくて情報のギャップを常に発生したり、依頼先との打合せが効果を与えなかったり、自社の代表者が契約を結ばず、媒介企業を下請けに委託したりすることが挙げられます。
報連相（報告ー連絡ー相談）は日本企業の文化だが、外国企業の文化ではないかもしれません。しかし、遠く離れた海外企業と協力すると、依頼先に丸投げてしまったら、危ない目に遭う可能性が高いです。また、相談の頻度と内容にも注意しないことも多いです。頻度が多すぎると、デベロッパーが仕事に集中できない、逆に短すぎると、プロジェクトの進捗を完全に把握できません。そして、相談ごとにいつ何を報告するかを決めなかったら、時間を無駄にします。一方、媒介企業に依頼したら、情報を失う可能性が高くなります。
2.7.スケジュール通りに納品しない
上記に述べたように、修正する頻度や程度などが完成品の納品時に影響を与えます。ソフトウェア・システムを実装する中で、バグが発生しないことを誰も保ちません。問題はバグを取り除く時間を推定できない事です。更に、仕様などの変更は進捗が遅れていることを引き起こします。
2.8.予算をオーバーする
進捗をスムーズに進まないと、修正費用といった追加費用が発生します。費用対効果が高いので、オフショア開発を求めていたが、結局国内より高費用がかかる場合もあります。プロジェクトの進捗が芳しくない状況に遭遇する企業はオフショア開発に関して経験があまり多くないんです。
3.オフショア開発の失敗を解決できる方法
3.1.開始前
3.1.1.下請けをせずに直接に契約を結ぶ
オフショア開発を経験しなかった企業はリスクを最小限にするために、媒介企業に業務を投げるという下請け扱いをしている傾向があります。上記に話したように、進捗を把握できないリスクの他に、自社の状況を十分に理解できない媒介企業がソフトウェア・システムの要件を伝えて切れないリスクもあります。そこで、日本企業はできる限り、直接に依頼先と契約を結んでください。更に、企業のIT部門を持ったら、IT部門の社員がブリッジSEとともにコードレビューをして品質に共通認識を持ったほうがいいです。最初から、丸投げだけではなく、依頼先とともにプロジェクトに力を注いだら失敗を最小限にすることができます。
3.1.2.実績が多い、日本企業と長く付き合っているオフショア開発の企業を厳選
高品質な完成品を受け取るために、日本企業と長く付き合って、実績が豊富な依頼先が良い選択肢になります。多くの業界に向けるソフトウェア・システム開発に精通した人材を有したその企業は報連相の働き方に従ったり、顧客のフィードバックに柔軟に対応したり、バグをすばやく修正したりします。相場より高い費用がかかる可能性は当然だが、リスクを最小限にすることは可能です。それに、かけ橋の人材として日本語能力が高い、日本国内のIT資格を取得した人材を有した企業をお勧めします。
3.1.3.企業の状況に合わせたオフショアモデルを選択
オフショアモデルと言えば、主にオフショア開発センター（ODC）とプロジェクトベースモデルの概念を思い浮かべます。前者は依頼先で働いているが、顧客の依頼業務を開発チームのフールタイムで実行するモデルです。そのモデルには最初の要件・仕様を変更できる（変更したら、追加費用がかかる）ので、要件が詳しく説明できない企業に適します。また、特定の時間で依頼先の人材を自分の社員として、IT業務などを行い、つまり契約の単価は人材が働ける時間を基づいます。それは締め切りが長引いたら、追加費用も発生します。一方、後者の目的は成果物、すなわちプロジェクトの完成度によって報酬を払います。しかし、初期の要件・仕様を変更したい場合、新契約を結ぶよりほかありません。
3.1.4.開発チームにブリッジSE、QA（品質管理担当者）、PM（プロジェクトマネジメント）がいるかどうかを確認
海外のオフショア開発企業が提供した開発チームには、IT知識を持っている、日本がうまく話せるブリッジSEがいることは当然だが、PMやQAがいない場合もあります。費用を抑えたい企業はメンバーの増加があまり好きではないが、PMかQAかいずれの人を追加するか品質を向上するのに役立ちます。VTIグループはPMとQAの役割が重要だことを理解して、要求されない場合でも、開発チームにQAまたはPMを確保します。顧客の予算に合わせた開発チームの人材を配置するようにコンサルティングを無料で提供します。
3.1.5.目的から、需要、予算、時期などを詳しく説明した仕様／要求を提供
進捗をスケジュール通りに進むために、できる限りに、契約または仕様、要件は明確にしてください。何が欲しいか、企業の課題が何か、予算がどのくらいか、いつ完成品を受け取りたいか、様々な点は明瞭にすればするほど、両側の紛争を避けられます。プロダクトについての要件・仕様がまだ分からない場合、オフショア開発センター（ODC）を推奨します。
3.1.6.打合せの方法を決定
最初から打合せの頻度やツールを決めたら、両側が情報をより簡単に把握することができます。例として、2～3日ごと両側が15分ぐらいで進捗の概要状況を相談し、1周1回に進捗の状況を報告し、1月1回にプロジェクトの完成度を報告することが挙げられます。依頼先の開発チームの顔が見えないから、打合せが必要です。しかし、打ち合わせごとが便利になるように注意します。
3.2.実装中
3.2.1.ドキュメント化と共有を徹底
コミュニケーションの中で、口頭だけではなく、形に残るように会話の内容をテキスト化したらほうがいいと思います。紛争や誤解などが発生したら、テキストをたどり着いて、正しい意図を把握することは可能です。また、相談する時、日本企業はできるだけで優しい日本語で話してください。少ない人に知られている言葉または丁寧すぎる表現を使うより、簡単な表現はコミュニケーションの効果を上げます。
3.2.2.進捗を常に管理
プロジェクトの進捗を円滑に進むために、コミュニケーションや打ち合わせを通じて進捗の状況を十分に把握するように力を注いでください。プロジェクトを担当する日本側が報告書を慎重に検査し、もし不明な点があれば、直ぐに問い合わせください。
3.2.3.予定通りのテスト・デモを確保
高品質な完成品を手に入れるために、テスト又はデモの段階を取り除かないでください。プロダクトを確認する時間が短すぎると、バグを置いたまま完成品を受け取ることは無駄でしょう。低品質な完成品を使用する期限がより低いために、新しくのを交換するべきです。そこで、テスト又はデモの時期を絶対にプロジェクトの時期に入れ、できる限りデモを行うようにしてください。
3.3.検収後
協力を維持するために、フィードバックをためらわない
完成品を受け取るとプロジェクトが終わると考えて、依頼先と相談しなくてもいいと思って、そうしようとすることは止めてください。ソフトウェア・システムを導入すると、定期で運用・メンテナンスをしなければなりません。使用中に、何か問題が発生したかというフィードバックをためらわず依頼先に提供してください。
4．VTIグループ
株式会社VTIは金融、建設、小売、運輸、インタネットサービスなど多岐多様な業種で、全規模企業向けにソフトウェア開発、自動化実装、デジタルトランスフォーメーション、ハイテクサービスをご提供します。
従来、VTIグループはAWSパートナー、マイクロソフトゴールデンパートナー、Magento、Odoo、ServiceNow、Salesforce公式パートナーに認定され、ISO 27001 セキュリティ標準、プライバシーマーク（Pマーク）、国際認証CMMIレベル3を取得したことに加えて、日本・韓国・ベトナム・シンガポールの100会社以上にパートナーとしてIT技術のサビースを提供しております。更に、この4国にわたる8子会社で働いている1200従業員以上は、企業様のDX革命の成功を目指して、社員一同全力を持って取り組んで参ります。
