こんにちは、スクーティー代表のかけやといいます。
私は2012年にベトナムに渡り、以降、100以上のオフショア開発プロジェクトに様々な立場で関わってきました。
その経験から、今後オフショア開発を検討されている皆様に、オフショア開発時のポイントをお伝えしたいと思います。
本記事では、新規サービスの立ち上げや、社内の新システム立ち上げなどで、サービスローンチまでに必要な機能を作りきるプロジェクトでのポイントについてお伝えします。
その前の段階の、契約締結の手続きやプロジェクトのはじめ方に関する注意点に関しては下記の記事を、
既存システムの継続的な機能追加や運用・保守に関しては、下記の記事をご覧いただければ幸いです。
オフショア開発開発でよくある業務の種類
オフショア開発では、主に下記の2パターンの業務を委託されるケースが多いです。
①継続的な業務
すでにあるシステムの継続的な機能追加開発を、一定の開発者リソースを確保して行うケースです。この場合は基本的にラボ型開発で行い、日本国内のエンジニア採用の代替手段としてご利用されるお客様が多いです。
また、オフショアチームで複数のシステムを担当する場合もあります。
②プロジェクト単位の業務
新規システムの立ち上げるプロジェクトで、リリース日が決まっているものです。契約は請負契約の場合もありますし、ラボ型契約の場合もあります。
契約時点で要件が明確になっている場合は請負契約で進めることが多いですが、契約時点で仕様が決まっておらず、決まったものから随時開発を進めていきたいという場合も多く、その場合はラボ型開発で進めます。
最初のローンチが終わったあとは、継続的な機能追加開発や保守フェーズに移行することが多いです。
本記事では、上記 ②プロジェクト単位の業務 を対象としています。①継続的な業務 のケースは別の記事でお伝えしたいと思います。
０．要件と業務範囲の確認
NDA締結後、業務委託契約締結前に、開発会社は要件、業務範囲とスケジュール（リリース希望日）の確認が必要になります。
請負契約の場合、まずこの要件と業務範囲が決まらないと見積もりと契約ができません。
ラボ型開発の場合も、チーム体制を決めるために、開発会社は開発ボリュームとスケジュールを知る必要があります。
したがって、お客様から開発会社へは下記のような情報提供が必要になります。
- 要件定義書
- 機能要件定義
- 非機能要件定義
- 業務要件定義
- 基本設計書（もしあれば）
また、業者選定にあたり、複数業者から相見積もりたい場合は、RFP（Request for Proposal）をお客様の方から提示し、業者からの提案時に必要な情報が提示されるようにコントロールするケースもあります。
１．プロジェクトキックオフ
プロジェクト単位の業務の場合、そのプロジェクトが終わったらプロジェクトチームは基本的に解散します（ラボ型開発で、リリース後も継続的に機能追加を行っていく場合は、チームが継続することもあります）。
ですが、数ヶ月に渡って同じ目的を持って一緒に働いていくメンバーですので、しっかりとプロジェクトキックオフを行い、チームメンバーを認識し、プロジェクトのゴールを共有するのがいいでしょう。
キックオフのコンテンツは、「初めてのオフショア開発はどうやって始めたらいい？（プロジェクト立ち上げ）」をご覧いただければと思います。
２．全体計画作成
一般的には開発チームがWBSを作成し、プロジェクトを完了するために必要な全ての業務の洗い出しと、それらを誰が、いつ着手し、いつ完了するかを明確にします。
契約時に全ての要件が明確になっている場合は、このスケジュールをマスタースケジュールとして、その計画に沿って進めることになります。
一方、契約時には要件が固まっていない部分があって、ラボ型開発で進めている場合、当初のスケジュールは不明確な情報をもとにした概算見積もりから作られます。
したがって、プロジェクトが進むにつれて、要件が明確になっていき、追って詳細見積もりをすることになり、その結果によってスケジュールは常に更新されることになります。
開発チームと常にタスクの優先順位を調整し、共有しながら、今あるリソースでローンチ日までに何をやりきることができるのかを常に監視し続けることが求められます。
３．実装業務を開始する
計画を作成したら、その計画に則ってチームは作業を開始します。
進捗の管理は上記「①継続的な業務」のケースと大きな違いはないので、そちらの記事をご確認いただければと思いますが、期限までに全て完了できるかどうかが重要なポイントなので、マスタースケジュールと実際の進捗の差分を常に追っていく必要があります。
開発チームには、日報や定例ミーティングなどで、マスタースケジュールと実績の差分を常に報告するように求めると良いでしょう。
４．オフショアチームの仕様の理解や成果物をこまめに確認する
プロジェクト進行中は、オフショアチームから頻繁に仕様に関する質問がされるはずです。窓口には一般的に日本語を話せる外国人通訳かブリッジSEが立ちますが、どうしても言語障壁があるため、彼らの理解が正しいかどうかの確認をこまめに取る必要があるためです。
中には細かい質問もあり、回答するのが面倒に感じるかもしれませんが、逆に質問の内容を見ることで仕様に関する理解度を測ることもできます。質問が細かいということは、仕様の理解はだいぶ進んでいるということが想像できます。
逆に、基本的なことを聞かれる頻度が高い場合は、全体的に仕様の理解が不十分であることが想像されるので、オンラインでレビューミーティングを持って、口頭で詳細に説明するなどの対処を取るのが良さそうです。
また、請負契約の場合、開発チーム側の業務が全て終わった後に検収期間がありますが、検収のときだけ成果物を確認するのはリスクが高いです。
もし仕様の認識相違があって、求める動作と全く異なるものだった場合、その手戻りが発生します。
開発会社には納品責任があるため、明らかに要件と異なるものに関しては追加費用は発生しませんが、仕様書に明記されていないものや記載が曖昧なものに関しては追加要件としてみなされ、追加費用が発生する可能性があります。
また、追加費用が発生する／しないに関わらず、新規サービスをリリースするための関係各所の調整が必要になったり、外部要因で絶対にずらしたくないリリース日に間に合わなくなる可能性も出てきます。
オフショア開発ではどうしてもコミュニケーションが難しくなるため、仕様を伝えたつもりだったのに蓋を開けたら全く違うものができていた、というリスクがあります。
こういった状況を作らないためにも、開発チームの成果物は最後の検収期間だけ確認するのではなく、できた機能から随時検証環境で確認しておいたほうが良いでしょう。
５．テスト
ローンチ後に本番環境で不具合が出ないように、慎重にテストをします。
単体テスト、結合テスト、運用テストだけでなく、セキュリティテスト、負荷テストなど、本番環境で起きうる事故を事前にできる限り挙げておき、それらを未然に防ぐための確認を行います。
どのようなテストが行うかは、システムやサービスの種類に依存するので、プロジェクト開始前に開発チームと議論して決める必要があります。
特に請負契約の場合、テストの種類を増やすと工数も増えるため、漏れがあると追加費用が発生してしまいます。
また、オフショア開発の場合、コミュニケーションギャップによる仕様の誤認や、仕様書の翻訳ミスなど、コミュニケーションに起因する不具合がリスクとして想定されます。
開発チームから、ソフトウェアの品質を定量的に評価したレポートを提出してもらい、客観的に、サービスローンチに耐えうる品質にあるという判断ができるようにする必要があります。
６．サービスローンチ
いわゆる伝統的なオフショア開発プロジェクトばかりを経験して、サービスをローンチするためにはどういう準備が必要か、ローンチ後はどのような体制が必要か、といった知見がない開発者や開発会社は多いです。
例えば、下記のような作業です。
- ドメイン、SSL取得
- 本番環境のオートスケーリングのテスト
- 監視設定と通知のテスト
- 障害発生時の連絡網作成
- ユーザーズマニュアルの作成（必要であれば）
- 利用規約、プライバシーポリシーなどの法務面の準備
- AppStoreやGoogle Playへの申請と、申請に必要な情報収集
- メンテナンスページ作成と、メンテナンスページ表示方法手順の作成
- など
これらの作業も、プロジェクト着手時に作成するWBSに含まれるべきですが、漏れている場合は開発チームと必要な作業を慎重に洗い出し、いつ着手して、いつ完了すべきかを事前に決めておく必要があります。
これらの慎重な準備を経て、いよいよサービスローンチとなります。
７．検収
請負契約の場合は、受け入れ条件を予め明確にしておき、全ての納品が完了したと判断できて検収完了となります。検収完了でもって、プロジェクトが終了となります。
