インドに外部委託して品質管理ができずに億単位で失敗したベンチャー

おはようございます。

晴れ空。風も空気中の浮遊物も収まっているようです。

＝＝＝ほぼ毎朝エッセー＝＝＝

昔話です。

e-Janでは2000年の創業当初はインドに開発を外注していました。
インドの会社に開発協力を委託して、現地に開発チームを設けて、
リエゾンとなるプロジェクトリーダーが日本に居ながらの体制です。

当時は第一次ＩＴバブルだったので、日本ではプログラマーが不足、
インドに活路を求めたわけです。結果的にはこの体制では大失敗しました。
失敗の理由はいろいろあると思いますが、今日は二つピックアップします。

・外部委託は人月との戦い
・プログラムが見えないが故の品質

＝＝

■外部委託は人月との戦い

言うまでもなく、時間と工数はかかればかかるほど費用がかかります。
それなので、委託する側はなるべく安くすませたい。
開発する側はなるべく人月を大きくしたい。関心ごとが違うのです。
根本的なところでそのせめぎ合いが存在します。

自社製品のような、継続的な改良が必要な分野において外部委託をすると、
それはどうしてもこのベクトルの違いに悩むことになります。
どんどん良くしたいけど、どんどんお金もかかるようになる。

自社製品を自社技術者が開発するのであれば、自分たちの仕事がやりやすく
なるように様々に工夫をしてくれます。一方、委託されるという開発の場合、
技術者たちにとってそこは一時的な職場という位置づけです。

ある開発会社の人は「納品して使われないのが一番うれしい」というような
ひどいことを言っていたくらいですから、このメンタリティーの違いは大きいです。

売り上げがでたらそこから開発会社にロイヤリティを支払うという、
レベニューシェア、いわば成功報酬型のやりかたもあります。
ところが、これも合意に至るのはなかなか難しいです。

新製品の開発で成功するのは、千三つ。夢をもって開発していても、
実際にそれが当たることは稀です。開発会社が損をするケースがほとんどです。

＝＝

■見えないが故の品質管理の難しさ

機械や建造物であればその見た目から品質感が分かる感覚があります。
ところが、プログラムは動かさないと分からないのです。
動かしてテストをするとその品質がようやく分かる。

インドで別な会社を見学しに行ったときのことです。
そこに駐在していたアメリカ人が嘆いていました。

彼はアメリカでビジネスプランを作り、それを具現化するためにインドの
会社でプログラム開発すべく、現地に乗り込んで監修していたのです。

「これ見てみなよ…」と指差す方にはべったりと手あかが。

その会社は新築のビルに入ったばかり。ところが、新しく塗ってある壁には、
見事に茶色い手あとが。そして新しいはずの家具も傷ついている。

個人主義が強いインドの文化の影響も多いのでしょう。
言われたことをやるけど他の人のことは構わない。
結果的にはこういうことが平気で起きる。

それが、プログラムを良く見てみるとあちらこちらに潜んでいるのだと。
ため息交じりに言っていました。

こういったことを克服するには、かなり強力な品質管理システムが必要なのでしょう。
欧米大手ＩＴ会社がインドで成功しているのはそういった仕組みを持ち込んでいるから。

その体力やノウハウが無いベンチャーではうまくマネジメントできないでしょう。
あるいは自分がよほどな辣腕プログラマーであればなんとかするかも知れません。

見えないが故の品質管理の難しさを克服するには、モチベーションの高い自社
技術者が自分たちのために「創り込みをするのだ」という気概で仕事をしてくれる、
今のところはそれしか無い、というのが学んだことです。

＝＝

何億円にもなる大きな授業料を払った失敗談でした。逆張りを頑張りすぎた例。
今は、品質が見えるような仕組みを自社で創り込んでいくという段階にあります。