要約(6)：ソフトウエア企業の競争戦略

今まで以下のように5回にわたって、ソフトウェア企業の競争戦略という本の
要約を書いてきましたが。

http://d.hatena.ne.jp/hidekoji/20050504
第一回：ソフトウェアビジネスの業態とソフトウェア企業のライフサイクルについて。
http://d.hatena.ne.jp/hidekoji/20050505
第二回：ターゲットとすべき対象について。
http://d.hatena.ne.jp/hidekoji/20050507
第三回：ターゲットとすべきマーケットについて
http://d.hatena.ne.jp/hidekoji/20050508
第四回：The Software Factory (ソフトウェア工場) Solutionが何故うまくいかないのか？
http://d.hatena.ne.jp/hidekoji/20050509
第五回：Synch-and-Stabilize(同期させ安定させる)

このシリーズは今日でおしまいにしようかと。

最後に取り上げるトピックは、第4章で取り上げられていた、Outsourcing to India and Elsewhere (インドやその他の地域へのアウトソーシング)にしようと思います。いまや、インドなしではソフトウェア企業は成り立たないといっても過言ではないほど、インドへの依存度は高くなってきております。

本書の中では、HQで設計、インドで実装という"factory-like"なスタイルにすると、sync-and-stabilizeの方法を取るのが難しいと指摘しています。

小職が勤める会社も、インドに開発拠点があり、HQで設計、インドで実装というスタイルなのですが、sync-and-stabilize式で開発はされています。
これは、地理や時差等の問題を、webを通じたコミュニケーション・ツール等をうまく活用したプロジェクト・マネージメントによって可能となっています。ただし、このknow-howがたまるまではやはり苦労したみたいです。

ちなみにHQ(米国)、インドとの役割は以下のように分かれています。

HQがすること

HQは、アプリケーションに関する要求/要件の取りまとめ、それにともなうハイレベル・デザイン(仕様の決定等)を行います。また実際の開発フェーズではプロジェクト・マネージメント(スケジュール、スコープやメンバーのアサイメント等の管理)を行います。コーディングは行いません。この他としては、私が参加したプロジェクトでは、HQでUIプロトタイプ(mockup)の作成やデータ・モデル管理(DBのテーブル設計等)は行ってました。

インドがすること

HQが作成した、仕様をもとに、詳細設計とコーディング、およびテストを行います。また、既に製品として出荷されているコードのメンテナンス(Bug対応)もインドがやっています。

このように、小職が見て知っているインドの活用例は上記のようですが、悩みの種としては、やはり優秀な人材は取り合いになるらしく、長く留まってくれないというのがあるみたいです。実際、小職も仲良くなったインド開発センターの開発者が米国の別のソフトウェア企業にヘッドハントされてました。

実際には、HQにいるDev ManagerやProduct Managerもインド人だったりするので、結局HQだろうとインドだろうと、どっちにしろインド人による開発という感じなのですが。。

以上でソフトウエア企業の競争戦略の要約シリーズは終わりです。