|
- |
なぜ日本は中国で失敗し続けるのか？ |
なぜ多くの日本企業は、中国オフショア開発で失敗し続けるのでしょうか？
これまで日本企業はシステム開発に関して数ある選択肢の中から、中国オフショア開発を選択してきました。それが、今日のIT業界は私たちが好むと好まざるとにかかわらず、中国やインドなど海外IT企業との共存が必要不可欠になってきています。日本企業の担当者が中国渡航しなくても、彼らの方から日本に押し寄せて、日本語で立派なプレゼンテーションを披露する時代になりました。
|
- |
事例から原因を研究する |
■不信感だらけのソースコードレビュー
ある中国オフショア開発プロジェクトの検収結果が届きました。いくつかのバグが見つかったため、残念ながら一発では検収が通りませんでした。よく調べてみると、コーディング規約に従ってないソースコードの書き方も若干あります。ソースコードレビューは何回もしていたはずなのに……。
日本企業の開発コーディネータ（以下、日本）は、バグの原因を探り、再発防止に努めなくてはいけません。開発コーディネータと中国ベンダの開発リーダー（以下、中国）は、以下のような会話をしています。
|
日本 |
「中国側のソースコードレビューはどうなっているのですか？ 先日報告されたソースコードレビューの報告書を読みましたが、何をどのようにレビューしたのか、よく理解できませんでした」 |
|
中国 |
「ソースコードレビューで重点を置くのは、コーディング規約の確認です。ソースコードレビューは、別部署のリーダーである李さんに応援してもらい、既に3回も実施しました。李さんは、当社でも特に技術力に優れている人物です」 |
ところが、中国側の報告内容には次のような不信な点があります。
- ツールを使ってコーディング規約をチェックしているのに、なぜか規約違反がある
- ソースコードレビュー会議で発言したのは、なぜか李さん1人しかいない
日本人の開発コーディネータは、ソースコードレビューの形骸化を懸念しています。ソースコードを1行ずつ丹念にチェックする根気強さが、中国側には不足していると感じています。実際、検収は一発では通りませんでした。そこで、開発コーディネータは中国側リーダーに対して、ソースコードレビューを再度実施するように指示します。ところが、中国側の回答は意外な内容でした。
|
日本 |
「コーディング規約を準拠しているかを再度見直すとともに、机上でのデバッグをもう1度実施してください」 |
|
中国 |
「ご要望は分かりました。しかし、机上でのデバッグですが、その作業工数は非常に多いと思います。通常、当社では実施しません。紙の上でソースコードを追いながら要求仕様を確認する方法などは、コーディングやり直しと実質的に変わりません。要求仕様の確認は、PC画面上からのテストで検証するものです。本当に必要でしょうか？」 |
さらにこう続けます。
|
中国 |
「検収で見つかったバグはもうすぐ修正されるので、プログラムは安定稼動します。したがって、わざわざ追加費用をかけてもう1度ソースコードレビューを実施しても、その効果には疑問があります。もし、机上のレビューだけですべてのバグは防止できるとなると、バグ摘出目標を上げる品質指標値の意味がないですね」 |
その言い分は理解できますが、開発コーディネータはどうしても納得できません。日本側が反論する前に、中国ベンダのリーダーはさらに追い討ちをかけます。
|
中国 |
「当社の方針では、最も重要なのは納期を守ること、そして品質を確保することです。品質保証はプログラムの動作確認テストが効果的です。画面上から動作確認するテストが最も優れていると思います。 テスト項目を増やし、何度も繰り返してテストするとバグ摘出率は高くなります。ソースコードの仕様チェックの概念はいいと思いますが、効率は良くないのではないでしょうか。例えば、あるプログラムを1時間かけてテストすると、効率よくバグが発見できるでしょう。 ところが、机上でのデバッグとなると、レビュー者と担当プログラマが2人で一緒にソースコードレビューしなければなりません。2人で半日かけてレビューしても、バグの発見は難しいのではないでしょうか。 また今回のプログラムには、複雑な計算アルゴリズムなどはありませんから、その観点での机上でのデバッグは必要ないと思います。 従って、当社としては動作確認テストを優先し、もし時間に余裕があれば、後からソースコードの仕様チェックを行う。これでよろしいでしょうか？」 |
以上が、中国オフショア開発の一例です。
|
- |
中国オフショア開発の教訓 |
■教訓「報告をうのみにした開発コーディネータ」
中国ビジネスで日本人が成功できない理由の1つとして、「相手を信じ過ぎる」ことが原因というのが定説となっています。中国オフショア開発では、「すべて確認しました。もう大丈夫です！」などの作業報告をうのみにする事象が当てはまります。
オフショア開発で成功する企業には、相手国の文化やコミュニケーションの傾向を察知する目の肥えたコーディネータが欠かせません。“目の肥えた”コーディネータとは、失敗事例から教訓を得て、日本流のプロジェクトマネジメントとオフショア開発委託先の企業文化を見事に融合させることができる人物です。
■教訓「経験不足のうえに土俵が異なるようでは、成功はおぼつかない」
中国ベンダでは、20代後半から30代の若手SEが、主に全体の統括リーダーを務めています。大半のリーダーは技術的に優れているのですが、やはりコミュニケーションに不安が残ります。納品したシステムに重大なバグが見つかるなど何か問題が生じたとき、日本から厳重に抗議しても、その重大性がベンダ幹部に報告されないことがあります。
中国ベンダ社内で情報が伝わらないのは、主として情報管理体制の甘さから来るものですが、同じくらい重大な理由として技術者の気質の問題が考えられます。ただし、中国人は品質意識が低いとか、頭が悪いとか、そういう次元ではありません。単に、日本流のきめ細かな報告・連絡・相談の経験が、決定的に不足しているからだといえるでしょう。
今回取り上げた事例では、中国のレビューに対する考え方が日本の教科書的な考え方とは根本的に異なることを示しています。
|
|
日本 |
中国 |
|
ソースコードレビューの目的 |
要求仕様との整合性などあらゆる面から、ソースコードの細部までを厳密にチェックすること |
コーディング規約やプログラミング技法の指導や確認 |
|
アプローチ |
ボトムアップ的な改善 |
トップダウン的な指示 |
|
レビュー実施者 |
関係者全員 |
理解している者1人 |
|
レビュー指摘事項の周知方法 |
みんなで頭を突き合わせて検討するので、その場で関係者全員に周知 |
有識者が1人でレビューした結果を、後からおのおのの担当者に伝達。指摘事項が全体で共有されることはない |
以上の教訓を踏まえて、この失敗例への対策を次のように整理しました。
- 日本流の開発プロセスの指導強化
- 結果報告をうのみにせず、プロセスの実施状況をしっかりと確認
|
- |
その他の事例では |
そのほか、中国オフショア開発の失敗例をまとめました。
■中国オフショア開発の失敗例
- 上流工程から任せてほしいというベンダの主張を受け入れ基本設計から委託したが、実際には最初から最後まで日本人技術者が中国に常駐しており、コスト削減の効果はほとんどなかった。
- 契約締結時にベンダへ自社の開発標準マニュアルを提供した。ところが、いざふたを開けてみると、マニュアルは十数年前に制定されたレガシーシステム開発を対象とした内容であり、オープン系開発ではまったく役に立たなかった。
- 試験発注の小規模プロジェクトで成功したので、次は本格的に大規模プロジェクトを発注した。ところが、前回担当したプロジェクトリーダーはすでに離職しており、また最初から説明をし直すことになった。
- ベンダとの契約交渉時に、過去プロジェクトで用いたドキュメントのサンプルを見せてほしいと依頼したら、顧客名が記載された設計ドキュメントのコピーをそのまま提示してきた。機密保持の意識がまったくないようだ。