近年、オフショア開発は今や当たり前のように活用されています。
しかしながら見にするのは失敗事例ばかり。
何故でしょう？
私は失敗するその理由のほとんどは実は日本側にあると考えてます。
そこでその理由について私の経験を元に以下にまとめてみました。
１．日本と同じ生産性でＷＢＳを作成する
当然のことながら設計書は日本語で記載されています。
ですのでオフショア側は仕様理解にも時間がかかります。
そして業務の背景は知りません。
日本の当たり前もオフショアには通用しません。
そんないろいろな壁があることを知っていながら
何故かスケジュールには考慮されていません。
オフショアを活用する一つの理由にコスト削減があります。
しかしながらコストが安いということは生産性もコストに
見合った生産性だということを前提に考えたほうが無難です。
２．ＱＡ、レビューのやり取りに時間がかかることを知らない
オフショア開発で一番苦労するのがコミュニケーションです。
特にＱＡのやり取りでは想定以上に時間がかかります。
そして進捗報告では日本側の回答が来ないため遅延しています。
と言った報告が上がってきます。
そして日本側とオフショア側の関係がギクシャクしてくるわけです。
そこに日本側の意識の甘さがあります。
オフショア開発で優先度を上げるべきタスクはＱＡ表のやり取りです。
このＱＡ表のやり取りをいかにスムーズに且つスピード感を
持って日本側が対応できるかがとても大事になります。
にも関わらず日本側でそういった意識を持って対応
できているSEは実に少ないと感じます。
３．翻訳、通訳が必要だということを分かっていても考慮しない
設計書はもちろん日本語で記載されています。
一方オフショア側の体制のほとんどのメンバーは日本語が読めません。
オフショア開発するにあたってオフショア側の体制のうち
日本語を話せる、通じるメンバーは全体のどのくらいの割合に
なるかがポイントになります。
経験上半分近くはいないとまずその部分が間違いなく
ボトルネックになります。
ですのでオフショアを活用する場合は日本語が
通じるメンバーの割合を意識してください。
４．日本側が不安のあまり干渉し過ぎ
オフショア開発では成功例よりも失敗例のほうをよく耳にします。
ですので日本側、特にエンドユーザはとても心配になります。
よって無駄にいろいろ確認してきますし、報告を必要以上に細かく聞いてきます。
そしてその対応にオフショア側は追われるわけです。
まさに本末転倒、デスマーチです。
心配なら直接現地に行って目で確かめてくればいいのです。
もし不安でやたらと状況を確認したいユーザがいれは
オフショアの拠点に行かせることが良いかと思います。
そして心配ならずっといてもらえばいいんです。
そのほうがまだましです。
５．日本側の設計書がオフショアを考慮していない(そのレベルに達していない)
そして実はこの理由が一番大きいのではと私自身は感じております。
複雑な日本語、記載していないけど製造の際に
考慮しなければいけない見えない要件等。
会話をしている中で自然とお互いの認識を確認し、
その前提の上で設計書が作成されているということは
まずは意識しましょう。
そしてこの当たり前のような意識はオフショア側には
当然ながらその感覚はありません。
ですので日本側で障害扱いの内容がオフショア側からは
仕様追加、変更と扱われるわけです。
そしてコストがかかり、結果としてこのオフショア先は
使えないという結論で失敗するわけです。
実は日本側にも問題があるということを自覚しましょう。
