2023.02.21
オフショア開発は、コスト削減や社内リソースの効率的活用のために、多くの組織で導入されています。
しかし一方で、オフショア開発は品質の担保が難しい面もあるため、ソフトウェアテスト会社を介してオフショア開発を行うケースが増えています。
今回は、オフショア開発の3つの壁(課題)と、オフショア開発を行う際に心得ておくべきこと、成功させるためのポイントをご紹介します。
- もくじ
1．オフショア開発とは
オフショア開発とは、システムやソフトウェアの開発業務を海外の受託会社や子会社に委託する手法です。
日本国内よりも人件費が安い国へアウトソーシングすることで、コスト削減を図ることができます。また優秀なIT人材を、必要なタイミングで、必要な時だけ、活用することでより効率的に開発を行うことが狙いです。
2．オフショア開発における3つの壁(課題)
オフショア開発では、開発コストの削減や優秀な人材の活用が可能になる一方で、以下の3つの壁があります。
- 言語の壁
- 距離の壁
- 文化の壁
それぞれ詳しく解説していきます。
①言語の壁
海外にアウトソーシングする場合、言語が異なるため、意思疎通を密に行うのが難しくなります。特に開発段階になると現地のエンジニアと直接のやり取りが必要になるため、お互いの言語を理解できないとスムーズな業務ができなくなります。
②距離の壁
日本と海外は距離が離れているため、委託先の人材と直接会う機会が限られます。また、国によっては時差もあるため、十分なコミュニケーションが取りにくいことが懸念されます。
③文化の壁
海外では、慣習や商習慣、品質の良し悪しの捉え方が日本と異なります。
そのため、各種取り組みにおいて認識がずれてしまうことが考えられます。
これが要因となり、製品が発注側の求める品質に満たないものになってしまうということが起こり得ます。
3．オフショア開発で心得ておくべきこと
オフショア開発を実施するにあたって心得ておくべきことを2つ解説します。
社内開発や国内へのアウトソーシングとは違った注意点もあるので、あらかじめ覚えておくようにしましょう。
「そんなの常識だろう」は通用しない
国内での自社開発や、同じく国内の開発会社が開発する際には、機能仕様がある程度曖昧であったとしても、発注元と受注側の間で暗黙の了解を持って対処することもできます。ある程度付き合いが長くなると、仕様書には書かれていない意図を受注側で経験に基づいて読み取って、システムに反映できることもあります。
しかし、オフショア開発をする場合は、「仕様書が多少不明確であっても、相手が気を利かせて対処してくれるだろう」と、期待してはなりません。暗黙の了解は期待できないと認識しておく必要があります。
海外では契約が絶対的な位置を占めるものです。たとえ日本の発注元が「確かに仕様書には明確に書いてはいないが、そんなことは常識だろう」と詰め寄ったとしても、海外の開発会社にはそれは通りません。
仕様書の行間を読むようなことはせず、仕様書に書かれていないものは実装されませんし、当然ながらテストも行われません。慣習や商習慣の違い、品質の良し悪しの捉え方の違いとは、こういったことにも表れるのです。
「常識に考えてやってもらえると思っていたものがやってもらえなかった」などのトラブルを防止するためには、「仕様書に書かれていないものは実装されない」「分かりにくい仕様書からは、それなりの品質レベルのものしか出来上がってこない」ということを、肝に銘じる必要があります。
受け入れテストで課題抽出するのでは遅すぎる
オフショア開発で委託したシステムの受け入れテストを実施する場合、その時点で課題抽出するのでは遅すぎる場合があります。
受け入れテストは、基本的に受け入れテストの前に委託先で十分なレビューやテストが行われていることを前提に、致命的な問題が無いことを確認するために行われるべきものです。そのため、もし受け入れテストでバグを大量に発生させてしまったら、それをリカバリーするのは大変です。特にオフショア開発では困難を極めます。
大きな手戻りが必要になることで、プロジェクトが大クラッシュする危険にさらされることも十分考えられます。そうなってしまったら、後は人海戦術に頼るしか他にほとんど選択肢はありません。その結果、オフショア開発でコストダウンを狙ったものの、かえって大変なコスト高になることも。何よりも、品質に関わる事故は、その企業の根幹を揺らがす事態にもなり得ます。
このような事態を避けるためには、受け入れテストよりも前に、レビューやテストを行って課題を洗い出し解決しておくことが重要です。詳しくは次章で解説していきます。
4．オフショア開発を成功させる3つのポイント
品質管理の鉄則として以下のようなことがあります。
鉄則1：バグを作り込まないで最初から正しく実装すること
鉄則2：作り込んだバグは可能な限り早い段階で検出して修正すること
この鉄則はオフショア開発にも適用されるべきもので、オフショア開発の特質を考慮すると、具体的には以下の3つが重要な項目として挙げられます。
- 仕様を曖昧にせず、明確に具体的に提示する
- 開発の初期段階で合同レビューする
- 計画をレビューし計画どおりに行われることを見届ける
順に詳細を見ていきましょう。
① 仕様を曖昧にせず、明確に具体的に提示する
オフショア開発では、前章で解説したように「仕様書が多少不明確であっても、相手が気を利かせて対処してくれるだろう」と期待してはなりません。
オフショア開発を成功させるには、しっかりした仕様書を提示すること、つまり、発注品質を高めることが最も重要です。
また、もし予算と体制が許せば、機能仕様に基づいたシステムテストのテスト設計を社内で行い、それをあらかじめ委託先に提示、そのシステムテストをクリアできるように開発してもらう、ということも仕様を明確化する手段の一つとしてあります。
日本の発注元と海外の委託先では品質の捉え方が異なるため、海外の開発会社では異常ケースへの対処が不十分なこともありますが、こういったことをカバーすることが期待できます。
この取り組みは、「鉄則１：バグを作り込まないで最初から正しく実装する」ことを狙ったものです。
② 開発の初期段階で合同レビューする
念を入れて仕様書を作成しても、言語の違い、慣習や商習慣の違いから、こちら(発注元)の意図を正確に伝えられていないことも想定しておく必要があります。
これに対処するため、発注元・委託先で早期にレビューすることが有効です。
このレビューは、早い段階で行うことがポイントです。委託先の設計書がまだ作成の途中でも、とにかく早めにレビューしましょう。
早期にレビューする狙いは、いわゆる「ボタンのかけ違い」を早めに検出して軌道修正することです。最初に大きな認識違いがあったり、ソフトウェアのアーキテクチャに大きな考慮モレがあったりしたとしても、早期の段階であれば、手戻りは最小限で済みます。
この取り組みの狙いは、欠陥を見つけ出すことよりも、むしろ軌道修正を早期に施すことで「鉄則１：バグを作り込まないで最初から正しく実装する」ことを狙ったものです。
③ 計画をレビューし計画どおりに行われることを見届ける
受け入れテストは、あくまでもサンプリングになるケースが多いです。そのため、受け入れテストの前に、委託先で十分なレビューやテストを行ってもらうことが重要です。
委託先でどんなレビューやテストを実施してもらうか、事前に指針を発注元で示しておき、それに沿って委託先で具体的な計画に落とし込んでもらいましょう。
また、レビューやテストの観点・範囲の要望は、委託先にあらかじめ伝えておくと良いでしょう。例えば、異常ケースはどこまで想定してレビューしておくか、などです。
加えて、委託先が立てた計画が、計画倒れになってしまったり、表面的な取り組みになってしまったりしないように、レビューやテストが計画どおりに実施されているか、発注元で定期的に見届けることも重要です。
この取り組みは、「鉄則2：作り込んだバグは可能な限り早い段階で検出して修正する」ことを狙ったものです。
更に踏み込むと、委託先で行ったレビューやテストから、どんなバグが検出されたか分析し、他に同様のバグがあることを疑って対策してもらうことも有効です。実際の運用の仕方としては、委託先から分析・対処の状況を定期的に報告してもらう形にするのが良いでしょう。ただし、発注元は委託先からの報告内容を鵜呑みにしてはいけません。ポイントとなる部分は裏付け調査するなど、慎重さを持つことが重要です。
まとめ
オフショア開発には、人件費が安く技術力の高い人材に開発工程を委託できるメリットがあります。
しかし一方で、言語や文化の違い、物理的な距離などの要因により、コミュニケーション齟齬が起きやすいという壁もあります。
オフショア開発を成功に導くには、オフショア開発ならではの課題とリスクを洗い出し、問題が起きる前に対策しておくこと重要です。
具体的には以下の3つのポイントを押さえておきましょう。
- 仕様を曖昧にせず、明確に具体的に提示する
- 初期段階でクライアントを交えて合同レビューする
- 計画をレビューし計画どおりに行われることを見届ける
発注前にきちんと準備して、オフショア開発を成功させていきましょう。
