オフショア開発はどういうプロセスで進められる？ 〜継続的な業務のケース〜
こんにちは、スクーティー代表のかけやといいます。
私は2012年にベトナムに渡り、以降、100以上のオフショア開発プロジェクトに様々な立場で関わってきました。
その経験から、今後オフショア開発を検討されている皆様に、オフショア開発でシステムの継続的な機能追加や運用・保守を進る際のポイントをお伝えしたいと思います。
その前の段階の、契約締結の手続きやプロジェクトのはじめ方に関する注意点に関しては
の記事をご覧いただければ幸いです。
オフショア開発開発でよくある業務の種類
オフショア開発では、主に下記の2パターンの業務を委託されるケースが多いです。
①継続的な業務
すでにあるシステムの継続的な機能追加開発を、一定の開発者リソースを確保して行うケースです。
この場合は基本的にラボ型開発で行い、日本国内のエンジニア採用の代替手段としてご利用されるお客様が多いです。
また、オフショアチームで複数のシステムを担当する場合もあります。
②プロジェクト単位の業務
新規システムの立ち上げるプロジェクトで、リリース日が決まっているものです。
契約は請負契約の場合もありますし、ラボ型契約の場合もあります。
契約時点で要件が明確になっている場合は請負契約で進めることが多いですが、契約時点で仕様が決まっておらず、決まったものから随時開発を進めていきたいという場合も多く、その場合はラボ型開発で進めます。
最初のローンチが終わったあとは、継続的な機能追加開発や保守フェーズに移行することが多いです。
本記事では、上記 ①継続的な業務 を対象としています。②プロジェクト単位の業務 のケースは別の記事でお伝えしたいと思います。
０．既存システムの情報収集
「①継続的な業務」のケースでは基本的に開発対象となるシステムが既に存在していることが前提となります。
したがって、NDAは締結済みで、業務委託契約前の段階で、まずはお客様からシステムに関する一通りの情報をご提供いただきます。
特にサーバ構成やソースコードの確認は重要で、どのようなスキルセットを持ったエンジニアを決めるために重要な情報となります。
また、次のマイルストーンとして、どのような機能をいつまでにリリースしたいのかも重要ですので、仕様書のご提供もいただきます。
１．チームの組成
頂いた既存システムに関する情報、毎月にかけられるご予算と、求められる開発スピードから、開発チーム側で最適なチーム体制を検討し、提案します。
オフショアチーム側の窓口となる通訳やブリッジSEのコミュニケーション能力や、アサインする開発者の技術力が非常に重要なので、事前に履歴書の確認やオンラインでの面談をされるお客様もいらっしゃいます。
２．ラボ型開発の契約締結、チームの立ち上げ
ラボ型開発の契約では、チーム体制が決まれば金額が決まります。
チーム体制が決まった段階で業者からは見積書が提出され、契約書の条件をご確認いただき、金額を含めた契約条件にご同意頂いた段階で契約締結に進みます。
業務開始初日には、全関係者が一同に介してキックオフをやることをおすすめします。
理想はお客様側のご担当者さんが、現地に赴き、オフショアチームと顔を合わせてキックオフを行い、その後ご飯を一緒に食べる時間を持つなどしたほうがチームの絆は強くなります。
ただ、近年のコロナの状況で海外渡航が難しいので、オンラインでのキックオフでもいいかと思います。
キックオフのコンテンツは、「初めてのオフショア開発はどうやって始めたらいい？ 〜プロジェクト立ち上げ編〜」をご覧いただければと思います。
３．既存システムの調査、学習
早速業務を開始しますが、いきなり開発業務を着手するケースは稀で、まずは既存システムの調査、学習から入ります。
サーバ構成、ソフトウェア構成、プロジェクトの進め方、ルール、ソースコードを書く際の作法、機能単位の完了条件、などを調査し、理解します。
これをきちんとやっておかないと、問題や障害を起こしてしまったり、ソースコードを見出してしまったりするリスクがあるため、チーム組成初期は学習期間が必要です。
学習期間は、開発チームが計画を作成し、お客様にご確認頂いた上で合意形成を取るのが良いと思われます。
４．実装業務を開始する
学習期間が終わったら実装業務を開始します。
継続的な業務の場合、スクラムプロセスで行う場合が多いですし、やりやすいと思います。スクラムプロセスの説明はここでは省きます。
まず準備として、お客様側のプロダクトオーナーが、開発が必要な機能をチケット（バックログ）として起票することが必要です。JIRAやBacklogのようなプロジェクト管理システムを使って開発チーム間でタスクやアサイン、進捗を管理することが多いです。
１スプリントは大体２週間で設定することが多いです。スプリントのはじめに計画ミーティングを行い、スプリント内で誰がどのバックログを担当するかと、そのスプリントのゴールを決めます。
スプリントの最後に、デモを行い、プロダクトオーナーにそのスプリントでできたものを見せます。
また、振り返りミーティングを行い、プロセスとして生産性を上げるための改善点を話し合い、次のスプリントで変えることを決めます。
計画ミーティングと振り返りミーティングはオフショアチーム内のみでやることもありますし、お客様含めてやる場合もあります。
そして、このサイクルを継続して、どんどん機能を追加し、リリースしていきます。
進捗や開発チームの状況の確認
オフショアチームは海の向こうにいて同じオフィスで状況を見ることができないため、コミュニケーションは意識して多めに取る必要があります。
一般的には下記のようなコミュニケーションを取りながら進捗の確認をします。
・開発チームから日報を送る
本日の進捗、明日の予定、課題があるかないか、などをチャットグループで報告します。
・オンラインミーティング
ZoomやMeetsなどのツールを使って、オフショアチームとオンラインでミーティングを持ちます。週に１回やるケースが多いですが、我々のお客様では、毎日やっているプロジェクトもあります。
・できた機能ごとに検証環境で確認
オフショア開発ではどうしてもコミュニケーションが難しくなるため、仕様を伝えたつもりだったのに蓋を開けたら全く違うものができていた、というリスクがあります。
それを防ぐために、できた機能を検証環境のサーバにアップし、お客様側で実際に操作して確認する状況を作ることが大切です。できたものを目で見ることができれば安心感が違います。
たとえ仕様と異なる動きをしていても、早期にフィードバックできるため、リリース直前に発覚というような状況にはなりません。
開発チームのパフォーマンスが良くない場合は？
ラボ型開発では、チームメンバーが非常に重要です。ラボ型開発は採用の代替手段ですので、ただの発注相手として扱うのではなく、オフショアチームの名前、顔、担当などを把握されることをおすすめします。
冒頭で述べたとおり、契約開始前に開発チームメンバーを選定するプロセスがあり、ベンダーはベストな布陣を提案すべきですし、お客様も慎重にメンバーを選ぶ必要がございます。
それでも、実際業務を始めると、プロジェクトの品質やスケジュールに影響を及ぼすほどの低いパフォーマンスしか出せないメンバーが出てくるかもしれません。
その場合は、メンバーの交代を依頼することができます。
また、開発チーム側も当然各メンバーのパフォーマンスを管理しているはずですので、開発チーム側からの提案で、メンバー交代を打診されることもあるかもしれません。
プロジェクトの出力が十分に出ない原因は様々なものが想定されるので、まずはチームで原因を話し合い、できれば既存のメンバーで継続的に改善をしていくのが良いかと思います。
それでも、原因が強く人に依存している場合は、メンバーの交代を検討することが必要になる場面もあるかもしれません。
最後に
今後も、オフショア開発を検討しているけどどのように始めたらいいか悩まれているような方や企業向けに、オフショア開発に関する情報を発信していこうと思います。
この記事は私が経営する株式会社スクーティーのコーポレートブログの下記記事を焼き直したものです。
もしお客様が管理されているシステムの継続的な機能追加や、運用・保守の委託先をお探しでしたら、ぜひお問い合わせください！