2008-07-14

過剰接待をしなくてもオフショア開発で生き残る方法

:::引用:::
本稿では上海の独立系小規模ベンダの中国人総経理から聞いた、オフショア開発を成功に導く独自の開発プロセス活用術を考察します。

活用したい日本企業に参考になる事例です。現役のプロジェクトマネージャやベンダ選定・評価に責任を持つPMO(Project Management Office)スタッフにとって、特に有益な情報となるでしょう。

 初めに会社概要と同社の成長の軌跡を紹介します。なかなか成長できなかった独立系ベンダがどのようにして一気に規模を拡大させたのか、その秘密に迫ります。次に、プロジェクトマネジメント知識体系“PMBOK(the project management body of knowledge)”を参考に、同社が独自に整備した標準開発プロセスの具体的な活用術を紹介します。最後に、組織力が自慢の小規模ベンダが規模を急速に拡大させるに当たり、想定されるマネジメント上の課題を整理して、取材者の立場から問題提起します。

オフショア開発ベンダの生の声

 それではここからは、オフショア開発ベンダのインタビューを掲載します。

聞き手:幸地司
話し手:上海同暢信息技術有限公司 総経理 高 国明氏

高 国明
  1962年生まれ。1984年に北京大学卒業後、日本の千葉大学大学院に留学。1992年ボーランド入社。コンパイラなどのソフトウェア開発に従事。 1997年独立しコムネットを設立、制御・ネットワークシステム開発や中国オフショア開発を中心に展開。2003年中国に帰国。上海にて電気設備メーカー のCIOに就任後、2005年日本向けのオフショア開発会社(上海同暢信息技術有限公司)を設立。同社総経理兼CTOに就任。
 計測制御システムや金融システムなど、大規模システムの開発、PMを多数経験。長年のオフショア開発のノウハウに基づき、自社独自のプロジェクト管理システム(TPMS)を構築した。

――これまでの会社成長の軌跡を簡単に教えてください

高氏:2005 年7月の設立以来、売り上げ・人員とも伸ばしています。ただし、ほかの中国ベンダと比べると、当社の成長率は低いと思います。なぜなら、会社設立当初は無 理に企業規模を拡大せず、まずは組織的なプロジェクト管理力の強化など、会社の基盤作りの強化を優先したからです。

 “組織的なプ ロジェクト管理力”とは、誰がリーダーになっても同じ方法で通用する“属人性の少ないプロジェクト管理力”のことです。企業規模が小さいうちに、しっかり とした仕組み作りをしないと、企業規模が拡大したときにプロジェクト管理力が著しく低下してしまうリスクがあるからです。

  2007年7月に、東京に販売営業拠点となる日本法人を設立しました。また、2008年1月には、河南省にソフトウェア開発センターを設立しました。ほか にも、組み込み系ソフトウェア開発とハードウェア設計が中心の無錫開発センターもありますので、上海本社を含めてグループで4拠点、開発人員は250人に なります。

上海同暢信息技術有限公司:会社概要
設立 2005年7月
本社 上海(浦東ソフトウェアパーク内)
資本金 230万人民元(約3500万円)
開発拠点 上海、無錫、河南省
日本支社 東京・新宿
役員構成 2人の中国人創業者と日本人役員1人
株主構成 創業者2人で株式100%保有
主要業務 業務アプリ系、Web系、組み込み系のソフトウェア受託開発、ハード設計(回路設計、PWB設計)、試作、生産

 河南省の開発センターは、ソフトウェア園区運営会社でもあるソフトウェア会社との合弁で設立しました。そこでは、主に業務系アプリケーション開発とWebソリューション系の受託開発を行っています。若いプログラマが多いので、主に下流工程で活用します。

 現在の日本法人は販売拠点としての機能がメインですが、年内に開発要員を配置したいと考えています。拠点ごとの従業員数ですが、多い順に河南省180人、上海50人、無錫20人です。そして日本法人は1人のみです。

図1:開発拠点ごとの要員数

――どのような仕事を請け負っているのですか

高氏:一 番多いのは業務系アプリケーション開発です。特に金融分野に自信があります。今年は、Web系のアプリケーション開発も増えています。組み込み系も事業の 伸びはゆっくりですが、力を入れています。今年はハードウェアや組み込み開発の拠点となる無錫開発センターに大きく期待しています。

――売り上げの推移と内訳を教えてください

高氏:2007 年度の売上高は600万人民元です。日本円でおよそ1億円です。1人当たりの売上高は、46人で割ると日本円でおよそ200万円。2007年の平均社員数 を割り出し、実際の稼働率を加味すると、1人当たりの年間売上高は日本円で320万円ほどになります。日本だと、1人当たりの年間売上高は1000万円が 目安なので、われわれの数値は約3分の1です。

 2007年の技術者稼働率は通年で80%以上を維持しました。売上規模が小さいの で、上海地区の同業者と比べるとかなり高い値だと思います。今年は規模を急拡大したので、稼働率は低下するものと予測しています。また、リピート受注率が 高く、売り上げの8割は当社と継続取引されるリピート顧客で占められます。

ラボ契約のメリットとデメリットは?

――日本企業との契約の形態を教えてください。一括請負契約とラボ契約、どちらが主流ですか?

高氏:一括請負契約とラボ契約の2種類です。現在は、仕事の9割を一括請負契約で請けています。ラボ契約は1割ほどで継続契約していただいています。当社としては、契約形態にこだわらず、案件内容やお客さまのニーズにより、契約形態を相談して決めています。

――発注者にとって、貴社とラボ契約を結ぶメリットは何でしょうか?

高氏:もしも、お客さまが安定して仕事を継続発注される場合は、ラボ契約のメリットが生まれます。ですが、仕様があいまいでスケジュールや仕事量が安定しないと、ラボ要員の待機が生じてしまいます。継続発注されない場合も、ラボ契約の良さは生かされません。

 初回取引はすべて一括発注から始まります。受発注者相互に仕事の進め方や力量が十分に把握でき、信頼関係が築けてから、ラボ契約に変更する方が良いと思います。お互いの信頼関係がないと、ラボ契約はかえって作業効率が落ちるのではないかと心配されるからです。

 お客さまにとっては、ラボ契約にすると仕様変更やリソースを調整しても、いちいち再見積もりする必要がなくなり、スケジュール調整のみで対応できます。

 お客さまは、まるで自社の従業員のような感覚でラボの技術者を臨機応変、柔軟に活用できます。一方で、お客さまにとってはラボ契約のデメリットも存在します。人員増加は歓迎されますが、急な人員削減は契約上難しいといわざるを得ません。

日本企業にとってラボ契約のメリット/デメリット
メリット
デメリット
  1. 安定的な開発リソースの確保
  2. ノウハウの蓄積
  3. 仕様変更、スケジュール変更等、臨機応変、柔軟な対応が可能(自前の開発リソースのように活用できる)
  4. セキュリティ向上(発注先パートナーのオフィス内にセキュリティルームを設置)
  5. 作業開始時に仕様が未確定の部分が多い案件でも適用可能
  1. 固定費化(仕事量が不安定で契約工数に満たない場合でも契約額の支払いが必要)
  2. 信頼関係が浅いパートナーの場合、開発リソースの質を落とされるリスク
  3. 運用を誤ると、緊張感の不足した取引となるリスク

独自の標準開発プロセス「TPMS」とは

――貴社と取引を始めるに当たり、お客さまはどんな点に留意すればよいのでしょうか

高氏:初 回発注時は、必ずお客さまに当社に来社していただきます。そして、両社のマネージャレベルが一緒に設計方針を策定します。同時に、品質保証や進ちょく管理 の手順を詳細に決めます。当社は、独自の標準開発プロセス(Touchdown Project Management System:TPMS)を持っていますので、お客さまが指定される報告・連絡ルート、途中段階の設計が終わったら、誰が何をどのような手順でやるか、構 成管理の手順などとTPMSをすり合わせて、最適な枠組みを一緒に決めます。

 TPMSは、よくある開発標準規約やプロジェクトマネジメント知識体系と以下の点で異なります。最も異なる点は精度が細かい点です。TPMSは、実際のオフショア開発プロジェクトで適応されながら、当社の社風や実態に合わせて最適化されつつあります。

  例えば、構成管理は、どういう手順でどのタイミングでチェックイン/チェックアウトするかなどの当たり前の動作が、数十ステップにわたり詳細に定義されて います。通常は、お客さまごとに異なる構成管理のルールが存在します。賢い人なら、すぐに構成管理を覚えられると思われるかもしれませんが、初めて取引す るお客さまの基準を知らないと間違いなく現場は混乱します。

 われわれのような知名度のない小規模ベンダは、初回取引で失敗すると次の機会がありません。ですから、構成管理の手順を細かく定め、各メンバーの役割と権限を厳密に定義します。もちろん、お客さまの意思を確認した上でTPMSを運用します。

――お客さまがひと言「構成管理をちゃんとやってください」と指示すればいいような気がします。なぜ、お客さまに手間を掛けさせてまで、詳細なTPMSを策定するのでしょうか

高氏:私 が直接プロジェクトを担当する場合は、ひと言「構成管理をやりましょう」と指示すれば終わります。ですが、私は社長ですからすべてのプロジェクトに介入で きません。当社のチームリーダーは20歳代後半が中心です。実務経験は5年くらいです。日本語の読み書きには不自由しませんが、顔を見ないで話す電話会議 は難しいレベルです。プログラマは、23歳か24歳くらいです。実務経験は2年ほどにすぎません。

 このような若手主体のチームメンバーに「構成管理をちゃんとしましょう」といっても、残念ながらお客さまの真意は伝わりません。つまり、過去にきちんとしたプロジェクト管理を経験していなければ、とても日本企業の要求には応えられません。

 リーダー1人とプログラマ2人の小さなチームなら、TPMSがなくても大きな問題は生じないでしょう。ですが、チームが大所帯になると混乱が起きます。しかも、お客さまの担当窓口が変わってしまうと、そのたびに説明し直さなくてはいけないとしたら、それこそ大変です。

 日本企業も、中国と同様に構成管理が徹底されていないと思います。中国人でも日本人でも、頭では理解しているものの、実際には「面倒だからいいや」という感じでやってしまうこともあるでしょう。

 今後、組織が大きくなると頻繁に人が入れ替わるようになるでしょう。この状況は避けられないと思います。しかし、絶対に崩れない仕組みを作っておけば安心だという発想です。組織が小さいうちにしっかりとした基盤、仕組みを作っておきたいのです。

 若手プログラマにとって、構成管理は面倒な存在です。でも、慣れれば楽になるし、操作も簡単です。受注から納品まで、そして納品後もいつ修正されたかなど、すべて状況が記録されるので、状況を正確に把握できます。

図2:平均的な中国ベンダの開発要員ピラミッド(人口ピラミッド)

――構成管理のほかにもTPMSはどのように役立ちますか

高氏:実は当社独自のTPMSといっていますが、マネジメント上の新しい概念はありません。繰り返しになりますが、TPMSの特長は当社の実態に最適化されていることです。例えば、「CMMI(capability maturity model)」に取り組んだとしても、概念が抽象的過ぎるといまの中国では運用されません。でもTPMSなら、確実に運用できます。

 例えば、Q&A票を使って日本に質問するのは当たり前ですが、どのように質問すればいいか、などの詳細な手順を22ステップのフロー図で定義しています。この22ステップ数が多いか少ないかは別として、中国では定義する必要があるのです。

 例えば、5人チームでお客さまから基本設計書をもらったとき、5人が同じQ&A票を起票することがあります。もしも、5件のQ&A票がすべてお客さまに届いてしまうと、お客さまは「この会社はどういう会社なんだ、まったく管理できていない!」と憤慨なさるでしょう。

  このような初歩的なトラブルを防ぐために、22ステップものQ&A手順が必要になります。当社では、すべてのQ&Aをプロジェクトリーダーがチェックしま す。社内で解決できるものは、お客さまには絶対に流れないように仕組み化しています。単純ですが、絶対にミスを起こさないような仕組みになっています。

 なぜ、TPMSでそこまでやるかというと、人材流動性が激しい中国では手順をきちんと定義しないと、後から入社した者が必ず問題を起こすからです。当社では、過去に何度も同様のミスを発生させていました。ですから、TPMSを策定し運用を徹底しているのです。

  ほかにもTPMSには特徴的な取り決めがあります。TPMSには、「すべてのタスクを2日以下にする」という厳格な基準があります。当社のWBSでは、最 下位のアクティビティはすべて2日以内の作業量に収めます。これを実現するには、高等なテクニックを要します。例えば、画面モジュールを作るのに、ベテラ ンのリーダーでもこの作業に5日ほど費やしてしまうような作業があるとします。それを当社では3つのタスクに分割する独自のノウハウで実施することで、こ れを2日以下にするのです。

 「すべてのタスクを2日以下にする」ことが実現できれば、万が一のことがあってもリカバリーは単純で す。そして、進ちょく報告では0%か100%だけが許されます。たとえ10年選手でも、進ちょく報告に主観が混じると間違いを起こします。ですので、当社 では100%完成しない限り、進ちょく率は0%と見なされます。

 今年は河南省開発センターでもTPMSを適用させます。当面は、上海本社からリーダーを派遣して、プロジェクト単位でOJTによる指導を図ります。

見切り発車への対応策は?

――どのような開発スタイルを採られていますか

高氏:一 括請負開発が多いので、基本的にはウォーターフォール型です。ですが、日本のお客さまは仕様変更が多いので、アジャイルのような繰り返し型を併用します。 当社が自信を持っている金融系プロジェクトでは、仕様変更に時間がかかるものや仕様自体に問題の多い場合は、中国で作れるものから先に作ることができま す。

――中国側の判断で勝手に見切り発車すると、ものすごくリスクが高いと思われますが、いかがでしょうか

高氏:当社の場合、リソースやコストの心配はありませんが、スコープのリスクが顕在化すると影響は大きいです。そのために、TPMSで仕様変更を管理しています。

  従来は、電話やメールで簡単に仕様変更の依頼を受け付けていました。当然ながら、誰も管理できなくなり、納品後に「言った、言わない」のトラブルが発生し ました。いまでは「全角文字から半角文字への修正」といった小さな対応まで、すべての仕様変更において仕様変更依頼書を作成して管理するよう心掛けていま す。このような仕様変更依頼書が必要な理由は、先ほど申し上げた通りです。

 また、当社の仕様変更依頼書はExcelで運用しています。仕様変更があれば、お客さまから仕様変更依頼書をメールでいただきます。ですが、一部では仕様変更を記録しないプロジェクトもあって、やはりそこだけトラブルに陥ってしまうことがあるのです。

――変更管理の徹底は素晴らしい概念ですが、ラボ契約のメリットを殺すような気がします。いかがでしょうか?

高氏:ラボでも、仕様変更管理を実行します。はたからは、面倒に見えるかもしれませんが、当事者にとっては苦になりません。人数が増えれば増えるほど、変更管理の徹底が威力を発揮します。

  当社のラボでは、仕様変更を随時受け付けています。当社が受注する範囲は基本設計から結合試験までです。成功したプロジェクトでの仕様変更の割合は約 30%です。見積もりと実績がずれる最大の原因は「仕様変更」です。次に、お客さまの都合で最初から予算枠が決まっていることがあります。取引実績を増や すためにやむを得ず、少ない工数で見積もりを出します。

図表3:工数超過の原因分析

 そのほかの要因には、コンポーネントがうまく動かないなど、外部要因による工数超過が見受けられます。最近はPHPなどの新しいフレームワークを使うことが多いので、経験不足によって担当するフレームワークのバグを理解できていない、などがあります。

  また、小規模プロジェクトの見積もりは、現場のリーダーに任せっ切りになるため、どうしても仕様確認の詰めが甘くなりがちでした。粗過ぎる仕様を、お客さ まに質問しないまま判断して見積もりを提出してしまうと、後になってトラブルになってしまいます。この場合、工数超過分はすべてオフショア側が負担すべき だと考えています。それでも、30%までの工数増なら許容範囲となるように生産性を高める努力を続けています。

――オフショア開発として受託する平均的な仕事の大きさは、どのくらいですか?

高氏:平 均的には20人月の案件が多いです。過去最大は200人月です。組み込み系開発では、1人月からでも仕事を請けます。初めての取引では、無償評価してもら う制度があります。業務系アプリケーション開発では無償評価制度なんて不要ですが、拡大余地のある組み込み系案件では挑戦する価値があると思っています。

図4:売上高と開発要員の推移



自分で挙げる今後の課題は?

――最後に、貴社の今後の課題についてお聞かせください

高氏:直面する課題を3点ほど挙げます。

  • 業務ノウハウの蓄積と上流工程要員の育成
  • 日本語会話力の強化
  • 河南省開発センターへのTPMSの完全浸透化

 まず第1点の課題は、「業務ノウハウの蓄積と上流工程要員の育成」です。

 一般的に中国では、「技術力」というと、「プログラミング技術」だと誤解している技術者が多い傾向にあります。しかし、本当の意味ではいくらプログラミング技術が優れていても、それだけでは一流の技術者とはいえません。

 弊社では、業務ノウハウも技術力の一部であるとの考えに立ち、業務アプリ系の全技術者に1.5分野の業務ノウハウの習得を目 標に育成しています。各自1つの分野をマスターし、さらにもう1つの分野ノウハウを半分でも身に付けるという意味です。業務ノウハウを弊社の付加価値の1 つとし、より幅広くお客さまのニーズに応えられる体制作りを目指さなくてはなりません。これは簡単なことではありませんが、ぜひともチャレンジしなくては ならない課題だと考えています。

 現在は、継続取引をしていただいているお客さまに中国出張の際、講師をお願いし、研修会を行ったり、教材をお借りして、社内研修会を行ったりしています。また、日本業務経験があるコアメンバーによる社内研修会も開催しています。

  このような机上の研修も必要ですが、やはり実際の開発業務の中で、技術者各人が「1.5分野の業務ノウハウ習得」を強く意識しているか、意識していないか は大きな差だと思います。例えば、ただ単に仕様通りに開発を行うのではなく、「なぜこのような仕様になっているのだろうか?」と考えるか考えないかで、大 きな差が出てくると思います。

――2点目の課題は、「日本語会話力の強化」ですね

高氏:弊社は、会社設立以来、日本向けのシステム受託開発100%で事業展開をしてきました(中国現地日系企業向けも一部含む)。中国オフショア開発では常識になっていると思いますが、弊社でも仕様書や打ち合わせ、報告書、電子メールなど、日本語100%で対応しています。

 ほかの中国企業でも同じ考えの企業が多いとは思いますが、通訳を介した開発は失敗リスクが高まるため、技術者自身が日本語を習得する基本方針を持っています。従って、技術者の日本語力向上に注力してきました。

  日本語専門の教師を社員として採用し、毎日定時後に日本語研修を行っています。また、日本語力も1つの人事評価指標に位置付け、全技術者に日本語力向上の インセンティブを与えています。そのため、社員の中には休日を利用して自主的に外部の日本語学校に通う者も少なくありません。

 また、日本語検定試験に合格した場合、各自が個人的に負担した研修費用を会社が負担する制度も導入しました。

 これが功を奏し、勉強を始めて間もない新人を除くと、日本語の読み書きは、ほぼ全員問題がなく対応可能であり、社内でのメールのやりとりも日本語を利用する者もいるくらいです。

  しかし、お客さまと日本語で技術打ち合わせができるレベルの技術者となると、残念ながらまだ十分とはいい切れません。幸いにも新たに設置した河南省開発セ ンターでは、以前より日本の仕事がしたいという技術者が多く、日本での業務経験もある技術者もおり、日本語レベルは比較的高いのですが、今後さらに組織が 大きくなると、日本語会話力がある技術者を育成、採用することが重要課題の1つだと考えています。

 現在、日本語を勉強中の技術者 は結構日本語会話ができるのですが、実際に日本人と会話する機会が少なく、いざとなると話せないケースが多々あるように思います。やはり、外国語の会話力 は机上のみではなく、日本語100%の環境で生活することで自信がつき、著しく会話力が向上すると思います。従って、今後は日本法人に研修を兼ねて、交代 で常駐させる制度も準備中です。

――最後に、「河南省開発センターへのTPMSの完全浸透化」については、どうお考えですか

高氏:3つ目の課題は、先月から新設した河南省開発センターへのTPMSの完全浸透化です。弊社は開発体制拡充の一環で、今年より河南省開発センターを新設し、グループ総勢46人から一気に250人体制になりました。

 通常で考えると、このような急激な規模拡大は管理力低下に直結し、間違いなく品質面、納期面のトラブルが続発します。私どもも過去、急成長し過ぎ、不幸にも力を落としてしまった中国企業を目の当たりにしています。

  しかし、河南省開発センターは新規に設立した拠点ではなく、現地のソフトウェア会社のODC(オフショア開発センター)という部門のみを対象に資本提携し た開発拠点です。従って、日本向け案件の受注実績もあります。弊社はCMMIに取り組んでいませんが、合弁相手の会社はCMMIを達成し、社内の管理制度 を整備してきている会社です。しかし、CMMIを達成していない私どもがいうのもおかしな話ですが、CMMIのみでは安心できないのです。やはり、河南省 開発センターにもTPMSを完全浸透化させなくてはならないと考えています。

 実はこの開発センター設立に関し、1年以上前から入 念な準備をしてきました。同社は弊社設立以来、付き合いのある協力パートナーでもあり、今回の河南省開発センター設立を1年以上前から計画し、同社のキー パーソン数人に上海に長期滞在してもらい、弊社の技術者と一緒に仕事をしてきました。従って、彼らはTPMSを経験的に習得できたのではないかと思いま す。

 現在はこれらのキーパーソンが河南省に戻り、かつ、上海本社からリーダークラスの人材を派遣し、同開発センターへのTPMS の完全浸透化を図りつつあります。しかし、油断は禁物で「事を急がずじっくりと!」と考えています。なぜならば、私ども上海本社でもTPMSの完全浸透化 に1年はかかりました。河南省開発センターには、まずは難易度の比較的低い案件からスタートし、TPMSの浸透状況をチェックしながら、徐々に対応案件を 拡大していきたいと考えています。

マネジメント上の課題を指摘する

 業界標準であるPMBOKを参考にした独自の開発プロセスを駆使した取り組みは、とても興味深いと思います。営業や過剰接待にうつつを抜かす他社とは異なり、中国人総経理が技術トップを兼ねるため、品質に対する意識の高さもこちらが舌を巻くばかりです。

  最後の締めとして公平さを期すために、インタビューを掲載するだけでなく、インタビュー企業にとって耳の痛い話もしたいと思います。本稿では、インタ ビューと称して特定企業を褒めちぎるちょうちん記事を垂れ流すことはありません。ここから最後までは、あなたも意識を変えて読み進めてください。

 本インタビューでは、忘れてはならない制約条件が2つあります。

  1つ目は、紹介した取り組み(TPMS)は発展途上の未完成品であり、決して万能ではないということです。実際、TPMSは社員数50人未満の状態での運 用がほとんどでした。そのため、TPMSが大規模プロジェクトにも耐え得るかどうかはまったくの未知数です。同社は、今年に入って要員規模を一気に5倍以 上も拡大させましたが、TPMSが正しく運用されるかどうかは誰にも分かりません。いくらきれいごとを並べて、未来の夢物語を語っても無意味です。 TPMSが大規模プロジェクトでも通用するかどうかは、あくまでも実績で示すしかありません。

 2つ目は、今年新設した河南省開発センターに関する制約条件です。同開発センターには現在180人のプログラマ集団が在籍し ますが、彼らのすべてが稼働しているわけではありません。すなわち、会社として180人の技術者をマネジメントした経験を持つわけではなく、実質的にはバ ブルのように膨らんだグループ人員規模は一瞬のうちに縮んでしまいます。これが、急成長を続ける中国オフショア開発ベンダの裏の顔です。私の指摘に対し て、高総経理は次のようにコメントしました。

 私どもは過去にバブルのように急成長し、堕落していった数多くの中国企業を目の当た りにしているため、これらの企業を反面教師にしています。彼らと同じ二の舞にはならないようにと、かなり以前から考えていました。一気に180人増員した からといって、すぐに180人分の仕事を受注しなくても問題ありません。過去数年、上海に派遣されOJTでTPMSを学んだ河南省のキーパーソン数人と、 上海から河南省に派遣するリーダークラスの人材とで、河南省開発センター全体にTPMSを浸透させます。もちろん私や、プロジェクト管理総括責任者(もう 1人の中国人役員)も定期的に指導、チェックしにいきます。

 こちらも「お手並み拝見」といったところでしょうか。結果が出るのは早くても1年後でしょうから、可能性ではなく実績で評価したいと思います。

  私たちは、中国ベンダがときどき主張する「中国No.1」や「規模拡大うんぬん」を真に受ける必要はありません。実態を大きく見せる中国式のリップサービ スだと解釈して軽く受け流すくらいでちょうどよいでしょう。この程度で、無慈悲に中国批判を繰り返すほどやぼなことはありません。

 とはいいながらも、これまでの中国は日本人の想像をはるかに超えたレベルで成長を遂げました。もしかしたら、不可能を可能にする突拍子もないアイデアが生まれるかもしれません。

 最後に筆者から皆さんに演習問題をプレゼントします。

【課題】
  2005年7月に創業し、2007年末時点で従業員46人の会社が、2008年2月初頭には250人に増えました。この会社の強みは2つあったことを思い 出しましょう。1つ目は、幹部社員の豊富な発注経験(TPMS構築力)。2つ目は、幹部が手間暇を掛けてOJTで新人を育てる組織力です(TPMS浸透 力)。

 この会社の強みを生かして、TPMSを大規模に展開させる案を考えなさい。

【回答例】
  従来路線の延長では、自慢の品質を維持したまま5倍以上の急拡大は不可能。インタビューで高総経理がいった通り、増員した180人を一気に稼働させるのではなく、発展速度を緩めながら、別の打開策を見いだす。

■打開策1
  高品質&少数精鋭の上海本社と人海戦術の河南省開発センターとはブランドを分ける。成功のカギは、初級プログラマ集団を売りまくる営業部隊と労務管理に長けた現地マネジメントの活躍次第だ。

■打開策2
  独自技術で勝負する。卓越した独自技術を武器に大規模案件を一括受注して、河南省開発センターを維持拡大する。現在の「組織力」を武器にしても、日本市場 への訴求は弱い。「組織力」や「マネジメント」はオフショア受託成功の必要条件だが、十分条件ではない。成功のカギは、日本企業に技術指導が可能な水準の 独自技術を蓄積。会社紹介資料から「プロジェクト管理体制」や「セキュリティ管理体制」といった必要条件に相当するページを減らして、技術やノウハウと いった十分条件に相当するページを増やすこと。

 これらが唯一の正解ではありません。あなたも中国ベンダの経営幹部になったつもりで、頭を柔らかくして、一緒に問題解決の道筋を考えてみましょう。

筆者プロフィール
幸地 司(こうち つかさ)
琉球大学非常勤講師
オフショア開発フォーラム 代表
アイコーチ株式会社 代表取締役
沖縄県生まれ。


九 州大学大学院修了。株式会社リコーで画像技術の研究開発に従事、中国系ベンチャー企業のコンサルティング部門マネージャ職を経て、2003年にアイコーチ 株式会社(旧アイコーチ有限会社)を設立。現在はオフショア開発フォーラム代表を兼任する。日本唯一の中国オフショア開発専門コンサルタントとして、ベン ダや顧客企業の戦略策定段階から中国プロジェクトに参画。技術力に裏付けられた実践指導もさることながら、言葉や文化の違いを吸収してプロジェクト全体を 最適化する調整手腕にも定評あり。日刊メールマガジン「中国ビジネス入門~失敗しない対中交渉~」の執筆を手掛ける傍ら、東京・大阪・名古屋・上海を中心 にセミナー活動をこなす。

オフショア大學:http://www.offshoringleaders.com/
オフショア開発フォーラム:
http://www.1offshoring.com/
アイコーチ株式会社:http://www.ai-coach.com/
■要約■
今回は月平均5~7人の規模で若い中国人プログラマを活用し、そのメリットを享受したい企業へ向けて、今回は中国でオフショア開発専門のソフトウェアベンダを経営する現役総経理である高氏に話を聞いた。

高氏の企業では、プロジェクトマネジメントの属人性を極力排除するために、独自の標準開発プロセス「TPMS」を開発し徹底させることにより、構成管理を 行っている。なぜなら、プログラマやリーダーのほとんどが20代であるため、開発プロセスを徹底しなければ、プロジェクトを円滑に進行させることが難しい ためだ。

この企業には、2つの注意点がある。1つ目はこのTPMSは発展途上の未完成品であり、現在の社員数での運用は未知数である点だ。2つ目は、新設した河南 省開発センターに関する問題だ。同開発センターには180人のプログラマが在籍するが、この180人の稼働率をいかに維持するかが今後の大きな課題になっ てくる。
●●コメント●●

0 件のコメント: