IT業界における“オフショア開発”とは、ソフトウェア開発をする際に、海外のIT企業や子会社に業務の一部を委託することです。プロジェクトの金銭的コストを抑える目的から、これまで多くの企業が中国やインド、ベトナムなどの人件費が安い国の企業に作業を依頼。IT分野においては1970年代から、オフショア開発の取り組みがなされてきました。
しかし、それから何十年もの歳月が流れ、様々なノウハウが蓄積されてきたにも関わらず、「オフショア開発に失敗した」という声は後を絶ちません。読者のみなさんの中にも、「自分の携わったプロジェクトでも、トラブルが起こって大変な思いをした」という方がいらっしゃるのではないでしょうか。
オフショア開発の失敗は多くの場合、国同士の文化の差異やそれに伴うコミュニケーションの難しさ。そして、契約や品質管理に対する認識の違いに起因しています。逆に言えば、それらのギャップを埋めることができれば、オフショア開発の成功率はグンと上がるのです。
今回は、アジア圏の企業とのオフショア開発を長年経験してきたエンジニアが、オフショア開発が上手くいかない原因、そしてその解決策を書いていきたいと思います。
異文化同士の認識のズレを避けるには、Q&A表で課題を共有し合おう
オフショア開発に携わったことのある方の中で、「想定していたのと全く異なる仕様のシステムが納品された」という経験をお持ちの方は多いでしょう。同じような文化的バックグラウンドを持っている日本企業同士で仕事をするときとは違い、全く異なる文化を持った海外企業と仕事をする場合には、認識のすり合わせを丁寧に行っていく必要があります。
例えば、データベースの複数のテーブルに、「会員ID」を表現するカラムが存在している場合、日本企業の場合だと「それらのカラムには、同じ名前を付けるのが当たり前だ」と考えるでしょう。しかし、私が以前に携わったプロジェクトでオフショア先の企業にデータベース作成を依頼した際、それらのカラムの全てに異なる名前を付けられてしまい、その後のメンテナンスや資料作成が非常に大変になったことがありました。
こうした事態を避けるためには、表計算ソフトなどでQ&A表を作成し、そのファイルを共有することで、お互いが疑問に感じた点や実装の方針などをオープンにすることが重要です。この場合に肝に銘じておきたいのは、少しでも不明な点があれば遠慮なく質問してしまうこと。「さすがにこんな些細なことを確認する必要はないよな」と考えてはいけません。そうすることで、文化と価値判断基準の差異に由来するコミュニケーションのミスをなくし、トラブルや不具合の数を減らすことができます。
緊急時にどういった対応を取るか、事前に両企業間で合意を取っておこう
深夜や休日に、担当システムに障害が発生した場合、エンジニアのあなたはどんな対応を取るでしょうか?おそらく、「システムが正常に動かなくなっているのだから、今すぐなんとかしなければ」と考え、調査や不具合修正を行うはず。そして、それは“当たり前”のことだと、多くの日本人エンジニアは思うでしょう。
しかし、一歩海外に出てみればそれは当たり前ではなくなります。オフショア開発においてよくあるのは、「障害発生時の対応方針が契約書に書かれていなかったため、オフショア先の企業が業務時間外に対応してくれなかった」というケースです。
私が過去に経験したプロジェクトで起きた事例だと、深夜にシステム障害が発生したためオフショア先の企業に電話で連絡した際に、「もう定時を過ぎているから対応できない。それに、そんな内容は契約書には書かれていなかった」と突き返されたことがありました。契約をベースに仕事をしながらも、ある程度は“義理”と“人情”で融通を効かせてくれる日本企業と異なり、海外の企業は契約書の内容を忠実に守って仕事をするケースが多いのです。
こうしたトラブルを事前に避けるためには、システム障害が発生した場合の責任の所在や対応方針を事前に文書化し、両企業間で合意を取っておくべきです。取引先の国の文化を理解し、それに寄り添って仕事を進めていくことで、「こんなはずじゃなかった」というケースを減らすことができます。
技術者の転職が多く、ノウハウが企業に蓄積されない。だからこそ、“それを前提に”仕組みを作りあげる
これは特にアジア圏において顕著なのですが、技術者の転職が非常に多いため、テクノロジーや業務に関するノウハウがなかなか企業に蓄積されず、ソフトウェアの品質が安定しないという課題があります。
例えば、世界的な人材派遣会社であるケリーサービスと中国の大手求人サイト・智聯招聘の調査によると、中国人の会社員のなんと約72%が5年以内に転職を検討するのだそうです。IT関連の新興企業が雨後の筍のような勢いで増えているアジア各国においては、どの企業も優秀な人材を喉から手が出るほど欲しがっています。そのため、高額な収入を提示してヘッドハンティングを行うケースも多く、他業種と比較しても転職する方の割合が高いのです。
こうした課題を解決するため、私が所属していたチームでは「開発手順や品質管理の基準を全て文書化し、その内容に準拠した形で業務を遂行してもらう」という方法を採用していました。つまり、人材が流出するのは“避けられないこと”と考え、エンジニア個々人のスキルに頼るのではなく、“仕組み化”によってソフトウェアの品質を安定させようとしたのです。
この方法は非常に効果が高く、納品物の品質向上に結び付いただけではなく、使用した開発手順や品質管理手法が文書ベースで分析できるようになったため、業務プロセスの可視化にも繋がりました。
レビューの方法にも、国ごとの文化の違いが表れる
ソフトウェアの品質保証において重要な“レビュー”に関しても、日本とオフショア先の海外では違いがあります。
私がかつて一緒に仕事をしていた海外企業の場合だと、レビューはレビューアーとレビューイーとが対面で行うものではなく、現場の上司やチームのリーダー・サブリーダーが机上にて単独で実施していました。そのため、プロジェクトの繁忙期になるとどうしてもチェック漏れが発生したり、特定のメンバーのみで確認するために視点が偏ったりしていたのです。
こうした事態を防ぐため、プログラムや文書などの各成果物は、どのような方法でレビューをするのかまで事前に認識合わせをしておきましょう。「そんなことまで決めておかなければいけないのか」と思われるエンジニアの方もいらっしゃるかもしれませんが、こうした地道な作業が、プロジェクトを成功に導いていくのです。
相手の文化を理解しようとする姿勢が、オフショア開発を成功に導く
オフショア開発が失敗してしまったとき、「取引先の企業に問題があったからだ。自分たちは何も悪くない」と思考停止することは簡単です。しかし、その失敗は多くの場合、それぞれの国や企業の文化をきちんと理解し合えていないことに起因しています。だからこそ、エンジニアに求められているのは、そのコミュニケーションギャップを埋めようとする姿勢です。
相手の文化を理解することは、コミュニケーション全般における大前提。それは、友人や恋人、家族のみならず、エンジニアやIT企業同士においても当てはまるのです。