閉じる


<<最初から読む

22 / 31ページ

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

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

 

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

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

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

 

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

 

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

 

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

 

 


アサインすべき人材

最初のプロジェクトが大トラブルプロジェクトになってしまったが、ここで会社として打つ手としてはプロジェクトに任せっきりにするのではなく、会社としてそのお客様へのサービスをサポートできるよう、上の者まで含めて状況を共有しておくことと、この状況をリカバリーできるような優秀な人材をアサインすることに限る。前者については日本の支社長だけではなく、アジアパシフィックを統括している人間まで連れてきて、こちらの本気度合いを理解してもらうよう努力した。

後者についてはいろいろ考えた結果、インドの人(来るのはシンガポールからだったのだが)を連れてきてプロジェクト全般を、プロジェクトマネージャーの上位からマネージメントするためにアサインすることとなった。以前日本で仕事があるものの、日本語は本当にカタコトで基本は英語でのコミュニケーション。内部だけではなく、お客様に対してもである。コミュニケーションギャップが発生するリスクはあったもののそれを上回るアドバンテージがあった。

 

1.日本でのビジネス経験

日本のお客様と対峙するのに日本でのビジネス経験は必須である。日本はなぜそこまで品質を重視するのか、細かいことにこだわるのか、については理屈というより肌で知ってもらっていたほうが断然やりやすい。これを他のメンバー(日本側インド側とも)に伝える必要があるのだが、その発信者がインド人であると伝わりやすい。お客様からしてもそこを理解しているのが分かると安心していただける。

 

2.社内でのコントロール

インドの会社の中では議論が多い。そして声が大きいもの、真剣に粘り強く訴え続けるものが最後に勝つということがある。この点はインド人マネージャーが日本にいるとお客さんの事情も汲んだ上で訴えてくれるので心強いし、一方的な結論にはなりづらい。、ここに日本人的な情に訴えるやり方も効果を出す。ローカルでも事情をインド側もそれなりに理解してくれようとするのだが、これはあくまでも一生懸命やっているローカルの人間の声に対してだけである。一方的なお願いだけでは聞き入れられない。手前味噌になるが日本で一生懸命やっている自分の声は受け入れてもらえる。インド人マネージャーと最強デュオみたいな状況になっていった。

 

3.社内人脈

このマネージャーはその後何名かのエンジニアを日本に招聘した。いずれも素晴らしいスキルを持ったメンバーだった。こういう人脈があるのもインド人マネージャーのアドバンテージの一つだ。日本人ではなかなかここまではできない。

 

こういった姿勢をお客様からも評価いただき、何とか仕事はつながった。次のプロジェクトも任せていただけることになった。まさに首の皮一枚という状況ではあった。


成長と制約

最初の苦難の時期を乗り切った後は、会社はそれなりに成長していった。日本でも新しいプロジェクトが受注できたり、新しい顧客を獲得できたりしてきた。それに伴って社員数も増えていき、成長を感じられる時期に入ってきた。ただし会社全体のグローバルの成長率は日本での成長率をはるかにしのぐものであり、そこから見ると日本のパフォーマンスは物足りないと本社からは見ていたはずである。日本での売上高は全体の売上高の2%程度で、当時GDPで世界2位とされていた国の売上としてはあまりに寂しい数字で、いつ撤退してもおかしくないようなものであった。

 

これにはいくつかの要因がある。まず第一に日本でオフショア開発というコンセプト自体が新しかったということがある。現場に常駐してお客さんとコミュニケーション取りながら、特にドキュメントに書いてなくても行間を読むようなあうんの呼吸でシステム開発をするというのが日本のスタイルであるが、これに対してオフショア開発は明確な指示がコミュニケーション(ドキュメント)の中でなされなくてはならない。日本では後から要件を付け足しても技術者が取り込んでくれたり、自分の経験で機先を制して自分でこうしたほうがいいとしてやってしまうことさえある。これに対してオフショア開発は書かれていなければ仕様変更という扱いになってしまうのである。それが全てコストやスケジュールに影響するわけではないのだが、お客さんの方はそういうやり方はできないというコメントになってしまう。また現場で一緒に仕事するとかなり迅速な対応できるのだが、オフショア開発の場合はインドへの連絡や時差の関係で指示してから出来上がるまで時間が掛かるケースがある。これを嫌がるケースもある。仕事のスタイルを変えるというのはどんな職種でも抵抗に遭いやすい。

 

二つ目は言葉の問題である。何名かバイリンガルの技術者をお客さん先に常駐させてオフショアチームとのつなぎを行なってはいるが、お客さん的にはどうしても全て日本語でプロジェクトを進めたいというケースが多い。英語に対する苦手意識が先行して、インドのオフショアは難しそうだというイメージになってしまう。またサティヤムでもバイリンガルのメンバーを潤沢につぎ込んだり、全てのドキュメントを日本語化すればその分コストは上がってしまい、下手すれば日本で開発するより高くつくことになってしまう。こういったことを敬遠して日本の企業はオフショア開発のパートナーとして中国を選ぶケースが圧倒的になってしまったのである。中国では日本語を話す人も多く、技術的には特殊な技術への対応は難しいものの一般的な開発言語(JAVAなど)であればコストもインドより安いからである。

 

それなりに案件は取れては来ていたのだが、一方で競合に負けることも多かった。日本のSI企業に負ける場合にはオフショア開発の不安な部分が挙げられ、中国オフショア企業に負ける場合には言語やコストが理由として挙げられた。こうした状況に本社側のプレッシャーは徐々に厳しくなっていく。


第一報

まだ正月気分が抜けきらない2009年1月7日に事件は明るみに出た。当日私は午前中は客先にいた。お客さんの年明けの仕事はこの日からで、お客さんに挨拶したり、客先に常駐している社内のメンバーとも新年おめでとうのコミュニケーションを取っていた。まだ仕事は本格的に始まっている感じではなく、午後は東京の自社のオフィスに戻って仕事しようと思っていた。

 

電車に乗りながら1時間半ちょっとで自社に到着。なんとなく中が騒がしい印象を受けた。自分の席に行くと同じセールスの人間が「平塚さん、やりましたよ。Fraudですよ。」と言う。その単語を知らなかった私は何の気なしにWebサイトでその単語の意味を調べる。「不正、詐欺」といったところが言葉の意味だ。何のことだろうと思っていたら周りから情報が入り始める。

当時の会長のRamalinga Rajuが、インドの証券取引所に対してこれまでサティヤムが粉飾決算をしてきたことを告白したのである。最初は小さな額であったものがだんだん大きくなり、止めるに止められなくなったとの事。「虎の背中に乗ったものの降り方を知らなかった」というのが本人のコメント。うまいこと言うが、これは犯罪である。これ以降サティヤムという会社および社員(そしてその家族)は大きく翻弄されることになる。

 


前兆

思えばこの事件には前兆があった。

事件発生の前年の2008年12月。サティヤムがインフラや不動産の事業をしている会社を買収するというニュースが流れた。電話会議形式でこの買収に関する株主への説明とヒアリングがされたが、相当紛糾したようである。現業のITとの関連が不明確であったこと、買収しようとしている企業が会長の息子が経営している会社で(買収対象のMaytasを逆からつづるとSatyamになる)会社の私物化にあたるという意見もあった。

この買収は結局株主の猛反対に会い、撤回せざるを得なくなった。結果として、このニュースを受けてサティヤムの株価は急落。取締役も何名かが辞任することとなった。これらの取締役は買収に関して反対をしていた人々で、自分たちの反対意見を聞き入れてもらえなかったことに対する抗議の辞任というような形になった。

 

これらのニュースは日本側からするとなかなか動きの見えづらいところで、そのような買収議論がされていることは知らず、結果として計画の撤回があったことが知らされた。株価の急激な下落や取締役の辞任があり、既存のお客様への説明は必要となった。このようなニュースが流れたが、この計画は撤回して今まで通りITの分野でビジネスをしていきますというメッセージを送った。海の向こうのニュースということもあり、お客様のほとんどは了解しましたという返信であった。

 

その中で一件の新規商談が打ち切りとなった。先方の会長がこのような動きをする会社とはビジネスを開始することはできないという意向を示したためであった。残念なことではあったが、我々はまだそれが単なる始まりであることを十分に認識できてはいなかった。



読者登録

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