コストの安さと国内ITエンジニアの人材不足から、オフショア開発を行いたい企業は数多いです。実際にオフショア開発を有効活用している国内企業も多いのですが、そこには当然リスクも存在しているのです。ここでは日本式が通用しないオフショア開発の難しさや、オフショア開発を有効に進めていくための進捗管理方法について説明します。既にオフショア開発はピークをすぎていると言われていますが、オフショア開発を利用してきた多くの国内企業が直面した問題を洗い出し、そこからオフショア開発をうまく活用できる方法が考えていきます。
言語の壁が立ちはだかる
日本式ではなかなか解決しないオフショア開発のリスクに言語の問題があります。ソフトウェア開発においてPGレベルでは特に言語の問題は存在しないと思いがちですが、意思の疎通には言語でのコミュニケーションがとても大切です。オフショア開発のさまざまな問題点が顕在化してくる中で、もっとも大きな問題がやはり言語の問題なのです。これは突き詰めていくとコミュニケーションの問題ということにもなります。
オフショア開発の中で、どうしても言語の問題がITエンジニアの間にたちはだかっています。プログラム言語自体は世界共通なのですが、問題となるのが仕様です。仕様や設計は当然日本語で書かれていますから、それを現地の言葉に翻訳しさらには、説明をしなくてはいけないのです。ここに多大なコストがかかると指摘する声も多いです。特に日本式の仕様書というのは事細かく書かれています。日本人のITエンジニアでも日本語の仕様書や設計書を理解するのは大変に苦労するのです。そういった日本式の難解な仕様書は、現地語に翻訳するのも大変です。飜訳を外部に委託する方法もあるのですが、正しく現地のITエンジニアに仕様や開発の意図が伝わるかどうかなどもしっかりとチェックしなくてはいけません。そこがまた日本式の厄介なところで、仕様の難解さがオフショア開発の効率を阻害してしまうのです。その難解さこそが飜訳の際にネックとなり、また現地のITエンジニアがどれだけ優秀であっても、日本人ITエンジニアが理解できない仕様を現地のITエンジニアが理解できないのも当然といえるのです。
あがってくるものは現地語になる
日本語の仕様書を現地の言葉に翻訳し、オフショア開発の現地のITエンジニアに現地語で説明します。ここにも難解な仕様を現地のITエンジニアに理解してもらわなくてはいけないリスクが存在します。そして、なんとかソフトウェアを作ってもらい、上がってきた納品物は当然のことながら現地の言葉となっているのです。プログラム自体は世界共通ですから問題はないのですが、それでも中のコメントなどが現地語になっていたら、それを日本語に飜訳しなくてはいけません。一般的なオフショア開発での納品物となると、プログラムソースはもちろんですが、仕様書、設計書、バグ管理表などがあります。仕様書や設計書、さらにはバグ管理表に至っても最初の説明の段階で渡したものはすべて、現地語に翻訳してあるものですから、上がってきた仕様書、設計書、バグ管理表などのすべてが現地語となっているのです。
これは当然と言えば当然なのですが、そこからさらに日本語に翻訳しなければならないコストがかかってくるのです。もっともそういったコストを考慮した上でのオフショア開発であるのは間違いありませんし、飜訳するコストがかかっても、全体のオフショア開発のコストの低さに問題はありません。ですから、そういった飜訳コストというのは想定内ということです。オフショア開発で明るみになったことがあるとすれば、日本式の仕様書や設計書の難解さです。誰でも分かるように事細かに記述していることが、現地語に翻訳する際に大きなネックとなりますし、作ってみると簡単なプログラムなのに、何故これほど分厚い仕様書になるのかと、現地のITエンジニアからも不思議に思われてしまうのです。
オフショア開発で進捗を管理する
言語の問題やコミュニケーションの問題などオフショア開発にはリスクがつきものですが、こうした問題点を理解したうえで、注意しながらオフショア開発は進めていく必要があります。オフショア開発の考えられるリスクを最小限に抑え、できるだけスムーズに進捗を進めていかなくてはいけません。そういったリスクを最小限にするためには、一つのブロックやシステムをオフショア開発に丸投げにするのではなく、そのブロックのさらに一部分単位でオフショア開発を依頼するのです。わかりやすく言えば、PG単体での依頼ということになるでしょうか。極端すぎる例えですが、部分的に依頼することでリスクを最小限に抑えることが可能となります。進捗管理が大変になると思いがちですが、一つのブロックや全行程、あるいは一つのシステムを依頼してしまい、できあがったものが全く別の結果を出してしまうということになると、最初からやり直しということにもなりかねません。リスクを最小限に抑えるためにも、進捗を事細かに管理することが大切なのです。
日本式であれば、細かく管理されたほうが出来上がりに間違いがなく、そういったことにも日本人であれば慣れているのですが、現地のITエンジニアには、細かく管理された労働環境に慣れないという場面も出てくるかもしれません。日本式で押し通すのか、現地のやり方に合わすのかケースバイケースでもあるのですが、日本式で押し通す方法を模索しながらも、どこかで妥協点を探ることが、正しい進捗管理の近道となるのです。
報告の徹底と現地常駐で進捗管理
日本式で報告というと、「報連相」を想像しがちですが、細かい報告になってしまうと現地のITエンジニアも大変ですし、受ける側の理解力も問われるでしょう。日本式でいきたいところですが、日本式の弊害というのもオフショア開発では、ずっと指摘されてきていることなのです。効率化を図るということも大切ですから、定期的にヒアリングをするといったことに気をつけるようにしましょう。それによって進捗を把握することができます。
定期的なヒアリングをすることで、現地のITエンジニアの力量を探ることもできます。プログラミング技術に問題はなくても仕様を理解していないと、違う結果の出るプログラムができあがってしまいます。そういった小さなことをできるだけ早い段階で摘んでおかなくてはいけないのです。
正しいプログラムが予定通りにできあがっているのかを確認するのが進捗管理ですが、そのためにも望まれるのが、オフショア開発現場に数名の社員を常駐させることです。現地に統括する社員がいないと進捗がどうなっているのかがわかりません。これは当然のことなのですが、ある程度の社員を現地に常駐させることで、進捗管理を容易に行うことができるのです。日本国内とオフショア開発現場をテレビ会議でつなぐ方法もあるのですが、側にいるのといないのとでは管理方法が全く違ってきます。現地常駐はオフショア開発では必須と考えたほうがいいでしょう。
オフショア開発の現場では、必ず言語の壁というのが立ちはだかってきます。それは当然オフショア開発を利用する上での想定内のリスクなのですが、たいていは思った以上の壁となって立ちはだかることになります。そこから試行錯誤が始まるのですが、多くの場合、日本式を無理強いさせるのではなく、現地の開発環境や習慣といったものをある程度認めないと、モチベーションを高めることはできません。そして、大切なのは現地に常駐させる社員の確保です。これらのことに気をつけることで、オフショア開発の進捗管理もスムーズに進んでいくことでしょう。
