システム開発におけるオフショア開発の手法は、年々採用されることが増えてきました。オフショア開発が未経験のエンジニアにとっては、オフショア開発がどういうフェーズを担当するのかが気になりますよね。
今回の記事では、オフショア開発が誕生してからの担当フェーズの変遷を振り返り、現在のフェーズ例とオフショア開発の最先端事情および今後について解説します。一連の流れを理解し、今後オフショア開発に参加する際の参考にしてください。
目次
オフショア開発とは
オフショア開発（Offshore Development）とは、主としてITシステムやソフトウェア、アプリケーションなどの開発業務の一部を、海外（offshore）の受託開発企業を活用して行う開発手法です。
Thank you for reading this post
委託される業務は、基本的に下流工程がメインです。委託している開発企業のクオリティが高く、かつコミュニケーションの問題がクリアできれば、上流工程も含めて委託することもあります。メリットとしてはコストパフォーマンスが良い、リソースが確保できるなどがあります。
現在、オフショア開発はアジア諸国を主に相手国にしています。多くの企業がこれまでに中国、インド、ベトナムなどでのオフショア開発にトライし、成功と失敗の数々の経験が情報として蓄積されました。オフショア開発委託歴10年を超えるベテランの企業から、ピンポイントの領域に特化した新興のオフショア企業まで、多種多様なタイプの企業が登場しています。選択肢が増えることで、オフショア開発のハードルは低くなってきました。
そうやって近年ではオフショアの活用の仕方も多様化し、オフショアの受託開発企業の方にも時代に応じた変化が見られ始めています。
オフショア開発が生まれた背景
オフショア開発が誕生した背景には、IT業界の利益構造の大きな変化という要素があります。オフショア開発手法の歴史は古く、1980年代の終盤にすでに登場していました。IT業界が大きく成長した1960年代から1980年代にかけては、コンピューターシステムの中心はメインフレーム（ホストコンピューター／汎用機）が主流でした。IT企業群はホストコンピューターやオフィスコンピューターなどの高価なハードウェア機器の製造および販売、企業への導入などを扱うことで利益の大部分を上げてきました。
しかし当初は主流ではなかったPC（パーソナルコンピューター）がみるみる小型化、高性能化し、価格も下がって普及していくにつれ状況が変わります。インターネットを民間企業や一般ユーザーが使い始め、サーバーも普及して行く中で、コンピューターシステムはオープンシステムに主役が移り変わり始めました。やがて開発方法も従来のメインフレームを用いる汎用系だけでなく、オープンシステムを活用してPCで行うオープン系の開発も増えていきます。ハードウェアで上がる利益が徐々に圧縮されるに従って、ITシステムやソフトウェア、アプリケーションの開発と導入による利益で補うようになりました。
ところが1990年代に入ってバブルが崩壊し、大手ITベンダーも厳しい経営困難に襲われます。その中で、プログラマーやエンジニアを採用する人件費も抑制せざるを得なくなりました。とはいえ開発を手がけなければ、さらに経営が困難を極めます。そこで国内においてプログラマーやエンジニアを確保する代わりに、人件費が大幅に安いアジアに目を向けます。そういった一連の流れが、後のオフショア開発が生まれる背景となりました。
オフショア開発の起源
大手ITベンダーはそれまでの国内での技術人材確保に代えて、安価で潤沢な労働力を求めてアジアに子会社を作り、開発拠点の移動を図りました。その結果、中国やインド、ベトナム、韓国、フィリピンなどに、ITシステム開発を受託できる企業が多数操業するようになりました。
バブルが崩壊しようと時代はITの進展を後押しし、大手IT企業だけでなく中堅、中小のシステム開発企業、いわゆるシステムインテグレーター（SIer：エスアイヤー）が続々と生まれ、システム開発が活発化します。業界の多重下請け構造が形成されていき、下位の企業ほど低単価の開発案件を受けざるを得ない状況も生まれました。並行して、大手ITベンダーがアジアに作った多くの子会社に、低単価で一部の工程を依頼するシステムインテグレーターも出てきます。それがオフショア開発の起源です。
上昇するオフショア開発の付加価値
2000年代の後半あたりから、コスト効率を確保しながら開発プロジェクトを完遂するアプローチとして、オフショア開発が再び注目を集めています。特に近年の少子高齢化の影響を受けた慢性的なIT人材不足は、オフショア開発が見直されるきっかけとなりました。
そして最近ではかつてほどのコストメリットはないにせよ、技術レベルも国内の受託開発企業と比べて遜色なく、行き違いも減少しています。そのため、オフショア開発の付加価値は、以前に比べて高まってきていると考えてよいでしょう。それを裏付けるように、年々オフショア開発の活用事例が増えてきています。
オフショア開発の担当フェーズの変遷
オフショア開発で委託する開発フェーズは、黎明期から何度も変遷を繰り返して現在に至ります。ここではオフショア開発を理解するために、開発の基本となる7つのフェーズを確認したうえで、担当フェーズの変遷を解説します。
開発の基本7フェーズとは
多くのシステムインテグレーターに共通する、開発の基本7フェーズは以下の表のとおりです。
| フェーズ名称 | 作業内容 |
|---|---|
| フェーズ1：要求分析 | クライアントの要求をヒアリングし、システムに落とし込むためのモデリングを実施する。 |
| フェーズ2：外部設計 | 論理設計とも呼ばれ、ユーザーインターフェースや操作を設計する。 |
| フェーズ3：内部設計 | 処理ロジックを意識において、稼働できるプログラムを設計する。 |
| フェーズ4：プログラム開発 | 実際に設計書にもとづいてコーディングし、プログラムを開発・実装する。 |
| フェーズ5：単体テスト | プログラム単位で基本的な仕様に沿って動作するか、エラーがないかを確認する。 |
| フェーズ6：結合テスト | 一緒に稼働させる他のプログラムと連携させて、正常に動作するかを確認する。 |
| フェーズ7：受入テスト | 実際にクライアントが業務で使う想定でテストを実施し、包括的に問題がないかを確認する。これをクリアできればリリース可能となる。 |
細かい部分では開発案件によって順序が変化したり、他のフェーズが入ったりする場合もありますが、基本的にはこの7つのフェーズが代表的なシステム開発の流れです。川の水が滝に落ちるのに例えて「ウォーターフォールモデル」とも呼ばれます。フェーズ1から3までが「上流工程」、4以降が「下流工程」として区分されます。
紙情報の電子化の時代｜1988年頃〜
ここからはオフショア開発の黎明期から、担当フェーズがどのように変遷してきたかを見ていきましょう。
まず、もっとも初期の1988年頃は、紙の情報を電子化することに多大な労力を必要とした時代です。この時代のオフショア開発の担当フェーズは以下の4つです。
フェーズ4：プログラム開発
↓
フェーズ5：単体テスト
↓
フェーズ6：結合テスト
↓
フェーズ7：受入テスト
この頃のオフショア開発では、4つのフェーズすべてにおいて、紙に記載された情報をデータ化する入力作業がメインです。それに対応するために安い人件費で多くの人員を起用して、人海戦術による開発サポートを展開しました。多くの人員による大量生産を展開した結果、この時期からしばらくはコンスタントに莫大な利潤を獲得できる時代となりました。
バッチ処理の時代｜2001年頃〜
2001年頃になると、オフショア開発の担当フェーズはフェーズ4のプログラム開発がメインとなります。この頃は、オフショアが担当する部分も手作業による膨大なデータ入力業務が収束して、開発作業がメインとなってきました。
とりわけ、量が多くてリスクが少ない「バッチ処理」の部分をオフショアの受託企業にメインで委託するようになります。バッチ処理とはデータごとに個別に処理を行う非効率さを避けるために、一定量もしくは一定期間のデータを集め、一括で処理する方法です。
バッチ処理以外にも、コーディングやフェーズ5の単体テストの実務も発注されました。しかしながらクオリティ的にはまだまだ改善の余地が多く、単体テストの発注はあくまで散発的なものにとどまっています。
下流工程全般の時代 ｜2004年頃〜
2001年頃になると、オフショア開発の担当フェーズは以下の2つがメインとなります。
フェーズ4：プログラム開発
↓
フェーズ5：単体テスト
技術が向上していき、バッチ処理だけではなく下流工程であるプログラム開発工程を全般的に委託するようになりました。オフショア開発が期待され、任せる範囲を広げたものの、コミュニケーション上の問題が表面化します。認識の齟齬によるミスが増えて工数が無駄に増え、期待されたコストパフォーマンスの実現は困難でした。
多くの部分を任せていたため、ミスが増えることによって日本側での手直しも増えました。その結果として、納期の遅れやコストの無駄遣いなどの大きな課題が生まれます。そのために、この頃からしばらくは、オフショア開発はリスクが大きいというイメージがつきまとうようになりました。
内部設計から結合フェーズの時代｜2008年頃〜
2008年頃になるとオフショアの受託開発企業は、設計の一部である内部設計や、単体テストの後の結合テストまで、広範囲に受託する時代が来ました。この時代のオフショア開発の担当フェーズは以下のとおりです。
フェーズ3：内部設計
↓
フェーズ4：プログラム開発
↓
フェーズ5：単体テスト
↓
フェーズ6：結合テスト
オフショア開発委託企業の方でも人材は育ち、実績も蓄積されてきて成果物に信頼性がもたれるようになります。リスクが減ってきたので、ダイナミックにコストダウンを実現するために、オフショアで行うことを前提とした開発案件が増えました。
内部開発から結合テストに至るまでの主要フェーズを、オフショアチームに委託することによって、日本側の工数をできるだけ絞り込みました。それによって、オフショア開発ならではのメリットが享受できる時代になったのです。
上流から下流に至る全フェーズの時代｜2018年〜
2018年頃から現在に至るまでの数年間は、オフショア相手国それぞれの技術やコミュニケーションレベルが向上した期間です。上流工程から下流工程まで、ほとんどの作業を委託できるオフショア受託企業も増えてきました。
この頃に入れば、オフショアチームも、もはやオンショア、つまり国内での開発と比べて遜色がないレベルの成果物を仕上げてくることが珍しくなくなってきました。コミュニケーションレベルも上がっているので、ローリスクでハイパフォーマンスが得られるオフショア開発を活用するシステムインテグレーターが増えています。
残された課題は英語によるコミュニケーション
もちろん、まだ課題はあります。残された課題は、さらなるコミュニケーションレベルの向上を目指すために、日本側が通訳やブリッジSEを介さずに直接英語を用いてコミュニケーションを取ることです。それができれば、品質面とコスト面、そして効率面の3面で得るものがたくさんあります。やりとりはスピーディに進み、認識の齟齬も減らせて成果物のクオリティは向上する可能性が高いでしょう。
オフショア開発を英語で行うことのベネフィットや、そうするための勉強法について、以下の記事で特集しています。そちらもぜひご参考にご覧ください。
現在のオフショア開発のフェーズ例
現時点での、オフショア開発の担当フェーズがどのようになっているのか、目安としてのフェーズ例を紹介しましょう。流れとしては以下のようになります。
フェーズ1：キックオフ
フェーズ2：仕様決定
フェーズ3：開発・実装
フェーズ4：テスト・修正
フェーズ5：リリース
それぞれのフェーズを、順を追って解説しましょう。
フェーズ1：キックオフ
フェーズ1は開始の合図です。プロジェクトの冒頭であるフェーズ1のキックオフは、そのプロジェクトの成功を左右する重要な場面です。キックオフのミーティングは、オンラインによる場合と現場日本側の担当者が赴いて行う場合もあります。いずれにせよこの段階で詰める部分をしっかりと詰めておかなければ、その後のトラブルの素になりかねません。
ポイントは、いきなり本題に入るのではなく、アイスブレイクなどにより人間関係を順当に築いておくことです。信頼関係が薄ければ、遅れやミスに適切な対応がとれなくなるリスクが生まれます。また、守るべきルールやチームとしての目標を明確にしておくことも重要です。最初の時点で関係者全員が正しく同じ方向を向くと、その後の進行もやりやすくなるでしょう。
フェーズ2：仕様決定
フェーズ2は発注する案件に必要な機能を仕様書に落とし込み、実装できる状態に持っていく作業です。一般的な仕様書よりも丁寧に作ったり、図やイメージ画を添えたりして認識違いを避けるように配慮するのが賢明でしょう。
開発案件の場合は、遷移図やUI（ユーザーインターフェース）、ワイヤーフレームなどをきちんと作っておくことで、わかりやすく意匠性が高い成果物が期待できます。現地の現場にプロジェクトマネージャーがいるなら、連携を取りながら進めるとクオリティを確かなものにできます。
フェーズ3：開発・実装
フェーズ3はいよいよ本格的な開発・実装の局面です。実際の作業はオフショア受託開発企業のエンジニアに任せるので、日本側の作業量はあまり多くありません。それでも気を抜かずに、プロジェクト進捗を注視することが大切です。
何か疑問点が出てきたり、進捗のスピードに遅れる兆候があったりする場合には、速やかに対応して改善しなければなりません。現場に任せていては、後から厄介なトラブルに見舞われかねないでしょう。常にオフショアの受託開発企業と連携して開発を進めるスタンスが、トラブルを最小限に止める確実な方法です。
フェーズ4：テスト・修正
開発工程が終わり、設計されたプログラムの実装が完了すると、単体テストおよび結合テストというテスト工程と、それに伴う修正が行われます。レベルが高い受託開発企業の場合は、開発者にテストを依頼できます。また、品質向上のために開発者とは別のテスターに委ねるのもよいでしょう。
テストにあたっては国によって動作環境が異なるケースもあるので、その辺りの配慮も必要となります。想定している使用環境やデバイスの機種に問題がないかを充分に確認して、テストおよび修正作業を進めましょう。
フェーズ5：リリース
テストと修正のフェーズが終了すると、いよいよリリースです。リリース後はクライアントやユーザーの反応をみながら、必要に応じてフィードバックします。一度委託したオフショア受託開発企業について、品質やコミュニケーションレベルに満足した場合は、その後の開発でもパートナーシップを続けることで一層の品質向上につながるでしょう。
以上が現在のオフショア開発における、平均的なプロジェクト進捗の流れとなります。それぞれのフェーズにおいてポイントを押さえて進めることで、成功の確率が高められるでしょう。
オフショア開発の最先端と今後
最後にオフショア開発の最先端の事情と今後について、触れておきましょう。
進化するオフショア受託開発企業
最近のオフショア受託開発企業で進んでいるところは、設計フェーズから委託できます。そのため、より大きなコストの削減ができるケースがあります。設計と開発・実装を一貫して担うことによって、認識の齟齬のないハイクオリティな成果物を提供する企業が続々と登場しました。
また、そういう企業は設計フェーズで作成されるすべてのドキュメントに関して、先方の日本人プロジェクトマネージャーが、現地で綿密なチェックを行います。その結果、国内での開発と遜色ないクオリティの維持が可能です。そういう企業はその他の受託開発企業よりもコストは上がりますが、国内での開発よりは抑えられます。リスクは少なくて品質面において信頼できるので、委託する価値があります。
開発対象のスケールアップ！
オフショア受託開発企業に委託される開発内容に関しては、従来からもっとも多かったのはWebシステムやモバイルアプリの案件です。とりわけコロナ禍による社会情勢の変化、飲食店の営業制約、企業の営業や会議のオンライン化、リモートワークの増加などの影響で、Webサービス開発とECサイトのアプリ開発が飛躍的に増加しています。オフショア受託開発企業にはそれらを得意分野とする企業が多く、今後もオフショア案件の一定のシェアを占める可能性があります。
一方、2020年あたりから急増しているのはオフショアで基幹系システムの開発を行うプロジェクトです。基幹系システムは大規模であり、システムがカバーする領域も大きく、開発チームには充分なスキルと経験が必要です。従来では、基幹系システム開発といえば国内での開発がほとんどでした。しかし、オフショア受託開発企業も規模が大きくなり、基幹システムの開発にも対応できるようになりました。そのため、この分野もオフショアに持っていくケースが急激に増加しています。
オフショアに期待できる今後の活用法とは？
オフショア受託開発企業の傾向のひとつに、アメリカを中心に世界の最先端技術を積極的に取り入れることがあります。いち早く新しくて良いものを取り入れることで、多種多様な分野での、新しいビジネススタイルの知見も身につきます。そのポテンシャルを活用するためには、従来の委託先という位置付けから、共同開発のビジネスパートナーとして提携するようなアプローチも必要です。
さらにいえば、ブロックチェーンやAIなどの開発については、むしろオフショア受託開発企業の方が国内のIT企業を凌駕している場合があります。とりわけベトナムではAIエンジニアが多く輩出しており、今後さまざまなシステムでの活用が期待できます。日本側としては最新のビジネスプラットフォームや先端技術を、オフショア開発を通して取り込むことが、今後の有効な活用法のひとつといえるでしょう。
まとめ
オフショア開発は、ITの進展とともにさまざまな形態に変化しながらも、絶えることなく存続し、現在では存在感を増しています。多くの開発フェーズを担えるようになったオフショア開発ですが、残された言葉の壁を日本側が英語を用いることで解決した時には、品質、効率、コストにおいて最強のタッグチームとなるでしょう。
今後オフショア開発に関わる可能性があるみなさんは、ここで紹介した情報を参考に良好なパートナーシップを結んで価値ある開発を進めてください。
