オフショア開発というと一般的には「品質が悪い」「バグが多い」「要件がちゃんと伝わらない」などのマイナスイメージを持たれる方も少なくありません。確かに低コストが魅力のオフショア開発ですが、品質に問題があるオフショア開発会社が多く存在するのも事実です。しかし、全てのオフショア開発会社がそのような問題を抱えているわけではありません。本ページではオフショア開発を成功に導くために、どのような観点でオフショア開発の発注先を見極めればよいのか、品質管理やプロジェクト管理をどのように進めれば良いかをご案内します。
まず、システム開発の品質向上に向けた取り組みの前に、オフショア開発を成功させるために乗り越えなければならない壁と、その乗り越え方についてお伝えします。さらにその壁を乗り越えた上で、どのようにシステムの品質向上を行っていけばよいのか、3つのポイントをお伝えします。
オフショア開発における3つの壁
オフショア開発を活用することによりコスト削減や開発要員確保など多くのメリットを享受できます。しかしながら、オフショア開発はメリットばかりではありません。オフショア開発を成功させるために乗り越えるべき壁は大きく3つあります。
言葉の壁
言語が異なるため、意思疎通を密に、かつギャップを出さずに行うのが難しい。
距離の壁
委託先の開発チームと直接会ってのコミュニケーション機会が限られる。またオフショア場所によっては時差がコミュニケーションの障害になる場合もある。
商習慣（開発習慣）の壁
品質管理、特に品質基準・レベルについての捉え方が発注者とオフショア先の間で異なる場合が多い。結果、発注側の品質基準が満たされないという事態が起こりやすい。
3つの壁の乗り越え方
システム開発において重要なQC（Quality Control：品質管理）やQA（Quality Assurance：品質保証）と言った品質管理の概念や施策を取り入れる前の大前提として、オフショア開発を行う場合には3つの壁を乗り越える必要があります。GICではこれらの壁を乗り越えるために、以下の施策を実施しています。
GICでは、オフショア開発先であるミャンマーのスタッフ全員に対し、入社前研修の時点(約入社6ヶ月前)から専門の日本語教師による日本語研修を実施しております。通常現地の日本語教師は現地人が多いですが、当社では日本人教師も現地に在住し、日本の語学学校で行うレベルと同等の日本研修を行っています。結果、入社1年目には開発エンジニアは全員、日本語検定N3レベル以上に達します。また開発リーダー、マネージャーは全員N1以上（日本語ネイティブレベル）で、プロジェクトチーム管理においても日本語サポートを全面的に実施しています。
オフショア開発先であるミャンマー現地オフィスには最速のFTTH回線を導入しており、ZoomやTeamsなどのオンライン・ビデオシステムやチャットなどの利用が可能です。昨今のコロナによるリモートワークが一般的になりつつありますが、日本のITベンダーと同様のオペレーションがオフショア開発先であるミャンマーでも対応可能です。また開発ツールは、GithubやSlackなどの一般的なサービスを標準として取り入れていますので、国内での開発環境と同様なものがそのまま利用出来ます。ツールの差異によるコミュニケーションミスも発生しません。
日本語の仕様書をベースにシステム開発を行う場合、オフショア開発先の窓口（ブリッジSE）はもちろん、プロジェクトにアサインされるシステムエンジニアや実際に開発を行うプログラマーも、日本の発注者側の業務やシステム、開発の進め方を理解し、日本語の仕様書を日本語のままで理解できることが、オフショア開発をコミュニケーションの齟齬なく進める上では理想です。
一般のオフショア開発会社では「窓口（ブリッジSE）には日本人が立つので、コミュニケーションや仕様書は日本語で問題ありません」といった内容が喧伝されています。一見安心なように見えますが、窓口のみに日本人が立つというプロジェクト体制には2つの問題があります。
1つ目は、やはり品質の問題です。ブリッジSEは日本人だとしても、結局日本人のブリッジSEが開発を進める上でコミュニケーションを取るのは、オフショア開発先の日本語がわからない多くの現地スタッフです。ブリッジSEが日本語の仕様書を英語に変換して、現地では英語ができるスタッフがそれを現地語に訳すなどしながら、現地語をベースにしたコミュニケーションを中心に開発が進んでいくため、コミュニケーションの齟齬が発生しやすいという状況は想像に難くないでしょう。
2つ目はコストです。そもそも低コストでおさめるためにオフショア開発を選択したはずが、窓口に立つのが人件費の高い日本人ではトータルでコスト高になってしまいます。
GICではこれらの問題をクリアするために、次のような対応を行っています。まず、ミャンマー現地のプロジェクトリーダーやプロジェクトの中心を担うメンバーは、全員が日本での就業経験が8年～10年以上で、日本の商習慣はもちろん、システム開発の進め方も熟知しています。窓口に立つブリッジSEも日本語検定N1（日本語の通訳ができるレベル）を基本としており、技術レベルも日本人同等ないしはそれ以上のスタッフをアサインしています。もちろんコストは日本人を起用する場合より遥かに安価です。「オフショア開発の価格帯なのに、まるで日本のITベンダーに開発を依頼しているようなスムーズなコミュニケーションや品質だ」という声をお客様からいただくことが大変多いです。
オフショア開発品質向上の3つのポイント
以上3つの壁を乗り越えることで最低限の品質の担保はできるようになりますが、、さらに品質を上げるためには以下のような施策を実行していく必要があります。
品質を作り込んでいく（品質を高いレベルで維持する）ためには、オフショア開発先だけでなく、発注側も一緒にシステム開発プロジェクトに取り組む必要があります。オフショア開発で失敗するパターンはいくつかありますが、典型的なものがオフショア開発先に開発を任せきりにする、つまり「丸投げ」のパターンです。これでは一緒に品質は作り込めないので、典型的な失敗パターンとなりえます。
システム開発で品質を作り込んで行くために一番重要な鉄則は以下3点で、これらはオフショア開発に限ったものではありません。
品質を高いレベルで維持するための3つの鉄則
品質管理でGICが最も重要視していることは、プロジェクト開始前や実施中、常に以上の3つの鉄則が把握・管理され、適切にプロジェクトが管理・コントロールされているかどうかです。そしてこのプロジェクトの管理・コントロール状況およびプロジェクト進捗を発注側と定量的かつリアルタイムに共有していくことが、プロジェクト管理において最もプロジェクトリーダーが気をつけなくてはいけないことになります。
この3つの鉄則を守り、プロジェクトを成功に導くために重要なポイントが3つあります。
オフショア開発の品質を向上させ、プロジェクトを成功に導くための3つのポイント
それでは、3つのポイントを具体的に見ていきしょう。
開発仕様を文章で明確に具体的に提示する
オフショア開発側、特に開発を担当するプログラマーにとって、開発を進める上では仕様書が全てのバイブルとなります。一般的に仕様書の行間を読むことは出来ません。詳細な仕様書の作成は、発注側にとってはコストと時間のかかる作業となりますが、後の製造フェーズのコストダウンや運用/保守フェーズで様々なメリットが出ることを考えると、プロジェクト全体ではコストダウンにつながります。仕様書作成フェーズのみを考えるので無くプロジェクト全体を考えるように発注側も「発注品質を高める」という意識改革をする必要があるかも知れません。
また、日本の発注元と海外の受注側では品質の捉え方が異なります。例えば、海外の開発会社では例外ケースへの対処が不十分なこともあります。正常系だけではなく、異常系の考え方やテストケースについても開発仕様として作りこみ、両社で認識を合わせる必要があります。
この取り組みは「鉄則①：要求仕様を明確に伝え、仕様の認識違いやバグが発生しないように実装する」という考え方にも通じます。
開発の初期段階で理解度の確認を含めた発注・オフショア側の合同レビューを行う
仕様書は、発注元の文化差や標準の違いもあり、念を入れて作成しても発注元の意図をオフショア開発先に対して正確に伝えられていない可能性もゼロではありません。このような認識の違いを防ぐ意味で、発注元とオフショア開発側で早期に合同レビューを行うことが非常に有効です。
このレビューは、発注元の仕様書作成が全て完了してから行うのでは無く、仕様書が2，3本出来た段階で行うことがポイントです。この時点で記載の仕方やレベルに修正が必要なことが明らかになれば、その後の仕様書の精度が高くなるからです。手戻りを最小にするためにも早期に合同レビューを行うことが非常に重要になってきます。
進捗確認・テスト計画を明確化し、計画通りの進捗と品質が保たれているかの確認を定量データに基づき行う
受け入れテスト計画を策定する場合、受け入れテストの前にサンプリングでテストを行うケースがあります。オフショア開発の場合は、サンプリングの時にある程度の量を受け入れて確認を行うというアプローチをとることが多いため、その点をテスト計画で考慮する必要があります。よくある「受け入れテストを行って箱を開けてみたら全然ダメだった」というケースを避けるためです。受け入れテストが始まる前に受注側で十分にサンプリングもしくは一定量のテストやレビューを行うことが重要となります。
受注側（オフショア開発先）でどんなレビューやテストを実施してもらうかなどのテスト計画指針を、発注者側はプロジェクト計画策定時に示しておきます。特に「異常系のテストはどこまで行われているか」「実装・結合テストが行われているか」がシステムの品質を大きく左右するので、予めテストケースなども含めてオフショア開発側と認識をあわせておく必要があります。受注側での受け入れテストやレビュー結果からどのようなバグ・問題が検出されたかを分析し、他にも同様のバグや問題が潜んでいないか、テストや確認を行うことも重要です。
また、品質管理においては重要なことは、品質メトリックスを定義し、プロジェクトの品質を定量的に測定し、品質の良し悪しを図ることです。GICでは、このように日々状況が変わるプロジェクトを客観的にかつ定量的にトラッキングしながらアクションプランを策定・実行していくことが、品質管理において重要なアクティビティだと捉えています。このアクティビティがプロジェクトリーダーや当社内の品質管理部門の大きな役割と定義してプロジェクトを運営・管理しています。
GICの品質管理と品質保証
品質を確保するためには、QC(Quality Control：品質管理)、QA(Quality Assurance：品質保証)の2つの考え方を取り入れながらプロジェクトを進行する必要があります。
プロジェクトが的確に品質管理（QC）を行っているかをレビュー・指導するのがQA（Quality Assurance：品質保証）の考え方ですが、GICでは社内の品質管理部門・スタッフが客観的な立場でQAレビュー等を行っており、品質メトリックス、プロセス/工程のイクジット・クライテリアを定めてプロジェクトの品質をメジャー（計測）することでプロジェクト全体の品質を高めています。
また、GICでは役員の出身母体でもある大手IT企業のQC/QAの考え方/適用方法を取り入れています。
GICは約10年間にわたってラボ契約および請負契約でオフショア開発プロジェクトを多数成功に導いて参りました。オフショア開発に興味のある方は、ぜひお気軽に以下からお問合せください。