オフショア開発で失敗しないポイント
システム受託開発のビジネスモデルは、誤解を恐れずに言えば実はとてもシンプルです。
基本的に原価は人件費だけなので、お客様から頂く月額費用(業界では1人月という単位)より安価な人件費で開発を行えば利益が出ます。
となると利益を増やすためには人件費を抑えるか、月額費用を上げるかです。月額費用は業界の相場があるのでなかなか簡単に挙げられませんが、人件費は工夫すれば下げることができます。
その目的を達成できるのがオフショア開発です。
以前に比べるとオフショア開発を始める企業は減りましたが、10年ほど前にはオフショア開発に進出する企業は後を絶ちませんでした。
企業がオフショア開発をする主な理由は以下になります。
人材が大きく不足しているのが現状です。そのため利益目的ではなく、人材不足に対応するためにオフショア開発を行っている企業もあります。
オフショア開発のピーク時期から数年経つと、オフショア開発の様々な問題点が顕在化してきました。
プログラミング言語自体は世界共通なので心配いりませんが、問題なのは仕様です。日本語で書かれた仕様を現地のエンジニアに説明しなければなりません。
ただでさえ仕様書は細かく書かれているので、日本人エンジニアでも日本語の仕様書を理解するのに苦労しますが、それを現地語に直して理解してもらう必要があります。
そして仕様を間違って理解してしまったら、間違った設計書が出来上がってしまいます。そのまま開発を進めたら案件は炎上します。やはり、言語の壁は大きいといえます。
一般的にシステム開発では、納品物(成果物とも言う)をお客様に納めて、業務が完了となります。
納品物にはプログラムソースや仕様書、設計書、バグ管理表などがありますが、これらは基本的に現地語で書かれます。現地のエンジニアが作成するので当たり前と言えば当たり前です。
英語ならまだしも、現地語で作成された納品物を日本語に翻訳することはまた別のスキルを必要とします。
初めての人がプログラムを一目見ただけではロジックを理解するのに時間がかかります。そのためロジックの前後にコメントを書くのが一般的です。
例えば、「フラグ1であれば、このページに遷移し、フラグ2であれば別のページに遷移する」など、アルファベットで書かれたプログラムを日本語でコメントします。
しかしオフショアの場合は現地語でコメントも書かれるため、どんな目的でロジックが書かれているか分かりません。 そのため追加で改修をする際は、ロジックを初めから理解せねばならず非効率です。
日本では常識と考えられていることでも、他国では非常識なこともありますし、国ごとの文化、習慣があります。
すべて日本式で仕事を進めることは難しいと考えておいた方が良いでしょう。
ですので、デメリットが直撃しないように注意しながらオフショア開発を進めていく必要があります。
一部分だけ依頼する場合、最終的にソースをマージする(プログラムを併合する)ことになるので、仕様が間違っていれば、マージ後の動作確認でバグが発生するはずです。
全行程を任せないことで早期にバグを発見できます。
もちろん、最初は一部であっても仕事に慣れてきたら徐々に依頼する量を増やしていく事は可能です。
ポイントとしては現地の開発現場に、数名の社員を常駐させておくことです。現地に社員がいないと実際の報告が正しいのか否かが分かりません。
社員とオフショア開発先のエンジニアが同じ空間にいることで実態が把握しやすくなりますし、現地のエンジニアも困った時には質問ができるようになります。
日本のエンジニアは納期を守る意識が高いです。そのためスケジュール通りに進んでいなければ率先して残業をして納期を合わせるよう調整します。
しかし、他国はそうとは限りません。そもそも納期意識が低い国もありますし、残業を行う意識がない国もあります。そのような国でオフショア開発をする場合は働き方に対する考えに事前同意してもらう必要があります。 平然と納期を破られたら仕事になりませんし、利益も減りますので、事前に合意がとれた企業とのみオフショア開発を行うべきです。
しかし、実は日本の協力会社に依頼するよりも多くの工程(言語の翻訳や現場管理、事前合意など)が必要になります。内容によっては日本企業に依頼した方が利益が残る場合さえあります。
そのため、様々なコストを考慮しても大きな利益を生みそうな案件だけオフショア開発を行い、その条件に満たない場合は国内の協力会社を使うのが最善の策です。
一時的な利益だけに目を向けると安易にオフショア開発に走ってしまいますが、長期的に見た時にオフショアをすべきか良く考えたうえで決断した方が良いでしょう。
基本的に原価は人件費だけなので、お客様から頂く月額費用(業界では1人月という単位)より安価な人件費で開発を行えば利益が出ます。
となると利益を増やすためには人件費を抑えるか、月額費用を上げるかです。月額費用は業界の相場があるのでなかなか簡単に挙げられませんが、人件費は工夫すれば下げることができます。
その目的を達成できるのがオフショア開発です。
- 圧倒的なコスト安と国内の人材不足が理由で企業はオフショア開発を行う
- 仕様理解不足やカントリーリスクなどオフショア開発はメリットばかりではない
- オフショア開発で失敗しないポイントは全行程を任せない、定期報告と現地常駐、働き方の事前合意などが必要である
- 長期的な考えのもと、オフショア開発を行うべきかどうか判断すべき
オフショア開発をしたがる理由
オフショア開発とは日本で請け負った開発業務を自社で行わず、海外企業や海外に設立した現地法人などに発注する開発方法です。中国やベトナムなど、人件費が安いアジア諸国の下請け企業へ発注することが多くみられます。以前に比べるとオフショア開発を始める企業は減りましたが、10年ほど前にはオフショア開発に進出する企業は後を絶ちませんでした。
企業がオフショア開発をする主な理由は以下になります。
圧倒的なコスト安
まずは圧倒的なコスト安です。オフショア開発に人気があったのは中国やインド、ベトナムなどの人材豊富で発展途上の国々。人件費が極端に安く、またエンジニアの数も比較的多いため、安価で人材が確保できます。 人件費は日本の25%~50%ほどで人材が確保できるため利益率は高くなります。国内の人材不足
国内の人材不足もオフショア開発を加速させた理由です。日本のエンジニアはアメリカや中国の企業と比べると給与が少なく、拘束時間も多いため定着率が高くありません。人材が大きく不足しているのが現状です。そのため利益目的ではなく、人材不足に対応するためにオフショア開発を行っている企業もあります。
オフショア開発のリスク
圧倒的なコスト安と国内の人材不足からオフショア開発を推進したい企業は多いのですが、しかしながらオフショア開発にはたくさんのリスクも存在しています。オフショア開発のピーク時期から数年経つと、オフショア開発の様々な問題点が顕在化してきました。
仕様理解
やはり言語の壁はどうしても立ちはだかります。プログラミング言語自体は世界共通なので心配いりませんが、問題なのは仕様です。日本語で書かれた仕様を現地のエンジニアに説明しなければなりません。
ただでさえ仕様書は細かく書かれているので、日本人エンジニアでも日本語の仕様書を理解するのに苦労しますが、それを現地語に直して理解してもらう必要があります。
そして仕様を間違って理解してしまったら、間違った設計書が出来上がってしまいます。そのまま開発を進めたら案件は炎上します。やはり、言語の壁は大きいといえます。
納品物が現地語
仕様に関しては日本語から現地言語への翻訳が問題となりますが、納品時には現地語で書かれた納品物が作成されます。一般的にシステム開発では、納品物(成果物とも言う)をお客様に納めて、業務が完了となります。
納品物にはプログラムソースや仕様書、設計書、バグ管理表などがありますが、これらは基本的に現地語で書かれます。現地のエンジニアが作成するので当たり前と言えば当たり前です。
英語ならまだしも、現地語で作成された納品物を日本語に翻訳することはまた別のスキルを必要とします。
コメントが現地語
プログラム作成時にコメントを入れますが、これも現地語です。初めての人がプログラムを一目見ただけではロジックを理解するのに時間がかかります。そのためロジックの前後にコメントを書くのが一般的です。
例えば、「フラグ1であれば、このページに遷移し、フラグ2であれば別のページに遷移する」など、アルファベットで書かれたプログラムを日本語でコメントします。
しかしオフショアの場合は現地語でコメントも書かれるため、どんな目的でロジックが書かれているか分かりません。 そのため追加で改修をする際は、ロジックを初めから理解せねばならず非効率です。
カントリーリスク
すべての仕事が日本と同じように進むわけではありません。国によって法律や国民性は異なります。日本では常識と考えられていることでも、他国では非常識なこともありますし、国ごとの文化、習慣があります。
すべて日本式で仕事を進めることは難しいと考えておいた方が良いでしょう。
オフショア開発で失敗しないポイント
以上のようにオフショア開発にはメリットもありますが、大きなデメリットもあります。ですので、デメリットが直撃しないように注意しながらオフショア開発を進めていく必要があります。
全行程を依頼しない
リスクを最小化するために開発の一部分を依頼するようにした方が良いです。全行程を依頼してしまって、実はまったく異なる仕様のシステムが出来上がる可能性もあります。一部分だけ依頼する場合、最終的にソースをマージする(プログラムを併合する)ことになるので、仕様が間違っていれば、マージ後の動作確認でバグが発生するはずです。
全行程を任せないことで早期にバグを発見できます。
もちろん、最初は一部であっても仕事に慣れてきたら徐々に依頼する量を増やしていく事は可能です。
定期報告と現地常駐
定期的に開発状況をヒヤリングするようにしましょう。それにより進捗状況の確認が可能になります。ポイントとしては現地の開発現場に、数名の社員を常駐させておくことです。現地に社員がいないと実際の報告が正しいのか否かが分かりません。
社員とオフショア開発先のエンジニアが同じ空間にいることで実態が把握しやすくなりますし、現地のエンジニアも困った時には質問ができるようになります。
契約前に働き方に合意してもらう
日本人は勤勉で良く働くと言われています。しかし、これは日本では当たり前ですが海外からは当たり前ではないこともあります。日本のエンジニアは納期を守る意識が高いです。そのためスケジュール通りに進んでいなければ率先して残業をして納期を合わせるよう調整します。
しかし、他国はそうとは限りません。そもそも納期意識が低い国もありますし、残業を行う意識がない国もあります。そのような国でオフショア開発をする場合は働き方に対する考えに事前同意してもらう必要があります。 平然と納期を破られたら仕事になりませんし、利益も減りますので、事前に合意がとれた企業とのみオフショア開発を行うべきです。
オフショア開発の前に一考を
オフショア開発は低コスト発注が可能な分、大きな利益が発生するように見えます。しかし、実は日本の協力会社に依頼するよりも多くの工程(言語の翻訳や現場管理、事前合意など)が必要になります。内容によっては日本企業に依頼した方が利益が残る場合さえあります。
そのため、様々なコストを考慮しても大きな利益を生みそうな案件だけオフショア開発を行い、その条件に満たない場合は国内の協力会社を使うのが最善の策です。
一時的な利益だけに目を向けると安易にオフショア開発に走ってしまいますが、長期的に見た時にオフショアをすべきか良く考えたうえで決断した方が良いでしょう。