オフショアは遠い | オフショア活用において、知っておくべきこと
itpjstudy
これまで、日本企業の海外拠点へシステムを導入するときのノウハウや知見について、お話してきました。今回は、プロジェクト内部のグローバル化について、取り上げたいと思います。
昨今では、オフショア活用が進み、国内拠点向けのプロジェクトであっても、プログラム開発はオフショア（海外）を利用するケースが多いと思います。いまでは、オフショアの活用は、プログラム開発だけに留まりませんが、今回は、オフショア活用の基本であるプログラム開発を例に、お話を進めていきます。
オフショアから見た、日本のプロジェクトのイメージ
さて、オフショア活用について、より理解を深めて頂くために、オフショアから見た「日本のプロジェクト」のイメージについて説明させてください。
日本のプロジェクトだけをやっていると、気付きにくいですが、多くのオフショアセンタは、必ずしも、日本の仕事だけをやっている訳ではありません。世界で見ると、日本語を勉強している人は少数で、英語人材の方が多いです。オフショアセンタも、日本向けの仕事と、日本以外の仕事の両方をやっていることが多いです。
彼らの本音を聞いてみると、日本のプロジェクトは面倒くさいそうです。
じゃあ、日本の仕事をやらなければ良いじゃないかと思うかもしれませんが、日本の仕事は、面倒だが、お金にはなるそうです。そのため、世界の色々なオフショアセンタで、日本向けの仕事をして頂いています。
さて、今回、日本企業のプロジェクトとして、オフショアを活用するに際しては、まず、なぜオフショアの人達にとって、日本の仕事が面倒くさいのかを理解することが非常に重要です。
日本の開発プロジェクトの特徴
- 難易度の高いプログラムが多い
- 高いプログラム品質が求められる
- 高頻度に多数の仕様変更が同時発生する
- スケジュール変更が多い
上記が、オフショアの人達から見た日本のプロジェクトの特徴です。「あぁ、なるほど」と思われる人も多いのではないでしょうか。
注意すべきことは、このような特徴が要因で、グローバルスタンダードよりも、日本のプロジェクトが難しくなっているということです。つまり、一般的なオフショアの人達にとっては、日本向けに経験やノウハウを積まなければいけないところになっているのです。
オフショア活用のための施策
上記のような難しさは、オフショア活用を進めるにあたって、色々なITパートナが壁に直面してきていますので、色々なアセットが蓄積されてきています。
オフショア活用のためのガイドラインやテンプレート、チェックリスト
日本の品質基準に合ったプログラムを作るということに関しては、プロセス改善の得意な日本人として、様々なアセットが作られてきていると思います。
- 難易度の高いプログラムが多い
- 高いプログラム品質が求められる
- 高頻度に多数の仕様変更が同時発生する
- スケジュール変更が多い
しかし、オフショア先を新規に増やしたりする場合などに、また同じ困難に直面します。イライラしたりすることもあるかと思います。大事なことは、「グローバルスタンダードのところに、日本流をお願いしているから、すぐに出来なくても仕方がない」と考えることです。
そう理解することが、問題の解決を早めます。
ちなみに「品質の高い日本流を覚えれば、日本以外のプロジェクトにも役に立つ」という動機付けは、うまく行きません。日本以外のプロジェクトでは、日本品質を求めていないからです。この理解が、非常に重要です。
目まぐるしく変わる状況変化に対応するための枠組み
日本のプロジェクトのもうひとつの特徴が、仕様やスケジュールがコロコロ変わるということです。
- 難易度の高いプログラムが多い
- 高いプログラム品質が求められる
- 高頻度に多数の仕様変更が同時発生する
- スケジュール変更が多い
こちらも、想像にかたくないと思いますが、日本のプロジェクトでは、多くの仕様変更が発生します。実は、海外でも、仕様変更は相当数発生しますが、日本の場合は、その難易度が高く、改修ボリュームが大きいという特徴があるように思います。
また、設計や課題検討の遅れなどにより、開発スケジュールの後ろ倒しも頻繁に発生します。
日本のプロジェクトの経験が豊富なオフショアリーダは、この特徴をよく知っています。そのため、自分で、状況確認を積極的に行って、ギリギリまで変更を受け入れられるよう、開発スケジュールや体制の工夫を行ったりしています。
しかし、全員がそういうノウハウを持っている訳ではありません。プロジェクトの枠組みととして、公式なプロセスを設けておくことが有効です。
オフショア開発メンバのスキル向上は、オンショア・オフショアの連携プロセスの改善は、プロジェクトをまたいだ企業レベルでの活動を行うべきです。
一方で、個々のプロジェクトにおいては、オフショア開発メンバの作業に影響を与えそうなものについては、状況が確定する随分前から、可能性を共有しておくことが大切です。
ただ、頭では事前に共有する大切さを理解しつつも、実際には難しいことが多いです。
なぜか。その辺りを、次にお話させて頂きます。
距離が離れていることは、やっぱり高いハードル
「オンサイト（日本）の人達は、言わなくても、分かってくれる。でも、オンサイトの人達は、感度が低い」ということが、よく言われます。しかし、これは、全く的外れな意見です。
決定的な要素は、場を物理的に共有しているかどうかです。
オンサイト（日本）の現地にいる人たちは、たとえ、会議に出ていなくても、なんとなく状況を感じることができます。そして、感じれば、自ずと振る舞いも変わってきます。
メンバ①
業務・アプリリーダのAさん。会議から帰ってきたら、すごく暗い顔をしているけど、どうしたのかな...？
メンバ②
設計作業が遅れているから、すごく怒られたみたいだよ。私たち、設計作業を加速しないとマズいね。頑張ろう。
このように、オンサイトの人達は、実際に、あれこれ言わなくても、なんとなく察してくれるのです。しかし、これが当たり前だと思ってはいけません。遠く離れたオフショアの人達には、状況を察するきっかけになるようなものはありません。
手間だと思っても、しっかり説明することが不可欠なのです。そして、それは、情報を持っているオンサイト側が主体的になって行うべきタスクになります。
なお、この辺りの手間を惜しんで、オフショア活用がうまく行かなくなると、プロジェクトに大きな被害をもたらすことになります。
オフショア活用が失敗したときのリスク
一番大きなリスクは、やはりコストになります。
開発タスクは、プロジェクトのなかでも、大きな工数を占めます。そのため、多くのプロジェクトでオフショアを活用して、費用を抑えようとします。
しかし、プログラムの難易度が上がり過ぎたり、短納期の仕様変更への対応が必要になったりして、オフショアを想定通り使えなくなるような事態が起きることがあります。
その場合、オフショア開発メンバの代わりに、オンサイトで急きょ開発者を用意して、対応して貰うことになります。そうすると、単価は上がりますから、開発コストが大きく上昇することになってしまいます。
先ほどもお話したように、開発工数は、プロジェクト工数の大きな割合を占めますので、オフショアからオンサイトへ切り替えたボリューム次第では、プロジェクト全体のコストを大幅に押し上げることになります。
こういったことが発生しているプロジェクトは、少なくはありません。オフショア活用の本質を理解して、そういった事態にならないよう対処していって頂きたいと考えます。
日本人の誇りとして「日本の品質は高い」という考えがあります。ITプロジェクトにおいても、日本は、世界の他に地域に比べて、非常に高性能なプログラムを開発しています。しかし、ビジネスにおいて、そうであるように、システムの世界においても、日本の高品質 ＝ ガラパゴスとなっている側面があるのは事実です。
オフショア活用においては、この点をきちんと心に留めておくことが、非常に重要だと考えています。ここを理解しておけば、自ずと行動も変わってきます。逆に、理解していないと「オフショアの人達は、なかなか分かってくれない」と不満だけが溜まる結果となります。
最後まで読んで頂き、ありがとうございました。ご意見・ご感想を頂けますと幸いです。
ITプロジェクト研究会
