オフショア開発の運営ノウハウ

はじめに

　 　私は株式会社テンダのジーワナと申します。前回の記事では私の背景や照会を記載させて頂きましたのでご興味ある方は以下①のリンクからご確認お願いいたします

　　前回投稿した記事では①オフショア開発になくてはならないモノ、②オフショア開発欠かせないブリッジSEの役割と体制について述べておりますのでご興味ある方は下記のリンクよりご確認お願いいたします。

リンク：①．https://qiita.com/Jeewana/items/41d453ab3a371802bb4b

　　　　②．https://qiita.com/Jeewana/items/32e93917c4f4d017d840

　　日本ではオフショア開発と言いましたら成功するかどうかの心配は持っている方まだまだ多いと思います。主にそのご心配されている方、オフショア開発を始めてご検討している方やオフショア開発についてご興味がある方向けに本記事では実際にオフショア開発プロジェクトを開始～運営～終了までのプロセスについて私の20年間以上の経験を基にご説明をさせて頂きます。

オフショア開発プロジェクトの開始～終了までのプロセス

１．オフショア開発に適した案件かどうかの判断

　　オフショア開発を選択する場合には、オフショアに関しての向き不向きをあらかじめ確認し把握しておくことがとても大事です。

オフショア開発に向いている案件のタイプ　例：

・現地（オフショア開発先）でも共通して仕様がイメージできるシステム・アプリ：

　　オフショア先でも利用されているような世界的に一般的な定番プロダクト（ECサイト、予約サイト、コーポレートサイトなど）

・難易度が低いシンプルなプロダクト：

　　仕様が複雑ではない、プログラムのロジックなどが単純ものであれば説明や情報コミュニケーションでの勘違い、間違いなどが起こりにくい（データ分析や計算系が中心となるロジックがシンプルなAI関係やR＆D案件）

・変化に柔軟に対応できるアジャイル系開発：

　　仕様が完全に固まっていなくてもその都度確認しながら開発を続けていけるような案件

・大規模・長期的な案件：

　　人月規模が大きいプロジェクトの場合はオフショアするとコストパフォーマンスが良い、開発先がプロジェクトの要件や仕様などの理解を得るにも一定の時間が必要となるのでその時間を確保しやすいし長期的に同じ案件をやることによってノウハウが蓄積されて開発スピードや効率も上がる。

３．オフショア先の企業とチーム体制の決定

　　オフショア先の国・地域を決定後にどのような会社と取引をするのかが課題になってきますがそこで以下のことを最低でも考えるべきでしょう。

・企業について審査を実施：

　　日本の場合は企業の審査を行える信頼できるサービがスありますが海外の場合は日本大使館、JETROやその国に既に入っている日系企業から情報を調べるのが確実だと思います。

・オフショア実績、得意分野、技術力と専門知識：

　　会社によっては得意分野や技術領域などが違ってきますし日本とのオフショア実績がある会社ならメリットが多いと思います。

・ブリッジSEの有無：

　　共通言語が使えるブリッジSEがいることがマストですので必ずチェックしましょう。

・情報セキュリティー（ISO27001）：

　　日本と比較するとほとんどのオフショア先の国々では情報セキュリティーについての意識が不十分との認識を持った方が安全です。ISO27001等資格を持っていればある程度でも安心できると思います。

・品質への取込み：

　　品質に関しても、情報セキュリティーよりも日本とのギャップが激しいとのこと認識した上で育成計画を必ず考えたほうが良いと思います。

・規模と柔軟性：

　　会社の規模が大きければ大きいほど柔軟性が減っていく傾向ですが案件によって適切な規模の会社を選ぶ必要があります。

・契約条件：

　　海外の場合、会社間の基本契約などの条件、万が一裁判などが発生した場合に同のように対応するのかなどを事前に考えておいた方が良いでしょう。

オフショア先の企業を決定後にチーム体制と契約形態も案件に適したものにするため下記のポイントを取上げたいと思います。

・プロジェクトで必要とされる技術とスキルセット：

　　プロジェクトの各段階に必要な人的リソースを必要な時点で割り当てられるようにプロジェクト開始時に計画すればスムーズにプロジェクトを実行できると思います。

・ブリッジSEの日本語とコミュニケーション能力：

　　共通言語が日本語の場合はオフショア先のブリッジSEの日本語能力やコミュニケーションツールがキーとなるので体制を考える時にバックアッププランも含めて考えたほうが良いでしょう

・単価と過去経験：

　　単価が安ければ安いほどコストが下がりますが、その場合は能力やスキルレベルも低いエンジニアになり実開発に大きな影響を及ぼすことになってしまう。
単価がより低いエンジニアを選ぶではなく、能力、スキルと単価のバランスをよく考えた上で決定するのが重要。

・面談実施（必要に応じて適正テストや技術テスト）：

　　初めての海外の企業が紹介するエンジニアをそのまま契約するよりあらかじめエンジニアの能力とスクレベルや性格などについて日本側でも確認することするべきでしょう。

４． 法的手続き、会社間契約とリソース・プロジェクト関係契約

　　会社間の基本契約や機密情報保持契約などが重要で、さらにプロジェクト運用にあたって個別契約やリソース関係で請負・ラボ契約も必ず結ぶ必要がある。契約類に関しては専門法律事務所などをコンサルするのは間違えが少ない、リスクも低いやり方になります。
　　オフショア開発の場合のリソースとの契約形態はほとんどの場合はラボ又は請負契約となります。契約形態の考え方としては日本の場合と同様ですがオフショアの場合はそれぞれ特徴があります。

・オフショアの場合請負契約対ラボ契約について

　 ラボ契約：ある一定期間、オフショア先の優秀なエンジニアを一定数確保してシステム開発プロジェクトを進めることができる契約です（契約形態は準委任契約と一緒）

　 特徴：コストをおさえながら一定期間優秀な人材を確保可（継続的なシステム開発業務が見込まれている、自社の開発リソースが足りない等の場合）。仕様が明確に決まっていない、あるいは仕様変更が多いことが見込まれる場合に適切です。業務知識や開発プロセスなどのノウハウを発注先（オフショア先）でも蓄積してもらいながら長期的に効率的な開発を行えます。

　 請負契約：請負契約とは、契約で定められた納期・工数に基づいて成果物を納品する契約です。発注時の仕様・要件定義に基づいて開発プロジェクトを進めていくため、発注者は開発プロセスに関わることはあまりありません。

５．オフショア開発関係インフラを整える

　　現状になって世界中に在宅ワークが一般的になったおかげでリモートワークに必要なインフラも高性能と安価で手に入るようになっています。オフショアの場合はプロジェクトにどのようなツールをどのような目的で使うのかをプロジェクト開始前に明確にし、使える環境を整えるのが重要です。

・そこで以下のツールが重要と考えられる

　　　　ビデオ会議ツール：Microsoft Teams, ZOOM, Google Meet
　　　　コミュニケーションツール：Slack, Chatwork, Mattermost
　　　　プロジェクト管理ツール：Backlog, Redmine, Asana, Jira
　　　　バージョン管理ツール：Git, Subversion

・日本との接続方法（VPN等）やソースコード、成果物や資料など置くサーバ環境なども明確にする

６．プロジェクトキックオフ＆運営開始

　　オフショアプロジェクトの成功に直接関係するのはコミュニケーションを含めたマネージメントのやり方となります。ブリッジSEの役割になりますが、日本国内のプロジェクトマネージメントの場合のやり方の違うところを中心に取上げます。

　 １．オフショア先の国の文化や国民性を理解する：
オフショア先チームとの信頼関係を深めるためや同じチームの仲間として指導や行動するためとても重要です。

　　２．ルールを決めて一緒に守る：

　　　・進捗状況を日々確認とチーム全員へ共有する、従って認識違いなどが発生していてもより早く気付くことができ対策が可能となります。

　　　・チームメンバ間でどの情報がどのタイミングに、どのように共有するのかなどをルール化して全員で実施。チームメンバへの作業依頼・詳細機能仕様などが日本側のブリッジSEからオフショア先のブリッジSEに伝え、その場でほかのチームメンバにも説明し正しく理解できたこと確かめることが重要です。

　　　・「報連相」を実施、チームメンバ間の開発関係以外でも（お休み計画等）課題・相談事項などがあるまま進むことを避けることによりプロジェクトがスムーズに進める環境を作ることができます。

　　３．タスク管理：日本では当たり前ですがオフショア先の社会によっては慣れていない場合が多く、目的や運営方法について説明した上で監視しながら実現する必要があります。

　　４．品質改選と意識開拓：成果物を作成する最初の段階から確認したり、指摘修正したりを繰り返しながら日本側で求める品質レベルについて育成するとともに品質向上と石開拓を継続的に実施すると長期的にメリットが多いです。

７．納品受け入れ、プロジェクト完了、オフショア開発チームの解放

　　日本国内のプロジェクトと同様にオフショアの場合でもプロジェクトの納品受け入れ後にプロジェクト契約に基づいてプロジェクトを完了することによってオフショア開発チームも解放することになります。

　　繰り返して同じ会社にオフショアすることによって同じメンバーも繰り返して使えるのでお互いやり方やコミュニケーションなどのノウハウが蓄積されて長期的にオフショアと言うハードルが徐々に低くなってしまうではないかと思います。

まとめ

　　オフショア開発に関して日本は米国や欧米より遅れていればその主な理由は言語の壁と文化や商習慣的な激しいギャップに違いないと思います。状況はそれであっても日本のIT人材の状況や経済発展などを考えればオフショアをやらざるおえない状況になりつつあります。

　　日本ではオフショアの失敗事例も多数あるかもしれませんが失敗は成功のもととなるので今までの失敗の原因や対策を確認しながら遅れず、着実にオフショアを成功させるゴールに向かって力を合わせましょう！