社内でシステム開発の経験がない、プログラミングを知らない、業務フローを明確化・簡略化できない――などが重なると開発は滞るか頓挫する恐れがあります。
その開発先が海外の場合、その確率は非常に上がる事となります。
なぜ、難しいのか。それを実体験をもとにしてまとめたいと思います。
- オフショアとは
- 難しい原因は？
- 対策はどうするのか
の順で話をしていきます。
##オフショア開発とは
Wikipediaより引用すると下記の通りです。
オフショアリングは一つの国を拠点としていた営利事業を別の国に移転する経済行為と定義される。主な動機は既存の事業拠点より低額の人件費、税制度などであるが、近年、自国で足りていない専門家を補完するために他国の人材を活用する手段として注目されている。アウトソーシングとオフショアリングは類似した意味を保持するため度々対比されるが、同一国内での委託はオフショアではなくアウトソーシングを指す。逆に海外への業務の委託はアウトソーシングではなく、オフショアリングと定義される。
参照：Wikipedia オフショアリング
同一国内ではアウトソーシング――言わば、外注と呼ばれる事を海外へ委託する事ですね。
##難しい原因は？
では、なぜ海外であると難しくなるのか――。
それは文化や常識の違いが一番だと感じます。
ここで一つ実験をしてみましょう。
皆さん、りんごをイメージしてください。
頭に思い浮かべましたか？
では、それは何色ですか？ 形はどのような形ですか？
人によって、そのりんごの色は赤だったり緑だったりするでしょう。
形は丸い形をしているかもしれません。でも、それはサッカーボールのような丸い形ではないですね。
人によってはカットされている状態だったかもしれません。
このように「りんご」ひとつにしても色々な事を思い浮かべる事ができます。
では、システム開発する上で話をしている中で、仕様書にかかれていない部分についてどのようになるのでしょうか？
結果は簡単で、お互いの常識がすれ違うのでできるイメージが両者で異なります。
依頼する側は「やってくれるだろう」と思っていても、相手側は「知らないよ」となってしまいます。
または、全く異なる仕様で出てくる場合もあります。
##対策はどうするのか
まずは仕様を揃える事です。
打ち合わせから納品まで仕様書、というものが存在しておらず（結果的に僕が作成しています）
何もかもが曖昧でした。
そこを正して、1つずつ違う所を指摘したり、仕様を修正するよう指示したりしています。
そうして、少しずつまともに動くものへと前進していきます。
口頭のみでは決してダメで、仕様書や図示等を出してそれらを合わせながら打ち合わせをする方が何倍も効果的であり、手戻りは減ります。
ただ、僕の場合について言えば、手戻りは減ったのですが、システムを理解すればするほど、バグを見つけてしまっているので何とも言えないのですが――。
なぜ、入力できなくなった！
とか。それについて、教えて貰ったのを参考に自分なりでやってきている事をまたまとめます。