閉じる


<<最初から読む

18 / 31ページ

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

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

 

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

 

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

 

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

 


ビジネスの伸び悩み

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

 

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

 

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

 

1.バイリンガルが必要

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

 

2.開発プロセスの違い

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

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

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

 

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


早起きは三文の得

私は営業チームのメンバーの中では早めに出勤していた。他にはインド人メンバーが多かったのだが、概して出勤が遅い。なんか損した感じもあるのだが、たまにはいいことも起こる。営業メンバーが共有している新規顧客からの問い合わせ用の共通メールアドレスに来た問い合わせのメールをいち早く見ることができて、いち早く回答した。内容はオフショアでのソフトウェア開発を真剣に考えているため話を聞きたいということだった。まずはお会いしてお話しを伺いたいということで早速アポイント。

 

ヒアリングの結果として、単発のプロジェクトではなくある程度のボリュームを任せるということ、1年間の作業ボリュームをコミットしていただけるということ、であった。前節にあるような単発プロジェクトの短所を全て吹き飛ばすような案件である。これはぜひ捕るべき案件であることが直感で分かった。ただしこの案件は何社かに声を掛けており、採用するのは2-3社くらになりそうとのこと。競争は激しそうである。

 

最終的には価格を含めて、体制、方法論、マネージメントなどを盛り込んだ提案書を作ることになるが、その前にお客さんとしてはインドを見ておきたいとのこと。1週間程度で各社回って施設の確認、オフショア側の体制の確認をしたいとのこと。これはよほど腰を据えて取り組まなくてはならない。

 

まずは出張の手配とお客さん側とのスケジュール調整。インドの各社とも共通なのだが、各都市にオフィスが点在している。1箇所ではなく、複数の場所を見てほしいということでお客さんの時間の取り合いである。サティヤムとしては本社のあるハイデラバード(ここが一番見栄えのよいオフィス)と今回のお客さんの業種向けのサービスを多く提供しているチェンナイの2箇所をぜひとも見てほしい(実はもう1箇所という声も上がっていた)とは思っていた。しかし最初にもらったドラフトのスケジュールでは、サティヤムは1箇所。何とか無理やり頼み込んで2箇所にしてもらった。

 

いざ出発後は気の抜けない日々が続く。お客さんのスケジュールをダメにしないように時間をきちんと守らなくてはいけないのだが、自社のミーティングの時間が長くなりがちになる。また次のところへの引渡し、また自社にいらっしゃった際の引受け、をきちんとやる。時には競合会社のオフィスに入って受付で待たせてもらう。それをしたら今度はその会社の人が自社の受付にどっかり座っていたりした。なお余談だが私の名前が日本のインド人コミュニティ(西葛西あたり)で知れ渡っていて、出張にいくのも平塚らしいという噂が立っていたようだ。

 

さて肝心のミーティングだが、どこの会社も我々はどんなサービスも提供できる、優秀な人材がいっぱいいる、コストは安い、を繰り返すのでお客さん的には飽きてくる。我々の1回目のミーティングもそんな感じでどうも印象に残らなかったようで、また施設もいろんな会社を回るので、どれがどの会社の施設か覚えておくのは大変であったよう。そこで2回目のミーティングはちょっと変わったことやろうと話しあった。たまたまそのお客さんのアメリカ子会社で行なった仕事があったので、それをケーススタディとして出してみた。この仕事はうまくいかなかった面もあったのだが、それも包み隠さず出してくれと依頼した。2回目のミーティングはその通りに行われ、お客さんにも興味もってもらった。またここではシニアマネージメントの者にも参加してもらい、コミットをしてもらった。これはお客さんのビジネスを知っている人、分かりやすい言葉でメッセージを伝えられる人に出てもらうのがよい。日本人の耳に馴染みやすい英語で明確にメッセージが伝わればお客さんの理解も得やすい。ミーティングにはそういう人選をしておく必要がある。2回目のミーティングにはそういう人に出てもらい、お客さんからも自分たちの意向をよく汲んでくれていると評価いただいた。

 

あともう一つやっておいてよかったのは議事録の配布である。英語だけのコミュニケーションで抜けるところもあるし、我々が言いたいことの念押しもできる。お客さんからすると仕事の負担が少し減るような感じでお互いにメリットがある。

 

滞在中は食事の面でも気を遣う。インドに始めて来た人はだいたいお腹の調子を悪くする。できれば胃に優しいものを途中で出すのも必要。昼間のミーティングではサンドイッチを出し、1回だけ一緒に行ってもらった夜の食事(何度も断られたが、1回だけOKしてもらった)ではインドにはほとんどなかった日本料理に行った。出張のほぼ最後だったが、温かいお茶を飲んでほっとしていただいたことは今でも記憶に残っている。


吉報

帰国後も当然営業活動は続く。いろんな会社から話を聞いた結果で追加のヒアリングがあったり、一番の難関の提案書が待ち構えている。お客さんが何を望んでいるか、心配事は何であるか、評価基準は何か、ということを正確に掴み取らなくてはならない。また他社の動向、特にコストは気になるところである。

 

提案書については今から振り返ってみてもここまで力を入れて細部まで手を加えた提案書はないと思う。その後、サティヤムでは提案書を書くのに専門のチームが組まれたりしたのだが、当時は営業が中心になって書くことが多かった。しかもかなりの少人数で。結局この時もインド側で1名、日本側は私と支社長が中心になって作り上げた。何回も徹夜し、英語でできたものをチェックし、必要であれば修正し、OKであれば翻訳(これも自分たちで!)していった。結果大作が出来上がったが、完成度は高く納得のいくものになった。

 

提案書の後はプレゼンテーション。提案書は自分たちで作成して、内容もよく理解していたのでプレゼン自体に問題はない。小細工のようだが、日本支社にも結構人がいることを示すために何人かエンジニアを動員したりもして、自分たちがサービスをきちんと提供できることをアピールしようとした。しかし何と言ってもここで効いたのは日本支社長の一言だった。「インドの各IT会社は日本に進出しているが、自分だけが立ち上げから関わりトップであり続けている。それはサティヤムだけである。」と自信を持って言ってくれた。これにはお客さんも感心してくれたようだ。ちなみにこの一言はその後「キラーパス」と呼ばれ、ミーティングの中でいかにキラーパスを繰り出すかをその後意識するようになった。

 

その後何度かやり取りがあった後に、ようやく採用の通知が来た。サティヤムで働いていて一番嬉しかった出来事の一つだった。

 


最初のプロジェクトで苦難の日々

さて仕事を受注できたからといってそこで終わりではない。今度はプロジェクトを成功に導くための膨大な努力が必要となる。まず第一に考えなくてはならないのは人である。プロジェクトを実行するためのマネージャ-がまず必要になる。これが全体のキーマンになる。お客様先に常駐して日々のコミュニケーションを取りながら、インドのオフショアチームにそれを的確に伝え確実に実行されるよう各種の調整を図らなくてはならない。時にはお客様側とインドチーム側の利害が対立して主張が真っ向からぶつかることもある。しかもこれを英語と日本語を駆使して行うし、ITの専門用語や技術的知識をある程度持っていなくてはならない。ある意味スーパーマン的な人間である。これは正直見つけるのは相当難しい。なので技術的知識はあるけどマネージメント経験がない、英語は分かるがITのバックグラウンドがない、というようにどちらかを捨てるケースがある。しかしこれが後々問題になる可能性がある。

 

サティヤムで最初に取り組んだのが店舗ごとに各種のデータを入力して、店舗別または都道府県別のパフォーマンスを数値やランキングで比較するようなWebの仕組みだった。収集するデータ、計算のロジック、その表示方法が決まれば出来るはずのシステムであるが大きな問題が2つ発生した。

一つ目は計算のロジックがなかなか決まらないということであった。そのロジックが決まらないまま、プログラムを作り始めたので、後から手直しが多く入り複雑怪奇なプログラムとなってしまった。これはお客さんの要件を決め切れないマネージメントやシステムエンジニアの問題で、それを決めないうちにプログラム作成に入ってしまったというプロセス上の問題もある。この問題は日本でも十分起こり得る問題で、インド固有の問題ではない。

二つ目の問題は表示の問題で都道府県を北から表示するのだが、これがなかなかできない。普通は北海道から表示するべきだが、なぜか青森からになっている。北からというのは何となく分かりつつも道と県は違うものと認識されていたのだ。スクロールしてみると当然府と都も扱いが異なっていて、正しく北から表示されていない。しかもこういった見た目の問題はインドでは後回しにされる傾向があり、誰も手をつけない。お客さんは検証するたびに青森が先頭になっているレポートを見てだんだん怒り始めるという負のスパイラルに入っていってしまう。この問題は日本以外の会社がシステム開発をする場合に起こり得る問題である。こういったローカルの事情をきちんと理解させるような仕組みがオフショアの開発では必要になる。

 

このシステムはスケジュールが遅れに遅れた。しかも途中でプロジェクトマネージャーが頭に来過ぎたのか置き手紙(メール?)を残して消えるという事件まで起きてしまった。この日までにプロフラムを完成させるといったオフショア側の約束が履行されなかったと思い、お客さんに合わせる顔がないということでそういう判断に走ってしまった。実際はそこは何とかクリアできたのだが、全体の立ち上げまではまだまだやること山積みだった。しかし年明けには立ち上げというスケジュールは変わらず、混乱が続くままにプロジェクトは続いた。残念ながら年明けにはまだまだ出来ていないところが多く、立ち上げはできないという判断になった。

 

その判断のミーティングでは、自分が営業としてお客様の叱責を一手に受けた。プロジェクトマネージャーではないが、こっちが逃げ出したいくらいだった。ただここで放棄するわけにはいかないので、プロジェクトマネージャーの代わりみたいなことをすることになった。ここまで遅れたので遅れついでに大幅な延期をお願いした。これはインド側とも協議して本当にできそうなラインでスケジュールを引いてみた。最初からこうしておけばよかったのだが後の祭りである。

 

一方で会社対会社の取引というレベルでもこの問題は取り扱われた。せっかく真剣に取り組もうとしたシステム開発のオフショア化ではあるが、難しいのではないか、他の会社に替えた方がいいのではという声が既に上がっていた。せっかくボリュームをコミットしていただいたのに最初でつまずこうとしていたのであった。これに対して打ち手を出さないと全てが水の泡になる可能性があった。

 

 



読者登録

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