<?xml version="1.0" encoding="utf-8" ?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<title>中国オフショアのブログ</title>
<link>https://ameblo.jp/linhanjp2013/</link>
<atom:link href="https://rssblog.ameba.jp/linhanjp2013/rss20.xml" rel="self" type="application/rss+xml" />
<atom:link rel="hub" href="http://pubsubhubbub.appspot.com" />
<description>ブログの説明を入力します。</description>
<language>ja</language>
<item>
<title>中国オフショア開発の実感②</title>
<description>
<![CDATA[ <p>実感①で、発注側の問題について記述したが、恐らく中国の受注側の立場の人間と思った方が多いね。</p><br><p>今回、中国受注側の問題点の事例を話す。</p><br><p>事例が沢山あるが、本日は、何年前（8年？）の話にする。あの時、私はブリッジSEとした。</p><br><p>中国B社へ30人月の仕事を一括発注した。プロジェクトとしては、既存のシステムから同様な機能を再構築する。</p><br><p>外部仕様は、既存のシステムと同様であるから、仕様伝達漏れのリスクがないと考えて、中国Ｂ社へ発注した。</p><p>中国Ｂ社の経営トップも、現在経験したプロジェクトより簡単であることを認識した。</p><br><p>プロジェクト開発期間が短いから、短期間で日本側から技術者の確保が困難であった。私が数社の選定先から中国B社を選んだ。</p><br><p>選んだ理由：</p><p>・短期間で15名の技術者がすぐ対応できる。　※オフショア開発が全盛期で、他社できない時期であった</p><p>・単価と工数が他社より安い。　　※最初の取引もあったが、経営トップが仕事を取りたい意欲があった</p><br><p>中国B社のプロジェクト管理、開発スキルに対して不安があったが、作業内容として簡単であったため、発注して直ぐ着手して貰った。</p><br><p>しかし、2週間後、恐ろしい進捗遅延を発生した。現場の状況を確認するため、私が中国へ出張を行った。</p><br><p>現場でさらに恐ろしい事実が把握した。プロジェクト管理、メンバーのスキルの問題が想像できない事実であった。※あまりもひどい話であったから、ここで略する。</p><br><p>すぐ、現地で中国B社の経営トップ、現場の技術主担当と会議を開き、対策を打った。中国Ｂ社に契約書通りに納品できない責任を説明し、プロジェクト直ぐリカバリ対策を要求した。</p><br><p>さらに、現場に行って、中国Ｂ社だけの対応は、リカバリできない現実も把握したから、契約を取りやめることは、日本側への影響が大きいであるため、東京側の技術者増員も行った。</p><br><p>増員2名の技術者は、中国B社への技術指導及び品質チェックを行った。プロジェクト管理に対して、私の作業時間も1人月を増やした。即ち、日本側で4人月を追加して、中国Ｂ社の対応を行った。</p><br><p>最後、予定した時期で、納品を行った。一部品質に問題があったが、瑕疵対応期間で問題なく解決した。早期問題を把握し、対策を行ったことで悪い結果にならなくなった。</p><br><p>コスト：</p><p>中国Ｂ社　25万×30人月　=　750万</p><p>日本側の対応　予定　70万×1人月　+　70×4人月　=　350万</p><p>予定：　820万　から　実績：　1100万</p><br><p>しかし、日本側で対応するなら、55万×30人月　=　1650万　よりコスト削減ができたことが事実である。</p><p>※予算としては、1650万が確保した。</p><br><p>さらに、実際は、短期間で技術者の確保ができない課題がクリアしたことが大きいな成果であった。</p><br><p>中国Ｂ社は、残念なから、プロジェクト管理、メンバーのスキルの低さにより、今後の契約の選定先から除外した。</p><br><br><br>
]]>
</description>
<link>https://ameblo.jp/linhanjp2013/entry-11525496334.html</link>
<pubDate>Mon, 06 May 2013 22:53:35 +0900</pubDate>
</item>
<item>
<title>中国オフショア開発の実感①</title>
<description>
<![CDATA[ <p>オフショア成功する為に、発注先選定が重要であることがよく言われている。</p><br><p>私もそう思う。</p><br><p>しかし、すべてと考えたら失敗してしまう事例がよくある。</p><br><p>私の職場も同様に、私担当したプロジェクトが中国Ａ社へ発注し、うまくできたから、別のプロジェクトも中国Ａ社に丸投げた。結果が失敗してしまった事例が数多くあった。</p><br><p>プロジェクトの失敗に対しては、案件単体の損失が無視できる程度（私担当外）多だったが、私が以下の損失が大きいだと思った。（他プロジェクトPMが思わなかった。）</p><br><p>・中国Ａ社の経営トップとコアメンバーの信頼関係が失ってしまった。</p><br><p>中国オフショア開発利用時、発注先の中国側の経営トップ、コアメンバーとコミュニケーションを充分に図り、会社対会社で、親密かつ対等なパートナーシップ、中長期的なWIN-WIN取引を行うことが重要である。</p><br><p>一つのプロジェクトで、数ヵ月間で発注先の会社とコミュニケーションをとり、管理層及び現場レベルでの良好なコミュニケーションをできたら、オフショア開発を確実に成功させるしくみができる。そのしくみを活かして、今後のプロジェクトコストさらに削減できる。</p><br><p>しかし、中国オフショア開発のしくみが無視している発注側の担当者であれば、簡単に信頼関係を潰してしまう。</p><br><p>中国Ａ社なら、オフショア開発経験が豊富、信頼関係も構築できた。発注者の仕事の進め方に問題を感じた場合、必ず問題提起してくる。しかし、発注者としては、その声に耳を傾けず、仕事の責任を丸投げながらプロジェクトを進めると、失敗したプロジェクトになるしかない。</p><br><p>すごく単純の考えであるが、言葉の壁が大きいという問題点が他プロジェクトからよく提出された。私は言葉の壁ではなく、中国側の会社との信頼関係が構築したくない本音だと思う。</p><br><p>プロジェクトのコスト削減より、楽な仕事を進みたいからと思ったでは無いかと思った。25～30万/人月より60～80万/人月のメンバーが使いたいだけだろう。プロジェクトのコストを意識しないのプロジェクト管理者に対して、失格だろう。</p><br><p>しかし、自分たちで失敗した事例を事例として、経営者に中国オフショア開発が無理であることを説明し、高いプロジェクト予算が取れることが、彼たちの実力である。これは、私が負けた。</p><br><p>私の感想に対して、発注側の担当としては反対意見が多いだと思うが、事例として言いたいことは、</p><br><p>・中国オフショア開発を利用するなら、開発コスト削減、下流工程の技術者の確保、開発スピートの向上の目標としてください。中国オフショア開発が流行しているなら、利用することをしないで欲しい。</p>
]]>
</description>
<link>https://ameblo.jp/linhanjp2013/entry-11525437836.html</link>
<pubDate>Mon, 06 May 2013 21:56:11 +0900</pubDate>
</item>
<item>
<title>はじめまして</title>
<description>
<![CDATA[ <p>はじめまして</p><br><p>日本のＩＴ業で数年間ブリッジSE担当している在日中国人です。</p><br><p>現在は、中国オフショア開発の専任では無くなって、プロジェクト全体の管理を行うPMを担当しています。</p><br><p>中国オフショア管理、一括発注の外注先管理よりは、プロジェクト内のメンバー管理が苦労しています。</p><br><p>各記事より、中国オフショア開発失敗事例を良く読みましたが、私の自身は、中国オフショア開発の方が楽勝だと思います。わりと、中国オフショア管理できない発注側のメンバー管理が苦労しています。</p><br><p>いつが、全体のプロジェクト管理ではなく、中国オフショア管理の専任に戻りたくてたまらない状態です。</p><br><p>中国オフショア開発の名として、ブログをひらき、自身の中国オフショア開発の経験を整理して、今後の仕事で再利用したいと思っています。</p><br><p>よろしくお願いいたします。</p>
]]>
</description>
<link>https://ameblo.jp/linhanjp2013/entry-11525398578.html</link>
<pubDate>Mon, 06 May 2013 21:36:50 +0900</pubDate>
</item>
</channel>
</rss>
