閉じる


<<最初から読む

15 / 31ページ

プロジェクトの難しさ

よく言われる話だが、オフショアを使った開発を成功に導くのは難しい。ただこれは別にオフショアプロジェクトに限った話ではない。一般的にシステム開発のプロジェクトを成功に導くのは難しい。プロジェクトを成功に導くのが難しい要因を一般的なもの(オフショア開発でも国内開発でも共通のもの)、オフショア開発ならではのものに分けて考えてみたい。前者についてはいろいろなところで言われていることで、ここでは特に触れない。後者について掘り下げてみたい。

 

1.一般的なもの

  • 納期に制約がある。
  • 要件が決まるのが遅く、後から変更が発生して一部やり直しになることがある。
  • コミュニケーション上の問題で、伝達したと思っていたことが相手方に伝わっていないことがある。

2.オフショア開発独自のもの

  • 日本語と英語の言語差がある。
  •  日本の習慣や一般常識と言われるものが理解しづらい。
  • 時差がある。

挙げればキリがないがまずはこのあたりでどういう問題が発生するか、どういう対応策が考えられるか検討してみたい。

 

日本語と英語の違いだが、これはインドのオフショアを使う上で避けて通れないポイントである。同じオフショア開発を行なう中国では、日本語を理解できる人材が多く、また漢字で何となくの意味は通じることがあってハードルが屋や低い。日本のシステム開発の中でオフショアを使う場合に90%以上が中国になっているが、これは言語が一番大きい理由になっていることに間違いない。インドでも 日本語を話せる人は増えてきたが、まだ数はそんなに多くはない。またオフショアで開発するメンバーはほとんど日本語ができない。さてどうするべきか?

  • 日本語と英語の出来るバイリンガルスタッフを客先(日本)にアサインする。一般的にオンサイトと言われる。これは国籍は問わないのだが、何かしらの付加価値が必要になる。お客さんとのコミュニケーションに長けている、プロジェクトで使用する技術に精通している、英語でオフショアに対して強いマネージメントができる、などなど。プロジェクトの特性によってどういう人がアサインされるかが決まる。新規の開発や他システムとの連携が多いプロジェクトでは日本人で他のステークホルダーとのコーディネーションが出来る人、技術に特化したプロジェクトの場合はインド人で技術に強く現場で説明が出来る人、といったマッチングが考えられる。
  • 日本の習慣というのはなかなか他の国の人には理解しづらい。しかし仕事ではそんなことは言ってられない。以前都道府県別のリストアップするという機能があった。通常は北は北海道からという順番なのだが、なぜか青森からしか出てこない。どうも道と県は違うカテゴリーに入ってしまったようで、同じリストの中に順番通りに入ってこなかった。思えば日本人だって都道府県のそれぞれの定義を明確に言える人は少ないはずで、何となく都道府県を同列に扱って北から並べるだけだ。そういったところは他国の人には丁寧に説明しなくてはならない。そして当然このようなことはシステムの要件とか仕様書には出てこない。
  • 日本とインドの時差は3時間半。日本でお昼の頃にインドはようやく出勤という形だ。そのギャップにいらだつこともあるが、これは変更できるものではなく、変更しようとするならインド側にシフト勤務を強いることになる。短期ならまだしもいつまでも続けられるものではない。そうであればこのギャップを有効活用することを考えた方がよい。日本の午前中にはオフショア側にやってもらうことの決定とか、オフショアからの質問事項に対する回答を用意しておく。それを午前中にメールしておき、必要に応じて日本時間の午後に出勤したオフショアメンバーと確認する。夕方はあとはこれだけ今日中にやっておいてという確認をした上で翌日の朝に出来上がったものをチェックする。もちろんこれは理想的な形で、なかなかそうはいかないことも多い。それでもこういうすり合わせの時間帯が持てるのは日本のビジネスには合っていると思われる。アメリカではインドとは昼夜逆転していて、すり合わせなく仕事が行なわれるケースも多いようだが、これは文化的なことと言語(同じ英語を使っている)ということに起因しているようだ。

インドオフショアを使った開発で何に気をつけるべきかもっと理解すれば、活用はさらに広まると思うのだが、なかなかそうはいっていないのが現実だ。

 


トラブル

いくらプロジェクトが難しいからと言っても、このような対策を取ればいいと言っても、それは外から見た客観的な物言いであり、実際にプロジェクトがトラブルモードに入っていくとなかなか落ち着いた判断が出来なかったり、コミュニケーションがさらに悪くなったり、トラブルがトラブルを呼ぶケースも多い。

 

これは地道に解決していくしかないのはどんなプロジェクトでも共通なのだが、このような状況下でのインドの人たちの反応のしかたなど、自身の経験から挙げてみたい。

 

1.相手によって態度が変わる

トラブルが起きても「自分たちのすべきことはした。この原因はお客の側にある。だから我々はタッチしない。」とか「お客の指摘事項は仕様の変更依頼だ。追加の発注が出るまでは仕事はしない。」などと強硬な発言が相次ぐ。これは会社の社内でのこと。ではいざお客さんの前に立つとどうなるか。やはり怖いケースもあって、意外と黙って聞いている。それどころか、「分かった。やろう。」ということにもなる。インドは契約的にきちんと書面を守るので融通が利かないという評価を聞くことがあるが、自分としてはあまりそうは思わない。感情的には日本人に近いところがあって、気持ちの面で納得すれば仕事するというのが印象だ。逆にそれがないといくら契約でも動かない。

我々日本人が間に立った時に弱気な交渉をすると彼らは不満を表す。あまりにも言うことを聞きすぎだという印象を持つのだろう。日本人ももっと頑張らねばと思うところだ。

 

2.夜間、休日の対応

日本人でも当然嫌がるのだが、やらざるを得ない場合がある。これも前の項目と一緒で多分に気持ちに負うところが大きい。一方的に仕事だけやらせるというのはフェアではないし、これは避けなくてはならない。今日やったら明日は休みとか今度食事に連れていくとか、「エサ」をぶら下げないとどうもならない。一度は神戸のプロジェクトで人が足りないことがあり、埼玉のプロジェクトにいたメンバーを土日に引っ張っていったことがある。この時は一日京都観光を連れていくという条件をつけた。最初は嫌がっていたが、京都観光が効いてサポートに来てくれた。

これは極端な例だが、基本的にはきちんと言えば夜間でも土日でも来てくれる。やはりプロジェクトで問題を解決することはみんなにとって優先事項なのだ。

 

3.言いたいことは言う

感情的にフラストレーションを溜め込むのはよくない。何かあれば吐き出させる機会を設けるのも重要。インドの人に言いたいことを言ってくれというと英語でまくし立てる(最初はゆっくりでも最後はえらく早口)。こちらも全部を理解してあげられるわけではないのだが、言うことで落ち着くこともある。それはケースバイケースで、一対一で話してもらうこともあれば、飲み会のような席で皆の前で言ってもらってアピールの機会のようにすることもある。


離職率の高さ(日本人編)

インドの会社でよく言われることの一つに離職率が高いということがある。これは比較の問題であるが、日本に比べて高いのは間違いない。ただし絶対的に高いのかどうかは分からない。アメリカなど他の国に比較すれば少ないのかもしれない。ただ日本のビジネスをしている我々にとっては日本での見られ方が重要になってくる。離職率が高いと一言で言ってもいろいろなケースがある。

 

ここでは日本で採用した日本人社員の離職について考えてみたい。

まずは営業職についてである。私も所属する営業職だが、実はここの離職率も相当高い。先に私より前にいた営業がみな辞めてしまったことは書いたが、全般的に短いサイクルで離職しているケースが多い。いくつか理由が考えられる。

 

1.英語の問題

お客様に対して話をする内容のインプットはインド側から渡される。この内容を理解するのに時間がかかる。ドキュメントだけでは不十分なため、電話会議などで補足情報も入手する。しかも英語である。英語が苦手だとこれは頭痛の種だ。しかもなぜか英語が苦手な人に限って、日本語では饒舌にお客様と会話してくる。そしてもっとインプットを求められるということになる。これが嫌で退職ということになったも多い。

 

2.契約や金銭面での内部交渉

営業が交渉する相手はお客様だけではない。社内的にも交渉の相手がたくさんいる。中でも厳しいのが法務部門や財務部門だ。法務部門は契約面で、財務部門は金銭面での社内交渉窓口になる。彼らのOKが出ないと契約や金額交渉をお客様と進められないのである。ただし当然一筋縄ではいかない連中ばかりである。会社のルールや今までの事例を元にして、日本での例外は認められないという立場を取ってくる。営業としてはなんとか商談をまとめたく、日本独自の法律や商習慣など様々な形で説明して合意を取り付けるようにしたい。しかしあまりにOKが出なかったり、時間が掛かったりするとへこたれてしまう。こういうことは続けられないと辞めてしまうケースがある。

こういうことは場数を踏んでいくと、ここまではOKなはずとか、他の契約でOKにしてもらったこの条件に置き換えようとか、話している相手の上司に訴えかけてOK取ろうとかいろんな手段が考えられるようになる。法務部門や財務部門だってビジネスを成立させたいのはお互い様である。どこかで合意できるポイントがあるはずだ。そういうことを理解する前に退職してしまうのはもったいない話ではある。

 

次に技術者についてである。技術者の場合も言葉の問題はあるが、プロジェクトの中で通訳・翻訳をしてくれる人がいたり、日本語だけでよい役割のこともあるので、営業よりは多少緩和されるところもある。技術者の場合、問題になるのはどちらかというと仕事の進め方の問題にある。

 

一般的に日本ではきちんと計画を立てた上で、その計画に沿って仕事を進めて行くというのが流れである。なので立ち上がりに時間が掛かる。しかしインドではどうもまずやってみようという考えがあるようだ。やってみてダメだったらやり方を変えてみればいい。日本で採用した技術者はほとんどが中途採用で日本式の前者のやり方に馴染んでいる。そういう人達が後者のやり方に直面するとストレスを感じてしまうことが多い。例えばレポート一つ取ってみても、事前に確認したフォーマットでなく違ったフォーマットで来たり、タイミングとしてこの日までに送ってくれといったものが遅れたりする。お客様や日本側の技術者にしてみれば、なぜ約束が守れないのかということになるのだが、インド側からするとフォーマットを変えたのは何らかの理由があったのであり(必要な項目を足すとか)、タイミングが遅れたのはできるだけ最新情報まで取り込もうとした結果かもしれない。

 

日本式とインド式のどちらがいいか悪いかは決めがたいが、これも十分にコミュニケーションがあればお互い理解できることであると思われる。こういう気持ちに至る前にインドのやり方ではダメだということで辞めてしまう人がいた。入社した時にはそのような差異も意識してもらっていたはずなのだが、残念な話ではある。


離職率の高さ(インド人編)

インドのIT企業では概して離職率が高い。一つには金銭的な理由がある。インド国内ではIT企業に対する需要は大きく、いくら国策でIT技術者を増やそうとしてもなかなか需要に追いついていないのが現状である。するとIT企業間で優秀な技術者の引抜きあいになる。その時にモノを言うのはやはり金銭的な待遇になってしまう。現在の給料の1.5倍とかいう数字がいきなり提示されてしまうのである。しかも若いメンバーになので、たちまちクラクラとなってしまう。特にインドはずっと景気が拡大してきているのでその傾向は根強い。

 

もう一つの離職の理由が「チャレンジ」である。技術的に新しいこと、メンバーレベルからマネージメントへの脱却、難しいプロジェクトにチャレンジしたいという気持ちから転職するケースが多い。ずっと一つのところで同じような仕事をしているのをよしとしないのである。こういった成長を求める気持ちは日本人としては見習うべきところも多い。

 

いずれにせよ離職が起きるとそのバックアップであったり、その人が持っていた知識の移転とかが必要になり、大騒ぎとなる。特にプロジェクトの佳境の段階で人が抜けるのは本当に困る。こういった不測の事態に備えて事前のバックアッププランを考えておくべきなのだが、やはり人材は少ないのである。なかなか難しいところがある。しかも日本だと最低1ヶ月間の期間があったりするのだが、インドではそれ未満のケースが多い。退職願を出してからは1ヶ月という期間があるようだが、慰留交渉とかもそこに含まれていて実際の引き継ぎを開始できるのは退職まであと2週間といったようなケースが多い。いくらシステムの世界とはいえ、その人に属している知識も少なくはない。これを明文化するのはなかなか難しい。

 

辞める人間はモチベーションを失っており、引き継ぎもいい加減になりがちである。なんとかここで最大限のものを引き出す努力をしなくてはならない。ただ引き継ぎをいい加減にするような人間は大したメンバーではないことが多い。ちゃんとした人間は引き継ぎにも最大限の努力をして後に迷惑をかけないようにしている。会社を辞めた後でも交流があるのは大体そういうメンバーである。

 


ビジネスの伸び悩み

入社後、少しずつ案件は獲得していった。ただしどれも単発のプロジェクトで、完了すればそこまでで次の仕事の保証があるわけではない。これは売り上げ的に問題があるということもあるし、もっと大きいのは経費負担が大きくなるという問題がある。プロジェクトを完了した人々が自社に戻ってくるのだが、その間は売上がなくて人件費だけが出ている状態になる。これは万国共通でシステムインテグレーターが抱える問題である。

 

これをか解決するのは難しい。解決策としては長期の契約を持ってくるのが一番である。これはシステムインテグレーター側だけのメリットではない。顧客にとっても自社のシステムを知っているシステムエンジニアやプログラマーが継続してサポートしてくれるのは手間が省ける話である。日本の情報システム子会社はまさにこのようなビジネスモデルである。

 

ただしこれをインドの会社とやろうという企業はなかなか出てこない。欧米ではインドのオフショアサービスの会社と組んで自社用の開発センターをインドに作って長期的にサービスを提供させるというのは一般的なのだが、日本ではあまり例がなかった。日本の顧客と欧米の顧客での大きな違いとそれによる影響は下記のようなものがある。

 

1.バイリンガルが必要

日本の顧客が英語のみでプロジェクトを実行する(コミュニケーション、ドキュメントとも)ということを受け入れることはなく、インドの会社にとってはバイリンガルの人材もしくは通訳・翻訳者を追加でアサインする必要があり、これがコストを押し上げて顧客に対するコストメリットが低減されてしまう。また当然コミュニケーションギャップが生じるリスクが高くなる。

 

2.開発プロセスの違い

欧米ではまずは業務要件やシステム要件に顧客が合意してプロジェクトが始まる。その後に発生した変更は仕様変更として取り扱われ、スケジュールやコストの見直し原因となる。これは顧客側も理解している。

このあたりは日本では曖昧になっていて、業務要件やシステム要件に関する合意がないままプロジェクトが走るケースが多い。そうすると後から揉めるのだが、コストの増加やスケジュールの延長が認められないケースが多い。ここでの揉め事が感情的な対立を生み出す。

スケジュールの延長がないため、急に人員を増やしたり、少しでも遅れれば破綻するような並行タスクでを組んだりする。そしてまたここで遅延が起きて対立が悪化していくという負のサイクルに入っていってしまう。

 

サティヤムでもうまくいっている顧客もあれば、1回のプロジェクトだけで関係が終わってしまう顧客もあり、ビジネスとしては伸び悩む時期が続いていた。



読者登録

tokuさんの更新情報・新作情報をメールで受取りますか?(読者登録について