システム開発

  1. HOME
  2. 事業案内
  3. システム開発
  4. オフショア開発
オフショア開発
中国におけるオフショア開発のメリット

日本のお客様向けのシステム開発において、「品質・納期・コスト」のすべてでベストパフォーマンスを目指すなら、特に中国でのオフショア開発が最も適していると当社は考えます。
グローバルな観点でのオフショア開発拠点としては、インド、東欧諸国、ベトナム等も脚光を浴びています。その中でも、中国系IT企業は「強い価格競争力」・「日本企業との取引意識の高さ」・「地理的近さ」・「日本語能力」・「漢字文化圏」等々の理由より、弊社としては、最も「親しみやすい」と考えております。

各拠点間の作業分担・特徴

オフショア開発のフローイメージ

日本本社

日本本社は以下の役割に責任を負います。
・お客様とのインターフェース
・現状分析~要件定義~設計 ならびに 受入検査~総合テスト
・品質管理、進捗管理、仕様変更管理
・中国現地法人、中国パートナー様からのQ/A対応
・中国から納品される成果物の受入検証・最終出荷判断
日本本社における、技術スタッフの割合は、現在、日本人85%・中国人15%という構成になっています。
日本本社に在籍している中国人はいずれも日本語が堪能です。

中国現地法人

中国現地法人以下の役割に責任を負います。
・中国側窓口
・詳細設計~製造~テスト
・現地パートナー様から納品される成果物の受入
・品質管理、進捗管理
・通訳・翻訳
日本のお客様のニーズ、システムの実現方式を早期に習得、中国側へ展開する手段として、日本に出向き日本本社 もしくは お客様先にて、先行的に業務を遂行するケースも有ります。
又、お客様のご要望に従い、日本本社のエンジニアと一緒にお客様ご指定の場所で開発業務を行うケースもあります。
中国現地法人では、外部の講師を招聘しての日本語学習への取り組みも積極的に行っています。

オフショア開発15の勘所

その1.仕様書の徹底理解、意思の疎通が肝要

- 遠隔地にあるため日本国内にある場合と比べると何倍も伝わりにくい。
- 言葉の問題だけでなくビジネス慣習の違い、業務そのものに対する理解不足
- 数多い細かい仕様の一つ一つ(すべて)、漏れなく末端のPGまでに伝わらない。Bugになっ てしまう。
- メール、電話、TV会議の併用、100%確信が持てるまで。

その2.中国の現地開発会社との窓口には日中両方の事情に精通する中国系BridgeSEが必須

- 日中間のシステム開発に実績があって、優れたマネジーメント力のある優秀な中国系 BridgeSEが必須。
- 中国の現地会社との窓口として、日本人SEの場合、面倒を嫌がったり、習慣の違いを不快 感として感じたりする傾向があり、中途半端に“失敗”として終わる場合が多い。

その3.日中間のシステム開発に中国系の会社は強い

その4.日本人SEと中国系SEの使い分け

- 日本人SE: 顧客とのインターフェース、上流設計。
- 中国系SE: 技術面で日本人SEの補佐、中国現地との橋渡し。長年日本で仕事をしてきた 当社では、特に中国系技術者の優秀さをより正しく見分けることが可能です。

その5.日本の案件には中国の会社がダントツ有利

- 中国人は半年も勉強すれば日本語の仕様書を読めるようになる。
- 日本向けシステム開発を手がける中国のシステム会社は大抵日本向け専門のソフトハウ スで社員が日本語の勉強に励んでいる。
- 日本語の仕様書を全て、正確英語に翻訳することが不可能。スケジュールが厳しい場合の 多い中、難しい技術用語や元々詳しくない仕様書を正確に英語に翻訳すること自体が難 しい。
日本の顧客側SEが忙しい中、技術者宛て毎日のようにメールで来る細かい仕様変更まで英語に翻訳することが不可能に近い。

その6.中国現地会社の特徴をよく理解する

お見積もりが不得意
- 日本の会社よりも遥かに不得意。お見積もりの重要性に対する認識不足でチェックする体制 すら無いこともある。
- ビジネススタイルとして当初の見積もり金額で間に合わなくなったら相手に要求して来る。 確かに日本側に、仕様変更や当初からあいまいな部分も多い。
採算が取れない心情は品質の低下や更なる作業に対する抵抗感に繋がり、日本の顧客の 感情を著しく悪くし、悪循環に。技術的に自信を持つ反面、仕様軽視のところも以下のよう な意識があり、日本側の指導が必要
- Bugが見つかれば修正すれば良い --> テストフェーズの徹底。Bugのない物を納品。
- 画面、帳票等の細部、厳密さが不足 --> 日本顧客が求めているものを良く理解させる。
- 例外処理の不徹底、テストパターン不完全 --> テストフェーズの徹底。Bugのない物を納 品。
- 仮納品したら、完了と認識してしまう --> “Bugのない物を納品”した後も変更への対応や BugFixが続く。
しかし、中国現地会社の進歩は早いです。気がつかせ納得できるまで細かく説得する努力を続ければ徐々に改善。
当社の現地協力会社は3年前より現在まですばらしい成長を見せています。

その7.失敗に終わるパターン

仕様伝達が組織的、的確に行われていない
- 日本側BridgeSEまた中国拠点のMgrが力不足。
- 体制的な問題(人員不足、日本語力、技術力の不足)。
- 作業スタイルが不適切(設計から製造プロセスなど)
品質チェック体制が徹底されていない
- 仕様書レベルでの理解不足
- 末端のPG作業にチェックの目が届かなく、理解の度合いを設計書レベルチェックできてい ない。
- テスト仕様の作成などに手抜き。
- 成果物のチェックを段階に分けて体制的に行われていない 。
その他
- 見積もりの失敗で品質や開発プロセスへの悪影響。
- 体力以上の仕事を請け負ってしまう。

その8.中国人開発技術者を使うコツ

すべての作業要求に対し徹底した理由説明
- 仕様や技術作業。
- 頭で想定していたことが元々違うため“はい”と答えられても実際理解できていない場合が ある。
- プロジェクトのビジネス背景を完全に理解できないことがある。
- ほぼ完全に理解しないと動かない。
作業スタイル
- 日本人と中国人技術者の作業スタイルに違う所も多い。
- こちらが正しいことを言っているつもりでも、相手が無理な要求をしているとしか思われないと きもある。
- この日本人と中国人のスタイル上の違いを説明し切って、初めて理解してくれる 。
- 理解さえすれば動いていてくれます 。
本当に理解しているかどうかについて、開発プロセスの各段階(仕様書レベル、プログラムレベル)で成果物でチェック、確認する必要がある 。

その9.プログラマの困惑

末端のPGまで仕様が正確に伝わないとBugになってしまう
- 初期の仕様理解から開発途中での変更/追加要求まで、数の非常に多いポイントがすべて 末端のPGに正確に伝わる必要がある。
- しかし全員多忙の中、エンドユーザの細かいご要望が真ん中複数の担当者を通って末端の PGに正確に伝わることが非常に難しい。
末端のPGの困惑
- 仕様書が詳しくなく、どうすれば良いか分からない。
- 直属の上司に聞いても分からない。また直属の上司から上に聞いても答えが返って来ない。
意思疎通上の問題(真ん中で介在する人が多いので問題が出易い)。
中間に入っている方のミス、勘違い、場合によって怠慢。
最初から分かる人がいない。誰も結論を出さない。

その10.現地会社にとって望ましいパターン

製造できる詳細仕様書が出来上がってほしい。
詳細設計などのフェースは以下の事由で生産性が悪く、出来れば日本で細部に渡って仕上げてほしい
- 日本のお客様とのやり取りで物によって答えがなかなか返って来ない。
- ビジネス慣行など、ものによってはなかなか理解し切れない。
- 問題をクリアするためには打ち合わせが必要なこともあり、物理的に難しい 。
- 仕様決めなど非効率的で日本語への要求も高く限られた人員を必要とすることは、日本でや って欲しい。
製造のみなら特長を活かせて生産性が高い
- ハイスキルで日本語も上手なSEへの要求が低く対応しやすい。
- 製造のみなら投入できる人員も多くCostPerformanceが出やすい。
- 技術力も発揮しやすいし仕様書レベルのバグが少なくなりマネジーメントもしやすい
仕様上の問い合わせは最小限に留めたい。製造ならお任せください。

その11.日本のお客様が求めているもの

いろいろ問題があっても納品物が完全なもの。
日本顧客側の事情
- 案件によって“詳細に出来るレベル”が違う 。
- 更に上に顧客があり情報の入手に時間の掛かる場合は確かにある。
- 担当者またはその上で、複数のプロジェクトを抱えていたりしてタイムリーに対応できない。また、まとめる暇がない。
品質の良いものを時間通りに納品してほしい。

その12.日本側も中国側もGiveUpしないこと

日本側
面倒に思わないこと
- 相手は海外にいるし言葉の問題もあるので仕方がない。
説明し切れなければ現地へ
- 一緒に1週間でもいればすべて解決 。
中国側
相手から出て来なければ
- 自分でまとめ、確認してもらう。
- 場合によって自分から打ち合わせを持ちかけ聞き出す。
仕様未確定のものについて
- すべて記録しておいて確定した時点でFixする!
- 時間が経っても忘れないこと。
(仮)納品した後も作業が続く
- Codingが終わったら開発が終了という錯覚の如く、納品したら終わりというふうにと思わないこと!!!

その13.Bridge機能の特化

製造まで抱えると全体が見えなくなる
- 毎日、開発体制やそれぞれのサブ機能の進捗や品質チェックに追われ、全体が見えにくい。
- 進捗確保が優先され、品質のチェックが徹底しにくい。
Bridge機能に特化するメリット
- 第三者の立場で、より顧客のご要望や開発者の困惑などを聞き入れやすい。
- 仕様のチェック、品質のチェックに専念でき、より品質の良い製品ができる。
- 開発体制について助言したり進捗管理もしやすくなる。

その14.現地との協調スタイル

現地(子会社、協力会社)との一体化作業
- 顧客に対し同じ立場で活動する
- 日本側での設計段階から現地の担当者にも一部担当してもらい仕様の理解を早める顧客 のビジネススタイルに沿って活動する
- 仕様変更への柔軟な対応
- 「細部に渡って完全なもの」、「お客様が求められているもの」を作ることが最優先 仕様書に書いていないからなくても良い、というわけではない
- 金銭的な相談よりきちんとした作業が先。
現地の子会社、協力会社へ徹底した教育
品質に対する要求の高さ
- 仕様変更に柔軟対応。画面、帳票など細部に対する確認。
ビジネス習慣
- 納期の厳しさ。残業、土日出勤
- 仕様変更は開発プロセスにおいて回避できないもので、当然顧客のご要望にお答えできなければ次の案件へ続かない
- 見積もりはより正確に。
すべてにおいて徹底した理由説明

その15.中国での開発、成功しやすいパターン

技術力への要求、専門性が高いほど力が発揮しやすい
- 日本の一般的なソフトハウスより高学歴で専門性の高い方でも確保しやすい。またほぼ全員理工系出身。 通信系、組み込み系はより力が発揮できる
- 仕様書のボリュームが少なく技術調査、開発作業が多い
製品開発、カスタマイズは能動的になれて成功しやすい
- 技術者が能動的、積極的に 一般受託の場合あくまで受身。仕様と違うと怒られる恐れがある
このようなものってできない? などのプロトタイプ開発
- 存分に技術調査力、開発力を発揮できる

このページのトップへ