オフショア開発への切り替えの障害

オフショア開発に対する日本と欧米の違い

欧米系の企業はトップダウンで物事が決まっていきます。
オフショア開発への切り替えもトップが決めれば、すぐに動き出します。そのため、欧米系の企業のオフショア案件は、大規模で発注工程も基本設計からシステムテストまで幅広いそうです。

一方、日本企業はボトムアップで物事が決まっていきます。トップから指示が出ても、現場がいうことを聞かないといったことがよく起こります。
オフショア開発への切り替えでも、トップが指示を出しても現場の抵抗に遭いなかなか進まないと聞きます。

その違いは発注量から見ても明確です。欧米はシステム開発の10%がオフショア開発なのに対して、日本は1%に過ぎません。個々のプロジェクトも大部分が、小規模で、製造工程を中心とした狭い発注範囲に留まっているといいます。

もちろん他の要因によるところもあると思います。
例えば言葉の違いです。英米系の企業は、インドやフィリピンなど英語を公用語とする国と直接やり取りができます。日本のようにブリッジＳＥやコミュニケータの確保で悩む必要はありません。

また、業界の構造も違います。欧米系の企業ではシステムをエンドユーザが内製する比率が高いので、同一業務を丸ごと委託できます。受託するオフショア開発企業では、業務の全体像を把握しやすく、時間を掛けてじっくりと理解を深めていくことができます。
それに対して、日本では外部のベンダが開発することが多いうえ、下請け、孫請けなどの多数の企業が参加しています。そのため、プロジェクト単位の短期の発注が多く、発注範囲が細切れになりやすいです。

現場が抵抗する理由の建前と本音

オフショア開発に切り替えるよう指示を出したとき、現場が抵抗する理由としてよく言われていたのが「オフショア開発に切り替えて問題が起きたら責任を取れない」というものです。
これを言われるとなかなか無理強いはできません。
しかし、本当は「今うまくいっているやり方を変えたくない」というのが本音なのです。

現状のままでもいずれ破綻する

私が所属していた部署ではパッケージの保守を行っていました。
そのパッケージは運用・保守業の負担が非常に重く、優秀な技術者を運用・保守作業に貼り付けなければなりませんでした。そのため、お客様の数が増えれば増えるほど、拡販やパッケージの刷新など新しいことをやる体力がなくなっていきました。

何年もその状態が続いていたので、所属員の平均年齢は非常に高くなっていました。それを改善しようと若い人を入れても、運用・保守というあまり面白くない作業のうえ、一人でたくさんの顧客を担当しなければならないことと、何かミスすると即事故につながる重圧で、モティベーションが非常に下がっていました。

そこでＰＭにオフショア開発への切り替えを打診しました。それに対するＰＭの答えは「問題が起きても責任はとれません」というものでした。
随分悩みましたが、そのＰＭの過去の行動を見ると５年以上何も手を打っていません。
「現状のままでもいずれ破綻する」と考え、私は現場の抵抗を押し切って、そのプロジェクトをオフショア開発へ切り替えることにしました。

切り替えには半年ほど掛かりましたが、オフショア開発への移行は順調に進み、そのプロジェクトにとってオフショア開発はなくてはならないものになっています。